При внесении изменений в деятельность компании руководитель вынужден балансировать между двумя крайностями. С одной стороны — есть опасность сломать непродуманным решением налаженные и устоявшиеся процессы. С другой — есть желание повысить эффективность максимальным образом, т.е. разрушить все «до основанья, а затем…» построить что-то кардинально новое. Именно на второй парадигме основывался активно пропагандируемый еще несколько лет назад реинжиниринг бизнес-процессов.
В учебниках по реинжинирингу бизнес-процессов приводились замечательные примеры многократного улучшения эффективности деятельности крупных международных компаний. Например, как IBM в разы ускорило процесс рассмотрения заявки на предоставление персональных компьютеров в кредит.
История с сокращениями выглядит так. Как-то раз Члены Правления Корпорации заинтересовались, почему средний срок рассмотрения заявки на предоставления персоналки в кредит составляет чуть ли не полтора месяца. В общем-то, за это время большая часть потребителей успевает приобрести такую мелочь другим путем. Для проверки бизнес-процесса члены Правления решили провести эксперимент: тут же на заседании заполнили по Заявке и попросили отнестись со всем вниманием. Естественно, что на следующий день они получили уведомление о предоставлении кредита.
«Значит, умеем — когда надо» — решили члены Правления и приказали провести анализ бизнес-процессов. А анализ показал, что каждую Заявку проверяют несколько отделов, каждый по своему аспекту (кредитная история, задолженности, имущество и т.п.). Причем рассмотрение идет последовательно через каждый отдел. Пачка свежих заявок поступает в очередной отдел и эксперт начинает анализ: «Все ясно — давать, все ясно — не давать, так интересный случай надо разобраться…» И пока он разбирается вся пачка, включая даже те, по которым он уже принял решение — ждет. И так в каждом отделе! (Кстати, вам это ничего не напоминает?)
Решение было простым по сути и реинжиниринговым по реализации. Каждый отдел сформулировал набор четких правил, по которым можно было однозначно понять: давать, не давать или надо разбираться. Далее специалисты разработали многотерминальную экспертную систему, за терминалы посадили операционисток (естественно обучив по специально разработанной программе). И процесс стал выглядеть так. Заявка поступает к операционистке, она вводит данные в экспертную систему, система выдает одно из трех решений: давать, не давать по следующим основаниям (текст отказа прилагается), направить на анализ в следующие отделы (перечень отделов). В результате клиент получал ответ за несколько дней: приходите, вам отказано или подождите еще несколько дней. Результаты: сокращение сроков привело к росту продаж, плюс экономия на экспертах, которым нашли более квалифицированную работу.
В примере налицо кардинальное изменение процесса и повышение эффективности в разы. Самое интересное, что практически любой руководитель в своей работе много раз использовал аналогичный прием: когда можно сформулировать четкие правила принятия решения. Например, при предоставлении скидок: если доставка за 5 дней — скидка 3%, если за 10 дней — 5%. Как только появляются такие правила — принятие решения делегируется вниз и это дает эффект в экономии, ускорении, качестве…
История с сокращениями выглядит так. Как-то раз Члены Правления Корпорации заинтересовались, почему средний срок рассмотрения заявки на предоставления персоналки в кредит составляет чуть ли не полтора месяца. В общем-то, за это время большая часть потребителей успевает приобрести такую мелочь другим путем. Для проверки бизнес-процесса члены Правления решили провести эксперимент: тут же на заседании заполнили по Заявке и попросили отнестись со всем вниманием. Естественно, что на следующий день они получили уведомление о предоставлении кредита.
«Значит, умеем — когда надо» — решили члены Правления и приказали провести анализ бизнес-процессов. А анализ показал, что каждую Заявку проверяют несколько отделов, каждый по своему аспекту (кредитная история, задолженности, имущество и т.п.). Причем рассмотрение идет последовательно через каждый отдел. Пачка свежих заявок поступает в очередной отдел и эксперт начинает анализ: «Все ясно — давать, все ясно — не давать, так интересный случай надо разобраться…» И пока он разбирается вся пачка, включая даже те, по которым он уже принял решение — ждет. И так в каждом отделе! (Кстати, вам это ничего не напоминает?)
Решение было простым по сути и реинжиниринговым по реализации. Каждый отдел сформулировал набор четких правил, по которым можно было однозначно понять: давать, не давать или надо разбираться. Далее специалисты разработали многотерминальную экспертную систему, за терминалы посадили операционисток (естественно обучив по специально разработанной программе). И процесс стал выглядеть так. Заявка поступает к операционистке, она вводит данные в экспертную систему, система выдает одно из трех решений: давать, не давать по следующим основаниям (текст отказа прилагается), направить на анализ в следующие отделы (перечень отделов). В результате клиент получал ответ за несколько дней: приходите, вам отказано или подождите еще несколько дней. Результаты: сокращение сроков привело к росту продаж, плюс экономия на экспертах, которым нашли более квалифицированную работу.
В примере налицо кардинальное изменение процесса и повышение эффективности в разы. Самое интересное, что практически любой руководитель в своей работе много раз использовал аналогичный прием: когда можно сформулировать четкие правила принятия решения. Например, при предоставлении скидок: если доставка за 5 дней — скидка 3%, если за 10 дней — 5%. Как только появляются такие правила — принятие решения делегируется вниз и это дает эффект в экономии, ускорении, качестве…
Только реализация обычно бывает проще: без экспертной системы и сокращения специалистов. Ну и без многократного роста эффективности.
Этот прием — является одним из результатов оптимизации бизнес-процессов. Неторопливой и кропотливой работой по постоянному улучшению деятельности Компании.
Отличие оптимизации от реинжиниринга в данном случае — это скорость получения результата, объем работ и суть изменений. Говоря просто, при оптимизации одно правило быстро доводится до исполнителя и настраивается на ходу. При реинжиниринге тщательно и долго разрабатывается взаимосвязанная система правил, потом она проверяется и часто реализуется с разработкой и внедрением различных форм автоматизации.
Известный гуру в области бизнес-процессов Том Давенпорт выделяет следующие различия между реинжинирингом и оптимизацией (усовершенствованием) бизнес-процессов:
У каждого подхода есть свои плюсы и минусы. Однозначного ответа на вопрос: «с какой скоростью надо менять бизнес-процессы?» нет. Ответ сильно зависит от конкретной ситуации в Компании.
Реинжиниринг нужен в тех случаях, когда на рынке произошли существенные изменения. Приведем несколько примеров:
- появился или скоро появится новый продукт, заменяющий выпускаемый нашей компанией (цифровое фото и «Поляроид»);
- на наш национальный рынок выходят западные банки, предоставляющие кредиты за час;
- значительно выросла заработная плата (или энергоносители) и мы теряем конкурентоспособность (это при работе на экспорт);
- на наш рынок выходят крупные компании с наработанными технологиями производства, продаж, логистики и т.п.;
- конкуренты провели или проводят реинжиниринг и вообще что-то готовят …
Оптимизация или улучшение бизнес-процессов нужны совершенно в других ситуациях. Когда поводов для особого беспокойства нет, но есть небольшие досадные накладки и недостатки в деятельности любимой компании: товар приходит с опозданием, только десятая часть переговоров заканчивается продажей и т.п.
Показывая различие между оптимизацией и реинжинирингом процессов, необходимо уточнить, что выше мы описали две крайние точки на оси между которыми, конечно есть много переходных состояний. Например, глобальная оптимизация процессов или частичный реинжиниринг. В последние годы мы в своей работе все чаще сталкиваемся с ситуацией глобальной оптимизации плавно перетекающей в реинжиниринговые решения.
Комментариев нет:
Отправить комментарий