«Лекс»

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

Если профессор не может объяснить семилетнему ребенку, чем он занимается – гоните его, он шарлатан.
Народная мудрость

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

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

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

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

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

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

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

• Операция – минимальная для анализа часть деятельности отдельного сотрудника, выполняемая им без проведения осознанного контроля за счет «автоматизации» с помощью их многократного повторения, например: переключить скорость или нажать "Ctrl B", в редакторе MSWord, чтобы выделить слово жирным текстом. Естественно, что любая операция когда-то была действием.
• Действие – несколько последовательно выполняемых операций, после выполнения, которых исполнитель осуществляет осознанный контроль. Например, припарковаться или выписать разовый пропуск. Причем, выделяя операции и действия необходимо ориентироваться не на уровень начинающего работника, а на уровень профессионала.
• Процедура – несколько последовательно выполняемых действий выполняемых конкретным исполнителем. У процедуры должен быть результат, в зависимости от процесса он может быть документом, вещью или недокументированной информацией (устное сообщение, электронное письмо, факс…)
• Бизнес-процесс базового уровня – последовательность взаимосвязанных процедур, выполняемых различными исполнителями и приводящая к получению законченного и значимого результата для организации. Например, заключенный договор, акт сдачи-приемки, товар на складе и т.п.
• Направление деятельности – укрупненная часть деятельности организации, состоящая из одной или нескольких групп бизнес-процессов базового уровня.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Михаил Гордеев, Андрей Борисов, Коршак Наталья
Источник: http://www.treko.ru/show_article_1300