Дьявол скрыт в деталях

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

Скажу сразу, раньше я такого никогда не видел. Я конечно слышал, что есть PMI PMBOOK, и даже прошел соответствующий курс. Что есть 34-й и 19-й ГОСТы. Что есть технологии бережливого производства и экстремального программирования. И какие-то из рекомендаций я пытался применять на разных проектах. Но не было главного - единой методологии, которую можно было бы начать использовать. 

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

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

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

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

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

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

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

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

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

Например, в схеме процесс имеет имя: "П01 Звонок клиенту", а в описании имеет имя: "П 01 звонок клиента". Попробуйте найти ошибку. Нашли? Сколько ошибок? 1? 2? 3? Молодцы, именно три ошибки. Давайте считать. 
1 ошибка: пробел между буквой "П" и цифрами "01"
2 ошибка: слово "звонок" с маленькой буквы
3 ошибка: не правильное окончание слова "клиента"
Дело тут не том, как нумеровать, хотя на это тоже был отдельный регламент, а в том, что процесс должен иметь одинаковое название везде, где на него имеется ссылка. 

Собственно после того как ошибка была найдена президентом, дальнейшая проверка прекращалась. Всем кто подписал документ автоматически шел штраф 100 баксов. И весь пакет документов отправлялся на переделку. Это был единственный руководитель, который, за всю мою практику, ТАК проверял документы. 

В месяц у меня стабильно 500-1000 баксов на штрафы уходило. Дело даже не в штрафах, а в том, что весь пакет документов надо было править, затем заново согласовывать и подписывать. Это было очень трудоёмко. 

Это было непривычно. Я ругался, матерился (про себя конечно). И шел на второй круг. Затем на третий, четвертый и так далее. К пятому мне было абсолютно все равно, есть там ошибки или нет. Я видеть не мог эти процессы. Они мне снились. Я во сне рисовал схемы и корректировал документы. 

Меня хватило на полгода. Затем были новые компании и новые проекты. И никто из руководителей после не уделял столько внимания документам. И вдруг я заметил такую особенность. Каждый раз когда я готовлю какой-нибудь документ, я автоматически проверяю его правильность. Я сразу же вижу ошибки и исправляю их. А уж про документы, которые готовили консультанты на проектах, я вообще молчу - там столько ошибок. Жаль, что я не мог их штрафовать. Поэтому ограничивался указанием на самые критичные. Особенного смысла в них вкладывать своих усилий не было, потому что завтра они уйдут на другой проект и может с ними я никогда больше работать не буду.

Источник: группа "Записки внедренца 1С" (http://www.facebook.com/groups/Zapiski/)