Ошибки при проведении исследований бизнес процессов

Типовая ошибка 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 г.

Если на собеседовании вас спрашивают «Имеете ли вы опыт моделирования бизнес-процессов», то в неявном виде вас спрашивают об опыте использования нотации 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

Автор: Елена Иванова, консультант по управлению, руководитель консалтинговой практики ГК «Раздолье».

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

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

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

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

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

Ошибка номер один: отсутствие системного подхода

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

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

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

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

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

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

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

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

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

Ошибка номер два: некорректная система контроля

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

Любой бизнес-процесс имеет определенную длительность во времени. И чем глобальнее бизнес-процесс, тем более длительное время он выполняется. Согласование тех же договоров, по моему опыту, может проходить от нескольких дней (в небольших компаниях) до 2-3 месяцев (если речь идет о крупных гос. корпорациях). Если контролировать результат только по конечной точке (подписан/не подписан договор), через какое-то время вы можете обнаружить, что срок согласования давно прошел, а договор где-то «застрял». И через три месяца довольно сложно разобраться, где застопорился бизнес-процесс и почему это произошло. Результат — компания потеряла контракт или сорвала сроки его выполнения, т.к. позже запустила работу по контракту.

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

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

1) Научиться декомпозировать бизнес-процесс на самодостаточные логические этапы (их обычно называют «подпроцессами» и «процедурами»).

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

3) Построить в компании процедуры сбора данных по этим индикаторам, настроить в информационной системе последовательность выполнения бизнес-процесса и систему ввода данных по точкам контроля.

4) Внедрить автоматическое формирование отчетности или дашборд-панели, позволяющие отслеживать отклонения по контрольным точкам процесса.

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

Ошибка номер три: неправильно закрепленная ответственность за бизнес-процессы

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

1) Излишняя централизация, когда несколько бизнес-процессов, влияющих друг на друга, объединяется под одного руководителя второго или ниже уровня управления.

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

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

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

2) Назначение владельцем бизнес-процесса того, кого «не жалко».

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

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

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

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

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

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

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

Ошибка номер четыре: мотивация как «параллельная реальность»

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

Выстраивание системы мотивации — сложная и многоплановая задача. Существует множество подходов и взглядов на мотивацию. В последнее время все больше получает распространение теория поколений Y, Z и прочее, где основной посыл – материальное стимулирование не главное. Но на мой взгляд правда состоит в том, что люди, которые не хотят зарабатывать деньги, просто не работают (занимаются блогерством, самореализацией и другими различными практиками). А те, которые работают, хотят получать за свою работу доход. Это означает, что на их поведение можно и нужно влиять через влияние на структуру и условия получения дохода.

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

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

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

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

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

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

3) Дискретность оценки и выплаты премии за достижение результата должна коррелировать с длительностью его получения. Если вы премируете за промежуточные результаты бизнес-процесса – это необходимо делать ежемесячно. Если за конечный – зависит от длительности получения результата (возможны квартальные или годовые премии).

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

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

Ошибка номер пять: «есть слона целиком»

Анализ и оптимизация бизнес-процессов не может продолжаться долго. Иначе компания устает, процессы меняются и все теряет смысл. Сам анализ процессов должен занимать от нескольких недель до трех месяцев (если требуются комплексные изменения по многим направлениям деятельности), но не более. А вот оптимизация, т.е. переход к целевому состоянию может длиться дольше (по моему опыту, от полугода до года). Но при этом она должна давать какие-то осязаемые результаты каждые 2-3 месяца.Поэтапная классическая схема: «сначала описываем «как есть», потом оптимизируем «как надо», потом внедряем изменения и только потом автоматизируем» не работает.

Слишком быстро сейчас меняется окружающая нас реальность. А это означает, что нужно:

1) Уметь «дробить» (т.е. декомпозировать) процессы на логические этапы (подпроцессы) и проводить улучшения по этапам процессов на более коротких отрезках.

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

3) Правильно подбирать состав команды, которая будет заниматься этой деятельностью.

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

В заключение, или Ошибка номер шесть

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

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

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

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

Как выстроить деятельность по регулярному мониторингу и совершенствованию бизнес-процессов? Ответ простой: подойти к этому как к бизнес-процессу:

1) Описать эту деятельность в виде бизнес-процесса по всем правилам формализации бизнес-процессов. Для этого в компании должны быть специалисты, компетентные в области процессного подхода, знающие нотации и средства моделирования бизнес-процессов, методы анализа и совершенствования.

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

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

4) Запустить проект по вводу нового бизнес-процесса в регулярную деятельность предприятия.

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

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