Доводчик (Завершающий работу) (Д)

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

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

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

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

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

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

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

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

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

Приложение 4

Применение принципа в отношении внешних клиентов на примере ком­пании в телекоммуникационной индустрии.

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

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

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

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

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

Приложение 5