Если автоматизировать бардак, получится автоматизированный бардак. Обнаружить изъяны бизнес-процессов помогает графическая нотация IDEF0.
Что такое IDEF0
Это методология и графическая нотация для описания бизнес-процессов. То есть это некий стандарт, в котором говорится как графически изображать бизнес-процессы. На мой взгляд - это одна из самых читаемых и понятных нотаций для бизнес-процессов.
Сначала мы поговорим о том, как рисовать IDEF0 диаграммы, а потом, как с помощью них анализировать процессы.
Полезные правила
Как и в любом стандарте присутствуют некие правила. Предлагаю разобраться в них по порядку на примере процесса приготовления бургера. На просторах интернета я нашел рецепт, который представлен ниже.
Рецепт бургера
Необходимые продукты:
Булочки для бургера - 3 шт.
Фарш мясной - 400 г
Сыр твердый - 30-50 г
Помидор - 1-2 шт.
Огурец соленый - 1 шт.
Лук синий (фиолетовый) - 1 шт.
Салатные (капустные) листья - 5-6 шт.
Майонез - 2 ч. л.
Кетчуп (любой) - 2 ч. л.
Перец черный - по вкусу
Соль - по вкусу
Масло подсолнечное - для жарки
Сам рецепт:
1. Подготавливаем необходимые ингредиенты для бургера.
2. В мясной фарш добавляем соль и перец по вкусу, хорошо вымешиваем. Формируем шарик, расплющиваем его в руках, чтобы получилась плоская котлета. Надавливаем большим пальцем в центр котлеты, чтобы она не вздулась во время обжаривания.
3. Обжариваем котлету 4-5 минут с каждой стороны. На готовую котлету кладем тонкий кусочек сыра.
4. Помидоры нарезаем кружочками, твердый сыр - тонкими пластинами, соленый огурец - тонкими кружочками. В отдельной емкости смешиваем майонез и кетчуп.
5. Булочку разрезаем пополам и смазываем соусом из майонеза и кетчупа.
6. Выкладываем на соус порванный руками листья салата (капусты).
7. На салат кладем нарезанный тонкими колечками лук.
8. На лук выкладываем кружочек помидора.
9. На кружочек помидора выкладываем котлету.
10. На котлету выкладываем пару ломтиков соленого огурца и ломтик сыра.
11. Накрываем бургер второй частью булочки. По такому же принципу формируем остальные бургеры.
Контекстная диаграмма
В IDEF0 всё начинается с контекстной диаграммы.
Контекстная диаграмма обозначается как A-0. Эта диаграмма позволяет определить границы моделирования. На ней есть всего один блок, он же действие, он же активность. В стандарте IDEF0 блоки принято называть глаголами. Это требование поможет вам не допускать ошибок, а так же добавляет читаемости к диаграмме. Блок и стрелки на контекстной диаграмме определяет связи процесса с внешним миром.
Стрелки, которые приходят к блоку слева - всегда входы в процесс. Это необходимые для передела ресурсы (объекты переменных затрат). То есть, если для приготовления бургера мы "потратим" булочку, то булочка - это вход.
Стрелки, которые приходят к блоку снизу называются механизмами. Это то, без чего процесс не может работать, например, персонал, инструменты, станки и так далее.
Стрелки, приходящие сверху - стрелки управления. Они определяют способы, условия и ограничения выполнения процесса.
Единственная выходящая стрелка из блока - стрелка справа. И это выход. То есть то, что получается в результате работы процесса. Как видно из нашей контекстной диаграммы - это далеко не всегда только основной результат процесса. В нашем случае мы испачкали нож и сковороду и вероятно где-то за границами этого процесса мы их помоем, тем не менее это тоже результат приготовления бургера.
Стрелки принято называть существительными.
Таким образом на контекстной диаграмме мы видим все ресурсы, необходимые процессу.
Декомпозиция первого уровня
Из контекстной диаграммы создаются диаграммы декомпозиции. То есть контекстная диаграмма уточняется и расписывается более подробно. Существует правило, что на диаграмме должно быть не более семи действий (блоков). Как правило семь - это уже много и диаграмма сложно читается. В нашем случае действий будет три.
Блоки на диаграммах располагаются не в порядке последовательности процесса, а в порядке доминирования действий. То есть, чем более важна эта часть процесса, тем выше она располагается. Тем не менее очень часто доминирование совпадает с последовательностью.
Я разделил процесс "Приготовить бургер" на три действия - подготовить ингредиенты, приготовить котлету, собрать бургер. То есть мы видим более подробное описание действия контекстной диаграммы.
Пока я делал диаграмму декомпозиции я обнаружил ошибки, допущенные на контекстной диаграмме. Например, мы передаём в процесс соль, но мы не можем передать в процесс щепотку соли, это будет соломка с солью. То есть соль останется и соответственно будет на выходе процесса. Тоже самое с перцем и маслом для жарки. Кроме того, для нарезки овощей кроме ножа потребуется доска.
Это абсолютно нормальная ситуация, на этапе контекстной диаграммы очень трудно предусмотреть абсолютно всё. Я работаю в программной среде BPwin, она автоматически выделяет ошибки в квадратные скобки. Далее я могу перенести эти данные на диаграмму более высокого уровня или затуннелировать их. Например, если мы считаем, что понимание, что доска используется в процессе, не нужно на контекстной диаграмме, мы можем специально обозначить нашу стрелку и это будет называться туннелем.
Представляю исправленные версии диаграмм.
Теперь видно, что все выходы присутствуют на контекстной диаграмме, а механизм доска затуннелирован.
Декомпозиция второго уровня
По аналогии сделаем декомпозицию действий подготовить ингредиенты и приготовить котлету.
На диаграмме А1 на которой изображено подготовка ингредиентов выяснилось, что майонез и кетчуп нужно в чём-то смешивать, соответственно у нас появляется ещё один механизм - емкость для смешивания.
Декомпозиция приготовить котлету прошла гладко.
Декомпозировать все блоки не обязательно. Потому в виду своей лености я не буду рисовать декомпозицию процесса собирания бургера.
Что можно увидеть на этих диаграммах?
С помощью этих диаграмм достаточно просто выявить необходимые ресурсы для масштабирования процесса. Например, если мы хотим приготовить несколько бургеров одновременно, то по диаграмме мы сразу сможем определить, что для этого нам понадобятся несколько сковородок, ножей, поваров, емкостей для смешивания или воспроизводство этих объектов или организация последовательного использования.
Второй очевидный момент - мы видим все необходимые ресурсы для работы процесса. Соответственно, если в других процессах мы не позаботились о том, чтобы передавать ресурсы своевременно, то наш процесс будет давать сбой.
В третьих, мы видим, что процесс даёт на выходе на самом деле.
И одно из самых важных - мы видим как контролируется процесс. В нашем случае со стороны управления приходит только рецепт. Там могут быть прочие нормативы и приказы, распорядки, традиции и так далее. Но всё это оставляет приготовление бургера на совести повара. Если мы вспомним ресторанную практику, то отпускаемую продукцию контролирует шеф-повар. То есть можно спроектировать процесс так, чтобы выход одного действия был управлением контролируемого действия.
Так же возможны действия, выходы которых являются механизмами для других действий.
Как посчитать стоимость процесса?
На диаграммах вы могли увидеть, что в нижнем левом углу каждого действия стоят цифры 0,00. Обычно там пишется стоимость данного действия.
Для каждого действия составляют таблицу из четырёх столбцов: центр затрат, цена, количество, сумма. Строки суммируются по столбцу сумма, полученное число умножается на вероятность прохождения этого блока. То есть, если контролирующий шеф-повар возвращает переделывать каждый второй бургер, то вероятность прохождения всего процесса - 1,5. Если мы замешиваем соус только каждый второй бургер, то вероятность прохождения этого блока 0,5. Самый популярный центр затрат - персонал. Обычно единица измерения персонала - трудовой час. То есть берётся зарплата сотрудника за час и умножается на количество часов (дней, минут, секунд), потраченное на это действие.
Таким образом, стоимость действия контекстной диаграммы, а значит и всего процесса - сумма стоимости всех действий на диаграмме декомпозиции. Стоимость действия на диаграмме декомпозиции - сумма стоимости всех "поддействий".
Тогда варьируя цену центров затрат, можно посмотреть, как будет увеличиваться или уменьшаться стоимость всего процесса. Возможно, увеличение стоимости процесса на организацию контроля уменьшит стоимость всего процесса в целом, так как уменьшится вероятность прохождения других действий. Тут нужно эксперементировать.
Итог
Так мы разобрались с тем, как рисовать IDEF0 диаграммы. Как с помощью них определять необходимые процессу ресурсы. Вычислять контролируемость процесса и считать его стоимость.
Если возникли вопросы, напишите мне во Вконтакте или на почту kirill-buta@ventra.su.
P. S. Стоимость и скорость бизнес-процесса подробно рассмотрены в следующей статье.