10 Принципы

Разработка нового процесса обычно ведется в течение нескольких недель командой реинжиниринга. В этот период команда рассматривает несколько вариантов процесса, собирает необходимую информацию и вносит исправления, если это необходимо. Даже после того, как новый процесс был согласован, задача разработки ключевых положений процесса может означать, что ко­манде придется вносить дальнейшие изменения в новый процесс. Занимаясь реинжинирингом процесса, команда должна вернуться к предварительно проведенной работе по выявлению требований клиентов процесса, установ­лению планки и созданию видения процесса, а также к ее пониманию мотивации сотрудников и технологиче­ским аспектам. Команда должна обратиться также к большому количеству принципов и рекомендаций, ко­торые помогут ей в деле создания нового процесса. Не­которые из этих принципов происходят из школы науч­ного управления и были разработаны, чтобы помочь людям выполнять работу максимально производительно. Другие принципы являются совершенно новыми и от­ражают радикальность, отличающую РБП от других бо­лее ранних подходов к оптимизации бизнеса. Именно к этим принципам мы сейчас и обратимся.

Применяя принципы на практике, команда реинжи­ниринга должна пытаться творчески использовать их.

Значит, следует использовать метод "мозгового штур­ма". (Далее мы более подробно рассмотрим этот метод). Команда также должна помнить, что эти принципы не являются непреложными законами. При некоторых факторах и некоторых ограничениях применять эти принципы неразумно. "Честность — лучшая политика" — этому принципу могут следовать большинство людей, тем не менее отдавая себе отчет, что бывают ситуации, когда быть полностью правдивым даже опасно. Команда реинжиниринга должна использовать этот принцип по­хожим образом.

Принципы реинжиниринга

Существуют шесть основных принципов РБП, каждый из которых рассматривается далее.

Как можно меньше людей должно быть вовлечено в процесс

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

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

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

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

К сожалению, у созданной для работы команды бы­ло недостаточно знаний по реинжинирингу бизнес-процессов и мало желания радикально изменить поря­док вещей. Их подход состоял в том, чтобы улучшить процесс главным образом за счет разъяснения основных шагов процесса и обязанностей тем, кто их выполняет. Хотя команда объявила об успешном окончании рабо­ты, для большинства сотрудников (особенно пользова­телей) было ясно, что проблема не решена. За короткое время все вернулось на круги своя, и людям снова при­ходилось ждать три месяца выполнения заявок. Координатор по качеству работы отдела IT попросил нас по­мочь, имея в виду, что может быть стоит рассмотреть более радикальные варианты, связанные с реинжинирингом процесса.

Наша первая реакция, когда мы взглянули на про­цесс, была — занято слишком много людей. По мере нарастания требований и ожиданий пользователей, до­бавляли все новых и новых специалистов. Мы разрабо­тали график информационных потоков, показывающий основные шаги процесса, и людей их выполняющих: в отделе IT оказалось не менее десяти различных групп, вовлеченных в процесс, и это не считая шагов процесса, выполняемых другими отделами, такими, как финансо­вый отдел, отдел дистрибуции и внутренних поставок! Схема приведена на рис. 10.1.

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

Рис. 10.1 показывает, что наибольший контакт с клиентом по поводу согласования требований в начале процесса и получения расписки о том, что эти требова­ния удовлетворены в конце процесса, имеет Информа­ционный центр, но этот отдел практически не касается

промежуточных шагов, кроме разрешения на покупку компьютера. Это означает, что Информационный центр оказывается втянут в споры по поводу изменения требо­ваний. Он иногда согласует эти изменения с коллегами из отдела IT, а в других случаях объясняет клиентам, почему не внесли их изменения. Координатор по каче­ству не смог объяснить, почему Группа технической поддержки не может самостоятельно определить требо­вания клиентов, заявляя только, что эту задачу всегда выполнял Информационный центр. Требуемые знания безусловно у Группы технической поддержки были, и в большинстве случаев Отдел технической поддержки лучше смог бы посоветовать, что нужно пользователю в соответствии с его требованиями.

Похожим образом роль Отдела операционных сис­тем сводилась большей частью к администрированию, составлению графиков внедрения, чем к технической приемке новых компьютеров и установке на них имею­щейся операционной системы. Поскольку для этого ис­пользовались данные Группы технической поддержки, то она могла бы легко выполнить и эту задачу. После­довательно удаляя одни шаги процесса (подтверждение полномочий требовалось только на особенно дорогие или нестандартные покупки) и передавая другие в веде­ние Группы технической поддержки, нам удалось изба­виться почти от всех других участников процесса. Но­вый процесс представлен на графике информационных потоков на рис. 10.2.

Теперь, когда в отделе IT не стало передачи работы из рук в руки, среднее время выполнения процесса со­кратилось с четырех до одной недели. Клиенты имеют дело только с Группой технической поддержки и в мо­мент появления каких-либо проблем не тратят времени на поиск человека, который занимается их запросом. Ответственность и подотчетность делают ненужным подтверждение полномочий и подписи на разных ста­диях процесса, которые существовали только для того, чтобы оградить различных участников процесса от жа­лоб клиентов.

Внесенные в процесс изменения совместили задачи и высвободили множество людей в процессе. Вниматель­ный читатель может заметить, тем не менее, что измене­ния все были сделаны внутри отдела IT и что это только один субпроцесс большого процесса, который затрагивает отдел клиентуры, финансовый отдел и отдел внутренних поставок. Схема информационных потоков высокого уровня показывает эти отделы и связи между ними, и поэтому можно провести реинжиниринг процесса и в этом направлении. Поскольку рекомендованные нами изменения отдел IT вначале принял с некоторым недове­рием, вряд ли организация была готова к еще более ра­дикальным изменениям! Тем не менее, такие изменения теоретически были возможны и это потребовало бы при­менения еще некоторых дополнительных принципов.

Клиент процесса должен выполнять этот процесс

Этот принцип похож на первый тем, что он способству­ет улучшению в работе процесса главным образом за счет уменьшения числа вовлеченных в него людей. Он полезен, поскольку дает некоторые рекомендации, кто должен выполнять задачи, совмещенные на одном рабо­чем месте. В большинстве процессов участвуют люди или отделы, связанные внутренними отношениями "поставщик—клиент". Один отдел производит товары или услуги, используемые другим отделом, который яв­ляется таким образом клиентом первого отдела. В Управлении всеобщим качеством (TQM) улучшения вносятся с помощью того, что внутренний поставщик знает требования внутреннего клиента и удовлетворяет их все с первого раза. С помощью данного принципа РБП пытается радикально изменить процесс: убрать по­ставщика и заставить клиента выполнять работу.

Сферу применения этого принципа можно оценить из схем информационных потоков, разработанных ко­мандой реинжиниринга. Следует выявить те процессы, которые начинаются с запроса, проходят через несколько отделов или сотрудников и заканчиваются выходом, ко­торый передается назад стороне, сделавшей запрос. Затем команда должна спросить, может ли сам клиент такого процесса выполнить многие, если не все промежуточные шаги. Приведенный выше пример с отделом IT (см. рис. 10.1) показывает, что Информационный центр явля­ется конечным клиентом существующего в отделе суб­процесса. Одним из вариантов, альтернативных варианту, когда все выполняет Группа технической поддержки, яв­ляется вариант, когда все выполняет сам Информацион­ный центр. Мы действительно рассматривали такую воз­можность, хотя это означало необходимость разработки более мощного фактора, открывающего новые возможно­сти — экспертной системы, позволяющей Информаци­онному центру выполнить все технические задачи, кото­рые до этого выполняли Группа технической поддержки и Группа операционных систем.

Конечно, этот принцип можно применить и более радикально. Истинный клиент процесса заказа и покуп­ки PC — это пользователь, т. е. кто-то, работающий за пределами отдела IT и обладающий небольшими техническими знаниями. Если вовлечь этого человека в вы­полнение процесса, возможно, удастся получить допол­нительную экономию времени, но это потребует более эффективных возможностей для выполнения процесса. Но все больше и больше компаний склоняются к тако­му подходу в отношении внутренних покупок и вопло­щают его на практике, выдавая своим сотрудникам кор­поративные карты и разрешая им делать покупки у внешних поставщиков. В самом деле, наиболее частый аргумент сотрудников, которые по три месяца ждали компьютеры, был: "Я мог бы сам купить компьютер и избежать всех этих проволочек".

Как этот принцип можно применить в отношении внешних клиентов, мы покажем на примере одной ком­пании в телекоммуникационной индустрии. Процесс обработки заказов у них был слишком длительным: от­дел сбыта занимался обработкой заказа очень долго 1-до 8 недель, считая от первоначального звонка клиента (рис. 10.3). В результате компания теряла клиентов, ко­торые за это время отказывались от ее услуг. За время такого длительного ожидания клиенты, естественно, успевали обратиться к конкурентам. Отдел сбыта и опе­раторы, в чьи обязанности входило классифицировать и отфильтровывать заказы для отдела сбыта, бросали вза­имные упреки друг другу.

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

В ходе рассуждений о том, как можно применить принцип, согласно которому клиент процесса сам дол­жен выполнять процесс, кто-то в команде предложил, чтобы клиенты и сами классифицировали свои заказы. На первый взгляд предложение показалось нереальным. Однако более тщательный анализ показал, что данный субпроцесс должен заключаться в том, чтобы оператор задавал покупателю набор стандартных вопросов. На следующем шаге надо было посмотреть, можно ли при помощи людей или технологии заставить покупателей классифицировать их собственные запросы. Требуемая технология, называемая «Автоматический распредели­тель звонков» (Automated Call Distribution, ACD), за­ключалась в том, что записанный на пленку голос про­сил звонящих при помощи набора определенных цифр на телефоне сообщить, какие именно услуги им требо­вались. Используя процедуру отделения данных заказов от других запросов, клиенты и в самом деле могли клас­сифицировать свои собственные запросы. Дополнитель­ным фактором была электронная связь (EDI) между от­делом сбыта и базой данных. Таким образом, внутрен­ний клиент процесса (сотрудник отдела сбыта) также выполнял часть процесса — еще один пример использо­вания данного принципа. Эти изменения означали, что сотрудники отдела сбыта получили возможность напря­мую общаться с клиентом и договариваться с ним не сходя с места.

Некоторые звонки не требовали подключения со­трудников отдела сбыта: клиент Просто хотел разместить заказ. Раньше такие обращения обрабатывались так же, как и остальные запросы, что заканчивалось звонком из отдела сбыта несколько недель спустя, обычно после того, как клиент уже заключил договор с конкурентом. Но если ACD направит эти звонки сразу к операторам, то договор можно заключить немедленно, освобождая время у отдела сбыта на работу с более сложными за­просами, где на самом деле потребуется коммерческая хватка.

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

Этот принцип не нов. Как покупатели товаров и ус­луг — от заправки бензином до составления завещания — люди сейчас лучше готовы выполнить часть процесса, которая раньше выполнялась специалистами. Большин­ство менеджеров выполняют рутинные операции по на­бору текста, которые раньше выполняли их секретари. Принцип не предполагает, что все части процесса вы­полняются клиентом или, что клиент делает все сам ка­ждый раз. Но этот принцип означает, что там, где воз­можно, клиент вовлечен в выполнение процесса на­много больше, чем это традиционно предполагалось. Знание требований внутренних клиентов и удовлетво­рение этих требований — один из базовых принципов концепции Всеобщего качества (TQM) — становится излишним при применении данного принципа. На са­мом деле удовлетворение требований клиентов стало важным только потому, что общий поток работы был разделен на фрагменты, где отношения "поставщик-клиент" являются самым главным элементом.

Обращайтесь с поставщиками, как будто они являются частью организации

Практическое применение этого принципа означает, что иногда от внешних поставщиков требуется выпол­нять шаги процесса, которые раньше выполнялись внутри организации. Покупка готового к работе компь­ютера в магазине в центре города не отменяет необхо­димости спецификации технических требований, это означает только, что поставщик, а не внутренний отдел IT будет делать это. Этот принцип означает, что всюду, где это возможно, команда реинжиниринга должна ис­кать пути привлечения внешних поставщиков для вы­полнения отдельных частей процесса. Некоторым про­изводителям автомобилей удалось убрать большую часть процесса закупок, когда они потребовали от поставщи­ков самим следить за уровнем запасов. Технологическим фактором, который позволил организовать новый про­цесс, стала EDI-связь[17]  между производственным депар­таментом и поставщиком, предоставляя последнему возможность принимать решения о закупках, которые раньше принимались внутри организации. В ответ на принятие на себя дополнительной ответственности по­ставщики получают привилегированный статус, в ре­зультате  чего  проблема  разрешается  ситуацией "выигрыш — выигрыш" для обеих сторон.

При применении этого принципа исчезают барьеры между организациями. Рис. 10.4 показывает применение принципа для типичного процесса закупок, хотя его можно применить и к другим частям бизнеса, например логистике. Когда этот принцип применяется в отноше­нии внутренних поставщиков товаров и услуг, он дает в результате изменения, которые были выполнены в вы­шеуказанном отделе IT, где Группа технической под­держки выполняла задачу, которую раньше выполнял Информационный центр.

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

Изменений такого масштаба достигла реинжини-ринговая команда одной финансовой организации, с которой мы работали. Команда была создана для анали­за процесса инсталляции локальной сети (LAN), пред­назначенной для использования в бизнесе. Этот процесс растягивался на восемь месяцев. В прошлом предпри­нимались бесчисленные попытки усовершенствовать этот процесс, но эффект был кратковременным и про­цесс сам по себе возвращался к исходной точке. В ре­зультате реинжиниринга процесс сжался до четырех дней — фантастическая цифра для всех, кто был связан с этим процессом. Каким же образом был достигнут та­кой резкий скачок? Пример иллюстрирует применение принципов, о которых мы говорили, а также важность творческого мышления, бросающего вызов самым осно­вополагающим установкам организаций.

Первоначальный процесс показан на рис. 10.5. Ос­новная задержка происходила на этапах подготовки двух бизнес-планов, которые были необходимы до того, как заказать оборудование и установить сеть. Поскольку были нужны два бизнес-плана, процесс занимал столько же времени, сколько и самая медленная ветвь; любой выигрыш во времени в подготовке одного из планов терялся, поскольку приходилось ждать завершения подготовки другого. Поэтому для каждого из отделов, занятых в этих этапах, не было никакого стимула вы­полнять свою работу побыстрее, и затягивание обоих субпроцессов превращалось в порочный круг.

Первая попытка реинжиниринговой команды пре­образовать этот процесс привела к новой версии про­цесса, воплотившей в себе принцип уменьшения коли­чества людей, занятых в процессе. Субпроцессы 1 и 2 были скомбинированы в единый процесс, за выпол­нение которого отвечал один коллектив. Так появился стимул завершить этот этап как можно быстрее в соот­ветствии с пожеланиями пользователей. Слияние двух отделов в один было необыкновенно радикальным ша­гом для этой достаточно консервативной организации, и команда почувствовала удовлетворение: ведь длительность процесса уменьшилась на целых 50%. Однако од­ного команда все-таки не сделала: она не смогла отбро­сить в сторону некоторые глубинные установки, опре­делявшие параметры процесса. Когда наш консультант спросил, зачем вообще необходим бизнес-план установ­ки сети, реакцией команды было замешательство. Такой вопрос никогда не ставился, а потому ответ не лежал на поверхности. Поразмыслив, команда пришла к выводу, что без хорошего бизнес-плана подразделения, которые хотят установить у себя локальную сеть, начнут бездум­но сорить деньгами. Однако, скоро стало ясно, что бюджеты этого не позволят, а потому не было никаких причин подозревать, будто подразделения станут вести себя так не по-деловому.

Как только эту глубинную установку вытащили на свет божий и подвергли сомнению, команда увидела новые возможности. Значительная часть времени уходи­ла на подготовку бизнес-планов. Если их пропустить, процесс заказа поставок и установки оборудования по­сле подачи заявки становится вопросом нескольких дней. Теперь целью команды стало приближение во времени этапов 4 и 5 к первоначальной заявке клиента. Применяя принцип "обращайтесь с поставщиками как с частью своей организации", команда пришла к мысли слить воедино этапы 1 и 4 и поручить их поставщикам. По многим причинам поставщики лучше всех могли установить потребности пользователей и определить, какое аппаратное и программное обеспечение им нуж­но. В процессе остался только один этап — этап 5, ко­торый можно было выполнить за 1—2 дня с момента подачи заявки. Процесс, который раньше занимал до восьми месяцев, сжался до четырех дней.

Одно из требований, которое данный принцип вы­двигает на первый план, — доверие к внешним постав­щикам. По традиции отношения с внешними постав­щиками часто бывают враждебными, и понятно, что ни процесс установки локальной сети, ни какой бы то ни было другой процесс, использующий данный принцип, не сможет работать, если где-то в глубине души нет уверенности в том, что поставщик обеспечит даже больше того, что нужно в реальности. Доверие возмож­но только, если с поставщиком установлены по-настоящему партнерские отношения. Такое партнерство можно рассматривать как дополнительную степень сво­боды на уровне организаций, а не на уровне людей или технологий. Такое партнерство должно быть основано на взаимной выгоде: и поставщик, и клиент только вы­игрывают от сотрудничества.

Создавайте множество версий сложных процессов

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

Многие процессы несут в себе подобные механизмы контроля, в которых обычно задействованы дополни­тельные сотрудники, дополнительные визы и неизбеж­ные проволочки, а оправданием этому служат доводы о том, что могло бы приключиться без таких механизмов. На первый взгляд такие оправдания кажутся совершен­но логичными, но если взглянуть на них повниматель­нее, станет понятно, что они обоснованы только в не­которых, достаточно редких случаях. У одной строи­тельной организации, в которой мы работали, был сложнейший процесс материально-технического снаб­жения, загроможденный бесчисленными визами и про­верками. На вопрос, почему процесс настолько сложен, менеджер отдела закупок сослался на случай, когда один сотрудник несколько лет назад попытался обма­нуть компанию на 150 000 ф. ст.. Процесс был разрабо­тан для того, чтобы подобное не повторилось, и такое оправдание казалось весьма здравым. Однако, почти три четверти заявок на закупки были на сумму менее 500 ф. ст., а многие — вообще на несколько фунтов. Сотруд­ников раздражало, что для покупки канцелярских това­ров приходилось следовать той же процедуре, как и при покупке на сумму в несколько десятков тысяч фунтов. В этом случае мысль о том, что без контроля возможны нарушения, приводила лишь к одному результату: механизмы контроля сохранялись во всех попытках изме­нить процесс, так что в конце концов процесс оставля­ли в покое, вместо того чтобы усовершенствовать его.

Ключ к этой головоломке — определить, при каких условиях подобный контроль имеет смысл, и создать несколько отдельных процессов: один со встроенными механизмами контроля, другие без них. Большинство страховых компаний применяют этот принцип при ра­боте с исками. Чтобы компания могла избежать мошен­нических исков, оценщик должен проверить иск, но с экономической точки зрения это имеет смысл только для исков на сумму, превышающую некий порог. Таким образом, компания работает с процессом, включающим этап оценки для исков, превышающих пороговую сум­му, и с упрощенным процессом (без этапа оценки) при обработке исков на сравнительно небольшие суммы.

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

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

Уменьшайте количество входов в процессы

Огромное количество времени во многих организациях тратится на сопоставление и сведение воедино разных форм представления одного и того же. Заявления на отпуск сопоставляются с отгулами, заявки на закупку — со счетами-фактурами, записи об отсутствии на работе по болезни — с бюллетенями, авиабилеты — с бронью и так далее; список практически бесконечен. Процессы, которые содержат в себе подпроцессы и задачи, вклю­чающие подобные сверки, скорее всего, окажутся мед­ленными и запутанными, потребуют участия большого количества людей. Уменьшение количества входов в процесс — один из способов уменьшения количества проводимых сверок, ускорения процесса и уменьшения численности задействованного персонала. Чтобы усо­вершенствовать процесс, просто убирают те входы, ко­торые нужно будет сопоставлять с другими входами, хо­тя подобное изменение может потребовать серьезных изменений в других частях процесса.

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

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

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

Сохраняйте децентрализованные подразделения, централизуя обмен информацией

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

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

Применение принципов реинжиниринга

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

Чтобы стимулировать оба типа мышления, по наше­му мнению, полезно использовать разнообразные спо­собы решения проблем. Один способ заключается в том, чтобы команда сначала обсудила каждый принцип и добилась полного понимания его значения. Если в ра­боте команды участвует внешний консультант, то он может привести примеры, как эти принципы применя­лись в других организациях. Другой способ — написать принципы на листе бумаги и повесить этот лист на сте­ну, чтобы всем было видно, или написать их на специ­альной пленке и показывать на экране. Третий способ — провести в команде мозговой штурм на тему "Как можно применить эти принципы для преобразования нашего процесса". Команде следует напомнить правила мозгового штурма: не должно быть никакой критики, команда должна ориентироваться на количество идей, а не на их качество, идеи должны быть скорее свободны­ми, чем строго аналитическими, каждая идея должна записываться, и команде следует развивать эти идеи, чтобы использовать весь заложенный в них потенциал, а не оценивать их.

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

Какую бы процедуру ни использовала команда, главная цель в том, чтобы она придумала разные спосо­бы удовлетворения запросов клиентов процесса, не ско­вывая себя установками, господствующими в организа­ции в настоящий момент. Команда должна выйти за рамки (как в задаче с девятью точками) и искать твор­ческие решения, ломая привычные подходы к работе. Полезно повесить на стену формулировку видения про­цесса, чтобы постоянно напоминать команде, чего она хочет добиться от процесса, а также перечень инстру­ментов, которые могут в этом помочь, чтобы команда генерировала идеи о том, как их можно использовать.

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

Собрание закончено, и участники команды присту­пают к проработке выдвинутых идей. В течение не­скольких следующих дней некоторые из идей превра­тятся в предложения, позволяющие воплотить в реаль­ность видение процесса и достичь поставленных целей по эффективности и результативности. Задача реинжиниринговой команды в том, чтобы развить эти идеи и найти инструменты для внедрения в практику. Для этого стоит использовать методы составления карты процесса, представленные в гл. 8, изображая процесс в графическом виде на бумаге.

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

Методы усовершенствования процессов

Хотя новый процесс, скорее всего, будет сильно отли­чаться от того процесса, чье место он займет — если только он призван достичь тех смелых целей, что были поставлены видением процесса, — части процесса оста­нутся теми же самыми. Так, хотя несколько субпроцес­сов, возможно, будут пропущены, скомбинированы с другими, переданы в ведение поставщиков или клиен­тов, остальные части процесса останутся на своем месте. Субпроцессы будут представлены теми же самыми кружками как в старой, так и в новой карте процесса (схеме информационных потоков). Это, однако, не оз­начает, будто команда должна просто-напросто сохранить "статус-кво". Изменения в одной из частей процес­са дают отличную возможность пересмотреть те субпроцессы, которые остались нетронутыми с прошлой вер­сии, и подвергнуть их строгому анализу на возможность усовершенствования. Существует несколько испробо­ванных и проверенных методик, которые помогут уви­деть, где и какие изменения нужны. Эти изменения бу­дут менее масштабными, чем реинжиниринг, проведен­ный командой над основной частью процесса, и цель здесь в том, чтобы усовершенствовать и упростить суб­процесс, который, как уже было решено, следует оста­вить от прежнего процесса. Схема информационных потоков субпроцесса весьма полезна для таких усовер­шенствований. Существуют четыре основных метода, которыми может воспользоваться команда для упроще­ния представленного на такой схеме процесса.

Анализ методом пяти вопросов

Как уже ясно из названия, метод пяти вопросов заклю­чается в ответах на пять вопросов для каждого этапа процесса, представленного на схеме информационных потоков:

В чем состоит задача?

Где она выполняется?

Когда она выполняется?

Кто ее выполняет?

Как ее выполняют?

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

Команду не должны ограничивать точные формули­ровки вопроса. Каждый из вопросов можно интерпре­тировать по-разному, и в этом сильная сторона методи­ки: ведь это позволяет взглянуть на процесс с разных сторон. Таким образом, спрашивая, когда выполняется этап и можно ли его выполнить в другое время, команда должна рассматривать вопрос времени в отношении как можно большего числа событий. Среди ответов могут быть такие, как: "до того как произошла ошибка", "до того как покупатель пожалуется", "после того как мы проверили ошибки", "до того как начать" и др.

Хотя это не такой уж и сложный метод анализа, он необыкновенно эффективен и мы использовали его для достижения небольших, но важных улучшений в разных аспектах процессов. В гл. 8 мы упомянули команду са­нитаров, которые изобразили алгоритм процесса транс­портировки пациентов из палаты в операционную и об­ратно в палату, после того как операция закончилась. Алгоритм показывал, что первым делом санитар, при­шедший в палату, проверял, в палате ли пациент и готов ли он к переезду в операционную. Отвечая на пять во­просов, команда сначала рассмотрела задачу этого этапа и согласилась, что задача вполне реальная. Затем зада­лись вопросом, можно ли было решить задачу в другом месте или в другое время. Это сразу навело на мысль, что лучшее время для проверки — до того, как санитар от­правится в палату: ведь если пациента перевели в другую палату, это позволит избежать ненужного визита. Если санитар позвонит в палату, прежде чем отправиться туда, он сможет не просто проверить, на месте ли пациент, но и сообщить персоналу о своем скором приезде, так что они смогут подготовить пациента к переезду в операци­онную до приезда санитара. Алгоритмический график показывал, что после проверки, на месте ли пациент, происходила задержка, пока персонал палаты готовил пациента к переезду в операционную. Так, сдвинув про­верку на более раннее время (до того как санитар поки­нет операционную), команда смогла уменьшить количе­ство ненужных поездок в палаты, откуда пациентов пере­вели, уменьшить количество операций, сорванных из-за того, что пациента не смогли найти в другой палате, сэ­кономить время санитаров, ожидавших, пока пациентов подготовят к операции.

Анализ добавленной стоимости

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

Чтобы провести анализ добавленной стоимости, ко­манда должна включить каждый этап процесса в одну из следующих категорий:

добавляет реальную стоимость,

добавляет стоимость для организации (business value),

никакой стоимости не добавляет.

Этапы, которые добавляют стоимость, — это те эта­пы, которые сказываются на окончательном результате процесса и которые напрямую связаны с удовлетворе­нием потребностей клиента. Среди них такие этапы, как собственно производство продукции в соответствии с пожеланиями клиента, или, в случае услуги, предос­тавление информации, которая может потребоваться клиенту, или само по себе оказание услуги. Вернемся к команде санитаров: алгоритм процесса доставки паци­ентов из палаты и в палату состоял более чем из 30 шагов, но все же только три шага на самом деле обеспечивали создание добавленной стоимости: анесте­зия, операция, реанимация. Можно представить себе как почувствует себя пациент, если будет пропущен хотя бы один из них! Хотя другие шаги тоже были важны­ми, они не были столь необходимыми и скорее были связаны с воплощением процесса, чем с решением его фундаментальной задачи.

Шаги, добавлявшие организационную стоимость, — это такие этапы, которые нужны организации, но не добавляют никакой реальной стоимости с точки зрения клиента. Среди них, например, хранение информации, которая может потребоваться другим отделам, заказ ма­териалов, подготовка отчетов. Иногда кажется, будто те или иные действия добавляют организационную стои­мость, потому что нам кажется, будто их результатами пользуется кто-то другой, но последующий анализ часто показывает, что никакой цели у них нет. Один менед­жер однажды рассказал нам, как отдел сбыта его компа­нии каждый месяц составлял подробный отчет о своей деятельности. Когда он спросил их, зачем они состав­ляют такие подробные отчеты, сбытовики ответили, что информация была нужна центральному офису, хотя са­ми они не имели представления, зачем и каким образом эта информация использовалась. Дальнейшие расспросы в центральном офисе показали, что никто не знал, за­чем отдел сбыта составлял отчеты, которые приходили каждый месяц, но всем казалось, будто эти данные важ­ны для самих сбытовиков: иначе зачем им тратить столько сил! Более подробные расспросы показали, что четырьмя годами раньше менеджер-практикант попро­сил собрать информацию для обзора, который он со­ставлял. Он уже давно ушел из компании, но каждый месяц информация предоставлялась, и никто не помнил и даже не спрашивал, зачем.

Подобные действия можно найти в каждой организа­ции. Задачи выполняются, даже если реальная причина давно исчезла, и на первый взгляд кажется, будто они кому-то нужны, хотя этот "кто-то" всегда находится в другом отделе. Предполагая, будто эти задачи добавляют организационную стоимость, команда должна удостове­риться, что организации это действительно нужно и что человек, которому это нужно, существует в реальности.

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

Анализ добавленной стоимости, использующий ал­горитмический график всех этапов процесса, предпола­гает, что все этапы разбиваются на три категории: до­бавляющие реальную стоимость, добавляющие органи­зационную стоимость, не добавляющие никакой стои­мости. Здесь может оказаться полезным маркер, позво­ляющий наглядно показать, какая часть этапов прихо­дится на долю каждой из категорий. Следующая задача в том, чтобы подумать, нельзя ли оптимизировать ка­кие-либо из добавляющих стоимость процессов — воз­можно, путем уменьшения времени или затрат. Можно ли устранить некоторые из этапов добавляющих органи­зационную стоимость? И наконец, как можно устранить не добавляющие стоимость этапы и улучшить процесс (при помощи метода пяти вопросов), устраняя причины некоторых проблем и предоставляя людям полномочия принимать решения там, где раньше им нужна была чья-то подпись?

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

Устранение бюрократии

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

Анализ длительности цикла

Анализ длительности цикла также использует алгорит­мические схемы, но цель здесь в том, чтобы показать, за какое время процесс пройдет полный цикл. Начиная с первого этапа процесса и до самого последнего на схеме показывается, сколько времени прошло с момента нача­ла процесса. Нужно также зафиксировать время выпол­нения каждого этапа. Как только это сделано, команда может сравнить суммарное время выполнения всех эта­пов с длительностью всего процесса. Не так уж редко встречаются случаи, когда соотношение достигает 5— 10%. Другими словами, только около 10% времени вы­полнения процесса действительно занято какой-то ра­ботой. Остальное время уходит на всевозможные за­держки, пока документы лежат на чьем-то столе или пока товары куда-то везут.

Существует несколько способов уменьшить полную длительность цикла, сохраняя длительность каждого этапа на прежнем уровне и тем самым увеличивая долю полезного времени. Некоторые задания можно выпол­нять параллельно с другими, если раньше они выполня­лись последовательно. Алгоритмическая схема покажет, не приходится ли возить документы или продукцию из одного отдела в другой, и если так оно и есть, вероятно, существует возможность объединить выполнение всех этапов в одном месте в одно время, уменьшив тем са­мым задержки, связанные с транспортировкой. При по­мощи лучшей координации действий можно также со­кратить время, пока документы ждут на чьем-то столе. Например, если табели за неделю должны быть собраны в 10.00 утра в пятницу, имеет смысл закончить и пере­дать их в 5.00 вечера в четверг. Изменение места произ­водства товаров также может уменьшить время транс­портировки. Итак, существует множество способов уменьшить промежутки времени между выполнением разных этапов процесса при помощи тщательного пла­нирования и проектирования.

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

Разработка нового процесса обычно ведется в течение нескольких недель командой реинжиниринга. В этот период команда рассматривает несколько вариантов процесса, собирает необходимую информацию и вносит исправления, если это необходимо. Даже после того, как новый процесс был согласован, задача разработки ключевых положений процесса может означать, что ко­манде придется вносить дальнейшие изменения в новый процесс. Занимаясь реинжинирингом процесса, команда должна вернуться к предварительно проведенной работе по выявлению требований клиентов процесса, установ­лению планки и созданию видения процесса, а также к ее пониманию мотивации сотрудников и технологиче­ским аспектам. Команда должна обратиться также к большому количеству принципов и рекомендаций, ко­торые помогут ей в деле создания нового процесса. Не­которые из этих принципов происходят из школы науч­ного управления и были разработаны, чтобы помочь людям выполнять работу максимально производительно. Другие принципы являются совершенно новыми и от­ражают радикальность, отличающую РБП от других бо­лее ранних подходов к оптимизации бизнеса. Именно к этим принципам мы сейчас и обратимся.

Применяя принципы на практике, команда реинжи­ниринга должна пытаться творчески использовать их.

Значит, следует использовать метод "мозгового штур­ма". (Далее мы более подробно рассмотрим этот метод). Команда также должна помнить, что эти принципы не являются непреложными законами. При некоторых факторах и некоторых ограничениях применять эти принципы неразумно. "Честность — лучшая политика" — этому принципу могут следовать большинство людей, тем не менее отдавая себе отчет, что бывают ситуации, когда быть полностью правдивым даже опасно. Команда реинжиниринга должна использовать этот принцип по­хожим образом.

Принципы реинжиниринга

Существуют шесть основных принципов РБП, каждый из которых рассматривается далее.

Как можно меньше людей должно быть вовлечено в процесс

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

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

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

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

К сожалению, у созданной для работы команды бы­ло недостаточно знаний по реинжинирингу бизнес-процессов и мало желания радикально изменить поря­док вещей. Их подход состоял в том, чтобы улучшить процесс главным образом за счет разъяснения основных шагов процесса и обязанностей тем, кто их выполняет. Хотя команда объявила об успешном окончании рабо­ты, для большинства сотрудников (особенно пользова­телей) было ясно, что проблема не решена. За короткое время все вернулось на круги своя, и людям снова при­ходилось ждать три месяца выполнения заявок. Координатор по качеству работы отдела IT попросил нас по­мочь, имея в виду, что может быть стоит рассмотреть более радикальные варианты, связанные с реинжинирингом процесса.

Наша первая реакция, когда мы взглянули на про­цесс, была — занято слишком много людей. По мере нарастания требований и ожиданий пользователей, до­бавляли все новых и новых специалистов. Мы разрабо­тали график информационных потоков, показывающий основные шаги процесса, и людей их выполняющих: в отделе IT оказалось не менее десяти различных групп, вовлеченных в процесс, и это не считая шагов процесса, выполняемых другими отделами, такими, как финансо­вый отдел, отдел дистрибуции и внутренних поставок! Схема приведена на рис. 10.1.

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

Рис. 10.1 показывает, что наибольший контакт с клиентом по поводу согласования требований в начале процесса и получения расписки о том, что эти требова­ния удовлетворены в конце процесса, имеет Информа­ционный центр, но этот отдел практически не касается

промежуточных шагов, кроме разрешения на покупку компьютера. Это означает, что Информационный центр оказывается втянут в споры по поводу изменения требо­ваний. Он иногда согласует эти изменения с коллегами из отдела IT, а в других случаях объясняет клиентам, почему не внесли их изменения. Координатор по каче­ству не смог объяснить, почему Группа технической поддержки не может самостоятельно определить требо­вания клиентов, заявляя только, что эту задачу всегда выполнял Информационный центр. Требуемые знания безусловно у Группы технической поддержки были, и в большинстве случаев Отдел технической поддержки лучше смог бы посоветовать, что нужно пользователю в соответствии с его требованиями.

Похожим образом роль Отдела операционных сис­тем сводилась большей частью к администрированию, составлению графиков внедрения, чем к технической приемке новых компьютеров и установке на них имею­щейся операционной системы. Поскольку для этого ис­пользовались данные Группы технической поддержки, то она могла бы легко выполнить и эту задачу. После­довательно удаляя одни шаги процесса (подтверждение полномочий требовалось только на особенно дорогие или нестандартные покупки) и передавая другие в веде­ние Группы технической поддержки, нам удалось изба­виться почти от всех других участников процесса. Но­вый процесс представлен на графике информационных потоков на рис. 10.2.

Теперь, когда в отделе IT не стало передачи работы из рук в руки, среднее время выполнения процесса со­кратилось с четырех до одной недели. Клиенты имеют дело только с Группой технической поддержки и в мо­мент появления каких-либо проблем не тратят времени на поиск человека, который занимается их запросом. Ответственность и подотчетность делают ненужным подтверждение полномочий и подписи на разных ста­диях процесса, которые существовали только для того, чтобы оградить различных участников процесса от жа­лоб клиентов.

Внесенные в процесс изменения совместили задачи и высвободили множество людей в процессе. Вниматель­ный читатель может заметить, тем не менее, что измене­ния все были сделаны внутри отдела IT и что это только один субпроцесс большого процесса, который затрагивает отдел клиентуры, финансовый отдел и отдел внутренних поставок. Схема информационных потоков высокого уровня показывает эти отделы и связи между ними, и поэтому можно провести реинжиниринг процесса и в этом направлении. Поскольку рекомендованные нами изменения отдел IT вначале принял с некоторым недове­рием, вряд ли организация была готова к еще более ра­дикальным изменениям! Тем не менее, такие изменения теоретически были возможны и это потребовало бы при­менения еще некоторых дополнительных принципов.

Клиент процесса должен выполнять этот процесс

Этот принцип похож на первый тем, что он способству­ет улучшению в работе процесса главным образом за счет уменьшения числа вовлеченных в него людей. Он полезен, поскольку дает некоторые рекомендации, кто должен выполнять задачи, совмещенные на одном рабо­чем месте. В большинстве процессов участвуют люди или отделы, связанные внутренними отношениями "поставщик—клиент". Один отдел производит товары или услуги, используемые другим отделом, который яв­ляется таким образом клиентом первого отдела. В Управлении всеобщим качеством (TQM) улучшения вносятся с помощью того, что внутренний поставщик знает требования внутреннего клиента и удовлетворяет их все с первого раза. С помощью данного принципа РБП пытается радикально изменить процесс: убрать по­ставщика и заставить клиента выполнять работу.

Сферу применения этого принципа можно оценить из схем информационных потоков, разработанных ко­мандой реинжиниринга. Следует выявить те процессы, которые начинаются с запроса, проходят через несколько отделов или сотрудников и заканчиваются выходом, ко­торый передается назад стороне, сделавшей запрос. Затем команда должна спросить, может ли сам клиент такого процесса выполнить многие, если не все промежуточные шаги. Приведенный выше пример с отделом IT (см. рис. 10.1) показывает, что Информационный центр явля­ется конечным клиентом существующего в отделе суб­процесса. Одним из вариантов, альтернативных варианту, когда все выполняет Группа технической поддержки, яв­ляется вариант, когда все выполняет сам Информацион­ный центр. Мы действительно рассматривали такую воз­можность, хотя это означало необходимость разработки более мощного фактора, открывающего новые возможно­сти — экспертной системы, позволяющей Информаци­онному центру выполнить все технические задачи, кото­рые до этого выполняли Группа технической поддержки и Группа операционных систем.

Конечно, этот принцип можно применить и более радикально. Истинный клиент процесса заказа и покуп­ки PC — это пользователь, т. е. кто-то, работающий за пределами отдела IT и обладающий небольшими техническими знаниями. Если вовлечь этого человека в вы­полнение процесса, возможно, удастся получить допол­нительную экономию времени, но это потребует более эффективных возможностей для выполнения процесса. Но все больше и больше компаний склоняются к тако­му подходу в отношении внутренних покупок и вопло­щают его на практике, выдавая своим сотрудникам кор­поративные карты и разрешая им делать покупки у внешних поставщиков. В самом деле, наиболее частый аргумент сотрудников, которые по три месяца ждали компьютеры, был: "Я мог бы сам купить компьютер и избежать всех этих проволочек".

Как этот принцип можно применить в отношении внешних клиентов, мы покажем на примере одной ком­пании в телекоммуникационной индустрии. Процесс обработки заказов у них был слишком длительным: от­дел сбыта занимался обработкой заказа очень долго 1-до 8 недель, считая от первоначального звонка клиента (рис. 10.3). В результате компания теряла клиентов, ко­торые за это время отказывались от ее услуг. За время такого длительного ожидания клиенты, естественно, успевали обратиться к конкурентам. Отдел сбыта и опе­раторы, в чьи обязанности входило классифицировать и отфильтровывать заказы для отдела сбыта, бросали вза­имные упреки друг другу.

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

В ходе рассуждений о том, как можно применить принцип, согласно которому клиент процесса сам дол­жен выполнять процесс, кто-то в команде предложил, чтобы клиенты и сами классифицировали свои заказы. На первый взгляд предложение показалось нереальным. Однако более тщательный анализ показал, что данный субпроцесс должен заключаться в том, чтобы оператор задавал покупателю набор стандартных вопросов. На следующем шаге надо было посмотреть, можно ли при помощи людей или технологии заставить покупателей классифицировать их собственные запросы. Требуемая технология, называемая «Автоматический распредели­тель звонков» (Automated Call Distribution, ACD), за­ключалась в том, что записанный на пленку голос про­сил звонящих при помощи набора определенных цифр на телефоне сообщить, какие именно услуги им требо­вались. Используя процедуру отделения данных заказов от других запросов, клиенты и в самом деле могли клас­сифицировать свои собственные запросы. Дополнитель­ным фактором была электронная связь (EDI) между от­делом сбыта и базой данных. Таким образом, внутрен­ний клиент процесса (сотрудник отдела сбыта) также выполнял часть процесса — еще один пример использо­вания данного принципа. Эти изменения означали, что сотрудники отдела сбыта получили возможность напря­мую общаться с клиентом и договариваться с ним не сходя с места.

Некоторые звонки не требовали подключения со­трудников отдела сбыта: клиент Просто хотел разместить заказ. Раньше такие обращения обрабатывались так же, как и остальные запросы, что заканчивалось звонком из отдела сбыта несколько недель спустя, обычно после того, как клиент уже заключил договор с конкурентом. Но если ACD направит эти звонки сразу к операторам, то договор можно заключить немедленно, освобождая время у отдела сбыта на работу с более сложными за­просами, где на самом деле потребуется коммерческая хватка.

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

Этот принцип не нов. Как покупатели товаров и ус­луг — от заправки бензином до составления завещания — люди сейчас лучше готовы выполнить часть процесса, которая раньше выполнялась специалистами. Большин­ство менеджеров выполняют рутинные операции по на­бору текста, которые раньше выполняли их секретари. Принцип не предполагает, что все части процесса вы­полняются клиентом или, что клиент делает все сам ка­ждый раз. Но этот принцип означает, что там, где воз­можно, клиент вовлечен в выполнение процесса на­много больше, чем это традиционно предполагалось. Знание требований внутренних клиентов и удовлетво­рение этих требований — один из базовых принципов концепции Всеобщего качества (TQM) — становится излишним при применении данного принципа. На са­мом деле удовлетворение требований клиентов стало важным только потому, что общий поток работы был разделен на фрагменты, где отношения "поставщик-клиент" являются самым главным элементом.

Обращайтесь с поставщиками, как будто они являются частью организации

Практическое применение этого принципа означает, что иногда от внешних поставщиков требуется выпол­нять шаги процесса, которые раньше выполнялись внутри организации. Покупка готового к работе компь­ютера в магазине в центре города не отменяет необхо­димости спецификации технических требований, это означает только, что поставщик, а не внутренний отдел IT будет делать это. Этот принцип означает, что всюду, где это возможно, команда реинжиниринга должна ис­кать пути привлечения внешних поставщиков для вы­полнения отдельных частей процесса. Некоторым про­изводителям автомобилей удалось убрать большую часть процесса закупок, когда они потребовали от поставщи­ков самим следить за уровнем запасов. Технологическим фактором, который позволил организовать новый про­цесс, стала EDI-связь[17]  между производственным депар­таментом и поставщиком, предоставляя последнему возможность принимать решения о закупках, которые раньше принимались внутри организации. В ответ на принятие на себя дополнительной ответственности по­ставщики получают привилегированный статус, в ре­зультате  чего  проблема  разрешается  ситуацией "выигрыш — выигрыш" для обеих сторон.

При применении этого принципа исчезают барьеры между организациями. Рис. 10.4 показывает применение принципа для типичного процесса закупок, хотя его можно применить и к другим частям бизнеса, например логистике. Когда этот принцип применяется в отноше­нии внутренних поставщиков товаров и услуг, он дает в результате изменения, которые были выполнены в вы­шеуказанном отделе IT, где Группа технической под­держки выполняла задачу, которую раньше выполнял Информационный центр.

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

Изменений такого масштаба достигла реинжини-ринговая команда одной финансовой организации, с которой мы работали. Команда была создана для анали­за процесса инсталляции локальной сети (LAN), пред­назначенной для использования в бизнесе. Этот процесс растягивался на восемь месяцев. В прошлом предпри­нимались бесчисленные попытки усовершенствовать этот процесс, но эффект был кратковременным и про­цесс сам по себе возвращался к исходной точке. В ре­зультате реинжиниринга процесс сжался до четырех дней — фантастическая цифра для всех, кто был связан с этим процессом. Каким же образом был достигнут та­кой резкий скачок? Пример иллюстрирует применение принципов, о которых мы говорили, а также важность творческого мышления, бросающего вызов самым осно­вополагающим установкам организаций.

Первоначальный процесс показан на рис. 10.5. Ос­новная задержка происходила на этапах подготовки двух бизнес-планов, которые были необходимы до того, как заказать оборудование и установить сеть. Поскольку были нужны два бизнес-плана, процесс занимал столько же времени, сколько и самая медленная ветвь; любой выигрыш во времени в подготовке одного из планов терялся, поскольку приходилось ждать завершения подготовки другого. Поэтому для каждого из отделов, занятых в этих этапах, не было никакого стимула вы­полнять свою работу побыстрее, и затягивание обоих субпроцессов превращалось в порочный круг.

Первая попытка реинжиниринговой команды пре­образовать этот процесс привела к новой версии про­цесса, воплотившей в себе принцип уменьшения коли­чества людей, занятых в процессе. Субпроцессы 1 и 2 были скомбинированы в единый процесс, за выпол­нение которого отвечал один коллектив. Так появился стимул завершить этот этап как можно быстрее в соот­ветствии с пожеланиями пользователей. Слияние двух отделов в один было необыкновенно радикальным ша­гом для этой достаточно консервативной организации, и команда почувствовала удовлетворение: ведь длительность процесса уменьшилась на целых 50%. Однако од­ного команда все-таки не сделала: она не смогла отбро­сить в сторону некоторые глубинные установки, опре­делявшие параметры процесса. Когда наш консультант спросил, зачем вообще необходим бизнес-план установ­ки сети, реакцией команды было замешательство. Такой вопрос никогда не ставился, а потому ответ не лежал на поверхности. Поразмыслив, команда пришла к выводу, что без хорошего бизнес-плана подразделения, которые хотят установить у себя локальную сеть, начнут бездум­но сорить деньгами. Однако, скоро стало ясно, что бюджеты этого не позволят, а потому не было никаких причин подозревать, будто подразделения станут вести себя так не по-деловому.

Как только эту глубинную установку вытащили на свет божий и подвергли сомнению, команда увидела новые возможности. Значительная часть времени уходи­ла на подготовку бизнес-планов. Если их пропустить, процесс заказа поставок и установки оборудования по­сле подачи заявки становится вопросом нескольких дней. Теперь целью команды стало приближение во времени этапов 4 и 5 к первоначальной заявке клиента. Применяя принцип "обращайтесь с поставщиками как с частью своей организации", команда пришла к мысли слить воедино этапы 1 и 4 и поручить их поставщикам. По многим причинам поставщики лучше всех могли установить потребности пользователей и определить, какое аппаратное и программное обеспечение им нуж­но. В процессе остался только один этап — этап 5, ко­торый можно было выполнить за 1—2 дня с момента подачи заявки. Процесс, который раньше занимал до восьми месяцев, сжался до четырех дней.

Одно из требований, которое данный принцип вы­двигает на первый план, — доверие к внешним постав­щикам. По традиции отношения с внешними постав­щиками часто бывают враждебными, и понятно, что ни процесс установки локальной сети, ни какой бы то ни было другой процесс, использующий данный принцип, не сможет работать, если где-то в глубине души нет уверенности в том, что поставщик обеспечит даже больше того, что нужно в реальности. Доверие возмож­но только, если с поставщиком установлены по-настоящему партнерские отношения. Такое партнерство можно рассматривать как дополнительную степень сво­боды на уровне организаций, а не на уровне людей или технологий. Такое партнерство должно быть основано на взаимной выгоде: и поставщик, и клиент только вы­игрывают от сотрудничества.

Создавайте множество версий сложных процессов

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

Многие процессы несут в себе подобные механизмы контроля, в которых обычно задействованы дополни­тельные сотрудники, дополнительные визы и неизбеж­ные проволочки, а оправданием этому служат доводы о том, что могло бы приключиться без таких механизмов. На первый взгляд такие оправдания кажутся совершен­но логичными, но если взглянуть на них повниматель­нее, станет понятно, что они обоснованы только в не­которых, достаточно редких случаях. У одной строи­тельной организации, в которой мы работали, был сложнейший процесс материально-технического снаб­жения, загроможденный бесчисленными визами и про­верками. На вопрос, почему процесс настолько сложен, менеджер отдела закупок сослался на случай, когда один сотрудник несколько лет назад попытался обма­нуть компанию на 150 000 ф. ст.. Процесс был разрабо­тан для того, чтобы подобное не повторилось, и такое оправдание казалось весьма здравым. Однако, почти три четверти заявок на закупки были на сумму менее 500 ф. ст., а многие — вообще на несколько фунтов. Сотруд­ников раздражало, что для покупки канцелярских това­ров приходилось следовать той же процедуре, как и при покупке на сумму в несколько десятков тысяч фунтов. В этом случае мысль о том, что без контроля возможны нарушения, приводила лишь к одному результату: механизмы контроля сохранялись во всех попытках изме­нить процесс, так что в конце концов процесс оставля­ли в покое, вместо того чтобы усовершенствовать его.

Ключ к этой головоломке — определить, при каких условиях подобный контроль имеет смысл, и создать несколько отдельных процессов: один со встроенными механизмами контроля, другие без них. Большинство страховых компаний применяют этот принцип при ра­боте с исками. Чтобы компания могла избежать мошен­нических исков, оценщик должен проверить иск, но с экономической точки зрения это имеет смысл только для исков на сумму, превышающую некий порог. Таким образом, компания работает с процессом, включающим этап оценки для исков, превышающих пороговую сум­му, и с упрощенным процессом (без этапа оценки) при обработке исков на сравнительно небольшие суммы.

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

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

Уменьшайте количество входов в процессы

Огромное количество времени во многих организациях тратится на сопоставление и сведение воедино разных форм представления одного и того же. Заявления на отпуск сопоставляются с отгулами, заявки на закупку — со счетами-фактурами, записи об отсутствии на работе по болезни — с бюллетенями, авиабилеты — с бронью и так далее; список практически бесконечен. Процессы, которые содержат в себе подпроцессы и задачи, вклю­чающие подобные сверки, скорее всего, окажутся мед­ленными и запутанными, потребуют участия большого количества людей. Уменьшение количества входов в процесс — один из способов уменьшения количества проводимых сверок, ускорения процесса и уменьшения численности задействованного персонала. Чтобы усо­вершенствовать процесс, просто убирают те входы, ко­торые нужно будет сопоставлять с другими входами, хо­тя подобное изменение может потребовать серьезных изменений в других частях процесса.

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

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

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

Сохраняйте децентрализованные подразделения, централизуя обмен информацией

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

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

Применение принципов реинжиниринга

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

Чтобы стимулировать оба типа мышления, по наше­му мнению, полезно использовать разнообразные спо­собы решения проблем. Один способ заключается в том, чтобы команда сначала обсудила каждый принцип и добилась полного понимания его значения. Если в ра­боте команды участвует внешний консультант, то он может привести примеры, как эти принципы применя­лись в других организациях. Другой способ — написать принципы на листе бумаги и повесить этот лист на сте­ну, чтобы всем было видно, или написать их на специ­альной пленке и показывать на экране. Третий способ — провести в команде мозговой штурм на тему "Как можно применить эти принципы для преобразования нашего процесса". Команде следует напомнить правила мозгового штурма: не должно быть никакой критики, команда должна ориентироваться на количество идей, а не на их качество, идеи должны быть скорее свободны­ми, чем строго аналитическими, каждая идея должна записываться, и команде следует развивать эти идеи, чтобы использовать весь заложенный в них потенциал, а не оценивать их.

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

Какую бы процедуру ни использовала команда, главная цель в том, чтобы она придумала разные спосо­бы удовлетворения запросов клиентов процесса, не ско­вывая себя установками, господствующими в организа­ции в настоящий момент. Команда должна выйти за рамки (как в задаче с девятью точками) и искать твор­ческие решения, ломая привычные подходы к работе. Полезно повесить на стену формулировку видения про­цесса, чтобы постоянно напоминать команде, чего она хочет добиться от процесса, а также перечень инстру­ментов, которые могут в этом помочь, чтобы команда генерировала идеи о том, как их можно использовать.

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

Собрание закончено, и участники команды присту­пают к проработке выдвинутых идей. В течение не­скольких следующих дней некоторые из идей превра­тятся в предложения, позволяющие воплотить в реаль­ность видение процесса и достичь поставленных целей по эффективности и результативности. Задача реинжиниринговой команды в том, чтобы развить эти идеи и найти инструменты для внедрения в практику. Для этого стоит использовать методы составления карты процесса, представленные в гл. 8, изображая процесс в графическом виде на бумаге.

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

Методы усовершенствования процессов

Хотя новый процесс, скорее всего, будет сильно отли­чаться от того процесса, чье место он займет — если только он призван достичь тех смелых целей, что были поставлены видением процесса, — части процесса оста­нутся теми же самыми. Так, хотя несколько субпроцес­сов, возможно, будут пропущены, скомбинированы с другими, переданы в ведение поставщиков или клиен­тов, остальные части процесса останутся на своем месте. Субпроцессы будут представлены теми же самыми кружками как в старой, так и в новой карте процесса (схеме информационных потоков). Это, однако, не оз­начает, будто команда должна просто-напросто сохранить "статус-кво". Изменения в одной из частей процес­са дают отличную возможность пересмотреть те субпроцессы, которые остались нетронутыми с прошлой вер­сии, и подвергнуть их строгому анализу на возможность усовершенствования. Существует несколько испробо­ванных и проверенных методик, которые помогут уви­деть, где и какие изменения нужны. Эти изменения бу­дут менее масштабными, чем реинжиниринг, проведен­ный командой над основной частью процесса, и цель здесь в том, чтобы усовершенствовать и упростить суб­процесс, который, как уже было решено, следует оста­вить от прежнего процесса. Схема информационных потоков субпроцесса весьма полезна для таких усовер­шенствований. Существуют четыре основных метода, которыми может воспользоваться команда для упроще­ния представленного на такой схеме процесса.

Анализ методом пяти вопросов

Как уже ясно из названия, метод пяти вопросов заклю­чается в ответах на пять вопросов для каждого этапа процесса, представленного на схеме информационных потоков:

В чем состоит задача?

Где она выполняется?

Когда она выполняется?

Кто ее выполняет?

Как ее выполняют?

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

Команду не должны ограничивать точные формули­ровки вопроса. Каждый из вопросов можно интерпре­тировать по-разному, и в этом сильная сторона методи­ки: ведь это позволяет взглянуть на процесс с разных сторон. Таким образом, спрашивая, когда выполняется этап и можно ли его выполнить в другое время, команда должна рассматривать вопрос времени в отношении как можно большего числа событий. Среди ответов могут быть такие, как: "до того как произошла ошибка", "до того как покупатель пожалуется", "после того как мы проверили ошибки", "до того как начать" и др.

Хотя это не такой уж и сложный метод анализа, он необыкновенно эффективен и мы использовали его для достижения небольших, но важных улучшений в разных аспектах процессов. В гл. 8 мы упомянули команду са­нитаров, которые изобразили алгоритм процесса транс­портировки пациентов из палаты в операционную и об­ратно в палату, после того как операция закончилась. Алгоритм показывал, что первым делом санитар, при­шедший в палату, проверял, в палате ли пациент и готов ли он к переезду в операционную. Отвечая на пять во­просов, команда сначала рассмотрела задачу этого этапа и согласилась, что задача вполне реальная. Затем зада­лись вопросом, можно ли было решить задачу в другом месте или в другое время. Это сразу навело на мысль, что лучшее время для проверки — до того, как санитар от­правится в палату: ведь если пациента перевели в другую палату, это позволит избежать ненужного визита. Если санитар позвонит в палату, прежде чем отправиться туда, он сможет не просто проверить, на месте ли пациент, но и сообщить персоналу о своем скором приезде, так что они смогут подготовить пациента к переезду в операци­онную до приезда санитара. Алгоритмический график показывал, что после проверки, на месте ли пациент, происходила задержка, пока персонал палаты готовил пациента к переезду в операционную. Так, сдвинув про­верку на более раннее время (до того как санитар поки­нет операционную), команда смогла уменьшить количе­ство ненужных поездок в палаты, откуда пациентов пере­вели, уменьшить количество операций, сорванных из-за того, что пациента не смогли найти в другой палате, сэ­кономить время санитаров, ожидавших, пока пациентов подготовят к операции.

Анализ добавленной стоимости

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

Чтобы провести анализ добавленной стоимости, ко­манда должна включить каждый этап процесса в одну из следующих категорий:

добавляет реальную стоимость,

добавляет стоимость для организации (business value),

никакой стоимости не добавляет.

Этапы, которые добавляют стоимость, — это те эта­пы, которые сказываются на окончательном результате процесса и которые напрямую связаны с удовлетворе­нием потребностей клиента. Среди них такие этапы, как собственно производство продукции в соответствии с пожеланиями клиента, или, в случае услуги, предос­тавление информации, которая может потребоваться клиенту, или само по себе оказание услуги. Вернемся к команде санитаров: алгоритм процесса доставки паци­ентов из палаты и в палату состоял более чем из 30 шагов, но все же только три шага на самом деле обеспечивали создание добавленной стоимости: анесте­зия, операция, реанимация. Можно представить себе как почувствует себя пациент, если будет пропущен хотя бы один из них! Хотя другие шаги тоже были важны­ми, они не были столь необходимыми и скорее были связаны с воплощением процесса, чем с решением его фундаментальной задачи.

Шаги, добавлявшие организационную стоимость, — это такие этапы, которые нужны организации, но не добавляют никакой реальной стоимости с точки зрения клиента. Среди них, например, хранение информации, которая может потребоваться другим отделам, заказ ма­териалов, подготовка отчетов. Иногда кажется, будто те или иные действия добавляют организационную стои­мость, потому что нам кажется, будто их результатами пользуется кто-то другой, но последующий анализ часто показывает, что никакой цели у них нет. Один менед­жер однажды рассказал нам, как отдел сбыта его компа­нии каждый месяц составлял подробный отчет о своей деятельности. Когда он спросил их, зачем они состав­ляют такие подробные отчеты, сбытовики ответили, что информация была нужна центральному офису, хотя са­ми они не имели представления, зачем и каким образом эта информация использовалась. Дальнейшие расспросы в центральном офисе показали, что никто не знал, за­чем отдел сбыта составлял отчеты, которые приходили каждый месяц, но всем казалось, будто эти данные важ­ны для самих сбытовиков: иначе зачем им тратить столько сил! Более подробные расспросы показали, что четырьмя годами раньше менеджер-практикант попро­сил собрать информацию для обзора, который он со­ставлял. Он уже давно ушел из компании, но каждый месяц информация предоставлялась, и никто не помнил и даже не спрашивал, зачем.

Подобные действия можно найти в каждой организа­ции. Задачи выполняются, даже если реальная причина давно исчезла, и на первый взгляд кажется, будто они кому-то нужны, хотя этот "кто-то" всегда находится в другом отделе. Предполагая, будто эти задачи добавляют организационную стоимость, команда должна удостове­риться, что организации это действительно нужно и что человек, которому это нужно, существует в реальности.

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

Анализ добавленной стоимости, использующий ал­горитмический график всех этапов процесса, предпола­гает, что все этапы разбиваются на три категории: до­бавляющие реальную стоимость, добавляющие органи­зационную стоимость, не добавляющие никакой стои­мости. Здесь может оказаться полезным маркер, позво­ляющий наглядно показать, какая часть этапов прихо­дится на долю каждой из категорий. Следующая задача в том, чтобы подумать, нельзя ли оптимизировать ка­кие-либо из добавляющих стоимость процессов — воз­можно, путем уменьшения времени или затрат. Можно ли устранить некоторые из этапов добавляющих органи­зационную стоимость? И наконец, как можно устранить не добавляющие стоимость этапы и улучшить процесс (при помощи метода пяти вопросов), устраняя причины некоторых проблем и предоставляя людям полномочия принимать решения там, где раньше им нужна была чья-то подпись?

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

Устранение бюрократии

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

Анализ длительности цикла

Анализ длительности цикла также использует алгорит­мические схемы, но цель здесь в том, чтобы показать, за какое время процесс пройдет полный цикл. Начиная с первого этапа процесса и до самого последнего на схеме показывается, сколько времени прошло с момента нача­ла процесса. Нужно также зафиксировать время выпол­нения каждого этапа. Как только это сделано, команда может сравнить суммарное время выполнения всех эта­пов с длительностью всего процесса. Не так уж редко встречаются случаи, когда соотношение достигает 5— 10%. Другими словами, только около 10% времени вы­полнения процесса действительно занято какой-то ра­ботой. Остальное время уходит на всевозможные за­держки, пока документы лежат на чьем-то столе или пока товары куда-то везут.

Существует несколько способов уменьшить полную длительность цикла, сохраняя длительность каждого этапа на прежнем уровне и тем самым увеличивая долю полезного времени. Некоторые задания можно выпол­нять параллельно с другими, если раньше они выполня­лись последовательно. Алгоритмическая схема покажет, не приходится ли возить документы или продукцию из одного отдела в другой, и если так оно и есть, вероятно, существует возможность объединить выполнение всех этапов в одном месте в одно время, уменьшив тем са­мым задержки, связанные с транспортировкой. При по­мощи лучшей координации действий можно также со­кратить время, пока документы ждут на чьем-то столе. Например, если табели за неделю должны быть собраны в 10.00 утра в пятницу, имеет смысл закончить и пере­дать их в 5.00 вечера в четверг. Изменение места произ­водства товаров также может уменьшить время транс­портировки. Итак, существует множество способов уменьшить промежутки времени между выполнением разных этапов процесса при помощи тщательного пла­нирования и проектирования.

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