Реинжениринг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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