Схемы алгоритмов. Мы уже несколько раз в этой главе упоминали схемы алгоритмов или алгоритмическую

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-08-03