АУДИТ И КОНСАЛТИНГ

СТРАТЕГИЯ

БИЗНЕС-ПРОЦЕССЫ

МОТИВАЦИЯ И KPI

ФИНАНСЫ

ЛОГИСТИКА

АВТОМАТИЗАЦИЯ

СИСТЕМА МЕНЕДЖМЕНТА КАЧЕСТВА

Адрес:
Россия, Санкт-Петербург, ул. Чайковского, д. 26

Интервью с Владимиром Репиным 22.03.2018

Узнав о том, что Владимир Репин планирует провести 29-30 марта в Москве тренинг «Business Studio 4: моделирование, анализ и регламентация бизнес-процессов», мы решили, что это отличный повод познакомиться с Владимиром Владимировичем поближе. И поговорить с ним как об этом событии, так и многих других интересных вещах.

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

В этом материале – ВТОРАЯ ЧАСТЬ нашей беседы, в которой мы обсудили следующую крупную тему тренинга Владимира, с которой – в общем и целом – у меня лично олицетворяется вся его работа:

Тема 2. Моделирование бизнес-процессов и проблемы использования нотаций, предусмотренных «Business Studio»

- Владимир, кому как ни Вам хотел бы я задать этот вопрос: а как правильно ориентироваться в разнообразии нотаций системы моделирования «Business Studio»? Каковы ключевые принципы выбора нотаций из комплекта системы, которых Вы придерживаетесь?

- Для проектирования процессов верхнего уровня в «Business Studio» имеется только одна пригодная для этого нотация и это IDEF0. Поскольку схемы верхнего уровня рисуются для человека, а не для машины, то она не устарела и использовать ее можно.

Но если мы говорим об операционных процессах - так называемых процессах «Work Flow», описывающих потоки работ, то нам остаются три остальные нотации, ну или формально четыре, если считать также «Процесс»…

 

- Никогда не понимал, честно говоря, смысла нотации «Процесс». Зачем она, если есть «Кросс-функциональная диаграмма»? Даже если у процесса один исполнитель, я лучше опишу процесс в рамке с его названием, чем без нее. В чем же смысл? Это что, версия «Cross Functional Flowchart» для ленивых?

- На мой взгляд, она просто лишняя в «Business Studio». Но если говорить о «Процедуре», то и с ней не все хорошо: она попросту безнадежно устарела. «Уши» этой нотации торчат из стандарта ANSI 1974 года, и в данном случае это не та классика, которая вечна. Применительно к «Процедуре» проблема в том, что изначально предназначенная для описания алгоритмов, она сегодня уже не имеет практического применения как раз в этой области: техническая культура ушла далеко вперед. Поэтому лично я применять ее не рекомендую.

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

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

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

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

Вторая нотация, которую можно применять для описания процессов среднего уровня, это ARIS eEPC, «событийно управляемая цепочка процессов» («even driven process chain»). Она позволяет описать процесс очень подробно и вместе с тем понятно, но – это минус – схемы процессов получаются объемными, вытянутыми на экране или листе. Долгое время этой нотации не было альтернативы, но, к счастью, «Business Studio» теперь поддеживает стандарт BPMN, а eEPC стремительно теряет и своих поклонников, и свою актуальность - в связи с низкой выразительностью по сравнению с BPMN.

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

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

 

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

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

 

- А вообще разнообразие нотаций в проекте – это благо или «зло»? Нужно использовать все пять из имеющихся в «Business Studio» сразу, или лучше ограничиться двумя или вообще одной, если получится?

- Я скажу так: использовать в большинстве случаев придется две: IDEF0 для верхнего уровня и какую-то другую для всех прочих. Поменять эти две нотации местами или ограничиться одной не получится.

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

А если мы используем связку нотаций вида «IDEF0-Процедура», «IDEF0-EPC» или «IDEF0-BPMN» - это нормальное, вполне работоспособное решение.

Но я категорически не понимаю другого: использования трех нотаций для описания процессов различного уровня: IDEF0, а потом, например, «Процедуру», а потом – «EPC».

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

 

- Как быть бизнес-аналитику в том случае, когда заказчик, будь то клиент проекта или работодатель, требует «улучшить» какую-либо из нотаций, добавив в нее данные или удалив из нее данные, использование которых она не предусматривает? Ну, тупо ситуация, когда условный «директор» просит, чтобы в EPC до кучи появился блок с временем выполнения операций? Или наоборот просит убрать некоторые события как «лишние»? Нужно идти навстречу пожеланиям или это тот «Сталинград», сдать который бизнес-аналитик не имеет права?

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

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

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

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

- А Вы имеете опыт моделирования процессов в нотации BPMN в целях автоматизации?

Он неожиданно ответил: «-Да!» И пояснил на примере:

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

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

Поэтому, говоря словами героя из фильма «Бриллиантовая Рука», «На это мы пойтить не могём!»: никакие собственные нотации и собственные правила их применения мы выдумывать не будем.
22.03.2018г.

Материал подготовлен для группы «Business Studio Fans» в социальной сети Facebook