Типичные ошибки при формировании схем бизнес процессов

Типовая ошибка 1. «Что вижу, то и пишу»

Она может показаться мелкой и даже придиркой, но она настолько часто встречается на рынке, что не упомянуть её невозможно. Если бы казахский акын был не певцом и поэтом, а писателем бизнес-процессов, то он бы, наверное, сказал: «Что вижу, то и пишу».

«Вот давайте мы опишем (благо способов описания бизнес-процессов немало) как работает наш отдел продаж. Вот давайте мы опишем как работает наше производство. Вот давайте мы опишем, как работает любой иной отдел».

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

Между тем, описание — это средство, а не цель. А целью является не столько фиксация текущего опыта, сколько усовершенствование. Ведь, если сам опыт плох, то фиксация его приведет к тиражированию неудач.

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

---

Типовая ошибка 2 (более серьезная). Неучёт соотношения «Результат/Затраты»

(При знакомстве с бизнес-процессом, при встрече с реальной живой компанией и её реальной деятельностью.)

Продолжая первую мысль: «усовершенствовать — это значит улучшить соотношение Результат/Затраты». Цель всей этой оптимизации — не растратить ресурсы, увидев то что есть, но описать их. Не буквально, а так, чтобы, при выполнении написанного, соотношение Результат/Затраты улучшилось. В известном смысле это критерий качества описания бизнес-процесса («было-стало»).

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

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

Потому что все имеет свою цену и, если начинать описывать просто «от и до», то, в результате, это выродится сами знаете во что — в отчеты, которые будут брошены, а жизнь пройдёт своим чередом. 

---

Типовая ошибка 3. Работа без представления об идеальном процессе

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

Формулировка П. Друкера: «Предприниматель — это не тот, кто получает прибыль, а тот, кто получает прибыль, сокращая усилия».

Это первая формулировка, показывающая нам направление. Мы должны не просто описать, мы должны так изменить бизнес-процесс, чтобы бОльший результат получался при сокращении усилий, а не путем увеличения работы.

Вторая формулировка (возможно моя): «Производительность не равна работе».

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

Вот эти 2 формулировки и задают нам ориентиры. Если их обобщить (или, как мы любим говорить, «свернуть»), то мы получим ту формулировку, которая известна в ТРИЗ — формулировку «идеальной системы» Генриха Альтшуллера.

Когда мы что-либо создаем, проектируем, совершенствуем (фирму, продукцию, каналы продаж и т.д.), мы имеем дело с системой, которую мы улучшаем. Бизнес-процесс тоже система, которую мы улучшаем вплоть до идеала. А формулировка идеальной системы (с точки зрения соотношения «Результат/Затраты»), как известно, звучит так: «Идеальная система — та, которой нет, а функции её выполняются».

Ошибкой же является отсутствие у разработчика бизнес-процесса этого ясного идеала, к которому он хочет приблизиться. Улучшение — это приближение к идеальному процессу, которого нет, а есть только его результаты. И этот идеал в ТРИЗ так и называется «Идеальный Конечный Результат» (ИКР).

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

---

Типовая ошибка 4. Неучёт закономерностей развития

Если бы мы разложили нашу мысль про результат и про затраты в график, то график идеальности выглядел бы так:

И, прежде чем что-либо писать, надо дать ответ на вопрос: «Где место той системы, которую мы совершенствуем, на этом графике?»

Если компания, бизнес-процессы которой мы совершенствуем, находится в зоне I, то, в целом, вся стратегия её структурирования, разделения функций, описания их и «приведения в порядок» будет одна. Иначе — другая.

Если компания находится в зоне I, то используется определенный набор шаблонов, готовых решений. Если компания находится в зоне II, то совсем другие рекомендации надо дать по отношению к её процессам, и, соответственно, достать другие шаблоны. И под эти другие шаблоны описать, собственно, процесс.

Если же компания находится в зоне III, то все будет совсем не так, как в случаях I и II.

Если мы строим для конкретных Заказчиков офисы в Гонконге, где все скалисто и места нет, то, вероятно, мы будем строить небоскреб, либо не будем строить вовсе. А если мы строим в степи на Юге России, где полно земли, однако коммуникации подвести чрезвычайно затратно, то мы тем же Заказчикам будем проектировать коттеджный поселок.

Если компания находится в зоне I, то само корректное переструктурирование её подразделений станет первой задачей разработчика. И под эту задачу все будет подстраиваться.

Если компания находится в зоне I, она, скорее всего, структурирована неверно относительно правил структурирования и у нее именно по этой причине соотношение Результат/Затраты плохое. Надо перестроить систему, а потом её описать уже в улучшенном виде, а не писать что видишь, даже если тебе говорят «это наша специфика».

У компаний, которые находятся в зоне II, видимо все хорошо, т.к., мы видим, что небольшим приростом затрат получается большой «выхлоп». Однако, если смотреть на динамику процесса, за вторым этапом последует третий…

Такая компания растет достаточно быстро и у нее накапливаются большие затраты, которые, тем не менее, системного дестабилизирующего влияния не оказывают, когда она в зоне II. Но через некоторое время ситуация изменится и компания с этими рисками окажется в зоне III, когда все быстро переключится.

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

Т.е., одна из ошибок таких компаний: отождествление успешных с устаревшими. Такие компании, как бы, говорят: «Вот у нас есть успешный проект, но нельзя ограничиваться только им, надо искать что-то еще». И они отбирают ресурс у успешного проекта и отдают этот ресурс остальным (часто плохим). Это похоже на «прогрессивное» налогообложение: отобрать у лучших и перераспределить среди прочих.

Понятно, есть и другая опасность: «почивать на лаврах», но у компании II этапа проблема не в этом. Это как с ребёнком, который имеет талант к пению, а его заставляют заниматься еще и хоккеем. Компании второго этапа надо избавиться от лишних направлений и сосредоточиться на своем «пении».

Т.е., заранее искать «третьи этапы» внутри себя и выбрасывать их: находить направления, где соотношение «Результат/Затраты» плохое и выбрасывать их. Внимание: не улучшать, а выбрасывать.

Если же компания находится в зоне III и соотношение «Результат/Затраты» опять стало плохим, но уже по другим причинам, чем в первом случае, то у нас будет третий набор шаблонов.

И это будут шаблоны разрушения. («Созидательного разрушения», как писал экономист Й. Шумпетер). Когда мы видим, что компания организована достаточно хорошо (понятно, что нет предела совершенству), её не надо особо переструктурировать. Более того, возможно Вы удивитесь, но может быть не особенно-то и важно описывать её бизнес-процесс. Т.к. он уже и так неплохо описан и люди его знают, понимают, привыкли по нему работать и, в известном смысле, не так уж все и плохо. И от вылизывания каких-то подсистем особых результатов не дождешься.

А дело заключается в том, что рынок из-под этой компании ушел. И, несмотря на более-менее отлаженную систему работы, она начинает каждый новый заказ, например, добывать все большими и большими усилиями. При этом суммы сделок мельчают и мельчают, а усилия по их добыче и выполнению те же самые, что и на крупные сделки. Но, поскольку теперь приходится за мелкими сделками гоняться и набирать их больше и больше, то соотношение «Результат/Затраты» получается очень плохое.

И поэтому нам не надо стратегически улучшать вот это «беганье за зайцами». Мы сгорим на этом «субботнике», но прибыли не заработаем. И кое-что надо разрушить внутри компании (или всю компанию), чтобы разрешить эти противоречия.

Т.о., у нас должна быть определенная стратегия усовершенствования, а у разработчика должно быть «стратегическое видение». 

---

Типовая ошибка 5. Неучет бизнес-контекста (окружения)

Мы — это мы, а что вокруг нас? Как устроены наши конкуренты, контрагенты? У них есть такие же проблемы? Выявление признаков определенного этапа дает возможность относительно быстро определить узкие места в бизнес-процессах, не изучая всю «пооперационку».

Позвольте привести развёрнутый пример.

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

Но при анализе окружения выяснилось, что, действительно, на рынке вокруг этой компании работает множество мелких предпринимателей, в т.ч. фрилансеров, которые размножаются чуть ли почкованием. И в городе с миллионным населением их могут быть тысячи (пусть и полудохлых). Часть из них пропадает, появляются другие. Одни из них оказывают услуги: ходят за прорабами, чтобы узнать кому можно будет оказать услугу по установке мебели. Другие у себя в гараже собирают какие-то кухни. Третьи, чуть покрупнее, даже «салоны» себе открыли — арендовали небольшие пространства в торговых центрах, где у них сидит «как бы дизайнер», стоит несколько экземпляров мебели и каталог. И там уговаривают: давайте мы пойдем к Вам на квартиру, сделаем замеры и т.п.

По ценам все эти фрилансеры демпингуют, но, получив заказ от Клиента, они сами ничего произвести не могут, а начинают бегать по рынку и размещать заказы по разным предприятиям: здесь фасады, там столешницы, здесь фурнитуру купим и т.д. Некоторые даже называют себя «системными интеграторами», при этом, на самом деле, они занимаются тем, что в своем гараже утюгом пленку наносят на МДФ.

И это окружение «отъедает её бизнес». И никакие рекламные усилия (пропаганда такого рода, что не надо заказывать у «физиков», которые делают халтурно) не помогают.

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

Третья же особенность заключается в том, что самые длинные операции — это сборка и взаимодействие с конечным Клиентом, к которому надо выехать сначала на замеры, потом смонтировать и т.д. А они же — Клиенты частные. Это сколько же надо производителю мебели людей иметь, чтобы не ставить Клиентов в очередь?! А обычно есть 2-3-5 замерщиков, несколько дизайнеров (мы же не будем же раздувать этот штат). А сколько они в день Клиентов посетят? Ну, 3-4… И это при больших рекламных затратах.  Вот и получается, что и производство простаивает, и Клиенты ждут, и заказов никакой очереди нет.

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

Поэтому мы и начинаем с тех подсистем, где: а) соотношение «Результат/Затраты» является плохим и б) быстрыми темпами обостряется противоречие между этими подсистемами с надсистемой при росте потока.

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

Если, в целом, подсистема затратная, то именно она отнимает у нас прибыль, именно она находится в сильной конкуренции с фрилансерами, каждый из которых если сбегает к 2-3-м Клиентам за день, а потом, на фоне этой общей низкой производительности, выполнит в месяц максимум 3-4 заказа и заработает себе 200 тыс. рублей, и поедет в Таиланд. И он вполне счастлив от такого образа жизни и не будет его менять, не будет создавать производства, не будут расширяться. А предприятие так работать не может.

«Фрилансеры» у предприятия конкуренцию выигрывают, но не по всей цепочке, а именно добавляют ему слабость только там, где оно и так слабо. Для них это не проблема — 2-3 заказа в месяц, а для производства — проблема. Для них это не проблема — идти в последнюю милю, а для производства — проблема. Для них не проблема медленно собирать одно изделие на общем низком фоне рыночном, а для производства — проблема, т.к. при потоке заказов надо сборочный участок иметь со всеми издержками и чтобы он не простаивал, и не тормозил общего потока работ. А когда у Вас 3-4 сборки в месяц, то всего этого не требуется.

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

А предпринимательское решение заключается не в том, чтобы «усилить слабые стороны», а в том, чтобы вообще не делать того, что мы делаем не очень хорошо = постараться выбросить «слабые процессы» из системы в надсистему. Т.е., например, производству не улучшать слабую сборку, а не собирать вовсе.

И надо сначала придумать, как оно без сборки будет работать, а потом этот новый бизнес-процесс описать. И этот новый способ (без сборки), с точки зрения Результат/Затраты (а не просто дешевле), должен быть точно лучше, чем есть сейчас.

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

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

Идея заключалась в том, чтобы расширить производство, не расширяя его. Сборочные участки преобразовать в коворкинг для фрилансеров, чтобы они не в гараже, а на фабрике собрали свой же заказ. Или же просто увезли комплект, чтобы собрать его на квартире Клиента. Фрилансерам оказывается и дополнительный сервис, или не оказывается, или оказывается по желанию.

Вдобавок так мы избавляем их еще от логистики. Если он без этого сервиса работает, то он в одном месте заказ на фасады разместил, в другом месте фурнитуру заказал, в третьем — столешницы, в четвертом — еще что-то сделал и т.д. Отсюда потери времени вплоть до двух месяцев и т.д. Теперь же он через 2 дня после замера получает готовый упакованный комплект. А фабрике-производителю теперь самой не надо ни собирать мебель, ни ездить к Клиенту на замеры и монтаж, ни открывать салоны и т.д.

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

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

Недаром Питер Друкер писал: «Причина успеха лежит за пределами предприятия, внутри предприятия лежат только причины издержек». 

---

Типовая ошибка 6. Слова молитвы дурака перед расшибанием лба

Если говорить об ошибках пропагандистов «бережливого производства», то их масса и по ним идешь порой, как по выжженной земле. Самое частое — это некритичное применение описаний опыта известных корпораций.

Например, много начитавшихся про «Тойоту» ходят по российским предприятиям и пытаются из них «Тойоту» сделать. Если бы фрилансер был способен сделать из российского предприятия Тойоту, он не был бы фрилансером.

Нередко рассказывают о том, что фирма «Тойота», чтобы снизить свои операционные издержки, работает без склада, только под заказ. Вот, стало быть, и Вы так делайте. Буквально так и говорят: «Тойота — не глупая, работает без склада». И тут вдруг маленькое предприятие (которое заказало такой консалтинг), имеющее маленькое же производство лестниц, дверей, ограждений, различных крепежных элементов, у которого всегда было преимущество — склад-магазин готовых полуфабрикатов (люди могли приезжать смотреть образцы, частично покупать, частично заказывать), закрывает этот склад и начинает работать только под заказ. И остается вообще без заказов, т.к., Клиенты приезжают и говорят: «У Вас тут ничего нет». Работники на этом предприятии говорят: «Надо произвести, мы можем». А им говорят: «Нееет. Бережливое производство! Тойота так не делает!»

Некритичное применение, в общем-то, правильного, но не к месту, увы, очень распространено.

Приём вне контекста применять глупо. Иногда надо выбросить склад с территории предприятия, а иногда надо его не только построить, но и организовать там продажи. И добиться ответа на вопрос: «На каком основании Вы это насоветовали?», кроме того, что «я читал про Тойоту» — не удается.

Поэтому последние слова молитвы дурака звучат так: «Я и Тойота». Если Вы это слышите, знайте — он сейчас разобьет лоб и не только себе.

Материал опубликован на сайте «Открытые бизнес-методики и технологии TRIZ-RI» 22 сентября 2016 г.

В этой статье мы разберем самые распространенные ошибки, которые совершают компании при внедрении бизнес-процессов.

Ошибка №1: Регламенты – главная цель

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

Я консультировал одну очень известную компанию. Они постоянно проводят у себя семинары по внедрению бизнес-процессов, к ним приезжали многие консультанты, в том числе и из большой четверки. Казалось бы, такие мероприятия непременно должны принести результат, ведь столько работы ведется в этом направлении. Но если задать прямой вопрос: «Чего вы добились в бизнес-процессах?», в ответ можно будет услышать: «У нас регламентированы все процессы. Все до единого”. И это удивительный результат. Редко какой компании удается достичь таких успехов. 

Ну тогда в чем же проблема? Проблема в том, что регламенты есть, а процессный подход не внедрен. Например, в этой компании 2 месяца нужно потратить на то, чтобы согласовать приказ, договоры согласуются по 4 месяца. Все регламентировано, но в результате бюрократизм достигает просто невероятных масштабов. Что с этим делать? Выбросить половину регламентов, и тогда работать станет в два раза легче. 

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

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

В чем тогда состоит цель? Управлять процессами. Что это означает? Есть несколько признаков процессного подхода:

1. Умение выявлять процессы. Должно быть понятно, из каких блоков и элементов состоит деятельность компании.
2. Умение определять последовательность действий, процессов, их взаимные связи.
3. Умение определять критерии и методы измерения результативности процессов. То есть важно понимать, что мы имеем в результате, какие ресурсы могут понадобиться для выполнения процессов.
4. Постоянное отслеживание наличия необходимых ресурсов и информации, которая нужна для выполнения процессов, а также обеспечение их выполнения.
5. Постоянное наблюдение, измерение и анализ процессов. Важно выявлять все моменты, которые приводят к неблагоприятным для организации последствиям.
6. Проведение регулярных мероприятий по улучшению процессов.

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

Ошибка №2: KPI – лекарство от всех бед

Есть большое количество руководителей, которые считают, что внедрение KPI – это ключ к успеху. Почему? Обычно говорят: «Нам нужно улучшить мотивацию. Все сотрудники должны четко работать на общую цель».

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

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

Вот пример. Руководитель одного известного банка был одержим идеей числовых показателей для каждого сотрудника. За конкретный результат (большой или маленький) полагалась четкая сумма оплаты. И в автоматизации работы компания добилась настоящего совершенства. Любой вклад работника не оставался незамеченным. Счетчики считались, каждая бумажка имела вес. Однако проблемы никуда не ушли. Они были связаны с мотивацией: без денежного вознаграждения сотрудники и пальцем не хотели пошевелить. Это странно для людей, которые считают, что KPI как раз и внедряется для мотивации. Получается, возник парадокс. Компания достигла предела, совершенствовать больше нечего, а мотивации все нет, даже наоборот, ее стало еще меньше. Разве это идеал? Все считается, измеряется, но сотрудники не заинтересованы в работе, они думают только о деньгах. Ситуация ухудшается и тем, что при таких условиях обычно в коллективе очень натянутые отношения. Люди просто перестают быть людьми. Сотрудники становятся безинициативными, недружелюбными и эгоистичными.

Ошибка №3: Устаревшие методы

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

Такой подход хорошо работал во времена Генри Форда. Но с тех пор прошло уже сто лет. Стоит проанализировать обстоятельства: работники у Форда были малограмотными, малообеспеченными, очень зависимыми от работодателя. Запросы этих людей едва достигали самой низшей планки. Живут ли такие люди в XXI веке? Если и да, то это, скорее, исключение. Поэтому стоит задать себе вопрос: как могут методы столетней давности работать в нынешних условиях? Успехи прошлого не гарантируют успех в будущем. Это часто не принимают во внимание. Времена меняются, и мы должны трезво оценивать ситуацию вокруг нас.

Что же актуально на сегодняшний день? Во время внедрения процессного подхода прежде всего необходимо организовать команду. Если речь идет об организации средних размеров, нужна команда топ-менеджеров. Внедрением процессного подхода должны заниматься руководители. И главное – начать с обсуждения проблем. Почему процессный подход так важен? Для организационных изменений должна быть причина. Какие проблемы надо преодолеть? Сформулировать их нужно как можно конкретнее, чтобы был критерий успеха во время подведения итогов. Какие процессы являются серьезным препятствием? Вся команда должна знать врага в лицо, чтобы понять, удалось ли от него избавиться.

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

Дальнейшие этапы управленческая команда должна проходить вместе, а также включать в это дело сотрудников. Здесь нужно перейти к распределению: как компания будет взаимодействовать с клиентами, какими способами их привлекать, обслуживать и т.д. Сотрудники тоже должны участвовать в обсуждении. Какой должна быть структура процессов? Должно быть принято коллективное решение.

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

Ошибка №4: Игнорирование корпоративной культуры

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

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

Любой объект управления состоит из 5 элементов:

1. Цели. Нужна правильно выстроенная система целеполагания, направляющая действие всех сотрудников компании.
2. Стратегия. Она интегрирует все направления бизнеса и определяет конечную цель.
3. Процессы. Задача руководителей – определить, каким образом в компании выполняются те или иные действия, как достигается результат.
4. Структура. С ее помощью происходит разделение областей ответственности.
5. Ценности. Они являются основой всего. Именно ценности определяют поведение человека. Ценности компании должны способствовать ее развитию. Создание корпоративной культуры – это миссия лидеров организации.

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

Ошибка №5: Неправильное понимание организационной структуры

Процессы работают не в любой организационной структуре. Например, они совсем не приживаются в компании, где присутствуют жесткие регламенты. А что первично: структура или процесс? Конечно, процесс, ведь это деятельность, которая приносит результат. Структура же нужна только для того, чтобы обслуживать эти процессы. И все.

Получается, сначала нужно модифицировать процессы, а потом уже подумать, какую организационную структуру к ним подобрать. Именно в таком порядке. Причем речь идет о четком понимании области ответственности. Какие именно подразделения за что отвечают? Это нужно описать с точки зрения обеспечения функционирования процессов. Тогда и получится правильная организационная структура. При этом нужно учесть наиболее важные процессы, например, комплексное планирование. Это основа всей работы. Или разработку новой продукции, без этого процесса у компании нет развития. Ну и так далее.

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

Ошибка №6: Игнорирование стратегии

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

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

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

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

Ошибка №7: Неверное определение целей процессов

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

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

Заключение

Процессы – это регулярно повторяющаяся последовательность действий. В этом и состоит их ценность. У нас есть время проанализировать нашу деятельность и учиться на собственных ошибках. Глубинный смысл процессного подхода состоит в возможности использовать свой опыт. Все это поможет улучшить нашу деятельность в будущем. Происходит настоящее обучение. Мы разрабатываем некую модель процессов, наблюдаем за ней и задаем вопрос, что можно улучшить. Проводим изменения. Видим улучшения, анализируем результаты, делаем выводы. Есть результаты? Значит, можно приступать к решению следующей проблемы. Если результаты не удовлетворяют, то нужно внести изменения в существующие процессы. Вот этот цикл непрерывного совершенствования и есть главный смысл процессного подхода.

Если на собеседовании вас спрашивают «Имеете ли вы опыт моделирования бизнес-процессов», то в неявном виде вас спрашивают об опыте использования нотации BPMN. Мне могут возразить, что есть и другие нотации, например UML Activity diagram или старый-добрый IDEF0. Но на сегодняшний день место лидера за BPMN.

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

В интернете есть целый ряд статей, посвященных рассмотрению ошибок, которые чаще всего допускают при создании диаграмм в нотации BPMN (ссылка 1, ссылка 2, ссылка 3, …). Отталкиваясь от них и от своего десятилетного опыта я написал эту статью.

Ошибки в BPMN-диаграммах бывают трех видов:

• Ошибки формальные – диаграмма не соответствует нотации BPMN.

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

• Логические ошибки – элементы использованы правильные, стиль соблюден, но есть проблемы в логике того, что смоделировано.

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

1. Не BPMN

В диаграмме использованы элементы, отсутствующие в BPMN. Это символы UML, IDEF и других нотаций. Или это самодельные, придуманные автором символы. Самый просто способ убедиться в том, что вы используете корректные элементы — обратиться к постеру BPMN elements

2. Пулы (Pool) та дорожки (Lane)

Во-первых, пулов и дорожек на диаграмме может не быть. Однако их наличие упрощает понимание диаграммы.

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

Дорожки позволяют нам показать участников описываемого процесса – кто какую задачу в рамках процесса выполняет. Если вдаваться в детали, то дорожки – элемент чисто визуальный. Исполнителя/исполнителей для каждой задачи указывают в ее свойствах. Вот как это выглядит в Bizagi:

Можно увидеть, что здесь есть возможность указать участников и указать их вовлеченность в выполнение задачи по RACI-матрице.

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

Итак,

• конкретных исполнителей/подразделения в рамках одной организации, участвующих в процессе — моделируем дорожками;

• процессы или внешних контрагентов моделируем пулами;

• исполнителей в простых случаях обозначаем в названии дорожки;

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

3. Глагол в названии
Название задачи должно содержать глагол: «Создать заявку», «Отправить запрос». Некоторые вместо этого пишут «Создание заявки», или еще хуже «Заявка». Это ошибка в стиле.

4. Подробное описание процесса, о котором мы ничего не знаем

В пункте 2 мы упоминали свернутый пул, моделирующий независимую сущность. К примеру, вы показываете процесс обработки заказа, поступившего от клиента. Клиента лучше всего изобразить свернутым пулом. Что там делается у клиента – для нас загадка, предсказать процесс сложно, повлиять мы на него не можем. Со стороны нашего процесса мы должны определить, какие действия со стороны клиента мы собираемся ожидать и это все. Но детальный процесс для клиента лучше не придумывать. Это пример логической ошибки.

5. «Долгая-долгая история»

Если процесс содержит много шагов, то диаграмма начинает напоминать детскую игру «змейка»:

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

Для разрешения этой ситуации есть 2 варианта:

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

2. Или использовать промежуточное событие «Ссылка» (Link):

6. «Потерянное письмо»

Следующая ошибка — логическая и, на мой взгляд, не очевидна. И критичной она становится только в том случае, когда вы моделируете не только для визуализации, а для выполнения с помощью BPMN-engine.

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

Теперь давайте рассмотрим пример диаграммы:

Если Task 2 будет завершен раньше, чем Task 1, то отправленное Process 2 сообщение потеряется, потому что Process 1 начинает его ожидать только после завершения Task 1. А до этого момента «почтальона» никто не встречает. Для исправления этой ситуации мы можем изменить диаграмму следующим образом:

Здесь мы письмо начинаем ждать сразу после отправки со стороны Process 1.

Для более требовательных ценителей можно также использовать вариант с подпроцессом, позволяющий вообще избавиться от сообщений:

7. «У всех свой путь, своя цель, но всех нас ждет один конец.»
С высказыванием Карлоса Кастанеды можно соглашаться, можно нет. Но очень редко у процесса возможен только один вариант завершения, как показано на диаграмме:

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

8. «Конец-делу венец» или завершение без описания.

All’s Well That Ends Well или «Все хорошо, что хорошо заканчивается». Не оставляйте финальное событие без подписи. Особенно эта подпись необходима, когда завершающих событий у нас несколько, как на последнем рисунке в пункте 7. Укажите, какой результат мы получили, когда дошли до этого красного кружка. Это упростит восприятие диаграммы читателем, а engine зафиксирует в протоколе, чем закончился экземпляр процесса.

9. «и швец, и жнец, и на дуде игрец»

Часто в диаграммах можно увидеть, что одна развилка (gateway) используется одновременно и для сведения, и для разветвления потоков:

Практики и теоретики рекомендуют использовать одну развилку либо для сведения, либо для разветвления. Меняем диаграмму следующим образом:

10. «Смешались в кучу кони, люди»

Благодаря наличию в BPMN развилки «Или/Или» мы можем моделировать различные варианты развития событий. Однако есть рекомендация отделять описание бизнес-правил от описания бизнес-процесса. Это и диаграммы упрощает, и внесение изменений делает проще. К примеру, изменение правил расчета кредитного рейтинга меняются гораздо чаще, чем процесс выдачи кредита. Поэтому от такой диаграммы:

мы можем перейти к следующей, используя специальный тип задачи «Business Rule Task»:

Продолжение следует…

Расписание тренингов по бизнес-анализу и анализу данных от Art of Business Analysis

В статье Владимира Репина рассмотрены типовые ошибки, которые допускают сотрудники организации, начинающие осваивать моделирование бизнес-процессов в среде Business Studio с использованием нотации BPMN. Обсуждается вопрос о возможности и целесообразности использования данной нотации для комплексного описания бизнес-процессов организации силами собственных сотрудников.

Введение

Задача «описания всех бизнес-процессов» компании многими специалистами рассматривается как нецелесообразная в силу того, что она крайне трудоемка и не дает очевидного практического результата в краткосрочной перспективе, например, явного прироста прибыли компании. Тем не менее, собственники и топ-менеджеры многих крупных компаний именно так ставят задачу: «описать все процессы». Причины такой постановки задачи различны: желание сделать «прозрачной» компанию, подготовиться к автоматизации, радикально снизить затраты, провести реинжиниринг и проч.

Для выполнения этой задачи нужны: эффективная система управления проектом, методология, инструмент (система моделирования) и человеческие ресурсы, адекватные по численности и подготовке. Если инструмент можно легко купить, то с методологией и ресурсами всё не так просто. Качество управления проектом сильно зависит от конкретного руководителя.

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

С человеческими ресурсами все тоже довольно сложно. Другими словами, их просто нет. Найти на рынке готового специалиста со знаниями методологии и инструмента, навыками моделирования в нотации BPMN, опытом в предметной области (например, сварка танков под вакуумом рентгеновским лазером) невозможно. Вывод один – массовое обучение и вовлечение в проект описания бизнес-процессов руководителей и специалистов подразделений.

В данной статье рассматриваются типовые ошибки, которые допускают сотрудники, впервые занявшиеся моделированием процессов вообще и, в частности, в нотации BPMN.

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

Исходные данные для анализа

Исходные данные для анализа таковы. В ряде компаний (нефтедобыча, производство, ритейл и проч.) проводилось обучение временных рабочих групп (ВРГ) численностью 25-30 человек. Некоторые участники когда-то занимались «описанием» процессов при помощи «диаграмм с ромбиками» (в Business Studio – это нотация «Процедура) или сталкивались с нотацией eEPC. Но большинство специалистов созданием графических схем не занимались.

Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» (В.В. Репин, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN. Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.

Во второй день рассматривались более сложные примеры и выполнялось комплексное задание на описание группы связанных между собой процессов. Это задание выполнялось в небольших рабочих группах по 2-3 человека. После описания процессов группы выполняли анализ качества моделей на основе чек-листа. Проводился разбор ошибок.

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

Требования и правила моделирования устанавливались в «Соглашении по моделированию» компании.

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

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

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

Типовые ошибки моделирования, допускаемы начинающими

Проблема мышки

Первая и, вероятно, самая главная проблема при моделировании процессов в нотации BPMN начинающими – это проблема «Мышки» (я использую этот термина на обучении вместо токена). Для многих сотрудников понимание сути потока работ и мышки, которая бегает от одной операции процесса к другой по стрелкам типа sequence flow, является довольно сложным. Но если не концентрировать внимание на потоке и не отслеживать мысленно различные пути мышки, то можно упустить из вида многие детали реального процесса. Модель в этом случае становится весьма неточной. В ней упускается множество практически важных моментов. В результате, схема вроде как нарисована, но ни выполнить ее анализ, ни обосновать изменения нельзя. Это одна из причин разочарования некоторых руководителей в графических схемах бизнес-процессов как в практическом инструменте развития бизнеса.

Оборванные входы-выходы

Следующая проблема – это оборванные входы-выходы. У неопытных и довольно безответственных рисовальщиков документы появляются «из воздуха», «зависают» на выходе операций процесса и никуда не попадают. Часто начинающие вообще не показывают на схеме потоки документов/информации.

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

Обсуждая входы/выходы можно отметить два аспекта. Технически на схеме в нотации BPMN в среде Business Studio можно показывать взаимодействие между разными процессами при помощи стрелки типа massage flow, связывая конкретную операцию процесса со свернутым пулом (другой процесс). Для последующей возможности вывода информации о входах/выходах в отчеты к этой стрелке должен быть привязан конкретный документ. Часто неопытные пользователи забывают это делать. Но сама по себе стрелка massage flow без привязанного к ней документа с точки зрения комплексной модели в Business Studio не несет конкретной информации.

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

Бывает обратная ситуация – на модели верхнего уровня входы/выходы есть, а при переходе на уровень вниз на процессы, описанные в нотации BPMN, эти входы/выходы теряются. Иногда на моделях нижнего уровня в нотации BPMN показывают информационные связи с процессами уровня + 2 выше. Как следствие – низкое качество модели компании в целом.

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

На мой взгляд, наличие потока документов на схеме процесса в нотации BPMN в Business Studio необходимо и практически полезно для целей анализа, регламентации и автоматизации.

На рисунке 1 приведен фрагмент схемы процесса с «оборванным» входом для операции «Проверить корректность заполнения заявки». Для операции «Проверить возможность выполнения заявки по режиму» входы/выходы вообще отсутствуют.

Некорректная логика процесса

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

Непонимание межпроцессного взаимодействия

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

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

Вторая проблема состоит в том, что отправку сообщений между разными процессами начинают показывать везде, где только можно, причем без всякого содержательного смысла:
• отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) – с ним просто есть взаимодействие по входам-выходам (причем, чаще всего, опосредованное – через базу данных или файл-сервер компании);
• отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел такой-то…» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
• отправляют сообщение в процесс, который находится в дереве на 2-3 уровня выше описываемого и сформирован в нотации IDEF0 – отправка «на деревню дедушке»;
• показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.

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

Использование таймеров

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

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

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

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

Процесс в процессе (рекурсия)

Довольно часто можно наблюдать такую картину. Берем для анализа процесс под каким-то названием. Начинаем смотреть его детальную схему в BPMN. Видим кучу действий с бумажками (служебки, распоряжения, отчеты, поручения и проч.). Где-то среди всей этой волокиты видим операцию, название которой в точности повторяет название процесса в целом. И это называется описать процесс! Проблема в том, что работу, реально добавляющую ценность, обкладывают бумажками и «закапывают» на нижний уровень, описание которого проектом не предусмотрено. Эту ошибку допускают очень многие, даже довольно опытные, сотрудники и бизнес-аналитики! Кстати, наличие таких моделей, как правило, означает, что модель вышестоящего уровня архитектурно плохо выстроена.

Красота схемы

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

Накопление опыта и исправление ошибок

По ходу выполнения проекта сотрудники накапливают опыт моделирования процессов. Степень проработки и качество моделей процессов становятся существенно выше. При интенсивной работе ВРГ (2-3 модели процессов в неделю), через 1-1,5 месяца можно говорить о приемлемом уровне качества описания моделей процессов.

Хотел бы отметить, что для освоения навыков моделирования процессов на операционном уровне (в нотации BPMN) очень полезно показать сотрудникам имитацию выполнения процесса в Business Studio. Еще лучше, если после этого они сами попробуют запустить на имитацию отрисованный ими процесс, причем сначала пошагово, чтобы почувствовать себя той самой «мышкой» (токеном). Это упражнение дает хорошее понимание сути моделирования процессов Work Flow.

Выводы

При использовании минимального набора объектов и маркеров, нотация BPMN вполне доступна для изучения сотрудниками, не имеющими опыта графического описания бизнес-процессов.

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

1. «мышка» или идеология исполняемых процессов;
2. информационное взаимодействие внутри процесса и между процессами («стыковка по входам/выходам»);
3. корректное использование событий отправки-получения сообщений и синхронизация процессов между собой по событиям;
4. соблюдение уровней при описании межпроцессного взаимодействия (процесс BPMN может отправить сообщение только в процесс BPMN);
5. корректное использование событий-таймеров;
6. четкое отслеживание множественных объектов для обработки;
7. визуальная наглядность схемы («Красота схемы»).

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

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

Важно отметить, что осознанность и мотивация на качественный результат у участников ВРГ – так же критически важные аспекты моделирования бизнес-процессов.

В целом, с учетом опыта выполненных проектов, можно сделать вывод, что комплексное описание бизнес-процессов силами собственных сотрудников организации в нотации BPMN в среде Business Studio возможно и практически целесообразно.

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»

Сентябрь 2018 г.