<< Оглавление

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

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

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

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

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

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

Предложение, чтобы сотрудник одного специализированного отдела выполнял обязанности сотрудника из другого отдела, является примером творческого мышления, о чем говорилось в предыдущей главе. Но это вряд ли целесообразно, и команда может прийти к заключению, что хотя такие идеи очень творческие, из них навряд ли можно извлечь практическую пользу. Если так, команде требуется рассмотреть, что необходимо для обеспечения таких изменений в процессе, принимая во внимание информационные и мотивационные факторы, описанные в гл. 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-связь между производственным департаментом и поставщиком, предоставляя последнему возможность принимать решения о закупках, которые раньше принимались внутри организации. В ответ на принятие на себя дополнительной ответственности поставщики получают привилегированный статус, в результате чего проблема разрешается ситуацией "выигрыш — выигрыш" для обеих сторон.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• В чем состоит задача?
• Где она выполняется?
• Когда она выполняется?
• Кто ее выполняет?
• Как ее выполняют?

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

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

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

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

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

• добавляет реальную стоимость,
• добавляет стоимость для организации (business value),
• никакой стоимости не добавляет.

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

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

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

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

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

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

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

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

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

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

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