О бизнес-процессах говорят и пишут много и регулярно. Множество консультантов и всяческих гуру процессного управления рассказывают на просторах интернета о том, как сделать клиента (или вашу компанию) эффективной и прогрессивной за счет оптимизации этих самых бизнес-процессов, продвигают ту или иную нотацию и инструмент, или просто выдают полный структурированный набор теорий и терминов, показывая свою компетентность в этом вопросе.
Но почему-то, когда речь заходит о решении конкретной бизнес-задачи на конкретном предприятии, заказчик или руководитель проекта ломают голову, бегают по рынку труда в поисках консультантов и бизнес-аналитиков, которые «сделают им счастье». И потом жалуются на то, что вот уже два года идет анализ и совершенствование процессов, все руководители устали от интервью и нескончаемых рабочих сессий, процессы, которые все так хотели улучшить, уже давно поменялись естественным путем, а результата как не было, так и нет.
А если речь идет о проекте по автоматизации, задача усложняется на порядок. Ведь зачастую за счет внедрения ERP системы заказчик хочет решить бизнес-проблему: снизить издержки, сократить ненужные запасы и неликвиды, повысить скорость обработки заказов клиентов (не ради скорости, а для того, чтобы обрабатывать больший товаропоток при тех же технических и технологических условиях). Ну и конечно при этом увеличить доходность предприятия (т.е. как минимум выручку, а как максимум- маржу в пересчете на одного сотрудника). И в последнее время многие заказчики как-то начали понимать, что без четко выстроенных правил работы предприятия автоматизация не очень помогает. Т.е. нужно провести программу проектов «оптимизация плюс автоматизация». Причем желательно к следующему учетному периоду (т.е. за год, максимум за два).
Есть ли у этой задачи быстрые и технологичные решения?
Я занимаюсь бизнес-процессами примерно с 98го года. Ну то есть, страшно сказать – «с прошлого века» :), и уже лет двадцать. Последние лет десять – в составе проектов по автоматизации управления. И каждый раз, работая с заказчиком, нахожу что-то новое: в самих бизнес-процессах, в разрезах их анализа, в подходах к их описанию и улучшению. И, наверное, смело могу сказать: «волшебной таблэтки» (или «серебряной пули», - кому как нравится) в этом вопросе нет.
Есть разные подходы к тому, как выделять и классифицировать эти самые бизнес-процессы, есть с десяток разных нотаций, в которых их можно описывать, есть целый ряд правил, по которым следует выявлять зоны неоптимальности и предлагать улучшения. Но, как говорилось в одной старой рекламе, нужна еще «совесть пивовара». То есть мозг и аналитические способности того самого бизнес-аналитика. По сути, мы с вами получаем в руки ящик с инструментами. А профессионализм аналитика заключается в выборе того инструмента, который лучше всего подойдет для конкретной бизнес-задачи конкретного предприятия. И умении правильно его применить, как в известном анекдоте: «1 рубль за удар, 10 000 - за знание, куда ударить».
Поэтому я хочу поделиться результатами осмысления собственных проектов и теми правилами, которые считаю важным и нужным учитывать при анализе и оптимизации бизнес-процессов:
1. Проект по анализу и оптимизации бизнес-процессов не может продолжаться долго. Иначе заказчик устает, процессы меняются и все теряет смысл. Сам анализ процессов должен занимать месяца три-четыре, не более. А вот оптимизация, т.е. переход к целевому состоянию может длиться дольше (по моему опыту, от полугода до года). Но при этом давать какие-то осязаемые результаты каждые 2-3 месяца. Поэтапная классическая схема: «сначала описываем «как есть», потом оптимизируем «как надо», потом внедряем изменения и только потом автоматизируем» не работает. Слишком быстро сейчас меняется окружающая нас реальность. А это означает, что нужно:
1) Уметь «дробить» (т.е. декомпозировать) процессы на логические этапы (подпроцессы) и проводить улучшения по этапам процессов на более коротких отрезках;
2) Выделять при анализе корневые проблемы. Т.е. те болевые точки, устранение которых даст максимально быстрый и полезный эффект. Но при этом учитывать связи изменяемой зоны со всей деятельностью компании, чтобы не получился неуправляемый «эффект бабочки» (кто не знает, что это такое, почитайте Р. Брэдбери);
3) Нужны максимально технологичные и при этом простые инструменты описания бизнес-процессов, которым можно научить не только ваших аналитиков, но и сотрудников заказчика. Это позволит сократить время на сбор начальных данных и получить стандартизованный и структурированный массив для аналитиков более высокого класса, которые собственно и будут заниматься оптимизацией и формализацией целевых моделей.
2. Задачи, которые хочет решить конкретный бизнес-заказчик, с одной стороны, типовые, с другой - всегда имеют свои уникальные особенности. Как говорится, тараканы у всех одинаковые, только размер и цвет разный. Поэтому выбор нотации для описания бизнес-процессов, а также технологии их изменения зависит от целей проекта и специфики управления на конкретном предприятии. Кто-то воспринимает только графические схемы с минимальным содержанием «фактуры», а кто-то хочет детальных сведений «почему и откуда вы вытащили такую проблему». Кто-то хочет экспертного решения «под ключ», а кому-то важно участие и вовлечение сотрудников в изменения. НО!!! У всех бизнес-процессов есть ключевые элементы, которые подлежат анализу и последующей оптимизации:
- действия и их последовательность
- субъекты, отвечающие за действия (т.е. должности предприятия)
- информация, появляющаяся в результате каждого действия, и способ ее отражения
- движение информации между процессами, т.е. поставщики информации, входящей в процесс, и потребители информации, выходящей из него.
Выбор нотации для моделирования определяется тем, что именно нужно анализировать и оптимизировать. Но в проектах автоматизации как правило нужно учитывать все перечисленные элементы:
- последовательность действий + информационный результат дают нам потоки данных в информационной системе
- действия + субъекты дают нам ролевую карту и настройку прав доступа
- движение данных между процессами дают нам требования к интеграции подсистем, которые, увы, построены по функциональному принципу и не всегда учитывают сквозные связи между процессами.
А вот выбор технологии оптимизации и формирования целевых моделей для последующей настройки в информационной системе определяется наличием или отсутствие правил выполнения бизнес-процессов. Т.е. регламентов и методологии. Например, методики расчета себестоимости продукции или ценообразования. Если на предприятии есть четкие правила- можете смело использовать экспертный подход.
А если их нет или они размыты, придется запускать рабочие группы с участием специалистов заказчика. Ведь только они смогут выработать правила, которые устроят бизнес, и которые потом станут частью настроек при автоматизации.
Проверить наличие или отсутствие правил можно через входы-выходы процесса. Ведь методика расчета себестоимости должна где-то формироваться, и передаваться в соответствующий бизнес-процесс в виде документа. И вот мы возвращаемся к выбору нотации для моделирования.
3. Информационная система является инструментом поддержки и фиксации порядка выполнения бизнес-процессов. Как в части закрепления ответственности за отдельные участки, так и в части установки маршрутов движения данных и правил их трансформации. Поэтому оптимизация процессов и их автоматизация суть части одного проекта повышения бизнес-эффективности. Одно без другого не приносит нужного результата. А это означает, что:
1) В вашей команде должны быть специалисты, которые имеют представление:
- как функционирует бизнес в целом
- какие данные и где должны генерироваться, чтобы в итоге попасть в отчетность для принятия управленческих решений
- как правильно нужно распределять ответственность между подразделениями, чтобы не создавать поводы для коррупции, удовлетворения личных интересов и пр.
И эти специалисты должны быть вне системы заказчика. Иначе если бы у заказчика был собственный бизнес-архитектор, они бы не обратился к вам. Если же у вас нет такого специалиста, нужно иметь в технологии описания бизнес-процессов такие правила, которые позволят вам хотя бы увидеть критичные точки и привлечь необходимые компетенции на этапе проектирования целевой модели (процессов и системы).
2) При анализе и формализации бизнес-процессов необходимо сразу фиксировать требования к их поддержке в будущей информационной системе. Причем наглядно и в привязке к конкретной процедуре/операции, из которой эти требования следуют. Это позволит вам не потерять важные задачи по настройке или доработке системы, сделать их логически обоснованными и иметь возможность всегда определить, почему и для чего нужно то или иное функциональное или техническое требование, как оно влияет на бизнес-процесс.
По сути, вот и все правила. А о том, как их применять, я рассказываю на дистанционной программе «Технология выполнения проектов ERP-класса – процессный подход», которая включает 7 видеоуроков, 2 практических задания, 3 вебинара и 6 документов, которые вы можете использовать в своей практике.
А для руководителей проектов предусмотрен дополнительный модуль «Специфика управления проектом на этапе сбора требований к Информационной системе при применении процессного подхода» со своими видеоматериалами и инструментами.
