Дата выпуска

04.12.2006

№ 10

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

 

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

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

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

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

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

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

1) Операция — это минимальная из анализируемых частей деятельности отдельного сотрудника, выполняемая им без проведения осознанного контроля, «машинально», автоматизм ее выполнения приобретается за счет многократного повторения (например, переключить скорость или нажать Ctrl+B в редакторе Microsoft Word, чтобы сделать начертание слова полужирным шрифтом). Любая операция когда-то была действием.

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

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

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

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

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

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

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

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

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

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

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

Затем договор попадает к юристу, который проверяет его правомочность. Он определяет, не противоречит ли договор законодательству, не нарушены ли интересы компании, сможет ли компания выиграть дело в суде, если оно будет возбуждено. Юрист также подтверждает своей подписью то, что он проверил договор, а значит, несет ответственность за правомочность данного договора.

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

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

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

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

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

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

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

Параметры оценки оптимальности

Как вы думаете, каким образом можно улучшить приведенный выше бизнес-процесс? Для этого нужно понять, кого и чем он не устраивает. То есть если он всех устраивает – то зачем его менять: «Оно восходит? Оно заходит... Оно РАБОТАЕТ? РАДИ БОГА, ТОЛЬКО НИЧЕГО НЕ ТРОГАЙ!!!». А вот если не устраивает – то есть два пути: хвататься за первый же недостаток и быстренько устранять его или, не торопясь, выявить все недостатки и устранить те, что реально позволяют повысить эффективность и реализуемы без революций.

В первом случае директор смотрит на схему, думает и говорит: «Плохо, что передача информации является устной, необходимо подавать замечания в письменном виде за два дня!» Он просит своего секретаря подготовить соответствующее распоряжение. В результате процесс не улучшается, подача замечаний в письменном виде только растягивает и без того длительный процесс согласования, а также отнимает время у всех исполнителей процедур. Раньше специалисты могли быстро устно сформулировать свои замечания, а теперь им приходится письменно выражать свои мысли, что для них мучительно сложно. Форма не задана, образцов нет, навыков, как правило, тоже (из тех исполнителей, которые перечислены на рис. 2, навык письменной речи нужен, пожалуй, только юристу, да и то лишь иногда). Суть процесса и алгоритм принятия решений остались прежними. Кроме того, допустим, что замечания согласующим лицом подаются за два дня. После их устранения Менеджер направляет проект договора на повторное согласование согласующему лицу. Согласующее лицо опять-таки в течение двух дней либо согласует, либо дает новые замечания. И так далее - количество итераций по согласованию не ограничено (то есть на согласование с одним специалистом уходит от 2 до 2*N рабочих дней, где N- количество итераций по согласованию).

Если компания использует технологичный путь устранения недостатков бизнес-процесса (БП), сначала последовательно выявляются все значимые недостатки по заданному набору параметров, потом их сравнивают с критериями оптимальности и в завершении готовят решения по их устранению. Оптимальность процесса оценивается по следующим параметрам:

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

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

Качество конечного результата. Как сидит костюмчик?

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

В рассматриваемом примере клиентов не устраивало два аспекта: время, затрачиваемое на их обслуживание, и уровень понимания их потребности. Заключают договор на высокоскоростное подключение, а в ходе исполнения выясняется, что кабельная линия не обеспечивает требуемого трафика. И клиенту предлагают доплатить за прокладку оптоволоконного кабеля или говорят «подождите весны» (ибо оптоволокно зимой не сваривают). А у него бюджет уже сверстан и он резонно спрашивает: "А где же вы раньше были? При подготовке Договора?". И уже неважно, что юрист предусмотрел нужный пункт в Договоре – лояльность клиента потеряна, и пошло тратиться время начальника отдела продаж, директора и юристов на разрешение конфликтной ситуации.

Руководство компании было недовольно следующим:

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

Кроме того, менеджеры были недовольны тем, что используемые при проведении оценки конечного результата критерии оптимальности были ситуативными. В общем виде их можно было сформулировать с помощью красивой фразы из миниатюры А. Райкина : «Костюмчик должен сидеть, как влитой». Это означает, что надо было продумать защиту по каждому типу рекламаций.

Из перечисленных недостатков логично вытекают первые выводы и рекомендации. Во-первых, следовало отделить от всех остальных договоров стандартные, проверяя которые директор может посмотреть только на сумму, а договоры нестандартные помечать особо. Во-вторых, зафиксировать и сделать известными каждому менеджеру параметры, по которым он в обязательном порядке должен проверять информацию перед составлением проекта договора, чтобы понять, в какой мере условия выполнения работ соответствуют стандартным. В-третьих, надо было перестать «согласовывать» и четко зафиксировать, кто и что проверяет в проекте. А также ввести различные временные нормативы работы над стандартными и нестандартными договорами: до предела сжать время выполнения всех операций в первом случае и увеличить его во втором. Наконец, необходимо было наладить технологию трансформации нестандартного договора в типовой и продумать алгоритм оценки выгодности нестандартного договора.