Материальный информационные или иной объект который используется в ходе реализации бизнес процесса

5.1. Основные элементы процессного подхода

По существу, построить любую систему
управления можно только на основе
однозначно определенных объектов, из
которых будет состоять эта система. То
же самое относится к системе процессного
управления организацией. Самыми главными
объектами в любой системе управления
являются «Объект управления» — то, чем
управляют, и «Субъект управления» —
тот, кто управляет. Также при построении
бизнес-модели организации приходится
сталкиваться с такими понятиями как
бизнес-процессы и функции.

Классическое определение функции в
бизнесе выглядит следующим образом.

Функция— устойчивая совокупность однородных
специализированных работ (действий,
операций), способность реализации
которых поддерживается в компании.

В настоящее время сформулированы
несколько различающихся определений
бизнес-процессов.

Бизнес-процесс— совокупность различных видов
деятельности, в рамках которой «на
входе» используется один или более
видов ресурсов, и в результате этой
деятельности «на выходе» создается
продукт, представляющий ценность для
потребителя (М. Хаммер, Д. Чампи).

Бизнес-процесс— несколько связанных работ или процедур,
в совокупности реализующих конкретную
цель текущей деятельности в рамках
существующей организационной структуры.

Бизнес-процесс— совокупность взаимосвязанных или
взаимодействующих видов деятельности,
которые преобразуют «входы» в «выходы»
(ISO 9000:2000).

Бизнес-процесс– это цепочка работ (функций), результатом
которой является какой-либо продукт
или услуга.

Из приведенных определений и смысла,
вкладываемого консультантами-практиками
в данные понятия, бизнес-процессы и
функции можно охарактеризовать следующим
образом:

  • бизнес-процессы и функции состоят из
    работ;

  • различие между процессами и функциями
    заключается в различии способов
    объединения работ и используемых
    элементов для их описания (см. табл.
    1.1);

  • функция является частью бизнес-процесса
    и при этом может входить, как в различные
    этапы процесса, так и в различные
    бизнес-процессы (см. рис. 1.2).

Рис. 5.1. Бизнес-процессы
и функции

Таблица 5.1. Различия между бизнес-процессами
и функциями

Функция

Бизнес-процесс

Состоит из однородных (одинаковых)
работ;

Работы, входящие в состав функции в
совокупности представляют узкопрофильный
вид деятельности.

Состоит из разнородных (различных)
работ;

Работы, входящие в состав процесса в
совокупности представляют широкопрофильный
вид деятельности, на выходе которого
получается результат, обладающий
ценностью для потребителя;

Описание процесса включает перечень
«входов», «выходов», «поставщиков» и
«потребителей» бизнес-процесса.

В рамках процессного подхода любое
предприятие рассматривается как
бизнес-система – система, которая
представляет собой связанное множество
бизнес-процессов, конечными целями
которых является выпуск продукции или
услуг.

Достижение определенной совокупности
целей за счет выполнения бизнес-процессов
называется деревом целей. Дерево
целей имеет, как правило, иерархический
вид. Каждая цель имеет свой вес и критерий
(количественный или качественный)
достижимости.

Бизнес-процессы реализуют бизнес-потенциал
компании. Множество работ, входящих в
состав бизнес-процессов, представляет
иерархическую декомпозицию функциональной
деятельности и называется деревом
функций (функционалом).

Бизнес-процессы связаны с показателями
деятельности предприятия, образующими
дерево показателей. На основании
показателей строится система показателей
оценки эффективности выполнения
процессов.

Владельцы процессов контролируют свои
бизнес-процессы с помощью данной системы
показателей. Наиболее общими показателями
оценки эффективности бизнес-процессов
являются:

  • количество производимой продукции
    заданного качества за определенный
    интервал времени;

  • количество потребляемой продукции;

  • длительность выполнения типовых
    операций и др.

Критериями эффективности основных
процессов являются обычно качество,
точность и своевременность выполнения
каждого заказа. Многие потребители
рассматривают увеличение качества как
нечто более важное, чем уменьшение цены.

Для управления процессом необходимо
назначить должностное лицо, ответственное
за выполнение процесса и его результат.
Чтобы должностное лицо могло управлять
процессом, в его распоряжение должны
быть выделены ресурсы, необходимые для
проведения процесса, делегированы права
и полномочия (хотя права и полномочия
для простоты тоже можно отнести к
ресурсам должностного лица). Каждый
процесс существует не сам по себе, а
выполняет какие либо функции в организации
и является подконтрольным высшему
руководству организации. Поскольку в
ряде случаев процессом может управлять
не один сотрудник, а коллегиальный орган
управления, то определение владельца
процесса будет следующим.

Владелец
процесса
— это должностное
лицо или коллегиальный орган управления,
имеющий в своем распоряжении ресурсы,
необходимые для выполнения процесса,
и несущий ответственность за результат
процесса,

Он должен знать бизнес-процесс, следить
за его выполнением и совершенствовать
его эффективность. Владельцу бизнес-процесса
необходимо обладать коммуникативностью,
энтузиазмом, способностью влиять на
людей и производить изменения.

Определим еще несколько понятий, а
именно:

  • • выход (продукт) процесса;

  • • вход процесса;

  • • ресурс процесса.

Выход
(продукт)

процесса — материальный или информационный
объект или услуга, являющийся результатом
выполнения процесса и потребляемый
внешними по отношениюк процессу
клиентами.

Выход (продукт) процесса всегда имеет
потребителя. В случае, если потребителем
является другой процесс, то для него
этот выход является входом. Выход
(продукт) процесса также может
использоваться в качестве ресурса при
выполнении другого процесса. К выходам
процесса могут относиться: готовая
продукция, документация, информация в
виде отчетов, персонал (для процесса
«Обеспечение кадрами»), услуги и т.д.

Вход
бизнес-процесса

материальный или информационный объект,
который в ходе выполнения процесса
преобразуется в выход.

Вход всегда должен иметь своего
поставщика. К входам процесса могут
относиться: сырье, материалы, полуфабрикаты,
документация, информация, персонал (для
процесса «Обеспечение кадрами»), услуги
и т.д.

Ресурс
бизнес-процесса

материальный или информационный объект,
постоянно используемый для выполнения
процесса, но не являющийся входом
процесса.

К ресурсам процесса могут относиться:
информация, персонал, оборудование,
программное обеспечение, инфраструктура,
среда, транспорт, связь и пр. Владелец
процесса в ходе планирования и управления
процессом производит распределение и
перераспределение ресурсов для достижения
наилучшего результата процесса. Отнесение
информации одновременно ко входам и
ресурсам процесса не является ошибкой.

Управляющий
фактор бизнес-процесса

материальный или информационный объект,
регламентирующий выполнение процесса,
но не являющийся входом процесса.

Пример 1. В случае процесса «маркетинг»
информация
является основнымвходом,
который преобразовывается ввыход
отчет,
контракт
или прогноз
продаж. В случае основных производящих
и вспомогательных процессов или
подразделений информация о планах и
перспективах организации, о конкурентах
и рынке может являться ресурсом или
управляющим фактором, так как напрямую
не преобразовывается в выходы.

Пример 2. Персонал, с точки зрения основных
процессов, является ресурсом, который
поставляет кадровая служба. Сточки
зрения кадровой службы — персонал это
продукт, который поступает на вход в
виде необученных кандидатов на заполнение
вакансий, а на выходе процесса подбора
и обучения кадров готовые специалисты
передаются руководителям подразделений.

Пример 3 Счет на оплату является входом
для финансовой службы. Выходом является
оплаченный счет или копия платежного
поручения. Для основного процесса
бюджет, в рамках которого производится
оплата счетов, является ресурсом .

Существует еще несколько признаков, по
которым можно отнести объекты к категориям
входов или ресурсов.

Ресурсы процесса:

  • • находятся под управлением владельца
    процесса;

  • • их объем планируется на большое
    количество циклов или длительный период
    работы процесса.

Входы процесса:

  • • поступают в процесс извне;

  • • их объем планируется на один или
    несколько циклов работы процесса, или
    выпуск определенного объема продукта.

Деление объектов, необходимых для
выполнения процесса, на «входы» и
«ресурсы», является достаточно условным.
Более важным для выполнения процесса,
является точное определение того, что
должно поступить в распоряжение владельца
процесса, чтобы процесс состоялся и был
выполнен успешно.

Пример 4. Рассмотрим процесс производства
готовой продукции и процесс обслуживания
оборудования. Предположим, что владельцем
процесса производства является директор
по производству, а владельцем процесса
обслуживания оборудования — главный
механик. В этом случае работоспособное
оборудование является ресурсом,
необходимым для осуществления процесса
производства. В то же время работоспособное
оборудование является выходом процесса
обслуживания оборудования.

Пример 5. Рассмотрим процесс сбыта
готовой продукции и процесс транспортного
обслуживания. Владельцем первого
процесса является начальник отдела
сбыта, второго — начальник транспортного
цеха. Для выполнения работы владельцу
процесса сбыта требуется служебный
автомобиль, причем он должен быть
доступен определенное количество часов
в месяц. Эти часы возможного использования
автомобиля являются ресурсом для
процесса сбыта. Для процесса транспортного
обслуживания выходом процесса будет
технически исправный, заправленный и
готовый к эксплуатации автомобиль.
Обратим внимание, что за состояние
автомобиля отвечает начальник
транспортного цеха, а использует его
возможности по транспортировке (в
качестве ресурса своего процесса)
начальник отдела сбыта.

Выходы, входы и ресурсы должны обозначаться
существительными, поскольку они являются
материальными объектами.

При обозначении выходов или входов
процесса часто приходится сталкиваться
со следующей проблемой. Различные
методики описания процессов разделяют
материальный объект и сопутствующую
ему документацию на два различных
объекта или два различных потока —
материальный поток и информационный
поток (документальный поток).

В некоторых случаях такое разделение
является оправданным, в некоторых —
нет. Рассмотрим данную ситуацию на
следующем примере.

Пример 6. Для потребителя получаемый
продукт должен состоять из самого
продукта и сопроводительной документации.
Сопроводительная документация может
состоять из накладной, паспорта,
сертификата, чека, подтверждающего
оплату данного продукта товара или
услуги. Последним звеном в поставке
продукта (товара или услуги) потребителю
является кладовщик (экспедитор, курьер).
Если эти лица передают потребителю
продукт без необходимой сопроводительной
документации, то продукт в ряде случаев
вообще не может быть использован по
назначению. Например, продукт без
сертификата соответствия, если этот
продукт включен в список продуктов
обязательной сертификации. Соответственно,
случаи поставки продукта без документации
должны рассматриваться как случаи
некомплектной поставки или выпуска
дефектной продукции.

Кратко рассмотрим базовую методику
управления процессом. На рисунке 5.1
показана концептуальная схема управления
процессом, основанная на сформулированном
выше определении процесса.

Рис. 5.1. Концептуальная
схема управления процессом

Процесс, представленный на рисунке 5.1,
имеет входы и выходы. Для выполнения
процесса используются ресурсы (персонал,
оборудование, инфраструктура, среда и
пр.). Управление процессом осуществляет
владелец процесса. Все ресурсы, необходимые
для выполнения процесса, находятся в
его распоряжении. Можно дополнить
определение владельца процесса,
приведенное выше, следующим образом:
«владелец процесса — должностное лицо,
которое имеет в своем распоряжении
персонал, инфраструктуру, программное
и аппаратное обеспечение, информацию
о процессе, управляет ходом процесса и
несет ответственность за результаты и
эффективность процесса». Таким образом,
в рассматриваемом понимании процессного
подхода к управлению наличие владельца
процесса, обладающего ресурсами, является
важнейшим необходимым условием.

Для того чтобы вести управление процессом,
владелец процесса должен получать
информацию о ходе процесса и информацию
от потребителя (клиента) процесса.
Поэтому одной из составляющих частей
процессного управления является система
поступления информации владельцу
процесса. Соответственно, вышестоящему
руководству должна поступать регулярная
отчетность о ходе процесса.

Процесс не может существовать отдельно
от организации. Для работы процессов
вышестоящее руководство должно определить
назначение процесса, поставить перед
владельцем процесса цели и утвердить
плановые значения показателей
результативности и эффективности
процесса. Владелец процесса, в свою
очередь, принимает управленческие
решения на основании поступившей
информации и установленных планов.

Таким образом, на рисунке 5.1 представлена
достаточно сложная схема процесса,
учитывающая взаимосвязь горизонтальных
материальных потоков и ресурсов и
вертикальных информационных потоков
и управленческих взаимодействий.

Соседние файлы в папке 1-cем(зачет)

  • #
  • #
  • #
  • #
  • #
  • #

При рассмотрении сущности бизнес-процесса важно выделить и описать основные его компоненты (рис. 2.3), к которым относятся следующие:

  • владелец бизнес-процесса;
  • входы бизнес-процесса;
  • выходы бизнес-процесса;
  • поставщик бизнес-процесса;
  • потребитель (клиент) бизнес-процесса;
  • показатели бизнес-процесса;
  • ресурсы бизнес-процесса;
  • интерфейс бизнес-процесса;
  • регламент бизнес-процесса.

Компоненты бизнес-процессов

Рассмотрим составляющие бизнес-процесса более подробно. 1. Владелец бизнес-процесса – должностное лицо, которое имеет в своем распоряжении персонал, инфраструктуру, программное и аппаратное обеспечение, информацию о бизнес-процессе, управляет ходом бизнес-процесса и несет ответственность за результаты и эффективность бизнес-процесса.

Владельцу процесса даются все полномочия для того, чтобы по своему усмотрению инициировать перемены в процессе. Один сотрудник может быть владельцем нескольких бизнес-процессов. Но в одном бизнес-процессе может быть только один владелец.

Владелец бизнес-процесса, несет ответственность:

  • за исполнение бизнес-процесса и соблюдение поточности операций;
  • отслеживание ключевых показатели эффективности бизнес-процесса (англ. – Key Performance Indicators, KPI);
  • контроль за получением необходимых ресурсов;
  • анализ исполнения бизнес-процесса и инициацию его улучшений;
  • решение конфликтных ситуаций между участниками бизнес-процесса;
  • коммуникации между участниками бизнес-процесса и другим персоналом компании.

Это не полный перечень, а лишь основные задачи, которые владелец бизнес-процесса должен решать ежедневно. В этой связи владелец процесса должен создать инициативную группу, состоящую из нескольких участников процесса, в совокупности обладающих знаниями обо всех особенностях выполняемых работ/операций, решающие отдельные задачи по достижению эффективности выполняемого процесса, его улучшению процесса и совершенствованию.

Владелец процесса может привлекать для работы специалистов по информационным технологиям, экспертов и консультантов, а также поставщиков и потребителей бизнес-процесса. Команда совещается на регулярных встречах.

2. Вход бизнес-процесса.

Существует два основных определения:

  • Вход процесса – это продукт (материальный или информационный объект), который в ходе выполнения процесса преобразуется в выход.
  • Вход процесса – это объект бизнес-процесса (функция, операция, совокупность элементов), взаимодействующий с внешними бизнес-процессами и получающий от них информацию/материальные ресурсы, необходимые для выполнения бизнес-процесса.

Вход процесса должен, с одной стороны, обеспечивать нормальное протекание процесса (т.е. обладать всей необходимой информацией, ресурсами, регламентами и т.д.). С другой стороны, вход процесса является событием, инициирующим запуск (активацию) бизнес-процесса.

У бизнес-процесса могут возникать различные входы: первичные и вторичные.

Первичные входы – изначальные материальные и нематериальные входы, запускающие операции процесса. Включает поток объектов, инициирующий «запуск» бизнес-процесса, например заказ клиента, план закупок и т.д.

Вторичные входы – потоки, являющиеся вспомогательными по ходу исполнения бизнес-процесса, не инициирующие его. Они включают потоки объектов, обеспечивающие нормальное протекание бизнеспроцесса, например стандарты, правила, механизмы выполнения действий, оборудование и пр.

3. Выход бизнес-процесса. Описывает то, что создается в результате деятельности, ее конкретную цель (ценность для клиента, ценность для заинтересованных лиц) – продукт или услуга, которые соответствуют заранее определенным условиям и удовлетворяют ожидания потребителя.

Бизнес-процесс может иметь первичные и вторичные выходы. Первичным выходом называются выходы, представляющие собой главную цель процесса. Они представляют собой основной результат, ради которого существует бизнес-процесс, определяются его целью, назначением бизнес-процесса.

Вторичные выходы – потоки результатов процесса, отличные от основной его цели, такие выходы также могут служить входами другим процессам. Вторичный выход является побочным продуктом бизнеспроцесса, который может быть востребован вторичными клиентами.

4. Поставщик бизнес-процесса – это тот, кто предоставляет необходимые для запуска бизнес-процесса ресурсы. Поставщиков в бизнес-процессе бывает несколько, но должно быть не менее одного. Зона ответственности поставщика – в нужное время и в полном объеме обеспечить участников бизнес-процесса всем необходимым.

Поставщики могут быть внутренними и внешними в зависимости от их расположения относительно организации, в которой протекает процесс. Внешними поставщиками процессов могут быть внешние организации, а также подразделения или должностные лица сторонней компании. В качестве внутренних поставщиков процессов могут выступать подразделения или должностные лица данной компании, а также другие бизнес-процессы этой компании.

Также поставщиков процессов можно подразделять на первичных и вторичных – в зависимости от характера предоставляемых ими входов. Входы бизнес-процесса могут первичными в случае, если они служат инициацией бизнес-процесса, или же вторичными в обратном случае.

5. Потребитель процесса – субъект (физическое или юридическое лицо, функциональное подразделение, другой процесс и т.д.), использующий результаты (выходы) бизнес-процесса. Потребителей бизнес-процессов также называют клиентами процессов. Потребители также могут быть внутренними и внешними в зависимости от нахождения относительно организации.

Внутренние – находящиеся в организации и в ходе своей деятельности использующие результаты (выходы) предыдущего бизнес-процесса; внутренними клиентами процесса являются подразделения (исполнители, процессы);

Внешние – находящиеся за пределами организации и использующие или потребляющие результат деятельности (выход) организации. Внешними клиентами организации являются не только потребители ее продукции или услуг.

К внешним клиентам организации целесообразно отнести все пять основных групп, заинтересованных в успешной деятельности организации. Это потребители основных продуктов; собственники (акционеры, инвесторы); персонал; поставщики, субподрядчики и партнеры; общество (органы власти и общественные организации).

6. Для оценки эффективности бизнес-процессов используются, как правило, качественные и количественные показатели, соответственно под критериями эффективности бизнес-процессов понимают количественную и качественную характеристику бизнес-процесса, которая выступает основанием для его оценки.

При проведении анализа бизнес-процессов, показатели эффективности принято группировать на три категории, которые представлены в табл. 2.3.

Компоненты бизнес-процессов

Показатели продукта процесса и удовлетворенности клиентов процесса отражают как количественную, так и качественную сторону результата выполнения процесса. Результат выполнения процесса определяется, прежде всего, объемом выпущенной продукции, ее внешним оформлением (упаковкой) и другими характеристиками, влияющими на степень удовлетворенности клиентов.

Анализ эффективности бизнес-процессов выводит на первое место проблемы обоснования системы показателей, которые характеризовали бы различные стороны процесса и этапы его выполнения.

Перечень абсолютных показателей представлен в табл. 2.4. Каждая организация должна создавать подобную систему показателей с учетом специфики процессов организации. Система показателей процесса должна развиваться вместе с процессом: по мере улучшения процесса следует использовать все более сложные показатели.

Представленные показатели не дифференцированы относительно основных бизнес-процессов организации. Каждый процесс чаще всего характеризуется далеко не одним показателем, а целой системой. Таким образом, для отладки бизнес-процессов организации необходим не набор показателей, а взаимосвязанная группа. Относительные показатели анализа бизнес-процессов представлены в табл. 2.5.

В целом, в систему должны входить только те показатели, на которые может непосредственно воздействовать владелец процесса. Организации нуждаются в периодической оценке эффективности бизнес-процессов, ведь это необходимо для разработки процессов и обеспечения их функционирования должным образом.

Компоненты бизнес-процессов

Компоненты бизнес-процессов

Компоненты бизнес-процессов

7. Ресурсы бизнес-процесса – перечень объектов, потребляемых в ходе выполнения бизнес-процесса и необходимых для получения конечного результата процесса. Особенности ресурсов бизнес-процесса заключаются в том, что потребности в них всегда безграничны, но в силу добываемости, исчерпаемости, созидаемости, платности, они всегда в реальности ограничены. Ресурсы бизнес-процесса показаны на рис. 2.4.

Проблема эффективности (результативности) бизнеса часто заключается в том, что в бизнесе мало уделяется внимания системе управления ресурсами, которая должна присутствовать на предприятии. А это существенно снижает процентные показатели эффективности управления издержками, вызывает нерациональность использования ресурсов, порождает непредвиденные, кризисные явления.

Компоненты бизнес-процессов

Система управления ресурсами бизнес-процесса состоит в привлечении необходимых, достаточных ресурсов для достижения запланированных целей, их соединении в производящей силе, обоснованном, сбалансированном распределении для получения доходов (прибыли), превышающих затраты на такие ресурсы.

Кроме того ресурсная база должна формироваться, развиваться на основе стратегических решений, поскольку тактический подход (базирующийся на текущих целях) на практике повышает фактические затраты. Оптимальное привлечение ограниченных ресурсов и эффективное, рациональное их использование – это проявление бизнес-способностей.

К основным характеристиками ресурсов относятся:

  • привлечение отдельных их видов происходит на ресурсных рынках: труда, капитала (существует конкурентная борьба за привлечение ресурсов);
  • обладают свойствами: альтернативностью (взаимозаменяемостью), мобильностью, комплексностью, комбинированностью;
  • стоимость ресурсов определяется не расценками на ресурсы, а ценой того, от чего приходится отказываться, чтобы их заполучить (альтернативная стоимость).

Ресурсы бизнес процесса – это определенный перечень необходимых объектов, потребляемых в ходе предпринимательства и без которых невозможно получение конечных результатов бизнес-процесса.

1. Интерфейс процесса. Каждый процесс использует внешние ресурсы и производит продукты или услуги. Все эти входы и выходы процесса являются интерфейсами (interface, англ. взаимодействие) процесса.

Если требования к качеству ресурсов компания предъявляет к поставщикам и добивается их выполнения, то с другой стороны процесса находятся клиенты, которые, в свою очередь, предъявляют требования к результатам деятельности компании. Таким образом, границы устанавливают пределы ответственности за результаты процесса.

Границы процесса – события, начинающие и завершающие процесс, которых может быть несколько.

Интерфейсы возникают не только на границах процесса. При переходе от одной функции процесса к другой передаются также и ресурсы, и это тоже является интерфейсом. Если обе функции, между которыми располагается интерфейс, принадлежат процессу, значит этот интерфейс внутренний в отличие от внешнего интерфейса, находящегося на границе процесса.

Взаимодействие может осуществляться через документ, информационную систему и т.д. Определение и унификация интерфейсов необходимы для слаженной работы процесса. Одной из основных задач управления бизнес-процессом является выявление несоответствий результатов, полученных одной операцией, для выполнения последующей операции. Для решения подобных проблем разрабатываются форматы интерфейсов, учитывающие требования потребителей к результатам выполнения операции.

. Регламентация бизнес-процесса. Регламент бизнес-процесса – документ, описывающий последовательность операций, ответственность, порядок взаимодействия исполнителей и порядок принятия решений по улучшениям.

Регламентации составляются по каждому бизнес-процессу и описывают порядок взаимодействия всех включенных в конкретный бизнес-процесс пользователей, при этом каждый процесс составляет отдельный массив данных. Цели регламентации бизнес-процессов следующие показаны на рис. 2.5.

Компоненты бизнес-процессов

Чтобы регламентация бизнес-процессов была выполнена правильно, требуется определить для каждого из процессов несколько параметров:

  • владельца бизнес-процесса;
  • входы и выходы бизнес-процесса;
  • участников бизнес-процесса;
  • показатели бизнес-процесса;
  • используемые технологии и ресурсы.

Последовательность регламентации системы управления бизнес- процессами представлена в табл. 2.6.

Компоненты бизнес-процессов

Компоненты бизнес-процессов

Регламент процесса утверждается руководством предприятия и служит законодательным документом в рамках своего содержания.

Структурно регламент состоит из нескольких разделов, к основным из которых относятся:

  • титульный лист;
  • паспорт регламента;
  • общие положения;
  • общее описание процесса;
  • детальное описание процесса;
  • показатели эффективности реализации процесса;
  • шаблоны форм документов;
  • лист согласования и лист регистрации изменений.

Для исполнителей и руководителей регламент бизнес-процесса является основой для урегулирования спорных вопросов, возникающих в рамках трудовой деятельности. Актуализация регламента осуществляется по мере необходимости или с заданной периодичностью.

Потребитель — не идиот. Он — ваша жена. (Дэвид Огилви)

Введение

     Цель статьи — рассказать о некоторых вопросах, связанных с процессным подходом к управлению и, в частности, с построением в организации «сквозных» бизнес-процессов (1). Общение с директорами и специалистами российских промышленных предприятий показало их двоякое отношение к сквозным процессам. Часть руководителей придерживается подхода к сегментации (выделению) процессов в рамках структурных подразделений (понимание 1), часть использует в своей работе понятие «сквозных» или межфункциональных(2) процессов (понимание 2). Обсуждение вопросов, связанных с реализацией процессного подхода в компаниях, выявило ряд существенных проблем. Дело в том, что при выделении и регламентации сквозных процессов не полностью решаются такие вопросы, как распределение ресурсов, управление процессом и оценка его эффективности. Сквозные процессы (например, процесс обслуживания клиента) определяются и документируются. Иногда даже определяются «ответственные за процесс» или т.н. владельцы процессов (подробнее см. ниже). В то же время, не создаются реально работающие механизмы выделения ресурсов владельцу процесса и система управления процессом в целом. Часто под сквозными процессами понимается деятельность, регламентированная в виде внутренних инструкций или стандартов, в которых прописан порядок участия подразделений в некоторой общей работе. В таких документах, как правило, описывается общая последовательность выполнения работ без распределения ответственности руководителей и порядка управления этими работами. На практике это приводит к тому, что сквозной процесс документально оформлен, но эффективное управление этим процессом не обеспечивается. Возникает вопрос, стоит ли выделять и документировать сквозные процессы на начальной фазе внедрения процессного подхода, когда деятельность компании слабо документирована, размыты зоны ответственности руководителей, не описаны и не распределены ресурсы? Ответ на этот вопрос является предметом рассмотрения в данной статье.
     Прежде всего, определим понятие бизнес-процесса. Бизнес-процесс — повторяющаяся, регламентированная деятельность, которая по определенной технологии преобразует входы и ресурсы в выходы (продукты) бизнес-процесса, представляющие ценность для потребителя. Данное определение близко к определению стандарта ИСО серии 9000:2000 (см. [1], [2]). Обратим внимание читателя, что в этом определении не говорится, где именно локализована деятельность, преобразующая входы в выходы. Это может быть деятельность, выполняемая в рамках одного структурного подразделения или отдела, а может быть деятельность, выполняемая различными подразделениями. Оба эти взгляда имею право на существование. Важно, чтобы при внедрении процессного подхода каждая их этих двух трактовок получила последовательную, логичную и экономически эффективную практическую реализацию. Рассмотрим указанные два понимания бизнес-процесса подробнее.

    Бизнес-процессы подразделения

     Бизнес-процесс подразделения — бизнес-процесс, ограниченный рамками одного структурного подразделения организации. Это означает, что все ресурсы, необходимые для выполнения процесса, находятся под управлением руководителя структурного подразделения. Он же является владельцем процессов подразделения, как показано на рисунке 1.

image001.gif

Рисунок 1. Бизнес-процессы подразделения.

     Владелец бизнес-процесса — должностное лицо, которое имеет в своем распоряжении ресурсы и управляет ходом бизнес-процесса на основе принципов PDCA (-цикл Деминга

) и несет ответственность за результаты и эффективность бизнес-процесса (см. [3],[4], [5]).
     Внутри подразделения может быть выделено несколько процессов, как показано на рисунке 1. Возможна ситуация, когда внутри подразделения будет выделен всего один процесс.
     У руководителя подразделения могут быть заместители — начальники отделов, которые так же могут являться владельцами процессов более низкого уровня. В любом случае, за все процессы подразделения отвечает руководитель подразделения.
     Для дальнейших рассуждений нам необходимо определить еще несколько понятий, а именно:
       — выход (продукт) процесса;
       — вход процесса;
       — ресурс процесса.

    Выход (продукт) — материальный или информационный объект, являющийся результатом выполнения процесса и потребляемый внешними по отношению к процессу клиентами (другими процессами или субъектами). Результат выполнения процесса может использоваться в качестве ресурса при выполнении другого процесса.
    Вход бизнес-процесса — продукт, необходимый для выполнения бизнес-процесса. При выполнении процесса вход процесса преобразуется в выход процесса.
    Ресурс бизнес-процесса — материальный или информационный объект, постоянно используемый для выполнения процесса, но не являющийся входом процесса. К ресурсам процесса относятся: информация, персонал, оборудование, программное обеспечение, инфраструктура, среда, транспорт и прочее. Ресурсы процесса находятся под управлением владельца процесса.

    Пример 1. Рассмотрим процесс производства готовой продукции и процесс обслуживания оборудования. Предположим, что владельцем процесса производства является директор по производству, а владельцем процесса обслуживания оборудования — главный механик. В этом случае работоспособное оборудование является ресурсом, необходимым для осуществления процесса производства. В тоже время оборудование является выходом процесса обслуживания оборудования.
    Пример 2. Рассмотрим процесс сбыта готовой продукции и процесс транспортного обслуживания. Владельцем первого процесса является начальник отдела сбыта, второго — начальник транспортного цеха. Для выполнения работы владельцу процесса сбыта требуется служебный автомобиль, причем он должен быть доступен определенное количество часов в месяц. Эта сумма часов возможного использования автомобиля является ресурсом для процесса сбыта. Для процесса транспортного обслуживания выходом процесса будет технически исправный, заправленный и готовый к эксплуатации автомобиль. Обратим внимание, что за состояние автомобиля отвечает начальник транспортного цеха, а использует его возможности по транспортировке ( в качестве ресурса своего процесса) начальник отдела сбыта.

     Локализация бизнес-процесса в рамках одного структурного подразделения означает следующее. В подразделение поступает информация и материалы, являющие продуктами деятельности других процессов-поставщиков. Они преобразуются процессами подразделения в результаты (выходы), потребляемые внутренними и внешними клиентами. Руководитель подразделения и его заместители управляют процессами подразделения и обеспечивают их результативность и эффективность.
     Как быть, если создание продукта в подразделении предполагает взаимодействие с процессами другими подразделений, как показано на рисунке 2.

image002.gif

Рисунок 2. Взаимодействие бизнес-процессов подразделений.

    В этом случае бизнес-процесс «Б» Подразделения 2 является поставщиком бизнес-процесса «А». Определяются границы процессов по входам и выходам, регламентируются требования (формы, сроки, ТУ и т.п.) по входам/выходам. Таким образом, деятельность внутри каждого подразделения четко структурируется, определяются зоны ответственности, распределяются ресурсы и, что очень важно, четко определяется порядок взаимодействия подразделений(3).

    Сквозные бизнес-процессы

    Сквозной (или межфункциональный) бизнес-процесс — бизнес-процесс, полностью или частично включающий деятельность, выполняемую структурными подразделениями организации, имеющими различную функциональную подчиненность. Пример сквозного процесса показан на рисунке 3.   

image003.gif

Рисунок 3. Сквозной (межфункциональный) процесс.

     В качестве примера, на рисунке 3 схематично показано, что сквозной процесс включает в себя примерно половину деятельности, выполняемой в подразделении 1, и некоторые составляющие деятельности других подразделениях.
     В некоторых источниках сквозной процесс определяется как элементарный поток работ — Work Flow (4) (последовательная во времени передача работы от одного исполнителя к другому, выполняемая согласно определенной логике). Такое определение является более узким по сравнению с рассматриваемым в статье, т.к. не включает в себя понятие ресурсов и системы управления процессом.
     По нашему мнению, сквозной процесс, также как и процесс подразделения, должен обязательно иметь владельца процесса. В его распоряжении должны находиться ресурсы, необходимые для выполнения процесса. Если владелец сквозного процесса не имеет ресурсов, то его роль сведется к сбору информации о деятельности процесса и доклада ее руководству организации, т.е. появится еще один контролер в худшем смысле этого слова(5).

     Пример 3. Рассмотрим процесс обслуживания клиента или, другими словами, процесс сбыта. С одной из точек зрения можно отнести к этому процессу следующие виды деятельности:
    — анализ рынка (отдел маркетинга);
    — анализ заявки клиента и подготовка договора (отдел сбыта);
    — согласование договора (юридический отдел);
    — анализ возможностей производства (производственный отдел);
    — расчет плановой себестоимости заказа (планово-экономический отдел);
    — анализ состояния расчетов с клиентом (финансовый отдел);
    — мониторинг состояния заказа в производстве (отдел сбыта);
    — отгрузка готовой продукции (склад);
    — фактурирование (бухгалтерия);
    — и проч.
    Таким образом, рассматриваемый сквозной процесс будет включать деятельность, выполняемую в следующих подразделениях: отдел маркетинга, отдел сбыта, юридический отдел, производственный отдел, планово-экономический отдел, финансовый отдел.

     Очевидно, что отнесение деятельности того или иного подразделения к сквозному процессу является субъективным и зависит от произвола конкретного руководителя предприятия. Обратимся к рисунку 2 и рассмотрим принадлежность функции «Х» в какому-либо подразделению. Руководитель подразделения 1 может предложить определить сквозной процесс, в котором функция «Х» находится под его управлением. Но руководитель подразделения 2 может не согласиться с такой постановкой задачи, например, обосновав необходимость личного управления функцией «Х» сложностью технологии и специальными требованиями к квалификации. На основе каких принципов в этом случае будет выделен сквозной процесс? Этот вопрос не имеет однозначного ответа.
     Сказанное выше означает, что при выделении сквозных процессов у руководства компании никогда не может быть уверенности в обоснованности сделанного выбора. Те руководители, которые осознают зыбкость такого подхода, пытаются всячески обосновать выделение сквозных процессов различными документально оформленными и якобы «общепринятыми» подходами: некоторые (см. [8]) пытаются интерпретировать стандарты ISO (см. [1], [2]) серии 9000:2000, некоторые опираются на 13-процессную модель американской бенчмаркинговой палаты, некоторые цитируют Хаммера и Чампи (см. [7]) и т.д. Тем не менее, можно уверенно констатировать, что универсальных принципов выделения сквозных процессов, лишенных субъективности, пока никто не предложил.
     Для чего пытаются определять сквозные процессы? По мнению многих руководителей, основная причина состоит в том, что путем выделения в организации сквозных процессов решается  проблема неэффективного взаимодействия подразделений различной функциональной подчиненности или, говоря другими словами, устраняются т.н. «функциональные барьеры». Ставится задача ориентировать деятельность подразделений компании на конечный результат и удовлетворение требований клиентов. Ход мыслей руководителей при этом примерно следующий: «:выделим наиболее важные сквозные процессы, ориентированные на удовлетворение клиентов компании, улучшим эти процессы, деятельность организации в целом улучшится:». Что означает такой подход на практике? Он означает, что из слабо документированной, плохо управляемой деятельности подразделений пытаются выделить некоторую часть работ, которая оформляется как сквозной процесс и которой, в дальнейшем, предполагается уделить большее внимание руководителей. Но обратим внимание, что изменения системы управления не происходят сами собой, они требуют изменения как принципов и средств управления, так и самих руководителей, их отношения к управлению. Поэтому простое выделение сквозных процессов, как правило, не приводит к изменению ситуации в компании.
     Подход, связанный с выделением сквозных процессов, видится нами как попытка руководителей российских предприятий упростить себе жизнь без серьезного изменения системы управления. На сегодняшний день практически не известны примеры серьезного ОБОСНОВАНИЯ ЦЕЛЕСООБРАЗНОСТИ внедрения сквозных процессов на промышленных предприятиях.
    Не будем подробно разбирать все проблемы использования сквозных процессов в организации (подробно они описаны в [6]), остановимся только на одной ключевой проблеме — проблеме распределения ресурсов. Выделяя и регламентируя сквозной процесс в окружающем его управленческого бардаке, мы тут же сталкиваемся с необходимостью структурировать всю остальную деятельность, не попавшую в рамки сквозного процесса. Почему? Дело в том, что эффективно управлять сквозным процессом можно только используя конкретные ресурсы: людей, оборудование, инфраструктуру и т.д. Для того, чтобы все эти ресурсы оказались в руках владельца сквозного процесса, должны быть созданы четкие правила, механизмы выделения ресурсов руководителями функциональных подразделений. Руководитель функционального подразделения в этом случае играет роль владельца ресурсов, а одной из его важнейших задач является управление внутренними процессами подразделения по обеспечению сквозного процесса ресурсами. Фактически это означает использование элементов матричного управления.
     Представим себе, что удалось формально зарегламентировать и документально зафиксировать порядок выделения ресурсов владельцу сквозного процесса. Далее, по ходу деятельности, возникают исключительно сложные проблемы контроля выделения этих ресурсов руководителями подразделений и оценки их реального использования в сквозном процессе. Необходима организация работ по планированию распределения ресурсов и учету их фактического использования. В условиях, когда деятельность не документирована, когда исполнители не имеют четко прописанных инструкций, организовать подобную работу очень сложно.
     Мы не будем в данной статье подробно разбирать проблемы, связанные с внедрением механизмов матричного управления, а ограничимся их кратким перечислением:
        — проблема распределения ресурсов;
        — проблема планирования и учета расхода ресурсов;
        — проблема оценки эффективности и результативности сквозного процесса;
        — проблема мотивации сотрудников, участвующих в различных сквозных процессах и выполняющих работу в своем функциональном подразделении.
     Если сквозные процессы выделяются в организации не просто для формальных целей, то необходимо заранее разработать механизмы, позволяющие устранить указанные выше проблемы.

    Выводы

     Краткий сравнительный анализ подходов к выделению сквозных бизнес-процессов и бизнес-процессов подразделений показывает, что при внедрении процессного подхода к управлению в организации целесообразно:
     Фаза 1.
a) построить сеть бизнес-процессов, выделяя процессы в рамках функциональных подразделений, назначить владельцев процессов;
b) описать бизнес-процессы подразделений и выполнить их регламентацию (- четко определяются границы процессов, необходимые для выполнения процессов ресурсы, налаживается взаимодействие между подразделениями по принципу «клиент-поставщик»);
c) разработать систему показателей оценки процессов, продуктов процессов и удовлетворенности клиентов;
d) запустить систему управления бизнес-процессами организации, основанную на выполнении цикла PDCA на всех уровням управления.
     Фаза 2.
e) ЕСЛИ ЭТО ЦЕЛЕСООБРАЗНО, выделить сквозные процессы и назначить владельцев сквозных процессов;
f) описать и регламентировать сквозные процессы (используется уже существующие к этому моменту регламенты бизнес-процессов подразделений с четко описанными ресурсами), разработать механизмы выделения ресурсов владельцам сквозных процессов и механизмы управления сквозным процессом;
g) разработать систему контроля использования ресурсов сквозными процессами;
h) разработать систему показателей оценки сквозных процессов, продуктов процессов и удовлетворенности клиентов;
i) запустить цикл PDCA для сквозных процессов.

     Таким образом, предприятиям, внедряющим процессный подход, предлагается сделать акцент на описании и регламентации бизнес-процессов структурных подразделений. После упорядочивания деятельности и успешного запуска механизмов процессного управления (цикл PDCA), гораздо проще и эффективнее можно будет решить задачу выделения и управления сквозными процессами, если они вообще потребуются. У организации появятся реальные возможности перехода к матричному управлению, если это будет необходимо для повышения эффективности бизнеса.

     Примечания

1 — Далее по тексту термины «бизнес-процесс» и «процесс» будут использоваться как синонимы

2 — К сожалению, существуют некоторые руководители, которые определяют процессы своих предприятий на основе чрезмерно формального  выполнения требований стандартов ИСО. Они создают, например, такие процессы, как: «оснащение рабочего места», «внутренний обмен информацией», «лидерство», «планирование качества» и т.п. (см. [8]).

3 — В данной статье мы не рассматриваем подробно вопросы создания системы управления процессами, т.к. об этом подробно говорилось в предыдущих статьях серии (см. [3], [4], [6]).

4 — См. например материалы, представленные на сайтах компаний «Инталев» или «Логика бизнеса».

5 — Некоторые авторы предлагают в качестве владельца процесса назначать «:молодого, творческого, пользующегося уважением в коллективе сотрудника:». При таком подходе, на наш взгляд, реально управление процессом не возможно, т.к. такой владелец процесса не наделен ресурсами и не включен в вертикаль управления.

     В.В.Репин, к.т.н.,
     руководитель отдела консалтинга ,
     менеджер проекта
www.finexpert.ru

     Литература
1. ИСО 9000:2000 Системы менеджмента качества — Основные положения и словарь.
2. ИСО 9001:2000 Системы менеджмента качества- Требования.
3. «Два понимания процессного подхода к управлению предприятием». В.В. Репин, журнал «Методы менеджмента качества», № 4, 2003 г.
4. «Опыт внедрения системы управления бизнес-процессами». В.В. Репин, журнал «Методы менеджмента качества», № 5, 2003 г.
5. «Сегментированное управление бизнес-процессами компании». В.В. Репин, В.Г. Елиферов, сайт www.finexpert.ru
6. «Сквозные» процессы в системе управления: миф или реальность?» В.В. Репин, журнал «Методы менеджмента качества», № 6, 2003 г.
7. Реинжиниринг корпорации: Манифест революции в бизнесе. М.Хамер, Дж.Чампи. СПб.: Изд.СПб ун-та, 1997.

Также на сайте:
Что такое «мониторинг» и «измерение процесса»?
Выбор методов измерения процессов системы менеджмента качества

Эффективная реализация бизнес-процессов — мечта любого предприятия. Для ее достижения разработаны методы и инструментальные средства описания, проектирования, анализа и оценки бизнес-процессов, концепции и правила их реорганизации, а также информационные технологии поддержки. Бизнес-процесс представляет собой набор взаимосвязанных бизнес-процедур (функций или действий, формирующих результат, имеющий ценность для потребителя), в результате которых производится определенная группа продуктов и услуг. Все бизнес-процессы существуют для выполнения функций предприятия и должны соответствовать установленной на нем иерархии целей. Технология Workflow занимает в этом ряду далеко не последнее место — большинство аналитиков рассматривают ее как важнейшую составляющую современных корпоративных информационных систем, наиболее перспективную технологию управления бизнес-процессами. Данная статья отражает опыт авторов, накопленный в процессе разработки и выполнения проектов в области реорганизации бизнес-процессов и внедрения систем класса Workflow. В статье используются термины, определения и концепции, предложенные в работах G.Aussems, J.Champy, T.Davenport, M.Duitshof, M.Hammer, R.Huffmeijer, S.Joosten, E.Mulder и материалах Workflow Management Coalition [1-3]. Особенности конкретной программной реализации систем класса Workflow иллюстрируются примерами работы русскоязычной версии системы Staffware компании Staffware plc.

Международной организацией, координирующей разработку терминологии, стандартов и спецификаций на системы класса Workflow, является Workflow Management Coalition (WfMC). Так, например, одним из ведущих событий прошедшего года в области информационных технологий стала демонстрация на международном форуме Giga Information Group»s Business Process and Workflow совместной работы систем класса Workflow шести различных производителей на основе стандартных интерфейсов. Значение соответствующих стандартов специалисты сравнивают с тем значением, которое оказала в свое время спецификация языка SQL на развитие систем управления базами данных.

Созданная в середине 1993 года WfMC объединяет около 200 различных организаций по всему миру. В их числе компании, специализирующиеся на разработке аппаратных и программных систем, внедрении, консалтинге, а также учебные заведения. По оценкам WfMC, емкость рынка систем класса Workflow составляет сегодня 100 млн. долларов, а такие примеры инсталляций системы Staffware, как комплекс для пяти тыс. пользователей в Министерстве обороны Великобритании или шести тыс. служащих страховой компании CIGNA Healthcare (США), служат убедительной иллюстрацией реалистичности этих оценок. Внедрения систем класса Workflow в России пока не столь масштабны. Тем не менее количество представленных на рынке систем уже исчисляется десятками, а количество проданных лицензий — тысячами.

Буквальный перевод термина «workflow» как «поток работ» является безусловно корректным грамматически, но почти никак не раскрывает его содержание. Более информативно определение продуктов класса Workflow как программных систем, обеспечивающих полную или частичную координацию выполнения производственных операций (заданий, работ, функций), составляющих структурированные бизнес-процессы предприятия.

объект — информационный, материальный или финансовый объект, используемый в бизнес-процессе (например письмо, оборудование, счет);

событие — внешнее (не контролируемое в рамках процесса) действие, произошедшее с объектом (скажем получение письма, поломка оборудования, изменение ставки налога);

операция — элементарное действие, выполняемое в рамках рассматриваемого бизнес-процесса (допустим подготовка письма, замена оборудования, оплата счета);

исполнитель — должностное лицо, ответственное за выполнение одной или нескольких операций бизнес-процесса (к примеру менеджер, сотрудник архива, директор).

Взаимоотношения между базовыми понятиями технологии Workflow отображены на концептуальной информационной модели, представленной на рисунке 1.

Несмотря на то что модель подготовлена в соответствии с требованиями стандарта IDEF1X, ее общая интерпретация и анализ не требуют от специального изучения правил используемой методологии. В рамках этой модели ПРОЦЕСС состоит из ОПЕРАЦИЙ и других ПРОЦЕССОВ. ОПЕРАЦИЯ адресуется ИСПОЛНИТЕЛЯМ, которые, в свою очередь, отвечают за выполнение одной или нескольких ОПЕРАЦИЙ. ОБЪЕКТЫ участвуют в выполнении ОПЕРАЦИИ. СОБЫТИЯ могут влиять на выполнение ОПЕРАЦИЙ, например, изменяя результат операций или последовательность их выполнения. ОПЕРАЦИИ обрабатывают СОБЫТИЯ, являясь реакцией системы на происходящие СОБЫТИЯ. Жизненный цикл ОБЪЕКТА связан с внешними СОБЫТИЯМИ и ОПЕРАЦИЯМИ, выполняемыми в составе ПРОЦЕССА.

Приведенные понятия не исчерпывают множество терминов, определений и особенностей технологии Workflow, тем не менее рассмотренная концептуальная модель и/или ее различные модификации служат основой программной реализации любой системы класса Workflow. При этом каждая система обеспечивает решение трех следующих задач:

  • разработка описания бизнес-процесса;
  • управление выполнением бизнес-процесса;
  • интеграция используемых в процессе приложений.

    Соответственно этим задачам в составе системы можно выделить типовые компоненты (рисунок 2) и проанализировать связи между ними.

    Picture 2

    Рисунок 2.
    Задачи и компоненты системы класса Workflow.

    Инструментальные средства описания процесса предназначены для формирования формального описания процесса в виде упорядоченного множества операций, правил их выполнения, связанных с ними объектов, исполнителей и событий. Полученное описание или спецификация процесса используется для контроля и управления выполнением процесса на основе поступающих в систему данных. В качестве этих данных выступают информация, введенная пользователем, результаты выполнения отдельных операций, данные от прикладных систем, архивов и баз.

    В свою очередь средства управления выполнением процесса предоставляют пользователю и/или прикладной системе информацию, необходимую для каждой операции, а выявленные на этапе выполнения несоответствия служат основанием для пересмотра спецификации процесса.

    Представление бизнес-процесса как процесса Workflow

    Все ли бизнес-процессы могут быть описаны как процессы Workflow? Какие бизнес-процессы целесообразно представлять в виде процессов Workflow?

    Важнейшей особенностью технологии Workflow является поддержка управления процессами, содержащими как автоматизированные — выполняемые средствами информационных систем, так и неавтоматизированные — выполняемые вручную операции. Благодаря этой особенности любой бизнес-процесс предприятия может быть представлен в виде процесса Workflow, если, конечно, этот процесс:

  • выделен;
  • структурирован;
  • выполняется по правилам, которые можно сформулировать;
  • периодически повторяется.

    Первые три ограничения являются ответом на вопрос «какие процессы можно описать», а последнее — «какие целесообразно».

    Многие специалисты в области анализа бизнес-процессов используют для их описания методологию функционального моделирования IDEF0. Следуя сложившимся традициям, мы также применяем эту методологию для иллюстрации перечисленных ограничений.

    Итак, процесс должен быть ВЫДЕЛЕН из всей массы выполняемых на предприятии работ, заданий и действий. Обобщенное представление такого процесса в методологии IDEF0 приводится на рисунке 3 — диаграммы верхнего уровня, определяющей взаимосвязи процесса с исполнителями и объектами, выступающими в качестве входов (исходные данные и материалы), управлений (ограничения на выполнение) и выходов (результаты выполнения). В методологии IDEF0 соответствующие связи называются IDEF-дугами. Количество присутствующих на диаграмме IDEF-дуг и их содержание могут быть любыми, но нельзя представить в виде Workflow процесс с исходными данными, неопределенными по составу, непредсказуемым результатом, неопределенными или неуправляемыми правилами выполнения и отсутствием исполнителей. Строго говоря, соответствующий процесс вряд ли можно считать бизнес-процессом, удовлетворяющим приведенному в начале статьи определению.

    Picture 3

    Рисунок 3.
    Обобщенное представление бизнес-процесса в методологии IDEF0.

    Кроме того, процесс должен иметь внутреннюю СТРУКТУРУ — не быть вырожденным, состоящим из одной единственной операции.

    В методологии функционального моделирования IDEF0 структура бизнес-процесса может быть раскрыта на диаграмме декомпозиции (рисунок 4), которая сохраняет входы, выходы, управления и исполнителей, указанных на родительской диаграмме, а также содержит составляющие процесс операции, подпроцессы и связи между ними. Функциональная модель бизнес-процесса представляет собой набор иерархических диаграмм, аналогичных представленной на рисунке 4, с метками для каждой IDEF-дуги, раскрывающими ее содержание.

    Picture 4

    Рисунок 4.
    Пример декомпозиции бизнес-процесса в методологии IDEF0.

    Уровень вложенности подпроцессов не ограничен, что позволяет описывать функциональную модель процесса любой сложности. Средства описания процесса Workflow реализуют соответствующую возможность, как правило, путем запуска дочерних процессов в указанных операциях родительского процесса и согласования получаемых результатов с последующими операциями.

    Формирование функциональной модели бизнес-процессов является первым шагом подготовки к внедрению системы класса Workflow. Хотелось бы обратить внимание на следующие немаловажные обстоятельства.

  • Внедрение системы класса Workflow базируется не на маршрутизации прохождения документов и не на автоматизации группы операций или вида действий, а на описании бизнес-процесса, ради эффективного выполнения которого, собственно, и осуществляется маршрутизация документов и/или автоматизация операций.
  • Технология Workflow не накладывает каких-либо специальных ограничений на уровень детализации бизнес-процесса и/или степень автоматизации выполняемых операции.

    В качестве элементарной операции можно использовать как рутинное, формальное действие, например «зарегистрировать учетные данные клиента», так и творческую, нетривиальную задачу, скажем «разработать технологию подъема Титаника». Следует лишь определить IDEF-дуги, связывающие эту операцию с другими в рамках рассматриваемого процесса.

    При всей важности функционального моделирования тем не менее представленных в функциональной модели данных еще недостаточно для полного определения процесса. Третьим требованием представления бизнес-процесса в виде процесса Workflow является НАЛИЧИЕ ПРАВИЛ выполнения процесса, которые можно сформулировать и формально описать. В первую очередь соответствующие правила касаются последовательности выполнения операций, условий и предусмотренной реакции на внешние события.

    Для того чтобы пояснить принципы формирования правил, рассмотрим категории операций, выполняемых в рамках бизнес-процесса (рисунок 5).

    Picture 5

    Рисунок 5.
    Категории операций, выполняемых в рамках бизнес-процесса, и примеры.

    Будем рассматривать операции, выполняемые группой исполнителей. В качестве направлений систематизации выберем согласованность времени выполнения (синхронно, асинхронно) и области действия (локальная или распределенная). Для выполнения синхронных локальных операций требуется наличие всех исполнителей в одно время и в одном месте. Синхронные распределенные операции выполняются в одно и то же время исполнителями, которые могут находиться в разных местах. Асинхронные локальные операции выполняются членами группы в одном, определенном месте, но в различное время. И, наконец, асинхронные распределенные операции выполняются членами группы исполнителей в различных местах и в различное время.

    Объектом автоматизации технологии Groupware являются три первых категории операций. В рамках технологии Workflow рассматриваются операции, относящиеся к последней категории, — распределенные и асинхронные. Причем эти операции могут выполняться последовательно или параллельно, иметь сколь угодно сложную логику, согласовываться по времени, данным и исполнителям.

    Четвертым и последним требованием представления бизнес-процесса в виде процесса класса Workflow является ПЕРИОДИЧНОСТЬ ВЫПОЛНЕНИЯ. В отличие от предыдущих требований, это требование носит чисто экономический характер.

    Инструментальные средства описания процесса

    С точки зрения системы, каждая операция, входящая в состав процесса, содержит задание, выполнение которого предполагает ввод и/или обработку информации. Типовыми параметрами описания операции являются следующие:

  • адресат — пользователь или группа пользователей, получающих задание, при этом указываются права на пересылку задания другому пользователю и права на копирование данных, относящихся к заданию;
  • экранная форма, содержащая представление данных и функций, используемых пользователем при выполнении задания;
  • предельный срок выполнения задания, определяющий, до какого времени соответствующая операция должна быть выполнена;
  • действия системы при инициализации и завершении операции.

    Последовательность выполнения операций и условия их перехода от одной к другой составляют алгоритм выполнения процесса. Помимо уже рассмотренных операций в описании алгоритма, как правило, используются:

  • логические условия;
  • внешние по отношению к процессу события;
  • средства создания параллельных ветвей;
  • точки встречи, позволяющие согласовать результаты параллельно выполняемых операций;
  • автоматические операции — операции, выполняющиеся без участия пользователя и запускающие на сервере внешнюю процедуру обработки циркулирующих в процессе данных;
  • сценарии — специальные экранные формы, содержащие вызов функций, операторов системы и внешних программ, используемых пользователем при выполнении различных операций.

    Использование инструментальных средств описания процессов в большинстве современных систем класса Workflow не требует от разработчика каких-либо знаний в области программирования или систем управления базами данных. Например, в системе Staffware средством такого класса является графический построитель процедур для Windows, работа которого основана на технологии пиктограмм и режиме drag-and-drop.

    При выполнении процесса Workflow информация передается от пользователя к пользователю в виде некоторого упорядоченного множества данных. Каждая операция использует подмножество этих данных, состав которого, а также способ представления данных задаются соответствующей экранной формой. Создание форм является прерогативой разработчика процессов, а инструментальные средства для разработки форм являются важным компонентом системы Workflow. Главным требованием к экранным формам, циркулирующим в системе, является их «интеллектуальность» — возможность динамически изменять состав, содержание и формат представления данных.

    Большинство систем поддерживают самые разнообразные типы данных. Очень важными являются данные типа «файл», благодаря которым обеспечивается возможность ассоциировать с формой файлы, находящиеся вне системы. Разработчик указывает операции, на которых эти файлы должны порождаться, и регламентирует возможность внесения в них изменений.

    Значения данных представляются в экранной форме в виде полей. При этом различаются:

    демонстрационные поля — поля, содержащие значения, для которых не допускается редактирование;

    обязательные поля — поля, которые необходимо заполнить в процессе выполнения задания;

    необязательные поля — поля, значения которых могут быть введены пользователем, однако это не является необходимым условием выполнения задания;

    вычисляемые поля — поля, значения которых вычисляются в соответствии с заданными правилами;

    невидимые поля — вычисляемые, но неотображаемые на экране.

    Построение форм представления данных является составной частью описания операций, составляющих процесс Workflow, и включает:

  • задание и форматирование текста, образующего форму;
  • определение требуемого подмножества данных;
  • указание способа их представления в форме;
  • описание условий и обстоятельств, определяющих содержание формы.

    Кроме того, для каждого поля могут быть заданы:

  • справка-пояснение того, как это поле заполнить; справочная информация будет выдаваться на экран по требованию пользователя;
  • диапазон или список допустимых значений;
  • одна или несколько таблиц, определяющих взаимосвязи между значениями полей формы.

    Использование таблиц позволяет организовать согласованную работу с логически связанными полями данных, например такими, как название компании и ее почтовый адрес.

    В большинстве современных систем класса Workflow присутствуют высокоуровневые инструментальные средства создания и редактирования экранных форм. Например, в Staffware таким средством является графический построитель форм для среды Windows.

    Управление выполнением процесса

    Любой конкретный случай выполнения процесса называется экземпляром или вариантом. Выполнение любого экземпляра состоит в рассылке пользователям заданий в виде экранных форм и управлении процессом их заполнения в соответствии с предусмотренным алгоритмом. При этом система класса Workflow обеспечивает:

  • одновременное выполнение множества экземпляров каждого процесса;
  • передачу заданий между операциями процесса посредством системы электронной почты;
  • обмен произвольными сообщениями между пользователями;
  • доступ к функциям системы и внешним программам, предусмотренным для пользователя разработчиком процесса;
  • взаимодействие путем обмена данными с внешними программами на сервере и клиенте.

    Работа пользователя с любой формой состоит из следующих действий:

  • просмотр содержимого;
  • заполнение и/или редактирование полей;
  • печать формы;
  • выпуск формы для последующей обработки.

    Часто при заполнении экранных форм поддерживается технология электронной подписи.

    В процессе эксплуатации система Workflow накапливает задания, ожидающие обработки, и формирует очереди заданий различных типов как для каждого пользователя, так и для группы. Автоматически производится периодическое обновление очередей и уведомление пользователя о наличии в очереди новых, еще непросмотренных заданий, заданий с высоким приоритетом или заданий с установленным предельным сроком выполнения. Например, в системе Staffware для работы с очередью заданий имеется специальное окно.

    Набор операций для работы с очередью заданий содержит следующие операции:

  • выбор задания;
  • переход к заполнению экранной формы выбранного задания;
  • выпуск выбранного задания — информирование системы об его выполнении;
  • пересылка выбранного задания другому пользователю в случае невозможности его выполнения;
  • установка критериев сортировки заданий в очереди;
  • ограничение списка отображаемых заданий посредством критерия-фильтра;
  • управление периодом обновления очереди.

    После выпуска или пересылки задания оно автоматически удаляется из очереди.

    В управлении и выполнении процесса Workflow участвуют следующие классы пользователей:

    администратор системы — поддержка и сохранение целостности всех данных, не относящихся к процессам, например данных о пользователях;

    разработчик процесса — разработка, тестирование и поддержка конкретного процесса;

    владелец процесса — редактирование конкретного процесса;

    менеджер — контроль исполнения экземпляров процесса посредством регистрационных отчетов и сервисных программ;

    пользователь — доступ к системе через очередь заданий, функция запуска экземпляра конкретного процесса и справочная подсистема.

    Каждый пользователь имеет уникальный код, пароль и относится к некоторой группе пользователей. Средства управления доступом системы Workflow ограничивают доступ к операциям, функции запуска экземпляров процесса и возможностям администрирования для определенных пользователей или групп пользователей. Кроме того, большинство систем предоставляют возможность управления доступом на уровне ролей, в соответствии с которой права доступа могут назначаться не физическим лицам или подразделениям, а должностям (ролям).

    Для контроля и управления текущим состоянием выполнения экземпляров процесса в системах Workflow предусмотрены следующие функции:

  • регистрационные журналы;
  • отчеты о состоянии;
  • пересмотр данных;
  • административные отчеты.

    Регистрационный журнал представляет собой внутренний отчет системы, в котором для каждого экземпляра процесса фиксируются дата и время каждой транзакции, выполненное действие и исполнитель. С помощью регистрационного журнала в любой момент времени можно получить информацию о том, что происходило и происходит при выполнении конкретного экземпляра процесса.

    Отчет о состоянии — это внутренний отчет системы, в котором отражается текущее состояние каждой операции каждого процесса. Различается четыре типа состояний: выпущена, не выпущена, отозвана или не отправлена. Кроме того, для любой операции можно получить данные о текущих значениях полей. Функция пересмотра данных отличается от отчета о состоянии лишь тем, что позволяет модифицировать значения полей и таким образом управлять выполнением экземпляра процесса.

    Административные отчеты используются для сбора и обобщения информации, относящейся к нескольким (всем, текущим или завершенным) экземплярам данного процесса. Типичными примерами административных отчетов являются отчеты об объеме продаж в регионе, о суммарном объеме всех принятых заказов или о количестве просроченных договоров. Структура и алгоритм административных отчетов определяются разработчиком процесса.

    Особенности программной реализации

    Естественно, что каждая конкретная программная реализация системы класса Workflow имеет множество своих особенностей. Приведем, например, краткое описание некоторых особенностей программной реализации для системы Staffware.

    Как и большинство систем класса Workflow система Staffware имеет архитектуру клиент-сервер. Сервер Staffware работает в среде Unix или NT, а для рабочего места клиента может использоваться алфавитно-цифровой терминал Unix, ПК в среде Windows или Macintosh. В качестве основы для управления данными система Staffware предоставляет несколько вариантов: собственную систему управления, базирующуюся на файловой системе сервера, СУБД Oracle или Informix. Для предприятий, имеющих сложную и территориально-распределенную структуру, важной является поддержка системой Staffware многосерверной конфигурации, в которой часть серверов может работать под Unix, другая — под NT, третья — под любой из этих операционных систем плюс СУБД Oracle, а четвертая — аналогично предыдущей, но с СУБД Informix.

    Система Staffware является открытой — специальные средства обеспечивают запуск внешних программ на сервере и клиенте, двусторонний обмен данными между Staffware и процессом на сервере, а также динамический обмен данных (Dynamic Data Exchange — DDE) с приложениями, работающими под Windows. Кроме этого, имеются библиотеки функций уровня прикладного программирования (API) под Unix и Windows, позволяющие разработчикам прикладных программ получить доступ к системным функциям Staffware.

    Имеется также специальная версия, ориентированная на работу в сети Internet, — Staffware W4 (Workflow on Word Wide Web), обеспечивающая Web-клиенту системы доступ через глобальную сеть к формам, очереди заданий, административным отчетам и регистрационным журналам. При этом в качестве клиентского программного обеспечения может использоваться любой стандартный Web-браузер.

    Среди множества дополнительных функций отметим следующие:

  • выход на любую внешнюю систему электронной почты, в том числе по протоколам X400 и SMTP;
  • многопользовательский режим отладки и тестирования новых процессов;
  • возможность копирования и восстановления описания процесса из копий;
  • набор функций сохранения и восстановления системы;
  • управление внутренним набором символов Staffware;
  • управление рабочим календарем;
  • доступ к системным переменным и функциям;
  • управление режимом работы с окнами.

    Место технологии Workflow в организации бизнеса

    Для определения места технологии Workflow в организации бизнеса воспользуемся подходом, предложенным С. Джостеном (S. Joosten) и его коллегами [2], и рассмотрим динамику изменения основных компонентов бизнес-системы (рисунок 8).

    Picture 8

    Рисунок 8.
    Динамика изменения основных компонентов бизнес-системы.

    Наиболее устойчивым компонентом является миссия предприятия, определяющая назначение компании, ее значимость для общества и направление деятельности. С точки зрения организации бизнеса, изменение миссии эквивалентно построению новой компании.

    Практически столь же устойчивой является иерархия целей предприятия и стратегия его развития. Изменения в стратегии являются, как правило, следствием таких внешних событий, как технологическая революция, радикальное изменение условий рынка или законодательства.

    Критические факторы успеха и состав тактических задач по реализации сформированных планов периодически пересматриваются на основе анализа тенденций развития рынка и статистики результатов деятельности.

    Определение результатов деятельности и подсчет значений показателей эффективности проводится столь часто, сколь это возможно для конкретного сектора рынка, групп изделий, услуг, клиентов, поставщиков и т. д. Однако и в этом случае достоверные данные являются результатом накопленной статистики, хотя и за менее продолжительный период.

    Все последующие компоненты входят в состав корпоративной информационной системы, в задачу которой входит информационная поддержка выполнения бизнес-процессов и принятия управленческих решений. При этом динамику развития этой системы в наибольшей степени определяют собственно бизнес-процессы.

    С точки зрения организации бизнес-системы основной задачей технологии Workflow является отделение правил выполнения бизнес-процессов от прикладных систем и систем управления базами данных, что обеспечивает принципиально большую гибкость и адаптируемость информационной системы. Иными словами, технология Workflow предоставляет возможность оперативной модификации правил выполнения бизнес-процессов без перестройки прикладного программного обеспечения и/или изменения структуры корпоративной базы данных.

    Другим важным направлением использования технологии Workflow служит интеграция различных приложений и данных вокруг бизнес-процесса. В этом отношении Workflow можно рассматривать как определенный шаг в развитии архитектуры открытых систем. Стандарты, разработанные WfMC, подтверждают эффективность и результативность усилий, нацеленных на развитие этого направления.

    Стратегия внедрения и использования

    Внедрение системы класса Workflow в практику работы предприятия всегда представляет собой проект, реализация которого не может быть возложена лишь на отдел информационных технологий. Более того, объем работ этого отдела в рамках соответствующего проекта редко превышает 25%.

    Какова иерархия целей такого проекта? Как эффективно организовать работы по сопровождению и развитию системы?

    Эти вопросы стали предметом специального исследования, названного WA-12 [2] и, выполненного рядом компаний, в числе которых Data General, Deloitte&Touche, Staffware и др. По данным исследования WA-12, типовыми целями проекта внедрения системы класса Workflow являются:

  • сбор, организация хранения и доступа к документам и данным, используемым при выполнении бизнес-процессов. При этом если системы типа «электронный архив» уделяют основное внимание вопросам регистрации, учета, индексации, хранения и поиска документов, то системы класса Workflow устанавливают связь между документами и операциями бизнес-процесса, управляют правилами прохождения документов, доставкой «тому, кому нужно, и тогда, когда нужно»;
  • управление выполнением бизнес-процессов. Хотя в исследовании WA-12 эта цель заняла второе место, большинство исследователей рассматривают ее как важнейшую. Внедрение технологии Workflow позволяет организовать конвейер обработки информационных, финансовых и материальных потоков на основе согласованного выполнения операций, работ и заданий, не ограничивая при этом творческую и деловую активность исполнителей, ответственных за конкретный участок работ;
  • получение достоверной информации о деятельности компании, анализ которой служит основанием для принятия управленческих решений и своевременной корректировки стратегии развитии.
  • интеграция отдельных «островков автоматизации», существующих в различных подразделениях предприятия, в единую информационную систему поддержки выполнения бизнес-процессов. Такая интеграция позволяет избежать дублирования и несогласованности данных, используемых в различных подразделениях.

    Необходимо отметить, что проект анализа деятельности и реорганизации бизнес-процессов предприятия и проект внедрения системы класса Workflow представляют собой далеко не одно и то же.

    Первый из них предполагает детальный и всесторонний анализ четырех верхних уровней пирамиды, представленной на рисунке 8. Второй обеспечивает решение задачи следующего, пятого уровня. Тем не менее оба проекта рассматривают бизнес-процессы предприятия и предполагают их выявление и описание.

    Предположим, однако, что соответствующие работы выполнены, система инсталлирована, бизнес-процессы описаны, организационные вопросы решены, проведено тестирование и осуществлен переход к промышленной эксплуатации системы. Начиная с этого момента главной задачей является поддержание системы в актуальном состоянии, отражающем особенности текущего состояния рынка, стратегию и тактику деятельности предприятия.

    Технология выполнения соответствующих работ разработана весьма подробно. Ее квинтэссенцией является цикл управления эксплуатацией и развитием системы класса Workflow, представленный на рисунке 9.

    Picture 9

    Рисунок 9.
    Цикл управления эксплуатацией и развитием системы класса Workflow.

    Выполнение множества процессов Workflow (блок «Выполнение») сопровождается сбором статистики, представленной в отчетах различных типов. Эти отчеты служат основой для выявления типовых маршрутов выполнения процессов, распределения затрат, причин нарушения сроков выполнения отдельных операций (блок «Разбор»). Полученные данные сравниваются с требованиями, предъявляемыми к системе, проводится оценка эффективности эксплуатации (блоки «Сравнение» и «Требования»). На основании результатов сравнения проводится перенастройка описанных процессов, уточнение интерфейсов с прикладными программами и базами данных, уточнение состава отчетов (блок «Настройка»). Отредактированные версии процессов поступают в блок «Выполнение», а соответствующие им изменения в правилах организации бизнеса (блок «Изменения») влияют на требования, предъявляемые к системе (блок «Требования»).

    Вместо заключения

    Основное количество внедрений систем класса Workflow в России сосредоточено сегодня только вокруг задачи управления документооборотом. Нисколько не отрицая важность и актуальность этой задачи, авторы обращают внимание на то, что возможности технологии Workflow существенно шире: она позволяет сделать бизнес более эффективным и, соответственно, эффект от внедрения может быть существенно более значимым.

  • —>

    Содержание

    1. Определение бизнес-процесса

    2. Основные элементы понятия «бизнес-процесс»:

    Владелец процесса

    Управление процессом

    Технология процесса

    Границы процесса

    Потребитель

    Поставщик

    Выход

    Вход

    Показатели управления процессом

    Требования

    Ресурсы процесса

    3. Виды процессов

    4. Уровни процессов

    1. Определение бизнес-процесса

    Бизнес-процесс (процесс) — устойчивая, целенаправленная, управляемая  совокупность  взаимосвязанных  видов деятельности, которая по определенной технологии  преобразует входы в выходы, представляющие ценность для клиента.

    Систему определений понятия «бизнес-процесс (процесс)», данных в стандарте ИСО 9000-2015, смотрите на странице Термины и определения процессного подхода к управлению. 

    Универсальная схема БП

    Рис. 1. Универсальная структурная схема бизнес-процесса 

    Каждый процесс встроен в определенную систему процессов, которые выполняются  как внутри компании, так и во внешних организациях. Требование к процессу определяет вышестоящее по отношению к рассматриваемому процессу  руководство («вышестоящий орган управления» на рис.1). Управляющая информация (приказы, планы, нормативные документы  и т.п.) поступает на вход процесса.  При выполнении деятельности и по завершении отчетных периодов вышестоящему руководству поступает отчетная информация.

    Результатом выполнения процесса  является продукция  (услуги). Результат также называется выходом. Потребители (внешние, внутренние) получают их  и используют для преобразования в другую продукцию (услуги) в рамках своих процессов.

    Попытки копирования «чужих» процессов или  использование типовых моделей  бизнес-процессов  — пустая затея. Система управления процессами каждой организации  является ее уникальным ноу-хау, действует в конкретной обстановке и меняется с изменением обстановки. Копирование и тиражирование системы управления предприятием имеет смысл только тогда, когда  организация создает сеть однотипных, тиражируемых подразделений или бизнес-единиц.

    п

    2. Основные элементы понятия «бизнес-процесс»

    Бизнес-процесс — это комплексное понятие, которое включает в себя следующие элементы:

    — владелец процесса;

    — управление процессом;

    — технология процесса;

    — границы процесса;

    — выход;

    — вход;

    — система показателей процесса;

    — ресурсы процесса;

    — потребитель;

    — поставщик. 

    Владелец бизнес-процесса

    — должностное лицо, имеющее в своем распоряжении ресурсы процесса, наделенное четкими обязанностями и полномочиями на управление процессом  с целью достижения намеченного результата;

    3D Style file format icon - ISO

    Ответственность и полномочия, связанные с процессами

    ИСО 9004-2010, п.7.3

    По каждому процессу организации следует назначать руководителя процесса (часто именуемого «владельцем процесса») с четкими обязанностями и полномочиями для создания, поддержания в работоспособном состоянии, управления и совершенствования процесса и его взаимодействия с другими процессами. Руководителем процесса может быть лицо или группа лиц в зависимости от характера процесса и культуры организации.

    Управление бизнес-процессом  (менеджмент бизнес-процесса)

    — деятельность владельца процесса по переводу процесса из текущего состояния в целевое.

    3D Style file format icon - ISO

    Менеджмент процессов.  Общие положения

    ИСО 9000-2015, п. 3.3.3

    Менеджмент — скоординированная деятельность по руководству и управлению организацией. Менеджмент может включать установление политик, целей  и процессов для достижения этих целей.

    ИСО 9004-2010, п. 7.1

    Менеджмент процессов должен иметь системный характер за счет создания и четкого понимания сети процессов, их последовательности и взаимодействия. Согласованное функционирование системы часто называют «системным подходом к менеджменту». Сеть процессов может быть описана схемой процессов и их взаимодействия.

    Технология бизнес-процесса
    – совокупность методов для достижения желаемого результата (преобразование входов в выходы).

    Границы бизнес-процесса

    — это события, с которых начинается (событие начала процесса) и заканчивается  процесс (событие  завершения процесса).

    Событие –  это наступление

    1) момента времени (например, «(наступило) 20-е число отчетного месяца»);
    2) ситуации (например, «получен договор, подписанный контрагентом» — начало процесса, или «заявка  покупателя передана в производство» — окончание процесса, или «поступила заявка покупателя» — начало процесса).

    Потребитель бизнес-процесса

    3D Style file format icon - ISO

    Потребитель (customer)

    ИСО 9000-2015, п.3.2.4

    Лицо, подразделение, организация, которые могут получать или получают продукцию   или услугу, предназначенные или требуемые этим лицом, подразделением, организацией (Пример — Клиент, заказчик, конечный пользователь, розничный продавец, получатель продукции или услуг как результатов внутреннего процесса, бенефициар и покупатель).

    ПримечаниеПотребитель может быть внутренним или  внешним по отношению к организации.

    Поставщик бизнес-процесса

    3D Style file format icon - ISO

    Поставщик (supplier), провайдер (provider)  

    ИСО 9000-2015, п.3.2.5

    Организация, предоставляющая или услугу (Пример — Производитель, дистрибьютор, предприятие розничной торговли или продавец продукции или услуги).

    ПримечаниеПоставщик может быть внутренним или внешним по отношению к организации. 

    Выход 

    — это продукт (материальный или информационный объект) или услуга, являющиеся результатом выполнения процесса и потребляемые внешними по отношению к процессу потребителями.

    3D Style file format icon - ISO

    Выход (output)

    ИСО 9001-2015, п.3.7.5 

    —  Результат процесса.

    Вход

    —  это продукт (материальный или информационный объект), который в ходе выполнения процесса преобразуется в выход. Поставляется другими процессами предприятия (внутренними поставщиками), или внешним поставщиком.

    Показатели управления процессом

    — это характеристики процесса, количественные или качественные, как объекта управления.

    Для каждого процесса должна быть разработана совокупность показателей (система показателей), по которым будет проводиться мониторинг и анализ 

    • процесса,  
    • результата процесса (продукция / услуга),
    • ресурсов,
    • удовлетворенности потребителя,

    а также определена процедура сбора и представления значений по этим показателям для обработки и анализа.

    3D Style file format icon - ISO

    Измерение. Общие положения

    ИСО 9004-2010, п.8.3.1

    Высшему руководству следует оценивать ход работ по достижению запланированных результатов на всех уровнях и во всех соответствующих процессах и функциональных подразделениях организации в соответствии с ее миссией, видением, политикой, стратегией и целями.

    Для мониторинга хода работ, для сбора и представления информации, необходимой для оценки эффективности деятельности и результативного принятия решений, должен использоваться процесс измерения и анализа. Выбор соответствующих ключевых показателей деятельности и методики мониторинга имеет решающее значение для успеха процесса измерения и анализа.

    3D Style file format icon - ISO

    Ключевые показатели деятельности

    ИСО 9004-2010, п.8.3.1

    Факторы, управляемые организацией и имеющие решающее значение для достижения устойчивого успеха организации, должны подвергаться измерению основных параметров и должны быть определены как ключевые показатели деятельности. Эти показатели должны поддаваться количественному измерению и должны давать возможность организации устанавливать измеримые цели, идентифицировать, вести мониторинг и прогнозировать тенденции и осуществлять корректирующие, предупреждающие действия и действия по улучшению в случае необходимости.

    Высшему руководству следует выбирать ключевые показатели деятельности, как основу для принятия стратегических и тактических решений. В свою очередь, эти показатели должны доводиться до сведения соответствующих подразделений и уровней в рамках организации для достижения целей высшего уровня.

    При выборе ключевых показателей деятельности организация должна позаботиться о том, чтобы эти показатели давали измеримую, точную и достоверную информацию.

    Требования

    3D Style file format icon - ISO

    Требование (requirement)

    ИСО 9000-2015, п.3.6.4

    Потребность или ожидание, которое установлено, обычно предполагается или является обязательным.

    Примечания

    1. Установленным является такое требование, которое определено, например, в документированной информации.

    2. Требование может быть сформировано разными заинтересованными сторонами или самой организацией.

    Для фиксирования требований к входам / выходам / ресурсам, пересекающим границы процесса, формируется документация, например спецификации на входы, выходы, ресурсы процесса.

    Ресурсы процесса

    — это информация и материальные средства, которые владелец процесса распределяет в ходе планирования работ по процессу и учитывает при расчете эффективности процесса (отношение стоимости затраченных ресурсов к достигнутому результату. Ресурсы не преобразуются в ходе процесса.

    В МС ИСО 9001 в качестве ресурсов рассматриваются:

    • персонал;
    • инфраструктура (здания и связанные с ними инженерные сети и системы; оборудование, включая технические и программные средства; транспортные ресурсы; информационные и коммуникационные технологии);
    • среда для функционирования процессов;
    • ресурсы для мониторинга и измерений;
    • организационные знания.

    3. Виды процессов

    Обычно все процессы организации классифицируются с точки зрения  отношения к основному результату деятельности организации. Основные процессы составляют цепочку жизненного цикла продукции. В организации может существовать несколько основных процессов, которые  в этом случае будут ориентированы на различных потребителей, различную продукцию, различные рынки.

    Вспомогательные процессы более универсальны в своей сущности. Практически во всех организациях существуют такие вспомогательные  процессы, как поиск, прием и обучение персонала; поставки; бухгалтерский учет и т.д. Один вспомогательный процесс может обслуживать несколько основных БП. Вспомогательные процессы, как правило, поставляют ресурсы для основных процессов.

    К вспомогательным относятся обычно следующие процессы:

    — подготовка кадров;

    — сервисное обслуживание оборудования;

    — обеспечение связью и IT;

    — административно-хозяйственное обеспечение;

    — обеспечение безопасности;

    — др.

    Для достижения целей всей организации, и целей каждого отдельного процесса, встроенного в систему процессов, исключительно важны процессы управления. Процесс управления организации в целом — процесс более высокого уровня. В зависимости от размеров организации и ее сложности в процессе управления оргазацией могут быть выделены подпроцессы: стратегическое управление, управление проектами, административное управление.

    Деятельность по управлению являются также неотъемлемым элементом каждого бизнес-процесса.  Исключение составляют только процессы операционного уровня, в которых акцент при их описании и регламентации смещается на технологию исполнения (поток выполняемых операций).

    Итак, обобщаем информацию по видам процессов:

    Основные процессы

    — через них проходит основная продукция (услуга);

    — добавляет ценность продукции (услуге);

    — результат получает внешний потребитель.

    Вспомогательные процессы

    — не касаются напрямую основной продукции (услуги);

    — добавляют стоимость продукции (услуге);

    — результат получает основной процесс.

    Процессы управления

    — задают цели и критерии (показатели);

    — обеспечивают достижение целей (путем исполнения основных функций управления: планирование, организация, координация, контроль, анализ, мотивация);

    — результат — деятельность всей организации, если рассматриваем управление в масштабах организации, и деятельность отдельных процессов в рамках системы процессов, если рассматриваем управление отдельного процесса соответствующего уровня.

    Обратите внимание! Разделение всех процессов по данным видам имеет смысл только в ряде случае. Например, когда надо выделить процессы,  участвующие в производстве продукции, и провести их анализ. При построении системы процессов важно не формальное отношение процесса к тому или иному виду, а их реальный вклад в достижение целей организации и уровень управляемости (способность достигать поставленные цели). 

    п

    4. Уровни процессов

    В рамках проведения структурного анализа системы бизнес-процессов организации  применяется принцип декомпозиции.  В процессе декомпозиции блок, отображающий организацию как единое целое, подвергается детализации на другой диаграмме.    Происходит постепенное разбиение сложного процесса верхнего уровня на составляющие его элементы (подпроцессы нижележащего уровня).

    Структурная декомпозиция в методологии SADT

    Рис. 2. Уровни бизнес-процессов 

    Понравилась статья? Поделить с друзьями:
  • Машина проехала от одного населенного пункта до другого столько километров сколько минут она ехала
  • Межотраслевых укрупненных нормативов времени на работы по документационному обеспечению управления
  • Межрайонная инспекция федеральной налоговой службы 2 по ленинградской области реквизиты для оплаты
  • Межрайонная инспекция федеральной налоговой службы 31 по свердловской области реквизиты для оплаты
  • Межрайонный осп по взысканию административных штрафов уфссп россии по московской области реквизиты