8 Создание карты процесса

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

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

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

Структурный анализ процессов

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

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

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

Схема внешней среды процесса

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

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

Графики информационных потоков

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

• Этап 1. Отдел по обслуживанию покупателей полу­чает заказ от покупателя, записывает его и посылает в отдел продаж и производства, а копию — в отдел технической поддержки.

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

• Этап 3. Используя информацию о заказе покупателя и техническую спецификацию, отдел продаж и произ­водства оформляет заказ на поставку, а также инфор­мацию о текущем уровне запасов. Этот заказ и инфор­мация передаются в планово-производственный отдел.

• Этап 4. Разрабатывается план производства для от­дела по планированию расходов сырья и материалов. Это делается на основе информации о продажах и запасах.

• Этап 5. Отдел по планированию сырья и материалов использует производственный план, номер контракта и информацию о наличии транспорта и запасов сырья и материалов для разработки требований к перевозке и плана потребности в материальных ресурсах.

• Этап 6. Отдел планирования перевозок выписывает заказ на транспортное средство, используя требования к перевозке и текущую информацию от третьей сто­роны (перевозчика). Информация о задержках скап­ливается в отделе по обслуживанию покупателей.

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

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

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

Выделение уровней информационных потоков

С помощью описанного способа можно построить трех­мерную карту, изображающую процесс, его субпроцессы и т.д. Схема информационных потоков второго уровня на основе этапа 4 на рис. 8.3 показана на рис. 8.4.

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

Рекомендации для использования SPA

Совершенно ясно, что существует необходимость разъ­яснения и наведения порядка в использовании SPA ко­мандой реинжиниринга, чтобы она избежала ошибок и трудностей при составлении карты процесса, и сущест­вует несколько рекомендаций, которые помогут это сде­лать. Первая — каждый процесс, субпроцесс следует обозначить определенной цифрой, которая позволит легко отличать его уровень и место в процессе. Сле­дующую за схемой внешней среды схему информацион­ных потоков первого уровня следует обозначить как уровень 1, а все субпроцессы в нем последовательно пронумеровать (1, 2, 3 и т.д.). На следующем уровне де­тализации в каждом субпроцессе следует пронумеровать его основные части, используя номер субпроцесса и но­мер его части. Это означает, что если субпроцесс 1 делится на три части, то они будут пронумерованы как 1.1, 1.2 и 1.3. Две части, составляющие субпроцесс 2, будут иметь номера 2.1 и 2.2. Аналогично и с осталь­ными субпроцессами. При еще большем уровне детали­зации две части шага 1.1 будут иметь номера 1.1.1 и 1.1.2. Подобным образом мы можем легко определить уровень детализации, место в процессе и основной суб­процесс, к которому относится данный шаг или целый процесс. Эта система похожа на нумерацию разделов и подразделов в обычных документах.

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

Рис. 8.5. Справочник процесса

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

Наконец, третья рекомендация при использовании SPA состоит в необходимости поддерживать соответст­вие входов/выходов между различными уровнями дета­лизации. В сущности это означает, что число входов и выходов процесса на разных уровнях должно быть од­ним и тем же. Например, на рис. 8.6, у субпроцесса 1 есть два входа и один выход. Когда мы рассматриваем более детально этот субпроцесс на следующем уровне схемы информационных потоков, у него должно быть также два входа и один выход, изображенные стрелками извне. У основных шагов процесса на этом уровне тоже могут быть свои входы и выходы, но они должны быть замкнутыми, так как соединяют основные шаги этого уровня между собой. Если бы на рис.8.6 субпроцесс 1.1 был разбит на составляющие еще более низкого уровня, то мы получили бы один вход и один выход, хотя его составляющие снова могли бы быть связанны­ми дополнительными входами и выходами.

Рис. 8.6. Соответствие входов/выходов

Поддержка соответствия входов/выходов обеспечивает внутреннюю целостность схем информационных потоков.

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

Схемы алгоритмов

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

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

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

Рис. 8.7. Символы, -рекомендуемые для использования в схемах алгоритмов

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

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

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

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

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

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

Максимизация использования SPA

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

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

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

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

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

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

Рис. 8.9. Схема информационных потоков процесса ремонта

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

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

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

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

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

Структурный анализ процессов

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

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

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

Схема внешней среды процесса

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

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

Графики информационных потоков

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

• Этап 1. Отдел по обслуживанию покупателей полу­чает заказ от покупателя, записывает его и посылает в отдел продаж и производства, а копию — в отдел технической поддержки.

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

• Этап 3. Используя информацию о заказе покупателя и техническую спецификацию, отдел продаж и произ­водства оформляет заказ на поставку, а также инфор­мацию о текущем уровне запасов. Этот заказ и инфор­мация передаются в планово-производственный отдел.

• Этап 4. Разрабатывается план производства для от­дела по планированию расходов сырья и материалов. Это делается на основе информации о продажах и запасах.

• Этап 5. Отдел по планированию сырья и материалов использует производственный план, номер контракта и информацию о наличии транспорта и запасов сырья и материалов для разработки требований к перевозке и плана потребности в материальных ресурсах.

• Этап 6. Отдел планирования перевозок выписывает заказ на транспортное средство, используя требования к перевозке и текущую информацию от третьей сто­роны (перевозчика). Информация о задержках скап­ливается в отделе по обслуживанию покупателей.

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

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

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

Выделение уровней информационных потоков

С помощью описанного способа можно построить трех­мерную карту, изображающую процесс, его субпроцессы и т.д. Схема информационных потоков второго уровня на основе этапа 4 на рис. 8.3 показана на рис. 8.4.

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

Рекомендации для использования SPA

Совершенно ясно, что существует необходимость разъ­яснения и наведения порядка в использовании SPA ко­мандой реинжиниринга, чтобы она избежала ошибок и трудностей при составлении карты процесса, и сущест­вует несколько рекомендаций, которые помогут это сде­лать. Первая — каждый процесс, субпроцесс следует обозначить определенной цифрой, которая позволит легко отличать его уровень и место в процессе. Сле­дующую за схемой внешней среды схему информацион­ных потоков первого уровня следует обозначить как уровень 1, а все субпроцессы в нем последовательно пронумеровать (1, 2, 3 и т.д.). На следующем уровне де­тализации в каждом субпроцессе следует пронумеровать его основные части, используя номер субпроцесса и но­мер его части. Это означает, что если субпроцесс 1 делится на три части, то они будут пронумерованы как 1.1, 1.2 и 1.3. Две части, составляющие субпроцесс 2, будут иметь номера 2.1 и 2.2. Аналогично и с осталь­ными субпроцессами. При еще большем уровне детали­зации две части шага 1.1 будут иметь номера 1.1.1 и 1.1.2. Подобным образом мы можем легко определить уровень детализации, место в процессе и основной суб­процесс, к которому относится данный шаг или целый процесс. Эта система похожа на нумерацию разделов и подразделов в обычных документах.

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

Рис. 8.5. Справочник процесса

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

Наконец, третья рекомендация при использовании SPA состоит в необходимости поддерживать соответст­вие входов/выходов между различными уровнями дета­лизации. В сущности это означает, что число входов и выходов процесса на разных уровнях должно быть од­ним и тем же. Например, на рис. 8.6, у субпроцесса 1 есть два входа и один выход. Когда мы рассматриваем более детально этот субпроцесс на следующем уровне схемы информационных потоков, у него должно быть также два входа и один выход, изображенные стрелками извне. У основных шагов процесса на этом уровне тоже могут быть свои входы и выходы, но они должны быть замкнутыми, так как соединяют основные шаги этого уровня между собой. Если бы на рис.8.6 субпроцесс 1.1 был разбит на составляющие еще более низкого уровня, то мы получили бы один вход и один выход, хотя его составляющие снова могли бы быть связанны­ми дополнительными входами и выходами.

Рис. 8.6. Соответствие входов/выходов

Поддержка соответствия входов/выходов обеспечивает внутреннюю целостность схем информационных потоков.

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

Схемы алгоритмов

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

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

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

Рис. 8.7. Символы, -рекомендуемые для использования в схемах алгоритмов

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

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

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

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

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

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

Максимизация использования SPA

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

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

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

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

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

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

Рис. 8.9. Схема информационных потоков процесса ремонта

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

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