Схемы алгоритмов
Мы уже несколько раз в этой главе упоминали схемы алгоритмов или алгоритмическую форму записи и теперь более подробно рассмотрим, как их можно использовать в совокупности со схемами информационных потоков. Мы не считаем, что SPA заменяет алгоритмические схемы, он скорее включает их на самом большом уровне детализации, требуемой для создания карты сложного процесса. Как мы увидим в конце этой главы, сочетание схем информационных потоков и алгоритмических схем дает значительные выгоды.
Алгоритмическая форма записи использовалась в течение многих лет, что доказывает состоятельность данного метода. Но реинжиниринг процессов вызывает изменения большего масштаба, чем это наблюдалось до сих пор и для чего разрабатывалась алгоритмическая форма записи. Вернувшись к нашей географической аналогии, можно сказать, что схемы улиц полезны департаменту планирования развития города в мэрии для того, чтобы решить, как улучшить движение транспорта в центре города, но эти схемы малопригодны для реконструкции национальных и наднациональных магистралей, что мы наблюдаем в Европе в последние годы.
Схемы алгоритмов — это зрительная интерпретация шагов процесса, и их обычно используют на том уровне детализации, где фигурируют отдельные задачи, действия и решения. Для их обозначения используются специальные символы. Хотя существует множество разных символов, наиболее распространенные из них приведены на рис.8.7 и их достаточно для большинства команд, чтобы изобразить все детали процессов низкого уровня. Некоторым читателям знакомы шаблоны, с помощью которых эти символы можно рисовать быстро и аккуратно и которые легко умещаются в кейсе, хотя опять-таки сегодня существуют программные продукты, делающие рисование алгоритмических схем намного более легким.
Рис. 8.7. Символы, -рекомендуемые для использования в схемах алгоритмов
Точно так же, как и с SPA, рисование алгоритмов может показаться сначала немного трудным, но вскоре люди развивают сноровку и начинают это делать быстро и аккуратно. Хотя окончательную версию стоит сделать красиво, на компьютере, первоначальные наброски лучше всего делать на больших листах бумаги при участии каждого. Имеет смысл пригласить кого-нибудь, имеющего опыт использования этого метода, чтобы он помог и подправил рисунки. Здесь снова можно дать рекомендации, как команде правильно использовать данный метод и получить от него максимум возможного.
Первая простая рекомендация состоит в том, что каждое действие, изображенное прямоугольником в процессе, должно начинаться с глагола. Но здесь общей проблемой является то, что люди часто используют глаголы для описания своих действий в процессе, а это может вносить путаницу. Например, кто-то заявляет, что следующим шагом в процессе является сбор важной информации, и при этом может невольно скрыть тот факт, что это действие на самом деле представляет собой целую серию действий, где заняты разные люди. Помните, что "собрать важную информацию" является, скорее всего, отдельным субпроцессом, который должен быть представлен на графике информационных потоков предыдущего уровня в виде круга со своими входными данными и выходом, которым может быть отчет или рекомендация. На уровне же алгоритма требуется больше деталей для того, чтобы показать шаги, людей и решения, относящиеся к этой задаче. Один из способов выйти на этот уровень детализации — спросить: "Как вы это делаете?" Поэтому в данном случае коммуникатор должен спросить: "Как вы собираете важную информацию?" Обычно это позволяет вскрыть детали выполнения задачи, и затем каждый шаг следует изобразить отдельно, используя правильные алгоритмические символы.
Другой общей проблемой является то, что часто люди, описывая шаги процесса, представляют его в идеализированном виде. Они описывают, что должно происходить, если все идет по плану, а не то, что происходит, когда люди и обстоятельства, словно сговорившись, ломают эти планы. Коммуникатор или другие члены команды, не знакомые с этой стороной процесса, могут не знать, что при этом пропущены важные шаги. Очевидно, это затрудняет улучшение процесса, представленного в идеализированном варианте, поскольку на бумаге, по крайней мере, он всегда работает без непредвиденных препятствий и задержек.
И снова существует простой способ избежать этой проблемы. Коммуникатор должен спросить: "Не нарушается ли порядок действий?" или "Бывает ли так, что дела идут плохо и выполнение следующего этапа усложняется?" Обычно в ответ он слышит: "Ну конечно же!", и команда снова начинает детально описывать, что обычно происходит в процессе и отражать это в алгоритме.
Наконец, точка принятия решения, изображенная в виде ромба с выходами "да" или "нет", не должна относиться только к тем шагам процесса, где принимается сознательное и преднамеренное решение типа "это соответствует стандарту качества?" Очень часто точки принятия решений весьма полезны для того, чтобы понять, что идет не так как надо в процессе и выявить действия, которые могут поправить дело. Например, работая с командой санитаров больницы, которые старались улучшить процесс транспортировки пациентов в операционную и из нее, мы спросили, каково их первое действие по прибытии в палату, санитары заявили, что помочь пациенту залезть на каталку. Когда наш консультант спросил, всегда ли это происходит первым делом после их прихода, санитары ответили, что это зависит от того, в палате пациент или нет. В результате была добавлена точка принятия решения "Пациент в палате?". Ответ "нет" приводил к множеству вариантов, зависящих от того, послали ли санитара не в ту палату, отлучился ли пациент в туалет и т.д. Каждый вариант представили в виде точки принятия решения.
Выяснилось, что в больнице происходили регулярные опоздания в операционную по вине пациентов, которые не были готовы к операции и не ждали в палате, и для того, чтобы найти пациентов, санитары должны были выполнять большое количество дополнительных задач, например, позвонить в операционную, поискать в палате и палатах по соседству и т.д. Иногда такие задержки приводили к отмене операций, влекущей за собой значительные издержки и жалобы пациентов. Этот недостаток процесса легко было пропустить, если бы точки принятия решений использовались только для формальных решений по ходу процесса. На самом деле число дополнительных решений, которые обычно принимаются в процессе, хорошо иллюстрирует случай с бригадиром санитаров, который посмотрел на полный алгоритм, представленный на большом листе бумаги на стене, и язвительно усмехнулся: "Я и не догадывался, что принимаю столько решений во время работы, я буду просить прибавку к зарплате!"
Максимизация использования SPA
Хотя SPA кажется на первый взгляд сложным методом, команды очень быстро учатся рисовать схемы информационных потоков и алгоритмы, а также использовать эти средства для изменения и улучшения процесса. В следующей главе мы увидим, как SPA можно использовать вместе с различными принципами для реинжиниринга процесса, но на этой стадии на SPA можно рассматривать как трехмерную картину процесса. Так же как и составление алгоритмов, SPA незаменим, когда дело доходит до разработки нового процесса. Тем не менее, когда SPA используют в сочетании с алгоритмическими схемами, тогда выявляется вся сила данного метода.
Используя схемы информационных потоков высокого уровня, команда может сделать вывод, что именно требует значительных изменений в выполнении процесса, не тратя время на детали его субпроцессов. После разработки вариантов процесса, команда может детально изучить, что следует оставить от старого процесса, используя графики информационных потоков низкого уровня и алгоритмы выполнения отдельных задач для выпрямления и улучшения процесса. При этом способе команда избавляется от работы по улучшению деталей шагов процесса, которые могут полностью исчезнуть вследствие реинжиниринга на более высоком уровне. Теперь требуется выпрямлять и улучшать только те части процесса, которые остались.
Так, в процессе, состоящем из пяти субпроцессов, команда может провести реинжиниринг, соединив первые два субпроцесса в один, отдав третий субпроцесс в ведение внешнего поставщика и поменяв пятый субпроцесс, чтобы включить туда важные шаги, выполнявшиеся ранее клиентом. Остается неизменным только четвертый субпроцесс, и здесь команда должна использовать графики информационных потоков низкого уровня и алгоритмы этого субпроцесса для его улучшения.
Исходя из сказанного, в рабочем порядке можно определить, что разница между реинжинирингом процесса и текущим улучшением процесса заключается в уровне иерархии SPA, на котором делаются изменения. На самом низком уровне, где используются алгоритмические схемы, любые изменения являются конкретными небольшими улучшениями и выпрямлениями. По мере того как мы двигаемся вверх по иерархии, изменения становятся все более значимыми, и настоящий реинжиниринг происходит тогда, когда мы изменяем саму природу схемы информационных потоков первого уровня.
Другая выгода от движения вверх и вниз по иерархии процесса для внесения изменений в процесс касается тех трудностей, которые часто испытывают команды, стараясь думать достаточно широко и вносить большие изменения вместо маленьких непрерывных изменений. Эта проблема усложняется уровнем детализации, на котором команда рассматривает процесс, поскольку каждый член команды реинжиниринга обычно очень хорошо знает свою часть процесса. В такой ситуации очень помогает переход на уровень выше и взгляд на процесс на более абстрактном уровне.
Выгоды от более абстрактного взгляда хорошо видны из примера, основанного на алгоритме, который команда технического обслуживания в университете разработала для процесса реагирования на запросы по ремонту лабораторного оборудования (рис. 8.8). Хотя команда не пыталась провести реинжиниринг процесса, тем не менее, испытывала определенные трудности, стараясь хоть что-то в нем улучшить. Этот процесс, сведенный к обмену записками, являлся образцом за бюрократизированного процесса и постоянно давал пищу другим отделам шутить по поводу того, как много требуется инженеров по техническому обслуживанию, чтобы заменить лампочку.
Рис. 8.9. Схема информационных потоков процесса ремонта
Проблема состояла в том, что алгоритм был слишком детализирован, и прорыв случился, когда команда нарисовала схему информационных потоков более высокого уровня, на которой стали более ясно видны различные службы, вовлеченные в процесс, без деталей выполняемых ими задач (рис. 8.9). Команда сразу же увидела множество вариантов улучшения процесса, основанных на выведении лишних людей из процесса и совмещении задач. Кроме резкого сокращения времени реагирования на запрос о ремонте оборудования, сократилось и количество шуток типа, как много инженеров требуется, чтобы сделать этот ремонт!
Двигаясь вверх по иерархии процесса, команда получает возможность вносить более существенные, радикальные и долгосрочные изменения в процесс там, где это требуется. SPA, представляя процесс в виде набора схем, выстроенных в определенной иерархии, дает команде средство для этого и в то же самое время позволяет ей, спускаясь вниз по иерархии, корректировать изменения в результате такого решительного оперативного вмешательства.