Моделирование и реинжиниринг процессов производства

Тема 7. Моделирование и реинжиниринг процессов производства.

· Методы моделирования бизнес-процессов.

· Метод функционального моделирования IDEF0.

· Метод информационного моделирования IDEF1.

· Метод моделирования процессов IDEF3.

· Метод моделирования потоков данных DFD.

· Реинжиниринг бизнес – процессов.

Методы моделирования бизнес-процессов

Для моделирования бизнес-процессов используется несколько различных методов. К числу наиболее распространенных методов относятся:

Рекомендуемые материалы

· метод функционального моделирования IDEF0;

· метод информационного моделирования IDEF1;

· метод моделирования процессов IDEF3;

· метод моделирование потока данных DFD.

Метод функционального моделирования IDEF0

Метод IDEF0 считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, формирующие значимый для потребителя результат, представляют ценность, и именно их улучшением предстоит в дальнейшем заниматься. Модель, основанная на организационно-штатной структуре, может продемонстрировать лишь хаос, царящий в организации (о котором в принципе руководству и так известно, иначе оно бы не инициировало соответствующие работы), на ее основе можно только внести предложения об изменении этой структуры. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.

В соответствии с этим принципом бизнес-модель должна выглядеть следующим образом:

1. Верхний уровень модели должен отражать только контекст системы — взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром.

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

3. Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций — совокупностей операций, сгруппированных по определенным признакам. Бизнес-функции детализируются с помощью элементарных бизнес-операций.

4. Описание элементарной бизнес-операции осуществляется посредством задания алгоритма ее выполнения.

Метод IDEF0 представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF0 отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этого метода основываются на следующих концепциях:

· Графическое представление блочного моделирования. Графика блоков и дуг IDEF0-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих "ограничения", которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются.

· Строгость и точность. Выполнение правил IDEF0 требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила IDEF0 включают: ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков — ограничение мощности краткосрочной памяти человека), связность диаграмм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), синтаксические правила для графики (блоков и дуг), разделение входов и управлений (правило определения роли данных).

· Отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель.

Метод IDEF0 может использоваться для моделирования самых разнообразных процессов и систем. В существующих системах метод IDEF0 может быть использован для анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются.

Построение IDEF0 -модели заключается в выполнении следующих действий:

· сбор информации об объекте, определение его границ;

· определение цели и точки зрения модели;

· построение, обобщение и декомпозиция диаграмм;

· критическая оценка, рецензирование и комментирование.

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

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

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

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

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

Рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цель. Опыт показал, что для отдельной модели, которая создается независимо от какой-либо другой модели, декомпозиция одного из ее блоков должна прекращаться, если:

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

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

· Необходимо изменить точку зрения, чтобы детализировать блок. Изменение точки зрения происходит примерно так же, как изменение уровня абстракции. Это чаще всего характерно для ситуаций, когда точку зрения модели нельзя использовать для декомпозиции конкретного блока, т. е. этот блок можно декомпозировать, только если посмотреть на него с другой позиции. Об этом может свидетельствовать заметное изменение терминологии.

· Блок очень похож на другой блок той же модели или на блок другой модели. Иногда встречается блок, чрезвычайно похожий на другой блок модели. Два блока похожи, если они выполняют примерно одну и ту же функцию и имеют почти одинаковые по типу и количеству входы, управления и выходы. Если второй блок уже декомпозирован, то разумно отложить декомпозицию и тщательно сравнить два блока. Если нужны ничтожные изменения для совпадения первого блока со вторым, то внесение этих изменений сократит усилия на декомпозицию и улучшит модульность модели (т.е. сходные функции уточняются согласованным образом).

· Блок представляет тривиальную функцию. Тривиальная функция — это такая функция, понимание которой не требует никаких объяснений. В этом случае очевидна целесообразность отказа от декомпозиции, потому что роль IDEF0 заключается в превращении сложного вопроса в понятный, а не в педантичной разработке очевидных деталей. В таких случаях декомпозиция определенных блоков может принести больше вреда, чем пользы. Тривиальные функции лучше всего описываются небольшим объемом текста. Следует заметить, что "тривиальный" не означает "бесполезный". Тривиальные функции выполняют очень важную роль, поясняя работу более сложных функций, а иногда и соединяя вместе основные подсистемы. Поэтому при анализе не следует пропускать тривиальные функции. Наоборот, их существование должно быть зафиксировано и они должны быть детализированы, как и любые другие функции. Однако следует предостеречь от больших затрат времени на анализ тривиальных функций системы. Усиленное внимание к мелочам может привести к созданию модели, которой будет недоставать абстракции, что сделает ее трудной для понимания и использования.

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

Основными составляющими компонентами информационной модели являются:

диаграммы – структурные  изображения информационной модели, представляющие, в соответствии с набором правил, состав и логические связи используемых данных;

словарь – значение каждого элемента модели описывается текстовым фрагментом.

Для разработчика информационной модели в IDEF1 важными для рассмотрения являются две области:

· реальный мир, состоящий из материальных и нематериальных объектов (таких как люди, предметы, идеи и др.) с их свойствами и взаимными связями, который изучается через общение с сотрудниками организации;

· информационная область, содержащая информационное изображение объектов реального мира.

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

Базовым понятием в методологии IDEF1 является понятие сущности. Сущность определяется как реальный или абстрактный объект, набор отличительных свойств которого, называемых атрибутами, известен. Каждая сущность имеет имя и атрибуты.                 

Фазы разработки информационной модели

Работу рекомендуется разбивать на 5 фаз, каждая из которых должна заканчиваться вполне определенным измеряемым результатом:

Фаза 0 – фаза определения предмета исследования и границ модели;

Фаза 1 – на этой фазе определяются классы сущностей;

Фаза 2 – на этой фазе определяют классы отношений, существующих между определенными на предыдущей фазе классами сущностей;

Фаза 3 – предметом этой фазы является определение классов ключей для каждого класса сущностей и каждого класса атрибутов, который используется классом ключей;

Фаза 4 – целью последней фазы является распределение не ключевых классов атрибутов по классам сущностей и полное описание таких классов атрибутов.   

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

Метод моделирования процессов IDEF3

Как и в методе IDEF0, основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели — действие, или в терминах IDEF3 "единица работы". Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис.3).

Рис. 3. Изображение и нумерация действия в диаграмме IDEF3

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

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

· разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других;

· сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения другого действия.

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

Рис. 4. Соединения "и"

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

Рис. 5. Соединение "исключающее "или""

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

Рис. 6. Соединения "или"

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

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

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

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

Метод моделирования потоков данных DFD

Диаграммы потоков данных DFD представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

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

Состав диаграмм потоков данных

Основными компонентами диаграмм потоков данных являются:

· внешние сущности;

· системы и подсистемы;

· процессы;

· накопители данных;

· потоки данных.

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

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

Рис. 7. Графическое изображение внешней сущности

При построении модели сложной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем.

Подсистема (или система) на контекстной диаграмме изображается так, как она представлена нарис.8.

Рис. 8. Подсистема по работе с физическими лицами (ГНИ — Государственная налоговая инспекция)

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

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

Процесс на диаграмме потоков данных изображается, как показано на рис.9.

Рис. 9. Графическое изображение процесса

Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: "Ввести сведения о налогоплательщиках", "Выдать информацию о текущих расходах", "Проверить поступление денег".

Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.

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

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

Рис. 10. Графическое изображение накопителя данных

Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно соответствовать модели данных.

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

Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рис.11). Каждый поток данных имеет имя, отражающее его содержание.

Рис. 11. Поток данных

Построение иерархии диаграмм потоков данных

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

· Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично IDEF0). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

· Не загромождать диаграммы несущественными на данном уровне деталями.

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

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

Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:

· наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

· возможности описания преобразования данных процессов в виде последовательного алгоритма;

· выполнения процессом единственной логической функции преобразования входной информации в выходную;

· возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

Спецификации представляют собой описания алгоритмов задач, выполняемых процессами. Они содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Языки спецификаций могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков моделирования.

Повторяющиеся стадии бизнес – процессов

1. Постановка целей.

2. Планирование.

3. Исполнение.

4. Измерение достигнутых показателей.

5. Определение отклонений.

6. Анализ причин отклонений.

7. Принятие управленческих решений по результатам анализа.

7.1. Оптимизация.

7.2. Совершенствование.

7.3. Реинжиниринг.

Реинжиниринг бизнес – процессов.

Понимание процесса

Первая задача реинжиниринга состоит в том, чтобы получить ясное и всестороннее понятие о про­цессе, подлежащем реинжинирингу.

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

Границы процессов

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

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

Границы процесса — это точки, где входы и выходы входят и выходят из процесса. Последняя задача на стадии определения границ процесса состоит в определении его поставщиков и клиентов. Необходимо точно знать, кто они и каковы их требования.

Требования клиентов

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

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

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

Измерение текущего процесса

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

Разработка видения нового процесса

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

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

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

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

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

Описание контекста видения

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

Перепроектирование процесса. (Разработка новой оргструктуры).

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

Вместе с этой лекцией читают "Влияние характера внешней среды на методы управления фирмой".

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

Собственно работа реинжиниринга организацион­ной структуры начинается на третьем шаге с вопроса: "Что мы хотим от структуры?" Мы считаем, что метод мозгового штурма — лучший способ получения полного перечня, требуемого на данной стадии.

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

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

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

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