Информационные технологии как основа реинжиниринга

Я не рассматриваю информационную технологию как самостоятельную ценность. Но она открывает широкие возможности. И что, пожалуй, важнее всего, она заставляет снова и снова задаваться вопросом: почему, почему, почему?

Пол О'Нил, председатель правления и главный исполнительный директор корпорации Alcoa

С тех пор как в 1994 году Майкл Хаммер и Джеймс Чампи обнародовали свою концепцию реинжиниринга, компании всего мира не перестают снова и снова придирчиво исследовать свои бизнес-процессы. Они стараются избавиться от организационной сложности и недостаточно эффективных внутренних процессов, мешающих удовлетворять потребности клиентов. Когда я прочитал книгу Хаммера и Чампи «ReengineeringtheCorporation»(«Проведение реинжиниринга в корпорации»), больше всего мое внимание привлекли три идеи. Во-первых, что время от времени необходимо подниматься над рутиной и бросать придирчивый взгляд на используемые бизнес-процессы. Те ли задачи они решают? Нельзя ли их упростить? Во-вторых, что, разбивая работу на множество отдельных участков и поручая их множеству отдельных работников, вы можете зайти так далеко, что уже никто не будет представлять себе процесс в целом и колеса начнут вращаться вхолостую. Наконец, в-третьих — эта идея тесно связана со второй, — что слишком большое число «перепасовок» создает слишком много точек, где вероятно возникновение сбоя [Michael Hammer and James Champy. Reengineering the Corporation: A Manifesto for Business Revolution, rev. ed. (New York: HarperBusiness, 1997).].

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

Создание нового бизнес-процесса — огромная работа. Необходимо поставить цели, к которым вы будете стремиться, определить время и условия начала и окончания работ, вычленить отдельные задачи, определить контрольные точки и показатели, рассчитать бюджет. Наибольший успех сопутствует тем проектам, которые ведутся людьми, имеющими четкие представления о своем клиенте и сценарии использования создаваемого продукта. Это верно и в отношении проектов по формированию новых бизнес-процессов. Клиент может быть вне или внутри компании, суть проблемы от этого не меняется: как он будет использовать разрабатываемый продукт или процесс? Какие получит преимущества по сравнению с тем, что было прежде?

Кроме того, необходимо добиться четкого понимания принимаемых компромиссных решений на каждом уровне руководства. Всякий проект состоит из множества компромиссов. Если говорить о разработке ПО, руководство всегда требует создать продукт с богатым набором функциональных возможностей и в то же время компактный, а сделать его нужно за одну ночь и с минимальными затратами. Большие начальники всегда хотят все сразу и сейчас, поэтому необходимо, чтобы они получили очень ясное представление о возможных и необходимых компромиссных решениях. Если вы считаете правильным наделить продукт дополнительными возможностями — пускай это и увеличит объем кода, — стоит заранее обезопасить себя от претензий со стороны вышестоящего руководителя, которому вдруг в самом конце работы может прийти в голову, что было бы лучше сделать что-нибудь попроще да покомпактнее. Очень неприятно бывает и когда менеджер из кожи вон лезет, чтобы удержать расходы в рамках установленного бюджета, а потом ему вдруг говорят, что не в деньгах дело — если надо, подкинули бы еще, — но в продукте всего должно было быть по максимуму. Все то же самое верно и в отношении работы по созданию электронного процесса.

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