Зачем рисовать схемы бизнес-процессов?

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

Начнем с того что BPMN, EPC и IDEF - это умные слова и не более того. Попытка описывать ими бизнес-процессы приравнивается к попытке чесания ногой за ухом...

Если специалист говорит, что описал процессы и в качестве результата будет показывать мне рисованные схемы (в Visio, ARIS, в нотациях BPMN, EPC или IDEF и т.д.), то у меня в голове сразу включает сигнал тревоги: "Умник прямо по курсу, от которого надо держаться подальше".

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

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

Этот поток "комплиментов" относится именно к специалистам по BPMN/EPC/IDEF и т.д., но не к нотациям как таковым. Сами нотации - есть обычный инструмент. Но, как и ножом - ими нужно уметь пользоваться и понимать где это нужно. К примеру, бесполезно ножом есть суп, даже если у вас очень модный нож и вам очень сильно хочется им похвастаться.

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

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

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

Именно эту картинку я и попытался отобразить в виде схемы.

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

А если при помощи таких схем описать процесс в целом, то получается «каша» и ноль полезной информации.

Андрей Л.

На мой взгляд, гораздо более информативны схемы [в нотации BPMN — Прим. ред.]. И я честно говоря вообще не представляю как вы автоматизировали порядка 100 процессов не разу не нарисовав хотя бы элементарную блок схему.

Анатолий Юмашев

Очень хорошо :)

И это действительно один из не многих, хороших примеров ) исключение из сегодняшнего правила...

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

1. Эти схемы хороши для 2-х целей:

1.1. Смотрятся прикольно.

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

2. Но бесполезны для следующих:

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

2.2. Нет контроля качества результатов. См. п.2.1

2.3. Нет контроля ввода данных и получения требуемой информации. См. п.2.1

Если у меня в конце периода, выявляется 20% нарушений сроков по РКК по Иванову, я иду к нему. А Ваня просто при выполнении не проставил нужную галочку. И что мне ему сказать? Ваня! Ты чо! Ты чо дурак! Ты разве не знаешь что вот этот квадратик на схеме "Исполнение документа", означает: проставить галочку "выполнено", на второй закладке в карточке записи.

Ваня с ума сойдет от такого контроля.

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

И как уже сказал, из 100 процедур, цель из п.1 возникла лишь один раз. А вот цели из п.2 - каждый день. Но они при помощи схем не решаются. Тут нужно словестное и попунктное описание процедуры :)

Алексей Н.

Зачем нужно рисовать блок-схемы бизнес-процессов?

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

Как Вы будет составлять типовой маршрут? По памяти и невнятным записям в блокноте, оставшимся после интервью с ключевыми пользователями? Я понимаю, что есть гении, которые видят всю картинку в голове и методично воплощают ее в коде. Но таких немного, согласитесь.

А как ставите задачи разработчикам, если являетесь консультантом? Как утверждаете ТЗ с заказчиком?

Без схем не обойтись. Для наших задач мне больше всего нравится BPMN и EPC. Конечно, можно не знать этих слов и что за ними стоит, но элементарную схему с "квадратиками" и "ромбиками" составлять необходимо в любом случае.

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

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

Анатолий Юмашев

см. здесь:

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

Я не управлял проектами разработки ПО. Хоть и занимался проектированием. Задачи ставил письменно. Приводя примеры.

И еще раз. Если стоит задача внесения изменений в ПО, в т.ч. разработка ТМ, то написание блок схем я признаю. Но эти блок схемы далее этого ТЗ не уйдут.

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

1. Словестное описание + блок-схема = круто. Словестное описание = хорошо. Блок схема сама по себе = фуфло и понты.

2. К консультантам я отношусь нормально :) Тем более что 2 года в ХХХХ за плечами, создание направления ЭДО с ноля, найм и переманивание в 3 захода вот этого специалиста (с первых 2-х раз не переманивался).

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

Алексей Баранов

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

И, общем-то, суть статьи, как я понял, сводится к тому, что

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

Если так - то полностью согласен.

Дмитрий Носивской

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

Анатолий Юмашев

Правильное впечатление ) так и есть ))

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

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

И вот уже 1,5 года ходит и схемки рисует, называя это проектом внедрения СМК. Сделала кучу макулатуры. И все это без толку.

Вот и наболело у меня ))

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

И все это без единого рисунка.

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

Алексей Баранов

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

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

Судя по тому, что -

руководству удобней "видеть сверху" (так в большинстве случаев и происходит)

А из этого -

понятно, что удобней для Вас.

У разных людей - разные задачи. Поэтому и подход разный.

Анатолий Юмашев

да слышал я эти байки ) мне их втирать не надо. какие они там решения принимают видя эти рисунки? можно пример? ))

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

Ага, а почему вы решили что это сверху? а не с правого или левого боку? ))

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

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

Интересны ваши примеры. Только чур без общих слов.

Алексей Баранов

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

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

Извиняюсь, Анатолий, если неудачно выразился и каким-то образом задел, но думаю, в этом направлении не стоит дискуссию продолжать.

Анатолий Юмашев

Алексей, стоит )) Меня обидеть сложно )

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

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

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

Алексей Баранов

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

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

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

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

Для всего есть свое: время/место/обстоятельства.

В том числе для понимания - какие инструменты ЗДЕСЬ хороши, а какие не очень.

Анатолий Юмашев

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

Я хорошо понимаю как преподать ту или иную информацию различным типам людей. И не спорю с этим.

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

Назовите 2-3 примера таких решений или даже 1 пример решения, которое может быть принято человеком-визуалом на основании рисованной блок-схемы.

И я же просил: ))

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

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

Тимур Ш.

Не поленился и накидал схемку, может она не так красива, но вполне информативна:

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

Анатолий Юмашев

зачем? )

да, информативно. можно и в таком виде показать.

но зачем именно в таком, если нет разницы?

Да и спор у меня сейчас с Алексеем ) жаждю конкретики ))

Наталья Глазырина

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

Анатолий Юмашев

Наталья, кто ж спорит? Я даже более скажу... внешнему аудитору, если хорошо договориться, можно даже аудиалом притвориться (в терминологии Алексея) и поверить нам на слово ))) в том плане что у нас все тип-топ. Он поверит и нам сертификат выпишет. Даже на схемы смотреть не будет. Ну а те что по умнее, те на схемы посмотрят и скажут - да! - это круто! пошуршат наличностью, напечатают сертификат и срулят восвояси.

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

Алексей Баранов

без мелочевки, 2 "глобальных":

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

Начало работ по "интернетизации" почтамтов и городских отделений почтовой связи (2001).

Не IDEF0 и BPM, но - схемы и объяснение в виде презентации.

Анатолий Юмашев

Супер ))) а тема то про что? ))

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

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

Но мы то ведем речь о описании в BPMN, IDEF итд процесса для управления? Мол руководству по такому описанию проще управлять. Я вот и хочу узнать че там руководство видит и почему ему проще по этим схемам чего то там понимать? Если там не отображена конкретная ситуация, под конкретную задачу.

И еще раз:

1. Рисование схем по процессу под конкретную задачу - это надо. Об этом и речь в статье.

2. Рисование схемы по процессу для управления. Зачем? И что это за управление такое? Что под ним понимается?

И если возьмем п.1, то мы увидим, что на один процесс или процедуру. Можно нарисовать 33 схемы. В зависимости от проблемы или задачи. Под каждую задачу будет своя схема, при том что процесс то один ))

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

Если убрать п.1 из внимания (т.к. это не предмет разногласия), а посмотреть на п.2 - то скажите мне, что это за руководство такое и какие такие решение оно может принимать? И какую пользу несут эти рисунки? ))

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

Алексей Баранов

Согласен, что не согласен с таким утверждением. :)

Не отношусь к таковым. Это - крайности.

Точно так же - как крайностью является утверждение:

Истина где-то между :)

Николай П.

Начнем с того что BPMN, EPC и IDEF - это умные слова и не более того. - Это о многом говорит...

Начнём с того что EPC служит для описания процессов НИЖНЕГО уровня где описываются события!

А IDEF0 - описывает логическое взаимодействие между работами... Т.е. ВЕРХНИЙ уровень процесса...

Статья выражает личное мнение автора и не содержит ничего интересного. Даже предложенный Тимуром BPMN вариант гораздо эффективнее и более информативен. Вы же изобразили какуюто странную вариацию FlowChart...

Елена Б.

Полезны, если их рассматривать с точки зрения описания ТМ под конкретную задачу.

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

Анатолий Юмашев

очень рад :)

потому что вот это...

мне ни о чем не сказало )

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

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

Ну, во-первых, я не знаю объективных методик, где описано понятие верхнего и нижнего уровня процессов с описанием IDEF и EPC.

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

Оригинал записи опубликован на DIRECTUM Club.