С. В. Черемных
И. О. Семенов
В.С.Ручкин

СТРУКТУРНЫЙ
АНАЛИЗ
СИСТЕМ:
ЮЕГ-
ТЕХНОЛОГИИ

Москва
“Финансы и статистика”
2003
УДК 004.94:658.012.12

ББК 65.290-2с51

4-46

Серия
“Прикладные информационные технологии”
Основана в 1997 г.

Главный редактор серии
доктор технических наук, профессор

СВ. Черемных

РЕЦЕНЗЕНТ

доктор технических наук, профессор С.В. Назаров

Черемных С.В. и др.

4-46 Структурный анализ систем: ГОЕЕ-технологии / С.В. Черем-
ных, И.О. Семенов, В.С. Ручкин. — М.: Финансы и статистика,
2003.— 208 с.: ил. — (Прикладные информационные технологии).

18ВЫ 5-279-02433-3

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

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

2404000000- 119
010(01)-2001

263 - 2002

УДК 004.94:658.012.12

ББК 65.290-2с51

18ВМ 5-279-02433-3

© С.В.Черемных, И.О. Семенов, В.С. Ручкин, 2001
К читателю

Эффективная экономика — это прежде всего эффективное управ-
ление. Вывод, с которым трудно не согласиться, но который, несо-
мненно, требует расширенного толкования соответственно требова-
ниям времени, в котором мы живем.

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

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

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

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

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

Далее, естественно, следуют:

•	идентификация узких мест, отрицательно влияющих на эффектив-

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

•	разработка и реализация мероприятий по переходу от существую-
щей («аз 18») к нормативной («1о Ье») моделям, иначе говоря, по
устранению имеющихся проблем и изменению бизнес-архитектур
предприятия, перестройке бизнес-процессов;

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

Так или примерно так выглядит область приложений инструмен-
тальных средств, которые должны быть на вооружении или по край-
ней мере в поле зрения менеджера. Что же мы имеем сегодня?

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

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

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

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

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

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

•	рабочих программ вузов, выпускающих специалистов соответст-
вующих специальностей;

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

Что касается других мер, то здесь, как представляется, резервы
есть.

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

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

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

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

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

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

Созданная в 1998 г. серия “Прикладные информационные техно-
логии” в издательстве “Финансы и статистика” предполагает публи-
кацию именно таких работ.

К настоящему времени в этой серии издан ряд книг, в том числе
А.М. Вендров “СА8Е-технологии” (1998 г.), под ред. С.В. Назарова
“Практикум по пакетам прикладных программ” (1999 г.) — с расши-
ренным по сравнению с общепринятым в вузовской практике (до 14)
списком приложений У/тску\У8, В.А. Козлов “Открытые информаци-
онные системы” (1999 г.) — по стандартам в области взаимосвязи от-
крытых систем, А.Л. Фридман “Основы объектно-ориентированной
разработки программных систем” (2000 г.)- по методам анализа задач
и проектирования программных систем в этой области.

Представляемая книга “Структурный системный анализ: Ю ЕР -тех-
нологии” — первое в серии издание, посвященное инструментальным
методам моделирования бизнеса и ориентированное именно на сис-
тему вузовского образования в области менеджмента.

В книге изложен один из наиболее эффективных и, думается, в
наибольшей степени подходящий для изучения в вузовской системе
подход, восходящий в основе своей к такой широко известной техно-
логии структурного анализа и проектирования систем, как 8АВТ
(81шсШгеб Апа1у818 апб Ве81§п Тесйтцие).

Речь идет, как видно из названия книги, о семействе весьма рас-
пространенных за рубежом (теперь есть и отечественные примеры)
так называемых 1ВЕР-технол огнях (1сат ВЕРтШоп), включающем на
сегодняшний день 14 позиций. В соответствии с поставленной целью
в книге описываются технологии ГОЕРО (функциональное моделиро-
вание бизнес-процессов) и 1ВЕРЗ (документирование технологиче-
ских процессов, происходящих на предприятии, дополненных техно-
логиями анализа “потока данных” ВРВ (Ва1а Р1о\у В1а§гат8) и
“потока работ” (АУогкНолу).

Программная поддержка методологии осуществляется пакетом
ВРауш 2.5 фирмы РРАТ1РШМ (версия 1998 г.). Этот “союз” обеспечи-
6
вает интегрированность декларируемого подхода к описанию и оцен-
ке бизнеса компании в форме, позволяющей использовать его в прак-
тике менеджерами всех уровней.

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

Таким образом, у руководства компании возникла естественная
необходимость иметь перед собой модель деятельности предприятия,
которая отражала бы все механизмы и принципы взаимосвязи различ-
ных подсистем в рамках одного бизнеса. Модель, которая бы перио-
дически трансформировалась из исходной «аз 18» в нормативную
«Щ Ье» на соответствующих этапах жизненного цикла компании в це-
лях оптимизации ее деятельности “в такт” с изменениями внешней
среды.

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

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

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

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

С.В. Черемных,

доктор технических наук,
профессор Финансовой академии
при Правительстве РФ
Предисловие

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

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

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

Для функционального анализа на концептуальном уровне важно
иметь эффективную, удобную и “прозрачную” методологию, доступ-
ную для понимания широкому кругу аналитиков, экспертов, админи-
страторов.

Методология 8АВТ, лежащая в основе стандарта ГОЕРО, появив-
шаяся в конце 60-х гг., по-прежнему популярна среди аналитиков и
широко используется для анализа именно предметной области.

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

Приложения (всего их шесть) несут в себе довольно важную смы-
словую нагрузку, дополняющую и углубляющую содержание основ-
ной части издания. В Приложении 1 дана информация о всех 14 чле-
нах семейства ГОЕР с тем, чтобы читатель получил представление о
размерах фронта работ по развитию методологий описания биз-
нес-процессах.

В Приложениях 2 и 3 для полноты картины в области инструментов
моделирования авторы представили информацию о существующих
нотациях моделирования и о программном пакете Пе81ёп/ГОЕР —
альтернативной (по отношению к ВРАУт), программной поддержке
функционального и информационного моделирования.

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

Приложение 5 содержит перевод широко известной и в некотором
смысле знаковой статьи М. Хаммера “Реинжиниринг: не автоматизи-
руйте — уничтожайте”. Необходимость публикации данного мате-
риала обусловлена тем, что эта основополагающая по многим причи-
нам работа далеко не всем доступна.

Приложение 6 дает возможность всем желающим поупражняться
в ГОЕР-моделировании на базе хорошо известной предметной облас-
ти — сфере вузовского образования.

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

Укажем в заключение обширный источник дополнительной ин-
формации по тематике этой работы — речь идет, конечно, об Интер-
нете. Доступ к этому источнику обеспечивается использованием не-
скольких коротких словосочетаний: СА8Е-технологий, 8АЭТ, ГОЕР,
ШЕРО и ВР\Ут.
1

ГЛАВА

МОДЕЛЬ БИЗНЕСА
И СТРУКТУРНЫЙ

АНАЛИЗ ЮЕЕ

Практически в любой области деятельности люди используют тот
или иной вид моделей (математических, физических или компьютер-
ных), чтобы иметь более ясное представление о том, что они делают.
Существуют два основных способа описания моделей: статический и
динамический.

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

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

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

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

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

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

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

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

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

Чтобы дать представление о
том, какой должна быть модель
бизнеса, рассмотрим несколько
разновидностей моделей. Приве-
дем пример наиболее известной
модели, которую обычно исполь-
зуют сотрудники для описания

.	. ..	организованной компании

своей компании (рис. 1.1).

Еще один способ описания компании состоит в указании раз-
личных функций, реализуемых отделами, совместная работа кото-
рых обеспечивает выполнение процесса (рис. 1.2). В этой модели

Рис. 1.1. Модель иерархически
Поставщик

Компания

Рис. 1.2. Модель, показывающая, как различные функции
обеспечивают выполнение процесса

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

Любая компания — сложная система. Даже небольшую компанию
нелегко увидеть во всех деталях. Более крупные компании фактиче-
ски непостижимы: никто не имеет достаточно ясной картины, откры-
вающей абсолютно все детали. Поистине удивительно, что крупные
компании могут довольно успешно функционировать. Впрочем, тому
можно найти несколько причин. Самая главная из них состоит в том,
что компании, несмотря ни на что, меняются довольно медленно
(инерционно) и согласованно. По мере того как сами люди совершен-
ствуются, происходят перемены в компании. Причем лишь в той сте-
пени, в какой люди чувствуют себя способными осознать последст-
вия. До тех пор пока компания не меняется радикально, свойственная
ей инерция помогает ей функционировать. Но если компания встреча-
ется с трудностями и ей предстоят радикальные перемены, то сущест-
вует серьезная опасность, что люди не смогут как следует понять: “что
они делают”, “почему они делают это”, “могут ли они делать что-ни-
будь другое”. Как правило, совет директоров поздно понимает, что до-
ла плохи, но если ничего не делать, само существование компании мо-
жет оказаться под угрозой. Обычно в такой ситуации компания
расстается с исполнительным директором и руководство надеется,
что его последователь сможет изменить ситуацию, но если проблемы,
14
стоящие перед компанией, достаточно серьезны и глубоки, то измене-
ний на уровне управленческого персонала будет недостаточно.

В качестве примера рассмотрим состояние дел на фирме 1ВМ в
1993 г. Одна из крупнейших компаний мира была потрясена до осно-
вания, и никто не знал, чем это обернется для нее в будущем и как 1ВМ
будет выглядеть, когда все успокоится. Более десяти лет назад для
большинства специалистов стала очевидной ведущая роль програм-
много обеспечения, а не оборудования. В1ВМ не захотели признавать
этот факт, придерживаясь своей старой стратегии. Судя по всему, если
бы фирма изменила курс лет десять назад, то о кризисе 1993 г. не было
бы и речи. А ведь в кризисной ситуации, как правило, не остается ни-
чего другого, как надеяться на везение. Уже ничего нельзя делать сис-
тематически и приходится перестраиваться на ходу — проводить ре-
инжиниринг на ощупь.

Так не должно быть. Работая более систематично с хорошими мо-
делями бизнеса, можно гарантировать, что ваша компания постижима
сверху донизу, по всей структуре. Можно описать компанию, разви-
вать новые мысли и идеи, сравнить их возможные последствия с тем,
что есть в настоящий момент, разработать сценарии воздействия на
компанию со стороны внешнего мира: заказчиков, конкурентов, поль-
зователей продукции и т.д. 1ВМ должна была моделировать различ-
ные сценарии события и исследовать возможные результаты. Сцена-
рии могли показать, что персональные компьютеры становятся все
мощнее, потребность в мэйнфреймах существенно уменьшается, рас-
тет популярность систем “клиент-сервер” (которые на самом деле бы-
ли известны еще в начале 80-х гг.), требуются открытые решения и
переносимое программное обеспечение и так далее. Оценка долговре-
менных перспектив могла бы помочь фирме вовремя изменить курс и
во всеоружии встретить наступающие перемены.

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

Требования к модели компании

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

1.1.1 | Клиенты и партнеры

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

1.1.2

Исполнительный
управленческий аппарат

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

1.1.3	Команда по реинжинирингу

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

1.	Визуализацию образа будущей компании и окружающего ее
мира.

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

2.	Описание альтернативных вариантов проекта выбора архитек-
туры основного процесса компании.

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

3.	Описание продукции компании в контексте того, как, когда и в
ходе какого процесса она вырабатывается.

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

4.	Адаптацию выбранного архитектурного решения к существую-
щей структуре компании.

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

5.	Описание реализации конечного проекта с учетом как человече-
ских, так и технических ресурсов.

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

1.1.4	Владелец процесса

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

1.1.5	| Владелец ресурса

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

Структурный анализ
средствами ЮЕЕ-моделирования

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

Описание действий и бизнес-процессов в виде текста обычно по-

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

Модели действий и бизнес-процессов (или просто моделирование
бизнес-процессов) позволяют выделять и организовывать информа-

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

Модель деятельности (или функ-
циональная модель) рассматривает
систему как набор действий, в кото-
ром каждое действие преобразует не-
который объект или набор объектов.
Функциональные модели выделяют
действия посредством представле-
ния в виде специального элемента —
блока (рис. 1.3). Блоки — это основ-
2*

Рис. 1.3. Функциональный блок
Методология

Начисления в

Данные_____________

о поступлениях	*

Данные_____________

о налогоплательщиках"

Отсрочки

Работа'
отдела учета
и
отчетности

_________Карточки
лицевых счетов

Прочие документы

Отчетность

Запросы
налогоплательщиков

Запросы

на формирование
сведений

Рис. 1.4. Модифицированный функциональный блок

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

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

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

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

Функциональный блок, изображенный на рис. 1.4, отображает
границы моделирования системы. Если рассмотреть его подробнее,
как бы заглянув внутрь него, можно выделить “детские” блоки, кото-
рые, в свою очередь, могут декомпозироваться. Сокращенный формат
представления иерархии приведен ниже (с. 21).
Планирование работы ателье
по пошиву верхней одежды

Спланировать закупки ткани и
необходимых аксессуаров
Составить расписание работы
портных

Утилизировать или распродать
невостребованную продукцию

Выполнение заказа по пошиву

Принять заказ

Разработать выкройки

Произвести пошив по выкройкам

Провести первую примерку

Подогнать изделие по результатам
примерки

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

1.3.

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

В этой книге будут рассмотрены три технологии моделирования:
метод функционального моделирования ГОЕГО, метод описания биз-
нес-процессов ЮЕГЗ и метод построения диаграмм потоков данных
(ОРО). Все описанные подходы входят в семейство стандартов ГОЕР
(1п1е§га1ес1 ОЕРтйюп), полный перечень и назначение которых приве-
дены в приложении.

Своим появлением семейство стандартов ГОЕР во многом обязано
появившейся в 80-х гг. технологии автоматизированной поддержки
разработки информационных систем САЗЕ (СотриТег АШед Зойхуаге
Еп§теегт&). До настоящего времени эта технология с успехом приме-
няется при разработке разнообразного программного обеспечения.
Однако в последнее время САЗЕ-технологии приобретают все боль-
шее распространение для моделирования и анализа деятельности
предприятий, предоставляя богатый набор возможностей для опти-
мизации или, в терминах САЗЕ, реинжиниринга технологических
процедур, выполняемых этими предприятиями — бизнес-процессов.

ГОЕГО, ранее известный как технология структурированного ана-
лиза и разработки (ЗйпсШгеб Апа1у§18 апй Ое§1§п ТесЪшцие — ЗАОТ),
был разработан компанией ЗоЕГесй, 1пс. в конце 60-х гг. как набор ре-
комендаций по построению сложных систем, которые предполагали
взаимодействие механизмов и обслуживающего персонала. Значи-
тельная часть ЗАОТ была принята ВВС США как часть их программы
интегрированной компьютерной поддержки производства (1п1е§га1сс!
СотрШег-АМеб МапиГасШпп§ — 1САМ) в конце 70-х гг. Эта техноло-
гия, переименованная в ГОЕРО, довольно быстро стала стандартом
технологии моделирования деятельности в министерстве обороны
США.

В 1993 г. группа пользователей ГОЕР (ГОЕР Изегз Огоир, в настоя-
щее время 8ос1е1у оР Еп1егрп8е Еп§шеепп§ — 8ЕЕ), совместно с На-
циональным институтом стандартов и технологии (Ыабопа! 1п$йШе
оР 81апс1агс18 апб ТесЬпо1о§у — М8Т) предприняли попытку создания
документированного стандарта для ГОЕРО, который мог бы использо-
ваться как военными, так и гражданскими департаментами правитель-
ства США. Этот стандарт был опубликован как федеральный стандарт
обработки информации (Рес1ега1 Гп&ппабоп Ргосе88ш§ 81апс1агс1 —
Р1Р8).

Несколько независимо, но с использованием аналогичных подхо-
дов технология ЭРЭ (Оа1а Р1оау В1а§гаш8 — диаграммы потоков
данных) завоевала популярность для структурной разработки (а впо-
следствии и структурного анализа) проектов построения информаци-
онных систем. Диаграммы потоков данных во многом аналогичны
моделям ГОЕРО и могут быть использованы при проектировании ин-
формационных систем, например, после разработки моделей анализа
ГОЕРО.

Стандарт ГОЕРЗ был специально разработан для закрытого проек-
та ВВС США. Это технология получения описания деталей процесса
от экспертов в предметной области и разработки таких моделей про-
цессов, в которых важно понять последовательность выполнения
действий и взаимозависимости между ними. Хотя ГОЕРЗ и не достиг
статуса федерального стандарта США, эта технология приобрела ши-
рокое распространение среди системных аналитиков как дополнение
к методу функционального моделирования ГОЕРО.

1.4 Методология 8А0Т

*

Подход 8АВТ относится к классу формальных методов, исполь-
зуемых при анализе и разработке систем. Несмотря на то что вполне
допустима независимая разработка функциональных моделей,
22
методология 8АПТ предполагает ведение структурированного проек-
та анализа, в процессе которого происходит их создание. В дополне-
ние к функциональному моделированию 8АВТ структурный анализ
предполагает построение информационных моделей данных и диа-
грамм состояний (81а1е-Тгапз111оп В1а§гатз — 8ТВ), которые модели-
руют поведение системы во времени.

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

Часто разработка моделей применяется для документирования
ситуации, сложившейся к определенному моменту (модели “как
есть” — «а818»). Впоследствии они применяются при создании новых
моделей функционирования системы (модели “как должно быть” —
«1о Ье»), а также для проверки моделей «1о Ье», с тем чтобы удостове-
риться, что предлагаемые изменения действительно повлекут улуч-
шение функционирования системы.

В дополнение к алгоритмизации процесса построения предлагае-
мой системы модели «1о Ье» используются для планирования загрузки
частей системы; калькуляции бюджета и распределения ресурсов; при
построении плана реорганизации системы, определяющего действия
по переводу системы из состояния «а8 18» в состояние «1о Ье».

Преимущества, получаемые от разработки моделей «аз 18», долж-
ны быть сопоставлены с затратами средств и времени, которые для
этого необходимы. В литературе без труда можно найти многочислен-
ные примеры систем, изначально построенных для решения несоот-
ветствующих их истинному назначению задач. «Аз 1з»-моделирова-
ние позволяет обойти подобные трудности. С другой стороны, если
имеется определенный уровень понимания задачи в целом (как это
часто случается при разработке информационных систем), затраты
средств на разработку «аз 1з»-моделей могут быть неоправданными.
1.5

Применение методов ЮЕЕ
для моделирования
поведения компаний

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

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

В целом корпоративная стратегия охватывает четыре основные
области:

•	сегменты рынка, которые компания намеревается занять;

•	продукты и услуги, которые компания намеревается предложить
на выбранных сегментах рынка;

•	каналы дистрибуции и маркетинга, которые компания будет ис-
пользовать для освоения данных сегментов рынка;

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

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

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

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

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

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

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

Если компания не занимается постоянным пересмотром и мо-
дификацией своей конкурентной стратегии, она может начать те-
рять позиции на рынке. Подобная ситуация сложилась в конце
80-х гг. во многих американских корпорациях, когда специалисты по
менеджменту Майкл Хаммер (М1сЬае1 Наттег) и Джеймс Чемпи
(1ате§ Сйатру) разъяснили необходимость отказа от устаревших пра-
вил ведения бизнеса и разработки новых. Реинжиниринг биз-
нес-процессов — процесс разработки и применения стратегии, при
котором взамен устаревшей существующей стратегии ведения бизне-
са разрабатывается новая с использованием описанных выше методов
моделирования.

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

•	несоответствие обозначенным требованиям к системе;

•	неадекватное или некорректное проектирование системы;

•	неадекватная производительность системы;

•	неправильная разработка интерфейса “человек — система”.

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

Выводы. Появившись в начале 80-х гг. как технология под-
держки разработки информационных систем, методология САЗЕ при-
меняется в настоящее время не только в программировании, но и как
средство описания деятельности различных организаций. Удобные
средства визуального представления информации, описанные в стан-
дартах семейства ШЕГ, могут применяться как для описания деятель-
ности произвольной компании, так и для проведения реинжиниринга
бизнес-процессов — оптимизации ее функционирования на рынке.
Всего принято более десятка стандартов ШЕГ, каждый из которых на-
шел свое применение в различных аспектах моделирования.
МЕТОДОЛОГИЯ ОПИСАНИЯ
БИЗНЕС-ПРОЦЕССОВ ЮЕЕЗ

ГЛАВА

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

ГОЕРЗ является технологией, хорошо приспособленной для
сбора данных, требующихся для проведения структурного анализа
системы.

В отличие от большинства технологий моделирования бизнес-
процессов, ГОЕРЗ не имеет жестких синтаксических или семантиче-
ских ограничений, делающих неудобным описание неполных или
нецелостных систем. Кроме того, автор модели (системный аналитик)
избавлен от необходимости смешивать свои собственные предпо-
ложения о функционировании системы с экспертными утвержде-
ниями в целях заполнения пробелов в описании предметной области.
На рис. 2.1 изображен пример описания процесса с использованием
методологии ГОЕРЗ.

ГОЕРЗ также может быть использован как метод проектирования
бизнес-процессов. ГОЕРЗ-моделирование органично дополняет тра-
диционное моделирование с использованием стандарта ГОЕРО. В на-
стоящее время оно получает все большее распространение как вполне
жизнеспособный путь построения моделей проектируемых систем
для дальнейшего анализа имитационными методами. Имитационное
тестирование часто используют для оценки эксплуатационных ка-
честв разрабатываемой системы. Более подробно методы имитацион-
ного анализа будут рассмотрены ниже.
00

Рис. 2.1. Описание процесса в методологии ПЭЕГЗ
2.1

Синтаксис и семантика
моделей ЮЕРЗ

2.1.1	Модели ЮЕЕЗ

Основой модели ГОЕРЗ служит так называемый сценарий биз-
пес-процесса, который выделяет последовательность действий или
подпроцессов анализируемой системы. Поскольку сценарий опреде-
ляет назначение и границы модели, довольно важным является под-
бор подходящего наименования для обозначения действий. Для под-
бора необходимого имени применяются стандартные рекомендации
по предпочтительному использованию глаголов и отглагольных су-
ществительных, например «обработать заказ клиента» или «приме-
нить новый дизайн».

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

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

2.1.2	Диаграммы

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

Аналогично другим технологиям моделирования действие, или в
терминах ГОЕРЗ «единица работы» (Ипй оГАУогк — ИОАУ), — другой
важный компонент модели. Диаграммы ГОЕРЗ отображают действие
в виде прямоугольника. Как уже отмечалось, действия именуются с
использованием глаголов или отглагольных существительных, каж-
дому из действий присваивается уникальный идентификационный
номер. Этот номер не используется вновь даже в том случае, если в
процессе построения модели действие удаляется. В диаграммах
ГОЕРЗ номер действия обычно предваряется номером его родителя
(рис. 2.2)

Название действия

заказ клиента

1

Номер действия

Номер родительского действия

Рис. 2.2. Изображение и нумерация действия в диаграмме ГОЕРЗ

2.1.4	| Связи

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

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

Изобра- жение	Название	Назначение
	►	Временнбе предшест- вование (Тетрога1 рге- себепсе)	Исходное действие должно завершить- ся, прежде чем конечное действие смо- жет начаться
	Объектный поток (ОЪ]’ес1 Доху)	Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться, прежде чем конечное действие сможет начаться
— —• —►	Нечеткое отношение (КеШюпзЫр)	Вид взаимодействия между исходным и конечным действиями задается анали- тиком отдельно для каждого случая ис- пользования такого отношения

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

Рис. 2.3. Связь типа «временное предшествование»
между действиями 1.1 и 1.2

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

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

1,5-секундная задержка
для предотвращения перегрузки
электрической цепи

Рис. 2.5. Связь типа «нечеткое отношение»

Наиболее часто нечеткие отношения используются для описания
специальных случаев связей предшествования, например для описа-
ния альтернативных вариантов временндго предшествования. На
рис. 2.6 вертикальные линии показывают начало и окончание дейст-
вий 1.1 и 1.2, имеющих предшественную связь. В соответствии с по-
рядком действий, показанным на рис. 2.3, внесение исправлений в ра-
боту начинается после принятия всех замечаний от рецензентов.
32
Начало А1.1

Время

Окончание А1.1

Начало А1.2	Окончание А1.2

Рис. 2.6. Временная шкала выполнения действия для рис. 2.3

Связь нечеткого отношения, альтернативная предшественной свя-
зи на рис. 2.3, представлена на рис. 2.7. В этом примере внесение
исправлений начинается по мере получения замечаний от рецензен-
тов, т.е. до непосредственного окончания действия по принятию заме-
чаний.

• Рис. 2.7. Альтернативная связь предшествования

На рис. 2.8 приведена соответствующая этой ситуации временная
шкала.

Время

Окончание А1.2

Рис. 2.8. Альтернативная временн&я шкала

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

Время

Рис. 2.9. Вариант альтернативной временной шкалы

3'1500

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

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

2.1.5	Соединения

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

•	разворачивающие соединения используются для разбиения пото-

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

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

В табл. 2.2 объединены три типа соединений.

Таблица 2.2

Графическое обозначение	Название	Вид	Правила инициации
&	Соединение «и»	Разворачи- вающее	Каждое конечное действие обяза- тельно инициируется
		Сворачи- вающее	Каждое исходное действие обяза- тельно должно завершиться
X	Соединение «эксклюзив- ное “или”»	Разворачи- вающее	Одно и только одно конечное дей- ствие инициируется
		Сворачи- вающее	Одно и только одно исходное дей- ствие должно завершиться
Продолжение

Графическое обозначение	Название	Вид	Правила инициации
О	Соединение «или»	Развора- чивающее	Одно или несколько конечных действий инициируются
		Сворачи- вающее	Одно или несколько исходных действий должны завершиться

Примеры разворачивающих и сворачивающих соединений приве-
дены на рис. 2.10.

Рис. 2.10. Два вида соединений

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

Рис. 2.11. «И»-соединения

3*

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

Соединение «эксклюзивное “или ”». Вне зависимости от количест-
ва действий, связанных со сворачивающим или разворачивающим со-
единением «эксклюзивное «или», инициировано будет только одно из
них, и поэтому только оно будет завершено перед тем, как любое дей-
ствие, следующее за сворачивающим соединением «эксклюзивное
«или», сможет начаться. Если правила активации соединения извест-
ны, они обязательно должны быть документированы либо в его описа-
нии, либо пометкой стрелок, исходящих из разворачивающего соеди-
нения, как показано на рис. 2.12.

На рис. 2.12 соединение «эксклюзивное «или» используется для
отображения того факта, что студент не может одновременно быть на-
правлен на лекции по двум разным курсам.

Рис. 2.12. Соединение «эксклюзивное ”или”»

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

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

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

Таблица 2.3

Графическое обозначение			Тип	Вид	Правила инициации
	&		Соединение «и»	Разворачи- вающее	Все действия начнутся одно- временно
				Сворачи- вающее	Все действия закончатся одно- временно
	О		Соединение «или»	Разворачи- вающее	Может быть, несколько дейст- вий начнутся одновременно
				Сворачи- вающее	Может быть, несколько дейст- вий закончатся одновременно
	X		Соединение «эксклюзивное «или»	Разворачи- вающее	Одновременное начало дейст- вий невозможно
				Сворачи- вающее	Одновременное окончание дей- ствий невозможно
Во многих спортивных состязаниях выстрел стартового пистоле-
та, запуск секундомера и начало состязания должны произойти одно-
временно. В противном случае состязание будет нечестным.

На рис. 2.14 представлена модель этого примера, построенная с
использованием синхронного соединения.

Рис. 2.14. Синхронное соединение

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

Парность соединений. Все соединения на диаграммах должны
быть парными, из чего следует, что любое разворачивающее соеди-
нение имеет парное себе сворачивающее. Однако типы соединений
не обязательно должны совпадать. На рис. 2.15 разворачивающее
«и»-соединение имеет парное сворачивающее «или»-соединение.
Интерпретация соединения Л аналогична случаю, показанному на
рис. 2.11. Соединение 12 интерпретируется следующим образом: по-
сле включения пожарной сигнализации и/или вызова пожарных,
и/или начала тушения производится запись в журнал.

Комбинации соединений. Соединения могут комбинироваться для
создания более сложных ветвлений (рис. 2.16). Комбинации соедине-
ний следует использовать с осторожностью, поскольку перегру-
женные ветвлением диаграммы могут оказаться сложными для вос-
приятия.
38
Рис. 2.15. Пример комбинации двух типов соединений

Рис. 2.16. Диаграмма ГОЕРЗ с комбинацией соединений

2.1.6	Указатели

Указатели — это специальные символы, которые ссылаются на
другие разделы описания процесса. Они используются при построе-
нии диаграммы для привлечения внимания пользователя к каким-ли-
бо важным аспектам модели.

Указатель изображается на диаграмме в виде прямоугольника, по-
хожего на изображение действия. Имя указателя обычно включает его
тип (например, ОБЪЕКТ, ИОВ и т.п.) и идентификатор (табл. 2.4). На
рис. 2.17 показан указатель типа ОБЪЕКТ.
Таблица 2.4

Тип указателя	Назначение
ОБЪЕКТ (ОВЛЗСТ)	Для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект
ССЫЛКА (СОТО)	Для реализации цикличности выполнения действий. Ука- затель ССЫЛКА может относиться и к соединению
ЕДИНИЦА ДЕЙ- СТВИЯ (Ипй оГ Вейауюг — ИОВ)	Для многократного отображения на диаграмме одного и того же действия. Например, если действие «Подсчет наличных» выполняется несколько раз, в первый раз оно создается как действие, а последующие его появления на диаграмме оформляются указателями НОВ
ЗАМЕТКА (ИОТЕ)	Для документирования любой важной информации обще- го характера, относящейся к изображенному на диаграм- мах. В этом смысле ССЫЛКА служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах
УТОЧНЕНИЕ (Е1а- Ьогайоп — ЕЬАВ)	Для уточнения или более подробного описания изобра- женного на диаграмме. Указатель УТОЧНЕНИЕ обычно используется для описания логики ветвления у соеди- нений

На рис. 2.18 показан пример отображения важного для данной мо-
дели отношения между действием и объектом.

Провести
посадку

Объект/Пилот

Рис. 2.17. Указатель
ОБЪЕКТ

1.1

Объект/Пилот

Рис. 2.18. Указатель
ОБЪЕКТ ссылается
на действие

2.1.7	Декомпозиция действий

Действия в ГОЕГЗ могут быть декомпозированы или разложены на
составляющие для более детального анализа. Метод ГОЕГЗ позволяет
декомпозировать действие несколько раз, что обеспечивает докумен-
тирование альтернативных потоков процесса в одной модели.
Для корректной идентификации действий в модели с множествен-
ными декомпозициями схема нумерации действий расширяется и
наряду с номерами действия и его родителя включает в себя порядко-
вый номер декомпозиции. Например, в номере действия 1.2.5:1 — но-
мер родительского действия, 2 — номер декомпозиции, 5 — номер
действия.

2.2

Требования ЮЕЕЗ
к описанию бизнес-процессов

В этом разделе мы рассмотрим построение ШЕГЗ-диаграммы на
основании выраженного в текстовом виде описания процесса. Пред-
полагается, что в построении диаграммы принимают участие ее автор
(в основном как системный аналитик) и один или несколько экспертов
предметной области, представляющие описание процесса.

2.2.1

Определение сценария, границ
моделирования, точки зрения

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

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

2.2.2	| Определение действий и объектов

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

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

Поскольку модели ГОЕГЗ могут одновременно разрабатываться
несколькими командами, ГОЕЕЗ поддерживает простую схему резерв
вирования номеров действий в модели. Каждому аналитику выделяет-
ся уникальный диапазон номеров действий, что обеспечивает их неза-
висимость друг от друга. В табл. 2.5 номера действий выделяются
каждому аналитику большими блоками. В этом примере аналитик 1
полностью использовал данный ему вначале диапазон номеров и до-
полнительно получил второй.

Таблица 2.5

Аналитик	Диапазон номеров ГОЕЕЗ
1	1-99
2	100-199
3	200-299
1	300-399

2.2.3	Последовательность и параллельность

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

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

ГЛАВА

МЕТОДОЛОГИЯ
ФУНКЦИОНАЛЬНОГО
МОДЕЛИРОВАНИЯ ЮЕЕО

Методология функционального моделирования ГОЕРО — это тех-
нология описания системы в целом как множества взаимозависимых
действий или функций. Важно отметить функциональную направлен-
ность: ГОЕРО-функции системы исследуются независимо от объектов,
которые обеспечивают их выполнение. “Функциональная” точка зре-
ния позволяет четко отделить аспекты назначения системы от аспек-
тов ее физической реализации. На рис. 3.1 приведен пример типовой
диаграммы ГОЕРО.

Рис. 3.1. Пример диаграммы ГОЕРО

Наиболее часто ГОЕРО применяется как технология исследования
и проектирования систем на логическом уровне. По этой причине
ГОЕРО, как правило, используется на ранних этапах разработки проек-
та, до ГОЕРЗ-моделирования, для сбора данных и моделирования про-
цесса “как есть”. Результаты ГОЕРО-анализа могут применяться при
проведении проектирования с использованием моделей ГОЕРЗ и диа-
грамм потоков данных.
3.1

Синтаксис и семантика
моделей ЮЕЕО

3.1.1	| Модели ЮЕЕО

ГОЕРО сочетает в себе небольшую по объему графическую нота-
цию (она содержит только два обозначения: блоки и стрелки) со стро-
гими и четко определенными рекомендациями, предназначенными
для построения качественной и понятной модели системы.

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

Первый шаг при построении модели ГОЕГО заключается в опреде-
лении назначения модели — набора вопросов, на которые должна от-
вечать модель. Набор вопросов можно сравнить с предисловием, в ко-
тором раскрывается назначение книги.

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

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

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

3.1.2	Действия

Сверка
документов
1

Рис. 3.2. Функциональный
блок ГОЕРО

Действие, обычно в ГОЕРО называемое функцией, обрабатывает
или переводит входные параметры (сырье, информацию и т.п.) в вы-
ходные. Поскольку модели ГОЕРО моделируют систему как множест-
во иерархических (вложенных) функций, в первую очередь должна
быть определена функция, описывающая систему в целом — кон-
текстная функция. Функции изображаются на диаграммах как по-
именованные прямоугольники или функциональные блоки. Имена
функций в ГОЕРО подбираются по сходным правилам наименования
действий в ГОЕРЗ — с использованием
глаголов или отглагольных существи-
тельных. Важно подбирать имена так,
чтобы они отражали систему с точки зре-
ния, выбранной для моделирования.

Пример функционального блока при-
веден на рис. 3.2.

Выше мы определяли ГОЕРО-модели
как иерархическое множество вложен-
ных блоков. Любой блок может быть декомпозирован на состав-
ляющие его блоки. Декомпозицию часто ассоциируют с моделирова-
нием “сверху вниз”, однако это не совсем верно. Функциональную
декомпозицию корректнее определять как моделирование “снаружи
внутрь”, при котором мы рассматриваем систему наподобие лукови-
цы, с которой последовательно снимаются слои.

3.1.3	| Границы и связи

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

В ГОЕРО также моделируются управление и механизмы исполне-
ния. . Под управлением понимаются объекты, воздействующие на
способ, которым блок преобразует вход в выход. Механизм исполне-
ния — объекты, которые непосредственно выполняют преобразовав
ние входа в выход, но остаются неизменными.
Для типизации категорий информации на ГОЕРО-диаграммах
используется аббревиатура 1СОМ, означающая четыре возможных
типа стрелок:

I (1прЩ) — вход — то, что потребляется в ходе выполнения
процесса;

С (Соп1то1) — управление — ограничения и инструкции, влияю-
щие на ход выполнения процесса;

О (ОиТрЩ) — выход — то, что является результатом выполнения
процесса;

М (Месйатзш) — исполняющий механизм — то, что использует-
ся для выполнения процесса, но остается неизменным.

На рис. 3.3 представлены четыре возможных типа стрелок в
11)ЕР0, каждый из которых соединяется с определенной стороной
функционального блока.

Рис. 3.3. Каждый тип стрелки соединяется с определенной стороной
функционального блока

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

Стрелки входа. Вход представляет собой сырье или информа-
цию, потребляемую или преобразуемую функциональным блоком для
производства выхода. Стрелки входа всегда направлены в левую сто-
рону прямоугольника, обозначающего в ГОЕРО функциональный
блок. Наличие входных стрелок на диаграмме не является обязатель-
ным, так как возможно, что некоторые блоки ничего не преобразуют и
не изменяют. Примером блока, не имеющего входа, может служить
“принятие решения руководством”, где анализируется несколько фак-
торов, но ни один из них непосредственно не преобразуется и не по-
требляется в результате принятия какого-либо решения.

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

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

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

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

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

Стрелки механизма исполнения. Механизмы являются ресур-
сом, который непосредственно исполняет моделируемое действие. С
помощью механизмов исполнения могут моделироваться: ключевой
персонал, техника и/или оборудование. Стрелки механизма исподь
нения могут отсутствовать, в случае если оказывается, что они не яв-
ляются необходимыми для достижения поставленной цели модели-
рования.
Комбинированные стрелки, В ГОЕРО существует пять основных
иидов комбинированных стрелок: выход — вход, выход — управле-
ние, выход — механизм исполнения, выход — обратная связь на
управление и выход — обратная связь на вход.

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

Рис. 3.4. Комбинация стрелок выход — вход

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

Рис. 3.5. Комбинированная стрелка выход — управление

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

Обратные связи на вход и на управление применяются в случаях,
когда зависимые блоки формируют обратные связи для управляющих
ими блоков. На рис. 3.7 получаемая от брокеров информация о теку-
4-1500	49
Рис. 3.6. Комбинированная стрелка выход — механизм исполнения

Рис. 3.7. Комбинированная стрелка выход — обратная связь на управление

щих биржевых курсах применяется для корректировки стратегии иг-
ры на бирже.

Стрелка выход — обратная связь на вход обычно применяется для
описания циклов повторной обработки чего-либо (рис. 3.8). Кроме то-
го, связи выход — обратная связь на вход могут применяться в случае,
если бракованная продукция может заново использоваться в качестве
сырья, как это происходит, например, в процессе производства окон-
ного стекла, когда разбитое стекло перемалывается и переплавляется
заново вместе с исходным сырьем.

Рис. 3.8. Комбинированная стрелка выход — обратная связь на вход
Разъединение и соединение стрелок. Выход функционального
6пока может использоваться в нескольких других блоках. Фактически
чуть ли не главная ценность ГОЕРО заключается в том, что эта методо-
1101 ия помогает выявить взаимозависимости между блоками системы.
(’оответственно ГОЕРО предусматривает как разъединение, так и со-
единение стрелок на диаграмме. Разъединенные на несколько частей
стрелки могут иметь наименования, отличающиеся от наименования
исходной стрелки. Исходная и разъединенные (или объединенные)
стрелки в совокупности называются связанными. Такая техника
обычно применяется для того, чтобы отразить использование в про-
цессе только части сырья или информации, обозначаемой исходной
стрелкой (рис. 3.9). Аналогичный подход применяется по отношению
к объединенным стрелкам.

Рис. 3.9. Разъединенная на две части и переименованная стрелка

3.1.4 Туннели

Понятие связанных стрелок используется для управления уров-
нем детализации диаграмм. Если одна из стрелок диаграммы отсутст-
вует на родительской диаграмме (например, ввиду своей несущест-
венности для родительского уровня) и не связана с другими стрелками
гой же диаграммы, точка входа или выхода этой стрелки на диаграмме
обозначается туннелем. На рис. 3.10, например, стрелка “корпоратив-
ная информационная система” — важный механизм исполнения для
данной диаграммы, но, возможно, она более нигде не применяется
в модели. Туннель в данном случае используется как альтернатива
4*	51
Рис. 3.10. Пример применения туннеля

загромождению родительских диаграмм стрелками, несущественны-
ми для их уровня.

Кроме того, туннели используются для отражения ситуации,
когда стрелка, присутствующая на родительской диаграмме, отсут-
ствует в диаграмме декомпозиции соответствующего блока. На
рис. 3.11 туннель у стрелки “модель производственного отдела” озна-
чает, что на диаграмме декомпозиции производственного отдела
отсутствует стрелка механизма управления с соответствующим на-
именованием.

Рис. 3.11. Другой пример применения туннеля
3.2 Построение моделей ЮЕЕО

В этом разделе мы рассмотрим методику построения ГОЕР0-моде-
лей более подробно.

3.2.1	Диаграммы

На рис. 3.12 типовая ГОЕРО-диаграмма показана вместе с находя-
щейся на ее полях служебной информацией, которая состоит из хоро-
ню выделенных верхнего и нижнего колонтитулов (заголовка и “под-
вала”). Элементы заголовка используются для отслеживания процесса
создания модели. Элементы “подвала” отображают наименование мо-
дели, к которой относится диаграмма, и показывают ее расположение
относительно других диаграмм модели.

ОЗЕР АТ: АКТНОК: Семенов Илья Олегович
РЯОЛЕСТ: Отдел учета и отчетности

МОТЕЗ: 1 2345678910

Данные о
поступлениях

Н.ачислзния.....

Отсрочки

Данные о налого-
плательщиках

РАТЕ: 15.03.97 |ИуУОЯК1НВ

КЕУ: 17.12.97

Обработка
данных
о поступлениях

Поступления

ОВАЛ_______

КЕСОММЕКРЕР

РЦВЫСАТЮН

Методо-
логия

Ведение
лицевых карточек
налогоплательщиков —
юридических лиц
2

СОМТЕХТ:

А-0

Карточки______

лицевых счетов

Прочие
документы

Подготовка
отчетности,
анализ и
прогнозирование
з

Отчет-
ность

.ВЕАОЕВ____ВАШ

Запросы
налого-
плательщиков

Запросы
на формирование
сведений

МСЮЕ: до

Т1Т1Е:

Отдел учета и отчетности

МОМВЕК:

Рис. 3.12. ГОЕРО-диаграмма со служебной информацией на полях
Все элементы заголовка диаграммы приведены в табл. 3.1.

Таблица 3.1

Поле	Назначение
И8еа АТ	Используется для отражения внешних ссылок на дан- ную диаграмму (заполняется на печатном документе вручную)
АиШог, ба1е, рго)ес1	Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась
Ъто1е§ 1 ... 10	При ручном редактировании диаграмм пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное исправление
	Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реали- зации формального процесса итерации пересмотра и утверждения
АУогкт§	Новая диаграмма, глобальные изменения или новый ав- тор для существующей диаграммы
Вгай	Диаграмма достигла некоторого приемлемого для чита- телей уровня и готова для представления на утверждение
Кесоттепбеб	Диаграмма одобрена и утверждена. Какие-либо измене- ния не предвидятся
РиЬНсабоп	Диаграмма готова для окончательной печати и публи- кации
Кеабег	ФИО читателя
Ва1е	Дата знакомства читателя с диаграммой
СогДех!	Схематическое изображение функциональных блоков на родительской диаграмме, на котором подсвечен деком- позируемый данной диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в по- ле помещается контекст ТОР

Все элементы “подвала” диаграммы представлены в табл. 3.2.

Таблица 3.2

Поле	Назначение
Мобе	Номер диаграммы, совпадающий с номером роди- тельского функционального блока
Тй1е	Имя родительского функционального блока
Продолжение

Поле	Назначение
ЫитЬег (С-МшпЬег)	Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия диаграммы будет иметь новое значение в этом поле. Как правило, С-МшпЬег состоит из инициалов автора и последовательного уникального идентификатора, например 800005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую, номер заменяемой диаграммы может быть заключен в скобки - 8П0005 (800004). Это обеспечивает хранение истории изменений всех диаграмм модели

3.2.2 Цикл эксперт — аналитик

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

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

Формально механизм рецензирования и модификации диаграмм
поддерживается полями 81аШ8 и нумерацией диаграмм, контроль ис-
тории изменений — полем Иек! (см. табл. 3.1).

3.2.3 | Построение моделей

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

•	Почему моделируется данный процесс?

•	Что выявит данная модель?

•	Как ознакомившиеся с этой моделью смогут ее применить?

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

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

•	Каковы задачи клерка?

•	Кто контролирует работу?

•	Какая технология нужна для выполнения каждого шага и т.п.

3.2.4	| Точка зрения

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

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

3.2.5	Границы моделирования

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

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

Чтобы облегчить правильное определение границ моделирования
при разработке ГОЕГО-моделей, существенные усилия затрачиваются
на разработку и рецензирование контекстной диаграммы ГОЕРО
(диаграммы “самого верхнего” уровня). Иногда даже прибегают к по-
строению дополнительной диаграммы для отображения уровня более
высокого, чем контекстный для данной модели, что позволяет обозна-
чить систему, внутри которой располагается объект для моделирова-
ния. Существенные затраты на разработку контекстной диаграммы
вполне оправданы, поскольку она является своего рода “точкой отсче-
та” для остальных диаграмм модели, и вносимые в нее изменения кас-
кадом отражаются на все лежащие ниже уровни.

Когда границы моделирования понятны, также становится яс-
ным, какие объекты системы по тем или иным причинам не вошли в
модель.

3.2.6

Выбор наименования
контекстного блока

Рекомендуется следующая последовательность действий при по-
строении модели “с нуля”: формулирование цели моделирования,
выбор точки зрения, определение границ моделирования. Наименова-
ние контекстного блока — функционального блока самого высокого
уровня — обобщает определение границ моделирования.

Правила подбора имени для контекстного блока в целом не отли-
чаются от общих правил именования функциональных блоков, поэто-
му для них обычно подбирают обобщающие названия типа “Управле-
ние отделом по работе с клиентами”, “Обработка заказов” и т.п.
3.2.7

Определение стрелок
на контекстной диаграмме

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

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

Определение входов. Входы можно рассматривать как особым об-
разом преобразуемые функциональными блоками сырье или инфор-
мация для получения выхода. В производственных отраслях опреде-
лить, как входное сырье преобразуется в готовую продукцию, обычно
довольно просто. Однако при моделировании информационных пото-
ков входной поток данных может представляться не потребляемым и
не обрабатываемым вообще. Случаи, когда входящие и исходящие
стрелки называются одинаково, крайне редки и в основном указыва-
ют на бесполезность данного блока для системы в целом или на некор-
ректный выбор имени для исходящей стрелки. Решением может
служить применение более подробного описания для входящих и ис-
ходящих потоков данных. Например, вход может иметь название
“Предварительный диагноз пациента”, а выход — “Уточненный диаг-
ноз пациента”.
Определение механизмов исполнения. После создания входов и
выходов можно приступить к рассмотрению механизмов исполнения
или ресурсов, относящихся к функциональному блоку. В понятие ме-
ханизма исполнения входят персонал, оборудование, информацион-
ные системы и т.п. Например, функциональный блок “Собрать де-
таль” может потребовать использования какого-либо оборудования,
например, гаечного ключа. При приеме экзаменов на водительские
права механизмом исполнения является инспектор ГИБДД. Как пра-
вило, определить механизмы исполнения для функциональных бло-
ков довольно просто.

Определение управления. Наконец, должно быть определено
управление, контролирующее ход работы функционального блока.
Все функциональные блоки в ШЕРО должны иметь хотя бы одно
управление. В случаях когда неясно, относить ли стрелку ко входу или
к управлению, следует ее рисовать как управление. Важно помнить,
что управление можно рассматривать как особую форму входа функ-
ционального блока.

Когда контекстная диаграмма представляется завершенной, по-
пробуйте задать следующие вопросы:

•	Обобщает ли диаграмма моделируемый бизнес-процесс?

•	Согласуется ли диаграмма с границами моделирования, точкой
зрения и целью моделирования?

•	Подходит ли выбранный уровень детализации стрелок для кон-
текстного блока? (Обычно на контекстной диаграмме рекоменду-
ется рисовать не более шести стрелок каждого типа.)

3.2.8 Нумерация блоков и диаграмм

Все функциональные блоки ГОЕГО нумеруются. В номерах допус-
кается использование префиксов произвольной длины, но в подав-
ляющем большинстве моделей используется префикс А. Номер блока
проставляется за префиксом. Контекстный блок всегда имеет но-
мер АО.

Префикс повторяется для каждого блока модели. Номера исполь-
зуются для отражения уровня декомпозиции, на котором находится
блок. Блок АО декомпозируется в блоки А1, А2, АЗ и т.д.; блок А1 — в
А11, А12, А13 и т.д.; блок — А11 в А111, А112, А113 и т.д. Для каждо-
го уровня декомпозиции в конце номера добавляется одна цифра.
3.2.9

Связь между диаграммой
и ее родительским
функциональным блоком

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

При ГОЕЕО-моделировании важно иметь в виду, что граница дет-
ской диаграммы есть граница родительского функционального блока.
Это означает, что вся работа выполняется блоками самого нижнего
уровня. В отличие от иерархии, применяемой в структурном програм-
мировании, блоки верхнего уровня не являются субъектами управле-
ния для блоков нижнего уровня. Это означает, что в ГОЕРО дети — это
одни и те же объекты, что и их родители, только показанные с боль-
шей детализацией. Действия генерального директора компании на
ГОЕРО-диаграммах могут отражаться рядом с действиями простых ра-
бочих.

На концах граничных стрелок (начинающихся или заканчиваю-
щихся за пределами диаграммы) детских диаграмм помещаются коды
1СОМ, чтобы показать, где находится соответствующая стрелка на ро-
дительской диаграмме (рис, 3.13). Они нужны для проверки целостно-
сти модели и могут быть полезны, когда порядок расположения стре-
лок на детской диаграмме отличается от порядка их размещения на
родительской диаграмме. Код 1С0М состоит из латинской буквы I, С,
О или М и числа, показывающего расположение стрелки на родитель-
ской диаграмме в порядке сверху вниз или слева направо.

С1 С2

И

12

Рис. 3.13.1СОМ-коды на граничных стрелках
3.2.10

Два подхода к началу моделирования
(“в ширину” и “в глубину”)

Модели могут проектироваться как с использованием подхода
“в ширину”, когда каждая диаграмма максимально детализируется
перед своей декомпозицией, так и с подходом “в глубину”, когда сна-
чала определяется иерархия блоков, а затем создаются соединяющие
их стрелки. Естественно, возможно применение комбинации этих
подходов, причем иерархия блоков может иногда немного меняться
после того, как нарисованы стрелки. Это происходит в случае, когда
создание стрелок может изменить понимание внутренней архитекту-
ры моделируемого объекта.

3.2.11	| Когда остановиться

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

При необходимости дальнейшей детализации отдельных процес-
сов могут быть использованы диаграммы ГОЕГЗ.

3.2.12	Другие диаграммы ЮЕЕО

В дополнение к контекстным диаграммам и диаграммам декомпо-
зиции при разработке и представлении моделей могут применяться
другие виды ГОЕГО-диаграмм.

Дерево модели. Дерево модели — обзорная диаграмма, показы-
вающая структуру всей модели. На рис. 3.14 приведен фрагмент такой
диаграммы. Обычно вершина дерева соответствует контекстному
блоку, под вершиной выстраивается вся иерархия блоков модели. Од-
нако не запрещается назначать вершиной произвольный блок, поме-
Рис. 3.14. Фрагмент дерева модели

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

Презентационные диаграммы. Презентационные диаграммы
(Рог ЕхрозШоп Оп1у сйа§гат8 — РЕО сНадгатз) часто включают в мо-
дели, чтобы проиллюстрировать другие точки зрения или детали, вы-
ходящие за рамки традиционного синтаксиса ГОЕРО. Диаграммы РЕО
допускают нарушение любых правил построения диаграмм ГОЕРО в
целях выделения важных с точки зрения аналитика частей модели. Ес-
тественно, если диаграмма РЕО включена в модель исключительно
для отображения другой точки зрения на систему, она, скорее всего,
внешне будет выглядеть как обыкновенная ГОЕРО-диаграмма, удовле-
творяя всем ограничениям ГОЕРО.

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

Кроме того, встречаются следующие виды презентационных диа-
грамм:

• копия ГОЕРО-диаграммы, которая содержит все функциональные
блоки и Стрелки, относящиеся только к одному из функциональ-
ных блоков, — это позволяет отразить взаимодействие между
этим блоком и другими объектами диаграммы;
118ЕО АТ:

А1ПН0Я: Семенов Илья Олегович
РЯОЗЕСТ: Отдел учета и отчетности

ГЮТЕ8: 1 2345678910

□АТЕ: 15.03.97
НЕУ: 17.12.97

РВАЕТ..

рцвисАтюк

Методо-
логия

Начисления
Отсрочки
Поступления
Данные о налого-
плателыциках

Ведение
лицевых карточек
налогоплательщиков —
юридических лиц

2

Запросы
налого-
плательщиков

МООЕ: до

Т1Т1Е:	Ведение лицевых карточек

налогоплательщиков — ЮЛ

Карточки______

лицевых счетов

Прочие________

документы

МУМВЕЯ:

Рис. 3.15. Диаграмма РЕО для выделения
функционального блока и его стрелок

•	копия ГОЕРО-диаграммы, которая содержит все функциональные
блоки и стрелки, непосредственно относящиеся только ко входу
и/или выходу родительского блока;

•	различные точки зрения, как правило, на глубину одного уровня
декомпозиции.

Взаимосвязь моделей
ЮЕЕО и ЮЕЕЗ

Действия, выполняемые
в функциональных блоках

Как правило, при работе с пластиковой картой клиент не произво-
дит всех доступных ему при этом действий, выполняя ограниченный
набор операций. Например, при оплате покупки не производится
снятие наличных, а при проверке баланса состояние счета вообще не
изменяется. Мы можем декомпозировать функциональный блок “Об-
работка операций с пластиковыми картами”, создав дополнительные
блоки для оплаты покупок, снятия наличных, проверки баланса и т.п.
Вместо этого можно создать отдельные ГОЕГЗ-модели для каждого
из этих действий. Это, в частности, полезно, если в дальнейшем пред-
полагается заняться оцениванием соответствующих операций по тем
или иным параметрам.

Более простой альтернативой предложенным выше двум подхо-
дам может служить так называемая таблица вызовов (асЙуаНоп 1аЫе),
описывающая различные комбинации входов, выходов, управлений и
механизмов исполнения для каждого способа вызова функционально-
го блока на исполнение. Вызов — это уникальная конфигурация зна-
чений входа, управления и требований к механизмам исполнения.
Простейший пример таблицы вызовов представлен в табл. 3.3. Для
каждого вызова присваивается уникальное имя в пределах блока и
перечисляются значения различных стрелок. Комбинация значений
стрелок должна быть уникальной для каждого вызова.

Таблица 3.3

Вызов	Стрелка	Значение стрелки
Значительная сумма наличных	Наличные деньги	Более 1000 руб.
	Счетчик банкнот	Требуется 1 счетчик
Мелкая сумма наличных	Наличные деньги	Не более 1000 руб.
	Счетчик банкнот	Не требуется

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

3.3.2

Создание моделей ЮЕЕЗ
для отображения блоков ЮЕРО

Для иллюстрирования вызовов листовых функциональных блоков
ГОЕРО (т.е. блоков, не имеющих диаграмм декомпозиции) может быть
применено построение ГОЕЕЗ-моделей. Если развитие ГОЕЕО-модели
64
предполагается аналитиками именно таким способом, моделями
ЮЕРЗ должен быть тщательно документирован каждый возможный
вызов функционального блока. Соответствующие таблицы вызовов
(наподобие табл. 3.3) можно будет составить впоследствии из соот-
ветствующих диаграмм ГОЕРЗ.

Выводы. Методология функционального моделирования
ПЭЕРО — это технология описания системы в целом как множества
взаимозависимых действий или функций. ГОЕРО имеет функциональ-
ную направленность. ГОЕРО-функции системы исследуются незави-
симо от объектов, которые обеспечивают их выполнение. Одной из
основных идей ГОЕРО-моделей является построение двух видов мо-
делей: “как есть” и “как должно быть”. Это нужно при проведении
реинжиниринга бизнес-процессов организации. Кроме того, ГОЕРО
обеспечивает удобный язык обмена информацией о моделируемой
системе.

5-1500
ГЛАВА

4.1

СТРУКТУРНЫЙ АНАЛИЗ
ПОТОКОВ ДАННЫХ
(ЛАТА ЕЬОУУ 01А0КАМ8 — ОРО)

Назначение диаграмм
потоков данных

Так же, как и диаграммы ГОЕРО, диаграммы потоков данных (Ва1а
Ноду В1а§гат§ — ПРЭ) моделируют систему как набор действий, со-
единенных друг с другом стрелками. Диаграммы потоков данных мо-
гут содержать два новых типа объектов: объекты, собирающие и хра-
нящие информацию, — хранилища данных и внешние сущности —
объекты, моделирующие взаимодействие с теми частями системы
(или другими системами), которые выходят за границы моделирова-
ния (рис. 4.1).

В отличие от стрелок в ГОЕРО, которые иллюстрируют отноше-
ния, стрелки в ЭРП показывают, как объекты (включая и данные) ре-
ально перемещаются от одного действия к другому. Это представле-
ние потока обеспечивает отражение в ЭРЭ-моделях таких физических
характеристик системы, къкдвижение объектов (потоки данных), хра-
нение объектов (хранилища данных), источники и потребители объ-
ектов (внешние сущности).

Построение ВРЭ-диаграмм в основном ассоциируется с разработ-
кой программного обеспечения, поскольку нотация ЭРП изначально
была разработана для этих целей. В частности, графическое изображе-
ние объектов на ПРО-диаграммах этой главы соответствует принято-
му Крисом Гейном (СЬпз Стале), Тришем Сарсоном (Тп§Ь Загзоп) —
авторами ВРП-метода, известного как метод Гейна-Сарсона. Другой
распространенной нотацией ЭРП является так называемый метод
Йордана-Де Марко (Тоигдол-ЭеМагсо).
о\

Данные	Информация

Рис. 4.1. Пример ЭРЭ-диаграммы
4.2

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

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

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

Рис. 4.2. Контекстная ВЕР-диаграмма

4.2.1

Функциональные блоки

Функциональный блок ЭРБ моделирует некоторую функцию, ко-
торая преобразует сырье в какую-либо продукцию (или, в терминах
ШЕР, вход в выход). Хотя функциональные блоки ВРВ и изобража-
ются в виде прямоугольников с закругленными углами, они почти
68
идентичны функциональным
блокам ГОЕРО и действиям
ГОЕРЗ. Как и действия ГОЕРЗ,
функциональные блоки ВРВ
имеют входы и выходы, но не
имеют управления и механизма
исполнения, как ГОЕРО. В неко-
торых интерпретациях нотации
ОРВ Гейна-Сарсона механиз-
мы исполнения ГОЕРО моде-
лируются как ресурсы и изо-
бражаются в нижней части
прямоугольника (рис. 4.3).

Рис. 4.3. Элемент ПРО-диаграммы,
построенной в нотации
Гейна-Сарсона

4.2.2	Внешние сущности

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

1

Клиент

4.2.3	Стрелки (потоки данных)

Стрелки описывают передвижение (поток) объектов от одной час-
ти системы к другой. Поскольку все стороны обозначающего функ-
циональный блок ПЕВ прямоугольника равнозначны (в отличие от
ГОЕРО), стрелки могут начинаться и заканчиваться в любой части
блока. В ВРВ также используются двунаправленные стрелки, кото-
рые нужны для отображения взаимодействия между блоками (напри-
мер, диалога типа «приказ — результат выполнения»). На рис. 4.5 дву-
направленная стрелка обозначает взаимный обмен информацией
между департаментом маркетинга и рекламы и департаментом пла-
стиковых карт.

з

Департамент
маркетинга
и рекламы

---------------------

Ор.	о

Департамент по работе
с пластиковыми
картами

Рис. 4.5. Двунаправленный поток между блоком и внешней сущностью

4.2.4

Хранилища данных

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

нилищами данных

1	Заказы

Рис. 4.6. Обозначение
хранилища данных
на ВРВ-диаграмме

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

4.2.5 Ветвление и объединение

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

Стрелки могут соединяться между собой (объединяться) для фор-
мирования так называемых комплексных объектов. Пример такого
объединения приведен на рис. 4.8.
Рис. 4.7. Разветвление стрелки, иллюстрирующее декомпозицию данных

Рис. 4.8. Объединение потоков в один

4.3

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

4.3.1	Два подхода к построению ОЕО-моделей

Диаграммы ОЕО можно строить с использованием подхода, ана-
логичного структурному методу анализа и проектирования, приме-
няемому в ЮЕРО. Вначале строится модель физической реализации
существующей системы, которая используется пользователями в на-
стоящее время. Затем создается логическая модель для моделирова-
ния основных требований реальной системы. После этого формирует-
ся новая логическая модель для отражения основных параметров
разрабатываемой системы. И наконец, создается новая физическая
модель, реализующая логическую модель новой системы.

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

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

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

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

4.3.2	Нумерация объектов

В ПРО каждый номер функционального блока может включать в
себя префикс, номер родительской диаграммы и собственно номер
объекта (рис. 4.9). Номер объекта уникальным образом иденти-
фицирует функциональный блок на диаграмме. Номер родительской
72
диаграммы и номер объекта в
совокупности обеспечивают
уникальную идентификацию
каждого блока модели.

Уникальные номера при-
сваиваются также каждому
хранилищу данных и каждой
внешней сущности вне зави-

Преф^жс^^	Номер объекта

АЗ 7

Номер диаграммы

Рис. 4.9. Компоненты номера
функционального блока ВРВ

симости от расположения объекта на диаграмме. Каждый номер хра-
нилища данных содержит префикс Э (Эа1:а 8 Гоге) и уникальный номер
хранилища в модели (например, ВЗ).

Аналогично, номер каждой внешней сущности содержит пре-
фикс Е (Ех1ета1 епй1у) и уникальный номер сущности в модели
(например, Е5).

Выводы. Диаграммы потоков данных (ВГВ) обеспечивают
удобный способ описания передаваемой информации как между час-
тями моделируемой системы, так и между системой и внешним
миром. Это качество определяет область применения ВГВ — они ис-
пользуются для создания моделей информационного обмена органи-
зации, например модели документооборота. Кроме того, различные
вариации ВГВ широко применяются при построении корпоративных
информационных систем.
ДРУГИЕ ВОЗМОЖНОСТИ
ЮЕЕ-МОДЕЛЕЙ

ГЛАВА

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

Кроме того, на базе моделей ГОЕРЗ иногда проводят имитацион-
ное моделирование для исследования параметров системы, меняю-
щихся во времени.

5.1

Стоимостный анализ
ЮЕЕ-моделей.
Функциональное оценивание

Функциональное оценивание (Асйуйу-Ьазес! со8Йп§ — АВС) — это
технология выявления и исследования стоимости выполнения той или
иной функции (действия). Исходными данными для функционально-
го оценивания являются затраты на ресурсы (материалы, персонал
и т.д.), затем эти затраты распределяются между блоками ГОЕРЗ-мо-
дели, которые, в свою очередь, привязываются к выходам системы,
называемым, в терминологии функционального оценивания, объекта-
ми затрат. В сравнении с традиционными способами оценки затрат,
при применении которых часто недооценивается продукция, произво-
димая в незначительном объеме, и переоценивается массовый выпуск,
АВС обеспечивает более точный метод расчета стоимости производ-
ства продукции, основанный на стоимости выполнения всех техноло-
гических операций, выполняющихся при ее выпуске.

Модель функциональной оценки отражает схему функционирова-
ния компании, так как в ее основе лежит ГОЕРЗ-модель действий. По-
скольку построение полной картины затрат может оказаться неоправ-
74
данно дорогим и долгим, важно сконцентрировать внимание на
основных производственных затратах компании. Модель функцио-
нальной оценки представляется, как правило, в виде таблицы, в кото-
рой стоимость каждого ресурса или механизма исполнения записыва-
ется в разрезе выполняемых действий и получающейся в результате
продукции. Фрагмент такой модели приведен в табл. 5.1.

Таблица 5.1

Действие	Ресурсы		Прием платежа		Инкассация	
	Наимено- вание	Стоимость	Кол-во	Всего	Кол-во	Всего
Подсчет наличных	Счетчик банкнот	$10	1	$10	3	$30
	Опера- ционист	$5	1	$5	3	$15
Итого				$15		$45

Формула расчета стоимости ресурсов для выполнения того или
иного действия выглядит так:

стоимость_ресурса • количество = общие_затраты_на__ресурс

Как уже упоминалось выше, при функциональном оценивании
результирующую продукцию называют объектом затрат, а основные
организационные единицы компании, такие, например, как депар-
таменты, — центрами затрат (со§1 сеп1ег§).

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

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

В иерархических моделях ГОЕРЗ стоимости присваиваются толь-
ко для блоков, не имеющих диаграмм декомпозиции (листовых бло-
ков); стоимостью родительских блоков в этом случае предполагается
совокупная стоимость листовых блоков.
5.2

Имитационные модели

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

При использовании для имитационного моделирования моде-
лей ГОЕРЗ статистически значимые изменения ассоциируются с со-
бытиями. Фактически, имитационное моделирование производится
посредством перехода с одного события на другое с течением вре-
мени. Такой тип имитационного моделирования называется дис-
кретным имитационно-событийным моделированием {(И8сге1е ечеп1
$шш1а1юп).

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

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

Естественно, что между имитационными и ГОЕРЗ-моделями сис-
темы существует довольно тесная взаимосвязь: ГОЕРЗ-модели могут с
незначительными изменениями быть использованы в качестве скеле-
та имитационной модели, построение которой, в свою очередь, значи-
тельно улучшает понимание механизма функционирования системы в
76
целом, что может привести к изменениям в исходной модели ЮЕГЗ.
Далее приведем описание основных компонентов имитационных
моделей.

5.2.1	Источники и назначения

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

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

5.2.2	Очереди

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

Поведение очередей должно быть описано в имитационной мо-
дели. Например, очередь может функционировать как стек — послед-
нее изделие, помещенное в очередь, извлекается из нее первым. Этот
принцип широко известен под аббревиатурой ЫГО (Ьа§11п —
Ои1). Очередь может функционировать и наоборот — по принципу
НГО (Ига! 1п — Р1Г81 Ои1). Кроме того, объекты могут извлекаться из
очередей случайным образом или по какому-либо специально задан-
ному признаку.

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

5.2.3

Оборудование

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

5.2.4

Пример имитационной модели

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

•	пополнение счета клиента наличными или с использованием чека;

•	снятие денег со счета;

•	перевод средств по счетам клиента;

•	выписка дорожного чека;

•	открытие нового счета.

При пополнении счета клиента (рис. 5.1) производятся следующие
действия:

•	если пополнение счета осуществляется с помощью чека — прове-
рить чек, затем записать депонируемую сумму;
40

33	34

Рис. 5.1. Пополнение счета
•	если счет пополняется наличными — подсчитать сумму налич-
ных, записать депонируемую сумму, поместить деньги в кассу;

•	если клиенту что-либо возвращается наличными — извлечь необ-
ходимую сумму из кассы, подсчитать ее и отдать клиенту;

•	записать общую сумму возвращенных денег;

•	возвратить клиенту документы по счету.

При снятии средств со счета (рис. 5.2) выполняются следующие
действия:

•	проверка состояния счета;

•	извлечение наличных из кассы, подсчет и передача клиенту;

•	запись общей суммы, переданной клиенту.

Рис. 5.2. Снятие средств со счета

При переводе средств с одного счета на другой (рис. 5.3) произво-
дится такая последовательность действий:

•	проверка состояния счета, с которого осуществляется снятие
средств;

•	запись снимаемой суммы;

•	запись депонируемой суммы;

•	возврат документов, касающихся произведенной операции, кли-
енту.

При выписке дорожного чека (рис. 5.4) выполняются следующие
действия:

•	если производится снятие средств — проверка состояния счета и
запись снимаемой суммы;

•	если транзакция проводилась с использованием наличных — про-
верка состояния счета клиента и документов по счету, подсчет
суммы наличных;

•	распечатка и передача чека клиенту.

Рис. 5.3. Перевод средств с одного счета на другой
ОО

Рис. 5.4. Выписка дорожного чека
Как видно из рис. 5.4, имеется два основных типа транзакций, раз-
личающихся по способу оплаты клиентом выписанного дорожного
чека: он может снимать деньги со своего счета или платить наличны-
ми. Это видно из (Ж-соединений на диаграмме: клиент может платить
наличными, снимать деньги со счета или даже одновременно исполь-
зовать оба способа. В случае если для банка существуют значительг
ные различия во времени (и, возможно, стоимости) проведения этих
типов транзакций, важно отразить в имитационной модели все три
упомянутых случая. Аналогично, если разница во времени проведе-
ния транзакции для разных типов счетов существенна, это также
должно найти отражение в модели.

Заметим, что в нашем примере не моделируется открытие новых
банковских счетов. Вместо этого при необходимости мы будем ис-
пользовать некоторое математическое выражение. Важно помнить,
что не всегда необходимо моделировать все действия (напомним, что
слово “действие” здесь понимается в терминологии ГОЕГЗ) одного
уровня детализации — мы создаем модели только лишь для сущест-
венных с выбранной точки зрения частей бизнес-процесса.

Важные для нас имитационные переменные представлены в
табл. 5.2. Фактически в этой таблице перечислены механизмы испол-
нения, необходимые для выполнения описываемых нами действий.

Таблица 5.2

Наименование ресурса	Всего в наличии	Стоимость, $/мин	СВМП*	Среднее время поломки
Операционист	3	0,20	0	0
Счетчик банкнот	1	0,05	Норм(6000,25)	Норм(16,3)
*СВМП - среднее время работы между поломками.				

Функция Норм(мат. ожидание, дисперсия) — функция распреде-
ления нормального закона, известная из математической статистики.

В таблице СВМП используется для отражения ситуации, когда ре-
сурс периодически недоступен в связи с техническими проблемами.
Среднее время поломки отражает средний интервал времени, в тече-
ние которого производится ремонт вышедшего из строя ресурса. При
необходимости можно аккуратнее отразить и работу операционистов,
что может потребоваться при моделировании работы банка в течение
нескольких дней. Обычно для этого используют всевозможные та-
бель-календари, известные из законодательства о труде.
В статистике существуют специальные формулы, описывающие
вероятность наступления того или иного события. Например, сколько
в среднем клиентов придет в операционный зал банка между 10-00 и
10-30 в пятницу? Среднее значение, называемое в статистике матема-
тическим ожиданием, изображено пиком каждой из трех кривых на
рис. 5.5. Разброс получившейся при реальном наблюдении ошибки,
показывающий, насколько близки друг к другу были реально наблю-
давшиеся значения, называется дисперсией и выглядит на графике,
как “ширина” каждой из трех кривых. Существует множество других
функций распределения вероятностей, отличных от показанного на
рис. 5.5 нормального распределения, которые могут быть применены
для описания огромного набора реально возникающих ситуаций. Ес-
тественно, что графики этих функций могут существенно отличаться
от приведенных на рисунке.

Рис. 5.5. Нормальная функция распределения

Использование статистических формул — это основа имитацион-
ного моделирования. В дополнение к отображению времени выполне-
ния тех или иных действий статистические формулы также использу-
ются для отражения времени прибытия сырьевых ресурсов, а также
времени доступности механизмов исполнения. Программное обеспе-
чение, выполняющее имитационное моделирование, непрерывно про-
изводит вычисления по этим формулам для количественного опре-
деления этих параметров.
В табл. 5.3 время выполнения каждого действия представлено в
виде статистической формулы. Например, время выполнения провер-
ки документов и записи суммы депозита имеет нормальное распреде-
ление и занимает в среднем 0,5 мин. Это первый параметр функции.
Естественно, что выполнение этих действий не всегда занимает ровно
0,5 мин, это всего лишь среднее время. Вполне можно также наблю-
дать, что в редких случаях эти действия могут быть завершены, ска-
жем, за 0,4 или 0,6 мин. Мы подсчитали это с использованием второго
параметра функции — дисперсии.

Таблица 5.3

Действие	Механизм исполнения	Количество	Время
Пополнение счета:			
Проверить документы и записать депонируе- мую сумму	Операционист	1	Норм(0,5;0.1)
Подсчитать неболь- шую сумму наличных	То же	1	Норм(0,5;0.5)
Подсчитать большую сумму наличных	Операционист  Счетчик банкнот	1  1	Норм(0,1;0.5)
Поместить сумму в кассу и сделать за- пись в кассовой книге	Операционист	1	Норм(0,1;0.5)
Извлечь наличные из кассы	То же	1	Норм(0,3;0.1)
Подсчитать неболь- шую сумму воз- вращаемых наличных		1	Норм(0,5;0.5)
Подсчитать большую сумму возвращаемых наличных	Операционист  Счетчик банкнот	1  1	Норм(0,1;0.5)
Передать сумму клиенту	Операционист	1	Норм(0,3;0.1)
Записать общую сумму, переданную клиенту	То же	1	Норм(0,3;0.1)
Вернуть клиенту до- кументы по счету	55	1	Норм(0,3;0.1)
Действие	Механизм исполнения	Количество	Время
Снятие средств со счета:			
Проверить состояние счета	Операционист	1	Норм(0,5;0.3)
Извлечь наличные из кассы	То же	1	Норм(0,3;0.1)
Подсчитать неболь- шую сумму возвращаемых наличных		1	Норм(0,5;0.5)
Подсчитать большую сумму возвращаемых наличных	Операционист  Счетчик банкнот	1  1	Норм(0,1;0.5)
Передать сумму клиенту	Операционист	1	Норм(0,3;0.1)
Записать общую сумму, переданную клиенту	То же	1	Норм(0,3;0.1)
Перевод средств по счетам:			
Проверить состояние счета, с которого снимаются средства	55	1	Норм(0,5;0.3)
Записать снятую сумму		1	Норм(0,3;0.1)
Записать депони- руемую сумму		1	Норм(0,3;0.1)
Вернуть клиенту документы по счету		1	Норм(0,3;0.1)
Выписать дорожный чек:	55		
Проверить состояние счета	55	1	Норм(0,5;0.3)
Записать снятую сумму	99	1	Норм(0,3;0.1)
Проверить состояние счета клиента	55	1	Норм(0,3;0.1)
Проверить данные чека	55	1	Норм(1,0;5)
Действие	Механизм исполнения	Количество	Время
Подсчитать сумму наличных	Операционист	1	Норм(0,5;0.5)
Распечатать и пере- дать клиенту чек	То же	1	Норм(1,0;5)
Открыть новый счет	99	1	Норм(15,6)

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

Во-первых, определим норму прибытия клиентов как Норм(1,2;
0,3). Это означает, что приблизительно каждые 1,2 мин в операцион-
ный зал заходит новый клиент. Если норма прибытия клиентов изме-
няется в зависимости от времени дня, мы могли бы составить таблицу
норм прибытия, в которой перечислили нормы прибытия клиентов в
зависимости от времени.

В соответствии с табл. 5.4 50% всех транзакций — операции депо-
нирования. Половина из них — всего лишь проверки состояния счета,
30% — депонирование мелких сумм и только 20% операций депони-
рования приносят банку значительные суммы. Аналогичные значения
показывают вероятности других действий.

Таблица 5.4

Группа действий	Вероятность
Депонирование средств на счет	0,5
Проверка состояния	0,5
Депонирование мелкой суммы	0,3
Депонирование крупной суммы	0,2
Снятие средств со счета	0,25
Снятие мелкой суммы	0,75
Снятие крупной суммы	0,25
Перевод со счета на счет	0,15
Группа действий	Вероятность
Выписка дорожного чека:	0,15
Оплата со счета	0,80
Оплата наличными	0,20
Открытие нового счета	0,05

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

В табл. 5.5 мы предположили, что длина очереди клиентов не
ограничена. Однако может оказаться полезным применить для оче-
реди некоторые ограничения, для того чтобы посмотреть, как теряют-
ся клиенты в случае, если очередь чрезмерно длинна (некоторые кли-
енты не будут томиться в операционном зале, если видят, что ждать
им придется долго).

Таблица 5.5

Очередь	Поведение	Вместимость
Приходящие клиенты	ПРО	0

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

Рассмотрим рис. 5.6. Процесс, применяющийся в очереди №1, яв-
но не справляется с возложенной на него задачей: длина очереди все
время растет. Длина очереди № 2 изменяется во времени, но не превы-
шает некоторого предела. Если он неприемлем, это означает, что оче-
редь в некоторые моменты времени становится слишком длинной.
Для понимания, почему это происходит, нужен дальнейший анализ.
Возможно, в пиковые периоды нагрузки требуется оптимизация рас-
пределения имеющихся ресурсов. Очередь № 3 (и обрабатывающие ее
действия) — кандидат на исключение из бизнес-процесса, если банк и
клиенты достигнут более удачной договоренности о расписании рабо-
ты операционного зала.

Время, мин

Рис. 5.6. Результат моделирования очередей

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

Обработка результатов моделирования

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

Таблица 5.6

Номер эксперимента	Количество операционистов	Количество счетчиков банкнот
1	1	1
2	2	1
3	2	2
4	3	1
5	3 ‘	2
6	4	3
7	4	1
8	4	2
9	4	3
10	4	4

Выводы. Модели ШЕР могут применяться не только для опи-
сания функционирования системы или предполагаемых изменений в
ней, но и для оценки последствий претворения этих изменений в
жизнь. Для выявления наиболее критичных с точки зрения расхода
ресурсов элементов системы и выяснения ее оптимального состава
применяются методы имитационного моделирования, для использо-
вания которых требуется построение ШЕРО- и ШЕРЗ-моделей.
ГЛАВА

6.1

ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ
ЮЕЕ-МОДЕЛИРОВАНИЯ

Р1айпит ВРуут — руководство
пользователя программного
пакета компьютерной поддержки
технологии моделирования ЮЕР

В этом разделе приведено описание работы с наиболее популяр-
ным в настоящее время пакетом ГОЕР-моделирования Р1а1тшп
ВРауш. С использованием ВР\ут получено большинство иллюстра-
ций этой книги. В приложении 2 приведено краткое описание работы
с другим пакетом, поддерживающим технологию ГОЕР-моделиро-
вания, — Ве81§п/ГОЕР.

ВРтпТи$опа1

СИск оп Ыие }аЬе}5 и ЯпЗ оиг аЬои* 1ор1с.

СПск а Тгу к Ьийоп регТопп 1азк изтд ВРилп.

Рис. 6.1. Главное окно «Наставника»
Р1аНпшп ВРууш имеет в своем составе программу «Наставник»,
позволяющую быстро ознакомиться как с основами ГОЕЕ-моделиро-
вания, так и с его реализацией в ВРууш. Приведенное ниже описание
работы с ВРууш по сути является сокращенным вариантом учебного
курса, предлагаемого пользователям программой «Наставник». На
рис. 6.1 изображено главное окно этой программы.

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

6.1.1 Краткий обзор

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

Рис. 6.2. Кнопка «Тгу И»
8<ер 2: Нате Же СоМех< Ас1Мф

ЫоНсе Жа1 а Ыапк ас!М1у Ьох Иаз Ьвеп
сгеаЖд апд Же Ш1е Ьаг Же пе»
тойе! пате апсГ

«А4>1 - Огйег РиИШтеп!}

•	Р|дМ*с1|ск оп Же согпех! асЖйу.

Г/?е еЛогёсаг теш? /а <8ар1ауе&

•	8е1ес! Нате ЗДНог...

ТЪе ЮЕРО Мате Ргор&Шеа &а$од
Ьох /« (//вр/ауес/. 7Ъе сигаог & т 1Ъе
пате еМгу ИеМ.

«Туре:

ИЮСВЗДдепЪег кеу]

ОШ>Вк

Жеп ргеее ОК.

^ТЬе (Егйег кеу] р1асее еасЬ чмогс! оп
а зерагаЖ Нпе.

ТЬе согйех* асНийу /в по» папж/.

СНск Нех< 8<ер >

Рис. 6.3. Подсказка «Наставника»

После ознакомления с
кратким обзором можно при-
ступить к выполнению зада-
ний на типовой модели, пре-
доставляемой совместно с
обучающей программой. Для
этого на последней странице
изучаемой темы всегда появ-
ляется кнопка «Тгу И» («по-
пробовать»)— рис. 6.2. Щел-
чок по ней позволяет перейти
к пошаговому выполнению
практических упражнений.
Типовые модели подготавли-
ваются и используются вме-
сте с тренировочными уп-
ражнениями.

После нажатия кнопки
“Тгу Й” обучающая програм-
ма предоставляет набор по-
следовательных подсказок
(рие Сагбз) для облегчения

® Пу »

выполнения задания, при этом в качестве наглядных примеров ис-
пользуется типовая модель (рис. 6.3).

В «Наставнике» имеется также возможность перейти непосредст-
венно к выполнению практических упражнений без просмотра теоре-
тического материала. Для этого достаточно нажать кнопку Тгу Й в лю-
бом разделе главного меню «Наставника».

6.1.2

Проверка правильности
выполнения задания

В «Наставнике» существует возможность проверки правильности
выполнения каждой задачи, для этого достаточно просто нажать кноп-
ку «Сйеск». Проверка покажет, как должна выглядеть модель в слу-
чае, если были выполнены все рекомендации обучающей программы.
Чтобы возвратиться к кнопке «Тгу Й», на подсказке достаточно просто
закрыть окно просмотра результатов работы. Для возврата к обучаю-
щей программе необходимо щелкнуть по кнопке «Попе» окна «Тгу Й».
Зачем нужно усовершенствование
бизнес-процессов

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

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

6.1.4	Деловое моделирование

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

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

6.1.5	Что такое ВР\ллп

ВР\ут — мощный инструмент моделирования для анализа, доку-
ментирования и понимания комплексных бизнес-процессов.

Моделирование полезно для:

• устранения избыточных или ненужных блоков (функций);
•	сокращения затрат;

•	совершенствования работы компании;

•	повышения качества обслуживания клиентов.

6.1.6 | Модель ВРуу1П

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

ВР\уш можно также использовать, для моделирования потоков ра-
бот, потоков процессов и потоков данных.

И АТ ШНМ ВРмлп - {(А Функциональный блок  ц П п/яннт дн<л римм.» Ц?Н 0 Ьр IП

±5®. **** М.	.^12°^... ***** .и*



Ц5ЕОАТ:

АОТНОЯ1

РЯОЖСП д

Р.ЕУ: 01.08.60

РГЖ

СОМТЕХТ:

ТОР

(ЖАРТ
ЯЕСОММЕЮЕО
ВЖАЖ-.

Г.лтс. эа 07 Г.Г,



Стрелка
управления

Стрелка
входа

Стрелка
выход*

Функциональный блок



з.











механизма
исполнения

ИООЕ:

тПЕ:

АО

Функциональна блок

1МЦМ6ЕЯ:



Рис. 6.4. Главное окно ВР\ут
6.2

ЮЕЕ-моделирование и ВРаалп

Методологии моделирования,
поддерживаемые ВРмнп

ВРхуш поддерживает три методологии моделирования:
• функциональное моделирование (ГОЕГО);

•	описание бизнес-процес-
сов (ГОЕРЗ);

•	диаграммы потоков дан-
ных (ВРЭ).

Таким образом, ВР\ут
объединяет три ключевых
подхода к моделированию
бизнес-процессов, что впол-
не удовлетворяет потребно-
сти как системных аналити-
ков, так и специалистов-тех-
нологов.

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

ВРмлп

-I	-----------------------(

* Сге&еп'юде! .............-....;	!

; т -Г Ы*»: |.	.... .	.

 ,	. Туре-. - -- --------;

:	;	'	«	Вийпт Ноет (1ОЕРЩ	’	?	1

1	\	Г	&окйои(10ЕЕЗ)	<	'	5

		!	г	йаыьмого)	;	;	:

<** 2репто<&1	'

‘ Г Орел яим&Икзт МосШай	;

Р Ойрйу (Ий сНод оп

|	0^	| Сапсе! | Цй> |

Рис. 6.5. Выбор нотации моделирования

6.2.2	| Функциональное моделирование (ЮЕЕО)

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

Рис. 6.6. Пример диаграммы ГОЕРО

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

На рис. 6.6 показан пример простой диаграммы ЮЕГО.

6.2.3	Диаграммы потоков данных (ОРО)

Диаграммы потоков данных (ВГВ) моделируют системы как взаи-
мосвязанный набор действий, которые обрабатывают данные в «хра-
нилище» как внутри, так и вне границ моделируемой системы. Диаг
граммы потоков данных обычно применяются при моделировании
информационных систем.

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

Стрелки в ВГВ показывают, как объекты (данные) фактически
взаимодействуют между собой. Это представление, объединяющее
хранимые в системе данные и внешние для системы объекты, дает
ВЕВ-моделям большую гибкость для отображения физических харак-
теристик системы, таких как обмен данными, разработка схем их хра-
нения и обработки.

6.2.4	Описание бизнес-процессов (ГОЕРЗ)

Методология ГОЕРЗ — это методология моделирования, предна-
значенная для обеспечения структурированного подхода к описанию
бизнес-процесса как упорядоченной последовательности событий
96
чо

данные

Информация

Рис. 6.7. Пример диаграммы ПРО
Рис. 6.8. Пример диаграммы ГОЕРЗ
одновременно с описанием любых участвующих в бизнес-процессе
объектов и относящихся к ним правил.

Создание диаграмм потоков работ — техника, хорошо подходя-
щая для сбора данных о системе и применяющаяся как часть струк-
турного подхода к анализу и проектированию системы. В отличие от
других методов моделирования бизнес-процессов, ГОЕРЗ требует ис-
пользования относительно строгих синтаксиса и семантики во избе-
жание получения неполного или противоречивого описания системы.

На рис. 6.8 приведен пример диаграммы ГОЕРЗ.

Диаграммы ГОЕРЗ применяются для:

•	улучшения понимания результатов моделирования бизнес-про-
цессов;

•	определения момента окончания моделирования;

•	сбора информации о схеме работы моделируемой компании.

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

6.2.5 Когда и какие методологии применять

ГОЕРО лучше всего применять как средство анализа и логического
моделирования систем, что, как правило, выполняется на ранних ста-
диях работы над проектом. Данные анализа, полученные с использо-
ванием ГОЕРО-моделирования, обычно используются на стадии разра-
ботки моделей ГОЕРЗ и диаграмм потоков данных (ЭРП) — рис. 6.9.

Рис. 6.9. Временная шкала использования разных методологий моделирования

7*	99
Практическое использование
ВРилп

6.3.1	Рабочее место ВРмлп

Рабочее место ВРхуш выполнено в виде рабочего стола, состояще-
го из нескольких окон. На рабочем столе размещены:

•	меню;

•	стандартная панель инструментов;

•	панель инструментов «МосЫМай»;

•	дерево модели;

•	область для рисования;

•	панель инструментов ВРууш;

•	статусная строка.

Панель меню ВР\\чп соответствует стандартам \Утс1о\У8 и обеспе-
чивает доступ ко всем функциям ВРхуш. Приведем некоторые из них:

печать — чтобы открыть окно печати, на панели меню выберите
«РПе», затем «РппЬ>;

масштаб — на панели меню выберите «У1е\у», затем измените
масштаб изображения для активной диаграммы или для всех диа-
грамм в модели на тот, который вам нужен.

Стандартная панель инструментов обеспечивает быстрый дос-
туп к часто выполняемым задачам (рис. 6.10).

Рис. 6.10. Стандартная панель инструментов ВРауш

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

6.3.2	| Дерево модели

Дерево модели ВРхуш (рис. 6.11) — мощный инструмент, который
используется для просмотра структуры модели и изменения любых
объектов диаграмм в открытой модели ВРдут. Одновременно работая
с несколькими моделями, можно рассматривать все диаграммы или
100
Р1АТ1МНМ 8Рит - ИА?) Ведение лицевых карточек *

1Й: :Мй«шс

Ойдгатг; ,, ‘ /'

ЙЙ Отдел учета и отчетности

Обрабсяк# дан-мьй си

|*~0 Учет начислений и уплат.

*~О Подготовка отчетности, анаг

Поступления

Данные о
нзлоголлэтея*>ци«ах

Начисления

Отсрочки

Рис. 6.11. Дерево модели ВРхут

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

Вы можете показывать и скрывать дерево модели, используя
кнопки «Мобе1 Ехр1огег». Когда дерево модели активно, оно находит-
ся в раздвигающемся окне слева, а активная диаграмма — в правом.

Дерево модели используется для:

•	просмотра разных моделей, построенных с использованием раз-
личных методологий моделирования;

•	переключения режимов просмотра диаграмм или действий;

•	немедленного перехода к просмотру или работе с соответствую-
щей диаграммой в рабочем пространстве ВР\ут посредством
щелчка мышью на названии диаграммы или действия;

•	просмотра действий и объектов диаграммы согласно уровням де-
композиции;

•	редактирования имени модели, диаграммы или действия посред-
ством двойного щелчка мышью на соответствующем названии;

•	просмотра соответствующей объекту РЕО-диаграммы, Мобе Тгее
или родственной диаграммы посредством щелчка мышью на
названии объекта диаграммы в иерархическом дереве.

6.3.3 | Область для рисования

Область для рисования — это большая площадь справа от главно-
го окна ВРдут, в котором расположено дерево модели. Она состоит из
трех областей:
•	заголовок;

•	область для рисования;

•	название.

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

6.3.4	| Панель инструментов ВРшт

Панель инструментов ВР\ут содержит инструменты для рисова-
ния объектов в диаграмме ВРдут. Эти инструменты могут быть разме-
щены в любой стороне экрана или находиться где-то в области диа-
граммы. Вы можете показывать или скрывать панель инструментов,
используя функцию «Ухеду» на панели меню. В ВРдут существует три
разных панели инструментов — по числу поддерживаемых програм-
мой методологий (рис. 6.12).

1 ВР!л>!П Т ооЬох	• в||
теми	ор|
- Т|5|►	А|Т|

ВРу-Яп ТооЬох О

ПГО|-*|о|Д-ГИ;

ЮЕЕО	ЮЕЕЗ	0Е0

Рис. 6.12. Три вида инструментальных панелей

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

6.3.5	| Помощь

При возникновении проблем в процессе работы с ВРдут исполь-
зование «Не1р» — самый быстрый способ их решения. Чтобы присту-
пить к работе с ВР\ут «ОпНпе Неф», воспользуйтесь разделом «Неф»
на панели меню, затем выберите один из предложенных вариантов и
продолжите поиск интересующей вас темы.

Вы можете также нажать Р1, чтобы просмотреть контекстно-
зависимую помощь для текущего диалогового окна или варианта
102
меню. Заметьте, что кнопка «Не1р» имеется также в диалоговом окне
на рис. 6.13. Вы найдете кнопки «Не1р» на большинстве диалоговых
окон.

- ъ Печать I

То ог сКапде ап асйУЙу пате

вШ-



1. СИоозе опе о( (оНоулпд (о ореп

1Ье Нате 1аЬ т (Ье Ас(М(у РгореПу
$Ьее1

« ОоиЫе-сПск (Не (йадгат ас(м(у.

•	ОоиЫе-сПск (Не ас(м(у Нее
оЬ)ес( т 1Ье МойЕ^хр.1огйь

2 СИоозе опе о( (Не (оПоулпд орйопз (о
пате а пеад ас(м1у ог сИапде Ше
пате о( ап ех»з11пд ас!м(у:

к То изе ап ех1зйпд ас(м!у пате
(гот (Не дкЛюпату, $е1ес( а пате
(гот (Ье 1)пи$е4 АсНиИу Натее
!«$(.

•	То аз$1дп а пеу/ пате, Туре а
пате »п (Ье (ех( Ьох,

«	То сЬапде (Ие сиггеп( пате, Туре
(Не сИапде т (Ье 1ех( Ьох.

3. СНскОК.

Жп<: То тойНу аИ оссиггепсез о(Же

Рис. 6.13. Окно контекстно-зависимой помощи

6.3.6 | Построение контекстных диаграмм

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

При создании модели сначала необходимо изобразить самый
высокий уровень — действие контекста. Наименование действия опи-
сывает систему непосредственно и, как правило, состоит из одного
активного глагола в сочетании с обобщающим существительным, ко-
торое разъясняет цель деятельности с точки зрения самого общего
взгляда на систему.
Каждый блок может иметь различные типы связанных с ним стре-
лок. Стрелки обозначают людей, место, вещи, понятия или события.
Стрелки связывают границы диаграммы с блоками, а также действия
(блоки) на диаграмме между собой. В диаграммах ГОЕРО имеется че-
тыре основных типа стрелок.

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

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

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

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

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

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

После создания модели можно задать ее параметры. Список
свойств модели — это диалог, в котором можно задать такие парамет-
ры, как полное наименование модели, ее словесное описание и состоя-
ние, в котором находится модель, например «в работе» или «для
публикации» (рис. 6.14).
Рис. 6.14. Диалог задания свойств модели

6.3.7 Декомпозиция

Декомпозиционное разложение модели используется в моделиро-
вании бизнес-процессов, для того чтобы дать более подробное описа-
ние блоков. Каждое из этих действий может в свою очередь быть де-
композировано. При каждой декомпозиции блока создается новая
диаграмма. Число декомпозиций не ограничено и полностью зависит
от уровня сложности, который необходимо показать в модели. Обра-
тите внимание на кружок на рис. 6.15.
Если действие не было декомпозирова-
но, в верхнем левом углу блока будет по-
являться символ «листа». После деком-
позиции данного блока символ «листа»
исчезнет.

Как декомпозировать блоки с ИС- Рис. 6.15. Обозначение блока,
пользованием ВРхуш? Это можно еде- не имеющего декомпозиции

Ор.	1

Обработать
заказы
лать двумя способами. В диаграмме нужно выбрать действие, которое
необходимо декомпозировать. Для этого выберите необходимый ин-
струмент в наборе ВРауш или в дереве модели, затем щелкните на дей-
ствии, которое нужно декомпозировать. Выбранное меню содержит
команду декомпозиции. В появившемся диалоге необходимо задать
требуемые тип и число подблоков. При декомпозиции блока ВР^уш
создает новую диаграмму, которая является диаграммой разложения
родительской диаграммы. Заметьте, что новые действия не связаны
между собой и не поименованы — это ваша следующая задача. Вы
должны задать взаимодействие между блоками и «привязать» к но-
вым блокам стрелки, которые автоматически унаследованы от роди-
тельской диаграммы.

Имя блока и другие его свойства вводятся в закладке «Кате» спи-
ска свойств блока. Для вывода свойств блока на экран достаточно два-
жды щелкнуть мышью на блоке.

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

Задание имени стрелки производится в закладке «Кате» диалога
свойств стрелок. Для вызова этого диалога достаточно дважды щелк-
нуть мышью на нужной стрелке.

Если стрелка заканчивается на границе диаграммы ВРдут, она по-
мечается туннелем из квадратных скобок. Аналогично помечаются
стрелки в родительской диаграмме, если в диаграмме декомпозиции
удаляется перенесенная из нее стрелка. Квадратный туннель на начале
стрелки указывает, что стрелка «не решена» в пределах иерархии мо-
дели (не имеется никакой другой стрелки с таким же именем в любой
другой диаграмме модели). Для поддержания целостности модели не-
обходимо корректировать стрелки, помеченные «туннелями» из квад-
ратных скобок, одним из следующих способов:

•	преобразованием в туннель из круглых скобок;

•	добавлением новой стрелки, соединяющей соответствующий
блок с границей диаграммы;
•	созданием внешней ссылки (ссылки на объект, не описанный в
данной модели) в соответствии с методологией ГОЕРО;

•	созданием ссылки на блок, расположенный на другой диаграмме.

В любой момент работы с диаграммой существует возможность
добавления на нее новых блоков с использованием инструмента
«Асбуйу Ьох Тоо1» панели инструментов. Для добавления блока сле-
дует щелкнуть на этом инструменте, а затем — на диаграмме в том
месте, где необходимо расположить новый блок. После того как до-
полнительный блок создан, вы можете связать его стрелками с други-
ми блоками и задать его название и другие свойства.

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

Перемещение любых объектов на диаграмме осуществляется с по-
мощью их «захвата» мышью и перемещения в новое место. При пере-
мещении блоков одновременно перемещаются и связанные с ними
стрелки. Функциональные блоки могут также быть перемещены меж-
ду диаграммами с использованием команд «Си1/Ра81е» из меню «Ес1й».
Номера блокам диаграммы ВРауш присваиваются автоматически. При
изменении взаимного расположения блоков могут меняться и их но-
мера.

Изменение размеров объектов диаграммы может быть сделано
перемещением их границ. Для запрета изменения размеров объектов
используют вкладку «ЬауоиЬ> диалога ввода свойств модели.

Если включен просмотр дерева модели, существует возможность
просмотра модели как дерева диаграмм или дерева функцио-
нальных блоков. Вершина дерева модели имеет кнопку переклю-
чения «Вха&гатз/АсбуШез» для отображения соответственно де-
рева диаграмм или дерева действий. Дерево диаграмм открывается
по умолчанию при запуске ВРдут. Дерево моделей ВРдут исполь-
зует специальный набор графических символов для представле-
ния диаграмм и действий в пределах дерева объектов. Вы можете
использовать это дерево, чтобы переключиться на соответствую-
щиемодель, диаграмму или действие для выполнения редактиро-
вания.
6.3.8

Оформление моделей

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

•	выделения недостаточно проработанных моментов;

•	выделения внесённых изменений;

•	отображения похожих по смыслу объектов.

Изменение цвета блоков диаграммы осуществляется с использо-
ванием цветового редактора (рис. 6.16). Чтобы изменить цвет объекта,
необходимо:

•	щелкнуть правой кнопкой мыши на объекте, выбрать в появив-
шемся меню пункт «Со1ог ебйог»;

•	выбрать необходимый цвет объекта из предложенной палитры.



8е1 Сокнз

(Ж

Г* ТехЮоки

ТЕХТ <♦	Со1ог 

------- "Г Тй!е СЫог

Сапсе!

ЕсЙ



Рис. 6.16. Цветовой редактор

Выбор атрибутов шрифта. Атрибуты шрифта (рис. 6.17), такие,
как тип, размер и стиль, могут использоваться для выделения или
группировки функциональных блоков. Для изменения шрифта сле-
дует:

•	щелкнуть правой кнопкой мыши на объекте, выбрать в появив-
шемся меню пункт «Роп1 ебйог»;

•	выбрать необходимый шрифт и, при необходимости, задать его
атрибуты.

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

Оформление стрелок. Использование стилей применяемых в
диаграмме стрелок важно для целостности и удобочитаемости созда-
ваемых диаграмм ГОЕРО. Вы можете изменять вид стрелок, устанав-
ливая их толщину, форму и цвет. Цвет стрелки выбирается с использо-
ванием редактора цветов, как описано выше. Толщина стрелок также
может быть изменена, что применяется для выделения отдельных



Н)ЕГО Авош Ргорейй®

Рис. 6.18. Выбор вида и оформления стрелки
процессов на диаграмме. Для изменения толщины стрелки необхо-
димо:

•	щелкнуть правой кнопкой мыши на стрелке и выбрать в меню
пункт «81:у1е ебйог»;

•	выбрать необходимую толщину стрелки в разделе «ТЫскпезз».

Следует обратить внимание на форму стрелки, которая определе-
на в соответствии с используемой методологией. Стрелки типа
«Ке1айопа1» не описаны в методологии ГОЕРО, но могут использовать-
ся, если строгое следование ГОЕРО не обязательно. Диалог выбора ви-
да и оформления стрелки приведен на рис.'6.18.

6.3.9	Ветвление и объединение стрелок

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

Названия стрелок отображаются автоматически и могут быть пе-
ремещены с помощью мыши. Для соединения стрелки с ее названием
может быть использован инструмент «8дш§§1е» с панели инструмен-
тов ГОЕРО или ГОЕРЗ.

Для пояснения содержимого диаграмм можно помещать на них
текстовые блоки с произвольными комментариями. Для добавления
текстового блока в диаграмму необходимо:

•	выбрать инструмент «Тех!» и щелкнуть мышью на том месте диа-
граммы, где необходимо разместить пояснения;

•	в появившемся текстовом окне следует ввести текст пояснения.

К текстовым блокам применимы все описанные выше инструмен-
ты оформления.

6.3.10	| Опции отображения

Вы можете отображать или скрывать определенные объекты диа-
граммы и отдельные элементы оформления. Например, Вы можете пе-
реключать тени функциональных блоков на диаграмме. Параметры
НО
меню «У1е\у» (рис. 6.19) относятся од-
новременно ко всем диаграммам разра-
батываемой модели.

В этом же меню производится на-
стройка рабочего места ВРауш. Напри-
мер, можно отобразить или скрыть
стандартную панель инструментов, па-
нель инструментов «Моде1МагЬ>, па-
нель инструментов «ВРхуш», дерево
модели и строку состояния. Также об-
ратите внимание на пункт меню
«2оош», позволяющий изменять мас-
штаб просматриваемых диаграмм. Этот
пункт дублирует инструмент «2оош»
стандартной панели инструментов.

; {Ивей Вер«* 1осЬ

** Ас^фО^/Егед.Л)иг,
м* Ас&йу&ит{т

* Титек

*

* ^еаГСогпш

✓ ЗигкЫТооЫг

* ЙРадпТооЬох

** МодейМай ТооЙиг

* Мо&1Е$&ге?

<✓ $№игВаг

Рис. 6.19. Опции отображения

6.3.11	Другие виды диаграмм ЮЕЕО

В дополнение к контекстным диаграммам и диаграммам декомпо-
зиции другие типы диаграмм ВР\ут позволяют упростить представле-
ние и разработку модели. Например, может оказаться необходимым
разработать сценарий «что-если» для модели.

В этом разделе будет рассмотрено создание двух типов моделей:
• диаграммы «только для представления» (Рог ЕхрозШоп Оп1у —

РЕО);

• древовидные диаграммы.

При правильном использовании эти типы диаграмм упрощают до-
кументирование моделей.

Создание диаграмм РЕО. Диаграмма РЕО может быть использо-
вана для пояснения какой-либо части процесса, отражения особой
точки зрения или выделения функциональных деталей, которые не-
возможно показать с использованием синтаксиса ГОЕРО. Диаграммы
РЕО могут снабжаться дополнительным поясняющим текстом и не
обязательно должны разрабатываться с учетом ограничений стандар-
та ГОЕРО. Диаграммы РЕО могут быть ассоциированы с любой суще-
ствующей в модели диаграммой, но они не являются иерархической
частью модели. Диаграмма РЕО — копия любой существующей в мо-
дели диаграммы. Диаграмма идентифицируется с помощью:
•	задаваемого разработчиком имени;

•	идентификатора вида АхР, где х — исходная диаграмма, а символ

Р показывает, что диаграмма имеет тип РЕО.

РЕО-диаграммы добавляются в модель с использованием пункта
«РЕО сНа^гаш» меню «Тпзег!». В диалоге «Сгеа1е Меху РЕО О1а§гат»
выберите один из следующих типов диаграммы для копирования:
• если Вы выбираете «СоШех!», просто напечатайте имя новой диат

граммы в поле «Кате»;

•	если Вы выбираете «ОесотрозШоп», активизируется выпадаю-
щий список «Сору Ргот», показывающий все диаграммы деком-
позиции в модели.

После нажатия ОК РЕО-диаграмма будет создана и отображена на
рабочем столе ВРхтаз.

Так же как и для любой другой диаграммы, вы можете открыть
диалог ввода свойств РЕО-диаграммы.

Создание древовидных диаграмм (Нойе Тгее О1а$гат$). Древо-
видные диаграммы используются для отображения структуры модели
в целом. В них, как правило, вершина (самый верхний узел) соответст-
вует диаграмме контекстного уровня. Однако в качестве вершины мо-
жет быть использован любой функциональный блок модели, при этом
его подблоки будут показаны в качестве ветвей дерева.

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

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

Древовидные модели нумеруются по шаблону АхЫ, аналогично
диаграммам ГЕО.

Древовидные диаграммы добавляются в модель с использованием
пункта «Кобе 1гее» меню «ЬхзеП».

При этом выводится диалог «Кобе 1гее йейшйоп», в котором зада-
ются:

•	имя;

•	функциональный блок вершины;

•	количество отображаемых уровней;

•	параметры форматирования.

После нажатия ОК древовидная диаграмма создается и высвечи-
вается на рабочем столе ВРхуш.
6.3.12

Открытие древовидных и ЕЕО-диаграмм

Древовидные и РЕО-диаграммы объединяются под названием
«родственные» диаграммы. Они не отражаются непосредственно в де-
реве модели, однако последнее может быть использовано для их от-
крытия. Для этого нужно, во-первых, переключить дерево модели в
режим «О1а§гат У1е\у», а затем щелкнуть правой кнопкой мыши на на-
звании диаграммы. При этом ВРхуш выдаст соответствующий список
родственных диаграмм. Для их открытия можно также использовать
инструмент «81Ыт§ сНа^гат 1оо1» на панели инструментов ВРхуш.

6.3.13 | Разбиение и объединение моделей

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

Разбиение модели. Для его осуществления необходимо придер-
живаться следующего алгоритма:

•	определите часть модели, которую необходимо отделить;

•	щелкните правой кнопкой мыши на выбранном функциональном
блоке;

•	выберите пункт меню «8р1й шос1е1»;

•	в диалоге «8р1й орйопз» введите имя, соответствующее имени
функционального блока, что позволит впоследствии объединить
модель;

•	включите опцию «Сору епйге (йсбопапез», чтобы скопировать
словари объектов в отделяемую часть модели;

•	нажмите ОК.

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

•	блок, с которого производилось разбиение, становится диаграм-
мой контекстного уровня в новой модели;
•	в исходной связи появляется стрелка связи с именем, соответст-
вующим имени новой модели;

•	все дочерние диаграммы функционального блока перенесены в
новую модель;

•	разделенный функциональный блок остается в исходной модели.

После создания новой модели можно использовать диалог ввода
свойств модели для определения свойств созданной модели.

Объединение моделей. По завершении разработки разделенных
моделей ВРхуш позволяет объединить их в одну. Для объединения мо-
делей должны выполняться следующие условия:

•	название стрелки связи должно соответствовать названию импор-
тируемой модели;

•	название функционального блока в контекстной диаграмме им-
портируемой модели должно соответствовать названию аналогич-
ного функционального блока в основной модели.

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

После открытия основной и импортируемой модели нужно:

•	щелкнуть правой кнопкой мыши на функциональном блоке основ-
ной модели, к которому нужно импортировать данные;

•	выбрать из меню пункт «Мег§е Мос1е1»;

•	диалог «Сопйгше шег§е?» подтверждает, что именно вы хоти-
те объединить и позволяет задать опции объединения.

По завершении объединения дерево модели обновляется для отра-
жения изменений в основной модели.

6.3.14

Оценивание бизнес-процессов
с использованием ВРуу1п

Добавление оценок к функциональным блокам ВРхуш обеспечива-
ет задание таких характеристик, как стоимость, время выполнения ра-
боты, параметры качества. Рассмотрим два метода задания этой ин-
формации:
•	задание оценок для функциональных блоков;

•	задание свойств блока, определяемых пользователем.

Добавление стоимостных оценок для функциональных блоков ос-
новано на применении метода «Асбу11у Ьазеб со8Й炙 (АВС). Основ-
ная идея этой технологии состоит в задании оценки отдельных функ-
циональных блоков системы для получения суммарной оценки затрат
на работу всей системы (модели). Затраты на работу родительских
функциональных блоков, как правило, должны быть идентичны за-
тратам на функционирование всех входящих в них подблоков. Таким
образом, АВС может использоваться для оценки затрат на функцио-
нирование системы в целом, например, для определения:

•	стоимости производимой продукции;

•	затрат на сервисные услуги;

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

Технология АВС предполагает объединение затрат в «центры
затрат» (под которыми понимается любой бизнес-процесс, функцио-
нальный блок или состояние системы, которые в конечном счете
влияют на стоимость функционирования системы) с последующим
отнесением стоимостей к объектам модели. Перед началом оценива-
ния затрат необходимо убедиться, что существующая модель полна и
устойчива. Оценка функциональных блоков производится в три этапа:

• определение единиц изме-
рения;

• определение «центров за-
трат»;

• применение ценовых мето-
дов к объектам модели.

Выбор единиц измерения
предусматривает определение
вида валюты, вида представле-
ния денежных единиц на экра-
не, а также единиц времени
(минуты, часы и т.п.). Эти па-
раметры являются глобальны-
ми по отношению к модели и
задаются в закладке «АВС
со81§» диалога задания свойств
модели (рис. 6.20).

!МоНе1 РюрегЬе*

«

Ойшй '!,	"'Г|	'\Г’&№'

; *	-/л?	’ г’л.





' НхлпЬег 4 Люяздй о!



Рис. 6.20. Диалог задания единиц
измерения

8*

115


[Проведение рекламной кампаний

Со81 Сегйег ЕсШог

ч ОеОиШоп



Црс1а&

|Мй

1-

СЬ$е

Не1р

Рис. 6.21. Диалог ввода данных о «центрах затрат»

Определение «центров затрат» («СоМ Сеп1ег$») — категорий
стоимости, которые будут присваиваться функциональным блокам
модели. Примеры «центров затрат»:
• маркетинг и реклама;

• закупки комплектующих изделий;

• техническая поддержка.

«Центры затрат» задаются с использованием пункта «Со§1 Сеп1ег
Ебйог» меню «ЕсйЬ> (рис. 6.21).

Ввод информации о затратах. Для каждого функционального
блока модели вы должны задать стоимость его работы, состоящей из
затрат, определенных на предыдущем этапе при задании «центров за-
трат». Для этого используется команда «Ас11У11у со§1 ебйог», вызывае-
мая из соответствующего меню при щелчке правой кнопкой мыши на
функциональном блоке (рис. 6.22). Для каждого функционального
блока определяется:
• частота его вызова;

• продолжительность работы;

• затраты на работу блока из «центра затрат».
ЮРГО АсНуйу Ргорей«е*	I??*



ЯМММ!М1>НМЙ1«М»И»«9^^





9Ш

Оаеа й йот 0всотройюг1&

ТоЫсог1

г ДтеаИе с1есотро5Йоп5 Т<Яа1ив<хЕ«к»лпсу.

о.ге

0.00

У гй



Вшйюп х Ггедиепсу О..СЮОО вау$

ок ] Отмена |  >.  - .^- [ Справка

Рис. 6.22. Ввод стоимостных параметров блока

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

Оценка затрат с использованием свойств, определяемых поль-
зователем. Свойство, определяемое пользователем (118егЮейпес1
Ргорег1у — ИПР), используется для отображения произвольной ин-
формации, относящейся к конкретному функциональному блоку или
стрелке. ВР\ут поддерживает различные типы СПОР, включая:
• «выпадающие списки», например, для хранения информации об
организации процесса или оценки его уровня,

• исполнимые 1ЮР, которые содержат ссылки на прикрепленные
объекты, обрабатываемые другими программами;

• текстовые списки, используемые, например, для хранения инфор-
мации типа «критические факторы успеха».

• 1ЮР могут использоваться для более полной детализации модели
и задания, например, таких свойств, как время, стоимость, качест-
во и ответственные лица.

[ЮР задаются с помощью пункта «СГзегЮейпес! Ргорег1у Наше
Еййог» меню «Е<11Ь>. Для этого нужно:
•	именовать свойство;

•	установить тип данных свойства;

•	при необходимости уточнить характеристики свойства (это необ-
ходимо для некоторых типов данных).

После создания ПОР существует возможность присвоения им зна-
чений с помощью закладки «1Л)Р уа1и姻 диалога редактирования
свойств функционального блока или стрелки.

6.3.15 | Печать диаграмм ВРмлп

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

•	выбрать диаграмму или диаграммы, которые вы хотите напеча-
тать;

®	включить родительскую диаграмму для диаграммы, которую вы
будете печатать;

®	определить спецификацию диаграммы для печати: цветовая гам-
ма, внешние границы диаграммы;

Рис. 6.23. Диалог выбора опций печати
•	отправить диаграмму в файл для последующей печати;

•	определить, как печатать диаграммы: каждая диаграмма на одном
листе по выбору, пакетная печать всех диаграмм модели с указа-
нием количества их на листе.

Вы можете печатать диаграммы ВРхуш из меню печати диаграм-
мы ВРхут, которое может быть открыто из меню «РПе» командой
«РппЬ> или нажатием изображения принтера на панели инструментов
(рис. 6.23). Этот режим позволяет вам определять опции печати, упо-
мянутые ранее.

6.3.16 | Отчеты по модели

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

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

•	отчет по диаграммам (б1а§гат герог!) — включает информацию об

объектах в активной диаграмме ВРхут;

•	отчет о стрелках (аггоху герог!) — включает информацию о стрел-
ках (связях) в ВРхут-модели;

•	отчет о затратах (асйуйу со§1 герог!) — содержит информацию о
затратах функциональных блоков и о «центрах затрат» в
ВРхут-модели;

•	отчет об объектах диаграммы (сНа^гат оЬ)ес1 героП) — содержит
информацию об объектах, размещенных на диаграмме (функцио-
нальных блоках, хранилищах данных и внешних ссылках) в
ВРхут-модели;

•	отчет об использовании данных (баи и§а§е герог!) — содержит ин-

формацию о таблицах базы данных или сущностях и атрибутах;

•	отчет о целостности модели (тобе1 соп§181епсу герог!) — содержит

информацию о том, насколько активная ГОЕРО-модель соответст-
вует выбранной ГОЕРО-методологии;
•	отчет о модели (тобе! герой) — содержит общую информацию от-
носительно ВРхут-модели (ГОЕРО, ГОЕРЗ или ВРИ). Отчет о мо-
дели может включать один или большее количество элементов,
указанных в диалоге «Мобе1 ВейпШоп Ебйог».

Для получения отчета необходимо выполнить следующие основ-
ные действия:

•	выбрать нужный отчет в меню «Керойз»;

•	выбрать элементы модели, которые необходимо включить в отчет
(рис. 6.24);

•	выбрать, куда нужно вывести сформированный отчет.

Рассмотрим более сложный отчет, например отчет об объектах
диаграммы. Как показано на рис. 6.24, это диалоговое окно имеет на-
много больше параметров, чем в предыдущем примере. Сложность
отчета определяется количеством данных, которые нужно отразить в
нем. Для выполнения отчета об объектах диаграммы нужно:

Омфат 0Ь>ес1 Верой

..................-	3 <

Верот! сит Р АсНуЙт Г* Оа*а йоге$ П ЕхЬйпа!

МоМ А

ГХаЬОейаеД. '



\ 1 Р Нате Г АОЬогМав®
Г	ЫитЬег	Г ДЬ|ес!Туре

Г"	ЕеМюп	Г" ^ас!$

'	Г	51акв	Г ОЙей®

?	Г	Г 0е®сг®1юп

:	ГЗоисг.	Г СопЛаЫ®

! Г*

I Г~

: ГСтНЫше

Г Г

> Г*

4	' аш ’	... Т* . -

1 { ^ Н.ерев1йд (лГ0ир У:

-Л!

 I?

$7 Яе-тоуе5реаа1СИа(

Р* С«мПП	С' :

 ;	.у

'ф

{	[

-	ОгсЫпд - ~—*

Т- ..'САЛгЙЙ -.]<

и$ег-ОеЯпей Ргорегйез:

Г МесЬОебпйоп

Г СаИА^Ыате

П СйАиоюОейпШоп

Рис. 6.24. Диалог задания параметров отчета
•	определить объекты диаграммы и степень детализации отчета;

•	выбрать элементы данных, которые нужно включить в отчет
(обратите внимание, что можно включать в отчет определяемые
пользователем свойства — ИЭР);

•	определить дополнительные параметры форматирования для пе-
чати или имена дисковых файлов;

•	определить, как данные отчета будут упорядочены.

ВРдут устанавливает набор предопределенных отчетов, которые
указаны как «стандартные». Это отчеты с заранее выбранными пара-
метрами, подходящими для большинства пользователей.

Не все отчеты ВРауш имеют стандартную форму. Стандартные от-
четы приведены вверху окна выбора, как это показано на рис. 6.24. На-
жав на кнопку раскрытия списка, вы будете видеть набор имеющихся
стандартных отчетов.

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

Кнопки «Нрс1а1:е» и «Пе1е1е» позволяют изменять существующие
параметры отчета или удалять созданные отчеты.

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

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

Выводы. В этой главе мы познакомились с программным сред-
ством Р1айпит ВРдут — наиболее распространенным на сегодняш-
ний день пакетом, поддерживающим создание моделей ГОЕРО, ГОЕРЗ
и ПРО. Широкий набор функций этой программы позволяет приме-
нять ее как для разработки программного обеспечения корпоратив-
ных информационных систем, так и для решения задач по реинжини-
рингу бизнес-процессов.
7

ГЛАВА

ПРАКТИЧЕСКИЕ ПРИМЕРЫ
ИСПОЛЬЗОВАНИЯ
ЮЕР-ТЕХНОЛОГИЙ

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

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

Как уже было рассмотрено ранее, 8АВТ — это методология,
разработанная специально, для того чтобы облегчить описание и пои-
мание искусственных систем, относящихся к разряду средней слож-
ности. Уже в течение продолжительного времени эта методология
успешно применяется для описания большого количества сложных
искусственных систем из широкого спектра областей (банковское
дело, планирование промышленного производства, организация
материально-технического снабжения, методология планирования,
технология программирования). Причина такого успеха заключает-
ся в том, что 8АЭТ является полной методологией для создания
описания систем, основанной на концепциях системного модели-
рования.

В этой главе приведены примеры практического применения
ГОЕГ-технологий моделирования для различных предметных об-
ластей.

ЮЕЕ-моделирование
в налогообложении

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

7.1.1	Постановка задачи

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

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

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

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

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

Разработка структурной функциональной модели деятельности
инспекции МНС РФ позволит построить модель деятельности, пред-
ставляющей собой “снимок” технологии функционирования налого-
вой инспекции на момент исследования. Данная модель позволит как
проанализировать бизнес-процессы, происходящие на территориаль-
ном уровне с использованием методов системного анализа, так и
сформулировать, обобщить подходы по реинжинирингу налогового
механизма.

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

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

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

Название проекта', моделирование деятельности инспекции
МНС РФ.

Цель проекта: реализация структурной функциональной модели
деятельности инспекции МНС РФ.

Точка зрения: руководство налоговой службы.

Технология моделирования: метод функционального моделиро-
вания ГОЕРО.

Инструментарий: программный продукт ВРхут 1.8.0.

Список данных:

•	методология;

•	кадровый состав;

•	техническое обеспечение;

•	программное обеспечение;

•	данные о налогоплательщиках;

•	бухгалтерская, налоговая отчетность;

•	платежные документы;

•	входящие документы;

•	отчетность;

•	сведения по начислениям;

•	сведения о состоянии лицевых счетов;

•	выходящие документы;

•	налоговые предписания.

При формировании списка данных необходимо проводить груп-
пировку понятий в целях повышения читабельности диаграммы
модели. Например, управлением рассматриваемой модели могут слу-
жить: законодательство, инструктивные материалы МНС РФ, долж-
ностные инструкции. Все эти понятия заменяются термином “ме-
тодология”. Примечания к модели содержат раскрытие каждого из
понятий для лучшего понимания построенной модели.

Уровень детализации и декомпозиции модели зависит от потреб-
ностей пользователя, который будет ее применять. Построение мо-
дели является итеративным процессом, т.е. первый реализованный
вариант модели, скорее всего, не будет окончательным и будет допол-
няться в дальнейшем.

Перечень функций'.

деятельность инспекции МНС РФ АО;

деятельность отдела налогообложения юридических лиц — А:
регистрация налогоплательщиков — АН,
камеральные проверки — А12,
документальные проверки — А13,
оперативно-бухгалтерский учет — А14,
анализ состояний предприятий — А15,
формирование отчетности — А16,

работа с электронной выпиской по банку — А17;

деятельность отдела налогообложения физических лиц — А2:
регистрация налогоплательщиков — А21,
налогообложение по подоходному налогу — А22,
налогообложение по имущественным налогам — А23,
оперативно-бухгалтерский учет — А24:

ведение лицевых карточек по подоходному налогу, налогу на
рекламу, налогу с продаж — А241,

ведение лицевых карточек по имущественным налогам —
А242,

ведение реестра платежных документов — А243,

ведение реестра поступлений — А244,

ведение реестра заключений — А245,

ведение реестра требований — А246,

формирование отчетных форм — А247,

контроль за финансовым состоянием граждан — А25,
формирование отчетности — А26,

работа со сведениями взаимодействующих структур — А27;

деятельность отдела информатизации — АЗ;

деятельность отделов административно-хозяйственного обеспече-
ния — А4.
7.1.3 Словарь

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

Бухгалтерская, налоговая отчетность — данные, предостав-
ляемые налогоплательщиком, на основании которых будет произво-
диться расчет налога.

Входящие документы — данные, получаемые от внешнего ис-
точника и связанные с деятельностью налогового органа, например,
сведения из банков о движении на счетах граждан сумм свыше
10 000$, запросы налогоплательщика и т.д.

Выходящие документы — данные, предоставляемые внешним
источникам налоговым органом, например, требования об уплате на-
лога, ответы на запросы и т.д.

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

Кадровый состав — сотрудники инспекции.

Методология — совокупность приемов и методов налогообло-
жения.

Отчетность — стандартная отчетность, предназначенная для
передачи в вышестоящие структуры либо для внутреннего пользо-
вания.

Платежные документы — данные о налоговых поступлениях.

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

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

Сведения по начислениям — данные, полученные в результате
расчета налога, необходимые для ведения лицевого счета налогопла-
тельщика.

Техническое обеспечение — совокупность аппаратных средств.
ГОЕРО-диаграммы модели представлены на рис. 7.1-7.4.

Методо-
логия

Данные________

о плательщиках
Бухгалтерская
отчетность

Входящие______

документы

Платежные
документы

Деятельность
ИМНС РФ

Отчетность

Выходящие
документы

Кадровый
состав

Програм-
мное
обеспе-
чение

Техни-
ческое
обеспе-
чение

Рис. 7.1. Контекстная диаграмма модели деятельности ИМНС РФ

Рис. 7.2. Декомпозиция первого уровня
г 1500

Рис. 7.3. Одна из декомпозиций второго уровня
Рис. 7.4. Одна из декомпозиций третьего уровня
Проводить дальнейшую декомпозицию не представляется целесо-
образным с точки зрения руководства МНС РФ, т.к. моделирование
третьего уровня и его декомпозиция уже предполагают рассмотрение
с точки зрения методистов Управления МНС РФ по оперативно-бух-
галтерскому учету.

7.1.5 | Описание функциональных блоков

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

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

А1. Деятельность отдела налогообложения юридических лиц.

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

А2. Деятельность отдела налогообложения физических лиц.

На данном этапе рассматривается методология деятельности от-
дела налогообложения физических лиц в целом. Декомпозиция про-
ведена также в соответствии с организационно-штатной структурой
отдела.

А24. Оперативно-бухгалтерский учет.

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

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

А243. Ведение реестра платежных документов.

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

•	анализ технологии работы на основе этой модели позволяет вы-
явить узкие места и увеличить производительность труда сотруд-
ников налоговых инспекций;

•	возможность быстрого и качественного обучения новых сотруд-
ников инспекции МНС РФ.

7.2

Моделирование
управленческого учета
на предприятии

7.2.1	Постановка задачи

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

Институт дипломированных бухгалтеров в области управления
(СЬаЛес! ТпзбШТе о Г Мапа§етеп1 Ассоип1ап1:8) определяет управленче-
ский учет как деятельность по обеспечению руководства информаци-
ей, которая необходима для управления предприятием с максимально
возможной степенью эффективности. Информация, которую обеспе-
чивает управленческий учет, может быть представлена в любой фор-
ме по выбору руководства.

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

7 2 2 Основные элементы модели
управленческого учета

Название проекта, организация управленческого учета на пред-
приятии.

Цель проекта: подготовить рабочую модель бизнес-процесса
управленческого учета для внедрения на предприятии.

Точка зрения: руководство предприятия.

Инструментарий: методология функционального моделирова-
ния ГОЕРО и программное приложение ВРауш 1.8.0.

Список данных:

потребность в управленческой информации;

стратегия предприятия;

управленческая информация;

информационная система;

финансовая функция;

центры ответственности;

руководство предприятия;

данные;

методология управленческого учета;

финансовая отчетность;

обработанные данные;

стратегия управленческого учета;

имеющиеся ресурсы;

квалификация персонала;

первичные документы;

данные в информационной системе;

подтвержденные данные;

отчетность в разрезе центров ответственности;

сводная отчетность;

отчетность по требованию.
7.2.3	I Перечень функций

В модели использованы следующие функции:
организовать управленческий учет — АО;

разработать методологию управленческого учета — А1:

определить стратегию управленческого учета — АП,

оценить имеющиеся ресурсы — А12,

разработать приемы и методы управленческого учета — А13;

собрать и обработать данные — А2:

получить и ввести данные — А21,

подтвердить данные — А22,

обработать данные — А23;

подготовить управленческую отчетность — АЗ:

подготовить отчетность по центрам ответственности — А31,

составить сводную отчетность — А32,
подготовить отчетность по требованию — АЗЗ.

7.2.4	| Словарь

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

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

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

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

Квалификация персонала — совокупность знаний, умений и на-
выков персонала в конкретной профессиональной области.

Методология управленческого учета— совокупность приемов и
методов ведения управленческого учета.

Обработанные данные — данные, распределенные по объектам
учета и центрам ответственности.

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

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

Подтвержденные данные — данные, соответствующие первич-
ным документам. Данные в информационной системе, обозначенные
как соответствующие первичным документам.

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

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

Сводная отчетность — стандартная управленческая отчет-
ность, характеризующая деятельность предприятия в целом. Деятель-
ность центров ответственности представлена обобщающими показа^
телями.

Стратегия предприятия — совокупность целевых ориентиров,
определяющих деятельность предприятия в долгосрочном периоде.

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

Управленческая информация — информация, необходимая для
принятия управленческих решений.

Управленческая отчетность — управленческая информация,
представленная в удобной для чтения форме. Может быть стандарт-
ной, подготавливаемой регулярно в установленной форме, и нестан-
дартной, подготавливаемой по требованию.

Управленческий учет — деятельность по обеспечению руковод-
ства предприятия информацией, необходимой для принятия управ-
ленческих решений.

Финансовая отчетность — агрегированная отчетность, под-
готавливаемая на регулярной основе для внешних пользователей
информации. Требования к составу, порядку составления и срокам
предоставления финансовой отчетности устанавливаются законода-
тельством или стандартами бухгалтерского учета.

Финансовая функция — бухгалтерия и финансовые подразделе-
ния предприятия.
Центры ответственности — структурные сегменты предпри-
ятия, руководители которых несут ответственность за конкретные по-
казатели деятельности (например, руководитель центра затрат отвеча-
ет за затраты своего сегмента, руководитель центра прибыли — за
затраты и выручку и т.д.).

7.2.5

ЮЕЕО-диаграммы модели
управленческого учета

ГОЕРО-диаграммы модели управленческого учета представлены
на рис. 7.5-7.7.

Стратегия
предприятия

Потребности
в управленческой
информации

Организовать
управленческий учет

Управленческая
информация

Руко-
водство
пред-
приятия

Центры
ответ-
ствен-
ности

Финан-
совая
функция

Информа-
ционная
система

Рис. 7.5. Контекстная диаграмма модели управленческого учета

7.2.6 Описание функциональных блоков

А1. Определить цели управленческого учета.

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

АН. На первом этапе декомпозиции руководством определяется
стратегия управленческого учета на основе потребностей в управлен-
ческой информации. Его задача — формализовать потребности и
увязать их со стратегией предприятия.
. Рис. 7.6. Декомпозиция первого уровня

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

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

А2. Собрать и обработать данные.

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

А21. Данные собираются и вводятся в информационную систему
непосредственно центрами ответственности, что обеспечивает опера-
тивность поступления информации. Состав данных, аналитические
признаки и сроки их учета определяются методологией.

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

А23. Данные в информационной системе распределяются по объ-
ектам учета и центрам ответственности. При наличии достаточной
аналитики это осуществляется автоматически.

АЗ. Подготовить управленческую отчетность

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

АЗ 1. Распределение данных по объектам учета и центрам ответст-
венности позволяет сформировать отчетность в разрезе центров от-
ветственности. Форма отчетов и сроки их представления определяют-
ся методологией.

А32. Сводная отчетность формируется на основе консолидации
отчетности центров ответственности и других обработанных данных.
В части подтвержденных данных контрольные функции выполняет
финансовая отчетность.

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

Применение функционального
моделирования в аудиторской
деятельности

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

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

8АВТ (ЗйнсШгеб Апа1у§18 апб Везщп Тесйшдие) — технология
структурного анализа и проектирования — широко используется
вомногих областях, начиная с 1973 г. 8АВТ обычно применяется
на ранних стадиях создания системы для минимизации возмож-
ных ошибок, исправление которых на стадии проектировании обхо-
дится гораздо дешевле, чем во время функционирования системы.
8АВТ-методология нашла свое применение в создании программно-
го обеспечения, долгосрочном стратегическом планировании, обу-
чении персонала, автоматизированном производстве, управлении
финансами и т.д.

С помощью методологии 8АВТ на основе технологий аудитор-
ской компании “ВВО Руфаудит” была создана обобщенная схема про-
цесса проведения аудиторской проверки, начиная с преддоговорной
организационной работы и заканчивая представлением аудиторско-
го заключения. Целью данной работы является последовательное
описание аудиторского процесса в максимально доступном и инфор-
мативном изложении. Она может быть использована как для оп-
тимизации аудита, управления им на высоком профессиональном
уровне, так и для ознакомления заинтересованного пользователя-не-
специалиста.

Работа над описанием технологии аудиторского процесса ведется
достаточно давно. Какие же методы могут быть применены? Словес-
ный метод — часто используемый. Однако он всегда несет в себе эле-
мент субъективности, эмоциональности. Составление блок-схем по-
зволяет доступнее представить процесс. Однако по сравнению с
блок-схемами диаграммы функционального моделирования облада-
ют явными преимуществами. Они позволяют показать мотивацию и
ограничивающие факторы, особенности механизма реализации, в них
четко прослеживается итеративность (рис. 7.8).

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

Любой процесс может быть описан с различной степенью детали-
зации. Таким образом, схемы разных уровней являются расшифров-
кой элементов более общих схем и подробно описывают тот или иной
этап. Так, ознакомление с деятельностью клиента является частью
разработки стратегии проведения аудиторской проверки (диаграммы
АО и А2). Кроме того, схема более низкого уровня сохраняет все внеш-
ние связи элемента родительской схемы, который она детализирует
(рис. 7.9).

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

Возможны также обратные связи: при промежуточной оценке ре-
зультатов принимается решение о корректировке направлений про-
верки, что приводит к изменению стратегии аудита и новому планиро-
ванию (диаграммы АО и АЗ) — рис. 7.10.
Рис. 7.8. Проведение аудиторской проверки
Рис. 7.9. Стратегия аудиторской проверки
Рис. 7.10. Проверка клиента
Стрелки (дуги) могут разветвляться и соединяться. Например, ес-
ли весь аудиторский процесс определяют специалисты аудиторской
компании, то конкретный этап преддоговорной работы осуществляет
партнер. Соединение дуг подчеркивает общий результат.

Выводы. Анализируя построенные схемы и детализируя их в
соответствии с текущими задачами, есть возможность структуриро-
вать весь процесс аудиторской проверки, составить план работы для
каждого специалиста, привязать каждый этап к временным ограниче-
ниям. Но самое главное, — структура и цели аудиторского процесса
представляются как единый механизм, что необходимо для понима-
ния конкретных задач каждого аудитора.
ПРИЛОЖЕНИЯ

П1 Семейство стандартов ЮЕЕ

Применяемые в СА8Е-средствах разные методики и модели опи-
сывают различные свойства систем, важные, например, с точки зре-
ния их автоматизации, а также позволяющие количественно оценить
параметры проектов. Следует отметить, что спектр свойств систем
различного назначения очень широк, и не все они к настоящему вре-
мени отражены в адекватных моделях. В то же время для класса
информационных систем организационного типа (Мапа§етеп1
1пГогтайоп 8у§1еш8 — М18) адекватные модели разработаны и под-
держиваются соответствующими средствами автоматизации.

Взаимная совокупность методик и моделей концептуального про-
ектирования ГОЕР (1гйе§га1ес1 ЭЕРтШоп) разработана в США по про-
грамме ЫШ^гаШб СошрЩег-АМес! МапиГасШпп§. В настоящее время
имеются методики функционального, информационного и поведенче-
ского моделирования и проектирования, в которые входят ГОЕГ-моде-
ли, приведенные ниже.

Название	Назначение
ГОЕРО	Функциональное моделирование Рипсйоп МобеПп§ МеЙюб
ГОЕР1 и ГОЕР IX	Информационное моделирование ТпГогшайоп апб Эа1а Мобе1т§ МеШоб
ГОЕР2	Поведенческое моделирование 81ти1айоп Мобе1т§ Мейюб
ГОЕРЗ	Моделирование деятельности  Ргосе§8 Р1о\у апб 0Ъ]ес181а1е Везспрйоп СарШге Мейюб
ГОЕР4	Объектно-ориентированное проектирование ОЬ]ес1-опеп1еб Ве81§п Ме11юб
ГОЕР5	Систематизация объектов приложения ОШо1о§у Эезспрйоп СарШге Мейюб
ГОЕР6	Использование рационального опыта проектирования Эе81§п Кабопа! СарШге Мейюб
ГОЕР8	Взаимодействие человека и системы Нитап-8у81еш ТШегасйоп Вс81§п
ГОЕР9	Учет условий и ограничений

ВизтезБ СопзТгат! В18соуегу

ЮЕР14	Моделирование вычислительных сетей

ХеЪуогк резцр

П)ЕГ0 реализует методику функционального моделирования
сложных систем. Наиболее известной реализацией ГОЕРО является
методология 8 АВТ (ЗйпсШгеб Апа1у818 апб Пе81§п Тесйтцие), предло-
женная в 1973 г. Д. Россом и впоследствии ставшая основой стандарта
ГОЕРО. Эта методика рекомендуется для начальных стадий проекти-
рования сложных искусственных систем управления, производства,
бизнеса, включающих людей, оборудование, программное обеспече-
ние.

ГОЕГ1Х иП)ЕГ1 реализуют методики инфологического проекти-
рования баз данных. В ГОЕР1Х имеется ясный графический язык для
описания объектов и отношений в приложениях, так называемый язык
диаграмм “сущность-связь” (ЕЮ — Епй1у-Ке1аНоп8 Вха^гашз) Разра-
ботка информационной модели по ГОЕР1Х выполняется в несколько
этапов:

•	выясняются цели проекта, составляется план сбора информации,
при этом обычно исходные положения для информационной мо-
дели следуют из ГОЕРО-модели;

•	выявляются и определяются основные сущности — элементы баг
зы данных, в которых будут храниться данные системы;

•	выявляются и определяются основные отношения, результаты
представляются графически в виде так называемых ЕК-диаграмм;

•	детализируются нестандартные отношения, определяются ключе-
вые атрибуты сущностей. Детализация отношений заключается в
замене связей “многие ко многим” на связи “многие к одному” и
“один ко многим”;

•	определяются атрибуты сущностей.

ГОЕГ2 и ГОЕГЗ реализуют поведенческое моделирование. Если
методика ГОЕРО связана с функциональными аспектами и позволяет
отвечать на вопрос: “Что делает система?”, то в этих методиках дета-
лизируется ответ: “Как система это делает”. В основе поведенческого
моделирования лежат модели и методы имитационного моделирова-
ния систем массового обслуживания, сети Петри, возможно примене-
ние модели конечного автомата, описывающей поведение системы
как последовательности смен состояний.

Перечисленные методики относятся к так называемым структур-
ным методам.
ГОЕЕ4 реализует объектно-ориентированный анализ больших
систем. Он предоставляет пользователю графический язык для изо-
бражения классов, диаграмм наследования, таксономии методов.

ГОЕЕ5 направлен на представление онтологической информации
приложения в удобном для пользователя виде. Для этого используют-
ся символические обозначения (дескрипторы) объектов, их ассоциа-
ций, ситуаций и схемный язык описания отношений классификации,
“часть-целое”, перехода и т. п. В методике имеются правила связы-
вания объектов (термов) в предложения и аксиомы интерпретации
термов.

ЮЕГ6 направлен на сохранение рационального опыта проектиро-
вания информационных систем, что способствует предотвращению
структурных ошибок.

ЮЕЕ8 предназначен для проектирования диалогов человека и
технической системы.

ЮЕЕ9 предназначен для анализа имеющихся условий и ограниче-
ний (в том числе физических, юридических, политических) и их влия-
ния на принимаемые решения в процессе реинжиниринга.

ГОЕЕ14 предназначен для представления и анализа данных при
проектировании вычислительных сетей на графическом языке с опи-
санием конфигураций, очередей, сетевых компонентов, требований к
надежности и т.п.
П2

Нотации моделирования

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

Для моделирования всех этих аспектов применяют функциональ-
ные, информационные и поведенческие модели, пересекающиеся
друг с другом.

Функциональная модель системы описывает совокупность вы-
полняемых системой функций, характеризует морфологию системы
(ее построение) — состав подсистем, их взаимосвязи.

Информационная модель отображает отношения между элемен-
тами системы в виде структур данных (состав и взаимосвязи).

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

Сочетания типов моделей образуют стандартные СА8Е-модели.

На рынке программных продуктов имеется много СА8Е-систем
для концептуального проектирования систем, поддерживающих пе-
речисленные модели. Чаще всего речь идет о поддержке мето-
дологии ШЕЕ. В России достаточно широко известны продукты
ВРауш, ЕКлуш, ОСКуш фирмы Р1айпит, Пе81§п/ГОЕГ фирмы Ме1а
ЗоНдуаге, СА8Е-аналитик фирмы “Эйтэкс”, Зйуегап фирм С8А,
РагасН§т Р1и§ и др. Приведем основные характеристики программных
продуктов фирмы Р1айпшп.

Система ВРхуш предназначена для разработки функциональных
моделей по методике ШЕРО.

Система ЕКлут служит для разработки информационных моделей
по методике ШЕГ IX. Имеются средства, обеспечивающие интерфейс
с серверами баз данных (от пользователя скрыто общение с ними
на языке 8()Ь), перевод графических изображений ЕН-диаграмм в
ЗрЬ-формы или в форматы других популярных СУБД. В систему
включены также типичные для СА8Е средства разработки экранных
форм.

Система ОСКуш служит для поддержки объектно-ориентирован-
ных технологий анализа и проектирования систем.
пз

Программное средство
моделирования 0е81дп/ЮЕ1:;

Одной из альтернатив описанному выше пакету Р1а1тит ВРхуш
является программа Ое81§п/ГОЕР, выпущенная в 1995 г. компанией
Ме!а Зойхуаге (США). Вез^п/ЮЕР поддерживает создание моделей в
следующих методологиях (рис. Ш):

•	ГОЕРО;

•	ГОЕР1Х.

Основными преимуществами Ве81§п/ГОЕР перед ВРхуш являются:

•	сравнительная простота программы и соответственно меньший
объем необходимых аппаратных ресурсов;

•	доступность — Ое81§п/ГОЕР распространяется бесплатно и ее
можно без проблем получить из 1п1ете1;

•	поддержка проектирования схем данных по методологии ГОЕР1X

(однако необходимо отметить, что компания Р1айпит предлагает

Рис, Ш. Выбор методологии моделирования в Эе81§п/ГОЕР
С1 Сиз1отег

Мо1ез:

М1 Регзоппе!

Рис. П2. Диаграмма ГОЕРО в Пе81§п/ГОЕР
для аналогичных целей программное средство ЕВлуш, которое об-
ладает бблыпими возможностями по сравнению с Ое81§п/ШЕР и
довольно распространено среди разработчиков баз данных).

По своим возможностям в части поддержки методологии ШЕРО
Пе81§п/ГОЕР во многом идентичен программе Р1айпиш ВРауш. Ре-
зультат моделирования по методологии ШЕРО с использованием
Ое81§п/ШЕР приведен на рис. П2. Программу Ое81§п/ШЕР можно
скопировать из Интернет, обратившись, например, по адресу:
\у\у\у .Шейпе, сот.
П4

Структурный

и объектно-ориентированный
подход. Что лучше

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

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

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

Традиционный подход
к разработке моделей

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

1.	Структурный анализ и структурное проектирование (81гис1игед
Апа1у§18 апд 81гисШгед Пе81§п — 8А/8П) является одной из самых из-
вестных методик разработки информационных систем. В методике
8А/8Э подчеркивается, что система предоставляет своим пользова-
телям одну или несколько функций — так называемый подход функ-
циональной декомпозиции. 8А/8И предлагает набор средств, таких
как диаграммы потоков данных, диаграммы состояний-переходов.
ЕК-диаграммы (на фазе анализа) и структурные схемы (на фазе проек-
тирования).

2.	Методика ШЕЕ (1п1е§га!е<1 сошрШег аИеб тапиГасШпщ*
ОЕНшйоп) была разработана ВВС США в середине 70-х гг. На основе
этой методики министерство обороны США создало федеральный
стандарт обработки информации ШЕГ IX, который обеспечивает
поддержку на нескольких уровнях посредством “модели бизнеса”,
“модели информационной системы” и “модели технологии”. Модели-
рование бизнеса поддерживается ЕК-диаграммами для данных и диа-
граммами потоков данных специального вида, что позволяет иерархи-
чески описывать функции системы.

3.	Методика 8АИТ (81гисШгес1 Апа11818 апд Ое81§п Тесйт§е) ис-
пользует систему обозначений, похожую на диаграммы потоков дан-
ных ШЕЕ, для описания функций и структур данных информацион-
ной системы на основе декомпозиции.

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

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

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

•	линейность выполнения этапов жизненного цикла разработки;

•	четкое разделение данных и процессов их обработки;

•	использование процедурных языков программирования.

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

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

•	трудоемкость внесения изменений;

•	большой объем документации по проекту, затрудняющий про-
граммирование;

•	серьезные ограничения возможностей сборки системы из готовых
компонентов;

•	сложность переноса на другие платформы.
П4.2

Объектно-ориентированный подход
к разработке модели

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

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

Особенности сложных информационных систем

Иерархичность. Описывая характерные черты сложных систем,
Г. Буч особое внимание уделяет их иерархическому характеру. Иерар-
хическое построение таких систем облегчает понимание их челове-
ком, возможности которого, связанные с восприятием информации,
весьма ограничены. Иерархические структуры позволяют рассмат-
ривать только определенный уровень, не вдаваясь в детали реализа-
ции. Для сложной системы целесообразно моделировать два типа
иерархии — типовую и структурную. Типовая иерархия отражает
взаимосвязи “общее-частное”, в объектно-ориентированном подходе
ей соответствует иерархия классов. Структурная иерархия показывает
связи типа “это — часть того”. При объектно-ориентированном под-
ходе ей соответствует иерархия объектов.

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

Применяемые инструментальные средства (ИС) должны поддер-
живать групповую разработку. Для этого современные ИС реализуют-
ся в комплексах с архитектурой “клиент-сервер”. В них должна быть
предусмотрена возможность интеграции результатов работы отделы
ных участников проекта и защиты их от несанкционированного
доступа.

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

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

Использование стандартных СУБД. Современные большие ин-
формационные системы используют в работе стандартные СУБД
в основном реляционного типа, причем реализация таких систем
обычно осуществляется в среде “клиент-сервер”. Интеграция при-
кладной системы с базой данных (БД) ставит перед разработчиками
ряд дополнительных задач. Главной из них является обеспечение пре-
емственности, т.е. возможности использования в разрабатываемом
приложении данных, накопленных в БД. Кроме того, при разработке
приложения в большинстве случаев возникает необходимость проек-
тирования логической структуры новой БД. Для интегрированных
систем с клиент-серверной архитектурой используются специальные
инструментальные средства.

Особенности объектно-ориентированного подхода

Стремление избавиться от недостатков структурного подхода
привело к развитию новых идей, основанных на объектной декомпо-
зиции. Такой подход к разработке программных систем получил
название объектно-ориентированного. В основе его лежат понятия
156
“объект”, “класс”, “инкапсуляция” и “полиморфизм”. В реальном ми-
ре, а точнее, в интересующей разработчика предметной области, в ка-
честве объектов могут рассматриваться конкретные предметы, а так-
же абстрактные или реальные сущности. Например, объектами могут
быть покупатель; фирма, производящая определенные товары; банк;
заказ на поставку. Объект обладает индивидуальностью и поведени-
ем, имеет атрибуты, значения которых определяют его состояние.
Так, конкретный покупатель, делая заказ, может оказаться в состоя-
нии, когда денег на его счете не хватает для оплаты, а его “поведение”
в этом случае заключается в “обращении в банк за кредитом”.

Каждый объект является представителем некоторого класса одно-
типных объектов. Класс определяет общие свойства для всех его объ-
ектов. К таким свойствам относятся:

•	состав и структура данных, описывающих атрибуты класса и соот-

ветствующих объектов;

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

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

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

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

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

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

При таком подходе сложная система описывается наиболее есте-
ственным образом.

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

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

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

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

П4.3

Преимущества и недостатки
объектно-ориентированного подхода

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

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

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

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

Повторное использование программных компонентов. Разраба-
тываемые в рамках некоторого приложения классы обычно отражают
типовые решения, поэтому их использование возможно и в других
приложениях. Возможность повторного использования программных
компонентов — одна из самых привлекательных черт объектно-ори-
ентированного подхода. Библиотеки классов, отражающие опыт в оп-
ределенной области, позволяют значительно снизить объем програм-
160
мирования при разработке новых приложений. При наличии развитых
библиотек классов проектирование и программирование новых при-
ложений будет в основном сводиться к сборке системы из готовых
компонентов.

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

•	осознавать выгоды такого подхода;

•	знать, какие части задачи могут быть решены с применением су-
ществующих программных средств;

•	заниматься поиском подходящих для повторного использования
программ;

•	стремиться найти такие программы;

•	использовать их даже в том случае, если они лишь частично совпа-
дают с тем, что программист написал бы сам.

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

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

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

1 1~1500

161
Недостатки объектно-ориентированного подхода

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

Недостатки самого объектно-ориентированного подхода лежат в
области программирования. Рассмотрим основные из них.

Динамическое связывание, предполагающее поиск метода в клас-
се, которому принадлежит получающий сообщение объект, приводит
к тому, что обращение к методу занимает в 1,75-2,5 раза больше вре-
мени, чем к обычной подпрограмме. Это, конечно, замедляет работу
приложения. Однако, как указывает Г. Буч, динамическое связыва-
ние при использовании строго типизированных языков применяется
примерно в 20% случаев вызовов методов. В результате снижаются
непроизводительные потери времени. В приложениях, где такие по-
тери критичны, приходится прибегать к специальным программист-
ским приемам.

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

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

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

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

Реинжиниринг:
не автоматизируйте —
уничтожайте

В данном приложении приводится перевод статьи одного из ос-
новоположников реинжиниринга бизнеса М. Хаммера (Кееп^теепп^
УУогк: Ооп’1 Аи1ота1е, ОЫИега1е Ъу Мгскае1 Наттег / НагуагВ
Визтезз Веугедк, 1990), одним из первых затронувших эту про-
блему. (Майкл Хаммер — президент Наттег апс1 Сотрапу
(ууту.йаттегапдсо.сот), консалтинговой фирмы, работающей в
области информационных технологий, расположенной в г. Кем-
бридж, штат Массачусетс).

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

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

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

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

В каждой компании есть великое множество неписаных правил:
“решения о выдаче кредита принимает кредитный отдел”, “для каче-
ственного обслуживания клиентов необходим локальный склад”,
“формы следует заполнять полностью и по порядку”. Цель реинжи-
ниринга— порвать со старыми правилами организации и ведения биз-
неса. Реинжиниринг включает в себя выявление этих правил и отказ
от некоторых из них в пользу новых способов выполнения работы.
Вновь разработанные процессы обусловят появление соответствую-
щих новых правил. Только так можно достичь значительного повы-
шения производительности.

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

Что сделали Гогд и МВЬ

Японские конкуренты и молодые предприимчивые компании ежо-
дневно показывают пример того, что возможна значительно более вы-
сокая производительность процессов. Они разрабатывают продукты
вдвое быстрее, используют активы в восемь раз эффективнее, отвеча-
ют клиентам в десять раз скорее. Некоторые крупные давно сущест-
вующие компании также показывают пример того, что можно сдо-
лать. Компании Рогд Мо1ог§ и МиШа1 Вепей! 1лГе Тпзигапсе провели
реинжиниринг процессов и в результате достигли конкурентного пре-
имущества. Рон! подверг реинжинирингу управление кредиторской
задолженностью, а Ми1иа1 Вепей! 1лГе — обработку заявлений на при-
обретение страховых полисов.

В начале 80-х гг., когда американская автомобильная промышлен-
ность находилась в депрессии, руководство компании Рогс1 решило ре-
организовать среди прочих и отдел кредиторской задолженности в
поисках возможностей сокращения издержек. Кредиторской задол-
женностью только в Северной Америке занимались более 500 чело-
век. Руководство полагало, что путем рационализации процессов и ус-
тановки новых компьютерных систем можно будет сократить число
сотрудников примерно на 20%.

Энтузиазм прошел, как только специалисты Роге! обратили внима-
ние на опыт компании Махба. В то время как руководство Рогб пыта-
лось уменьшить численность сотрудников до 400, отдел кредиторской
задолженности в Махба состоял из пяти человек. Разница в цифрах
была потрясающей. Даже принимая во внимание меньший размер
Махба, выходило, что отдел кредиторской задолженности в Рогб при-
мерно в пять раз больше, чем нужно. Специалисты Рогб понимали, что
дело тут не в производственной гимнастике, не в пении гимна компа-
нии и не в низких учетных ставках в Японии.

Руководство Рогб переформулировало задачу: отдел кредитор-
ской задолженности должен справляться со своими обязанностями
при уменьшении числа служащих не на сотню, а на несколько сотен.
Затем начались мероприятия по ее осуществлению. Прежде всего, ру-
ководство проанализировало существующую систему. Когда отдел
закупок выписывал заказ, его копия направлялась в отдел кредитора
ской задолженности. Позднее, когда отдел входного контроля полу-
чал материалы, копия документа о получении также направлялась в
отдел кредиторской задолженности. Тем временем сам отдел креди-
торской задолженности получал счет от поставщика. Задача отдела
кредиторской задолженности, таким образом, состояла в том, чтобы
сличить заказ, документ о получении и счет. Если документы соответ-
ствовали друг другу, отдел осуществлял платеж.

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

Один из способов улучшить положение дел — помочь служащему
быстрее выявить причину несоответствия, однако лучший выбор —
вообще предотвратить расхождения. Чтобы этого добиться, в Рогб
ввели “обработку без счетов”. Теперь, когда отдел закупок дает заказ,
информация о нем вводится в базу данных. Копии заказа никому не
рассылаются. Когда товар прибывает на разгрузку, приемщик про-
веряет базу данных, чтобы выяснить, соответствует ли этот товар ка-
кому-либо неисполненному заказу. Если да, производится приемка,
166
сведения о которой также заносятся в базу данных. Если нет, заказ
просто возвращается поставщику.

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

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

Компания МиШа1 Вепей! 1лГе, восемнадцатая по величине фирма,
занимающаяся страхованием жизни, провела реорганизацию процес-
сов обработки заявлений на приобретение страховых полисов. До ре-
организации МВЬ обрабатывала заявления примерно так же, как и
конкуренты. Длительный многоступенчатый процесс включал про-
верку кредитоспособности, котировку, рейтинг, андеррайтинг и т.п.
Заявление проходило 30 этапов обработки в пяти отделах силами 19
человек. В лучшем случае МВЬ обрабатывала заявление за 24 часа,
однако в большинстве случаев на это уходило от 5 до 25 дней. Боль-
шая часть времени тратилась на передачу информации из одного отде-
ла в другой (другая страховая компания как-то оценила среднее время
обработки заявления в 22 дня, из которых фактическая работа занима-
ла всего 17 минут).

Жесткий последовательный процесс, принятый в МВЬ, имел мно-
жество осложнений. Например, когда клиент хотел получить деньги
по старому полису в связи с истечением срока и приобрести новый, от-
дел текущих операций должен был запросить у казначейского отдела
чек, получить по которому деньги мог бы только сотрудник МВЬ.
Этот чек вместе с необходимыми документами затем поступал в отдел
новых операций.

Для улучшения обслуживания клиентов президент МВЬ потребо-
вал повысить производительность на 60%. Было очевидно, что для
достижения этой цели нужны были кардинальные технологические
изменения. Рабочая группа установила, что с помощью баз данных и
вычислительных сетей можно донести значительный объем информаг
ции до отдельного сотрудника, а с помощью экспертных систем мож-
но помочь в принятии обоснованных решений людям с ограниченным
опытом. Применение этих принципов привело к появлению нового
процесса обработки заявлений, который очень сильно изменил всю
организацию и имел очень мало общего со старым.

Компания МВЬ отказалась от старого штатного расписания и
организационной структуры и создала новую должность — управ-
ляющий делом (сазе шапа§ег). Управляющие делами несут пол-
ную ответственность за заявление с момента, когда оно получено,
домомента, когда выпускается полис. В отличие от клерков, раз за
разом исполняющих одну и ту же задачу под бдительным взором
начальника, управляющие делами работают автономно. Больше не
существует передачи запросов клиентов от одного сотрудника к
другому.

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

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

Сущность реинжиниринга

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

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

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

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

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

При проведении реинжиниринга необходимо освободиться от ус-
таревших бизнес-процессов и принципов их разработки и создать но-
вые. В Гоп! было старое правило: “мы платим, когда получаем счет”.
Никто никогда не устанавливал это правило и не фиксировал его су-
ществование, однако именно оно определяло процесс работы с креди-
торской задолженностью. Реинжиниринг выявил это правило и заме-
нил его новым: “мы платим, когда получаем товар”.

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

Один из способов добиться кросс-функциональности — создать
рабочую группу из представителей всех функциональных подразделе-
ний, участвующих в реорганизуемом процессе или зависящих от его
результатов. Рабочая группа должна критически проанализировать
существующий процесс и точно выяснить, каков его желательный ре-
зультат. Неважно, что происходит с формой 73В в ее “путешествиях”
по компании; важно понять, для чего вообще нужна форма 73В. Вме-
170
сто поиска возможностей для улучшения существующего процесса
группа должна определить, какие его этапы реально добавляют стои-
мость, и найти новые способы достижения результата.

Группа реинжиниринга должна без конца задавать одни и те же
вопросы: “Зачем?”, “А что, если?”, “Зачем нужна подпись руководи-
теля на бланке заявки?”, “Это механизм контроля или точка принятия
решения?”, “А что, если руководитель подписывает только заявки на
сумму свыше 500 долларов?”, “А что, если он или она вообще их не
просматривает?”. Процесс решения этих вопросов может четко отде-
лить необходимые части процесса от поверхностных деталей. Регио-
нальные отделения одной из страховых компаний на Восточном
побережье США в течение долгого времени готовили регулярную от-
четность для отправки в головное отделение. Никто даже не знал, что
эти отчеты просто подшивались в папки и никогда не использовались.
Процесс просуществовал дольше, чем обстоятельства, которые вызвав
ли его к жизни. Реинжиниринг должен выявлять такие ситуации.

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

Принципы реинжиниринга

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

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

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

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

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

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

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

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

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

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

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

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

Считайте географически разнесенные ресурсы централизован-
ными. Конфликт между централизацией и децентрализацией давно
уже стал классическим. Децентрализация любого ресурса (людей,
оборудования, складских запасов) позволяет организовать лучшее об-
служивание тех, кто использует этот ресурс, не взирая на его малую
эффективность. Теперь компаниям уже не нужно искать золотую се-
редину. Они могут воспользоваться базами данных, телекоммуника-
ционными сетями и стандартными системами обработки, чтобы со-
вместить выгоды централизованного ресурса (масштаб, координация)
с выгодами гибкости и качества обслуживания.
В компании Не\у1е11-Раскагс1, например, в каждом из более чем 50
производственных подразделений был свой отдел закупок. Такое по-
ложение дел обеспечивало быструю реакцию на возникновение по-
требностей и высокое качество обслуживания заводов, однако не
давало экономии, в особенности на количественных скидках. В ком-
пании Нем4е11-Раскаг(1 решили проблему, оставив отделы закупок в
подразделениях и создав головное подразделение для их координат
ции. У каждого отдела закупок есть доступ к базе данных общего
пользования, где хранятся данные о поставщиках и качестве их по-
ставок, и право самостоятельно размещать заказы. Головной отдел
закупок администрирует базу данных и использует ее при перегово-
рах от лица компании в целом и для наблюдения за результатами рабо-
ты других отделов закупок. В результате число поставок без опозда-
ния выросло на 150%, время подготовки производства сократилось на
50%, количество неисправностей уменьшилось на 75%, а стоимость
покупных изделий значительно упала.

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

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

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

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

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

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

Когда компания МиШа1 ВепеГИ ЫЕе реорганизовала процесс обра-
ботки заявлений, она не только сократила линейную последователь-
ность, но и устранила потребность в руководителях. Эти два вида
сокращений — вертикальное и горизонтальное — часто сопутствуют
друг другу. Сам факт того, что работник видит только одну часть про-
цесса, означает потребность в руководителе с более широким углом
зрения. Управляющие делами в МВЬ ведут процесс от начала до кон-
ца, что уменьшает потребность в традиционном руководстве. Роль ру-
ководителя меняется — из контролера и начальника он становится по-
мощником и наставником.

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

Думайте масштабно

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

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

Весьма значительные изменения произошли и в компании МиШа1
Вепей! ЫГе. Ввести должность управляющего делом в существую-
щую штатную структуру было невозможно — ответственности было
много, а подчиненности никакой. МВЬ пришлось изменить штатную
структуру и политику вознаграждения сотрудников и, кроме того, вы-
работать такую схему, по которой люди, исполняющие работу, вос-
принимались как более важные, чем те, кто руководил работой. Схе-
12-1500	177
мы продвижения по службе, программы подбора и подготовки
кадров — эти и многие другие системы руководства были пересмотре-
ны, чтобы поддержать новую конструкцию процесса.

Размах этих изменений показывает, что для успешного реинжини-
ринга необходим один фактор — высшее руководство, наделенное во-
ображением. Никому в организации не нужен реинжиниринг. Это
запутанный и сложный процесс, влияющий на все, к чему люди уже
давно привыкли. Только если поддержка высшего руководства “про-
живет” дольше, чем скептицизм, люди воспримут реинжиниринг
всерьез. Некий шутник в одной электронной компании однажды заме-
тил: “Каждые несколько месяцев у нашего руководства меняется ре-
лигия. Сначала это было качество, потом — обслуживание, потом —
упрощение организации. Мы просто затаив дыхание ждем, когда это
пройдет и все станет так, как было”. Приверженность идее и постоян-
ство, возможно, с легким налетом фанатизма, необходимы, чтобы
привлечь на свою сторону тех, кого устраивает существующее поло-
жение вещей.

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

У нас есть все необходимые для работы инструменты. Информа-
ционная технология предлагает множество способов реорганизации
производства. Однако наши решения относительно технологий долж-
ны диктоваться нам, в том числе и воображением. Мы должны иметь
смелость сократить на 78 дней 80-дневный производственный цикл,
уменьшить общехозяйственные расходы на 75% и устранить появ-
ление 80% ошибок. Эти цели нельзя считать недостижимыми. Если
у руководства есть фантазия, реинжиниринг даст возможность ее
осуществить.
П6

Темы для самостоятельной
работы

В качестве предметной области для тренировки навыков модели-
рования бизнес-процессов средствами технологии ГОЕР предлагается
популярная в настоящее время ситуация — организация работы обра-
зовательных учреждений в различных вариантах — государственных
и негосударственных, с филиалами и без на различных этапах их жиз-
ненного цикла: «набор — обучение — вручение дипломов».

Ситуация богата вариантами: очное и заочное образование, вечер-
няя и дневная формы обучения, различный статус — с образованием
юридического лица для филиалов или без образования.

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

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

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

В предлагаемой ниже таблице представлено 27 таких тем (пример-
но на две академические группы обучаемых), имеющих одинаковые, в
данном случае, исходные задания:

построить функциональные модели процессов (согласно вы-
бранной строке таблицы заданий), включающие «контекст-
ную» и «декомпозиционную» диаграммы, по правилам ме-
тодологии ЮЕР-технологий, обсуждаемых в этой книге.
№ темы	Содержание задания	Основные моделируемые функции системы	Точка зрения	Примечания и комментарии
1	Организация работы регионального филиала государственного вуза  Цикл: “набор — обуче- ние — вручение дипло- мов”	Обеспечить филиал всеми видами по- мощи для организации:  -	рекламной кампании;  -	приема вступительных экзаменов;  -	формирования групп  Обеспечить филиал всеми видами учеб- но-методической поддержки:  -	в процессе обучения;  -	в процессе контроля уровня знаний Обеспечить финансовую сторону дея- тельности филиала:  -	оплату труда работников филиала;  -	стипендию студентам;  -	выделение денежных средств для обеспечения повседневной работы (аренда, закупки и пр.)	Ректорат го- ловного вуза	Использовать квалифициро- ванные преподавательские кадры на местах, где и реали- зовать процесс обучения (днев- ная форма)
2	Организация работы регионального филиала государственного вуза Цикл: “набор - обуче- ние - вручение дипло- мов”	Организовать набор студентов, сформи- ровать группы  Обеспечить студентов методическими пособиями, полученными из головного вуза  Проводить зачетные мероприятия  Организовать подготовку и защиту дип- ломов  Подготовить отчеты (включая финансо- вые) для головного вуза и пр.	Директор филиала	Форма обучения — дневная  Учесть возможность исполь- зования преподавательских кадров головного вуза  Выезд преподавателей для чте- ния установочных лекций, кон- сультаций и приема экзаменов в филиал дважды в год
3	Организация процесса обучения в региональ- ном филиале государст- венного вуза  Цикл: “поступление — обучение — подготовка и защита дипломов”	Поступление в вуз  Участие во всем цикле обучения Прохождение зачетных мероприятий Подготовка дипломной работы Защита дипломной работы	Студент	Форма обучения — дневная
4	Организация процесса приема в государствен- ный вуз	Организация рекламной кампании Организация процесса тестирования с учетом возможности поступления в вуз для успешно прошедших тестирование Организация процесса приема вступи- тельных экзаменов (письменных и уст- ных)  Организация процесса зачисления с уче- том необходимости собеседования и возможности апелляций	Ректорат вуза	Учесть возможность дополни- тельного набора
5	Организация процесса поступления в государ- ственный вуз	Поиск подходящего вуза  Организация подготовки (репетиторы, курсы и прочее)  Предварительное тестирование Сдача вступительных экзаменов Прохождение собеседования	Студент	Учесть возможность апелляции и перехода на другой факуль- тет в случае недобора баллов
Продолжение

№ темы	Содержание задания	Основные моделируемые функции системы	Точка зрения	Примечания и комментарии
6	Организация процесса поступления в государственный вуз	Помощь ребенку в поиске подходящего вуза  Помощь в организации репетиторства  Обеспечение питания и отдыха  Организация рабочего места Прочее	Родители	Учесть необходимость кратко- срочного отдыха ребенка в промежутке между экзаменами
7	Организация процесса обучения в вузе	Учебная работа  Выполнение заданий с использованием современных информационных ресурсов Прохождение контрольных мероприятий Подготовка и защита дипломов	Студент	Учесть возможность переэкза- меновки
8	Организация процесса обучения в вузе	Учебная работа  Контроль выдачи и приема заданий Прохождение контрольных мероприятий Подготовка и защита диплома и пр.	Деканат	Учесть возможность переэкза- меновки и отчисления студен- тов
9	Организация подготовки студента к ответственному экзамену	Спланировать подготовку в целом Обеспечить наличие учебно-методичес- ких материалов  Спланировать консультации  Пройти промежуточное тестирование  Сдать экзамен	Студент	Учесть возможность дополни- тельного изучения материала после неудачного тестирова- ния  Учесть возможность переэкза- меновки
10	Организация подготов- ки студента к ответст- венному экзамену	Спланировать подготовку в целом  Обеспечить наличие учебно-методичес- ких материалов  Спланировать консультации  Пройти промежуточное тестирование  Сдать экзамен	Студент	Учесть возможность дополни- тельного изучения материала после неудачного тестирова- ния  Учесть возможность переэкза- меновки
11	Организация подготов- ки студента к ответст- венному экзамену	Спланировать подготовку в целом  Обеспечить наличие учебно-методичес- ких материалов Спланировать консультации Пройти промежуточное тестирование Сдать экзамен	Студент	Учесть возможность дополни- тельного изучения материала после неудачного тестирова- ния  Учесть возможность переэкза- меновки
12	Организация подготов- ки студента к ответст- венному экзамену	Спланировать подготовку в целом  Обеспечить необходимое для студентов наличие учебно-методических мате- риалов  Спланировать консультации преподава- телей  Обеспечить возможность предваритель- ного тестирования знаний  Спланировать сроки сдачи экзамена и возможность переэкзаменовок	Деканат	Учесть возможность дополни- тельного изучения материала после неудачного тестирова- ния  Учесть возможность переэкза- меновки
13	Организация подготов- ки студента к ответст- венному экзамену	Спланировать подготовку  Обеспечить питание  Обеспечить денежными средствами для покупки литературы  Найти репетиторов  Другие мероприятия	Родители	Учесть возможность предо- ставления ребенку короткого отдыха перед ответственным экзаменом с выездом на при- роду
оо	Продолжение

№ темы	Содержание задания	Основные моделируемые функции системы	Точка зрения	Примечания и комментарии
14	Организация подготов- ки студента к ответст- венному экзамену	Спланировать подготовку по своему курсу  Дать обзор курса  Подготовить экзаменационные вопросы и задачи  Обеспечить индивидуальные консуль- тации  Обеспечить возможность предвари- тельного тестирования Подготовиться и принять экзамен Отчитаться перед деканатом	Лектор (веду- щий препода- ватель)	Учесть возможность дополни- тельного экзамена (переэкзаме- новки)  Учесть необходимость подго- товки дополнительных заданий для компьютерного тестирова- ния
15	Организация коммер- ческого дистанционно- го образования на базе регионального предста- вительства, являющего- ся юридическим лицом Форма обучения — дневная  Набор студентов — на местах	Обеспечить представительство всеми видами помощи для организации:  рекламной кампании;  приема вступительных экзаменов;  формирования групп  Обеспечить представительство всеми ви- дами учебно-методической поддержки и контроля:  в процессе обучения;  в процессе контроля уровня знаний Контроль финансовой деятельности представительства в целом и отчислений вузу	Ректорат го- ловного вуза	В процессе обучения исполь- зуются преподавательские кадры вуза  Выезд преподавателей для чте- ния установочных лекций, кон- сультаций и приема экзаменов в филиал предусматривается дважды в год  Оплата за обучение произво- дится через представительство вуза
16	Организация коммер- ческого дистанционно- го образования на базе регионального предста- вительства, не являю- щегося юридическим лицом  Форма обучения — дневная  Набор студентов — на местах	Обеспечить представительство всеми видами помощи для организации: рекламной кампании;  приема вступительных экзаменов;  формирования групп  Обеспечить филиал всеми видами учеб- но-методической поддержки и контроля: в процессе обучения;  в процессе контроля уровня знаний;  Обеспечить прием денежных поступле- ний за обучение  Обеспечить финансовую сторону дея- тельности филиала:  оплату труда работников филиала;  выделение денежных средств для поддержки повседневной работы (аренда, закупки и пр.)	Ректорат го- ловного вуза	В процессе обучения использу- ются преподавательские кадры вуза  Выезд преподавателей для чте- ния установочных лекций, кон- сультаций и приема экзаменов в филиал предусматривается дважды в год  Оплата — через вуз
17	Организация коммер- ческого дистанционно- го образования на базе регионального предста- вительства, являющего- ся юридическим лицом Форма обучения — дневная  Набор студентов — на местах	Обеспечить представительство всеми ви- дами помощи для организации:  рекламной кампании;  приема вступительных экзаменов;  формирования групп  Обеспечивать представительство всеми видами учебно-методической поддержки и контроля:  в процессе обучения;  в процессе контроля уровня знаний Контроль финансовой деятельности представительства в целом и отчислений вузу	Ректорат го- ловного вуза	В процессе обучения исполь- зуются региональные препода- вательские кадры  Оплата обучения производится через представительство вуза
00
о\

Продолжение

№ темы	Содержание задания	Основные моделируемые функции системы	Точка зрения	Примечания и комментарии
18	Организация коммер- ческого дистанционно- го образования на базе регионального предста- вительства, не являю- щегося юридическим лицом  Форма обучения — дневная  Набор студентов — на местах	Обеспечить представительство всеми ви- дами помощи для организации:  рекламной кампании;  приема вступительных экзаменов;  формирования групп  Обеспечить филиал всеми видами учеб- но-методической поддержки и контроля:  в процессе обучения;  в процессе контроля уровня знаний Обеспечить прием денежных поступ- лений за обучение  Обеспечить финансовую сторону дея- тельности филиала:  оплату труда работников филиала;  выделение денежных средств для поддержки повседневной работы  (аренда, закупки и пр.)	Ректорат го- ловного вуза	В процессе обучения использу- ются региональные препода- вательские кадры Оплата — через вуз
19	Организация коммер- ческого дистанционно- го образования на базе регионального предста- вительства, являющего- ся юридическим лицом  Форма обучения — дневная  Набор студентов — на местах	На основе материалов центра обеспечить организацию:  рекламной кампании;  приема вступительных экзаменов;  формирования групп  Обеспечить контингент всеми видами учебно-методической поддержки и конт- роля:  в процессе обучения;  в процессе контроля уровня знаний Обеспечить прием денежных поступле- ний за обучение, распределение их между центром и региональными представи- тельствами, финансовую отчетность	Ответствен- ный регио- нальный пред- ставитель	В процессе обучения исполь- зуются региональные препода- вательские кадры  Оплата обучения производится через представительство вуза
20	Организация коммер- ческого дистанционно- го образования на базе регионального предста- вительства, не являю- щегося юридическим лицом  Форма обучения — дневная  Набор студентов — на местах	На основе материалов центра обеспечить организацию:  рекламной кампании;  приема вступительных экзаменов;  формирования групп  Обеспечить контингент всеми видами учебно-методической поддержки и контроля:  в процессе обучения;  в процессе контроля уровня знаний Обеспечить отчетность центру по всем видам учебной и финансовой деятель- ности	Ответствен- ный регио- нальный пред- ставитель	В процессе обучения использу- ются региональные преподава- тельские кадры  Оплата — через вуз
21	Организация коммер- ческого дистанционно- го образования на базе регионального предста- вительства, не являю- щегося юридическим лицом  Форма обучения — дневная  Набор студентов — на местах	На основе материалов центра обеспечить организацию:  рекламной кампании;  приема вступительных экзаменов;  формирования групп  Обеспечивать контингент всеми видами учебно-методической поддержки и конт- роля:  в процессе обучения;  в процессе контроля уровня знаний Обеспечить прием денежных поступле- ний за обучение, распределение их между центром и региональными предста- вительствами, финансовую отчетность	Ответствен- ный регио- нальный пред- ставитель	В процессе обучения использу- ются преподавательские кадры вуза  Выезд преподавателей для чте- ния установочных лекций, кон- сультаций и приема экзаменов в филиал предусматривается дважды в год  Оплата обучения производится через представительство вуза
ОО
00

Продолжение

№ темы	Содержание задания	Основные моделируемые функции системы	Точка зрения	Примечания и комментарии
22	Организация коммер- ческого дистанционно- го образования на базе регионального предста- вительства, не являю- щегося юридическим лицом  Форма обучения — дневная  Набор студентов — на местах	На основе материалов центра обеспечить организацию:  рекламной кампании;  приема вступительных экзаменов;  формирования групп  Обеспечить контингент всеми видами учебно-методической поддержки и конт- роля:  в процессе обучения;  в процессе контроля уровня знаний Обеспечить отчетность центру по всем видам учебной и финансовой деятель- ности	Ответствен- ный регио- нальный пред- ставитель	В процессе обучения использу- ются преподавательские кадры вуза  Выезд преподавателей д ля чте- ния установочных лекций, кон- сультаций и приема экзаменов в филиал предусматривается дважды в год  Оплата — через вуз
23	Организация коммер- ческого дистанционно- го образования на базе регионального предста- вительства, являющего- ся юридическим лицом Форма обучения — дневная  Набор студентов — на местах	Спланировать процесс поступления  Подать документы и сдать вступитель- ные экзамены  Оплатить через представительство обу- чение  Получить реквизиты студента  Пройти цикл обучения, сдать экзамены и получить право подготовить и защитить диплом  Успешно защитить дипломную работу и получить диплом	Студент	В процессе обучения использу- ются региональные преподава- тельские кадры  Оплата обучения производится через представительство вуза Возможны неудачи во время сессий. Учесть пересдачи
24	Организация коммерчес- кого дистанционного об- разования на базе регио- нального представитель- ства, не являющегося юридическим лицом Форма обучения — дневная  Набор студентов — на местах	Спланировать процесс поступления Подать документы и сдать вступитель- ные экзамены  Оплатить через банк вуза обучение  Получить реквизиты студента  Пройти цикл обучения, сдать экзамены и получить право подготовить и защитить диплом  Успешно защитить дипломную работу и получить диплом	Студент	В процессе обучения использу- ются преподавательские кадры вуза  Выезд преподавателей для чте- ния установочных лекций, кон- сультаций и приема экзаменов в филиал предусматривается дважды в год  Оплата — через вуз
25	Организация компьюте- ризированного рабоче- го места (1п1егпе1) на дому	Спланировать процесс  Поиск фирм для покупки оборудования, подходящего по производительности и стоимости  Поиск реквизитов для размещения обо- рудования  Загрузка, проверка и настройка програм- много обеспечения  Организация подключения к сети 1п1ете1	Студент	Учесть возможность частич- ных неудач на каждом этапе
26	Поиск информации в 1п1егпе1 при подготовке реферата по экономи- ческим дисциплинам	Составление плана поиска, накопления результатов, их обработки  Консультации у преподавателя  Оформление результатов работы  Защита работы	Студент	Учесть возможность частич- ных неудач на каждом этапе
ю	Продолжение

№ темы	Содержание задания	Основные моделируемые функции системы	Точка зрения	Примечания и комментарии
27	Подготовка выступле- ния на студенческой конференции “Неделя науки”	Планирование  Выбор темы с преподавателем  Работа с первоисточниками информации  Оформление работы  Выступление	Студент	Учесть необходимость неодно- кратных консультаций с науч- ным руководителем темы

Задания:

1.	С использованием ЮЕРО-технологии построить функциональные модели процессов, указанных в таблице
(контекстные диаграммы).

2.	Представить к диаграмме: список данных, список функций, глоссарий, правовое обеспечение исследуемого процесса
(выдержки из законодательных актов с указанием их источников).
ГЛОССАРИЙ

Анализ функций— методика анализа исполнения функций в компании.

Аудит—согласно определению комитета Американской бухгалтерской ассоциа-
ции “аудит — это системный процесс получения и оценки объективных дан-
ных об экономических действиях и событиях, устанавливающий уровень их
соответствия определенному критерию и представляющий результаты заин-
тересованному пользователю”.

Бизнес-процесс— модель преобразования сущностей типа «вход-выход», пони-
маемая как работа по реализации приписываемой функции.

Бизнес-процесс-реинжиниринг (БПР) — методика кардинальной реструктури-
зации бизнес-процессов.

Бизнес-функция (Вшипезд-Гипсйоп) — термин, используемый для описания
того, что в процессе функционирования организации выполняют те или иные
действия. ГОЕРО обеспечивает поддержку моделирования бизнес-функций
посредством нотации, использующей действия и стрелки.

Вертикальное сжатие бизнес-процессов—объединение нескольких разноуров-
невых рабочих процедур в одну.

Внешняя среда — существенно важные объекты вне системы.

Вход (1при<: агпну)— стрелка, входящая в левую часть блока диаграммы ГОЕРО.
Вход обозначает сырье или информацию, потребляемые действием,
обозначенным данным блоком, и которые необходимы для получения
выхода.

Выход (Ои1ри€ агнцу) — стрелка, выходящая из правой стороны блока
диаграммы ГОЕРО. Выход обозначает изделия или информацию, полученные
в результате выполнения действия, обозначенного блоком.

Горизонтальное сжатие бизнес-процессов — объединение нескольких одно-
уровневых рабочих процедур в одну.

Границы моделирования (Зсоре) — ширина охвата и глубина детализации при
описании моделируемого набора объектов.

Действие (Асйуйу) — описание набора мероприятий, имеющего целью
обработку или передачу либо данных, либо ресурсов (например, “обработать
заказ” или “провести технический контроль”). Модели ГОЕРО выделяют
неэффективные действия (у которых отсутствует управление или выход) и,
таким образом, способствуют работе по проведению реинжиниринга
бизнес-процессов. Действие в модели ГОЕЕЗ, называемое также единицей
работы, описывает обработку, мероприятие, принятие решения или другую
процедуру, выполняемую системой или организацией. Действия в
диаграммах ЭРП отображают обработку или передачу данных.

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

Изменения модели бизнес-процессов — сокращения, добавления, изменения
образующих бизнес-процессы работ, изменение сетевой модели образующих
бизнес-процессы работ, перераспределение ответственности звеньев за ис-
полнение бизнес-процессов.

Команда процесса — выделенная группа менеджеров и специалистов, ответст-
венная за реализацию процесса.

Количественные модели бизнес-инжиниринга — количественные описания
инжиниринговых моделей компании.

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

Логистика — 1. Отрасль науки — совокупность самостоятельной методологии,
теории, методов и способов оптимизации всех видов потоков (физических,
информационных, энергетических и т.д.),'сопровождающих экономические,
социальные и коммуникативные процессы в сфере создания, воспроизводст-
ва и потребления товаров и услуг в условиях функционирования и развития
рыночных отношений. 2. Теория планирования, управления и контроля про-
цессов движения материальных, трудовых, энергетических и информацион-
ных потоков в человеко-машинных системах. 3. Совокупность теории и прак-
тики анализа и оптимизации перемещения продукта и сопровождающих его
потоков в сфере производства и обращения товара.

Менеджмент— 1. Совокупность функций, необходимых для организации любой
деятельности на том или ином иерархическом уровне рыночной экономики.
2. Форма описания, представления деятельности и роли отдельного лица или
группы лиц, которые ставят и контролируют задачи по управлению процесса-
ми организации, планирования, координации и контроля в той или иной об-
ласти воспроизводства или экономики в целом. 3. Наука управления рыноч-
ной экономикой, включающая теорию систем, теорию решений, социальную
психологию, социологию, психологию, математику и др. 4. Руководство фир-
мы, возглавляющее процесс организации и функционирования производства
и ответственное за результаты деятельности и выживаемость фирмы в усло-
виях конкурентной борьбы. 5. Управление экономикой, производством, пер-
соналом, ресурсами и т.д. в условиях рынка.

Метаструктура— устойчивые связи различающихся структур.

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

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

Организационная реструктуризация — изменение организационной модели
компании.

Подсистема — часть системы, образованная компонентами.

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

Проектирование функциональной модели — методика определения иерархи-
ческого упорядочивания необходимых функций компании.

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

Реструктуризация — изменение структуры компании.

Реструктуризация бизнес-процессов — изменение модели бизнес-процессов
компании.

Стратегия — модель целей и способов их реализации.

Стратегический анализ — модель представления и анализа информации для
принятия стратегических решений.

Стрелка (Агго^у) — стрелка на диаграмме ГОЕРО представляет вход, управление,
выход или механизм выполнения действия. На диаграммах ГОЕРЗ стрелки
обозначают порядок выполнения действий (стрелки, нарисованные
сплошной линией), отношения (стрелки, нарисованные прерывистой линией)
или поток (двухконечные стрелки, нарисованные сплошной линией). В ПРО
стрелка обозначает поток данных между действиями, хранилищами данных и
внешними ссылками.

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

Структура процессов — отражение компонентов процессов и устойчивых свя-
зей между ними.

Функция— обособленный устойчивый вид деятельности.

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

Функциональная структура— отражение функций и устойчивых связей между
ними.

Функциональные стратегии—документированные цели в функциональной об-
ласти (продукты, бизнес-процессы, менеджмент, ресурсы) и систематизиро-
ванные суждения о способах их достижения.

Управление (Соп1го1 агго^у) — ограничение для блока диаграммы ГОЕРО,
определяющее, как, когда и при каких условиях выполняется действие,
обозначенное этим блоком. Это правила, стандарты, законы, должностные
инструкции и т.п. Стрелки, обозначающие управление, входят в блок
диаграммы ГОЕЕО сверху.

Управленческий анализ — сложившийся систематизированный набор методик
представления и анализа информации для принятия управленческих реше-
ний (маркетинговый анализ, финансово-экономический анализ, операцион-
ный анализ и т.д.).

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

ЮЕЕЗ — стандарт моделирования бизнес-процессов, поддерживающий
графическое описание непосредственного механизма функционирования
системы или организации. ГОЕЕЗ содержит правила разработки двух видов
сетевых диаграмм: диаграмм потоков для бизнес-процессов; диаграмм
изменения состояния объекта.

Отваге — методики и программное обеспечение для описания и проектирова-
ния структур.

УУогкДоту — методики и программное обеспечение для описания и проектирова-
ния бизнес-процессов.
РЕКОМЕНДУЕМАЯ
ЛИТЕРАТУРА

Основная литература

1.	Вендров А.М. СА8Е-технологии — современные методы и
средства проектирования информационных систем. - М.: Финансы и
статистика, 1998.

Введение в проектирование информационных систем с помощью современ-
ных методов и средств. Методология проектирования, структурный и объект-
но-ориентированный подход. Характеристики СА8Е-средств. Может служить хо-
рошим методическим пособием.

2.	Ефимов В.Н. Опыт использования функционального модели-
рования при разработке банковских систем // Банковские техноло-
гии. - 1998. - С. 64-68.

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

3.	Дэвид А. Марка и Клемент МакГоуэн. 8АВТ-методология
структурного анализа и проектирования. - М.: Метатехнология, 1993.

Классический труд, в котором изложены основные концепции методологии
8АЭТ-1ЭЕЕ (81гис1игес1 Апа1у818 апб Пе81§п ТесЬтцие). Подробно описан процесс
построения функциональных моделей процессов. Множество примеров, взятых
из реальных аналитических проектов, иллюстрируют различные способы приме-
нения 8АЭТ в широком спектре областей. Представляет большую ценность как
учебно-методическое пособие для начинающих изучать предмет, не потерявшее
своей ценности за прошедшее с момента выхода время.

4.	Калянов Г.Н. СА8Е. Структурный системный анализ
(автоматизация и применение).- М.: Лори, 1996.

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

5.	Калянов Г.Н. Консалтинг при автоматизации предпри-
ятий. - М.: СИНТЕГ, 1997.

. Обобщение опыта разработки консалтинговых проектов, выполненных для
банков, промышленных и торговых предприятий, офисных учреждений и т.д.
Подробно рассматривается методологическая и инструментальная база выполне-
ния консалтинговых проектов (СА8Е-технологии), анализируются подходы к ре-
организации деятельности предприятий, предлагается методология выполнения
консалтинговых проектов, апробированная на крупнейших российских предпри-
ятиях. Весьма полезна как учебное пособие для “продвинутых” слушателей.

6.	Клейменова М.С. Системный подход к проектированию слож-
ных систем И Журнал д-ра Добба, 1993. - № 1. - С. 9—14.

Весьма удачное с точки зрения подачи материала пособие для “непродвину-
тых” пользователей, в котором представлены фрагменты истории структурного
подхода, а также основные моменты (с примерами) 8АЭТ-П)ЕГ-технологии.

7.	Кукушкин А.А., Овсянников А.А. СА8Е-моделирование ин-
формационных процессов. - Орел: ВИПС, 1998.

Пособие по курсовому проектированию для слушателей военных учрежде-
ний, включающее все необходимое для исполнения проекта: требования к проек-
ту, общие положения по СА8Е-моделированию, методику построения модели,
методические примеры, а также описание основных функций поддерживающего
технологию моделирования программного продукта ВР\ут.

8.	Маклаков С.В. ВРууш, ЕВлуш. СА8Е-средства разработки ин-
формационных систем. - М.: ДИАЛОГ-МИФИ, 1999.

Практическое руководство по созданию информационных систем с помо-
щью СА8Е-средств фирмы Р1айпит ВР\ут и ЕВлуш. Изложена методология раз-
работки модели процессов в В Рауш и модели данных с помощью ЕВлуш. Связыва-
ние модели процессов и модели данных. Создание объектной модели и ее
связывание с моделью данных при помощи ЕВлуш Тгап§1а1юп АУ1хагс1. Составле-
ние качественных отчетов с помощью ВРТхуш. Очень хорошее и современное
учебное пособие в обсуждаемой области, но, к сожалению, малопригодное для
“непродвинутой” аудитории.

Дополнительная литература

9.	Алексеева М.М. Планирование деятельности фирмы / Учебно-
методическое пособие. - М.: Финансы и статистика, 1998.

10.	Бовыкин В.И. Новый менеджмент (управление предприятия-
ми на уровне высших стандартов; теория и практика эффективного
управления). - М.: Экономика, 1997.
11.	Бочкарев А., Кондратьев В., Краснова В., Матвеева А. и др.
Семь нот менеджмента. Настольная книга руководителя. Издание
третье, дополненное. - М.: Эксперт, 1998.

12.	Буч Г. Объектно-ориентированное проектирование с примера-
ми применения: Пер. с англ. - М.: Конкорд, 1992.

13.	Васкевич Д. Стратегии клиент/сервер. Руководство по выжи-
ванию для специалистов по реорганизации бизнеса. - Киев.: Диалек-
тика, 1996.

14.	Виноградов В.И., Ручкин В.С. О необходимости построения
информационно-функциональной модели территориальной налого-
вой инспекции. - Тамбов: Тамбовский государственный университет,
1998.

15.	Виссема X. Менеджмент в подразделениях фирмы (предпри-
нимательство и координация в децентрализованной компании): Пер.
с англ. - М.: Инфра-М, 1996.

16.	Гейн К., Сарсон Т. Системный структурный анализ: средства
и методы. - М.: Эйтекс, 1992.

17.	Билл Гейтс. Бизнес со скоростью мысли. - М: Эксмо-пресс,
2001.

18.	Громов А.И., Каменнова М.С., Старыгин А.Н. Создание
корпоративного электронного архива и реорганизация бизнес-про-
цедур компании // СУБД. - 1995. - № 3. - С. 84-94.

19.	Гудушаури Г.В., Литвак Б.Г. Управление современным
предприятием. - М.: Тандем, ЭКМОС, 1998.

20.	Дейл М. Самообучающиеся организации. Хрестоматия
“Управление обучением”. - М.: МЦДО “ЛИНК”, 1996.

21.	Джонсон Д. Процессы управления стратегическими измене-
ниями. Хрестоматия “Управление изменением”. - М.: МЦДО
“ЛИНК”, 1996.

22.	Дракер П.Ф. Управление, нацеленное на результаты: Пер. с
англ. -М.: Технол. шк. бизнеса, 1994.

23.	Дракер П.Ф. Эффективное управление. Экономические зада-
чи и оптимальные решения: Пер. с англ. - М.: ФАИР-ПРЕСС, 1998.

24.	Забелин П.В. Основы корпоративного управления концерна-
ми.-М.: ПРИОР, 1998.

25.	Зиндер Е.З. Бизнес-реинжиниринг и технологии системного
проектирования (учебное пособие). - М.: Центр информационных
технологий, 1996.
26.	Зиндер Е.З. Реинжиниринг + информационные технологии =
новое системное проектирование // Открытые системы. - 1996. -
№ 1.-С. 56-59.

27.	Ивлев В.А. Методологический подход консалтинговой дея-
тельности// Информационные технологии. -1995. -№ 3-4. - С. 17-19.

28.	Ивлев В.А., Каменнова М.С., Попова Т.В. Методологиче-
ский подход к реорганизации деятельности предприятия // Открытые
системы. - 1996, - № 2. - С. 67-69.

29.	Ивлев В.А., Попова Т.В. Организация и реорганизация
деятельности предприятия // Компьютер Пресс. - 1996. - Июнь, -
С. 120-122.

30.	Ивлев В.А., Попова Т.В. Построение бизнес-системы // Ком-
пьютер Пресс. - 1996. - Июль. - С. 84-90.

31.	Как уцелеть среди акул (Опередить конкурентов в умении про-
давать, руководить, стимулировать, заключать сделки). Деловая стра-
тегия (концепция, содержание, символы): Пер. с англ. Б. Карлоф. -
Уфа: Акад, менеджмента. -М.: Экономика, 1993.

32.	Калянов Т.Н. Консалтинг при автоматизации предприятий:
Научно-практическое издание. - Серия “Информатизация России на
пороге XXI века”. - М.: СИНТЕГ, 1997.

33.	Калянов Г.Н., Козлинский А.В., Лебедев В.Н. Сравнение и
проблема выбора методов структурного системного анализа // РС
АУЕЕК/КЕ. - 1996. - № 34 (27 августа). - С. 46, 47, 50.

34.	Калянов Т.Н. Системное проектирование — новый вид дея-
тельности на российском рынке // Информационные технологии. -
1995.-№3-4.-С. 20-21.

35.	Каменнова М.С. Системный подход к проектированию слож-
ных систем // Журнал д-ра Добба. - 1993. - № 1. - С. 9-14.

36.	Квинн Д.Б. Управление стратегическими изменениями. Хре-
стоматия “Управление изменением”. - М.: МЦДО “ЛИНК”, 1996.

37.	Колген Д. В защиту процессного консультирования. Хресто-
матия “Управление изменением”. - М.: МЦДО “ЛИНК”, 1996.

38.	Кондрашов В.В., Краснова В.Б. Реструктуризация управле-
ния компанией. Модульная программа для менеджеров, вып. 6. - М.:
Инфра-М, 2000.

39.	Кравченко В.Ф., Кравченко Е.Ф., Забелин П.В. Организаци-
онный реинжиниринг. Учебное пособие для вузов. - М. Приор, 1999.

40.	Лейна Фишер. Совершенство на практике. Лучшие проекты в
области управления бизнес-процессами и \УогкДо^у. - М.: Весть-Ме-
татехнология, 2000.
41.	Медынский В.Г., Ильдеменов С.В. Реинжиниринг инноваци-
онного предпринимательства. - М.: ЮНИТИ, 1999.

42.	Мильнер Б.З. Теория организаций. - М.: Инфра-М, 1998.

43.	Моисеева Н.К. Функционально-стоимостный анализ в маши-
ностроении. - М.: Машиностроение, 1987.

44.	Моисеева Н.К., Анискин Ю.П. Современное предприятие:
конкурентоспособность, маркетинг, обновление. Кн. 1,2. -М.: Внеш-
торгиздат, 1993.

45.	Моисеева Н.К., Кравченко Е.Ф., Аверьянов И.И. Проекти-
рование функционально-структурной организации торговой фирмы с
использованием 8АПТ-МЕТОДОЛОГИИ // Маркетинг. - 1998. -
№3.-С. 47-60.

46.	Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса. - М.: Фи-
нансы и статистика, 1997.

47.	Оуен А. Как осуществлять стратегию. Хрестоматия “Управле-
ние изменением”. - М.: МЦДО “ЛИНК”, 1996.

48.	Оценка бизнеса / Под ред. А.Г. Грязновой, М.А Федотовой. -
М.: Финансы и статистика, 1999.

49.	Питере Т., Уотермен Р. В поисках эффективного управления.
Опыт лучших компаний: Пер с англ. - М., 1986.

50.	Питерсон Д. Теория сетей Петри и моделирование систем. -
М.: Мир, 1984.

51.	Попов Э.В. Бизнес-процесс “Реинжиниринг” и интеллектуаль-
ное моделирование компаний // Статические и динамические эксперт-
ные системы: Учеб, пособие. - М.: Финансы и статистика, 1996.

52.	Пью Д. Понимание организационных изменений и управление
ими. Хрестоматия “Управление изменениями”. - М.: МЦДО “ЛИНК”,
1996.

53.	Пью Д., Мэйби К. Стратегии управления сложными измене-
ниями. Курс профессионального диплома по менеджменту “Управле-
ние развитием и изменением”. Кн. 10. Открытый университет Велико-
британии: Пер. с англ. - М.: МЦДО “ЛИНК”, 1995.

54.	Робсон М., Уллах Ф. Практическое руководство по реинжи-
нирингу бизнес-процессов: Пер. с англ. / Под ред. Н.Д. Эриашвили. -
М.: ЮНИТИ, 1997.

55.	Росс Д. Структурный анализ: язык для передачи понимания //
Требования и спецификации в разработке программ. - М.: Мир, 1984.
56.	Ручкин В.С. Вербальная модель функционирования отдела
учета и отчетности физических лиц территориальной налоговой ин-
спекции. Новые информационные технологии в финансово-кредит-
ной сфере/Международная Академия информатизации. - 1997.

57.	Сапегин А.М. Реорганизация бизнес-процессов: когда, как и
зачем // РС АУЕЕК/КЕ. - 1995. - 5 дек. - С. 41, 42, 44.

58.	Семенов И.О. Вербальная модель функционирования отдела
учета и отчетности юридических лиц территориальной налоговой ин-
спекции. Новые информационные технологии в финансово-кредит-
ной сфере // Международная Академия информатизации, 1997.

59.	Сенге П. Новая работа для лидера. Хрестоматия “Управление
обучением”. - М.: МЦДО “ЛИНК”, 1996.

60.	Таранов П.С. Золотая книга руководителя. - М.: Агентство
“ФА-ИР”, 1998.

61.	Тельнов Ю.Ф. Реинжиниринг бизнес-процессов: Учебное по-
собие. - М.: Московский государственный университет экономики,
статистики, информатики, 1999.

62.	Томас М. Кулопулос. Необходимость АУогкйоху. Решения для
реального бизнеса. - М.: Весть-Метатехнология, 2000.

63.	Уотсон Л., Мейон-Уайт У. Системные концепции и стратегия
вмешательства. Курс профессионального диплома по менеджменту
“Управление изменением”. Кн. 3. Открытый университет Великобри-
тании: Пер. с англ. - М.: МЦДО “ЛИНК”, 1993.

64.	Управление развитием и изменением. Управление изменени-
ем. Хрестоматия / Составители К. Мэйби, Б.М. Уайтм. - М.: МЦДО
“ЛИНК”, 1998.

65.	Уткин Э.А. Бизнес-реинжиниринг. Обновление бизнеса. - М.:
Тандем, 1998.

66.	Хаммер М., Чампи Дж. Реинжиниринг корпорации: манифест
революции в бизнесе: Пер. с англ. - Спб.: Изд-во С.-Петербург, ун-та,
1997.

67.	Черемных С.В. Материалы по изучению курса “Моделиро-
вание бизнес-процессов”. - М.: Финансовая академия при Правитель-
стве РФ, 2000.

68.	Шапот М.Д. Инструментальные средства поддержки реинжи-
ниринга бизнес-процессов // Материалы семинара “Динамические ин-
теллектуальные системы в управлении и моделировании”. - М.:
ЦРДЗ, 1996.
69.	Юдицкий С.А., Кутанов А.Т. Методология структурного
анализа и логического проектирования сложных информацион-
но-управляющих систем // Приборы и системы управления. - 1994. -
№4.-С. 15-25.

70.	Вагкег К. СА8Е’”МеЙю(1. ЕпН1у-Ке1айопз1нр Мойе1т§. -Н-У:
АскННоп-АУез1еу РиЫ1з11т§ Сотрапу, 1991.

71.	ВеШп В., 8исЬтап 8. ТЬе 81гисШгес1 8уз1етз Веуе1ортеп1 Май-
на!. - К-У: Уоигскт Ргезз/Ргепйсе Най, 1989.

72.	Воаг В. Н. Тйе ай оГ з1га1е§1с р1аппт§ Гог тГогтайоп 1есЬпо1о§у
// Сгайт§ 81га1е§у Гог Изе 908.Зойп АУйеу&8опз, 1993.

73.	ВоеЬт В.УУ. А 8рйа1 Мойе1 оГ 8ойлуаге Веуе1ортеп1 апй Еп-
йапсетеШ // 1ЕЕЕ Сотрн1ег. Уо1. 21, Ко 5, 1988. - Р. 61-72.

74.	Сагкоп I. Мотеп1з оГ ТгнЙ1. МА: ВаШп^ег РиЬНзЫп^ Сот-
рапу. 1987.

75.	Сагкоп I. апй Ьа^егзСгот Т. Кду Ругапмс1ета! Еп Ьок от йеп
пуа таптзкап, сйеГеп осй 1еес1агеп, 1985.

76.	Вапйоп С., Вапйоп М. Визтезз Ргосезз Апа1уз1з. - Еопйоп:
Тотрзоп Визтезз Ргезз, 1997.

77.	ВауепроН Т.Н. Визтезз Ьтоуайоп, Кееп§теепп§ АУогк
Й1гон§11 ТпГогтаНоп Тес1то1о§у. - Воз1оп: Нагуагй Визтезз 8с!юо1
Ргезз, 1993.

78.	Вауепрог! Т.Н. Ргосезз 1ппоуаНоп: Кееп§теепп§ Й1гон§111пГог-
таНоп Тес1то1оёу. - СатЬпй^е: Нагуагй Птуегзйу Ргезз, 1993.

79.	ВеМагсо Т. 81гнсШгес1 Апа1уз1з апй 8уз1ет 8рес1йсаНоп. - К-У:
Уоигскт Ргезз, 1988.

80.	Вопоуап Визтезз Кееп§теепп§ хуШ1 ТпГогтайоп Тес1то1-
о§у. -Н-У: РгепНсе На11, 1994.

81.	Е1упп К. СпНса! 8иссезз Гас1огз Гог а 8иссезз1й1 Визтезз
Кееп§теепп§ Рпуес! //СА8Е АУогШ СопГегепсе РгосеесНп§з. Воз1оп:
1993, Ос1оЬег.

82.	Еоигтег К. РгасНса! Ошде 1о 81гисШгес1 8уз!етз Эеуе1ортеп1
апд Мат1епапсе. - К-У: Уоигскт Ргезз/РгепНсе На11, 1991.

83.	Сапе С. СотрШег АИед 8ойхуаге Еп§теепп§: 1пе Мейюс1о1-
о§1ез. -Ы-У: Ргепйсе НаП, 1990.

84.	С1Ьзоп М.Ь. Тйе СА8Е Рййозорйу // ВУТЕ. - 1989. Аргй. -
Р. 209-218.

85.	Натшег М. Веуопй Кееп§теепп§. - Ьопскт: Нагрег СоШпз
Визтезз, 1996.
86.	Нашшег М., СЬашру I. Кееп§теепп§ Й1е Согрогайоп: А Мапь
Гез1о Гог Визтезз Кеуо1иНоп. - К-У: Нагрег-СоШпз, 1993.

87.	Наттег М., 81еуеп А.8. Тйе Кееп§теепп§ Кеуо1ийоп: А Напск
Ьоок. -К-У: НагрегВизтезз, 1995.

88.	Наг топ Р. Визтезз Ргосезз Кееп§теепп§ хуйй ОЬ]ес1з - Рай 2
// ОЬ]ес1-Опеп1:ес1 81га1е§1ез. - 1995. - V. 5. - .№ 1.

89.	НаЙеу В., ИгЬЬа! 1.1п1е§га1е<1 ЗйисШгей Апа1уз1з апй Вез1§п. -
К-У: Вогзе! Ноизе, 1987.

90.	Нщ^тз В. Ва1а ЗпгисШгей Зойлуаге Мат^епапз: Й1е ХУагтег-Огг
Арргоасй. -К-У: Вогзе! Ноизе, 1986.

91.	ШЕЕ ЗТВ 729-1983. ЗЬпйагй СИоззагу оГЗоШуаге Еп§теепп§
Тегтто1о§у. -К-У: 1ЕЕЕ, 1983.

92.	ТасоЬзоп I., СЬпз^егзоп М., Лопззоп Р. апй Оуег^аагд С. ОЬ-
]ес1-опеп1е<1 ЗоЪуаге Еп§теепп§ - А ЕГзе Сазе Впуеп Арргоасй. Кеаск
т§, МА: АскНзоп-ХУез1еу. -Ы-У: АСМ Ргезз, 1992.

93.	ТасоЬзоп I.., Епсззоп М., ЛасоЬзоп А. Тйе ОЬ]ес1 Ас1уап1а§е:
Визтезз Ргосезз Кееп§теепп§ ауйй ОЬ]ес1 Тес1то1о§у // АСМ Ргезз —
АскНзоп-ХУез1еу РиЫ1з11т§, 1995.

94.	<ГоЬап88оп Н., МсНи^Ь Р., РепШеЬигу I. апй УУее1ег III XV.
Визтезз Ргосезз Кееп§теегт§. Вгеакрот! 81га1е§1ез Гог Магке! Вотк
папсе. СЫскез^ег: Зойп ХУИеу & Зопз, 1993.

95.	К1етЬег§. ВРК Тоо1з Са1е§опез — МиШр1е СИокез Кезеагск
Но1е // 1и1у 7 1995. (ЗайпегОгоир.

96.	Мап^апеШ К. Мег§т§ ВРК апй 81га1:е§у 1тр1етеп1айоп. Тке
КаНопа1 РиЬПсаНоп Гог ВРК Еп1егрпзе Кееп§шеепп§. - V. II. - Зззие. -
Ко 6. - 8ер1етЬег, 1995.

97.	Магко В.А., МсСоуап К.Ь. ЗАЭТ: 81:гис1иге(1 Апа1уз1з апй Эе-
81§п Тескт§ие. -К-У: МсОгауу НШ, 1988.

98.	МсС1иге С., Магйп I. Керозйогу: Вазхз Гог 1п1е§гаНоп. СЫса§о:
Ех1епс1ес11п1еШ§епсе, 1991.

99.	Моай I. ОЬ]ес1 Мейюдз Тате Кееп§епеепп§ Мадпезз //
Ва1ата11оп. - Мау, 1995.

100.	Огг К.Т. ЗйисШгей Зуз^етз Веуе1ортеп1. - К-У: Уоигдоп
Ргезз, 1977.

101.	Ра§е-<1опе8 М. ТЬе РгасНса1 Ошйе 1о 81гисШгес1 Зуз^етз Эе-
81§п. -К-У: Уоигскт Ргезз, 1988.

102.	Ко88 В. АррИсаНопз апд ех1епз1опз оГ 8АВТ// ШЕЕ Сот-
ри1ег. - Арп1, 1995.
103.	К.О88 К.С. Епк1у Мо<1е1т§: Тесктциез апк Аррксакопз.
Воз1оп: Оа1а Вазе Кезеагск Огоир, 1987.

104.	8Ыаег 8. апс! МеИог 8.Х ОЬ]ес1-Опеп1ес1 8уз1етз Апа1уз!з. -
Еп§1еууооа СНйз. - К-Т: Ргепйсе На11, 1988.

105.	8а1§ате К.К., Вескег 8.С., Ти В.Н. 8рагкз: А Кпоу4ес1§е
Вазек Ргосезз Мос1е1т§ апк 81ти1аНоп 8уз1ет // Тке Какова! Визтезз
Ргосезз Кееп§1пеепп§СопГегепсе, 1995.

106.	8Ье1е§ XV. Визхпезз Ргосезз Кееп§теепп§ кпуеп Ьу Ьизтезз
еуеШз//Ва1аЬазе Кеууз1ейег. 8ер1етЬег/Ос1оЬег, 1993.-21(5).

107.	Тзап§ Е. Визтезз Ргосезз Кееп^теепщ* апс! ууку к гецшгез
Ьизтезз еуеп! апа1уз!з // Сазе Тгепдз. - МагсЬ, 1993.

108.	ХУШосЬ В.Е. Визтезз Ргосезз Еп§теепп§. Утпепке
агЬеИзргозеззе о§ ог§атзаз]оп88!п1к1игеге 1 Гогапс1пп§еп8 кесептит. -
Копуау Га§Ьо§&г1а§е1, 1994.

109.	\У1гГз-Вгоск К., ХУПкегзоп В. апк ХУхепХег Ь. Вез1§тп§ ОЬ-
]ес1-Опеп1ес1 8о1луаге. - Еп§1е\уоос1 СШТз. - К-Т: Ргепксе НаП, 1990.

ПО. ТоигЛоп Е. апк Сопз^апкпе Ь.Ь. 81гис1игес1 Вез!§п: Гипка-
тепЫз оГ а В1зс1р1те оГ Сотри1ег Ргодгат апк 8уз1ет Вез1§п. -
Еп§1е\уоос1 СНйз. - К-Т: Ргепксе-НаП, 1979.

111.	ТоигЛоп Е. Мокет 81гисШге<1 Апа1уз1з. ТоиМоп Ргезз/
Ргепксе-НаП, 1989.

112.	Тоигйоп Е. 81гисШгес1 ХТаШЙн-ои^кз. 4Й1 екп. - Еп§1е\уоо<1
СШТз. - К-Т: Ргепксе-НаП, Тоигскт Ргезз, 1989.
Оглавление

К читателю................................................. 3

Предисловие................................................ 9

Глава 1. Модель бизнеса и структурный анализ ГОЕР .. 11

1.1.	Требования к модели компании....................... 16

1.1.1.	Клиенты и партнеры........................... 16

1.1.2.	Исполнительный управленческий аппарат.... 16

1.1.3.	Команда по реинжинирингу..................... 17

1.1.4.	Владелец процесса............................ 18

1.1.5.	Владелец ресурса............................. 18

1.2.	Структурный анализ средствами ГОЕР-моделирования...	19

1.3.	Из истории моделирования бизнес-процессов....... 21

1.4.	Методология 8АОТ................................ 22

1.5.	Применение методов ГОЕР для моделирования поведения
компаний............................................ 24

Глава 2. Методология описания бизнес-процессов
ГОЕРЗ........................................... 27

2.1.	Синтаксис и семантика моделей ГОЕРЗ................ 29

2.1.1.	Модели ГОЕРЗ................................. 29

2.1.2.	Диаграммы.................................... 29

2.1.3.	Единица работы. Действие..................... 30

2.1.4.	Связи........................................ 30

2.1.5.	Соединения................................... 34

2.1.6.	Указатели.................................... 39

2.1.7.	Декомпозиция действий........................ 40

2.2.	Требования ГОЕРЗ к описанию бизнес-процессов... 41

2.2.1.	Определение сценария, границ моделирования, точ-
ки зрения........................................ 41

2.2.2.	Определение действий и объектов.............. 41

2.2.3.	Последовательность и параллельность.......... 42
Глава 3. Методология функционального моделирова-
ния ЮЕЕО........................................... 44

3.1.	Синтаксис и семантика моделей ГОЕРО............ 45

3.1.1.	Модели ШЕРО.............................. 45

3.1.2.	Действия................................. 46

3.1.3.	Границы и связи.......................... 46

3.1.4.	Туннели.................................. 51

3.2.	Построение моделей ГОЕРО....................... 53

3.2.1.	Диаграммы................................ 53

3.2.2.	Цикл эксперт — аналитик.................. 55

3.2.3.	Построение моделей....................... 55

3.2.4.	Точка зрения............................. 56

3.2.5.	Границы моделирования.................... 56

3.2.6.	Выбор наименования контекстного блока.... 57

3.2.7.	Определение стрелок на контекстной диаграмме... 58

3.2.8.	Нумерация блоков и диаграмм.............. 59

3.2.9.	Связь между диаграммой и ее родительским функ-
циональным блоком............................... 60

3.2.10.	Два подхода к началу моделирования (“в ширину” и
“в глубину”).................................... 61

3.2.11.	Когда остановиться...................... 61

3.2.12.	Другие диаграммы ГОЕРО.................. 61

3.3.	Взаимосвязь моделей ГОЕРО и ГОЕРЗ.............. 63

3.3.1.	Действия, выполняемые в функциональных блоках 63

3.3.2.	Создание моделей ГОЕРЗ для отображения блоков
ГОЕРО........................................... 64

Глава 4. Структурный анализ потоков данных (Ра1а Яоуу
0!адгагн5 — ОЕР) .................................. 66

4.1.	Назначение диаграмм потоков данных............. 66

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

4.2.1.	Функциональные блоки..................... 68

4.2.2.	Внешние сущности......................... 69

4.2.3.	Стрелки (потоки данных).................. 69

4.2.4.	Хранилища данных......................... 70

4.2.5.	Ветвление и объединение.................. 70

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

4.3.1.	Два подхода к построению ПРВ-моделей..... 71

4.3.2.	Нумерация объектов....................... 72
Глава 5. Другие возможности ЮЕЕ-моделей ............... 74

5.1.	Стоимостный анализ ГОЕР-моделей. Функциональное
оценивание........................................... 74

5.2.	Имитационные модели ............................ 76

5.2.1.	Источники и назначения.................... 77

5.2.2.	Очереди................................... 77

5.2.3.	Оборудование.............................. 78

5.2.4.	Пример имитационной модели................ 78

5.2.5.	Обработка результатов моделирования....... 89

Глава 6. Программное обеспечение ЮЕЕ-моделирова-
ния................................................. 90

6.1.	Р1аНпит ВРауш — руководство пользователя программно-
го пакета компьютерной поддержки технологии модели-
рования ГОЕР......................................... 90

6.1.1.	Краткий обзор............................. 91

6.1.2.	Проверка правильности выполнения задания.. 92

6.1.3.	Зачем нужно усовершенствование бизнес-процес-
сов .............................................. 93

6.1.4.	Деловое моделирование..................... 93

6.1.5.	Что такое ВРауш?.......................... 93

6.1.6.	Модель ВРаухп............................. 94

6.2.	ГОЕР-моделирование и ВРауш...................... 95

6.2.1.	Методологии моделирования, поддерживаемые
ВРауш............................................ 95

6.2.2.	Функциональное моделирование (ГОЕРО)...... 95

6.2.3.	Диаграммы потоков данных (ОРТ))........... 96

6.2.4.	Описание бизнес-процессов (ГОЕРЗ)......... 96

6.2.5.	Когда и какие методологии применять....... 99

6.3.	Практическое использование ВРауш............... 100

6.3.1.	Рабочее место ВРауш...................... 100

6.3.2.	Дерево модели............................ 100

6.3.3.	Область для рисования.................... 101

6.3.4.	Панель инструментов ВРауш................ 102

6.3.5.	Помощь.................................   102

6.3.6.	Построение контекстных диаграмм.......... 103

6.3.7.	Декомпозиция...........................   105

6.3.8.	Оформление моделей....................... 108

6.3.9.	Ветвление и объединение стрелок........... 110

6.3.10.	Опции отображения....................... 110

6.3.11.	Другие виды диаграмм ГОЕРО.............. 111
6.3.12.	Открытие древовидных и ГЕО-диаграмм..... 113

6.3.13.	Разбиение и объединение моделей......... 113

6.3.14.	Оценивание бизнес-процессов с использованием
ВРауш........................................... 114

6.3.15.	Печать диаграмм ВРууш.................. 118

6.3.16.	Отчеты по модели....................... 119

Глава 7. Практические примеры использования
ЮЕЕ-технологий....................................... 122

7.1.	ГОЕГ-моделирование в налогообложении.......... 123

7.1.1.	Постановка задачи....................... 123

7.1.2,	Основные элементы модели................ 125

7.1.3.	Словарь................................. 127

7.1.4.	ГОЕРО-диаграммы модели.................. 128

7.1.5.	Описание функциональных блоков.......... 131

7.2.	Моделирование управленческого учета на предприятии.. 132

7.2.1.	Постановка задачи....................... 132

7.2.2.	Основные элементы модели управленческого учета 133

7.2.3.	Перечень функций........................ 134

7.2.4.	Словарь................................. 134

7.2.5.	ГОЕРО-диаграммы модели управленческого учета.. 136

7.2.6.	Описание функциональных блоков.......... 136

7.3.	Применение функционального моделирования в аудитор-
ской деятельности ................................. 139

Приложения........................................... 145

Ш. Семейство стандартов ГОЕР....................... 145

П2. Нотации моделирования.......................... 148

ПЗ. Программное средство моделирования Пе§1§п/ГОЕР.. 149

П4. Структурный и объектно-ориентированный подход. Что
лучше.......................................... 152

П4.1. Традиционный подход к разработке моделей.. 153

П4.2. Объектно-ориентированный подход к разработке
модели....................................... 155

П4.3. Преимущества и недостатки объектно-ориентиро-
ванного подхода.............................. 159

П5. Реинжиниринг: не автоматизируйте — уничтожайте.. 164

П6. Темы для самостоятельной работы................ 179

Глоссарий...........................................  191

Рекомендуемая литература............................. 195
Производственное издание

Черемных Станислав Владимирович
Семенов Илья Олегович
Ручкин Владимир Сергеевич

СТРУКТУРНЫЙ АНАЛИЗ СИСТЕМ!
ШЕР-ТЕХНОЛОГИИ

Заведующая редакцией Л. А. Табакова
Редактор И. В, Сидорова

Младший редактор Н.А. Федорова 7
Художественный редактор Ю, И, Артюхов
Технический редактор Т. С. Маринина
Корректоры М. М. Виноградова, Т. М Васильева
Обложка художника Е. К. Самойлова
Компьютерная верстка Л. Н. Канатникова

ИБ№4330

Подписано в печать 23.04.2003. Формат 60Г88/16
Печать офсетная. Гарнитура «Таймс»

Усл. п. л. 12,74. Уч.-изд. л. 10,18
Тираж 3000 экз. Заказ 1500. «С»119

Издательство «Финансы и статистика»
101000, Москва, ул. Покровка^ 7
Т&тефон (095) 925-35-02, факс (095) 925-09-57
Е-тай: тай@Г1П8Ш.ги Ьпр://Шцг.Йп®1аг.ти

ГУП «Великолукская городская типография»

Комитета по средствам массовой информации Псковской области

182100, Великие Луки, ул. Полиграфистов, 78/12
Тел./факс: (811-53) 3-62-95

Е-таП: УТШМАЯТКХ! г