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

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

Для начала рассмотрим схему процесса приведенную на рисунке

Пример малоинформативной модели процесса (простая часто встречающаяся схема).

Что мы можем понять из такой схемы без дополнительных комментариев и знания специфики выполнения работ? Увы, очень мало. Все, что мы можем понять, что некто неизвестно как узнает о начале работ и создает проект договора. Этот же некто, отдает проект кому-то на согласование. При согласовании некий другой субъект (или несколько субъектов) как-то проверяет проект договора. Потом кто-то относит его кому-то на утверждение. Причем не ясно, кто переделывает договор в случае наличия замечаний при согласовании и утверждении. Не ясно, что проверяется в договоре, не ясно, зачем создается договор, почему и как…

Не слишком ли много неопределенности и вопросов? Прежде чем привести пример адекватной схемы давайте уточним, на какие вопросы мы не видим ответа:

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

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

Операция — минимальная для анализа часть деятельности отдельного сотрудника, выполняемая им без проведения осознанного контроля за счет «автоматизации» с помощью их многократного повторения, например: переключить скорость или нажать «Ctrl-B», в редакторе MSWord, чтобы выделить слово жирным текстом. Естественно, что любая операция когда-то была действием.

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

Процедура — несколько последовательно выполняемых действий, выполняемых конкретным исполнителем. У процедуры должен быть результат, в зависимости от процесса он может быть документом, вещью или недокументированной информацией (устное сообщение, электронное письмо, факс…)

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

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

Уровни анализа процессов деятельности компании.

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

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

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

• «вход» и «выход» процесса?
• из каких процедур состоит процесс?
• кто выполняет каждую процедуру?
• что получается в результате ее выполнения?
• кто получает результат и что он с ним делает?

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

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

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

Далее договор попадает к юристу. Юрист проверяет, а вообще правомочен ли договор? Не противоречит ли он законодательству, не нарушены ли интересы компании. Если, не дай бог, дело дойдет до суда,— мы сможем его выиграть? И опять же, юрист ставит подпись, говорящую о том, что он договор проверил — а значит, подтвердил свою ответственность за правомочность данного договора.

Далее финансовый менеджер, который проверяет, а, вообще говоря, мы договор заключили верно, с точки зрения финансовой схемы компании? Цена, скидки, условия платежа — согласно утвержденным нормам — или мы делаем клиенту какую-то поблажку? Если делаем — то будьте любезны, объясните почему. И в итоге опять подпись, которая опять же подтверждает ответственность.

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

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

В практике был забавный случай, когда Генеральный директор Управляющей компании группы получил Проект договора согласованный всеми замами, но без названия компании, от имени которой он заключается.

Как вы думаете, отражали данный процесс схема, приведенная на первом рисунке Скажем так — с трудом… Как в романе «12 стульев»: «Это Ваш мальчик?» — «Мальчик… Кто скажет, что это девочка — пусть первым кинет в меня камень!» Конечно, нельзя назвать Кису Воробьянинова девочкой, но и на мальчика он не тянет. На втором рисунке  приведен пример схемы более полно отображающей состояние с заключением договора.

Пример нормального описания процесса «Заключение договоров (на предоставление телекоммуникационных услуг связи)

По такой схеме (при наличии знаний и опыта участия в процессе) уже можно проводить оценку оптимальности».