Алгоритм реинжиниринга
Если взять за основу общий вид алгоритма реинжиниринга, то он может быть таким:
- Шаг 1. Анализ сильных и слабых сторон предприятия, потенциала предприятия (в том числе кадрового состава, его квалификации и опыта), оценка потенциальных и реальных рынков по наиболее перспективным для компании направлениям.
Шаг 2. Рассмотрение альтернатив позиционирования для наиболее перспективных рынков, оценка возможностей (возможность стать розничной сетью, крупным оптовым дилером, производителем и т. д.). Выбор наиболее приемлемых альтернатив и их дальнейшее согласование внутри предприятия.
Шаг 3. Формулировка общих стратегических целей предприятия и целей бизнесов.
Шаг 4. Разработка для каждого бизнеса средне- и краткосрочных стратегий, которые позволят достичь поставленных целей.
Шаг 5. Проработка мероприятий по реализации выбранных стратегий, построение оптимальной оргструктуры и систем планирования, стимулирования и контроля.
Шаг 6. Формирование бюджетов для каждого бизнеса, свод общего бюджета, коррекция запланированных мероприятий. Выстраивается оперативный план действий.
Вся корректировка бизнес-процессов происходит на стадии разработки структуры в тот момент, когда ее предназначение уже однозначно определено. Степень «революционности» реорганизации определяется принятыми стратегиями, а вот работоспособность, как это ни странно, обеспечивается отсутствием у них «хозяев».
Впрочем, рассмотрим, почему же так происходит.
Бизнес-процессы современного предприятия слишком сложны, чтобы один «хозяин» смог их полностью охватить. У него не хватит квалификации сделать всю работу за всех, более того, то же отсутствие квалификации сыграет негативную роль в процессе надзора за качественным и своевременным выполнением обязанностей функциональными подразделениями. То есть, по сути, роль хозяина сводится к банальному досмотру, который, в общем-то, ни на что влиять не будет.
На практике предприятию гораздо выгоднее создать на стыках отделов не полностью совпадающие интересы смежных структур, в увязке которых эти структуры весьма заинтересованы (а для заинтересованности ввести некоторые бонусы, поощрения и т. д.). Таким образом, совокупная результативность процессов значительно возрастет – все-таки одно дело работать, потому что этого хочет «хозяин», другое – потому что это необходимо самому отделу. С другой стороны, любые неувязки будут решаться обеими заинтересованными сторонами, да и контроль станет распределенной функцией.
Остается один нюанс — разработка новых и коррекции существующих бизнес-процессов. Проблема успешно решается заменой «хозяина» процесса на заказчика. Таким образом, любое подразделение предприятия получает право инициации необходимых ему бизнес-процессов в рамках своей зоны ответственности. Подразделение-заказчик выбирает подразделение-исполнителя, а затем принимает результаты процесса и отвечает за их эффективное использование.
Распределение зон ответственности и последующий реинжиниринг позволяют получить оптимизационный эффект без кардинальной ломки успешных испытанных технологий, которые могут не вписываться в модельную схему. Элементы матрицы могут существовать в проектных подразделениях компании, однако для целостной структуры перспективнее давать четкие указания функциональным единицам, нежели поставить стрелочника на каждом стыке их взаимодействия.
Что касается непосредственной автоматизации бизнес-процессов, как раз здесь и нужен «хозяин», — именно он и станет переводить запросы руководителей отделов на язык постановки задач программирования. Однако это подразумевает, что реинжиниринг будет выполнен до назначения «хозяина».
