Личная информация:

Консультировал в области регулярного менеджмента более 70-ти компаний: от 10 до 9.000 человек (включая: холдинги, сети магазинов, фабрики, сервисные компании, строителей, государственных служащих, веб-агентства, интернет-магазины). Ученик Александра Фридмана.

Один из соавторов книги "Социальные технологии Таллиннской школы менеджеров. Опыт успешного использования в бизнесе, менеджменте и частной жизни": http://www.ozon.ru/context/detail/id/140084653/

генеральный директор

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

Конфуций

кому: собственникам, топ-менеджерам, руководителям

Управление процессами через регламенты приводит к управлению «рукой через ногу»

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

• минимизация ошибок со стороны сотрудников;
• стандартизация качества работы;
• ликвидация персоналозависимости;
• возможность каждому сотруднику выполнять работу наиболее эффективным способом.

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

Почему? Сейчас попробую объяснить. Регламент - это описание какой-либо части рабочего процесса (последовательности действий), протекающего в компании: либо процесса целиком, либо нескольких процессов, либо части процесса.

Процесс (синоним “бизнес-процесс”) - это последовательность действий для решения какой-либо типовой задачи (нетиповые задачи относятся к проектам).

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

Процессы делятся на простые и составные. Составные - содержат в себе несколько простых процессов. Ещё бывают сквозные процессы . Так называют процессы, разные этапы которых проходят через несколько отделов компании. В этом обычно и заключается их сложность.

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

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

Почему регламентов недостаточно

• Далеко не все процессы линейные. Многие имеют множество условий “если…, то…”. Сложно быстро разобраться в “полотенце” текста регламента и понять, как этапы процесса связаны между собой . Например, регламент по подбору сотрудников изобилует подобными развилками почти на каждом этапе. В зависимости от должности соискателя собеседование может проходить удалённо или очно, с привлечением его непосредственного руководителя или без.
• Если процесс проходит через несколько звеньев, возникает проблема “кто ответственен за конечный результат”. В случае сбоев и косяков, сотрудники валят вину друг на друга и на обстоятельства, возникает круговая порука.
• Сотрудники не могут договориться между собой о том, кто выполняет какую работу.
• Из-за низкой наглядности (всё тот же гигантский объём текста регламента) крайне непросто заниматься оптимизацией и развитием процесса .
• Значительны затраты времени сотрудников на чтение, изучение, и понимание общей картины и всех взаимосвязей. Регламент редко описывает процесс целиком. Зачастую процессу, проходящему через несколько отделов, соответствуют разные регламенты.

Введение в управление процессами: в каком виде лучше описать процесс?

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

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

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

• Однозначная трактовка схемы участниками процесса.
• Наличие достаточного количества обучающего видео-материала по данной системе обозначений (нотации).
• Перспективы нотации: быстро ли она развивается, насколько используется, будет ли использоваться в дальнейшем или уже “отмирает”

Всем этим критериям, по моему мнению, отвечает нотация BPMN (версия 2.0) . Для отрисовки схем рекомендую использовать бесплатную программу Bizagi Modeler .

И ещё раз про упрощение. Начиная рисовать схемы, вам не обязательно соблюдать стандарт на все 100%, это только усложнит внедрение. На начальных этапах главное, чтобы схемы были понятны участникам и однозначно ими трактовались. Привести схемы в соответствие стандарту вы еще успеете.

Итого, схемы процессов решают следующие задачи:

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

Не забудьте задать цели оптимизации и подсчитать, насколько изменятся затрачиваемые ресурсы у новой версии процесса!

Ключевая фишка процессного управления - ответственный за весь процесс

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

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

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

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

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

За развитие процесса и выполнение всех его копий должен отвечать один человек

Таким образом, есть человек, который несёт ответственность за весь процесс (в том числе и за работу ответственных за копии), а есть люди, отвечающие за выполнение копий. В рамках процессного управления ответственные за копии процесса подчиняются “владельцу процесса”, а ответственным в свою очередь подчиняются участники процесса.

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

Алгоритм описания и развития бизнес-процесса с помощью схем и регламентов

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

Этап 1. Нарисовать и согласовать схему процесса

1. Начертите схему процесса совместно с ответственным за развитие процесса и экспертами из числа ответственных за исполнение конкретных копий процесса. Выделите наиболее критичные точки процесса. У каждого процесса и у каждого этапа на схеме есть “вход” и есть “выход”. При написании регламента учтите, что будет подаваться на вход, а что будет результатом работы.
2. Согласуйте схему со всеми участниками процесса или начальниками подразделений участников.

Пример №1. Схема процесса “Подбор сотрудников” в нотации BPMN

Пример №2. Часть схемы “Подбор сотрудников” в нотации BPMN

Этап 2. Написать регламент выполнения этапов процесса

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

Пример описания в регламенте одного из этапов схемы процесса

Этап 3. Запустить управление процессом

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

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

В дальнейшем перейдите на бизнес-процессы в Битрикс24 или 1С. Вполне возможно, что их будет более чем достаточно для вашей компании.

Этап 4. Развивайте и оптимизируйте процесс с целью роста эффективности и качества

Как я уже упоминал, за развитие процесса должен отвечать его “владелец” (обращаю внимание, что это не из разряда “хочу/не хочу”, а почётная обязанность сотрудника).

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

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

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

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

Заключение, или Почему «всё и сразу» - это путь на кладбище проектов

Про процессы можно рассказывать много, хватит на целую книгу. Но… кладбища мёртвых проектов заполнены попытками внедрить “всё и сразу” и на самом дорогом и/или многофункциональном программном обеспечении. В лучшем случае сотрудники не использовали внедрённые технологии, или системы получались настолько громоздкими, что работать с ними было невозможно. В худшем - сложности при внедрении так и не позволили завершить работу до конца.

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

Читавшие эту статью, также читали

Время «Ч»: Когда внедрение регулярного менеджмента в вашей компании неизбежно, а оттягивание старта лишь принесёт дополнительные убытки

Сайт производителя товаров и оборудования: 10 типовых ошибок, которые препятствуют поиску новых дилеров и оптовиков

Если вы решили нанять бизнес-консультанта, задайте ему три вопроса. 1. Что он понимает в вашем бизнесе? (Если он не вел данный конкретный бизнес как владелец, он его не знает.) 2. Может ли он своими деньгами ответить за то, что он наконсультировал? 3. Почему он не может устроиться на работу? (Консультантами у нас обычно становятся те, кто не может никуда устроиться.)

Российский предприниматель:

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

Методология прописывания бизнес-процессов очень проста. Надо взять учебник «Основы информатики и вычислительной техники» за 8-й класс и открыть раздел «Алгоритмы». Приведенные там инструкции позволяют прописывать любые процессы, где есть условия и ответы «да» и «нет», делать любые выводы и инструкции в графической форме. Эта методология легко «зашивается» в таблицы Excel. Не надо для прописывания бизнес-процессов использовать сложные инструменты, которых вы сами не понимаете. Объем бизнес-процессов колоссальный, и чем более сложным будет софт, тем больше шансов, что вы запутаетесь. Большой массив данных должен собираться примитивным инструментом.

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

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

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

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

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

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

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

Совет:

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

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

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

Выделите фрагмент с текстом ошибки и нажмите Ctrl+Enter

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

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

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

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

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

Зачем это нужно?

1. Когда хаотичное представление о деятельности предприятия складывается в бизнес-процессы и формализуется на бумаге, становится кристально понятно, какие действия выполняются правильно и вовремя, какие нужно откорректировать, а от каких можно и вовсе отказаться. Становятся заметны точки – генераторы ошибок.
2. После формализации на бумаге становится проще их планировать, представлять «как должно быть».
3. У каждого бизнес-процесса есть владелец и каждое действие в нем закреплено за каким-либо сотрудником (группой). При обнаружении ошибки легко будет идентифицировать «виновного» и вместе предотвратить ее повторное появление.
4. По описанным бизнес-процессам в разы проще вводить в курс дела новых сотрудников. И даже если 60% команды сменится, угроза бизнесу будет минимальной.
5. Внедрение интегрированной информационной системы всегда сопровождается написанием бизнес-процессов.
6. Бизнес с описанными процессами несравнимо проще масштабировать. Открытие филиалов (), подразделений, партнерство, продажа франшиз – вам открыты любые возможности.

Что такое бизнес-процесс

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

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

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

Например, потребителями будут Финансовый директор и Коммерческий директор. Результатом будет сумма просроченной задолженности на конец периода и сумма, которую удалось получить с дебиторов. Владельцем будет Финансовый контролер. Потребители могут устанавливать требования к процессу, такие как периодичность проверки, набор действий по взысканию задолженности, плановая сумма возврата.

Бизнес-процессы бывают:

1. Основные.
2. Вспомогательные.
3. Управляющие.

К основным относятся те, которые создают продукт (производится товар, оказывается услуга). Без их выполнения невозможно существование предприятия, поэтому их нельзя ликвидировать, только оптимизировать.

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

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

1. Составление годового бюджета.
2. Планирование денежных потоков.
3. Проверка потенциальных партнеров и т.д.

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

Как описывать бизнес-процессы

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

Список готовится в три шага:

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

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

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

Рисунок 1 . Как создать из функции бизнес-процесс

Проделав эти действия, вы получите перечень:

• Бизнес-процесс 1 и далее функции
• Бизнес-процесс 2 и далее функции
• И т. п.

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

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

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

Рисунок 2 . Обозначение

Те процессы, которые можно выполнить параллельно, разместите выше и ниже основных.

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

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

1. Для этого на чистом слайде расположите вход и выход из процесса.
2. Разделите лист по горизонтали на области – роли участников.
3. По ролям участников расположите основные блоки – функции процесса. Сохраняйте последовательность выполнения.
4. Добавьте развилки и дополнительные функции.
5. Разместите на схеме документы, которые должны быть сформированы в ходе выполнения. Электронное письмо, excel таблица это тоже документы с точки зрения процесса.
6. Обозначьте используемые программы и базы данных. Желательно писать не название программы, а конкретный блок ПО (например, не 1С а Платежный календарь 1С и т.д.).
7. Добавьте показатели эффективности в процесс там, где они проверяются.
8. Свяжите полученную схему с другими процессами.

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

Рисунок 3 . Пример описания бизнес-процесса

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

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

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

Как найти невыгодные бизнес-процессы

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

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

Минусы описания бизнес-процессов

Помимо множества плюсов описание бизнес-процессов несет в себе и ряд минусов.

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

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

Третий минус – это длительность внедрения. Проект может занимать от 6 месяцев до 1 года.

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

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

Текстовое описание бизнес процессов

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

Плюсы описания бизнес процессов текстом

• Очень просто сделать – просто садись и пиши.
• Не требует специальных навыков – темные времена прошли, теперь писать умеет каждый:)

Минусы

• Текст сложно обрабатывать – работа с массивами текста весьма сложна, ведь нам нужно найти суть, скрытую за словами.
• Затрудняет целостное восприятие процесса: читая вторую страницу, можно уже забыть, что было на первой. Очень тяжело читать текст, описывающий сложный, разветвленный процесс. Приходится постоянно возвращаться назад, чтобы понять, о чем речь. В итоге восприятие картины целиком нарушается.
• Сложно для восприятия – если текст готовит человек без писательских навыков, его прочтение превратится в пытку. У каждого свой язык, и порой он может быть очень сложен. Вы же встречали «плохие» книги? Описание процесса может быть еще хуже:)
• Сложно структурировать и анализировать – процесс может иметь множество путей развития. Это значит, что в зависимости от результатов, событий и условий мы выполняем разные действия в процессе. А теперь представьте, каково это – описывать текстом. Очень сложно сохранить простую структуру, когда у вас десяток «если» на одну страницу. В результате этого анализ потребует от вас огромных усилий и титанической предварительной работы.

Подсказка – используйте структурированные списки

Описание бизнес процессов в виде таблиц

Таблица – это здорово! Таблицы я люблю. Их можно рассматривать часами… и не найти ответ на свой вопрос:) Шучу. На самом деле описание бизнес процессов компании в виде связанных таблиц – это не такая уж плохая идея. По крайней мере, намного лучше текстового описания. Самая большая сложность заключается в том, чтобы подготовить хороший шаблон таблицы, в которую, собственно, потом уже внесут данные.

Плюсы описания бизнес процессов текстом в виде таблиц

• Относительно просто подготовить – подготовить шаблон не так сложно. Главное, чтобы он был понятен тем, кто будет его заполнять. Кроме того, все программы для работы с таблицами (например, Excel) позволяют добавлять описание к ячейкам таблицы. Используйте эту возможность для пояснений данных.
• Относительно просто заполнить шаблон – еще раз, если шаблон понятен, заполнить его не составит труда. Для этого не нужны специальные навыки и знания.
• Наличие структуры – таблица сама по себе уже предполагает некую структуру.
• Удобство обработки цифровых данных – с цифрами лучше всего работать в таблице. Так что для данного типа данных этот тип описания подходит лучше всего. Данные в таблице (даже текстовые) гораздо удобнее сравнивать и анализировать.

Минусы

• Некомпактно – описание больших процессов со всем множеством подпроцессов и элементов будет выглядеть как «простыня». Компактным такой вид назвать сложно.
• Отсутствует необходимая детализация – для того чтобы таблица имела более компактный вид, количество данных должно быть ограничено. Это значит, что даже если вы вносите текст в таблицу, он должен быть ограничен. А значит, добиться необходимой детализации может стать непросто.
• Нет целостности восприятия – большое количество данных не способствует этому. Хотя если необходимо просмотреть данные одной операции (подпроцесса) в строке или данные одного типа в столбце, то лучше таблицы не придумать.
• Сложно отобразить ветвления – та же проблема, что и с текстом. Большое количество ветвлений и, что важно, развитие процесса исходя из условий ветвления довольно сложно отобразить наглядно.
• Требует подготовки – нужно потратить время на подготовку хорошего шаблона.

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

Описание в виде схемы, модели бизнес процесса

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

Плюсы описания бизнес процессов в виде модели

• Простота восприятия – наш мозг устроен таким образом, что картинку мы воспринимаем быстрее, чем что-либо. Поэтому схему воспринимать очень просто. Мозг «фотографирует» схему и обрабатывает ее на бессознательном уровне в разы быстрее, чем наше сознание. Схему воспринимать просто еще потому, что мы сразу видим взаимосвязи элементов.
• Целостность восприятия – 1 схема представляет из себя модель процесса на определенном уровне. Это значит, что схема сразу дает нам представление о процессе в целом. В частности, о его границах, основных элементах и т.д. Если процесс детализируется на нескольких уровнях, то схемы все равно остаются связанными.
• Необходимая и достаточная детализация – в то же время на схеме можно отобразить относительно большое количество деталей без потери качества восприятия.
• Наглядное отображение ветвлений и путей развития процесса – правильно построенная схема сразу дает представление о том, каким путем должен развиваться процесс в правильном варианте. А также другие варианты развития событий.
• Удобство автоматизации – многие программные инструменты позволят переводить диаграммы в языки программирования, что очень сильно упрощает жизнь разработчикам и внедренцам ПО.

Минусы

• Требует специальных навыков – нужно знать, как правильно строить диаграммы. Знать разные нотации. А иногда даже самостоятельно сделать набор элементов и правил, которыми вы будете пользоваться для описания.
• Относительно большое время на подготовку описания – хорошо построенная модель процесса должна быть проста и понятна. Для того, чтобы сделать схему таковой, необходимо потратить кучу времени. Сложно может сделать каждый дурак, а вот простота требует мастерства;)

Инвестиции в графический тип описания окупаются весьма неплохо.

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

В итоге

В итоге вы будете задействовать все типы описания. Документ под названием «Описание бизнес процесса…» будет содержать и графическую схему, и таблицы, и текст. Это нормально. Но мой вам совет – ориентируйтесь на графические модели и избегайте текста. Хорошая модель не нуждается в сопровождении текстом. В большинстве случаев.
Создание бизнес процессов начинается с их описания.

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

1. «Простая блок-схема » (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема » (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на Рис. 1-4.

Рис. 1. Схема процесса в нотации «Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

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

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 2, показаны ниже.

«Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

В целом, применение схем в формате, подобном представленному на Рис. 2, является удобным как для разработчиков, так и для сотрудников, работающих по этим схемам.

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

Второй особенностью схемы процесса, представленной на Рис. 3, является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником — стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.

Такой подход дает возможность:

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

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

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

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 3, показаны ниже.

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.

На Рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.

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

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно рассмотреть приведенный выше пример описания бизнес-процесса в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т. е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

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

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний

При формировании схемы Рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т. п.

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

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

Использование сложных, формализованных нотаций при описании процессов приводит к:

• Трудностям при использовании (интерпретации) схем рядовыми сотрудниками;
• Невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;
• Значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
• Дополнительным сложностям при документировании схем (большой объем и т. п.).

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность