Зачем нужен управленческий консалтинг сугубо инженерной компании?

Стандартная ситуация: Заказчик хочет автоматизировать свой бизнес. Но когда мы начинаем проводить предпроектные исследования, то обнаруживаем, что, если мы будем автоматизировать ситуацию КАК ЕСТЬ, то мы будем автоматизировать хаос. В таких ситуациях мы настоятельно рекомендуем Заказчику сначала упорядочить и оптимизировать свои бизнес-процессы и только потом приступить к работам по автоматизации. Но, даже если предположить, что у Заказчика до автоматизации все процессы были идеально выстроены (признаемся, мы такого ни разу не встречали :-) ), то очевидно, что любая автоматизация изменит и бизнес-процессы, и распределение функциональных полномочий в компании, и, возможно, организационную структуру. Если эти изменения не документировать, не создать новые регламенты (как минимум, регламенты работы с новыми автоматизированными рабочими местами и информационными системами), то эффект от автоматизации может быть нулевой, если не отрицательный.

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

Бизнес-моделирование крупными мазками

Укрупненная схема организации работ по бизнес-моделированию с целью автоматизации проиллюстрирована ниже на Рис.1.

С чего начать?

Классическим “Е2-Е4” для управленческого консалтинга является проведение мероприятий по организационной диагностике. Но, также как и в шахматах, в исключительных случаях, мы допускаем и другие стартовые варианты. Но, подчеркиваем, эти варианты (по отклонению от классического начала) мы рассматриваем как экзотику. Но все-таки у некоторых читателей этой страницы может возникнуть вопрос: а зачем эта самая организационная диагностика нужна? Для ответа на этот вопрос приведу медицинскую аналогию.
Для ответа на этот вопрос приведу медицинскую аналогию.

“На что жалуемся, больной?”

Стандартная ситуация: Когда к какому-нибудь терапевту в поликлинике на прием приходит пациент, которого он видит в первый раз, то этот терапевт сначала совершает практически одни и те же действия: общий осмотр, измерение температуры, измерение давления, зачем-то оттянет веко, “Сделайте глубокий вдох… Дышите… Не дышите...”, “Покажите язык...”, “Скажите “А-а-а-а”...” и т.д. И только потом, основываясь на жалобах пациента, а также на результатах первичного осмотра, назначает конкретное лечение, или дополнительное обследование, а может перенаправить пациента к другому узкому специалисту.

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

Следующий этап: описание бизнес-процессов КАК ЕСТЬ

Фактически - это следующий уровень детализации, являющийся естественным продолжением организационной диагностики. Грубо говоря, если на предыдущем этапе, мы создавали двумерную модель, т.е. отвечали на вопрос КТО за ЧТО отвечает в организации, то теперь, надо, как бы, добавить третье измерение: КОГДА (или после чего), т.е. мы пытаемся выявить причинно-следственные связи между функциями, смоделировать алгоритм работы компании. Если на предыдущем этапе мы описали функции на верхнем уровне, то на этом этапе мы “наводим лупу детализации” на те функции, которые мы (совместно с Заказчиком) сочли подлежащими к развернутому описанию в виде схем бизнес-процессов. В результате этих работ возникает дискретно-событийная модель бизнес-процессов.

Выходными документами на этом этапе, как правило, является альбом схем бизнес-процессов КАК ЕСТЬ, в которых обозначены стартовые, промежуточные и финальные события, функции (являющиеся, фактически, подфункциями дерева функций, описанного на предыдущем этапе), исполнители, документы, причинно-следственные связи, материальные ресурсы, информационные системы и общий алгоритм взаимодействия между подразделениями КАК ЕСТЬ.
Отдельно имеет смысл остановиться на выборе нотации описания бизнес-процессов.

Почему мы, как правило, выбираем нотацию EPC?

Вообще-то о нотации EPC (сокращение от event-driven process chain - цепочки процессов, управляемые событиями) написано в Интернете очень много, например, очень хорошая статья вот здесь:
http://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/epc_notation
или вот здесь:
http://www.interface.ru/fset.asp?Url=/ca/an/danaris2.htm

Поэтому, вместо того, чтобы писать очередную статью про EPC, хотелось бы объяснить, почему из всего многообразия нотаций по описанию бизнес-процессов (например: IDEF, UML, BPMN и др.), мы предпочитаем именно EPC.

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

Следующий этап: оптимизация бизнес-процессов (разработка бизнес-модели КАК НАДО)

Понятно, что этот этап является естественным продолжением предыдущего этапа. Но, если на предыдущем этапе мы “фотографировали” ситуацию КАК ЕСТЬ, анализируя документы, консолидируя результаты интервью и т.п., то здесь уже так просто не получится, потому что общих рецептов по синтезу оптимальной бизнес-модели деятельности организации не существует. Тем не менее, мы предлагаем соблюдать набор простых правил, благодаря которым возникает возможность если не научно обосновать, то хотя бы интуитивно почувствовать близость к оптимуму новой бизнес-модели и провести комплекс мероприятий по оптимизации с максимальной эффективностью.
Приведем здесь некоторые из этих правил:
1. Перед любой оптимизацией должен быть сформулирован критерий оптимизации. В частности, один и тот же исходный бизнес-процесс можно пытаться оптимизировать по критерию минимизации стоимости, а можно - по критерию максимизации надежности, а можно - по критерию максимизации скорости выполнения и это будут три разных бизнес-процесса.
2. Те, кто будет готовить решение по оптимизации, а также те, кто потом будет внедрять оптимизированный бизнес-процесс, должны подчиняться Первому Лицу организации, а порой и Собственнику. Это связано с тем, что любая оптимизация приводит к перераспределению функциональной нагрузки и зон функциональной ответственности между подразделениями. И в большинстве случаев в результате такого перераспределения есть “пострадавшие” подразделения, которые будут недовольны такой оптимизацией. Кроме того, оптимизация - это ломка привычного порядка вещей, что может вызвать негативную реакцию у участников бизнес-процссов. . А это, в свою очередь, порождает конфликтоген, который может быть разрешен исключительно на уровне Первого Лица.
3. Процесс по оптимизации должен быть подкреплен политической волей Первого Лица (или Собственника). Это правило вытекает из предыдущего.
4. Критерии оптимизации бизнес-процессов должны вытекать из стратегических целей организации.
5. Старайтесь наращивать детализацию постепенно, до тех пор, пока бизнес-модель не станет адекватной поставленным целям.
6. Для поиска оптимального решения мобилизуйте внутренний экспертный потенциал самой организации: проводите брейн-штурминги, фокус-группы, ролевые игры и т.п. с ключевыми участниками бизнес-процессов.

Если одной из главных целей оптимизации является автоматизация бизнес-процессов, то следующим этапом , соответственно, является автоматизация. При проведении работ по автоматизации, по возможности, мы стараемся придерживаться ГОСТ 19 и 34

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