Нотация IDEF0 и еще раз про построение структуры бизнес-процессов компании. (Часть 3)

Бизнес-процессы и системный подход.
October 3, 2014
Бизнес-процессы для начинающей компании. Часть 1.
October 20, 2014
Показать все

Нотация IDEF0 и еще раз про построение структуры бизнес-процессов компании. (Часть 3)

Нотация IDEF0 и еще раз про построение структуры бизнес-процессов компании. (Часть 3)

Начнем с самого верхнего уровня. А именно рассмотрим измененную структуру бизнес-процессов (рисунок 7). Я использовал для этого так называемое дерево процессов – иерархическое представление структуры процессов без описания входов и выходов. Такое представление обладает тем преимуществом, что позволяет «увидеть» все процессы и работы сразу. В специальных программах такое представление можно получить автоматически, но с таким же успехом его можно составить и вручную, например, в MS Visio. Далее мы еще увидим, как эти изменения выглядят в нотации IDEF0.

 

i7

Рисунок 7. Измененная ветка бизнес-процессов.

 

i8

Рисунок 8. Первоначальная ветка бизнес-процессов.

Как видно, в первоначальной версии работа «Собирать и отгружать товар» (Рисунок 8) была декомпозирована на 6 работ.

Также в рамках  одной диаграммы у нас оказались вместе работы трех типов:

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

Поэтому в исправленном варианте мы разделили работы по описанным выше типам и добавили еще один уровень декомпозиции.  Теперь работа «Собирать и отгружать товар» (Рисунок 7) декомпозирована только на 3 работы, но две из них имеют еще один уровень декомпозиции.

Кроме того изменили наименование, а также содержание и выходы, работ:

  • «Отчитываться о выполнении заявок» на «Анализировать и контролировать работу склада»
  • «Принимать и обрабатывать доставки» на «Принимать и обрабатывать заявки клиентов».

Так как такие наименования более соответствуют новому содержанию данных работ, что будет видно в дальнейшем из рисунка 12.

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

 

risunok_9_novyy_razmer_1

Рисунок 9. Исправленная диаграмма декомпозиции работы «Собирать и отгружать товар».

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

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

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

К сожалению, на диаграммах в нотации не видно, кто именно является получателем выхода (или аналогично поставщиком входа) за пределами текущей диаграммы. Чтобы уточнить это необходимо смотреть диаграммы более высокого уровня, а для такого случая как наш, когда мы строим схему не схему процессов всей компании, а одной ветки, то и контекстная диаграмма этого не подскажет. Для выхода из этой ситуации можно воспользоваться отдельным цветом стрелок (хотя чтобы разделить внутренних и внешних получателей/поставщиков) и указывать получателя в названии стрелки, кроме того можно указать эту информации в свойствах объектах, но на схеме это видно не будет. Однако, в специальных программных продуктах вроде ERWin или Business Studio есть справочник стрелок (входов и выходов), и эту информацию можно вывести в табличном виде. Вообще настоятельно  рекомендуется заполнять советующие поля описаний стрелок для тех будет в дальнейшем работать со схемой. Кроме того, эту и многую другую информацию можно хранить в матрице бизнес-процессов – это таблица, в которой указывается информация о процессах: наименование, владелец, цель процесса, входы и выходы, поставщики и получатели, показатели процесса и т.д. Такая таблица хорошо дополняет графическую схему, я приведу ее пример в конце статьи.

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

 

risunok_10_novyy_razmer_1

Рисунок 10. Диаграмма декомпозиции работы «Управлять комплектование и отгрузками».

На диаграмме теперь две работы, ранее это было одна недекомпозированнная работа:

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

 

risunok_11_novyy_razmer_1

Рисунок 11. Диаграмма декомпозиции работы «Осуществлять КиО»

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

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

К примеру, процесс верхнего уровня называется «Делать X» (продавать, производить и т.д.). Далее он декомпозируется на подпроцессы по содержанию деятельности: управлять деятельностью, непосредственно осуществлять деятельность, обеспечивать деятельность и т.д. А уже потом, при необходимости, каждый из этих подпроцессов может быть также разложен на структуры. Например, по этапам работ и/или видам работ. Так, на производстве могут разные этапы обработки сырья или параллельные производственные циклы.

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

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

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

risunok_12_novyy_razmer

Рисунок 12. Исправленная диаграмма декомпозиции работы «Выполнять заявки клиентов по доставке товара».

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

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

Еще раз о том, зачем нужна нотация IDEF0.

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

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

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

© Сагалович Александр.Минск. Октябрь 2014.

Добавить комментарий