Зачем нужно рисовать блок-схемы бизнес-процессов? Конкретный пример...
Начнем с того что BPMN, EPC и IDEF - это умные слова и не более того. Попытка описывать ими бизнес-процессы приравнивается к попытке чесания ногой за ухом...
Если специалист говорит что описал процессы и в качестве результата будет показывать мне рисованные схемы, в Visio, Aris, в нотациях BPMN, EPC или IDEF и т д, то у меня в голове сразу включает сигнал тревоги: "умник прямо по курсу, от которого надо держаться по дальше".
Почему то в сообществе "специалистов по управлению / MBA / консультантов / экспертов / программистов" - нужно подчеркнуть, сложилось мнение что описание бизнес-процессов это аля рисование схемок и произношение умных слов.
Они так любят свои художества, что за этой влюбленностью не замечают их бесполезность. Им до ламочки тот факт, что эти схемы не позволяют контролировать результаты, собирать информацию или добиваться повышения качества продукции. Им просто нравится умничать и казаться умными. Причем учитывая уровень управленческих компетенций в нашей стране, им это часто удается.
Вот. Выговорился )))
Этот поток "комплиментов" относится именно к специалистам по BPMN/EPC/IDEF итд, но не к нотациям как таковым. Сами нотации - есть обычный инструмент. Но как и ножом - ими нужно уметь пользоваться и понимать где это нужно. К примеру бесполезно ножом есть суп, даже если у вас очень модный нож и вам очень сильно хочется им похвастаться.
За последний год, при том что удалось описать и информатизировать порядка 100 процедур, есть регламенты, инструкции и достаточно мощная информационная система, потребность в описании блок-схемы по процессу пока выявилась всего лишь 1 раз.
Задача косалась процедуры входящих документов. Там есть проблема с контролем (как выяснилось из-за ошибки в ПО ДИРЕКТУМ), которую нужно было найти, определить, обосновать руководству и поставить задачу программистам. Вот под эту конкретную задачу и понадобилось написать схему.
Восстановим хронологию событий:
1. Поставлена цель: отказ от бумаги
2. Начали проработку нового порядка действий
3. Выяснили, что отказаться от бумаги не можем, т.к. в ДИРЕКТУМе нет контроля исполнения РКК
4. Начали думать над постановкой контроля в ДИРЕКТУМе, чтобы видеть показатели типа: "Средняя длительность исполнения входящих документов", "Доля документов выполненных в сроки". Ну и увиедть конкретные записи по нарушениям. Например: РКК №123 - нарушение срока на 5 дней. Ответственный: Петров и Сидоров
5. Пытаюсь вывести отчет. Но не тут то было. В отчете есть план.дата, но в 99% записей нет факт.даты. А как посчитать среднюю длительность? И как узнать нарушен срок или нет? Никак! И те РКК, где План.дата меньше сегодняшней даты = просрочены. Хотя люди говорят что все выполнили и нажали Выполнено.
6. Начинаем разбирать ситуацию, почему в 1% записей факт дата есть, а в 99% - нет. Выясняем, что факт.дата проставляется и не проставляется в следующих вариантах:
6.1. Факт дата проставляется, если реквизит "На контроле" = "Да", документы выполнен, отправлено задание контроль на руководителя и принято. Все!
6.2. А не проставляется во всех остальных случаях, включая:
6.2.1. Реквизит "На контроле" = "Да", но руководитель не принял задание-контроль. Факт дата = Пусто. Документ считается просроченным.
6.2.2. Реквизит "На контроле" = "Нет". В этом случае ПО вообще не ставит Факт.дату. Все поручения обозначаются как просроченные.
7. И тут получаем большую проблему, в части п.6.1 - руководство, которое отвечает за процедурный тип деятельности, вынуждено обрабатывать очень большой поток входящи документов (ставить резолюции), и кроме того что человеку идет несколько десятков входящих на резолюцию, сюда же наваливается нагрузка этих же документов по контролю и получаем завал. Руководитель перестает справляться с потоком. ТМ зависает на контроле. Все РКК видны как просроченные.
Именно эту картинку я и попытался отобразить в виде схемы.
Цель у этой схемы не описать процесс, а показать проблемную точку в процедуре, быстро поставить задачу программисту по поиску ошибки в ТМ и объяснить руководству, от куда завал.
Т.е. взята конкретная точка зрения на конкретное место в процессе и схема более или менее информативна.
А если при помощи таких схем описать процесс в целом, то получается каша и ноль полезной информации.
Да, кстати, рисовал при помощи службы http://live.yworks.com/graphity/
Очень удобная и лучшее из того что встречал. В категории online & free
На мой взгляд гораздо более информативны схемы представленные, например, вот в этом проекте. И я честно говоря вообще не представляю как вы автоматизировали порядка 100 процессов не разу не нарисовав хотя бы элементарную блок схему.
См. п.2.1 и См. п.2.1. - так еще правильней ))
Зачем нужно рисовать блок-схемы бизнес-процессов?
Приземлимся до прикладного уровня, до нашего всего - Директума.
Как Вы будет составлять ТМ? По памяти и невнятным записям в блокноте,оставшихся после интервью с ключевыми пользователя? Не, я понимаю, что есть гении, которые видят всю картинку в голове и методично воплощают ее в коде. Но таких немного,согласитесь.
А как ставите задачи разработчикам, если являетесь консультантом? Как утверждаете ТЗ с заказчиком?
Без схем не обойтись. Для нашиз задачь мне больше всего нравится BPMN и EPC. Конечно можно не знать этих слов и что за ними стоит, но элементарную схему с "квадратиками" и "ромбиками" составлять необходимо в любом случае.
А для регламентирования работ схемы являются лишь одной из составляющих описания процессов, наглядной картинкой, так сказать. Не случайно проектные решения по описанию БП состоят из словесного описания процессов и дополнены схемой.
Мне сдается, что автор вместе с неприязнью ко схемам испытывает еще и классовую ненависть к консультантам в костюмчиках на проектах
Схемы, как и любое другое наглядно представление информации, сами по себе ничего не дают, они дополняют словесное описание и пр..
Словестное описание + блок-схема = круто. Словестное описание = хорошо. Блок схема сама по себе = фуфло и понты.
+ к предыдущему.
И вот только после этого всего, я позволю себе сесть за рисование схем по процессам.
Сдается мне, что дело тут скоре в психологии, а не в используемых инструментах: словесное описание и схемы - дополняющие друг друга инструменты.
Кто-то лучше воспринимамет одно, кто-то другое. Чтобы было принято нужное вам решение, лучше подавать информацию в том виде, в котором она удобней "принимающему решения", а не тому, кто эту информацию генерирует.
Судя по тому, что -
Мой управленческий опыт, хоть и не связан с DIRECTUM (см. профиль), включает опыт общения и с руководством республики и федеральных органов.
Все, что я сказал выше - на нем и основано: я, как отвечавший за ИТ в большой организации, разделял информацию: для меня - детали, для руководства - визуальное представление, ответственные и цифры (суммы, сроки). Можно сказать, что это "вид сбоку", непринципиально. Руковдителя-эксперта на высшем уровне управления не встречал.
Извиняюсь, Анатолий, если неудачно выразился и каким-то образом задел, но думаю, в этом направлении не стоит дискуссию продолжать.
Алексей, стоит )) Меня обидеть сложно )
Вы утверждаете что руководство в этих схемах че то видит. Я себя считаю руководителем (и не только проектов), но нифига полезного в этих схемах не вижу. Вы утверждаете обратное. Объясните. Дайте примеры. Аргументируйте.
То что вы общаетесь с топ-топ-чиновниками, это не аргумент в пользу ваших доводов. Дайте пример какие такие решения руководитель может принять на основании рисованных схем.
Я тут много с какими топ-топами общаюсь, а еще у меня яблоко есть - вкусное. Но ни первый, ни даже второй аргумент не есть подтверждение моих слов.
И все-таки уходим мы в сторону, как мне видится - причиной этому могло быть неоднозначно воспринятая высказанная мною идея. Чтобы подвести к логическому концу нашу "ветку", озвучу свою мысль с другой стороны:
Известно, что есть разные типы людей (визуалы, аудиалы, кинестетики, и пр.). Только с этим (а не с занимаемой должностью) связано - как кому легче воспринимать информацию.
Отдельно хочу добавить, что в моих постах не было никакого намека на то, что если Вы не любите блок-схемы, то Вы не руководитель. Это просто характеризует привычное Вам восприятие.
Можно не учитывать то, как ВАШ руководитель принимает решения, попросту затратите бОльше энергии (так же, как дама-консультант, не учитывающая Ваше восприяте).
Для всего есть свое: время/место/обстоятельства.
В том числе для понимания - какие инструменты ЗДЕСЬ хороши, а какие не очень.
Алексей, я согласен. Кучу психологий изучал. Как в плане аудиалов/визуалов, так и еще тцать теорий, от воды/огня, холериков/сангвиников, до соционики с MBTI и еще ряда шаманских учений ))
Я хорошо понимаю как преподать ту или иную информацию различным типам людей. И не спорю с этим.
Предположим что вы имели ввиду визуалов и они якобы, смотря на эти схемы могут принять какие то решения.
Назовите 2-3 примера таких решений или даже 1 пример решения, которое может быть принято человеком-визуалом на основании рисованной блок-схемы.
И я же просил: ))
Не поленился и накидал схемку, может она не так красива, но вполне информативна:
при необходимости можно выделить тот блок (приемка работ руководителем), при котором у вас начинается "завал и потеря информации"
Схемы хороши тем, что если ты процесса не знаешь, то тебе не нужно перелопачивать инструкцию на несколько страниц, достаточно посмотреть на схему. Пример, хоть и абстрактный: внешнему специалисту, ну например аудитору по СМК, будет гораздо проще получить представление о процессе из схемы, нежели из инструкции/описания = документа на нескольких страницах.
Наталья, кто ж спорит? Я даже более скажу... внешнему аудитору, если хорошо договориться, можно даже аудиалом притвариться (в терминологии Алексея) и поверить нам на слово ))) в том плане что у нас все тип-топ. Он поверит и нам сертификат выпишет. Даже на схемы смотреть не будет. Ну а те что по умнее, те на схемы посмотрят и скажут - да! - это круто! пошуршат наличностью, напечатают сертификат и срулят восвояси.
Ну и туда же идем... коли о СМК речь завели... назовите мне пункт стандарта, который обязывает рисунки рисовать...
без мелочевки, 2 "глобальных":
Выбор варианта замены контрольно-кассовых машин (ККМ "Онега") работающих на перфолентах, на ККМ на базе ПК (выбор между Ленинградским ПО и Казанскими разработчиками, 1998). Модернизация была успешно проведена во всех отделениях связи республики.
Начало работ по "интернетизации" почтамтов и городских отделений почтовой связи (2001).
Не IDEF0 и BPM, но - схемы и объяснение в виде презентации.
Сорвали мне весь троллинг! Ай яй яй!
Ладно! С наступающим всех! ))
Начнем с того что BPMN, EPC и IDEF - это умные слова и не более того. - Это о многом говорит...
Начнём с того что EPC служит для описания процессов НИЖНЕГО уровня где описываются события!
А IDEF0 - описывает логическое взаимодействие между работами... Т.е. ВЕРХНИЙ уровень процесса...
Статья выражает личное мнение автора и не содержит ничего интересного. Даже предложенный Тимуром BPMN вариант гораздо эффективнее и более информативен. Вы же изобразили какуюто странную вариацию FlowChart...
Принимайте участие в опросе Какие средства описания процесов в вашей компании используются? В этом месяце у нас тематика BPM - появилось много материалов по теме BPM.
Авторизуйтесь, чтобы написать комментарий