Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


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



Согласовав схему внешней среды процесса, команда должна создать карту процесса, позволяющую взглянуть на процесс более детально. Это будет схема информационных потоков первого уровня, и на ней будут показаны основные составляющие процесс субпроцессы. Каждый субпроцесс изображается в виде кружка, с идущими к нему и от него входами и выходами в виде стрелок. Здесь не требуется включать в схему клиентов и поставщиков, как это было на схеме внешней среды процесса, только входы и выходы от них и к ним. Таким образом, можно избежать пере усложнения схемы процесса и показать только информацию, являющуюся новой по сравнению с предыдущей схемой. Для процесса, показанного на рис.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, рисование алгоритмов может показаться сначала немного трудным, но вскоре люди развивают сноровку и начинают это делать быстро и аккуратно. Хотя окончательную версию стоит сделать красиво, на компьютере, первоначальные наброски лучше всего делать на больших листах бумаги при участии каждого. Имеет смысл пригласить кого-нибудь, имеющего опыт использования этого метода, чтобы он помог и подправил рисунки. Здесь снова можно дать рекомендации, как команде правильно использовать данный метод и получить от него максимум возможного.

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

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

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

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

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


Поделиться:



Популярное:

Последнее изменение этой страницы: 2016-03-22; Просмотров: 1062; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.028 с.)
Главная | Случайная страница | Обратная связь