Как это часто бывает с новыми модными концепциями, обнародование простых, но глубоких идей Хаммера и Чампи по поводу реинжиниринга процессов породило гигантскую волну бизнес-семинаров, учебных курсов, университетских лекций, статей в журналах и книг различных авторов, которые все можно объединить одним заголовком: «и я того же мнения» [В октябре 1998 года Интернет-поиск по ключевому слову «reengineering» принес 189 940 самых разнообразных документов — от статей, посвященных «проблеме 2000 года», до семинара, охарактеризованного как «серьезно о развлечениях». По любой другой важной для делового мира теме документов было намного меньше. В частности, по управлению знаниями — в семь раз.]. В ходе этого процесса (извините за каламбур) широкие массы бизнесменов научились применять термин «реинжиниринг» для обозначения практически любой реорганизации. Пару лет назад одна крупная компьютерная компания начала процедуру «реинжиниринга» с увольнения практически всего отдела кадров, так что некому было рационализировать остальную часть процесса, оказавшегося по сути своей сокращением штатов. Без руководящей и направляющей роли специалистов-кадровиков компания совершила множество грубейших ошибок. Она отказалась от услуг внештатных работников, хотя, естественно, выплатила им все оговоренные контрактами суммы. То есть отказалась от
Создание нового бизнес-процесса — огромная работа. Необходимо поставить цели, к которым вы будете стремиться, определить время и условия начала и окончания работ, вычленить отдельные задачи, определить контрольные точки и показатели, рассчитать бюджет. Наибольший успех сопутствует тем проектам, которые ведутся людьми, имеющими четкие представления о своем клиенте и сценарии использования создаваемого продукта. Это верно и в отношении проектов по формированию новых бизнес-процессов. Клиент может быть вне или внутри компании, суть проблемы от этого не меняется: как он будет использовать разрабатываемый продукт или процесс? Какие получит преимущества по сравнению с тем, что было прежде?
Кроме того, необходимо добиться четкого понимания принимаемых компромиссных решений на каждом уровне руководства. Всякий проект состоит из множества компромиссов. Если говорить о разработке ПО, руководство всегда требует создать продукт с богатым набором функциональных возможностей и в то же время компактный, а сделать его нужно за одну ночь и с минимальными затратами. Большие начальники всегда хотят все сразу и сейчас, поэтому необходимо, чтобы они получили очень ясное представление о возможных и необходимых компромиссных решениях. Если вы считаете правильным наделить продукт дополнительными возможностями — пускай это и увеличит объем кода, — стоит заранее обезопасить себя от претензий со стороны вышестоящего руководителя, которому вдруг в самом конце работы может прийти в голову, что было бы лучше сделать что-нибудь попроще да покомпактнее. Очень неприятно бывает и когда менеджер из кожи вон лезет, чтобы удержать расходы в рамках установленного бюджета, а потом ему вдруг говорят, что не в деньгах дело — если надо, подкинули бы еще, — но в продукте всего должно было быть по максимуму. Все то же самое верно и в отношении работы по созданию электронного процесса.
Необходимо проявлять гибкость с учетом меняющихся требований, но так, чтобы последующими корректировками не увести проект от исходных целей. Необходим ясный и прозрачный процесс оценки предлагаемых изменений и принятия решений, включая и возможный пересмотр постановки задачи.