Интернет-курс

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

Содержание темы:

1. Возникновение реинжиниринга бизнес-процессов.

2. Общая схема бизнес-процесса как объекта управления.

3. Составляющие части процесса.

4. Различия между процессным и функциональным управлением.

5. Резюме.

Вопрос 1. Возникновение реинжиниринга бизнес-процессов.

Основоположниками реинжиниринга бизнес-процессов считаются Майкл Хаммер и Джеймс Чампи, которые в 1993 г. выпустили книгу под провокационным названием «Реинжиниринг корпорации: Манифест революции в бизнесе».

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

1. Отказаться от «вертикальных» структур управления и переориентировать бизнес на «горизонтальные» межфункциональные процессы.

2. Вместо того, чтобы задаваться вопросом «Каким образом сделать нашу работу быстрее (лучше, дешевле)?», задать себе другой вопрос: «А почему мы вообще делаем эту работу?».

3. В сегодняшних условиях наибольшее влияние на успех или провал бизнес оказывают три «К»: клиенты, конкуренция и коренные изменения.

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

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

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

М. Хаммер и Дж. Чампи «Реинжиниринг корпорации: манифест революции в бизнесе».

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

МС ИСО 9000:2000 Системы менеджмента качества. Основные положения и словарь.

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

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

Вопрос 2. Общая схема бизнес-процесса как объекта управления.

Рис. 1. Общая схема бизнес-процесса

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

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

Вопрос 3. Составляющие части процесса.

Для выполнения любого вида деятельности, как правило, необходимы следующие составляющие:

1. Планы - человек планирует даже свой поход в булочную.

2. Технология - необходимо выбрать подходящую технологию для доставки хлеба к столу, пешком, на велосипеде, трамвае или на такси. Затраты денег и времени в каждом случае будут разными.

3. Персонал - необходимо выбрать члена семьи, который выполнит покупку хлеба оптимальным образом.

4. Оборудование - выбор оборудования (велосипед, трамвай или такси) часто взаимосвязан с выбором технологией.

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

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

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

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

9. Вспомогательные материалы -

10. Производственная среда -

11. Теплоэнергоносители -

12. Программное обеспечение (hard&soft) -

13. Информация -

Не будем дальше расшифровывать составные части процесса, для того чтобы не довести ситуацию до абсурдной.

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

Рис. 2 Составные части процесса

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

Вопрос 4. Различия между процессным и функциональным управлением.

Подавляющее большинство организаций в современном мире устроено по функционально-иерархическому принципу, подразумевающему наличие нескольких уровней (3-12) управления – от Генерального директора (Президента) до простого рабочего. Звенья иерархической системы (подразделения организации) часто сгруппированы по функциональному признаку, то есть по видам деятельность внутри организации, например: Управление сбыта, Финансовый отдел, Бухгалтерия и т.д. Внутри каждого такого звена существует функциональная иерархия от начальника верхнего уровня – к простому исполнителю. Очевидно, что внутри звеньев функциональной иерархии существуют потоки информации, направленные сверху вниз и снизу вверх. Примерами таких потоков могут служить:

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

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

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

Рис. 3. Горизонтальные процессы и вертикальные потоки информации

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

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

На Рис. 3. показаны горизонтальные процессы, рассматриваемые, как правило, в виде потоков работ, выполняемых в функциональных подразделениях. Выходами этих процессов пользуются клиенты (потребители) организации. Именно эти процессы чаще всего называют бизнес-процессами организации. Однако, реальная картина деятельности такова, что не существует горизонтальных процессов, пересекающихся с вертикальными потоками информации. Такое представление является абстрактным, оторванным от жизни, бесполезным на практике. Это факт наглядно отражен на следующем рисунке 4.

Рис. 4. Процессы в иерархической функциональной структуре

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

Рисунок 4. отражает еще одно существенное заблуждение по отношению к процессному подходу, а именно представление процессного подхода как набора идеально прямых, горизонтальных процессов организации (на рисунке 4. это выражает подпись «так должен проходить бизнес-процесс…»). Такое состояние возможно только для простейших «плоских» организационных структур, да и, то только в теории. В реальной же организации, например на промышленном предприятии, процесс плоским быть не может.

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

Рис. 5. Измерение длительности работы

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

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

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

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

· происходит узкая специализация отдельных сотрудников и подразделений (проблемы на стыках);

· слабое делегирование полномочий и ответственности, усложнение системы согласований (бюрократизм);

· снижение эффективности ориентации деятельности подразделений на конечный результат.

Для любой функциональной иерархии справедлив принцип Питера, согласно которому каждый сотрудник достигает уровня свой некомпетентности по мере продвижения вверх по функциональной иерархии. Суть этого принципа состоит в следующем. Человек, являющийся хорошим рабочим, может не стать хорошим мастером и, тем более, начальником цеха. При выдвижении на вышестоящую должность человек может не соответствовать занимаемой должности из-за узости своего кругозора, своих способностей, опыта и т.д. Но работу нужно выполнять. Для этого назначенный на новую должность сотрудник берет себе компетентных замов. Среди этих замов так же могут оказаться некомпетентные сотрудники. Таким образом, функциональная иерархия начинает расти, при этом эффективность и результативность работы постепенно снижается. В классической функциональной иерархии руководитель стремится увеличить численность своих подчиненных, свое влияние в организации, размера бюджета функционального подразделения. Все это ведет к увеличению непроизводительных расходов организации, снижению качества поставляемых товаров и услуг. Итогом такого развития событий является прекращение деятельности организации: банкротство, реорганизация, поглощение конкурентами и т.п. Среднее «время жизни» организаций, как и людей, не превышает 60-80 лет. На наш взгляд, внедрение процессного подхода к управлению существенно снижает риск неконтролируемого роста бюрократической машины и затрат на ее поддержание.

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

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

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

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

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

· реальная деятельность представляет собой процессы;

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

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

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

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

Рис. 6. Пример описания потока документов в рамках процесса

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

· управление бизнес-процессом;

· потоки работ;

· потоки информации (документов);

· потоки материальных ресурсов.

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

Резюме.

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

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

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

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

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

· происходит узкая специализация отдельных сотрудников и подразделений (проблемы на стыках);

· слабое делегирование полномочий и ответственности, усложнение системы согласований (бюрократизм);

· снижение эффективности ориентации деятельности подразделений на конечный результат.

Литература

1. М.Хаммер, Дж.Чампи. Реинжиниринг корпорации: Манифест революции в бизнесе. СПб.: Изд.СПб университета, 1997.

2. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. М, РИА «Стандарты и качество», 2004 г., 408 с.

3. «Принцип Питера, или Почему дела идут вкривь и вкось». Питер Лоуренс Дж. Издательство: ЭКСМО-Пресс, 2002.

Тема 2. Классификация процессов. Понятие сети процессов организации

Цели обучения:

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

Содержание темы:

1. Классификация процессов.

2. Клиенты процессов.

3. Основные процессы организации.

4. Вспомогательные процессы организации.

5. Процесс управления организацией.

6. Резюме.

Вопрос 1. Классификация процессов.

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

Таблица 1.

Классификация процессов организации

Типы процессов	Характерные признаки	Клиенты
Основные процессы (процессы основной деятельности)	Назначение процессов – создание основных продуктов. Результат – основной продукт и/или полуфабрикат для его изготовления. Процессы лежат на пути создания основных продуктов. Процессы добавляют к продукту ценность для потребителя.	1.Внешние клиенты. 2.Конечные потребители. 3.Внутренние клиенты – другие процессы организации.
Вспомогательные процессы	Назначение процессов – обеспечение деятельности основных процессов. Результат – ресурсы для основных процессов. Деятельность процессов не касается основных продуктов. Процессы добавляют продукту стоимость.	1.Внутренние клиенты – другие процессы организации.
Процесс управления организаций	Назначение процесса – управление деятельностью всей организации. Результат – деятельность всей организации.	Собственники (инвесторы) Потребители (клиенты) Персонал (сотрудники) Поставщики и субподрядчики Общество (внешняя среда)

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

Рис. 7. Основные и вспомогательные процессы

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

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

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

«Все процессы были поделены на первичные и поддерживающие (вспомогательные) в соответствии с теорией М. Портера о цепочках ценности. Некоторые из поддерживающих процессов были потом выделены в отдельный класс - процессы развития. Эти три группы процессов определяются следующим образом:

Первичными процессами называются основные и создающие ценности процессы предприятия. Эти процессы пронизывают всю компанию, начиная с потребителя и заканчивая поставщиками.

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

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

Дальнейшее развитие эта классификация получила при выполнении работ по программе ENAPS (европейская сеть изучения перспективных показателей). Программа предназначалась для создания базы данных для европейской системы сравнительного бенчмаркинга. В результате работы по программе ENAPS были приняты другие названия групп бизнес-процессов:

1. Бизнес-процессы:

1.1. Разработка продукции:

· Исследование продукции,

· Разработка и конструирование продукции,

· Разработка и конструирование процесса,

· Технологическая подготовка производства.

1.2. Требования потребителей:

· Развитие рынка,

· Организация маркетинга и продаж,

· Тендерное размещение заказов.

1.3. Выполнение заказов:

· Обеспечение и материально-техническое снабжение,

· Планирование и управление производством,

· Производство и сборка продукции,

· Распределение продукции и выходящая логистика,

· Обслуживание договора.

1.4. Обслуживание потребителя:

· Послепродажное обслуживание,

· Возврат продукции.

2. Вторичные процессы:

2.1. Поддержка:

· Финансовый менеджмент,

· Управление человеческими ресурсами,

· Управление информацией,

· Текущий ремонт и обслуживание оборудования,

· Медицинский контроль персонала, окружающая среда и техника безопасности.

2.2. Перспективное развитие:

· Совершенствование текущего процесса,

· Исследование технологии производства продукции,

· Повышение квалификации персонала,

· Расширение базы материально-технического снабжения,

· Расширение внешних связей,

· Стратегическое планирование.

Вопрос 2. Клиенты процессов.

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

Рис. 8. Внутренние и внешние клиенты процессы

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

· Клиенты (потребители основных продуктов, производимых организацией).

· Собственники (акционеры, инвесторы, аффилированные лица).

· Персонал (сотрудники и руководители организации).

· Поставщики (поставщики входящих материалов, комплектующих и продуктов, субподрядчики и партнеры, аутсорсинговые компании).

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

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

Вопрос 3. Основные процессы организации.

На рисунке 9 приведен пример перечня основных процессов в организации на основе схемы жизненного цикла продукции, изложенного в стандарте ISO 9004-1:1994. Для конкретной организации отдельные этапы (процессы) могут отсутствовать или быть включенными друг в друга. Например, для предприятий пищевой промышленности нет «процесса утилизации и переработки в конце срока службы», но может быть «процесс утилизации и переработки отходов производства». Для предприятий атомной энергетики «процесс утилизации и переработки в конце срока службы» является одним из важнейших и дорогостоящих процессов.

Рис. 9. Пример перечня основных процессов на основе схемы жизненного цикла продукции по ISO 9004-1:1994

Вопрос 4. Вспомогательные процессы организации.

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

· процесс подготовки кадров;

· процессы сервисного обслуживания оборудования;

· процессы обеспечения связью, IT- обеспечение;

· процесс административно хозяйственного обеспечения;

· процесс финансового и бухгалтерского обеспечения деятельности организации;

· процесс обеспечения безопасности;

· другие процессы.

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

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

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

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

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

Вопрос 5. Процесс управления организацией.

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

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

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

· во-вторых, результативность и эффективность «процессов управления деятельностью» можно будет оценить только по количеству принятых управленческих решений и потраченным на это ресурсам, так как эффективность и результативность управления деятельностью можно оценить только по результатам основной деятельности, а как раз основная деятельность в этот «процесс» и не входит;

· в-третьих, в случае признания за «процессами управления деятельностью» права на самостоятельное существование, придется признать и то, что ресурсы, выделенные для проведения этих процессов, не зависят от цены принимаемого решения и состоят из информации, кабинета со столом, креслом и листом бумаги (для обобщенного «типового» рабочего места руководителя);

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

Совершенно аналогичная ситуация возникает, если выделять как самостоятельные процессы мониторинга, измерений, анализа и улучшений, что достаточно часто встречается в переводной литературе. Причина чаще всего кроется в неквалифицированном переводе. Классический англо-русский словарь В.К. Мюллер дает 10 русских эквивалентов английскому слову «process» (6 существительных и 4 глагола). Переводчики используют только один-единственный – «процесс». Подобные проблемы вы могли увидеть в перечне бизнес-процессов, созданному по проекту ENAPS, в данной теме.

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

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

· отдел стратегического развития (функции – определение проектов стратегических целей организации, составление проектов долгосрочных планов, контроль и анализ их выполнения и т.д.);

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

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

· другие службы или помощники (референты) генерального директора по специфическим видам деятельности.

После перечисления функций процесса управления (аппарата генерального директора) становится ясно, что выделение и описание отдельного процесса управления небольшой (до 300 – 500 работников) организации, тоже может быть нецелесообразным. В более простых случаях можно обойтись без процесса управления, но деятельность генерального директора по управлению организацией все равно должна быть регламентирована. Более подробно цели и способы регламентирования деятельности высшего руководства организации рассмотрим в разделе III.

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

Резюме.

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

2. Процессы организации делятся на три типа:

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

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

· Процесс управления организацией.

3. Основные процессы:

· Назначение процессов – создание основных продуктов,

· Результат – основной продукт и/или полуфабрикат для его изготовления,

· Процессы лежат на пути создания основных продуктов,

· Процессы добавляют к продукту ценность для потребителя,

· Клиенты основных процессов: Внешние клиенты. Конечные потребители. Внутренние клиенты (другие процессы организации),

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

· Назначение процессов – обеспечение деятельности основных процессов,

· Результат – ресурсы для основных процессов,

· Деятельность процессов не касается основных продуктов,

· Процессы добавляют продукту стоимость,

· Клиенты вспомогательных процессов: Внутренние клиенты (другие процессы организации).

5. Процесс управления организацией:

· Назначение процесса – управление деятельностью всей организации,

· Результат – деятельность всей организации,

· Клиенты процесса: Собственники (инвесторы), Потребители (клиенты), Персонал (сотрудники), Поставщики и субподрядчики, Общество (внешняя среда).

Литература

1. Андерсен Бьерн. Бизнес-процессы. Инструменты совершенствования / Пер. с англ. С.В. Ариничева / Науч. ред. Ю.П. Адлер. – М.: РИА «Стандарты и качество», 2003.

2. МС ИСО 9000-1:1994 Общее руководство качеством и стандарты по обеспечению качества. Часть 1: Руководящие указания по выбору и применению.

3. Мюллер В.К. Англо-русский словарь, Издание 23-е стереотипное. – М.: «АЛЬКОР+», 1991.

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

Цели обучения:

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

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

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

Содержание темы:

1. Выделение процессов с учетом существующей оргструктуры.

2. Выделение процессов с учетом системы планирования.

3. Выделение процессов с учетом существующих центров финансового учета.

4. Выделение процессов с учетом размера объектов планирования, учета и отчетности.

5. Выделение процессов на основе разбиения продуктовой цепочки.

6. Выделение процессов с учетом полномочий и зоны ответственности владельца.

7. Выделение процессов с учетом нормы управляемости.

8. Одновременное применение различных принципов выделения процессов.

9. Резюме.

Вопрос 1. Выделение процессов с учетом существующей оргструктуры.

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

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

Пример: В начале 90-х годов прошлого (ХХ-го) века на одном из крупных предприятий возникла проблема снижения издержек. «Бороться» с этой проблемой было поручено финансовому директору. Финансовый директор разработал для сотрудников финансовой службы систему мотивации в зависимости от размера сэкономленных средств. Финансовая служба стала самостоятельно принимать решения, какие счета оплачивать, а какие нет. В первую очередь перестали оплачиваться счета на вспомогательные материалы и запчасти. Издержки предприятия сократились, финансовая служба получила обещанный премиальный фонд, а через три месяца простои оборудования в производстве возросли на 30% из-за отсутствия смазочных, расходных материалов и запчастей для обслуживания оборудования.

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

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

· линейно-функциональные;

· дивизиональные;

· матричные.

Процессы в организациях с линейно-функциональной структурой.

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

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

Рис. 10. Линейно-функциональная структура организации

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

Рис. 11. Схема выделения процессов в торгово-производственной организации, построенной по линейно-функциональной структуре

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

Процессы в организациях с дивизиональной структурой.

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

Рис. 12. Дивизиональное построение организации

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

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

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

Рис. 13. Выделение процессов верхнего уровня в дивизиональной организации

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

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

Данный холдинг выделил у себя 7 основных и 6 вспомогательных процессов.

Основные:

1. Изучение рынков и потребителей.

2. Разработка видения и стратегии.

3. Разработка продуктов.

4. Маркетинг. Мониторинг рынка продукции.

5. Снабжение сырьем и оборудованием.

6. Производство.

7. Сбыт продукции.

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

1. Управление финансовыми и материальными ресурсами.

2. Развитие и управление персоналом.

3. Управление информационными ресурсами и технологиями.

4. Управление программами охраны внешней среды, здоровья, безопасности.

5. Управление внешними связями.

6. Управление улучшениями и изменениями.

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

В некоторой литературе встречается похожее выделение процессов организации, но к вышеупомянутым ошибкам добавляется еще одна. Основной процесс №7 назван «Выставление счетов и сервисное обслуживание». То есть «выставление счетов», работа, выполнением которой в реальной организации занимаются максимум 2-3 сотрудника низшего уровня, поставлена в один ряд с процессами «Маркетинга» и «Производства». Эта ошибка тянется из дословного перевода с английского языка “7.0 INVOICE AND SERVICE CUSTOMER” – 7-й процесс по классификации Международной Бенчмаркинговой Палаты. Данная Модель классификации была разработана и опубликована в 1995 году и использовалась некоторыми организациями для классификации потоков информации (внешней и внутренней) для улучшения межфункциональных и междивизионных коммуникаций. Это пример еще одной ошибки, вызванной употреблением термина «процесс» в различных областях и различном контексте.

Процессы в организациях с матричной структурой.

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

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

· административному руководителю, который отвечает за обеспечение сотрудников (подразделений) ресурсами для выполнения основных обязанностей;

· руководителю проектных работ или руководителю по направлению (Рис. 15).

Рис. 15. Матричная организация работы по направлениям и проектам

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

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

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

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

Вопрос 2. Выделение процессов с учетом системы планирования.

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

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

· стратегические (долгосрочные), разрабатываемые на срок от 1 года и более;

· текущие (оперативные), разрабатываемые на срок до 1 года с разбивкой по кварталам и/или месяцам.

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

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

· доведены до сведения руководителей, отвечающих за направления работы;

· контролироваться и пересматриваться по мере их выполнения.

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

Вопрос 3. Выделение процессов с учетом существующих центров финансового учета.

Принцип 3. Размер процесса определяется экономической целесообразностью создания ограниченного числа центров учета затрат.

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

Пример: «Рассказ финансового директора об организации бюджетирования.

Для того чтобы внедрить бюджет, я должен выделить центры финансового учета (ЦФУ). До этого я, естественно, должен представить организационную структуру компании, описать функции подразделений. Эта операция перехода от организационной структуры к выделению ЦФУ занимает примерно месяц: во-первых, как правило, нет положения об организационной структуре; во-вторых, нужно какое-то время для «эмоционального» разгадывания того, сколько же в этой структуре ЦФУ. Таким образом, у меня через месяц появляется «картинка» ЦФУ.»

Не правда ли, действия финансового директора напоминают действия руководителя проектной группы по выделению и описанию бизнес-процессов организации? В организации, где управление процессами и финансами структурировано, «картинка ЦФУ» и схема бизнес-процессов должны совпасть. Если эти проекты ведут разные руководители то «картинки» могут и не совпасть. Это будет означать, что деятельность организации разделена на различные, не совпадающие, бизнес-единицы с различными системами учета. Вряд ли такое решение можно будет назвать удачным для организации. Таким образом, можно сделать еще один вывод о важности координации действий руководителей в части производства и учета, а также представлении организации, как единого целого.

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

Рис. 16. Взаимосвязь между выделением процессов и центров финансового учета (ЦФУ)

Целесообразность создания большого количества центров учета и процессов связаны между собой, поэтому после первоначального выделения процессов (рис. 11 и 13) следует задать себе следующий вопрос: «для каких вспомогательных процессов существующая система учета может создать ЦФУ и регулярно предоставлять данные анализа финансовой деятельности владельцам вспомогательных процессов в объеме, необходимом для оценки эффективности процессов и управления вспомогательными процессами?».

Первой реакцией руководства организации при взгляде на эту схему будет следующая: Как, разве расходы на содержание управленческой части тоже нужно считать? Ответ: да, тоже нужно! Расходы на содержание управленческого аппарата могут быть очень велики. «Когда заходит речь об экономии и рационализации, то на предприятии обычно сразу обнаруживается почему-то не замечаемый ранее избыток управленцев. Вдруг оказывается, что в компании «Хитачи» 40 процентов расходов на персонал приходится на управленческий аппарат, а ежедневный расход бумаги в компании «Сумитому сёдзи» составляет 2 миллиона листов. Результатом такого рода откровений обычно является сокращение значительной части управленческого персонала. Фирма «Мицукоси», например уменьшила число начальников отделов и секторов почти в четыре раза».

Вопрос 4. Выделение процессов с учетом размера объектов планирования, учета и отчетности.

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

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

Количество процессов, выделяемых в организации напрямую зависит от размера организации и действующей системы управления. В состав процесса кроме системы управления, о которой так много было написано ранее, входит еще и деятельность исполнителей работ (операций) процесса. Технологическая последовательность работ (операций) обычно не вызывает проблем с описанием, но для того, чтобы сгруппировать операции в управляемые блоки под названием процессы, необходимо принять некоторые правила объединения. При использовании полного списка процессов, приведенных в перечне Международной бенчмаркинговой палаты, результат может получиться совершенно ошеломляющий и приводящий организацию в полный ступор. В этом перечне приведены названия 273 процессов! Максимальное количество выделенных процессов, которое приходилось встречать на практике, составляет 127. Для построения учета и управления таким количеством процессов не обойтись без мощного ERP-продукта, который не по карману малым и средним организациям. Для справки – численность организации, в которой было выделено 127 процессов, составляла не более 200 человек. То есть, фактически в организации было произведено выделение функций или работ (операций) нижнего уровня по продуктовой цепочке. Системы учета и управления построены не были.

Вопрос 5. Выделение процессов на основе разбиения продуктовой цепочки.

Принцип 5. Размер процесса определяется разбиением сквозной цепочки создания продукта на промежуточные отрезки (процессы, подпроцессы, функции).

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

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

Рис. 17. Два варианта выделения процессов в зависимости от цепочки преобразования продукта (добавления ценности)

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

Вопрос 6. Выделение процессов с учетом полномочий и зоны ответственности владельца.

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

Для решения этого вопроса необходимо принять во внимание два фактора:

а) кто отвечает за передачу полуфабриката или конечного продукта на следующий этап или клиенту?

б) кто отвечает за наибольшую (наиболее значимую или ресурсоемкую) часть работ по созданию данного конечного или промежуточного продукта?

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

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

· установить границы процесса по правилу Парето 80:20 – в процессе должно выполняться не менее 80% объема работ по преобразованию входа в выход.

Критерии для выделения процессов в случае участия субподрядчиков в получении итогового результата, показаны на рисунке 18.

Рис. 18. Определение владельца процесса при выполнении части работ субподрядчиками

Вопрос 7. Выделение процессов с учетом нормы управляемости.

Принцип 7. Количество процессов, находящихся в подчинении у одного владельца, не должно превышать типовые нормы управляемости.

У одного владельца в подчинении может быть не более чем 7±2 процесса. При этом если процессы в организации построены по принципу вложенности (декомпозиции) сверху вниз, то для руководителей верхнего уровня количество процессов должно быть меньше 7, так как сложность управления объектами растет с их размером (рисунок 19).

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

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

В свою очередь норма управляемости накладывает ограничения на количество процессов, которыми в состоянии управлять руководитель: их тоже может быть не более 7-9 у одного владельца. Чем выше по иерархической лестнице руководитель, тем сложнее управление, и тем меньше направлений должно быть в его подчинении. Наоборот, чем ниже уровень руководства, тем больше подчиненных может быть у руководителя. Например, учительница в классе руководит однотипными действиями 25 учеников, а у генерального директора современного крупного предприятия должно быть не более 4-5 напрямую подчиненных ему заместителей.

На величину нормы управляемости влияют:

· степень информатизации предприятия;

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

· степень делегирования подчиненным прав и полномочий;

· уровень компетентности руководителя и подчиненных;

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

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

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

Для того, чтобы назначить владельца процесса необходимо ответить на ряд вопросов:

1. Кто получает плановые задания и несет ответственность за результат процесса (продукт) перед следующим уровнем руководства?

2. Кто имеет в своем распоряжении и управляет ресурсами и информацией по процессу?

3. Кто отвечает за организацию работ по процессу, определяет технологию работ (операций)?

4. Кто организовывает систему сбора информации о ходе процесса?

5. Кто ведет мониторинг (контроль и анализ) хода процесса?

6. Кто отвечает за реализацию мероприятий по повышению эффективности процесса?

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

Практический опыт выделения процессов и построения систем процессного управления в российских организациях говорит о том, что для организаций численностью до 100 –200 сотрудников можно выделять не более 7-8 процессов, связанных с основной и вспомогательной деятельностью. Примеры выделения процессов для небольшой организации были рассмотрены в предыдущей книге авторов, поэтому повторять их нет смысла. Для организаций более крупного масштаба количество процессов, выделяемых для построения системы управления, может составлять 15 – 20.

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

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

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

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

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

Вопрос 8. Одновременное применение различных принципов выделения процессов.

На рисунке 20 после применения одного из вышеупомянутых правил, в сети функций и работ организации выделен один процесс. Границы процесса обозначены жирной линией, а функции, попавшие в данный процесс, закрашены белым цветом.

Рис. 20. Результат выделения процесса, соответствующего требованиям одного принципа

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

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

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

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

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

Рис. 21. Применение нескольких принципов при выделении процессов приводит к несовпадению границ выделенных процессов

Резюме.

1. Выделение процессов в организациях производится с учетом:

· существующей оргструктуры;

· действующей системы планирования;

· существующих центров финансового учета (ЦФУ);

· размеров объектов планирования, учета и отчетности;

· продуктовой цепочки;

· полномочий и зон ответственности владельцев процессов;

· норм управляемости и степени автоматизации (компьютеризации) управления.

2. Выделенные процессы могут меняться в ходе развития организации и изменении условий внешней среды.

3. Не существует «правильного (типового или универсального) списка» процессов.

Литература

1. «7 нот менеджмента» - 5-е изд., доп. – Москва, ЗАО «Журнал «Эксперт», ООО «Издательство ЭКСМО», 2002.

2. Исикава Каору. Японские методы управления качеством. – М. Экономика. 1988.

3. Пшенников В.В. Японский менеджмент. Уроки для нас. ЗАО "Япония сегодня", Москва, 2000.

4. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. - Москва, РИА «Стандарты и качество», 2004.

5. Веснин В.Р. Основы менеджмента. Москва, Т.Д. «Элит-2000», 2001.

Тема 4. Система показателей бизнес-процессов

Цели обучения:

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

Содержание темы:

1. Интеграция системы показателей бизнес-процессов с системой стратегического управления организацией.

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

3. Использование показателей бизнес-процессов для управления.

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

5. Резюме.

Вопрос 1. Интеграция системы показателей бизнес-процессов с системой стратегического управления организацией.

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

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

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

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

· методику управления на основе стратегии;

· набор регламентирующих документов (разделов документов), включая формы плановых и отчетных документов;

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

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

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

Рис. 22. Интеграция системы стратегического управления с системой управления бизнес-процессами

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

Рис. 23. Структура системы целей, планов и показателей сверху-вниз

После того, как система стратегических целей и показателей для организации в целом создана, необходимо разработать систему показателей для каждого бизнес-процесса. Система показателей «разворачивается» сверху вниз, как показано на рисунке 23. Планы и показатели деятельности организации в целом детализируются на показатели бизнес-процессов верхнего уровня (на схеме рисунка 23 – это бизнес-процессы первого уровня). Затем разрабатываются показатели для процессов второго уровня и т.д. В организации, имеющей 3-4 уровня иерархии управления, рекомендуется выполнять разработку показателей до процессов второго уровня. Важно не переусложнить систему показателей. В дальнейшем, после внедрения и успешной эксплуатации системы, можно переходить к детализации системы показателей для процессов 3-4 уровня. Следует отметить, что разработку системы показателей по процессам верхнего уровня осуществляет руководство организации и владельцы процессов. Разработку системы показателей для процессов второго уровня осуществляют владельцы процессов первого уровня при участии владельцев процессов второго уровня и т.д.

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

Требования к показателям бизнес-процессов.

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

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

· «прозрачность» для руководителей организации;

· удобство для владельцев процессов, управляющих своими процессами на основе этих показателей;

· понятность персоналу, выполняющему процесс;

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

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

При этом необходимо позаботиться о том, чтобы выбранная система показателей процессов была:

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

б) стоимость ее должна быть адекватна ценности информации;

в) достаточно наглядной и простой для анализа и сопоставления информации.

Три вида показателей бизнес-процесса.

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

1. Показатели продукта (результата, выхода) бизнес-процесса. Эта группа показателей характеризует результат процесса - то, ради чего данный бизнес-процесс создан и существует. По этим показателям проводится бенчмаркинговая оценка продукта процесса. Данная группа показателей отвечает на вопрос: «Что произвел процесс?»

2. Показатели эффективности бизнес-процесса. Эта группа показателей характеризует затраты ресурсов на производство продукта процесса и используется для бенчмаркинга самого процесса. Данная группа показателей отвечает на вопрос: «Какой ценой получен данный продукт (результат)?».

3. Показатели удовлетворенности клиентов бизнес-процесса. Эта группа характеризует удовлетворенность потребителей результатами процесса. Данная группа показателей отвечает на вопрос: «Насколько доволен клиент тем, что он получил?».

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

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

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

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

Рис. 24. Схема измерения показателей процесса

Глядя на рисунок 24, легко представить себе аналогию системы показателей с приборной доской, на которой перед летчиком размещена вся информация о ходе полета и состоянии самолета. Такая аналогия была отмечена еще в 1932 г. под названием Tableau De Bord (приборная доска) во Франции, затем Р. Каплан и Д. Нортон разработали свою концепцию BSC (Balanced ScoreCard).

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

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

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

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

Пример показателей процессов отдела подготовки кадров и юридической службы.

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

1. Текучесть кадров (отношение уволившихся к работающим).

2. Качество набора и обучения (отношение выдержавших испытательный срок к принятым на работу).

3. Срок заполнения вакансий.

4. Средний возраст персонала.

5. Средний стаж работы в организации.

6. Подтвержденная эффективность обучения (справки от руководителей подтверждающие эффективность обучения).

7. Количество жалоб, трудовых споров, судебных исков (проигранных), суммы выплат и штрафов, потери от забастовок и др.

8. Отношение выигранных дел к возбужденным.

9. Количество дел решенных во внесудебном порядке.

10. Суммы штрафных санкций, выплаченных за отчетный период.

11. Количество конфликтов с контрагентами и персоналом по юридическим вопросам.

Рассматривая данный набор показателей в качестве примера, не следует забывать, что некоторые показатели могут отражать не эффективность работы кадровой службы, а определенную кадровую политику высшего руководства. Так если в компании установлен жесткий возрастной ценз, или плановая текучесть кадров определена на высоком уровне (10-15 %). Это значит, что руководство организации сознательно ограничивает значение показателей 4 и 5, и их использовать для оценки хода процесса набора и подготовки кадров нельзя.

Вопрос 3. Использование показателей бизнес-процессов для управления.

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

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

Рис. 25. Установление показателей для процессов на основании стратегии компании

Владелец процесса «Клиент» анализирует полученные показатели и организует свой процесс так, чтобы добиться установленных требований. При выполнении и последующем анализе процесса оказывается, что для обеспечения заданных значений показателей, необходимо обеспечить на входе процесса «Клиент» определенное среднее значение показателя «Х» продукта (услуги), поставляемого процессом «Поставщик». Анализ показал (см. рис. 26), что существующее среднее значение показателя «Х» не соответствует требованиям Владельца процесса «Клиент» - плановое значение показателя «Х» оказалось значительно выше существующего.

Рис. 26. Существующая ситуация с показателем «X»

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

Рис. 27. Согласование требований между владельцами процессов

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

Рис. 28. Динамика изменения значений показателя «Х»

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

Регулярно (не реже 1 раза в месяц) владелец процесса «Поставщик» отчитывается перед вышестоящим руководством (см. Рис. 29). В отчет, кроме всего прочего, входит информация по улучшению показателя «Х».

Рис. 29. Отчетность владельца процесса «Поставщик» перед вышестоящим руководством

Если по прошествии нескольких периодов оказывается, что:

а) показатель «Х» не меняется в нужную сторону;

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

Если фактические значения показателя «Х» меняются, приближаясь к установленному целевому уровню, то это означает нормальную работу владельца процесса «Поставщик» по управлению своим процессом.

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

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

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

На некотором предприятии Генеральный директор решил мотивировать владельца одного из основных бизнес-процессов (см. рисунок 30.) на сокращение среднего времени выполнения процесса. Обращаясь к владельцу процесса, директор сказал следующее: «если сокращаешь время выполнения процесса (чтобы стало лучше чем у конкурентов), то получаешь премию сам и платишь премию своим сотрудникам в зависимости от вклада в работу по улучшению…».

Рис. 30. Процесс и его границы

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

Рис. 31. Контрольные точки для измерения длительности выполнения процесса

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

Рис. 32. Средняя длительность выполнения процесса

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

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

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

Рис. 33. Динамика изменения показателей

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

· создавать комплексную, непротиворечивую систему показателей оценки процесса;

· измерять как результативность, так и эффективность процесса;

· определить критерии нормального хода процесса;

· выполнять мониторинг изменения состояния процесса на основе системы показателей;

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

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

Резюме.

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

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

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

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

· «прозрачность» для руководителей организации;

· удобство для владельцев процессов, управляющих своими процессами на основе этих показателей;

· понятность персоналу, выполняющему процесс;

4. Выбранная система показателей процессов должна быть:

· достаточно полной, чтобы адекватно оценивать результаты процессов и процедур;

· стоимость ее должна быть адекватна ценности информации;

· достаточно наглядной и простой для анализа и сопоставления информации.

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

· Показатели продукта (результата, выхода) бизнес-процесса. Эта группа показателей характеризует результат процесса - то, ради чего данный бизнес-процесс создан и существует. По этим показателям проводится бенчмаркинговая оценка продукта процесса. Данная группа показателей отвечает на вопрос: «Что произвел процесс?»

· Показатели эффективности бизнес-процесса. Эта группа показателей характеризует затраты ресурсов на производство продукта процесса и используется для бенчмаркинга самого процесса. Данная группа показателей отвечает на вопрос: «Какой ценой получен данный продукт (результат)?».

· Показатели удовлетворенности клиентов бизнес-процесса. Эта группа характеризует удовлетворенность потребителей результатами процесса. Данная группа показателей отвечает на вопрос: «Насколько доволен клиент тем, что он получил?».

6. Система показателей должна стимулировать владельца процесса решать следующие задачи:

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

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

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

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

Кейс.

Выбор показателей для процесса «Управление финансами» торгово-производственной компании

Рассмотрим пример практического выбора показателей для процесса «Управление финансами» торгово-производственной компании (далее Процесс).

1. Исходные данные по компании.

Некая торгово-производственная компания решила «Описать и оптимизировать бизнес-процессы компании». Общая численность компании составляет около 2000 человек. Компания имеет 10 филиалов, ведущих розничную продажу товаров в различных регионах страны. Структура компании построена по дивизиональной схеме.

2. Исходные данные по процессу «Управление финансами»:

2.1. Владелец процесса – Финансовый директор.

2.2. Состав процесса: В состав Процесса входят следующие структурные подразделения компании:

· Бухгалтерия (15 чел.).

· Финансовый отдел (10 чел.).

· Отдел информационного обеспечения (12 чел).

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

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

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

Рис. 34. Оргструктура финансовой службы компании

2.3. Функции процесса:

· Бюджетирование,

· Бухгалтерский и финансовый учет,

· Составление налоговой отчетности,

· Финансовое планирование,

· Финансовый контроллинг,

· Информационное обеспечение бухгалтерского учета,

· Информационное обеспечение деятельности компании,

· Обеспечение работоспособности связи и оргтехники,

· Информационная безопасность компании.

3. Задание.

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

4. Разбор Кейса.

4.1. Определение выходов (продуктов) процесса «Управлением финансами».

Рис. 35. Состав процесса «Управление финансами» и выходы процесса

Результатами деятельности процесса «Управление финансами» являются:

· Документы бухгалтерского и налогового учета;

· Финансовые планы и бюджеты компании и подразделений;

· Данные финансового контроллинга и аудитов филиалов;

· Работоспособность средств связи и информации.

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

Комментарии:

С точки зрения выделения процессов на основе принципа размеров процесса, если численность служб и подразделений, подчиненных финансовому директору не превышает 50 сотрудников, выделение сразу трех самостоятельных процессов нецелесообразно. В данной ситуации, исходя из однородности и взаимосвязанности функций, выполняемых подразделениями, на начальном этапе построения системы процессов, выделен один процесс под условным названием «Управление финансами». В составе этого процесса при дальнейшей декомпозиции запланировано выделить три подпроцесса: «Бухгалтерский учет», «Финансовый анализ и контроль» и «Информационное обеспечение». Такое разделение необходимо планировать заранее, поскольку оно также оказывает влияние на выделение основного процесса и построение системы показателей деятельности.

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

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

1. Показатели продукта.

1.1. Экономия ресурсов (рассчитывается как экономический эффект от внедрения изменений в работе финансово-бухгалтерской службы).

1.2. Процент отчислений на налоги (от прибыли).

1.3. Отклонения налоговых выплат от плановых (в процентах).

1.4. Отклонения по прибыли по данным аудиторских проверок (в процентах).

1.5. Отклонения по результатам налоговых проверок (в процентах):

· по доначислению прибыли;

· по доначислению других налогов.

1.6. Выполнение плановой прибыли по финансовому инвестированию (в процентах).

1.7. Отклонение от прогноза исполнения бюджета (в процентах).

1.8. Закрытие месяца по учетной программе (в днях после отчетного месяца).

2. Показатели процесса.

2.1. Размер выставленных штрафов от налоговой службы за отчетный период (в рублях).

2.2. Количество не размещенных денежных средств (в рублях).

2.3. Отклонение по прибыли за закрытый период (в процентах).

3. Показатели удовлетворенности потребителей.

3.1. Время оформления заявки на оплату (в рабочих часах).

3.2. Время согласования договоров в финансовой службе (в рабочих часах).

3.3. Время на отправку платежа (в рабочих часах).

3.4. Количество (процент) неточных переводов.

3.5. Эффект от неправильно проведенных финансовых расчетов (расчет по факту анализа отклонения).

3.6. Задержки по выполнению поручений (в днях).

3.7. Исполнение бюджета финансово-бухгалтерской службы (в процентах).

3.8. Эффективность работы персонала (отношение оборота к численности, или к фонду заработной платы)

4. Показатели Отдела информационного обеспечения.

4.1. Коэффициент работоспособности информационного оборудования (включая телефоны и оргтехнику) или время простоев. (К или в часах).

4.2. Процент выполнения заявок на доработки программного обеспечения и оргтехники за месяц (в процентах).

4.3. Среднее время выполнения заявок и технических заданий на доработки (в рабочих часах).

Комментарии:

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

· размер чистой прибыли;

· возврат на активы;

· возврат на инвестиции и т. д.

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

2. Отчеты БДР, БДДС и ББЛ, в которых зафиксированы фактические значения финансовых результатов деятельности компании, являются выходами - одним из результатов деятельности процесса «Управление финансами».

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

Показатели 1.1, 3.5 и 3.8 – для создания объективной методики их расчета потребуется слишком много ресурсов, а результат может получиться весьма субъективным.

Показатели 1.2 и 2.3 – выполнение этих показателей в большой степени зависит от других процессов и подразделений.

Показатели 1.6 и 2.2 – относятся к разовым инвестиционным проектам, которые финансовый директор выполняет по заявкам акционеров лично и не характеризует деятельность процесса «Управления финансами».

Показатель 2.1 – входит в состав показателя 1.5, поэтому его самостоятельное применение нецелесообразно.

Показатели 3.1, 3.2 и 3.3 - можно объединить под общим названием: «Время прохождения документов в подразделении» и для упрощения оценивать его по средней величине времени прохождения.

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

4. В результате ход процесса «Управление финансами» можно оценить по системе из 10 показателей. Именно столько информации о деятельности процесса должно войти в отчетность процесса «Управление финансами», по которой финансовый директор отчитывается перед генеральным директором.

4.3. Окончательный перечень показателей, характеризующих деятельность процесса «Управление финансами».

Показатели продукта:

1. Отклонение налоговых выплат от плановых - (в %).

2. Отклонение по прибыли по данным аудиторских проверок – (в %).

3. Отклонение по результатам налоговых проверок:

· по доначислению прибыли – (в %),

· по доначислению налогов – (в %).

4.Отклонения от прогноза исполнения бюджета – (в %).

Показатели процесса:

5.Закрытие месяца по учетной программе на ____ дней следующих за отчетным месяцем.

6.Исполнение бюджета подразделения.

7. Исполнительская дисциплина.

Показатели удовлетворенности потребителей:

8. Время прохождения документов в подразделении (заявки на оплату, договора).

9. % ошибок (неточностей) при переводах денежных средств.

10. Время простоев по информационному обеспечению – (в часах).

Комментарии:

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

Литература

1. Елиферов В.Г., Репин В.В, Бизнес-процессы. Регламентация и управление, М.: «Инфра-М», 2004 г.

2. Нортон Дэйвид П. Каплан Роберт С. Организация, ориентированная на стратегию. Как в новой бизнес-среде преуспевают организации, применяющие сбалансированную систему показателей.- М.: «Олимп-Бизнес», 2004.

3. Рой Жан, Веттер Магнус, Ольве Нильс-Горан, Оценка эффективности деятельности компании. Практическое руководство по использованию сбалансированной системы показателей. М.: «Вильямс», 2003.

4. Balanced Scorecard Functional Standards™ Release 1.0a, May 5, 2000.

Раздел II. Моделирование бизнес-процессов. Описание бизнес-процессов с помощью различных методик и нотаций

Тема 5. Общие положения. Нотация IDEF0

Цели обучения:

Освоение принципов формирования графических схем бизнес-процессов, ознакомление с различными методиками моделирования и методикой IDEF0 (программный продукт BPWin 4.0).

Содержание темы:

1. Описание бизнес-процессов с помощью графических схем.

2. Основные методологии описания бизнес-процессов.

3. Методология IDEF0.

4. Резюме.

Вопрос 1. Описание бизнес-процессов с помощью графических схем.

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

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

· Какое программное обеспечение использовать для описания?

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

· Как проводить анализ и выявлять проблемы при помощи полученных описаний бизнес-процессов?

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

1. целей проекта (что, для чего, каким образом предполагается менять в организации);

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

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

4. возможностей программных продуктов по документированию процессов.

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

Как правило, описание бизнес-процессов проводится с целью: а) документирования, т.е. описания процессов в виде регламентирующих деятельность документов; б) анализа и реорганизации процессов. Целью реорганизации может быть повышение результативности и эффективности процессов, внедрение информационной системы, подготовка к сертификации по стандартам ISO серии 9000 версии 2000 г. и прочее. Для каждой такой задачи существует определенный набор знаний по бизнес-процессу, которые должны быть отражен в модели процесса. От задачи к задаче требования к описанию бизнес-процессов могут меняться. Попытка учесть в одной модели все стороны и аспекты деятельности одновременно приводит к тому, что модель оказывается перегруженной и неудобной в применении. В общем случае, модель бизнес-процесса должна давать ответы на следующие вопросы:

· Какие функции (работы, операции) необходимо выполнить для получения заданного конечного результата?

· Кто выполняет функции процесса?

· Как происходит взаимодействие исполнителей при выполнении этих функций, в какой последовательности?

· Какие механизмы управления существуют в рамках рассматриваемого бизнес-процесса?

· Какие входящие документы/информацию использует каждая функция процесса?

· Какие исходящие документы/информацию генерирует каждая функция процесса?

· Какие ресурсы необходимы для выполнения каждой функции процесса?

· Какая документация регламентирует выполнение каждой функции?

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

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

Вопрос 2. Основные методологии описания бизнес-процессов.

В настоящее время для описания бизнес-процессов используется несколько методологий. К числу наиболее распространенных относятся методологии моделирования бизнес-процессов (Business process modeling), методологии описания потоков работ (Work Flow modeling) и методологии описания потоков данных (Data flow modeling).

Наиболее широко используемой методологией описания бизнес-процессов является стандарт США IDEF0. Подход IDEF0 был разработан на основе методологии структурного анализа и проектирования SADT. В настоящее время развитие методологии IDEF0 сопряжено с развитием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.). Методология IDEF0 предоставляет аналитику прекрасные возможности для описания бизнеса организации на верхнем уровне с акцентом на управление процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа: по информации, по управлению, движение материальных ресурсов. Продуманные механизмы декомпозиции модели процесса в IDEF0 существенно упрощают работу аналитика. Следует отметить, что модели в нотации IDEF0 предназначены для описания бизнеса на верхнем уровне. Их основное преимущество, на наш взгляд, состоит в возможности описывать управление процессами организации.

Второй важнейшей методологией описания процессов является методология IDEF3. Формально эта методология называется Work Flow modeling, что отражает ее сущность. IDEF3 предназначен для описания рабочих процессов или, говоря другими словами, потоков работ. Методология описания IDEF3 очень близка к алгоритмическим методам построения схем процессов и стандартным средствам построения блок-схем (см. например построение блок-схемы в программе MS Word). Основа методологии IDEF3 состоит в построении моделей процессов по принципу последовательно выполняемых во времени работ (функций, операций). Можно обоснованно утверждать, что IDEF3 лежит в основе популярной в настоящее время методологии ARIS eEPC.

Еще одной группой методологий, активно используемых на практике, являются нотации DFD (Data flow diagramming). Эти нотации предназначены для описания потоков данных. Они позволяют отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами. Кроме того, нотация DFD позволяет описывать потоки документов (документооборот) и потоки материальных ресурсов (например, движение материалов от одной работы к другой). Методология DFD может эффективно использоваться для описания процессов при внедрении процессного подхода к управлению организацией, так как позволяет максимально снизить субъективность описания бизнес-процессов. Схемы процессов в DFD позволяют выявить основные потоки данных в организации. Это важно для последующего создания моделей структуры данных и разработки требований к информационной системе организации.

Одной из современных методологий описания процессов является методология ARIS (Архитектура интегрированных информационных систем). Методология была разработана немецкой компанией IDS Scheer AG. Основа методологии состоит в том, что любая организация рассматривается как сложная система, описание которой строится их четырех основных групп моделей: моделей организационной структуры, моделей функций, моделей данных и, объединяющих эти три группы, - моделей бизнес-процессов. Архитектура ARIS включает большое количество типов моделей, использующих различные типы графических объектов и различные типы связей для построения разносторонних моделей организации. Однако следует подчеркнуть, что на практике используется очень ограниченное число нотаций архитектуры ARIS. К числу наиболее практических важных, относится основная нотация архитектуры ARIS – нотация eEPC, что означает «расширенная цепочка процесса, управляемого событиями». По сути, данная нотация действительно является расширением методологии IDEF3 за счет использования понятия события (Event). Кроме нотации eEPC, ARIS предоставляет аналитику и другие средства описания процессов организации.

В последние годы активно развивается спецификация UML (Unified modeling language). Методология UML предназначена для описания функционирования сложных программных продуктов, основанных на объектно-ориентированных языках программирования. Хотя в рамках этой методологии рассматривается ряд диаграмма (например, Activity diagram), которые можно использовать для описания процессов, в целом UML не предназначен для описания бизнес-процессов организации.

Вопрос 3. Методология IDEF0.

Основные правила методологии IDEF0.

Основным объектом диаграммы процессов в нотации IDEF0 является объект Activity. Графически он представляет собой четырехугольник. Объект служит для описания функций, выполняемых в организации, см. рисунок 36 Напомним, что каждую функцию (процедуру, работу) можно рассматривать в качестве некоторого процесса.

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

Рис. 36. Основные объекты методологии IDEF0

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

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

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

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

Все стрелки начинаются от края диаграммы и подходят к функциям.

Итак, рисунок 36 показывает основные принципы построения диаграммы в IDEF0. На первый взгляд все очень просто. Однако с момента появления нотации (в виде методологии SADT) в начале 70-х годов XX века, более удачных способов описания процессов организации на верхнем уровне предложено не было. В чем же сила этого представления?

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

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

Для понимания принципов моделирования в IDEF0 рассмотрим пример построения простейшей диаграммы процесса.

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

Начнем описание процесса с того, что поместим на диаграмму три функции, как показано на рисунке 37. Первую функцию назовем «Планировать деятельность», вторую – «Осуществлять деятельность и вести регистрацию фактической информации», третью – «Анализировать, контролировать и управлять деятельностью».

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

Рис. 37. Отображение функций бизнес-процесса

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

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

Рассмотрим рисунок 38. Представим себе, что функцию планирования выполняет Коммерческий одел (КО), которые использует при этом MS Excel. Для планирования КО использует информацию о рынке (прайс-листы и т.п.) и заявки клиентов. Регламентируется деятельность КО «Регламентом планирования», «Планом организации на год». Результатом работы КО является «План отгрузки готовой продукции (ГП)». Посмотрим, как эта информация будет отображена на диаграмме. Обращаем ваше внимание, на квадратные скобки, в которые заключена стрелка «Информация о рынке». Эти квадратные скобки на диаграмме обозначают нарушение правил формирования схем. Так обозначается вход или выход, который отсутствует (не «подвязан») на других диаграммах. Такая стрелка носит название «туннельной». Хотя нотация позволяет пользоваться такими стрелками, на практике рекомендуется ограничить их применение минимальным объемом для обозначения внешних контактов. В самом деле, появление на диаграмме такой стрелки на входе какого либо бизнес-процесса, означает, что нет бизнес-процесса, где она является выходом, или (в случае обозначения «туннельного» выхода) – нет процесса-потребителя данного выхода. То есть, в модели появляются разрывы, а ход процессов нарушается. При анализе такой модели, стрелки в квадратных скобках должны быть или привязаны ко входам (выходам) других процессов, или осознанно назначены «туннельными» - не привязанными к другим стрелкам и процессам. В этом случае на готовой диаграмме квадратные скобки меняются на круглые (Рис. 42). «Туннелирование» стрелок является еще одним инструментом, повышающим гибкость моделирования в нотации IDEF0.

Рис. 38. Отображение функции «Планировать деятельность»

Рассмотрим функцию «Осуществлять деятельность…». Ее выполняет Производственный отдел (ПрО) и Цех. Для выполнения работ требуется сырье и материалы. Работы регламентируются нормативами на расход сырья, ГОСТами, ОСТами, ТУ, требованиями клиента. Для работы Производственному отделу требуется АСУ ТП собственной разработки. Для производства готовой продукции Цеху требуются станки и прочее оборудование, т.е. основные средства.

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

Рис. 39. Отображение функции «Осуществление деятельности»

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

В своей работе по анализу и контролю КО руководствуется регламентом анализа и контроля. Не стоит забывать и годовой план работы организации в целом. Для работы КО использует MS Excel.

Судя по схеме процесса, представленной на рисунке 39, КО использует вход «Фактическую информацию по выполнению плана». Что еще необходимо для выполнения работы КО по анализу и контролю? Конечно, плановая информация. Иначе не с чем будет сравнивать фактические данные, и принимать решения. Таким образом, необходимо показать на схеме, что «План отгрузки ГП», являющийся выходом первой функции процесса, и попадающий на вход функции «Осуществлять деятельность», должен так же попадать и на вход функции «Анализировать…деятельность». При этом, как видно на рисунке 40, стрелка, изображающая «План отгрузки ГП» ветвится.

Результатом работы КО является Отчет для руководства организации «План/факт», как показано на следующем рисунке 40.

Рис. 40. Отображение функции «Анализировать … и управлять деятельностью»

Вы заметили, что стрелка, изображающая КО (как и Excel), не повторяется на диаграмме дважды? Она ветвится. Ветвление стрелок – прекрасный инструмент, позволяющей сделать диаграмму процесса более наглядной. Стрелки могут так же сливаться. Подробно ознакомится с правилами ветвления и слияния стрелок можно ознакомится в спецификации стандарта IDEF0. Здесь же мы приведем только несколько основных примеров использования данного механизма.

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

Рис. 41. Основные правила ветвления стрелок в диаграммах IDEF0

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

Ветвление стрелок в ситуации 2 недопустимо, так как оно означало бы, что поток А содержит в себе одновременно и А и Б, что некорректно. Аналогично можно рассмотреть ситуации 3 и 4 слияния стрелок.

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

Первым типом обратной связи в диаграммах IDEF0 являются обратные связи по информации. Они показываются в виде стрелок, выходящих из правой стороны четырехугольника и входящих в левую сторону другого четырехугольника. Обратные связи этого типа на диаграмме процесса обязательно отображаются снизу, т.е. обходят функции снизу. В нашем примере покажем обратную связь по информации «Информация для корректировки плана». Стрелка, отображающая эту обратную связь, выходит из правой стороны четырехугольника «Анализировать…деятельность» и входит в левую сторону четырехугольника «Планировать деятельность». Таким образом, мы отобразили на диаграмме процесса тот факт, что КО регулярно анализирует выполнение плана и, в случае отклонений от него, формирует информацию, необходимую для корректировки плана на следующий период.

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

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

В нашем примере, покажем обратную связь по управлению «Оперативное управляющее воздействие» в виде стрелки, выходящей их правой стороны четырехугольника «Анализировать… и управлять деятельностью» и входит в верхнюю сторону четырехугольника «Осуществлять…деятельность». Эта обратная связь означает, что при анализе и контроле выполнения плана, КО принимает оперативные управленческие решения, регулирующие выполнение работ ПрО и Цеха по производству готовой продукции.

На рисунке 42 представлены обе рассмотренные нами обратные связи – по информации по и управлению.

Рис. 42. Готовая модель бизнес-процесса в нотации IDEF0

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

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

Декомпозиция объектов в диаграммах IDEF0.

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

Рис. 43. Декомпозиция диаграмм в IDEF0

Как видно из рисунка 43, нумерация диаграмм идет сверху вниз – от диаграммы верхнего уровня к диаграммам нижнего уровня. Каждая диаграмма нижнего уровня получает свой номер на основе номера родительской диаграммы верхнего уровня. Например, функция «Осуществлять деятельность…» имеет номер А2, а функции процесса более низкого уровня имеют номера А21 – А 25. Если мы декомпозируем функцию А22, то функции более детального процесса получать номера А221 – А22N. Буквенный индекс А вводится условно. Использование рассмотренного механизма нумерации делает отслеживание функций процессов достаточно наглядным. Напомним, что количество функций на одной диаграмме должно составлять не более 6 (иногда допускается 8). В этом случае по номерам объектов всегда можно однозначно определить уровень процесса.

Преимущества и недостатки использования IDEF0 для описания бизнес-процессов.

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

Таблица 2.

Преимущества и недостатки методологии IDEF0

Преимущества

Недостатки

· полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);

· возможность агрегирования и детализации потоков данных и информации (разделение и слияние стрелок);

· наличие жестких требований методологии, обеспечивающих получение моделей процессов стандартного вида;

· простота документирования процессов;

· соответствие подхода к описанию процессов в IDEF0 стандартам ISO 9000:2000.

· сложность восприятия (большое количество стрелок);

· большое количество уровней декомпозиции;

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

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

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

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

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

Резюме.

1. Выбор методики и программного продукта проекта по описанию бизнес-процессов зависит от:

· целей проекта (что, для чего, каким образом предполагается менять в организации);

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

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

· возможностей программных продуктов по документированию процессов.

2. В общем случае, модель бизнес-процесса должна давать ответы на следующие вопросы:

· Какие функции (работы, операции) необходимо выполнить для получения заданного конечного результата?

· Кто выполняет функции процесса?

· Как происходит взаимодействие исполнителей при выполнении этих функций, в какой последовательности?

· Какие механизмы управления существуют в рамках рассматриваемого бизнес-процесса?

· Какие входящие документы/информацию использует каждая функция процесса?

· Какие исходящие документы/информацию генерирует каждая функция процесса?

· Какие ресурсы необходимы для выполнения каждой функции процесса?

· Какая документация регламентирует выполнение каждой функции?

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

3. Наиболее широко используемой методологией описания бизнес-процессов является стандарт США IDEF0. Подход IDEF0 был разработан на основе методологии структурного анализа и проектирования SADT. В настоящее время развитие методологии IDEF0 сопряжено с развитием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.). Методология IDEF0 предоставляет аналитику прекрасные возможности для описания бизнеса организации на верхнем уровне с акцентом на управление процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа: по информации, по управлению, движение материальных ресурсов.

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

5. Еще одной группой методологий, активно используемых на практике, являются нотации DFD (Data flow diagramming). Эти нотации предназначены для описания потоков данных. Они позволяют отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами. Кроме того, нотация DFD позволяет описывать потоки документов (документооборот) и потоки материальных ресурсов (например, движение материалов от одной работы к другой).

6. Методология ARIS (Архитектура интегрированных информационных систем) была разработана немецкой компанией IDS Scheer AG. Основа методологии состоит в том, что любая организация рассматривается как сложная система, описание которой строится их четырех основных групп моделей: моделей организационной структуры, моделей функций, моделей данных и, объединяющих эти три группы, - моделей бизнес-процессов. Архитектура ARIS включает большое количество типов моделей, использующих различные типы графических объектов и различные типы связей для построения разносторонних моделей организации.

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

Все стрелки начинаются от края диаграммы и подходят к функциям.

8. Для наименования функций могут быть использованы только глаголы или отглагольные существительные.

9. Преимущества методологии IDEF0:

· полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);

· возможность агрегирования и детализации потоков данных и информации (разделение и слияние стрелок);

· наличие жестких требований методологии, обеспечивающих получение моделей процессов стандартного вида;

· простота документирования процессов;

· соответствие подхода к описанию процессов в IDEF0 стандартам ISO 9000:2000.

10. Недостатки методологии IDEF0:

· сложность восприятия (большое количество стрелок);

· большое количество уровней декомпозиции

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

Литература

1. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. Москва, 1993.

2. С.В. Маклаков. BPWin и ERWin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2000.

3. Август-Вильгельм Шеер, Бизнес-процессы: основные понятия, теории, методы, Москва: Просветитель, 1999.

4. А.М. Вендров. Проектирование программного обеспечения экономических информационных систем. Москва: «Финансы и статистика», 2000.

5. А. В. Леоненков. Самоучитель UML. СПб.: БХВ-Петербург, 2001.

Тема 6. Методологии IDEF3, DFD и другие

Цели обучения:

Ознакомление с методиками моделирования потоков работ (IDEF3) и методикой моделирования потоков данных (DFD).

Содержание темы:

1. Методология IDEF3.

2. Методология DFD.

3. Другие методологии описания бизнес-процессов.

4. Резюме.

Вопрос 1. Методология IDEF3.

Нотация IDEF3 является второй важнейшей нотацией (после IDEF0) и предназначена для описания потоков работ (Work Flow modeling). IDEF3 широко используется для создания моделей бизнес-процессов организации на нижнем уровне (при описании работ, выполняемым в подразделениях и на рабочих местах). Следует отметить, что нотация IDEF3 была взята за основу при создании методики описания процессов ARIS eEPC – «расширенной цепочки процесса, управляемого событиями».

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

Таблица 3.

Виды объектов для отображения бизнес-процессов в нотации IDEF3

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

На рисунке 44 приведен пример бизнес-процесса в нотации IDEF3 под названием «Обработать заявку клиента». Рассматриваемый процесс является частью более общего процесса «Сбыт готовой продукции». Процесс начинается с поступления заявки клиента, которую обрабатывает функция «Выполнить учет заказа в системе». По ходу ее выполнения данные заказа клиента регистрируются в системе автоматизации (например, в файле Excel). Затем менеджер отдела сбыта выполняет проверку на соответствие номенклатуре (функция «Выполнить анализ на соответствие номенклатуре»). Результатом выполнения данной функции могут быть два события: первое – «заказ соответствует номенклатуре изделий, производимых организацией», второе – «заказ не соответствует номенклатуре изделий». Для отражения этих событий в модели процесса используется логический оператор «исключающее или» (кстати, в спецификации IDEF3 логические операторы называются «перекрестками»). После этого логического оператора процесс ветвится. В случае несоответствия заказа номенклатуре выполняется нижняя ветка процесса, а именно функции: «Уведомить клиента о невозможности выполнения заказа» и «Внести заказ клиента в статистику неудовлетворенного спроса».

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

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

Обратим внимание, что данный процесс приводится в виде модели в нотации ARIS eEPC, для сравнения возможностей двух нотаций по описанию одного и того же процесса. Также для сравнения способов представления одной и той же информации о процессе, в данной теме этот процесс изображен с разделением по зонам ответственности и видам объектов в нотации ARIS PCD (Process Chain Diagram).

Рис. 44. Модель бизнес-процесса «Обработать заявку клиента» в нотации IDEF3

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

Вопрос 2. Методология DFD.

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

Рис. 45. Схема процесса в нотации DFD

На диаграмме DFD функции обычно располагаются слева направо в порядке, соответствующем последовательности их выполнения во времени, хотя это не является обязательным. Если придерживаться указанного требования, то полученная схема будет являться описанием процесса, которое схоже с описанием процесса в нотации IDEF3. Процесс, представленный на рисунке 45 имеет два входящих потока данных и три исходящих потока данных. На верхнем уровне рассмотрения этот процесс выглядел бы в виде одной функции с двумя входами и тремя выходами. Таким образом, к описанию процессов в DFD применимы типовые правила декомпозиции. Что касается сторон четырехугольников, то в нотации DFD они не имеют того значения, как в IDEF0.

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

Рис. 46. Модель процесса в нотации DFD

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

· определение существующих хранилищ данных (текстовые документы, файлы, СУБД);

· определение и анализ данных, необходимых для выполнения каждой функции процесса;

· подготовка к созданию модели структуры данных организации;

· выделение основных и вспомогательных бизнес-процессов организации.

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

Рис. 47. Отображение потоков данных и материальных потоков с помощью нотации DFD

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

Вопрос 3. Другие методологии описания бизнес-процессов.

Описание процессов при помощи блок-схем.

Простейшим, но практически важным, способом описания бизнес-процессов является методика составления блок-схем. Данный подход имеет много общего с графическими языками описания алгоритмов программного обеспечения. С точки зрения методологии, формирование блок-схем проводится так же, как в нотации IDEF3, хотя для упрощения символы логики могут опускаться. Для разработки блок-схем могут быть использованы стандартные офисные программные продукты, например MS Word или Visio. Основные графические объекты языка описания процессов при помощи блок-схем представлены в следующей таблице 4.

Таблица 4.

Графические объекты блок-схемы процесса

Пример описания процесса при помощи блок-схем представлен на следующем рисунке 48.

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

Рис. 48. Пример блок-схемы процесса

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

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

Диаграммы класса Swim Lane.

Диаграммы класса Swim Lane строятся по классификации блоков и/или признакам ответственности за выполнение функций (работ). Поле диаграммы разделяется по горизонтали и/или вертикали на параллельные «плавательные дорожки» (отсюда и название диаграммы). Блоки функций располагаются по зонам ответственности (дорожкам). Последовательность выполнения работ отображается стрелками-связями между ними. Такая диаграмма позволяет однозначно распределить ответственность за выполнение функций и оценить степень загрузки каждого ответственного. Диаграммы класса Swim Lane строятся в программных продуктах BPWin 4.0 (DFD) и ARIS Toolset (ARIS PCD). На следующем рисунке 49 приведен пример построения диаграммы Swim Lane в нотации ARIS PCD.

Рис. 49. PCD диаграмма процесса «Обработка заявки клиента»

На рис. 49 описан то же процесс «Обработка заявки клиента», что и на рис. 44 в методологии IDEF3 но объекты расположены в виде столбцов таблицы. В первом столбце расположены события и некоторые символы логики, во втором – функции, в третьем – входящие и исходящие документы, в четвертом – виды прикладного программного обеспечения, в пятом – должности, задействованные в процессе. Такое представление процесса лучше подходит для целей документирования процессов. Однако представление PCD обладает существенным недостатком – его можно эффективно применять для простых (не более 5-8 функций), желательно линейных процессов. Сложные процессы с разветвленной логикой отображать при помощи PCD неудобно, что наглядно видно на рисунке 49.

На следующем рисунке 50 изображена часть диаграммы Swim Lane, нарисованная с помощью MS Word. Такие диаграммы удобны для документирования простых рабочих операции, которые охватывают деятельность нескольких различных подразделений. На это следует обратить внимание, поскольку подавляющее количество процессов при их выполнении пресекает границы функциональных подразделений. Как правило, до 85% проблем возникает на стыках функциональных подразделений из-за несогласованности взаимодействий между функциональными подразделениями. Подробнее вопросы межфункционального взаимодействия будут рассмотрены в разделе III.

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

Рис. 50. Swim Lane диаграмма для «Инструкции по приемке товара» Оператора системы в торгово-закупочной организации

Резюме.

1. Нотация IDEF3 является второй важнейшей нотацией (после IDEF0) и предназначена для описания потоков работ (Work Flow modeling). IDEF3 широко используется для создания моделей бизнес-процессов организации на нижнем уровне (при описании работ, выполняемым в подразделениях и на рабочих местах).

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

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

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

5. Созданные при помощи нотации DFD модели потоков данных организации могут быть использованы при решении таких задач, как:

· определение существующих хранилищ данных (текстовые документы, файлы, СУБД);

· определение и анализ данных, необходимых для выполнения каждой функции процесса;

· подготовка к созданию модели структуры данных организации;

· выделение основных и вспомогательных бизнес-процессов организации.

6. Простейшим способом описания бизнес-процессов является методика составления блок-схем. Данный подход имеет много общего с графическими языками описания алгоритмов программного обеспечения. Для разработки блок-схем могут быть использованы стандартные офисные программные продукты, например MS Word или Visio. Такая форма представления блок-схем удобна для документирования процессов и создания регламентирующей документации: описания процессов, должностных и рабочих инструкций.

7. Диаграммы класса Swim Lane строятся по классификации блоков и/или признакам ответственности за выполнение функций (работ). Поле диаграммы разделяется по горизонтали и/или вертикали на параллельные «плавательные дорожки» (отсюда и название диаграммы). Блоки функций располагаются по зонам ответственности (дорожкам). Последовательность выполнения работ отображается стрелками-связями между ними. Такая диаграмма позволяет однозначно распределить ответственность за выполнение функций и оценить степень загрузки каждого ответственного и хорошо подходит для целей документирования процессов. Однако представление PCD обладает существенным недостатком – его можно эффективно применять для простых (не более 5-8 функций), желательно линейных процессов. Сложные процессы с разветвленной логикой отображать при помощи PCD неудобно.

Литература

1. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М.: 1993.

2. С.В. Маклаков. BPWin и ERWin. CASE-средства разработки информационных систем. М.: Диалог-МИФИ, 2000.

3. В.В.Репин, В.Г. Елиферов. Процессный подход к управлению. Моделирование бизнес-процессов. М.: РИА «Стандарты и качество», 2004.

4. А. Шматалюк и др. Моделирование бизнеса. Методология ARIS. Практическое руководство. М.: Серебряные нити, 2001.

Тема 7. Методология моделирования бизнес-процессов ARIS

Цели обучения:

Рассмотреть методологию ARIS (Architecture of Integrated Information Systems – Архитектура Интегрированных Информационных систем) – вторую из самых распространенных методик моделирования бизнес-процессов.

Содержание темы:

1. Общая структура методологии ARIS.

2. Нотация Value-added chain diagram (VAD).

3. Нотация ARIS eEPC – расширение нотации IDEF3.

4. Нотация ARIS Organizational Chart.

5. Нотация ARIS Function Tree.

6. Нотация ARIS Product Tree.

7. Нотация ARIS Information Flow.

8. Использование нескольких нотаций при создании моделей процессов в ARIS.

9. Резюме.

Вопрос 1. Общая структура методологии ARIS.

В данной теме мы рассмотрим методологию ARIS (Architecture of Integrated Information Systems – Архитектура Интегрированных Информационных систем). Методология разработана в компании IDS Scheer AG, Германия. В настоящее время на рынке инструментальных средств моделирования бизнес-процессов представлено одноименное ПО ARIS, включающее такие модули, как: ARIS Easy Design, ARIS Toolset, ARIS Server и др.

Методология ARIS включает в себя несколько различных нотаций для описания деятельности организации с различных точек зрения. В методологию были интегрированы существующие стандарты и спецификации описания процессов и данных, например: IDEF3, ERD, DFD, UML и т.д. Основная концепция ARIS по описанию организации показана на следующем рисунке 51.

Рис. 51. «Домик ARIS»

Изображение на рисунке 51 часто называют «домиком ARIS». Подход методологии ARIS к описанию процессов основывается на рассмотрении деятельности организации с четырех точек зрения: взгляд на организационную структуру, взгляд на данные (потоки и структура), взгляд на функции (функциональные иерархии), взгляд на контроль и управление (сводные модели бизнес-процессов).

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

· нотация Value-added chain diagram (диаграмма цепочки процесса, добавляющего стоимость);

· нотации extended Event-driven Process Chain – eEPC (расширенная нотация цепочки процесса, управляемого событиями) и PCD (диаграмма цепочки процесса);

· нотация Organizational chart (организационная диаграмма);

· нотация Function tree (дерево функций);

· нотация Product tree (дерево продуктов).

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

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

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

Вопрос 2. Нотация Value-added chain diagram (VAD).

На следующем рисунке представлена одна из важнейших нотаций ARIS – нотация Value-added chain diagram. Диаграмма цепочки процесса, добавляющего стоимость, используется при описании бизнес-процессов организации на верхнем уровне. Как правило, консультанты, использующие ARIS, рекомендуют выделять 6-8 бизнес-процессов верхнего уровня и описывать их в нотации VAD. Затем проводится декомпозиция полученных процессов верхнего уровня, при этом используется либо нотация VAD, либо eEPC. Рассмотрим основные объекты нотации VAD, представленные на рисунке 52.

Основным объектом нотации VAD является объект «Value added chain». Фактически это процесс или некоторая группа функций организации, которая служит для получения добавленной стоимости. Объекты соединяются между собой пунктирной стрелкой, которая имеет тип «is predecessor of» - «является предшественником». Этот тип связи показывает, что один процесс является предшественником другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные связи. Поэтому термин «is predecessor of», на наш взгляд, является неудачным.

Рис. 52. Внешний вид бизнес-процесса, описанного в нотации Value-added chain diagram (VAD)

Между процессами, отображенными на схеме рисунка 52, могут быть отображены потоки материальных ресурсов и информации. Для описания этих потоков можно воспользоваться объектами типа «Cluster» - для описания информации, и «Technical term» - для описания материальных потоков. Для описания инфраструктуры, необходимой для выполнения процесса, в данном примере выбраны типы объектов «Product/Service» и «Information service». Выбор типов объектов для отображения реальных потоков является в достаточной степени условным. Очень важно в начале работ по моделированию процессов определиться, какие именно типы объектов будут использованы, и какие объекты реального мира они будут отображать. Так в случае примера рисунка 52, можно было бы показать все потоки (информационные и материальные) при помощи объектов типа «Technical term».

На рисунке 52 показаны так же объекты «Organizational unit», отображающие организационные подразделения, выполняющие соответствующие процессы.

Объекты связываются между собой при помощи связей определенного типа (см. рисунок 52). Например, информационные поток, отображаемый объектом «Cluster», является входящим для первого процесса и связан с ним при помощи стрелки типа «is input for» («является входом для»). Другим примером является тип связи «executes» - «исполняет» между объектами «Value added chain» и «Organizational unit». Тип связи «is used by» показывает, что «Product/Service» используется процессом и т.д. Таким образом, в методологии ARIS важнейшим требованием является корректный выбор и дальнейшее использование связей и объектов определенного типа.

На следующем рисунке 53 представлен пример модели верхнего уровня, выполненный в нотации ARIS VAD. Вы уже знакомы с этим процессов. В предыдущей теме, этот же процесс представлен в нотации IDEF0.

Рис. 53. Процесс производства продукции, описанный с помощью методологии ARIS, нотация VAD

Принципы построения диаграммы процесса верхнего уровня в VAD существенно отличаются от IDEF0. Существенным отличием нотации ARIS VAD и IDEF0 является то, что в VAD стрелки могут входить в любую сторону объекта «Value-added chain». (Напомним, что в IDEF0 каждая сторона объекта «Activity» (функция) имеет определенное назначение.) На рисунке 54 представлена ситуация, возможная в нотации VAD, когда на диаграмме процесса приводится множество обратных связей, смысл которых понятен только создавшему модель аналитику.

Рис. 54. Использование обратных связей в нотации ARIS VAD

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

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

Вопрос 3. Нотация ARIS eEPC – расширение нотации IDEF3.

Нотация ARIS eEPC расшифровывается следующим образом - extended Event Driven Process Chain – расширенная цепочка процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В следующей таблице 5 приводятся основные используемые в рамках нотации объекты.

Таблица 5.

Объекты для описания бизнес-процессов в нотации ARIS eEPC

Помимо указанных в таблице 5 основных объектов, при построении диаграммы eEPC могут быть использованы многие другие объекты. На практике применение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и делает ее плохо читаемой.

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

Рис. 55. Простейшая модель в нотации eEPC

Из рисунка 55 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» («activates») или инициирует выполнение Функции 1. Функция 1 «создает» («creates») Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3.

Внимательный анализ нотации eEPC показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием eEPC является наличие объекта «событие» («Event»). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выполняется та или иная последующая ветка процесса. Нотация eEPC называется, очевидно, расширенной именно вследствие наличия в ней объекта «событие», - в IDEF3 такого объекта нет. На следующем рисунке 56 приводятся примеры применения символов логики и событий при построении моделей в нотации eEPC.

Рис. 56. Применение логических операторов при построении моделей в eEPC

При построении модели в ARIS eEPC должны соблюдаться следующие правила:

· каждая функция должна быть инициирована событием и должна завершаться событием;

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

Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.

На рисунке 57 показано применение различных объектов нотации ARIS eEPC при создании модели бизнес-процесса.

Рис. 57. Применение различных объектов при создании модели в нотации eEPC

Из рисунков 56 и 57 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов и визуального отображения загрузки персонала в процессе можно использовать другие инструменты описания, например графики Гантта в приложении MS Project.

Рассмотрим примеры применения нотации eEPC для описания бизнес-процессов. На рисунке 58. представлен бизнес-процесс обработки заказа клиента. Этот же процесс изображен в нотации IDEF3.

Процесс начинается с события «Поступил заказ клиента». Это событие инициирует функцию «Выполнить учет заказа в системе», которую выполняет менеджер Отдела сбыта. Для выполнения работы он использует «Систему учета заказов». Результат выполнения функции отображается событием «Учет заказа выполнен». После этого менеджер по сбыту выполняет функцию «Выполнить анализ на соответствие номенклатуре». Результатом выполнения функции являются два альтернативных события «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического исключающего «ИЛИ».

Функция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: если заказ не соответствует номенклатуре, либо производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ» и т.д.

Как видно из рисунка 58, схема процесса в ARIS eEPC отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и должностей. Схема в ARIS визуально представляется более информативной и воспринимается лучше, однако размер этой схемы существенно превышает размер схемы в нотации IDEF3.

Рис. 58. Пример описания процесса в нотации ARIS eEPC

Вопрос 4. Нотация ARIS Organizational Chart.

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

Рис. 59. Модель организационной структуры предприятия

Модель строится из объектов "Organizational unit", "Position", "Internal person" и др. Заложенные в нотацию виды связей позволяют отразить различные виды отношений между объектами организационной структуры. В представленном на рисунке примере "Предприятие" управляется "Директором", при этом используется тип связи "is Organization Manager for". Иерархия подразделений строится при помощи связей типа "is composed of". Так же могут быть указаны должности – "Position" и фамилии реальных сотрудников, их занимающие – "Internal person", тип связи "occupies".

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

Вопрос 5. Нотация ARIS Function Tree.

Нотация ARIS Function Tree предназначена для формирования моделей дерева функций. Пример такой модели представлен на рисунке 60. Все функции на диаграмме рисунка 60 соединены связями. Чаще всего используются типы связей «is execution-oriented superior» и «is process-oriented superior». Первый тип связи служит для построения дерева по функциональному признаку (описания функций подразделения). Второй тип связи используется при построении дерева функций, входящих в некоторый бизнес-процесс.

Рис. 60. Модель Function Tree

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

Вопрос 6. Нотация ARIS Product Tree.

На рисунке 61 представлена нотация ARIS Product Tree. Эта нотация предназначена для создания моделей дерева продуктов. Модели такого типа могут использоваться для описания материальных входов и выходов процесса.

Рис. 61. Модель Product Tree

Вопрос 7. Нотация ARIS Information Flow.

Нотация Information Flow является аналогом нотации DFD и используется при построении схем потоков данных или документов между функциями бизнес-процессов предприятия. Простота нотации ограничивает области ее полезного применения. Основными объектами нотации являются "Function" (- используется так же при построении моделей бизнес-процесов) и "Information Flow" – информационный поток, как показано на следующем рисунке 62.

Рис. 62. Нотация ARIS Information Flow

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

Вопрос 8. Использование нескольких нотаций при создании моделей процессов в ARIS.

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

Рис. 63. Использование нотаций ARIS при создании моделей

Как правило, работа по описанию бизнес-процессов организации в ARIS начинается с создания модели организационной структуры. Одновременно (или позже) могут разрабатываться модели, описывающие структуру основных материальных входов и выходов, а так же основных информационных входов и выходов. С использованием данных моделей создаются модели бизнес-процессов верхнего уровня в нотации VAD. После этого разрабатываются модели функций подразделений и другие вспомогательные модели (например, описание прикладных программных систем). Затем формируются модели процессов в нотации eEPC. Модели eEPC строятся на основе уже имеющихся описаний организационной структуры, функций подразделений, материалов, систем и т.д. Итогом работы является комплект моделей, описывающих деятельность организации с различных точек зрения.

Резюме.

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

· нотация Value-added chain diagram (диаграмма цепочки процесса, добавляющего стоимость);

· нотация Organizational chart (организационная диаграмма);

· нотация Function tree (дерево функций);

· нотация Product tree (дерево продуктов).

2. Сила методологии ARIS (с формальной точки зрения) заключается в ее комплексности, которая проявляется во взаимосвязи моделей, построенных в различных нотациях.

3. Основные недостатки такого комплексного подхода:

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

· трудно реализуемы на практике, так как влекут большой расход ресурсов (человеческих, материальных и финансовых) в течение длительного времени.

4. Диаграмма цепочки процесса, добавляющего стоимость, используется при описании бизнес-процессов организации на верхнем уровне. Как правило, консультанты, использующие ARIS, рекомендуют выделять 6-8 бизнес-процессов верхнего уровня и описывать их в нотации VAD. Затем проводится декомпозиция полученных процессов верхнего уровня, при этом используется либо нотация VAD, либо eEPC.

5. Внимательный анализ нотации eEPC показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием eEPC является наличие объекта «событие» («Event»). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выполняется та или иная последующая ветка процесса. Нотация eEPC называется, очевидно, расширенной именно вследствие наличия в ней объекта «событие», - в IDEF3 такого объекта нет.

6. При построении модели в ARIS eEPC должны соблюдаться следующие правила:

· каждая функция должна быть инициирована событием и должна завершаться событием;

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

7. Как правило, работа по описанию бизнес-процессов организации в ARIS начинается с создания модели организационной структуры. Одновременно (или позже) могут разрабатываться модели, описывающие структуру основных материальных входов и выходов, а так же основных информационных входов и выходов. С использованием данных моделей создаются модели бизнес-процессов верхнего уровня в нотации VAD. После этого разрабатываются модели функций подразделений и другие вспомогательные модели (например, описание прикладных программных систем). Затем формируются модели процессов в нотации eEPC. Модели eEPC строятся на основе уже имеющихся описаний организационной структуры, функций подразделений, материалов, систем и т.д. Итогом работы является комплект моделей, описывающих деятельность организации с различных точек зрения.

Кейс.

Разбор типовых ошибок моделирования бизнес-процессов

1. Пример типовых ошибок при моделировании в нотации IDEF0.

1.1. Задание для решения.

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

Рис. 64. Пример модели бизнес-процесса в нотации IDEF0, содержащей ошибки

2. Ошибки при формировании модели в нотации ARIS eEPC.

2.1. Задание для решения.

На рисунке 65 представлен пример некорректной модели в ARIS eEPC. Модель бизнес-процесса, представленная на рисунке 65 содержит ряд типичных ошибок, которые часто допускают при использовании нотации ARIS eEPC (более обще – нотаций класса Work Flow).

Рис. 65. Типичные ошибки модели бизнес-процесса в нотации ARIS eEPC

3. Разбор Кейса.

3.1. Пример типовых ошибок при моделировании в нотации IDEF0.

Разбор примера диаграммы.

На рисунке 66 указаны ошибки, допущенные на IDEF0-диаграмме рисунка 65. Нарушением нотации IDEF0 является отсутствие управляющего воздействия для функции А3. На рисунке 66 эта ошибка исправлена - появилось стрелка «Регламент 3», отображающая управляющее воздействие. Согласно стандарту IDEF0, для каждой функции на диаграмме процесса должно быть указано хотя бы одно управляющее воздействие.

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

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

Четвертая ошибка на диаграмме заключается в некорректном слиянии стрелок, а именно стрелки «Информация D» и «Информация E» сливаются в одну стрелку «Информация D», что является нарушением требований стандарта.

Рис. 66. Разбор ошибок в модели бизнес-процесса, представленной на рисунке 65

4. Ошибки при формировании модели в нотации ARIS eEPC.

Разбор примера диаграммы.

Разбор ошибок, допущенных на рисунке 66, представлен на рисунке 67. Ошибкой является некорректное использование символов логики, а именно операторов «И» и «исключающее ИЛИ». Если рассматривать модель процесса слева направо видно, что процесс разветвляется на две ветки при помощи оператора «И». Это означает, что выполняются обе ветки процесса. Однако рассматриваемые ветки процесса сливаются при помощи оператора «исключающее ИЛИ». Это означает, что процесс продолжается при выполнении любой из предыдущих веток процесса. Поэтому человек, читающий такую модель, не сможет ее однозначно интерпретировать. (Заметим, что при наличии подробного текстового комментария модель с указанной ошибкой все-таки можно будет использовать). Если поменять символы «И» и «исключающее ИЛИ» местами, то мы получим полностью некорректную модель, поскольку по ходу процесса будет выполнять только одна ветка процесса, но завершение процесса будет возможно только в случае выполнения двух веток.

Рис. 67. Разбор ошибок в модели бизнес-процесса, представленной на рисунке 66

Еще две ошибки в модели связаны с некорректным отображением стрелок, входящих в функцию и исходящих из функции. В нотации ARIS eEPC в любую функцию может входить только одна стрелка и выходить только одна стрелка (то же самое требование действует в нотации IDEF3). Дело в том, что стрелки отображают последовательность выполнения функций процесса во времени. Любая функция начинается и заканчивается определенным событием. Возможно ситуация, когда функция может закончиться двумя различными событиями. В этом случае, функция соединяется стрелкой с логическим оператором ветвления «исключающее ИЛИ», от которого идут стрелки к двум событиям. Таким образом, в корректно построенной модели у каждой функции не должно быть более одной входящей и одной исходящей стрелки.

Еще одна ошибка связана с некорректным использованием оператора ветвления процесса «исключающее ИЛИ». На вход данного оператора поступают две стрелки, в то время как выходом также являются две стрелки. Корректно интерпретировать такой оператор ветвления невозможно. Для устранения указанной ошибки необходимо использовать дополнительный оператор «ИЛИ» (возможно «И» - в зависимости от вкладываемого в модель смысла).

Литература

1. А. Шматалюк и др. Моделирование бизнеса. Методология ARIS. Практическое руководство. Москва: "Серебряные нити", 2001.

2. Август-Вильгельм Шеер, Бизнес-процессы: основные понятия, теории, методы, Москва: Просветитель, 1999.

3. Елиферов В.Г., Репин В.В, Бизнес-процессы. Регламентация и управление. – (учебник для программы МВА) М.: «Инфра-М», 2004.

Раздел III. Технология реструктуризации бизнес-процессов

Тема 8. Организационная часть проекта реструктуризации бизнес-процессов.

Цели обучения:

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

Содержание темы:

1. Введение.

2. Подготовка проекта описания бизнес-процессов.

3. Методология «полного» описания бизнес-процессов.

4. Резюме.

5. Приложение.

Введение.

Цели проектов реструктуризации бизнес-процессов.

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

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

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

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

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

· отсутствие четких критериев достижения целей проекта;

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

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

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

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

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

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

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

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

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

3. Для ведения проекта по реструктуризации среди сотрудников организации должно быть некоторое количество людей, занимающих активную позицию и готовых к переменам. Это количество часто называют «критической массой». Размер «критической массы» в изменяемом объекте (организации или процессе) не должен быть меньше 25-30% от численности сотрудников всего объекта. Без поддержки сотрудников любые начинания тоже заглохнут.

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

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

· участие руководства верхнего уровня;

· наличие четких, проработанных целей проекта;

· наличие профессионального руководителя проекта;

· наличие утвержденной методологии ведения проекта, включая методологию создания моделей процессов;

· рабочая команда, соответствующая поставленным задачам;

· эффективное использование инструментальных средств моделирования бизнес-процессов;

· освещение работ среди сотрудников предприятия.

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

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

· опыт работы в организации (отрасли) не менее 3 лет;

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

· знание и понимание принципов процессного управления и методов менеджмента качества;

· знание и понимание методологий моделирования бизнес-процессов (знание нотаций моделирования или способов отображения бизнес-процессов);

· владение методологией ведения проекта по описанию бизнес-процессов;

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

Вопрос 1. Подготовка проекта описания бизнес-процессов.

Подготовка проекта описания бизнес-процессов.

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

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

· диагностика проблем предприятия;

· определение перечня основных бизнес-процессов;

· определение целей проекта;

· выбор (разработка) и утверждение методики ведения проекта, включая методику моделирования бизнес-процессов;

· подготовка программного и аппаратного обеспечения;

· формирование рабочих групп;

· методическая подготовка: обучение руководителей и специалистов предприятия;

· информирование персонала о задачах проекта;

· детальное планирование работ.

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

Рис. 68. Последовательность работ подготовительного этапа проекта

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

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

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

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

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

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

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

Управление проектом по описанию бизнес-процессов.

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

· мотивацию персонала организации, демонстрирование личной заинтересованности в проекте;

· участие в постановочных совещаниях рабочей группы;

· оперативный анализ разрабатываемых материалов;

· оперативный контроль деятельности руководителей подразделений и рабочей группы;

· поэтапный контроль выполнения проекта;

· анализ и перераспределение функций подразделений, ответственности и полномочий руководителей, ресурсов на основе результатов проекта;

· обеспечение рабочей группы необходимыми ресурсами.

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

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

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

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

Отметим несколько моментов, важных при управлении рабочей группой:

· оперативный контроль за деятельность членов рабочей группы;

· ежедневные совещания (10-15 мин) перед началом рабочего дня;

· еженедельная отчетность перед высшим руководством о ходе проекта;

· ежемесячные расширенные совещания рабочей группы с подведением итогов работы;

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

Создание и обучение рабочих групп.

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

Рис. 69. Формирование рабочей группы

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

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

1. желание работать в проекте и улучшать деятельность организации;

2. опыт работы в организации не менее 3-х лет;

3. знание и понимание задач своего подразделения и выполняемых функций;

4. знания и навыки в области менеджмента организаций;

5. авторитет в коллективе, высокая «ценность» сотрудника для подразделения;

6. возможность быстрого обучения, возможность творческой работы;

7. коммуникабельность;

8. инициативность;

9. навыки работы с персональным компьютером.

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

Таблица 6.

Оценка сотрудников для отбора в рабочую группу

№	Критерий отбора	Вес	Иванов И.И.	Петров А.П.	Сидоров В.А.
1	Желание работать в проекте и улучшать деятельность организации	1	10	7	5
2	Опыт работы в организации не менее 3-х лет	0,6	6	3	8
3	Знание и понимание задач своего подразделения и выполняемых функций	0,8	4	7	5
4	Знания и навыки в области менеджмента организаций	1	8	5	6
5	Авторитет в коллективе, высокая «ценность» сотрудника для подразделения	1	4	8	9
6	Возможность быстрого обучения, возможность творческой работы	0,5	6	6	4
7	Коммуникабельность	0,5	3	7	7
8	Инициативность	0,4	6	9	6
9	Навыки работы с персональным компьютером	0,2	3	9	7
…
	Итоговая оценка		36,3	39,3	38,1

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

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

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

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

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

· принципы и методы управления процессами (идеология процессного управления);

· методы измерения эффективности и качества процессов;

· методы моделирования бизнес-процессов;

· инструментарий моделирования бизнес-процессов (BPWin, ARIS и др);

· основы проектного управления.

Обучение по этим тематикам целесообразно проводить в течение трех семинаров-тренингов: первый – по темам 1-2, второй – по теме 3, третий – по теме 4. Примерная программа обучения приводится в следующей таблице 7.

Таблица 7.

Типовая программа обучения сотрудников рабочей группы

№	Наименование темы	Состав вопросов
1	Принципы и методы управления процессами	1. Классификация процессов организации. 2. Философия процессного управления (Деминг, Джуран, Кросби и др.). 3. Принципы управления процессами. Цикл Деминга PDCA. 4. Методика внедрения процессного управления организацией. 5. Разработка документации, регламентирующей управление процессами.
2	Методы измерения эффективности и качества процессов	1. Базовые методы измерения эффективности и качества процессов. 2. Требования стандарта ISO-9000:2000. 3. Примеры построения систем измерения показателей процессов.
3	Методы моделирования бизнес-процессов	1. Стандарты моделирования бизнес-процессов (IDEF0, IDEF3, DFD). 2. Моделирование процессов в ARIS. 3. Моделирование процессов при помощи блок-схем. 4. Комплексная методика ведения проекта моделирования бизнес-процессов. 5. Методики анализа и реорганизации бизнес-процессов. 6. Примеры построения моделей бизнес-процессов.
4	Инструментарий моделирования бизнес-процессов (BPWin, ARIS и др)	1. Обзор рынка инструментальных средств моделирования бизнес-процессов. 2. Моделирование процессов в системе BPWin. 3. Моделирование процессов в системе ARIS. 4. Сравнительный анализ эффективности применения различных программных продуктов. 5. Использование инструментальных средств в проекте.

Дальнейшее обучение рабочей группы продолжается при выполнении конкретной работы по проекту, а именно:

· диагностика существующих процессов;

· структуризация дерева целей проекта;

· разработка Технического задания;

· разработка «Методики выполнения проекта»;

· обучение руководителей и сотрудников подразделений.

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

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

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

Структура «Методика» достаточно проста. На следующем рисунке представлены ее основные компоненты.

Рис. 70. Основные компоненты «Методики»

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

Структура методики выполнения проекта реструктуризации бизнес-процессов:

1. Цели проекта.

2. Управление проектом.

3. Структура управления проектом.

4. Описание процесса выполнения работ (основные этапы).

5. График Гантта (основные этапы).

6. Документы, регламентирующие управление проектом.

7. Порядок взаимодействия сотрудников в проекте.

8. Порядок формирования/расформирования рабочих групп.

9. Описание этапов выполнения проекта.

10. Этап 1. Подготовка проекта.

11. Этап 2. Формирование моделей бизнес-процессов.

12. Этап 3. Анализ процессов. Разработка регламентирующих документов.

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

14. Глоссарий проекта.

15. Приложение № 1. Корпоративный стандарт «Шаблон «Регламента описания бизнес-процесса».

16. Приложение № 2. Корпоративные стандарты. Формы документов.

17. Приложение № 3. Формы отчетных документов рабочей группы.

18. Приложение № 4. Положение о рабочей группе.

Описание состава и последовательности работ (процесса) и ответственных может приводиться в различном формате:

· табличное представление;

· представление в виде сетевого графика;

· текстовое представление в виде календарного графика выполнения работ.

Дополнительно к описанию состава и последовательности работ используется представление в виде графиков Гантта, поскольку они удобны для детального описания выполняемых работ в заданном масштабе времени (например, неделя).

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

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

Одно из приложений «Методики» называется «Регламент описания бизнес-процесса». Именно этот документ является основой внутрикорпоративного стандарта описания. Этот документ служит для достижения нескольких целей:

· дает определение бизнес-процесса;

· регламентирует параметры процесса, по которым он идентифицируется в организации;

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

· регламентирует порядок управления бизнес-процессом;

· регламентирует порядок улучшения бизнес-процесса;

· дает ссылки на другие документы, необходимые для регламентации работ по процессу (положения, инструкции, методики).

Пример шаблона «Регламента бизнес-процесса» приведен в приложении к данной теме. В курсе «Управление качеством» данной программы дистанционного обучения тоже приведен шаблон описания процесса, но он сделан с учетом выполнения требований к процессу со стороны стандарта МС ИСО 9001:2000, поэтому его содержание отличается от данного шаблона, который предназначен для управления бизнес-процессом. Данный шаблон носит более простой характер.

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

При разработке «Методики» рабочая группа должно определить наиболее подходящее средство описания бизнес-процесса в виде схем какого-либо вида. В зависимости от целей проекта могут использоваться различные нотации: IDEF, DFD, ARIS, блок-схемы и т.д. Если проект предполагает описания процессов сверху вниз, то целесообразно использовать несколько нотаций для разработки схем процессов. Вполне возможен вариант, когда рабочая группа разрабатывает собственную нотацию описания процесса, базируясь на знании существующих мировых стандартов и лучшего практического опыта.

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

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

Ошибки выполнения подготовительного этапа проекта.

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

· неадекватное участие руководства в проекте;

· плохо проработанные цели и техническое задание;

· некорректно сформированная рабочая группа;

· плохо проработанная «Методика ведения проекта»;

· некачественно проведенное обучение сотрудников;

· неадекватное освещение проекта среди сотрудников организации.

Все указанные выше ошибки приводят к следующей ситуации. Работу по проекту будет выполнять рабочая группа, состоящая из второстепенных, неквалифицированных, имеющих незначительный практический опыт сотрудников. Эта группа не будет иметь четких целей, и не будет понимать, куда двигаться. Руководство компании не будет оказывать поддержку рабочей группе. Отсутствие методик приведет к многократной переделке схем процессов без значительных улучшений. Сотрудники компании будут оказывать скрытое сопротивление деятельности рабочей группы и т.д. В результате, через 2-3 месяца работы руководство получит комплект моделей, который не сможет прочитать. Попытки анализа информации вызовут у руководства сильное раздражение. Итогом станет прекращение проекта и, возможно, увольнение части сотрудников, входивших в рабочую группу. Что бы избежать такого печального хода событий, следует максимально привлекать руководство к участию в проекте, готовить качественные методические материалы, привлекать к проекту лучших людей организации и т.д.

Вопрос 2. Методология «полного» описания бизнес-процессов.

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

Шаг 1. Определить внешних клиентов организации (окружения) и входы/выходы для организации в целом.

Рис. 71. Шаг 1. Определение окружения организации и внешних входов/выходов

При выполнении первого шага рассматривается организация в целом и ее окружение. Определяются внешние входы и выходы. Результатом работ является спецификация входов/выходов и окружения организации. Важно отметить, что входы/выходы должны быть указаны в спецификации на верхнем уровне. Например, было бы неправильно включать в спецификацию такие позиции, как «накладная», «готовое изделие А» и т.п. Нужно включать агрегированные позиции: «документы на отгрузку», «готовые изделия» и т.п.

Шаг 2. Привязать полученные входы/выходы к подразделениям организации.

Рис. 72. Шаг 2. Привязка полученных входов/выходов к подразделениям организации

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

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

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

Шаг 3. Определить внутренние входы/выходы для каждого подразделения организации.

Рис. 73. Шаг 3. Определение внутренних входов/выходов для каждого подразделения

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

Шаг 4. Определить перечень функций, выполняемых в каждом подразделении.

Рис. 74. Шаг 4. Определение перечня функций, выполняемых в подразделении

На четвертом шаге рассматривается деятельность каждого подразделения в отдельности. Более четко определяются границы подразделений.

Для каждого подразделения формируется перечень выполняемых в нем функций. Именно на этом этапе начинает сказываться элемент субъективности. Как правило, реально выполняемые в подразделениях функции, отражены в формальных документах лишь на 30-40%. Дело в том, что положения о подразделениях, инструкции и другие документы редко пересматриваются и не являются актуальными. Такое положение обусловлено в первую очередь отношением руководства компании к регламентирующей документации и отсутствием системы работы с документацией.

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

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

Рис. 75. Шаг 5. Группировка функций подразделения по процессам

При выполнении шага 5, функции каждого подразделения группируются по бизнес-процессам, формирующим выходы подразделения. Каждая функция подразделения должна быть отнесена хотя бы к одному такому бизнес-процессу. При разделении часть функций войдет в «сквозные» бизнес-процессы организации, т.е. процессы, проходящие через границы функциональных подразделений, как показано на рисунке 76. Другая часть функций может войти во вспомогательные процессы. Некоторую часть функций, вероятно, затруднительно будет отнести к какому-либо процессу верхнего уровня. При внимательном рассмотрении, такие функции могут оказаться внутренними функциями подразделения. Среди них могут быть и такие, которые не нужны ни подразделению, ни организации в целом и подлежат устранению.

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

Результатом работы на шаге 5 является четкое понимание деятельности подразделений за счет ее структуризации по бизнес-процессам. Обратим внимание, что субъективность выделения бизнес-процессов уровня подразделения на основе его выходов и выполняемых функций является минимальной.

Шаг 6. Используя входы/выходы между подразделениями сгруппировать бизнес-процессы подразделений в бизнес-процессы организации.

Рис. 76. Шаг 6. Формирование бизнес-процессов организации из бизнес-процессов подразделений

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

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

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

Рис. 77. «Объемные» бизнес-процессы

Шаг 7. Сформировать матрицы ответственности по каждому подразделению. На основе этих матриц составить матрицы ответственности бизнес-процессов организации.

Рис. 78. Шаг 7. Формирование матриц ответственности по бизнес-процессам

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

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

Резюме.

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

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

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

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

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

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

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

· Для ведения проекта по реструктуризации среди сотрудников организации должно быть некоторое количество людей, занимающих активную позицию и готовых к переменам. Размер «критической массы» в изменяемом объекте (организации или процессе) не должен быть меньше 25-30% от численности сотрудников всего объекта.

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

4. Участие первого лица в проекте заключается в:

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

· участии в постановочных совещаниях рабочей группы;

· оперативном анализе разрабатываемых материалов;

· оперативном контроле деятельности руководителей подразделений и рабочей группы;

· поэтапном контроле выполнения проекта;

· анализе и перераспределении функций подразделений, ответственности и полномочий руководителей, ресурсов на основе результатов проекта;

· обеспечении рабочей группы необходимыми ресурсами.

5. К участникам рабочей группы предъявляются следующие требования:

· желание работать в проекте и улучшать деятельность организации;

· опыт работы в организации не менее 3-х лет;

· знание и понимание задач своего подразделения и выполняемых функций;

· знания и навыки в области менеджмента организаций;

· авторитет в коллективе, высокая «ценность» сотрудника для подразделения;

· возможность быстрого обучения, возможность творческой работы;

· коммуникабельность;

· инициативность;

· навыки работы с персональным компьютером.

6. «Регламент описания бизнес-процесса» служит для достижения нескольких целей:

· дает определение бизнес-процесса;

· регламентирует параметры процесса, по которым он идентифицируется в организации;

· регламентирует порядок управления бизнес-процессом;

· регламентирует порядок улучшения бизнес-процесса;

7. Последовательность описания бизнес-процессов:

· Шаг 1. Определить внешних клиентов организации (окружения) и входы/выходы для организации в целом.

· Шаг 2. Привязать полученные входы/выходы к подразделениям организации.

· Шаг 3. Определить внутренние входы/выходы для каждого подразделения организации.

· Шаг 4. Определить перечень функций, выполняемых в каждом подразделении.

· Шаг 5. Для каждого подразделения сгруппировать функции по процессам, формирующим выходы. Привязать к этим процессам входы.

· Шаг 6. Используя входы/выходы между подразделениями сгруппировать бизнес-процессы подразделений в бизнес-процессы организации.

· Шаг 7. Сформировать матрицы ответственности по каждому подразделению. На основе этих матриц составить матрицы ответственности бизнес-процессов организации.

Литература

1. EN ISO 9000:2000 Системы менеджмента качества – Основные положения и словарь.

2. EN ISO 9001:2000 Системы менеджмента качества- Требования.

3. PMBOK-2000 (Project Management Body of Knowledge).

4. ГОСТ Р50.1.028-2001 Методология функционального моделирования IDEF/0.

5. М. Робсон, Ф. Уллах. Практическое руководство по реинжинирингу бизнес-процессов. - М.: Аудит, 1997.

Тема 9. Технология описания составных частей бизнес-процессов

Цели обучения:

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

Содержание темы:

1. Введение.

2. Описание входов/выходов и поставщиков/потребителей процесса.

3. Описание ресурсов процесса.

4. Описание деятельности руководства процесса.

5. Описание контрольных точек процесса.

6. Описание возможных отклонений в ходе процесса.

7. Описание показателей процесса.

8. Описание регламентирующих документов процесса.

9. Описание участия руководителя в управлении процессом.

10. Резюме.

Введение.

При внедрении процессного подхода к управлению необходимо описать существующие процессы с целью создания регламентирующих документов (например "Описание процесса", "Регламент выполнения процесса"). Должна быть разработана Методика описания процессов, которая определяет порядок и технические средства описания. Следует отметить, что не обязательно пытаться отобразить всю информацию по процессу на его графической схеме. Необходимо заранее определить, какая информация будет представлена графически, а какая – при помощи таблиц и текста. При использовании относительно простых программных продуктов (например, при использовании MS Word или Visio для формирования графических схем) большая часть информации о процессе будет представлена в виде таблиц и текста, а при использовании сложных продуктов (ARIS Toolset) большую часть информации можно занести в базу данных моделей процессов.

В качестве технического средства описания потоков работ может быть, например, использован ARIS Toolset и нотация ARIS eEPC. Мы рассматриваем ARIS Toolset, так как этот продукт получил в настоящее время достаточно широкое распространение в России. Аналогичные рассуждения могут быть сделаны относительно особенностей применения любых других продуктов моделирования бизнес-процессов, использующих методики описания процессов класса Work Flow.

Ниже приводятся требования к моделям ARIS eEPC, сформулированные с учетом требований процессного подхода к управлению. Аналогичные требования можно предложить при использовании IDEF0 и IDFE3.

Модель процесса должна, по крайней мере, включать следующую информацию:

· входы/поставщики процесса (process interface, document, technical term);

· выходы/клиенты процесса (process interface, document, technical term);

· ресурсы: персонал, оборудование, информация, среда (organization unit, application system и т.п.);

· технология выполнения процесса (event, function, operators);

· все этапы цикла управления (планирование, выполнение, контроль, анализ, принятие решений);

· контрольные точки для измерения показателей;

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

· показатели процесса, продукта и данные удовлетворенности клиентов;

· участие руководителя (управление процессом).

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

Вопрос 1. Описание входов/выходов и поставщиков/потребителей процесса.

Описание входов/выходов и поставщиков/потребителей процесса.

Рис. 79. Фрагмент модели в ARIS eEPC. Описание входов/выходов процесса

На рисунке 79 показан фрагмент модели процесса в нотации ARIS eEPC. Овалами обведены: интерфейс-«Процесс-поставщик 1» и вход-«Документ». Вторым входом в процесс является «Материал». Поставщиком рассматриваемого процесса является также «Процесс-поставщик-2». Клиентом процесса является «Процесс-клиент», который получает результат выполнения процесса в виде документа. Таким образом, на модели бизнес-процесса отображены поставщики/входы и клиенты/выходы. Это исключительно важно, так как позволяет четко описать границы бизнес-процесса.

Принципы согласование входов и выходов процесса.

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

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

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

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

Владелец процесса в ходе согласования должен однозначно описать спецификацию на вход (выход или ресурс) или дать ссылку на документ, где эта спецификация описана однозначным образом. При необходимости, можно ввести дополнительные требования по количественным, качественным или временным требованиям предоставления данного входа (выхода или ресурса). Способы формализации данного согласования могут быть выбраны различные. На рисунке 80 изображен пример формализации взаимодействия между процессами (подразделениями). На рисунке изображено прослеживание и взаимное согласование входа Процесса А, который получает от Процесса Б документ по форме Ф 01.02.45. В свою очередь Процесс А передает Процессу В документ по форме Ф 09.12.11. После взаимного согласования и утверждения регламентов Процессов А, Б и В, у владельцев этих процессов не должно возникать проблем и вопросов по взаимодействию.

Рис. 80. Согласование входов и выходов между процессами

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

При описании процесса необходимо четко и однозначно определить:

1. Что является результатом процесса – выходом процесса?

2. Кто является ответственным за результат процесса?

3. Что является входом процесса?

4. Кто является поставщиком каждого из входов процесса?

5. Кто является субподрядчиком при выполнении процесса?

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

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

Рис. 81. Иллюстрация согласования процессов между собой

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

Ситуация 2. Один и тот же результат деятельности процесса (выход) может одновременно, или по каким то правилам, поступать на различные входы различных процессов. Так выход 3.3 поступает на вход 5.2 процесса 5 и вход 6.5 процесса 6. В этом случае для описываемого процесса 3 должны быть установлены определенные правила, по которым производится распределение и передача выхода процессам-потребителям. Наличие таких правил приобретает особую актуальность в условиях регламентирования вспомогательных процессов организации, так как минимизирует борьбу за ресурсы между руководителями (владельцами процессов).

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

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

Сколько входов (выходов) должен иметь процесс, если наш процесс получает от других процессов (передает другим процессам) несколько десятков видов продуктов (документов)?

Ответ на этот вопрос тоже придется искать в области действия понятий экономическая целесообразность и здравый смысл. То есть, придется установить для своей организации не только соглашение о правилах декомпозиции процессов и агрегирования функций, но и аналогичные правила для декомпозиции и агрегирования входов. Рекомендуется: для обозначения конкретных видов документов (товаров, продуктов) использовать термин «продукт». Использование этого термина связано также с тем, что в системах управления организациями существуют списки (перечни) продуктов (товаров), которые используются для учета и планирования материальных потоков. Аналогичные перечни создаются (или используются) при внедрении программных продуктов класса ERP (MRP II). Для обозначения группы товаров или продуктов рекомендуется использовать обобщенное название «вход» («выход»).

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

Возвращаясь к рисунку 81 можно отметить, что вход 3.1 является агрегированным названием входа, в по которому в процесс 3 от процесса 1 поступает три различных продукта А, Б и В.

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

Вопрос 2. Описание ресурсов процесса.

Рис. 82. Фрагмент модели в ARIS eEPC. Описание ресурсов процесса

На рисунке 82 показаны ресурсы, используемые при выполнении процесса: программное обеспечение и структурные подразделения (персонал). На рисунке 82 они обведены овалом.

Вопрос 3. Описание деятельности руководства процесса.

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

Рис. 83. Составляющие элементы модели бизнес-процесса

Первый вариант содержит пять необходимых элементов любого процесса:

· планирование деятельности;

· выполнение деятельности;

· контроль деятельности;

· анализ деятельности;

· принятие решений.

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

· планирование деятельности;

· контроль деятельности руководителем;

· анализ деятельности руководителем;

· принятие решений.

Вопрос 4. Описание контрольных точек процесса.

На следующем рисунке 84 приводится пример отображения на модели контрольной точки процесса. В данном примере, при выполнении «Работы 1» исполнитель фиксирует в «Журнале учет №…» некоторые показатели. Форма регистрации информации может быть различной: бумажной (журналы) и электронной (файлы, базы данных, прикладные системы). На модели важно показать, на каком этапе процесса необходимо фиксировать информацию для последующей ее обработки и анализа с целью последующего улучшения процесса.

Рис. 84. Фрагмент модели в ARIS eEPC. Описание контрольных точек процесса

Вопрос 5. Описание возможных отклонений в ходе процесса.

Модель процесса должна отображать не только нормальный ход процесса, но и возможные отклонения. Так на рисунке 85 показано отклонение от нормального хода процесса, которое может случиться после выполнения «Работы 1». В этом случае выполняется ветка процесса под названием «Действие в случае отклонения». Конечно, все отклонения в модели процесса отобразить невозможно, но это и не требуется. Необходимо в первую очередь описывать наиболее существенные отклонения, которые могут в значительной степени повлиять на процесс, либо сделать его последующее нормальное выполнение невозможным. Следует отметить, что по мере совершенствования процесса перечень возможных существенных отклонений будет меняться, что потребует своевременного пересмотра моделей и регламентирующей документации. Заметим, что отклонения от нормального хода процесса можно описывать при помощи текста, не отображая на графической схеме.

Рис. 85. Фрагмент модели в ARIS eEPC. Описание отклонений от нормального хода процесса

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

Рис. 86. Фрагмент модели в ARIS eEPC. Описание действий с несоответствующей продукцией бизнес-процесса

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

Вопрос 6. Описание показателей процесса.

Согласно методике процессного управления, для каждого бизнес-процесса должны быть определены показатели эффективности процесса, показатели продукта и данные удовлетворенности клиентов (ДУК клиента). Эти показатели могут быть отображены на модели бизнес-процесса, как показано на рисунке 87. Указанные показатели привязаны к конкретным работам. Результирующие показатели («Показатель процесса», «Показатель Выхода 1») условно привязаны к последней работе процесса.

Рис. 87. Фрагмент модели в ARIS eEPC. Описание действий в случаях отклонений от нормального хода процесса

Отметим, что отображать показатели на модели не обязательно. Это вполне можно сделать при документировании процесса в текстовом или табличном формате.

Вопрос 7. Описание регламентирующих документов процесса.

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

Рис. 88. Фрагмент модели в ARIS eEPC. Описание регламентирующих документов

Вопрос 8. Описание участия руководителя в управлении процессом.

На рисунке 89 показана связь модели, описывающей деятельность сотрудников, с моделью деятельности руководителя. Представим себе, что при выполнении процесса возникали некоторые отклонения, которые были зафиксированы в «Журнале учета…». По итогам работы в течение месяца, владелец процесса (руководитель) анализирует возникшее отклонение, используя информацию о соответствующих показателях из журнала учета, либо сводные данные, предоставленные сотрудниками. Руководитель выявляет причину отклонения и оценивает возможный ущерб для организации (процесса) в случае, если отклонение не будет устранено. Затем руководитель разрабатывает корректирующие мероприятия и оценивает их экономическую эффективность. Если величина возможного ущерба превышает стоимость корректирующих мероприятий, руководитель организовывает выполнение корректирующих мероприятий (назначает ответственных исполнителей).

Рис. 89. Связь моделей деятельности руководителя и сотрудника

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

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

Резюме.

1. Модель процесса должна включать следующую информацию:

· входы/поставщики процесса;

· выходы/клиенты процесса;

· ресурсы: персонал, оборудование, информация, среда;

· технология выполнения процесса;

· все этапы цикла управления;

· контрольные точки для измерения показателей;

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

· показатели процесса, продукта и данные удовлетворенности клиентов;

· участие руководителя (управление процессом).

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

3. При описании процесса необходимо четко и однозначно определить:

· Что является результатом процесса – выходом процесса?

· Кто является ответственным за результат процесса?

· Что является входом процесса?

· Кто является поставщиком каждого из входов процесса?

· Кто является субподрядчиком при выполнении процесса?

4. Для того чтобы ответить на вопрос: Сколько входов (выходов) должен иметь процесс, если наш процесс получает от других процессов (передает другим процессам) несколько десятков видов продуктов (документов)? необходимо установить:

· соглашение о правилах декомпозиции процессов и агрегирования функций;

· правила для декомпозиции и агрегирования входов.

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

· планирование деятельности;

· контроль деятельности руководителем;

· анализ деятельности руководителем;

· принятие решений.

6. Два основных принципа, которыми необходимо руководствоваться при описании бизнес-процессов:

· принцип «здравого смысла»;

· принцип экономической целесообразности.

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

Приложение.

PDF-документ: Шаблон Регламента бизнес-процесса

Литература

1. Елиферов В.Г., Репин В.В, Бизнес-процессы. Регламентация и управление. – (учебник для программы МВА) М.: «Инфра-М», 2004 г.

2. А. Шматалюк и др. Моделирование бизнеса. Методология ARIS. Практическое руководство. Москва: "Серебряные нити", 2001 г.

3. Август-Вильгельм Шеер, Бизнес-процессы: основные понятия, теории, методы, Москва: Просветитель, 1999.

Тема 10. Техника реструктуризации бизнес-процессов

Цели обучения:

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

Содержание темы:

1. Введение.

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

3. «Вредные советы» от М. Хаммера и Дж. Чампи.

4. Резюме.

Введение.

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

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

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

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

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

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

· делегирование полномочий руководителей сотрудникам, выполняющим процесс;

· перераспределение функций между процессами;

· кардинальное перепроектирование процессов.

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

Вопрос 1. Примеры проведения реструктуризации.

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

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

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

Рис. 90. «Однажды в подразделении. Работа руководителя»

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

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

Рис. 91. Владелец процесса, как рядовой исполнитель, наделенный правом принятия решения

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

Рис. 92. Шаг 1. Исключаем функции владельца процесса из процесса

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

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

Рис. 93. Шаг 2. Делегирование полномочий вниз

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

Перераспределение работ и функций между процессами.

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

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

Рис. 94. Исходная ситуация для перераспределения функций между процессами

Прежде всего, необходимо выполнить анализ деятельности (см. рисунок 95). Следует выполнить анализ возможности и целесообразности выполнения функции «Х» в процессе «А»:

· наличие в процессе «А» ресурсов, необходимых для выполнения функции «Х»;

· квалификация персонала, требуемая для выполнения функции «Х»;

· экономическое обоснование целесообразности выполнения функции «Х» в процессе «А» (сокращение времени выполнения процесса, снижение затрат, сокращение числа несоответствий и т.п.).

Следует так же проанализировать, как выполняется функция «Х» в процессе «Б»:

· анализ выполнения функции «Х» (сложность технологии, степень специализации персонала, потребность в ресурсах, юридические аспекты);

· степень загрузки функции «Х» (% времени) по созданию продуктов для процесса «А» (необходимо выяснить, создает ли функция «Х» продукты/услуги для других клиентов, кроме продуктов для процесса «А»);

· экономический анализ целесообразности выполнения функции «Х» в процессе «Б».

Целесообразно, чтобы анализ проводился совместно владельцем процесса «А» и владельцем процесса «Б».

Анализ выполнения функции «Х» и взаимодействия процессов «А» и «Б» позволяет сделать вывод о целесообразности передачи функции «Х» в процесс «А». Возможно несколько вариантов реорганизации. Некоторые их них представлены ниже.

Рис. 95. Анализ процесса

На рисунке 96 показан первый вариант возможной реорганизации. Если анализ показывает, что функцию «Х» целесообразно оставить в процессе «Б» (например, для выполнения функции «Х» требуется специальное оборудование, сложная технология и узкоспециализированный персонал), то необходимо более четко регламентировать взаимодействие между процессами «А» и «Б». Для этого определяется формы, сроки передачи документов (продуктов), ответственные лица. Далее согласованная информация заносится в регламент выполнения процесса «А» и в регламент выполнения процесса «Б». Кроме того, в процессах должны быть установлены контрольные точки (места для сбора информации), необходимые для анализа информации об отклонениях.

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

Рис. 96. Регламентация взаимодействия

Вторым вариантом реорганизации является передача функции «Х» из процесса «Б» в процесс «А». Такая передача может быть осуществлена только после проведения тщательного анализа целесообразности (в т.ч. при помощи экономических оценок). Например, если функция «Х» не требует для своего выполнения существенных ресурсов, узкоспециализированных специалистов и в процентном отношении на 100% выполняется для процесса «А», то, вероятно, ее целесообразно передать в процесс «А», как показано на рисунке 97.

Рис. 97. Передача функций в процесс.

Третьим вариантом реорганизации является создание в рамках процесса «А» новой функции «Х» (см. рисунок 98). В качестве примера можно привести ситуацию, когда функция «Х» не требует для своего выполнения существенных ресурсов, узкоспециализированных специалистов, но в процентном отношении «работает на» процесс «А» лишь частично (не 100% времени). Целесообразность создания в процессе «А» функции «Х», дублирующей аналогичную функцию в процессе «Б», должна быть обоснована экономическим расчетом.

В качестве примера можно привести случай, когда выполнение функции «Х» в процессе «Б» и транспортировка результатов ее выполнения из процесса «Б» в процесс «А» дороже, чем выполнение функции «Х» в процессе «А».

Рис. 98 Организация новой функции в процессе «А»

Вопрос 2. «Вредные советы» от М. Хаммера и Дж. Чампи.

Одной из лучших и основополагающих книг в области реструктуризации (реинжиниринга) бизнес-процессов, является книга М. Хаммер, Дж. Чампи «Реинжиниринг корпорации. Манифест революции в бизнесе» (СПб.: Изд.СПб университета, 1997). Книга написана ярким, сочным языком с большим количеством практических примеров реинжиниринга. Авторы прямо указывают, что: «Рецептов реинжиниринга, которые гарантировали бы желаемый результат, не существует».

Однако авторы на основе анализа проведенных реинжиниринговых проектов выделили некоторые закономерности, которые и представлены читателю в сокращенном виде:

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

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

1. Попытайтесь «отладить» процесс вместо того, чтобы его изменить.

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

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

2. Не сосредоточивайте внимание на бизнес-процессах.

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

3. Игнорируйте все, кроме перепроектирования процессов.

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

Даже менеджеры, которые заинтересованы в радикальном перепроектировании процесса, часто испытывают страх перед лицом всеобъемлющих изменений, которых требуют подобные преобразования. Мы часто сталкиваемся со следующим сценарием: менеджер высшего звена дает задание реинжиниринговой команде добиться кардинального улучшения функционирования процессов, вызывающих беспокойство у руководства. Через некоторое время команда вновь собирается, описывает менеджеру концепцию кардинальных преобразований и объясняет, как она сократит на 90% время производственного цикла, на 95% издержки и на 99% брак. Менеджер подпрыгивает от восторга. Затем команда старается объяснить, что перепроектированный процесс потребует новой системы оценки работ, объединения усилий многочисленных подразделений, переосмысления полномочий руководства и иного стиля трудовых отношений. Менеджер высшего звена опять подпрыгивает, но на этот раз не от восторга. «Я просил вас снизить издержки и брак, — говорит он, — но не просил перестраивать компанию». Команда после этого обычно распускается, и о ее концепции кардинальных изменений больше ничего не слышно. Но перестройка компании как раз и составляет содержание реинжиниринга.

4. Пренебрегайте ценностями и убеждениями людей.

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

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

5. Старайтесь довольствоваться незначительными результатами.

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

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

6. Прекращайте изменения как можно раньше.

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

7. Заранее сужайте проблемы и ограничивайте масштаб реинжиниринговых мероприятий.

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

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

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

8. Позвольте существующей корпоративной культуре и стилю руководства предотвратить реинжиниринг.

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

9. Попытайтесь осуществить реинжиниринг «снизу вверх».

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

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

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

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

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

11. Урежьте ресурсы, выделенные на реинжиниринг.

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

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

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

12. Похороните реинжиниринг среди приоритетов корпорации.

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

13. Рассредоточьте энергию по многочисленным реинжиниринговым проектам.

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

14. Сумейте не отличить реинжиниринг от других программ усовершенствования бизнеса компании.

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

15. Сконцентрируйте внимание исключительно на перепроектировании.

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

16. Постарайтесь осуществить реинжиниринг безболезненно для всех.

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

17. Отступайте, когда люди сопротивляются изменениям, порожденным реинжинирингом.

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

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

18. Растягивайте реинжиниринговые мероприятия.

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

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

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

Резюме.

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

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

3. Изменения процессов могут быть следующего вида:

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

· перераспределение функций между процессами;

· согласование процессов по входам/выходам.

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

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

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

· Аналогичная функция создается в двух процессах из-за того, что существующая является «узким местом».

6. Рецептов реинжиниринга, которые гарантировали бы желаемый результат, не существует.

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

Кейс.

Разбор практического примера описания и реструктуризации бизнес-процессов в нотации DFD

Рассмотрим пример описания процессов логистики торгово-закупочной компании (ритейл).

1. Исходные данные по компании.

Некая торгово-закупочная компания решила «Описать и оптимизировать бизнес-процессы компании». Общая численность компании составляет около 400 человек. Компания имеет 15 магазинов, ведущих розничную продажу товаров в различных регионах. Структура компании построена по функциональной схеме.

1.1. Управление компанией.

Компанию возглавляет генеральный директор. Высшими органами управления компанией являются Бюджетный комитет и Ассортиментный комитет.

1.2. Состав компании:

· Компания состоит из семи департаментов,

· Департамент маркетинга,

· Коммерческий департамент,

· Департамент логистики,

· Департамент продаж,

· Финансовый департамент,

· Департамент персонала,

· Департамент информационного обеспечения.

1.3. Функции департаментов.

Департамент маркетинга:

1. Управление департаментом (планирование, бюджетирование, управление и отчетность).

2. Проведение маркетинговых исследований рынка и покупателей.

3. Организация и проведение промомероприятий.

4. Проведение ассортиментного и ценового комитета.

Коммерческий департамент:

1. Управление департаментом (планирование, бюджетирование, управление и отчетность).

2. Планирование продаж товаров по категориям.

3. Закупка товаров.

4. Разработка планограмм выкладки товаров.

Департамент логистики:

1. Управление департаментом (планирование, бюджетирование, управление и отчетность)

2. Приемка товаров от поставщика.

3. Входной контроль товаров по качеству и количеству.

5. Перемещение товаров в зону хранения и размещение на полках.

6. Хранение товаров.

7. Распечатка складских требований.

8. Формирование поставок в магазины.

9. Отгрузка товаров в магазины.

10. Доставка товаров в магазины.

11. Организация и оформление возвратов товаров и брака.

12. Оформление накладных на приемку и передачу товаров.

13. Генерация отчетов о товародвижении в учетную систему.

Организационная структура департамента логистики:

· Директор департамента;

· 2 смены кладовщиков с начальниками смен (внутри смены существует специализация, одна бригада принимает и размещает товар, другая – комплектует заявки на отгрузки товаров в магазины);

· Кладовщик склада возврата (Склада СВ);

· Диспетчер по логистике;

· Оператор базы данных.

Департамент продаж:

1. Управление департаментом (планирование, бюджетирование, управление и отчетность).

2. Приемка товаров.

3. Хранение товаров.

4. Выкладка товаров.

5. Продажи товаров.

6. Возврат товаров и брака.

7. Генерация отчетов о продажах в учетную систему.

Финансовый департамент:

1. Управление департаментом (планирование, бюджетирование, управление и отчетность).

2. Бюджетирование.

3. Бухгалтерский и финансовый учет.

4. Составление налоговой отчетности.

5. Финансовое планирование.

6. Финансовый контроллинг.

Департамент персонала:

1. Управление департаментом (планирование, бюджетирование, управление и отчетность).

2. Подбор и подготовка персонала.

3. Ведение кадрового учета.

Департамент информационного обеспечения:

1. Управление департаментом (планирование, бюджетирование, управление и отчетность).

2. Информационное обеспечение деятельности компании.

3. Обеспечение работоспособности связи и оргтехники.

4. Информационная безопасность компании.

2. Схемы бизнес-процессов.

2.1. Необходимые допущения:

1. Деятельность компании первоначально разбита на 8 бизнес-процессов (Рис. 99).

· 1 процесс управления;

· 4 основных процесса (маркетинг, коммерция, логистика, продажи);

· 3 вспомогательных (финансы, персонал, ИТ).

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

3. Взаимодействие процессов с процессом управления тоже прописано в документальном виде, а также в «Положении о бюджетировании» и «Положении об Ассортиментном комитете».

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

5. Диаграммы на Рис. 99 – 102 построены в нотации DFD с помощью программного продукта BPWin 4.0. На диаграммах можно увидеть следующие условные обозначения:

· поток материальных продуктов обозначается полужирными стрелками с двумя наконечниками;

· поток управленческой информации (планы и отчеты) обозначается пунктирными стрелками;

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

· попытка отобразить отчетность департамента логистики перед процессом «Управление компанией» на диаграмме нижнего уровня, привела к появлению туннельной стрелки на диаграммах Рис. 101 и 102.

3. Задание.

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

4. Разбор Кейса.

1. На Рис. 99 изображено взаимодействие основных бизнес-процессов и процесса управления.

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

4.1. Результат анализа и группировки функций департамента логистики по потенциальным владельцам.

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

Директор департамента логистики

1. Управление департаментом (планирование, бюджетирование, управление и отчетность)

Смена кладовщиков (бригада 1)

2. Приемка товаров от поставщика

3. Входной контроль товаров по качеству и количеству

4. Перемещение товаров в зону хранения и размещение на полках

Смена кладовщиков (бригада 2)

5. Хранение товаров

6. Распечатка складских требований

7. Формирование поставок в магазины

8. Отгрузка товаров в магазины

Диспетчер по логистике

9. Организация доставки товаров в магазины

Кладовщик склада СВ

10. Организация и оформление возвратов товаров и брака

Диспетчер базы данных

11. Оформление накладных на приемку и передачу товаров

12. Генерация отчетов о товародвижении в учетную систему

4.2. Выделение бизнес-процессов и подпроцессов в департаменте логистики.

При данной организации работ в департаменте логистики выделены следующие бизнес-процессы и подпроцессы (Рис. 102):

· Бизнес-процесс 1 «Управление логистикой»– директор по логистике;

· Бизнес-процесс 2 «Управление возвратами товаров и брака» – кладовщик склада возвратов

· Подпроцесс «Приемки товаров на склад» – начальник смены;

· Подпроцесс «Комплектации заявок на поставку» – начальник смены;

· Подпроцесс «Доставки товаров в магазины» – диспетчер по логистике.

Комментарии к выделению процессов и подпроцессов:

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

2. Бизнес-процесс 2 «Управление возвратами товаров и брака» - выделен как самостоятельный бизнес-процесс по следующим критериям:

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

· координатором этой деятельности, в соответствие с принятой схемой работы, является кладовщик склада СВ;

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

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

3. Подпроцессы «Приемки товаров на склад», «Комплектации заявок на поставку» и «Доставки товаров в магазины» выделены как отдельные подпроцессы внутри общего бизнес-процесса «Управление логистикой», так как:

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

· участие диспетчера по логистике в бизнес-процессе «Возврат товаров и брака» не является его основной обязанностью, но поскольку административно он, как и кладовщик СВ, подчиняется директору департамента логистики, проблем с их взаимодействием не возникает.

4.3. Проведение реструктуризации выделенных бизнес-процессов.

Поводом для реструктуризации Бизнес-процесса 1 «Управление логистикой» послужили следующие основания:

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

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

3. Территориальная удаленность офиса коммерческого департамента от склада приводила к существенному увеличению времени приемки товара, пришедшего в «проблемной поставке», или, вовсе, отказу склада принимать «проблемную поставку».

4. Логистика ежедневных поставок в магазины тоже требовала оперативного решения вопросов по дозаказу товаров от поставщиков в случаях пикового спроса на некоторые группы товаров.

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

Рис. 99. Выделение основных бизнес-процессов компании

Рис. 100. Группировка функций для коммерческого департамента

Рис. 101. Группировка функций для департамента логистики

Рис. 102. Вариант выделения бизнес-процессов.

Рис. 103. Бизнес-процесс 1 после реструктуризации.

Литература

2. М. Хаммер, Дж. Чампи «Реинжиниринг корпорации. Манифест революции в бизнесе» (СПб.: Изд.СПб университета, 1997).

Глоссарий

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

Примечание: анализ может также включать определение эффективности.

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

Бизнес-процесс - см. Процесс.

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

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

Документ - информация и соответствующий носитель.

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

Примечания:

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

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

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

Информация - значимые данные.

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

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

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

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

Примечания:

1. Распределение обычно бывает упорядоченным.

2. Организация может быть государственной или частной.

Организационная структура - распределение ответственности, полномочий и взаимоотношений между работниками.

Примечания:

1. Распределение обычно бывает упорядоченным.

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

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

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

Показатели продукта (услуги)(ПП) - параметры продукта процесса.

Показатели (данные) удовлетворенности клиента (потребителя) (ДУК) - параметры удовлетворенности клиента.

Поставщик - организация или лицо, предоставляющие продукцию.

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

Примечания:

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

2. В контрактной ситуации поставщика иногда называют "подрядчиком".

Потребитель - организация или лицо, получающие продукцию или услугу.

Примеры: клиент, заказчик, конечный пользователь, розничный торговец, бенефициар и покупатель.

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

Продукция - результат процесса.

Примечания:

1. Имеются четыре общие категории продукции:

- услуги (например перевозки);

- программные средства (например компьютерная программа, словарь);

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

- перерабатываемые материалы (например смазка).

2. Услуга является результатом, по меньшей мере, одного действия, обязательно осуществленного при взаимодействии поставщика и потребителя, она, как правило, нематериальна. Предоставление услуги может включать, к примеру, следующее:

- деятельность, осуществленную на поставленной потребителем материальной продукции (например автомобиль, нуждающийся в ремонте);

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

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

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

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

Примечания:

1. Отдельный проект может быть частью структуры более крупного проекта.

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

3. Выходом проекта может быть одно изделие или несколько единиц продукции.

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

Примечания:

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

2. Для обозначения объекта проектирования и разработки могут применяться определяющие слова (например проектирование и разработка продукции или проектирование и разработка процесса).

Производственная среда - совокупность условий, в которых выполняется работа.

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

Процедура - установленный способ осуществления деятельности или процесса.

Примечания:

1. Процедуры могут быть документированными или недокументированными.

2. Если процедура документирована, часто используется термин "письменная процедура" или "документированная процедура". Документ, содержащий процедуру, может называться "документированная процедура".

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

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

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

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

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

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

Система - совокупность взаимосвязанных и взаимодействующих элементов.

Система менеджмента - система для разработки политики и целей и достижения этих целей.

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

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

Эффективность - связь между достигнутым результатом и использованными ресурсами.