В последнее время прочно вошли в нашу бизнес жизнь такие слова, как бизнес-процесс, AS IS, TO BE, реинжиниринг, оптимизация процессов. Сколько дискуссий, сколько полемики. Одних только систем описания процессов можно насчитать десятки. Есть специальные методики описания, есть специальные программы. Наверное, уже есть экзамены и дипломированные бизнес аналитики, которые виртуозно владеют джиу-джитсу, ARIS и IDEF.

А кто-нибудь задумывался на тему, а что дальше?

Вот описали процессы, кому это теперь отдать, кто без этого не сможет работать? Архивариус? Ну да, ему давно в архив не передавали таких красивых документов, от которых так и «тянет» интеллектом. Можно передать генеральному директору, он посмотрит, отдаст в канцелярию и? Не мучайтесь, по моему опыту могу сказать, что будет дальше. Вероятность 90%, что документы полистают и уважительно положат на угол стола. Когда они надоедят руководителю, то он их отпишет в подразделения с резолюцией – «к исполнению». В подразделениях посмотрят, покрутят, и положат на полку. В 10% случаях руководитель передаст документы в канцелярию, и те будут решать в течение нескольких месяцев логическую задачку, что же с этим делать. Это и не приказ, и не регламент, и не меморандум… Что же это? В итоге они оформят это как инструкцию, дадут ей номер и прикрепят к делу №Х.

Так что же такое бизнес-процессы и кому они нужны.

Первое, что приходит на ум, так это ИТ. ИТ дали такой толчок развитию методик описания бизнес-процессов. Это все родилось из потребности программистов зарисовать алгоритм системы перед ее созданием. Это как чертеж или принципиальная схема. Когда-то зарисовывали в блок схемах бизнес потребности, потом, развив эту тему, начали говорить об оптимизации процессов, модели AS IS и TO BE. Получается, что данные описания бизнес-процессов нужны программистам? Думаю, это не совсем так. Программисту нужен список «фич», из которых состоит программа. А декомпозировать бизнес-процессы на функциональные требования задача не из легких. Что от всего этого описания процессов может пригодиться, так это список процессов для систематизации требований соответственно.

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

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

Не может же быть это Великим Модным Заблуждением? Но почему нет? Наверное, может. Проиграются компании и перестанут играть. Будет новая Большая Идея, и будут все массово писать книги о Большой Идее, внедрять Большую Идею и строить бизнес в соответствии с Большой Идеей.

Может быть, есть здравое зерно в описании и создании бизнес-процессов?

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

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

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

Так неужели формализованные бизнес-процессы бесполезны?

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

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

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

Похожие записи

• Теоретические основы описания бизнес-процессов