Практическое руководство по реинжинирингу бизнес- процессов - Майк Робсон, Филип Уллах. Практическое руководство по реинжинирингу бизнес- процессов - Ма. Guide to business process reengineering

• Название: Guide to business process reengineering
• Анкор: Практическое руководство по реинжинирингу бизнес- процессов - Майк Робсон, Филип Уллах.doc
• Дата: 17.12.2017
• Размер: 1.19 Mb.
• Имя файла: Практическое руководство по реинжинирингу бизнес- процессов - Ма.doc
• Тип: Guide; #11854
• Категория: Экономика. Финансы
• страница: 24 из 31

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

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

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

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

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

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

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

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

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

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

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

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


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