Если вы входите в число тех, кто «готовит телегу зимой», сейчас время это сделать со скидками до 50%.
Вы еще успеваете зарегистрироваться на наши открытые программы до конца года.
Присоединяйтесь, чтобы сделать искусственный интеллект вашим незаменимым помощником в HR.
Находясь на этом сайте, вы соглашаетесь на использование файлов cookie в соответствии с принятой Политикой защиты персональных данных. Если вы не согласны, измените настройки вашего браузера или не используйте сайт.
Отправляя любую форму на сайте, вы соглашаетесь с Политикой защиты персональных данных.
Борисов Андрей Борисович
Гордеев Михаил Юрьевич
Кто стер пыль с моего стола! Там было записано три важных телефона!!!
(Анекдот специалистов по тайм-менеджменту начала 90-х годов)
В смягченных формах похожие на анекдот ситуации нередко происходят в деятельности высшего руководства и приводят к решениям типа «Срочно написать инструкцию по уборке помещения!». Такая инструкция – пример оптимизации регулярно выполняемого бизнес-процесса, только, увы, не самый лучший пример. Его можно назвать оптимизация на основе интуиции.
При интуитивной оптимизации деятельности вообще и бизнес-процессов в частности, как правило, совершается четыре типа ошибок:
Одна из самых распространенных ошибок – уход во второстепенные и несущественные для эффективности деятельности компании детали. На практике это означает решение проблем слабо и очень косвенно влияющих на результаты процессов, но играющих роль «последней капли». Например, когда после очередного срыва срока поставки, начальник отдела доставки оправдывается тем, что всё сделал по Заявке, и директор начинает улучшать форму «Заявки на доставку». Реальная же причина срыва срока скрывается не в форме Заявки, а в процессе и может находиться совсем в другом процессе, например в закупке или продаже и оптимизацию надо начинать с анализа процессов.
Использование интуиции вместо технологий происходит из-за слабой развитости технологий оптимизации бизнес-процессов и их недостаточной распространенности. Кроме того, в тех редких книгах, которые описывают реальные технологии оптимизации, используется слишком сложный язык и слишком много внимания уделяется деталям и формулам. Боле того, очень часто эти книги слишком абстрактны и неконкретны. Хотя на самом деле большинство вполне конкретных и технологичных решений лежат на уровне элементарной логики и их только надо вовремя уметь применять. В результате менеджеры компании, оптимизирующие свои процессы, совершают все возможные ошибки. К сожалению, работы по оптимизации у менеджеров происходят не настолько часто, чтобы процесс научения на своих ошибках приводил к достаточному росту квалификации.
Использование технологии оптимизации процессов не по назначению является прямым следствием неправильного понимания процессной деятельности. К сожалению, после популяризации стандарта ИСО данная ошибка является практически повсеместной и кроется в очень абстрактном определении процессов деятельности, а именно:
Процесс - совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы
Увы, данное определение является очень общим и ровняет «под одну гребенку» всю деятельность: и процессы, и проекты, и задачи, и функции. На самом же деле, деятельность различна и тот или иной тип деятельности имеет собственные инструменты управления. В частности процессы деятельности управляются технологиями описания, оптимизации и регламентации бизнес-процессов. И именно для этого вида деятельности данная технология дает максимально значимый эффект, ощутимый результат. Но данная технология не панацея от всех бед. Так, например, ее применение для проектной деятельности или для несвязных функций крайне ограничено и, как правило, не дает столь ощутимого результата. Для «Задач» же данная технология в принципе неприменима. В итоге эффект от проектов по оптимизации процессов деятельности зачастую равен нулю, так как в той или иной ситуации данную технологию применять было нельзя. Подробнее данную проблему мы рассматриваем в статье про технологию регламентации деятельности.
Наконец личное участие высших руководителей в работах по оптимизации не только отвлекает их от решения более важных задач, но и приводит к снижению инициативы и ответственности со стороны специалистов, снижает качество проработки деталей, а также может уводить в стратегическую область, т.е. в кардинальную перестройку.
Топ-менеджеры не должны своими руками оптимизировать процессы – это дело специалистов. Но руководители должны понимать, как работают специалисты для того, чтобы своевременно выделять проблемы, а затем правильно ставить задачи и принимать результаты.
В этой статье мы хотим дать краткий обзор основ технологии оптимизации именно для того, чтобы уважаемые читатели журнала могли понимать как принципы, так и основные правила оптимизации бизнес-процессов.
«...Мы наш, мы новый мир построим, Кто был ничем, тот станет всем!»
При внесении изменений в деятельность компании руководитель вынужден балансировать между двумя крайностями. С одной стороны – есть опасность сломать непродуманным решением налаженные и устоявшиеся процессы. С другой – есть желание повысить эффективность максимальным образом, т.е. разрушить все "до основанья, а затем..." построить что-то кардинально новое. Именно на второй парадигме основывался активно пропагандируемый ещё несколько лет назад реинжиниринг бизнес-процессов.
В учебниках по реинжинирингу бизнес-процессов приводились замечательные примеры многократного улучшения эффективности деятельности крупных международных компаний. Например, как IBM в разы ускорило процесс рассмотрения заявки на предоставление персональных компьютеров в кредит.
История с сокращениями выглядит так: Как-то раз Члены Правления Корпорации заинтересовались, почему средний срок рассмотрения заявки на предоставления персоналки в кредит составляет чуть ли не полтора месяца. В общем-то, за это время большая часть потребителей успевает приобрести такую мелочь (1-2 тысячи долларов) другим путем. Для проверки бизнес-процесса члены Правления решили провести эксперимент: тут же на заседании заполнили по Заявке и попросили отнестись со всем вниманием. Естественно, что на следующий день они получили уведомление о предоставлении кредита.
"Значит, умеем – когда надо" – решили члены Правления и приказали провести анализ бизнес-процессов. А анализ показал, что каждую Заявку проверяют несколько отделов, каждый по своему аспекту (кредитная история, задолженности, имущество и т.п.). Причем рассмотрение идет последовательно через каждый отдел. Пачка свежих заявок поступает в очередной отдел и эксперт начинает анализ: "Всё ясно - давать, всё ясно – не давать, так интересный случай надо разобраться..." И пока он разбирается вся пачка, включая даже те, по которым он уже принял решение – ждёт. И так в каждом отделе! (Кстати, Вам это ничего не напоминает?)
Решение было простым по сути и реинжиниринговым по реализации. Каждый отдел сформулировал набор четких правил, по которым можно было однозначно понять: давать, не давать или надо разбираться. Далее специалисты разработали многотерминальную экспертную систему, за терминалы посадили операционисток (естественно обучив по специально разработанной программе). И процесс стал выглядеть так: Заявка поступает к операционистке, она вводит данные в экспертную систему, система выдает одно из трех решений: давать, не давать по следующим основаниям (текст отказа прилагается), направить на анализ в следующие отделы (перечень отделов). В результате клиент получал ответ за несколько дней: приходите, вам отказано или подождите ещё несколько дней. Результаты: сокращение сроков привело к росту продаж, плюс экономия на экспертах, которым нашли более квалифицированную работу.
В примере налицо кардинальное изменение процесса и повышение эффективности в разы. Самое интересное, что практически любой руководитель в своей работе много раз использовал аналогичный прием: когда можно сформулировать четкие правила принятия решения. Например, при предоставлении скидок: если доставка за 5 дней – скидка 3%, если за 10 – 5%. Как только появляются такие правила – принятие решения делегируется вниз и это дает эффект в экономии, ускорении, качестве... Только реализация обычно бывает проще: без экспертной системы и сокращения специалистов. Ну и без многократного роста эффективности.
Этот прием – является одним из результатов оптимизации бизнес-процессов. Неторопливой и кропотливой работе по постоянному улучшению деятельности Компании.
Отличие оптимизации от реинжиниринга в данном случае – это скорость получения результата, объем работ и суть изменений. Говоря просто, при оптимизации одно правило быстро доводится до исполнителя и настраивается на ходу. При реинжиниринге тщательно и долго разрабатывается взаимосвязанная система правил, потом она проверяется и часто реализуется с разработкой и внедрением различных форм автоматизации.
Известный гуру в области бизнес-процессов Том Давенпорт выделяет следующие различия между реинжинирингом и оптимизацией (усовершенствованием) бизнес-процессов:
Таблица 1.
Наименование параметра | Оптимизация | Реинжиниринг |
---|---|---|
Уровень изменений | Наращиваемый | Радикальный |
Начальная точка | Существующий процесс | «Чистый лист» |
Частота изменений | Непрерывно/единовременно | Единовременно |
Требуемое время | Короткое | Длительное |
Направление | Снизу вверх | Сверху вниз |
Охват | Узкий, на уровне функций | Широкий, межфункциональный |
Риск | Умеренный | Высокий |
Основное средство | Статистическое управление | Информационные технологии |
Тип изменений | Культурный | Культурный/Структурный |
У каждого подхода есть свои плюсы и минусы. Однозначного ответа на вопрос: "С какой скоростью надо менять бизнес-процессы" нет. Ответ сильно зависит от конкретной ситуации в Компании.
Реинжиниринг нужен в тех случаях, когда на рынке произошли существенные изменения. Приведем несколько примеров:
Оптимизация или улучшение бизнес-процессов нужно совершенно в других ситуациях. Когда поводов для особого беспокойства нет, но есть небольшие досадные накладки и недостатки в деятельности любимой компании: товар приходит с опозданием, только десятая часть переговоров заканчивается продажей и т.п.
Показывая различие между оптимизацией и реинжинирингом процессов, необходимо уточнить, что выше мы описали две крайние точки на оси, между которыми, конечно, есть много переходных состояний. Например, глобальная оптимизация процессов или частичный реинжиниринг. В последние годы мы в своей работе все чаще сталкиваемся с ситуацией глобальной оптимизации плавно перетекающей в реинжиниринговые решения.
Холодная война. Американцы выкрали в СССР чертежи вертолёта, собрали - Паровоз. Изучили внимательно чертежи, опять собрали... Опять Паровоз. Привлекли лучших инженеров, собрали всё в точности по чертежам... Паровоз. Отчаявшись, выкрали русского инженера Васю. Вася два дня просидел в гараже, на третий открывается дверь гаража... Вертолет. Американцы в шоке:
- Как это у тебя получилось?
- Ну тут же на чертеже в правом нижнем углу ясно написано: "После сборки обработать напильником".
Обычно работой по оптимизации занимаются высшие руководители, привлекая к проработке решений своих подчиненных с особо аналитическими мозгами. Причем занимаются в фоновом режиме, используя такие инструменты как интуицию, здравый смысл и, естественно, свой богатый управленческий опыт. При таком подходе говорить о целенаправленном улучшении бизнес-процессов сложно. Это скорее творческий процесс со своими взлетами и падениями, свершениями и неудачами. Увы, с практически не передаваемым опытом. Чтобы его получить - нужно найти "гуру" (авторитета) и начать с ним работать, а в статье можно только приводить примеры и потихоньку на них учиться.
Столкнулись с проблемой в отделе продаж: клиент обращается с заказом партии стоек для продажи, в ходе предпродажной подготовки получает дизайн-проект (бесплатно) и не размещает заказ. Потом выясняется, что почти такую же конструкцию он разместил в другой компании. Стали формулировать правила выявления не-добросовестных клиентов на ранних стадиях переговоров и вот, что получилось... Далее пример конкретного решения и т.п.
Наша статья описывает оптимизацию процессов не как высокое искусство «Hot couture», а как технологию, по-этому таких примеров в ней не будет.
В последние годы появилось много специалистов именно по вопросам оптимизации деятельности: директора по развитию их подчиненные и консультанты. Эти специалисты не только накопили большой опыт решения задач оптимизации, имеют специальное образование, но и владеют технологиями оптимизации.
Технология в отличие от искусства – это последовательность действий, которая приводит к гарантированному получению результата и может быть передана другому человеку за короткий промежуток времени. Понятно, что технология не поможет создать шедевр мирового уровня типа "Черный квадрат" Малевича (1,5 миллиона долларов), но на окрашенной, с соблюдением соответствующей технологии в черную краску классной доске (500 рублей), действительно можно будет писать мелом, так чтобы написанное могли прочитать и ученики на задней парте, а не только учитель. И эти доски действительно можно будет регулярно производить, «с регулярным качеством» и «регулярной прибылью».
Мы понимаем, что топ-менеджеры не должны своими руками оптимизировать процессы – это дело специалистов. Но руководители должны понимать, как работают специалисты для того, чтобы правильно ставить задачи и принимать результаты. В данной статье мы хотим ознакомить вас с базовой частью технологий по оптимизации бизнес-процессов. Необходимо учитывать, что технологий гораздо больше, чем может включить статья. Да и понятны многие из них только специалистам. Задача же данной статьи просто и доходчиво рассказать о том, как сделать оптимизацию бизнес-процессов не инструментом «Малевичей в бизнесе», а простым и доступным способом управления процессной деятельностью организации.
Мышей коршуны заклевали... Надоело это мышам и пошли они к сове:
М: Сова, ты такая умная, скажи нам: как сделать так, чтобы нас коршун не трогал и не обижал?
С: Взлетите выше коршунов – и никто Вас не тронет!!!
М: Вау! Молодец сова. Так и сделаем.
Пошли на поляну, лапами махали, махали, хвостиками крутили, крутили… ничего не выходит. Вымотались, устали, от налетевших коршунов даже убежать не смогли. На следующий день приходят и спрашивают:
М: Сова, а как же нам взлететь-то... Выше коршунов-то??? А?
С: Вот достали!... Идите отсюда, я стратег, а не тактик!
Зачастую, во многих компаниях, проекты по оптимизации бизнес-процессов переходят из разряда простой и понятной технологии в область высоких материй и искусства. Происходит это ввиду различных причин. В начале нашей статьи мы вкратце их рассмотрели. К сожалению, необходимо сказать, что часть компании сами себе создают проблемы, когда начинают применять не те технологии, не для тех целей. Так, например, многие компании пытаются применить постулаты стандарта ИСО, для оптимизации своих процессов деятельности.
Учитывая то, что сам стандарт ИСО очень абстрактный, общий и расплывчатый (из серии «искусства»), да и дает он «сертификат качества», а не технологию управления процессной деятельностью, то использование его постулатов для оптимизации бизнес-процессов в лучшем случае бесполезно. Но наши компании не ищут легких путей и простых решений. Поэтому обычно проекты по оптимизации в компаниях начинаются со споров о «высоком». Спорят руководители, спорят менеджеры, спорят топы. Но деятельность, оптимальность деятельности сосредоточена не на верхнем уровне – она сосредоточена на уровне конкретных исполнителей. В итоге, когда через несколько лет проекта по оптимизации дело наконец—то доходит до тех, от кого в большей степени зависит и оптимальность и качество, то ответы на свои вопросы «а как это теперь надо делать?», они, к сожалению, слышат как в анекдоте «достали… я стратег, а не тактик».
И вот чтобы оптимизация бизнес-процессов была не искусством, а стала вполне четкой, понятной и простой технологией, причем технологией уровня «тактики», для этого в следующих главах статьи мы попытаемся рассказать, что есть технология оптимизации бизнес-процессов. К сожалению, рамки статьи не позволяют нам рассказать весь четырехдневный семинар по данной теме, поэтому материал придется давать очень сжато.
Надеемся, что это не помешает восприятию читателей и все будет понятно и технологично.
Начнем описание базовых технологий с принципов, без соблюдения которых оптимизация превращается в рас-суждения на уровне здравого смысла… или высокое искусство. И так, четыре главных принципа оптимизации бизнес-процессов:
Принцип первый: У оптимизации должна быть основа. Он означает, что перед оптимизацией надо придать жесткость бизнес-процессам. Оптимизировать хаос может только Бог. Человеку надо сначала "увидеть" ход протекания процессов, т.е. зафиксировать их в виде моделей "Как есть". Причем, если описать процессы, происходящие в настоящее время, не удается, например, из-за их высокой изменчивости, то и оптимизировать нечего (В данной ситуации можно выстраивать процессы заново, оценивая на оптимальность и улучшая уже новые процессы).
Принцип второй: При оптимизации "рыбу чистят с хвоста". Данный принцип означает, что оценку оптимальности надо вести от частного к общему. Выявляя отдельные недостатки, объединяя их в связанные группы и оперативно исправляя. А вот, если вам лично ближе подход "от общего к частному", то вам нужен реинжиниринг, т.е. комплексное, системное, "до основанья..."
Принцип третий: Решения по оптимизации – неоднозначны. Это значит, что устраняя неоптимальность по одному критерию, мы с высокой вероятностью ухудшаем процесс по другому. Об этом мало знать надо ещё и уметь выявлять такие последствия, оценивать преимущества и недостатки и делать обоснованный выбор. Принцип четвертый: Сотрудники не любят оптимальные процессы. Настоящая оптимизация процессов неизбежно усиливает эксплуатацию исполнителей, поэтому неизбежно явное и неявное, часто даже неосознаваемое людьми сопротивление.
Из данных принципов достаточно логично следуют условия и шаги проведения оптимизации:
Если профессор не может объяснить семилетнему ребенку, чем он занимается – гоните его! Он шарлатан.
Американская народная мудрость
Итак – главное условие успешности технологичной оптимизации – наличие модели или схемы процесса. Рассмотрим требования к схематическому представлению процессов. Вообще-то их очень много и даже есть общепризнанные специалистами нотации или языки описания. Сейчас остановимся на основных требованиях. Для начала рассмотрим схему процесса приведенную на рисунке 1.
Что мы можем понять из такой схемы без дополнительных комментариев и знания специфики выполнения работ? Увы, очень мало. Все что мы можем понять, что некто, неизвестно как узнает о начале работ и создает проект договора. Этот же некто, отдает проект кому-то на согласование. При согласовании, некий другой субъект (или много) как-то проверяет проект договора. Потом кто-то относит его кому-то на утверждение. Причем не ясно, кто переделывает договор в случае наличия замечаний при согласовании и утверждении. Не ясно, что проверяется в договоре, не ясно зачем создается договор, почему и как...
Не слишком ли много неопределенности и вопросов? Прежде чем привести пример адекватной схемы давайте уточним, на какие вопросы мы не видим ответа:
Успешность оптимизации во многом зависит от точности и глубины понимания текущей ситуации. Для этого необходимо собрать и структурировать оптимум информации о деятельности.
Для того чтобы мы собрали именно оптимум информации, т.е. не мало, но и не слишком много надо иметь некоторое представление об уровнях анализа деятельности. Для оптимизации упрощенно можно выделить 5 основных уровней анализа:
Встает логичный вопрос – на каком уровне надо описывать схему процесса? Ведь с одной стороны – не зная операций и действий сотрудников и последовательности выполнения процедур, сложно судить о деятельности всего бизнес-направления и необходимых точках оптимизации. Но с другой стороны, если описывать процесс на уровне операций – уйдет слишком много времени и труда.
Поэтому, в соответствии со вторым принципом оптимизации, гласящим: «рыбу чистят с хвоста» – описание деятельности компании начинается с описания бизнес-процессов базового уровня, т.е. описывается деятельность каждого исполнителя, приводящая к получению законченного и значимого результата для организации. Только отдельные сложные процедуры бизнес-процесса детализируются до уровня действий.
Детализация же до уровня операций целесообразна исключительно в случае написания ТЗ для автоматизации бизнес-процесса.
Существует множество методик описания бизнес-процессов и поддерживающих эти методики программных продуктов. Выбор методики и программного средства зависит от многих факторов, например: масштаб оптимизации, размер компании, бюджет проекта по оптимизации и т.п. Вне зависимости от методики описания модель процесса должна отвечать на следующие основные вопросы:
Кроме того, при описании бизнес-процесса важно уделять внимание таким, казалось бы, мелочам как способы передачи информации и носители информации (например, устная передача информации может оказаться в лучшем случае «испорченным телефоном», а в худшем – вообще потеряться). Именно они могут послужить одним из объектов для оптимизации.
Давайте вернемся к нашему примеру на Рисунке 1. На самом деле данная схема описывала процесс: «Заключение договора на предоставление телекоммуникационных услуг связи». Суть процесса на первом этапе заключался в том, что менеджер по продажам телекоммуникационной компании, в обязанности которого входит работа с клиентами, анализирует информацию, полученную от клиента о его потребностях, и предлагает ему наиболее выгодное сетевое решение. Проще говоря, у клиента есть потребность в получении высокоскоростного канала связи. Задача менеджера по продажам, понять эту потребность, оценить пропускную способность требуемого канала, оценить наиболее удобный для клиента тарифный план, сделать клиенту предложение и при условии согласия клиента – внести все предложенные решения в договор.
Далее происходит стандартная для большинства компании схема согласования. Договор согласуется с непосредственным руководителем, который проверяет (или не проверяет) правомерность установленных условий, цен, тарифных планов и т.п. В любом случае, проверят ли руководитель договор или нет – он ставит под ним свою подпись, которая фактически говорит о том, что он подтвердил свою ответственность, выраженную в выгодности данного контракта для компании. Если по факту окажется обратное – ну что же – все-таки, наверное, нужно было проверять! Как проверить данную ситуацию – тема отдельной беседы – беседы о системе контроля или как модно нынче говорить – системе контролинга.
Далее договор попадает к юристу. Юрист проверяет, а вообще правомочен ли договор? Не противоречит ли он законодательству, не нарушены ли интересы компании. Если, не дай бог, дело дойдет до суда – мы сможем его выиграть? И опять же Юрист ставит подпись на том, что он договор проверил – а значит, подтвердил свою ответственность за правомочность данного договора.
Далее финансовый менеджер, который проверяет, а, вообще говоря, мы договор заключили верно, с точки зрения финансовой схемы компании? Цена, скидки, условия платежа – согласно утвержденных норм – или мы делаем клиенту какую-то поблажку? Если делаем – то будьте любезны – объясните почему. И в итоге опять подпись, которая опять же подтверждает ответственность.
Понятно, что после каждого согласования договор может и не быть согласован. В этом случае он отправляется менеджеру на доработку. Менеджер его дорабатывает и цикл повторяется. Самое интересное начинается после того, как клиент получает согласованный с такими усилиями Договор, и выясняется, что "его не правильно поняли"... Т.е. ошибка в приеме устной информации произошла на самом первом шаге процесса.
В нашей практике был забавный случай, когда Генеральный директор Управляющей компании группы получил Проект Договора согласованный всеми замами, но без названия компании, от имени которой он заключается. Как вы думаете – отражает данный процесс схема, приведенная на Рисунке 1? Скажем так – с трудом... Как в романе "12 стульев": "Это Ваш мальчик?" – "Мальчик... Кто скажет, что это девочка – пусть первым кинет в меня камень!" Конечно, нельзя назвать Кису Воробьянинова девочкой, но и на мальчика он не тянет. На рисунке 2 приведен пример схемы более полно отображающей состояние с заключением договора.
По такой схеме (при наличии знаний и опыта участия в процессе) уже можно проводить оценку оптимальности.
- Пап! А, пап! А почему солнце восходит на востоке, а заходит на западе?
Папа-программист отрывает от монитора воспаленные глаза и смотрит на сына:
- Оно восходит? Оно заходит... Оно РАБОТАЕТ? РАДИ БОГА, ТОЛЬКО НИЧЕГО НЕ ТРОГАЙ!!!
Как Вы думаете, как можно улучшить приведенный бизнес-процесс? Для этого нужно понять, кого и чем он не устраивает. То есть если он всех устраивает – то зачем его менять: «Оно восходит? Оно заходит... Оно РАБОТАЕТ? РАДИ БОГА, ТОЛЬКО НИЧЕГО НЕ ТРОГАЙ!!!». А вот если не устраивает – то есть два пути: хвататься за первый же недостаток и быстренько устранять его или не торопясь выявить все недостатки и устранить те, что реально позволяют повысить эффективность и реализуемы без революций.
При использовании первого пути Директор смотрит на схему и говорит: "Так устная передача информации – это плохо, пусть подают замечания в письменном виде и за два дня! Маша быстренько подготовьте Приказ!" Приказ о подаче замечаний в письменном виде, увы, процесс не улучшает, а только увеличивает и без того затянутое время согласования, плюс, отнимает лишнее время у всех исполнителей процедур. Там где можно было быстро всё рассказать - специалисты начинают мучиться с выражением мыслей на бумаге. Форма не задана, образцов нет, навыков, как правило, тоже (из исполнителей приведенных в схеме навык письменной речи нужен, пожалуй, только юристу, да и то при подаче исков и апелляций). Суть процесса и алгоритм принятия решений остались прежними. Кроме того, о каких двух днях на одно согласование идет речь, если по большей части договоров замечания подаются за два дня, но число итераций выросло до трех-пяти. Если на каждую по два дня, то согласование с одним специалистом уходит от 6 до 10 рабочих дней.
При использовании технологичного пути сначала последовательно выявляются все значимые недостатки по заданному набору параметров, потом они сравниваются с критериями оптимальности и в завершение готовятся решения по устранению. По каким параметрам надо оценивать оптимальность процесса:
Рассмотрим в сокращенном виде и на уже приведенном примере, как происходит оценка по некоторым пара-метрам.
Оценка качества конечного результата процесса проводится через рекламации к нему. Рекламации – это и официальные жалобы от клиентов, и их аргументы в спорах, и неудовлетворенность руководства компании, и устные жалобы исполнителей.
В рассматриваемом примере клиентов не устраивало два аспекта: время, затрачиваемое на их обслуживание и уровень понимания их потребности. Заключают договор на высокоскоростное подключение, а в ходе исполнения выясняется, что кабельная линия не обеспечивает требуемого трафика. И клиенту предлагают доплатить за прокладку оптоволоконного кабеля или говорят «подождите весны» (ибо оптоволокно зимой не варят). А у него бюджет уже сверстан и он резонно спрашивает: "А где же вы раньше были? При подготовке Договора?" И уже не важно, что юрист предусмотрел нужный пункт в Договоре – лояльность клиента потеряна и пошло тратиться время начальника отдела продаж, директора и юристов на разрешение конфликтной ситуации.
Руководство компании было недовольно следующим:
Критерии оптимальности при оценке конечного результата ситуативные. В общем виде их можно сформулировать с помощью красивой метафоры из миниатюры А.Райкина: Костюмчик должен сидеть, как влитой. Это означает, что по каждому типу рекламаций следует продумать защиту.
Из перечисленных недостатков логично вытекают первые выводы и рекомендации. Во-первых, надо выделить стандартные договора, по которым директору достаточно только проверить сумму. А нестандартные договора следует помечать особо. Во-вторых, надо зафиксировать и довести до каждого менеджера параметры, по которым он в обязательном порядке должен проверить информацию перед составлением проекта договора, что бы понять насколько стандартны условия выполнения работ. В-третьих, надо запретить термин "согласование" и четко зафиксировать: кто и что проверяет в проекте. В-четвертых, надо развести временные нормативы для стандартных и нестандартных договоров – до предела сжав их по стандартным и расширив границы по отклонениям. Наконец, надо наладить технологию перевода нестандартного договора в типовой и продумать алгоритм оценки выгодности нестандартного договора.
По глубокому снегу рысь догоняет зайца не более 100 метров. Если за это время она не поймала добычу - преследование прекращается, но не потому, что устала, а потому, что число полученных калорий – будет меньше числа затраченных.
Аналогично происходит оценка качества промежуточных результатов. Она проводится методично, по каждой процедуре и критериями оптимальности являются удобство исполнителя следующей процедуры и того, кто является менеджером процесса.
Пользователь следующей процедуры должен получать результат в виде и форме наиболее удобном для работы (по возможности). Например, когда юрист может не читать каждое слово в типовом договоре? В двух случаях: если типовой договор отксерен и вся специфическая информация вписана от руки или если менеджер пользуется файлом, закрытым для редактирования, кроме ввода данных в специальные поля. Если же исполнитель пользуется обычным вордовским файлом – читать надо внимательно и аккуратно, кто его знает, что он ещё поменял в исходном выверенном тексте.
Менеджер процесса, в данном случае начальник отдела продаж, должен своевременно получать информацию о состоянии договора. В какой процедуре он находится, нет ли отклонений по срокам, не возникли ли проблемы, переводящие договор в состояние нестандартный.
Как говаривал профессор Преображенский: «Каждый должен заниматься своим делом. Я сторонник разделения труда. В Большом пусть поют, а я буду оперировать. Вот и хорошо, и никаких разрух...».
При оценке оптимальности каждой процедуры, надо анализировать действия исполнителей. Напомним: действие – это последовательность операций, выполнив которые человек осуществляет контроль результата. Например, какие действия совершает тот же юрист при проверке проекта договора:
Это основные действия, которые выполняются всякий раз, а теперь действия, возникающие, как исключения:
Теперь о критериях оптимальности при оценке процедуры. Во-первых, она оптимальна, если исполнитель выполняет минимальный набор действий (3-5) с четко описанными правилами и понятным содержанием. Действия по исключениям оптимально выносить в отдельные процедуры. Тогда можно будет устанавливать жесткие нормативы и прогнозировать своевременность – можно отследить факт начала процедуры по обработке исключения.
Во-вторых, процедура оптимальна, если разброс времени выполнения всех действий в процедуре различается не более чем в 2-3 раза. Если финансовому менеджеру для проверки надо 10-30 минут – это нормально. Разброс от 10 минут до 2-х часов или тем более 3-х дней – означает, что в схеме процесса надо выделять процедуры исключения.
В-третьих, если время, отведенное на выполнение процедуры, не превышает на один рабочий день время реальной работы. То есть, если юристу для проверки типового договора надо 10 минут, то ответ он должен давать не позднее, чем через один рабочий день. Какое-то время ему все-таки нужно дать, с учетом того, что у него есть и другие работы и он не может всё бросить в момент получения проекта договора на согласование. А вот, если проверка нестандартного договора занимает 3-4 дня, то набросить надо максимум ещё 1 день.
Время выполнения также сильно связано с ещё одним критерием оптимальности: какого типа действия совершает исполнитель? Для действий можно выделять три типа различающихся по временным затратам: ознакомление, сверка и преобразование.
Оценка схемы процесса и эффективности его управления – тема большая. Мы не будем раскрывать её в рамках данной статьи и только приведем некоторые показатели и критерии.
При оценке схемы процесса используются следующие показатели (критерии в скобках):
При оценке эффективности управления важно выделять владельца и менеджера процесса и их полномочия. Т.е. какими способами они могут воздействовать на исполнителей. Владелец процесса – это руководитель, который правомочен (т.е. реально может) своим волевым решением внести в процесс любое изменение. Менеджер процесса – это сотрудник, который максимально заинтересован в исполнении конкретного факта прохождения процесса и несет ответственность за его результат.
Как правило, при оценке реально сложившихся процессов, выясняется, что владелец у всех – Директор (Генеральный директор, Председатель Правления, т.е. Первый руководитель организации). При отсутствии функционального подчинения только он может вносить исправления в сквозные процессы, так как только ему подчиняются все участники.
А вот менеджера процесса часто просто не удается выявить – за конкретный случай прохождения процесса никто, как правило, не отвечает. Все норовят отвечать за пуговицы. Если же менеджер и находится, то возникает проблема с наличием у него рычагов воздействия процесса на исполнителей.
О значительной части рекомендаций по оптимизации мы уже упоминали в ходе оценки оптимальности. Давайте подведем некоторый итог и покажем пример схемы достаточно сильно оптимизированного процесса (рис.3). А также дадим к нему некоторые комментарии.
Юридический отдел разработал формы типовых договоров и совместно с начальником отдела продаж установил четкие правила определения, того к какому типу договоров относится та или иная сделка. Начальник отдела продаж разработал Бланк-заказ, который помогает менеджеру точно определить требования клиента, условия работ, стоимость и тип договора.
При начале взаимодействия с клиентом менеджер заполняет Бланк-заказ, который помогает ему четко понять, что именно хочет клиент и какие работы должны быть проведены. Заполненный Бланк-заказ он показывает клиенту и получат от него подтверждение того, что его правильно поняли. После чего менеджер выбирает типовой договор заполняет реквизиты, состав работ, цену и т.п. и передает начальнику отдела на проверку. Если же менеджер понимает, что договор не укладывается в рамки типового, то он направляет Бланк-заказ начальнику с соответствующим комментарием. А начальник принимает решение о разработке нестандартного договора. Но это уже другой процесс...
Стоить отметить – типовые формы также облегчают задачу юристам, финансистам и прочим согласующим лицам. Это следует из того, что согласующие лица уже не выискивают нюансы по всему тексту договора, а проверяют только те разделы, право заполнения которых предоставлено менеджеру. Тем самым мы улучшили результат, который получают согласующие лица на входе, то есть сделали его более понятным и структурированным. Только этим мерами мы уже частично уменьшили сложность согласования, а значит и сократили время согласования.
Но и это еще не все, что можно оптимизировать в данном процессе – следующий шаг: оптимизация самого процесса – параллельное согласование. Проблема существующего процесса, что при каждой ошибке на последнем этапе согласования, необходимо вновь проходить все предыдущие этапы. Так как согласование договора последовательное, то затраты на согласование все время складываются. То есть при условии, что согласование с непосредственным руководителем X часов, юридическим отделом Y часов, финансовым отделом Z часов, получаем общее время согласования X+Y+Z. Если распараллелить данный процесс и установить НОРМУ времени на проведение согласования, то получим, что весь процесс согласования уложится в N часов. В подавляющем большинстве случаев N будет гораздо меньше, чем сумма X+Y+Z . Например, в отделении одного крупного западного завода в России есть норма на получение подписи на договоре – один рабочий день. Процесс последовательный. Представьте, сколько Вам потребуется времени для получения трех подписей – три дня. А если данный процесс сделать параллельным – один день.
НО! Вспомним один принцип – решения по оптимизации не бывают однозначными! В нашем примере неоднозначность решения по оптимизации заключается в том, что распараллелив процессы нам сложно проверить договор разработанный менеджером как единое целое. То есть подписи юристов и финансистов на разных вариантах договора есть, а вот как их собрать на конечный экземпляр. Кроме того, сложно понять какие замечания были к договору у всех заинтересованных лиц, ведь в конечном итоге нам необходимо проверить исправлены ли они. Выход из данной ситуации в добавлении в процесс еще одного документа – Листа согласования. То есть, теперь в нашем оптимизированном процессе, каждое согласующие лицо обязано в письменной форме отражать все свои замечания в документе "Лист Согласований". Листов согласований должно быть столько же, сколько у нас в процессе присутствует согласующих лиц. Если хоть один из согласующих лиц не согласен с представленной версией договора – договор дорабатывается и вновь высылается всем заинтересованным лицам на согласование с пометкой измененных мест! И так до тех пор, пока замечания не закончатся. Листы согласований хранят всю историю согласований. Договор считается согласованным, когда все согласующие подтвердили его правильность.
И так, что было изменено в рассмотренном примере оптимизированного бизнес-процесса:
Вот как можно оптимизировать такой маленький фрагмент, такого небольшого бизнес-процесса, если знать основные принципы оптимизации, которые мы приводили выше. Что надо делать?
Теперь можно переходить к регламентации и внедрению оптимизированного процесса в деятельность, но это тема для следующих статей.
Обучение антикризисному управлению
Курсы ВЭД
Курсы для генеральных директоров
Курсы для директора по персоналу
Обучение для торговых представителей
Курсы по интернет маркетингу
Обучение по профстандартам
Курсы управления ассортиментом в рознице
Тренинг управленческих навыков
Тренинг по коммуникации
Курсы мерчендайзера
Управление мотивацией персонала
Коучинг тренинг
Система обучения персонала
Оценка персонала
Курсы по подбору персонала
Тренинг по ораторскому искусству
Тренинги - системное мышление
Тренинги продаж b2b
Тренинг продаж по телефону
Обучение торгового персонала
Тренинг для тренеров
Тренинг по переговорам
Тренинг по активным продажам
Тренинг по командообразованию
Тренинг отдела продаж
Курсы коммерческого директора
Курсы по управленческому учету
Курсы для финансовых директоров
Курсы по финансовому анализу
Тренинг - финансы для нефинансистов
Тренинг по лидерству
Курсы E-learning