Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
ПРИКЛАДНЫЕ ▼ ИНФОРМАЦИОННЫЕ ^ ^ ■ ^ ^
ТЕХНОЛОГИИ
С. В. Черемных
И. О. Семенов
В. С. Ручкин
Моделирование и анализ систем.
практикум
ПРИКЛАДНЫ1 ИНФОРМАЦИОННЫ! ► | технологииПРИКЛАДНЫ1 ИНФОРМАЦИОННЫ! ► | технологииС.В. Черемных И. О. Семенов В. С.Ручкин
ПРИКЛАДНЫ1 ИНФОРМАЦИОННЫ! ► | технологии
ПРИКЛАДНЫ1 ИНФОРМАЦИОННЫ! ► | технологии
Моделирование и анализ систем. ЮЕйехнологии: практикум
Москва “Финансы и статистика” 2006
УДК 004.94:658.012.2(076.5)
ББК 65.290-2с51я73
4-46
Серия“Прикладные информационные технологии”Основана в 1997 г.
Главный редактор сериидоктор технических наук, профессорС.В. Черемных
РЕЦЕНЗЕНТ
доктор технических наук, профессор В.А. Бывшее
Черемных С.В.
4-46 Моделирование и анализ систем. I DEF-технологии: практикум / С.В.Черемных, И.О. Семенов, В.С. Ручкин. - М.: Финансы и статистика, 2006. - 192 с.: ил. - (Прикладные информационные технологии).
ISBN 5-279-02564-Х
Практикум по системному структурному анализу на основе пакета стандартов моделирования IDEF предназначен для формирования практических навыков их использования для построения моделей экономических систем. Первая часть практикума содержит все необходимые сведения по технологиям IDEF0, IDEF3, DFD. Вторая часть представляет собой комплект заданий на базе этого комплекса для аудиторной и самостоятельной работы слушателей.
Для студентов, аспирантов, преподавателей вузов, специалистов-менеджеров всех уровней, слушателей, получающих второе высшее образование.
ЧЧ2404000000 - 136010(01)-20062404000000 - 136010(01)-2006без объявл.без объявл.УДК 004.94:658.012.2(076.5)ББК65.290-2с51я73УДК 004.94:658.012.2(076.5)ББК65.290-2с51я73
Ч
Ч
2404000000 - 136010(01)-2006
2404000000 - 136010(01)-2006
без объявл.
без объявл.
УДК 004.94:658.012.2(076.5)
ББК65.290-2с51я73
УДК 004.94:658.012.2(076.5)
ББК65.290-2с51я73
ISBN 5-279-02564-ХISBN 5-279-02564-Х©СВ Черемных, И О Семенов, В С Ручкин, 2002
ISBN 5-279-02564-Х
ISBN 5-279-02564-Х
К читателю
Структурный системный анализ как практический метод служит инструментом человеческого разума для анализа ситуаций тысячелетия (с момента возникновения и разума, и ситуаций). Научный подход в этой области сложился сравнительно недавно. В настоящее время под этим термином понимается «метод исследования системы, который начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней» [6]. Два базовых принципа заложены в этом определении, а именно: принцип «разделяй и властвуй» и принцип так называемого «иерархического упорядочивания». Понимание этих принципов, знание предметной области и общей логики научного анализа вполне достаточно для решения прикладных задач, хотя точного определения структурного системного анализа к большой досаде поклонников «чистой науки» и не существует.
В истории науки и техники такое случалось нередко. Отдавая должное замечательным достижениям математики, мы, согласно урокам истории, в постановке задач и выборе методов их решения должны отталкиваться от предметной области, следуя классическому афоризму: ученые делают то, что можно, но так, как нужно, инженеры — наоборот: то, что нужно, но уж как получится. И в этом нет пугающего антагонизма: грамотно и своевременно решенная инженерная или экономическая задача со временем часто получает изящное математическое оформление.
«Почему мы должны отказываться от обеда лишь на том основании, что не полностью понимаем процессы пищеварения?» — печально замечал в свое время (1892 г.) О. Хевисайд (1850—1925), блестящий инженер, в дискуссии с не менее блестящими математиками по поводу острой критики недостаточной обоснованности своего метода (операционного исчисления в теории дифференциальных уравнений). При этом Хевисайд, опираясь на свой метод, не реагируя на критику, решал одну за другой важнейшие практические задачи из области электротехники. В наши дни метод операционного исчисления читается в технических вузах как самостоятельная математическая дисциплина, параллельно с ней — электротехника, где излагаемый в математическом курсе метод является одним из ключевых в расчете так называемых линейных цепей.
Мы тоже не будем отказываться от нашего «исчисления». Думается, наличие международного стандарта на излагаемые технологии — весомый для любого специалиста аргумент в решении вопроса, ис-
пользовать или не использовать данную технологию в соответствующей ситуации.
Обращаясь непосредственно к содержанию этой работы, прежде всего необходимо уточнить некоторые детали, касающиеся термина «системный структурный анализ». Три идеи, лежащие в нашем понимании этого термина, следуя [6], выделим как основополагающие:
идея разбиения исследуемого процесса на функциональные блоки — подпроцессы исходя из ряда принципов, например «определенности» (выход каждого блока должен быть ясно понимаем независимо от сложности происходящего процесса), «единственности» и т.д.;
идея иерархии, означающая возможность детализации (декомпозиции) любых нужных нам процессов, реализованная в виде так называемых «иерархических структур»;
идея использования графических нотаций с возможностью «текстового» разъясняющего дополнения.
Предлагаемая книга представляет собой практикум по технологии структурного анализа в варианте, базирующемся на хорошо известных специалистам методологиях, позволяющих анализировать процессы (в том числе и бизнес-процессы) с трех ключевых точек зрения одновременно — IDEFO (Integration Definition for Function Modeling), IDEF3 и DFD (Data Flow Diagram):
IDEFO-технология структурного анализа и проектирования. Это язык моделирования, предложенный более 25 лет назад Д. Россом (SoftTech, Inc.) и называвшийся в исходном своем виде SADT (Structured Analysis and Design Technique). Согласно этой технологии анализируемый процесс представляется в виде совокупности множества взаимосвязанных действий, работ (Activities), которые взаимодействуют между собой на основе определенных правил (Control), с учетом потребляемых информационных, человеческих и производственных ресурсов (Mechanism), имеющих четко определенный вход (Input) и не менее четко определенный выход (Output);
ЮЕРЗ-технология сбора данных, необходимых для проведения структурного анализа системы, дополняющая технологию IDEF0. С помощью этой технологии мы имеем возможность уточнить картину процесса, привлекая внимание аналитика к очередности выполнения функций и бизнес-процессов в целом. Логика этой технологии позволяет строить и анализировать альтернативные сценарии развития изучаемых бизнес-процессов (модели типа “Что — если”?);
DFD (Data Flow Diagram) — структурный анализ потоков данных. Диаграммы DFD позволяют описать процесс обмена информаци-
ей между элементами изучаемой системы. DFD отображает источники и адресаты данных, идентифицирует процессы и группы данных, связывающие в потоки одну функцию с другой, а также, что важно, определяет накопители (хранилища) данных, которые используются в исследуемом процессе.
Упомянутые методологии имеют мощную компьютерную поддержку в виде интегрированного программного пакета BPWin 4.0, что превращает совокупность упомянутых методологий в единый инструментальный метод структурного системного анализа, применимый практически к любым видам «активности» человека. Далеко не случайно, кстати, что основной блок технологии IDEF0 в оригинале назван «Activity».
Важно для системы образования также и то, что обсуждаемые методологии относятся к так называемым «открытым» стандартам, в отличие от «корпоративных» (ARIS, ORACLE и многих других).
Ограничений на использование технологий IDEF-BPWin в настоящее время не наблюдается. Поэтому из технологии профессионального использования они за последние годы шаг за шагом превращаются в технологии общего пользования. Подготовленные на основе этого подхода специалисты, как представляется, составляют активный резерв аналитиков и (или) менеджеров предприятий, организаций, фирм, призванных играть ключевые роли в их развитии, резерв, готовый от имени своей фирмы в тесном контакте с профессиональными консалтинговыми компаниями решать сложнейшие проблемы корпоративного «инжиниринга» и «реинжиниринга». Дополнительная гарантия успеха состоит в том, что и те, и другие имеют возможность общаться на одном с ними языке — языке моделирования IDEF.
В этом своем качестве (в условиях вуза) IDEF-BPWin-технологии полезны не только и не столько для изучения тонкостей анализа предметной области (откуда у будущих еще выпускников знание этих тонкостей!), сколько для формирования современного менталитета будущих выпускников. Проще говоря, они учат думать правильно, процессно.
Учить думать — вообще-то задача всего образования. Уверенность в том, что технологии структурного анализа могут внести свой серьезный вклад в решение этой задачи дает сама природа IDEFBPWin-технологии. Поясним этот тезис, используя музыкальную метафору семи нот (сравните «7 нот менеджмента»). Речь идет о семи базисных понятиях, на которые опирается обсуждаемая триединая технология: цель (анализа); точка зрения (аналитика, менеджера, владельца процесса и т.д.); функциональный блок («активность»); интерфейсная дуга; декомпозиция; глоссарий (словарь); диалог «аналитик — эксперт».
Здесь, как видно, представлены и человеческие факторы (цель, точка зрения, глоссарий, диалог) и формализуемые факторы (функциональный блок, интерфейсная дуга, декомпозиция), подчиняющиеся семантике и синтаксису языка, каковым, в сущности, является излагаемая «структурная» технология.
В такой интерпретации IDEF-BPWin-технологии предстают в историческом плане как реализация мечты специалистов по человекомашинным процедурам 60-80-х годов, разрабатывающих на уровне тех лет инструментальные методы поддержки принятия решений, которые в идеале способны были бы соединить в едином порыве коня и трепетную лань — жесткость машинной логики и изменчивость (часто вредящую делу) человеческого настроения.
Отмеченная выше открытость стандартов IDEF создает очевидное (конкурентное!) преимущество использования этих технологий в образовательной сфере. Вспомним открытость стандартов IBM PC — основную причину взрыва активности предприятий, производящих персональные компьютеры в прошедшие два десятилетия. Так что у нас есть все основания ожидать если не взрыва, то резкого увеличения активности в вопросах внедрения «открытых» IDEF-BPWin-техноло- гий в жизнь в ближайшее время.
Представляемая книга состоит из двух частей — теоретической и практической. Первая часть содержит необходимые сведения по технологиям IDEFO, IDEF3, DFD. Вторая часть представляет собой комплект заданий на базе этого комплекса. Принята структура изложения, отвечающая принципу “от простого к сложному”. Компьютерная поддержка практикума, о чем говорилось выше, — программный пакет BPWin версий 2.5/4.0. Возможно использование и более ранней версии BPWin 1.8.
В общем, успехов Вам, дорогой читатель. Вас ожидает путешествие в новый мир — мир новейших информационных компьютерных технологий, специализированную информационную среду, работая в которой, Вы сможете посмотреть на свою активность другими глазами и сделать весь процесс принятия решений в своей сфере гораздо более обоснованным.
СВ. Черемных, доктор технических наук, профессор Финансовой академии при Правительстве РФ
Предисловие
В настоящее время все большую популярность приобретают инженерные методы реорганизации предприятий на основе современных информационных технологий. Понятия «бизнес-процессы», «процессно-стоимостной подход», «структурный системный анализ», «функциональное моделирование», «информационное моделирование», «реинжиниринг» и многие другие, с ними связанные, уверенно входят в лексикон аналитиков всех уровней. Соответственно расширяется спектр компьютеризованных инструментальных методов анализа экономических процессов и бизнес-процессов в частности.
Перечень специальностей, где активно используются новейшие технологии, первоначально ориентированный в основном на специальности «Информационные системы в экономике», «Менеджмент», постоянно расширяется. В этом списке в данный момент уже нашли себе место такие специальности, как «Бухгалтерский учет и аудит», «Финансы и кредит», «Мировая экономика», «Антикризисное управление», «Маркетинг» и т.д.
В Финансовой академии при Правительстве Российской Федерации создан новый институт «Математические методы и антикризисное управление» для подготовки специалистов квалификации «экономист-математик». Разработаны требования к рабочим программам в рамках единой концепции формирования у слушателей навыков применения инструментальных методов структурного системного анализа экономических процессов, включая аспирантские и магистерские программы по специальности 08.00.13 «Математические и инструментальные методы в экономике».
Соответствующие рабочие программы выглядят, конечно, по-разному в соответствии с различием требований для разных категорий слушателей: студентов, аспирантов, магистрантов или слушателей систем дополнительного образования. В зависимости от специфики используются какой-либо из блоков общего направления либо их комбинации (см. таблицу). Количество часов, выделяемых на практику, составляет около половины общего количества для каждого блока (как правило, 68 ч.).
Представляемое учебное пособие (практикум), как видно из таблицы, имеет свою нишу в учебно-методическом комплексе. Техноло-
7
гия его использования зависит от ситуации: в аудиторной работе он служит естественной поддержкой лекционной части дисциплины, а в процессе самостоятельной работы слушателей — руководством к приобретению соответствующих навыков моделирования.
Структура программ дисциплин по инструментальным методам
Наименование дисциплины
Методо- логическая основа
Инструментальная поддержка
Объем
Форма итогового контроля
Всего
Лекции
Практикум
Структурный анализ бизнес- процессов
IDEF0, IDEF3, DFD,
BPWin 2.5, Design/IDEF, Visio 2000
34
16
18
Реферат, зачет
И нформационное моделирование бизнес-процессов
IDEF1, IDEF IX,
ERWin 3.5.2.
34
16
18
Зачет
Реинжиниринг и оптимизация бизнес-процессов
IDEF, Design/ IDEF
BPWin 2.5, ERWin 3.5.2, Design/ IDEF
34
18
Курсовая работа, экзамен
Упражнения рассчитаны на использование версий BPWin 2.4 (1998 г.) / BPWin 4.0 (2000 г.). При этом для выполнения заданий в полном объеме рекомендуется использовать набор рабочих файлов BPWin, размещенных на сайте Финансовой академии www.fa.ru.
Версия BPWin 1.8 (1995 г.) может использоваться параллельно, в качестве вспомогательного средства для получения практических навыков работы в среде моделирования IDEF0.
Авторы считают своим приятным долгом выразить благодарность сотрудникам фирмы Interface, дистрибьютеру программного продукта BPWin 4.0,. за помощь при внедрении этого продукта в учебный процесс Финансовой академии при Правительстве Российской Федерации.
1ГЛАВА1ГЛАВАМЕТОДОЛОГИЯ ОПИСАНИЯБИЗНЕС-ПРОЦЕССОВ IDEF3
1
ГЛАВА
1
ГЛАВА
IDEF3 — способ описания процессов, основной целью которого является обеспечение структурированного метода, используя который эксперт в предметной области может описать положение вещей как упорядоченную последовательность событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу.
Рис. 1.1. Описание процесса в методологии IDEF3Рис. 1.1. Описание процесса в методологии IDEF3Технология IDEF3 хорошо приспособлена для сбора данных, требующихся для проведения структурного анализа системы. В отличие от большинства технологий моделирования бизнес-процессов, IDEF3 не имеет жестких синтаксических или семантических ограничений, делающих неудобным описание неполных или нецелостных систем. Кроме того, автор модели (системный аналитик) избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области. На рис. 1.1 изображен пример описания процесса с использованием методологии IDEF3.
Рис. 1.1. Описание процесса в методологии IDEF3
Рис. 1.1. Описание процесса в методологии IDEF3
Технология IDEF3 также может быть использована как метод проектирования бизнес-процессов. ЮЕРЗ-моделирование органично дополняет традиционное моделирование с использованием стандарта IDEF0. В настоящее время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для дальнейшего анализа имитационными методами. Имитационное тестирование часто используют для оценки эксплуатационных качеств разрабатываемой системы, более подробно методы имитационного анализа будут рассмотрены позднее.
1.11.1Синтаксис и семантика моделей IDEF3
1.1
1.1
Модели IDEF3
Основой модели IDEF3 служит так называемый сценарий бизнес- процесса, который выделяет последовательность действий или подпроцессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели, довольно важным является подбор подходящего наименования для обозначения действий. Для подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных. Например, “Обработать заказ клиента” или “Применить новый дизайн” — вполне подходящие названия сценариев.
Точка зрения для большинства моделей должна быть явным образом документирована. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.
Для системного аналитика также важно понимание цели моделирования — набора вопросов, ответами на которые будет служить модель, границ моделирования (какие части системы войдут в модель а какие не будут в ней отображены) и целевой аудитории (для кого разрабатывается модель).
Диаграммы
Как и в любой рассматриваемой в этой книге технологии моделирования действий, главной организационной единицей модели IDEF3 является диаграмма. Взаимная организация диаграмм внутри модели 10
IDEF3 особенно важна в случае, когда модель заведомо создается для последующего опубликования или рецензирования, что является вполне обычной практикой при проектировании новых систем. В этом случае системный аналитик должен позаботиться о таком информационном наполнении диаграмм, чтобы каждая из них была самодостаточной и в то же время понятной читателю.
Единица работы. Действие
Аналогично другим технологиям моделирования действие, или в терминах IDEF3 “единица работы” (Unit of Work — UOW) — другой важный компонент модели. Диаграммы IDEF3 отображают действие в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 1.2).
Обработатьзаказ клиентаОбработатьзаказ клиентаНазвание действияНазвание действия
Обработатьзаказ клиента
Обработатьзаказ клиента
Название действия
Название действия
1.11.1
1.1
1.1
Номер действия
Номер родительского действия
Рис. 1.2. Изображение и нумерация действия в диаграмме IDEF3
Связи
Связи выделяют существенные взаимоотношения между действиями. Все связи в IDEF3 являются однонаправленными, и, хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организовываются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 1.1 приведены три возможных типа связей.
Таблица 1.1
Типы связей в модели IDEF3
Изображение
Название
Назначение
►
Временное предшествование (Temporal precedence)
Исходное действие должно завершиться прежде, чем конечное действие сможет начаться
Объектный поток (Object flow)
Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться прежде, чем конечное действие сможет начаться
Нечеткое отношение (Relationship)
Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения
Связь типа “Временное предшествование”. Как видно из названия, связи этого типа отражают, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь должна быть поименована таким образом, чтобы человеку, просматривающему модель, была понятна причина ее появления. Во многих случаях завершение одного действия инициирует начало выполнения другого, как показано на рис. 1.3. В этом примере автор должен принять рекомендации рецензентов, прежде чем начать вносить соответствующие изменения в работу.
Рис. 1.3. Связь типа “Предшествование” между действиями 1.1 и 1.2
Связь типа “Объектный поток”. Одной из наиболее часто встречающихся причин использования связи типа “объектный поток” состоит в том, что некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Такая связь отличается от связи временного предшествования двойным концом обозначающей ее стрелки. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования. Это означает, что порождающее 12
Рис. 1.4. Объектная связь между действиями 1.1 и 1.2Рис. 1.4. Объектная связь между действиями 1.1 и 1.2
Рис. 1.4. Объектная связь между действиями 1.1 и 1.2
Рис. 1.4. Объектная связь между действиями 1.1 и 1.2
объектную связь исходное действие должно завершиться, прежде чем конечное действие начнет выполняться, как показано на рис. 1.4. В приведенном примере счет на оплату услуг является результатом выполнения действия 1.1. Счет необходим для проведения оплаты услуг.
Запустить двигатель1.1 I "Запустить двигатель1.1 I "Запуститьводяной насосЗапуститьводяной насос1.21.2Связь типа ‘‘‘Нечеткое отношение”. Связи этого типа используются для выделения отношений между действиями, которые невозможно описать с использованием предшественных или объектных связей. Значение каждой такой связи должно быть определено, поскольку связи типа “Нечеткое отношение” сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений — отображение взаимоотношений между параллельно выполняющимися действиями. Рис. 1.5 иллюстрирует фрагмент процесса запуска бензопилы с водяным охлаждением и нечеткое отношение между действиями “Запустить двигатель” и “Запустить водяной насос”. Название стрелки может быть использовано для описания природы отношения, более подробное объяснение может быть приведено в виде отдельной ссылки.
Запустить двигатель
1.1 I "
Запустить двигатель
1.1 I "
Запуститьводяной насос
Запуститьводяной насос
1.2
1.2
1,5-секундная задержкадля предотвращения перегрузкиэлектрической цепи
Рис. 1.5. Связь типа “Нечеткое отношение”
Наиболее часто нечеткие отношения используются для описания специальных случаев связей предшествования, например для описания альтернативных вариантов временного предшествования. Обратимся еще раз к рис. 1.3. На рис. 1.6 вертикальные линии показывают начало и окончание действий 1.1 и 1.2, имеющих предшественную связь. В соответствии с рисунком внесение исправлений в работу начинается ПОСЛЕ принятия всех замечаний от рецензентов.
ВремяВремяНачало А1.1 Окончание А1.1Начало А1.1 Окончание А1.1Начало А1.2 Окончание А1.2Начало А1.2 Окончание А1.2Рис. 1.6. Временная шкала выполнения действия для 2.3Рис. 1.6. Временная шкала выполнения действия для 2.3
Время
Время
Начало А1.1 Окончание А1.1
Начало А1.1 Окончание А1.1
Начало А1.2 Окончание А1.2
Начало А1.2 Окончание А1.2
Рис. 1.6. Временная шкала выполнения действия для 2.3
Рис. 1.6. Временная шкала выполнения действия для 2.3
Альтернативная предшественной связи с рис. 1.3 связь нечеткого отношения представлена на рис. 1.7. В этом примере внесение исправлений начинается по мере получения замечаний от рецензентов, т.е. до непосредственного окончания действия по принятию замечаний.
Принять рекомендации рецензентов 1.1 I ~Принять рекомендации рецензентов 1.1 I ~Принятие исправленийВнестиисправления1.2IПринятие исправленийВнестиисправления1.2I
Принять рекомендации рецензентов 1.1 I ~
Принять рекомендации рецензентов 1.1 I ~
Принятие исправлений
Внести
исправления
1.2I
Принятие исправлений
Внести
исправления
1.2I
Рис. 1.7. Альтернатива связи предшествования
На рис. 1.8 приведена соответствующая этой ситуации временная шкала.
ВремяВремя
Время
Время
Рис. 1.8. Альтернативная временная шкала
Отметим еще раз необходимость четкого документирования временных ограничений между действиями, соединенными нечетким отношением. В качестве примера рассмотрим еще одну временную шкалу (рис. 1.9) для рис. 1.3.
Начало А1.1Начало А1.1ВремяВремяОкончание А1.1Окончание А1.1Окончание А1.2Окончание А1.2
Начало А1.1
Начало А1.1
Время
Время
Окончание А1.1
Окончание А1.1
Окончание А1.2
Окончание А1.2
Рис. 1.9. Другой вариант альтернативной временной шкалы
В случае, изображенном на рис. 1.9, внесение исправлений будет начато после получения первых замечаний, однако будет закончено ПЕРЕД тем, как все замечания от рецензентов будут получены и обработаны.
Оба рассмотренных выше варианта временной альтернативной шкалы могут иметь место в реальности, поэтому корректная интерпретация нечеткого отношения должна быть документирована в модели. Важно отметить, что корректность в этом случае означает именно интерпретацию, которая в точности отображает документируемую ситуацию, а не интерпретацию, более эффективную для работы системы, с точки зрения аналитика.
1.1.51.1.5СоединенияСоединения
1.1.5
1.1.5
Соединения
Соединения
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или, наоборот, определенное действие может требовать завершения нескольких других действий для начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса.
Разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других.
Сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения только одного другого действия.
В табл. 1.2 объединены три типа соединений.
Таблица 1.2
Типы соединений в модели IDEF3
Графическое обозначение
Название
Вид
Правила инициации
&
Соединение “И”
Разворачивающее
Каждое конечное действие обязательно инициируется
Сворачивающее
Каждое исходное действие обязательно должно завершиться
X
Соединение “Эксклюзивное ИЛИ”
Разворачивающее
Одно и только одно конечное действие инициируется
Продолжение
Графическое обозначение
Название
Вид
Правила инициации
X
Соединение “Эксклюзивное ИЛИ”
Сворачивающее
Одно и только одно исходное действие должно завершиться
О
Соединение “ИЛИ”
Разворачивающее
Одно (или более) конечное действие инициируется
Сворачивающее
Одно (или более) исходное действие должно завершиться
Примеры разворачивающих и сворачивающих соединений приведены на рис. 1.10.
Рис. 1.10. Два вида соединений
“И”-соединения. Соединения этого типа инициируют выполнение всех своих конечных действий. Все действия, присоединенные к сворачивающему “И”-соединению, должны завершиться, прежде чем может начать выполняться следующее действие. На рис. 1.11 после обнаружения пожара инициируются включение пожарной сигнализации, вызов пожарной охраны и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных действия завершены.
Соединение “Эксклюзивное ИЛИ”. Вне зависимости от количества действий, прицепленных к сворачивающему или разворачивающему соединению “Эксклюзивное ИЛИ”, инициировано будет только одно из них, и поэтому только одно из них будет завершено перед тем, как любое действие, следующее за сворачивающим соединением "Эксклюзивное ИЛИ", сможет начаться.
16
Рис. 1.11. “И”-соединения
Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения, как показано на рис. 1.12.
На рис. 1.12 соединение “Эксклюзивное ИЛИ” используется для отображения того факта, что студент не может одновременно быть направлен на лекции по двум разным курсам.
Рис. 1.12. Соединение “Эксклюзивное ИЛИ”
Соединение “ИЛИ”. Соединения этого типа предназначены для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение “ИЛИ” в основном определяется и описывается непосред-
ственно системным аналитиком. На рис.. 1.13 соединение J2 может активировать проверку данных чека и (или) проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных — при оплате наличными. И то, и другое действие инициируется при частичной оплате чеком и частичной — наличными.
Рис. 1.13. Соединение “ИЛИ”
Синхронные и асинхронные соединения. В рассмотренных примерах связей “И” и “ИЛИ” мы не затрагивали отношений между началом и окончанием действий, инициируемых разворачивающими соединениями. Все действия в этих примерах выполнялись асинхронно, т.е. они не должны были начинать выполняться одновременно. Однако есть случаи, когда время начала или окончания параллельно выполняемых действий должно быть одинаковым, т.е. действия должны выполняться синхронно. Для моделирования такого поведения системы используются синхронные соединения. В табл. 1.3 приведены виды синхронных соединений.
Таблица 1.3
Синхронные соединения модели IDEF3
Графическое обозначение
Тип
Вид
Правила инициации
&
И
Разворачивающее
Все действия начнутся одновременно
Сворачивающее
Все действия закончатся одновременно
||о 1
ИЛИ
Разворачивающее
Может быть, несколько действий начнутся одновременно
Продолжение
Графическое обозначение
Тип
Вид
Правила инициации
о
ИЛИ
Сворачивающее
Может быть, несколько действий закончатся одновременно
X
Эксклюзивное ИЛИ
Разворачивающее
Одновременное начало действий невозможно
Сворачивающее
Одновременное окончание действий невозможно
Синхронное соединение обозначается двумя вертикальными линиями внутри обозначающего его прямоугольника в отличие от одной вертикальной линии в асинхронном соединении.
Во многих спортивных состязаниях выстрел стартового пистолета, запуск секундомера и начало состязания должны произойти одновременно. В противном случае состязание будет нечестным.
Рис. 1.14 иллюстрирует модель этого примера, построенную с использованием синхронного соединения.
Рис. 1.14. Синхронное соединение
Заметим, что синхронное разворачивающее соединение не обязательно должно иметь парное себе сворачивающее соединение. Действительно, начинающиеся одновременно действия вовсе не обязаны оканчиваться одновременно, как это видно из примера с состязаниями. Также возможны ситуации синхронного окончания асинхронно начавшихся действий.
Парность соединений. Все соединения на диаграммах должны быть парными, из чего следует, что любое разворачивающее соединение имеет парное себе сворачивающее. Однако типы соединений вовсе не обязательно должны совпадать. На рис. 1.15 разворачивающее “И”-соединение имеет парное сворачивающее “ИЛИ”-соединение. Интерпретация соединения Л аналогична случаю, показанному на рис. 1.11. Соединение J2 интерпретируется следующим образом: после включения пожарной сигнализации и (или) вызова пожарных и (или) начала тушения производится запись в журнал.
Рис. 1.15. Пример комбинации двух типов соединений
Комбинации соединений. Соединения могут комбинироваться для создания более сложных правил ветвления (рис. 1.16). Комбина-
Рис. 1.16. Диаграмма IDEF3 с комбинацией соединений
ции соединении следует использовать с осторожностью, поскольку перегруженные ветвлением диаграммы могут оказаться сложными для восприятия.
Указатели
Указатели — это специальные символы, которые ссылаются на другие разделы описания процесса. Они выносятся на диаграмму для привлечения внимания читателя к каким-либо важным аспектам модели.
Таблица 1.4
Типы указателей модели IDEF3
Тип указателя
Назначение
ОБЪЕКТ (OBJECT)
Для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект
ССЫЛКА (GOTO)
Для реализации цикличности выполнения действий. Указатель ССЫЛКА может относиться и к соединению
ЕДИНИЦА
ДЕЙСТВИЯ (Unit of Behavior — UOB)
Для помещения на диаграмму дополнительного экземпляра уже существующего действия без зацикливания. Например, если действие “Подсчет наличных” выполняется несколько раз, в первый раз оно создается как действие, а последующие его появления на диаграмме оформляются указателями UOB
ЗАМЕТКА (NOTE)
Для документирования любой важной информации общего характера, относящейся к изображенному на диаграммах. В этом смысле ССЫЛКА служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах
УТОЧНЕНИЕ
(Elaboration — ELAB)
Для уточнения или более подробного описания изображенного на диаграмме. Указатели УТОЧНЕНИЕ обычно используются для описания логики ветвления у соединений
Указатель изображается на диаграмме в виде прямоугольника, похожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор. На рис. 1.17 изображен указатель типа ОБЪЕКТ.
Рис. 1.18. УказательОБЪЕКТ ссылается на действиеРис. 1.18. УказательОБЪЕКТ ссылается на действие
Рис. 1.18. Указатель
ОБЪЕКТ ссылается на действие
Рис. 1.18. Указатель
ОБЪЕКТ ссылается на действие
Объект/Пилот
Рис. 1.17. Указатель
ОБЪЕКТ
На рис. 1.18 показан пример отображения важного с точки зрения модели отношения между действием и объектом.
| Декомпозиция действий
Действия в IDEF3 могут быть декомпозированы, или разложены на составляющие, для более детального анализа. Декомпозировать действие можно несколько раз. Это позволяет документировать альтернативные потоки процесса в одной модели.
Для корректной идентификации действий в модели с множественными декомпозициями схема нумерации действий расширяется и наряду с номерами действия и его родителя включает в себя порядковый номер декомпозиции. Например, в номере действия 1.2.5: 1 — номер родительского действия, 2 — номер декомпозиции, 5 — номер действия.
1.21.2Требования IDEF3 к описанию бизнес-процессов
1.2
1.2
В этом подразделе мы рассмотрим построение 1ВЕРЗ-диаграммы на основе выраженного в текстовом виде описания процесса. Предполагается, что в построении диаграммы принимают участие ее автор (в основном как системный аналитик) и один или несколько экспертов предметной области, которые будут представлять нам описание процесса.
22
1.2.11.2.1Определение сценария, границ моделирования, точки зрения
1.2.1
1.2.1
Перед тем как попросить экспертов предметной области подготовить описание моделируемого процесса, должны быть документированы границы моделирования, чтобы экспертам была понятна необходимая глубина и полнота требуемого от них описания. Кроме того, если точка зрения аналитика на процесс отличается от обычной точки зрения для эксперта, это должно быть ясно и аккуратно описано.
Вполне возможно, что эксперты не смогут сделать приемлемое описание без применения формального опроса автором модели. В таком случае автор должен заранее приготовить набор вопросов таким же образом, как журналист заранее подготавливает вопросы для интервью.
| Определение действий и объектов
Результатом работы экспертов обычно является текстовый документ, описывающий интересующий аналитика круг вопросов. В дополнение к нему может иметься письменная документация, позволяющая пролить свет на природу изучаемого процесса. Вне зависимости от того, является ли информация текстовой или вербальной, она анализируется и разделяется частями речи для идентификации списка действий (глаголы и отглагольные существительные), составляющих процесс, и объектов (имена существительные), участвующих в процессе.
В некоторых случаях возможно создание графической модели процесса в присутствии экспертов. Такая модель также может быть разработана после сбора всей необходимой информации, что позволяет не отнимать время экспертов на детали форматирования получающихся диаграмм.
Поскольку модели IDEF3 могут одновременно разрабатываться несколькими командами, IDEF3 поддерживает простую схему резервирования номеров действий в модели. Каждому аналитику выделяется уникальный диапазон номеров действий, что обеспечивает их независимость друг от друга. В табл. 1.5 номера действий выделяются каждому аналитику большими блоками. В этом примере Иван исчерпал данный ему вначале диапазон номеров и дополнительно получил второй.
Таблица 1.5
Распределение диапазонов номеров IDEF3 между аналитиками
Аналитик
Диапазон номеров IDEF3
Иван
1-99
Петр
100-199
Николай
200-299
Иван
300-399
Последовательность и параллельность
Если модель создается после проведения интервью, аналитик должен принять решения по построению иерархии участвующих в модели диаграмм, например, насколько подробно будет детализироваться каждая отдельно взятая диаграмма. Если последовательность или параллельность выполнения действий окончательно не ясна, эксперты могут быть опрошены вторично (возможно, с использованием черновых вариантов незаконченных диаграмм) для получения недостающей информации. Важно, однако, различать предполагаемую (появляющуюся из-за недостатка информации о связях) и явную (ясно указанную в описании эксперта) параллельности.
* ♦ ♦
Итак, IDEF3 — это способ описания бизнес-процессов, который нужен для описания положения вещей как упорядоченной последовательности событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу. IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения структурного анализа системы. Кроме того, IDEF3 применяется при проведении стоимостного анализа поведения моделируемой системы.
2ГЛАВА2ГЛАВАМЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0
2
ГЛАВА
2
ГЛАВА
Рис. 2.1. Пример диаграммы IDEF0Рис. 2.1. Пример диаграммы IDEF0Методология функционального моделирования IDEF0 — это технология описания системы в целом как множества взаимозависимых действий, или функций. Важно отметить функциональную направленность IDEF0 — функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. “Функциональная” точка зрения позволяет четко отделить аспекты назначения системы от аспектов ее физической реализации. На рис. 2.1 приведен пример типовой диаграммы IDEF0.
Рис. 2.1. Пример диаграммы IDEF0
Рис. 2.1. Пример диаграммы IDEF0
Наиболее часто IDEF0 применяется как технология исследования и проектирования систем на логическом уровне. По этой причине он, как правило, используется на ранних этапах разработки проекта, до IDEF3 моделирования для сбора данных и моделирования процесса “как есть”. Результаты IDEF0 анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных.
2 1 Синтаксис и семантика
" моделей IDEF0
Модели IDEF0
IDEF0 сочетает в себе небольшую по объему дэафическую нотацию (она содержит только два обозначения: блоки и стрелки) со строгими и четко определенными рекомендациями, в совокупности предназначенными для построения качественной и понятной модели системы.
Методология IDEF0 в некоторой степени напоминает рекомендации, существующие в книгоиздательском деле, часто набор напечатанных моделей IDEF0 организуется в брошюру (называемую в терминах IDEF0 комплекту имеющую содержание, глоссарий и другие элементы, характерные для законченной книги.
Первый шаг при построении модели IDEF0 заключается в определении назначения модели — набора вопросов, на которые должна отвечать модель. Набор вопросов можно сравнить с предисловием, в котором раскрывается назначение книги.
Границы моделирования предназначены для обозначения ширины охвата предметной области и глубины детализации и являются логическим продолжением уже определенного назначения модели. Как читающий модель, так и непосредственно ее автор должны понимать степень детальности ответов на поставленные в назначении модели вопросы.
Следующим шагом указывается предполагаемая целевая аудитория, для нужд которой создается модель. Зачастую от выбора целевой аудитории зависит уровень детализации, с которым должна создаваться модель. Перед построением модели необходимо иметь представление о том, какие сведения о предмете моделирования уже известны, какие дополнительные материалы и (или) техническая документация для понимания модели могут быть необходимы целевой аудитории, какие язык и стиль изложения являются наиболее подходящими.
Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Точка зрения выбирается таким образом, чтобы учесть уже обозначенные границы моделирования и 26
назначение модели. Однажды выбранная точка зрения остается неизменной для всех элементов модели. При необходимости могут быть созданы другие модели, отображающие систему с других точек зрения. Вот несколько примеров точек зрения при построении моделей: клиент, поставщик, владелец, редактор.
| Действия
Действие, обычно в IDEF0 называемое функцией, обрабатывает или переводит входные параметры (сырье, информацию и т.п.) в выходные. Поскольку модели IDEF0 представляют систему как множество иерархических (вложенных) функций, в первую очередь должна быть определена функция, описывающая систему в целом — контекстная функция. Функции изображаются на диаграммах как поименованные прямоугольники, или функциональные блоки. Имена функций в IDEF0 подбираются по сходным правилам с именами действий в IDEF3 — с использованием глаголов или отглагольных существительных. Важно подбирать имена таким образом, чтобы они отражали систему так, как если бы она обозревалась с точки зрения, выбранной для моделирования.
Сверка документов 1Сверка документов 1Пример функционального блока приведен на рис. 2.2.
Сверка документов 1
Сверка документов 1
Выше мы определяли IDEF0 модели как иерархическое множество вложенных бло
ков. Любой блок может быть декомпозиро- РиСе 2е2‘ Функциональный ван на составляющие его блоки. Декомпозицию часто ассоциируют с моделировани
ем “сверху вниз”, однако это не совсем верно. Функциональную декомпозицию корректнее определять как моделирование “снаружи вовнутрь”, в котором мы рассматриваем систему наподобие луковицы, с которой последовательно снимаются слои.
Границы и связи
Чтобы быть полезным, описание любого блока должно, как минимум, включать в себя описание объектов, которые блок создает в результате своей работы (’’выхода”), и объектов, которые блок потребляет или преобразует (’’вход”).
В IDEF0 также моделируются управление и механизмы исполнения. Под управлением понимаются объекты, воздействующие на
27
способ, которым блок преобразует вход в выход. Механизм исполнения — объекты, которые непосредственно выполняют преобразование входа в выход, но не потребляются при этом сами по себе.
Для отображения категорий информации, присутствующих на диаграммах IDEF0, существует аббревиатура ICOM, отображающая четыре возможных типа стрелок:
I (Input) — вход — нечто, что потребляется в ходе выполнения процесса;
С (Control) — управление — ограничения и инструкции, влияющие на ход выполнения процесса;
О (Output) — выход — нечто, являющееся результатом выполнения процесса;
М (Mechanism) — исполняющий механизм — нечто, что используется для выполнения процесса, но не потребляется само по себе. Рис. 2.3 показывает 4 возможных типа стрелок в IDEF0, каждый из типов соединяется со своей стороной функционального блока.
СтрелкавходаСтрелкавходаСтрелка механизма исполненияСтрелка механизма исполненияРис. 2.3. Каждый тип стрелки соединяется со своей стороной функционального блокаРис. 2.3. Каждый тип стрелки соединяется со своей стороной функционального блока
Стрелкавхода
Стрелкавхода
Стрелка механизма исполнения
Стрелка механизма исполнения
Рис. 2.3. Каждый тип стрелки соединяется со своей стороной функционального блока
Рис. 2.3. Каждый тип стрелки соединяется со своей стороной функционального блока
Для названия стрелок, как правило, употребляются имена существительные. Стрелки могут представлять собой людей, места, вещи, идеи или события. Как и в случае с функциональными блоками, присвоение имен всем стрелкам на диаграмме является только необходимым условием для понимания читателем сути изображенного. Отдельное описание каждой стрелки в текстовом виде может оказаться критическим фактором для построения точной и полезной модели.
Стрелки входа. Вход представляет собой сырье, или информацию, потребляемую или преобразуемую функциональным блоком для производства выхода. Стрелки входа всегда направлены в левую сто28
рону прямоугольника, обозначающего в IDEF0 функциональный блок. Наличие входных стрелок на диаграмме не является обязательным, так как возможно, что некоторые блоки ничего не преобразуют и не изменяют. Примером блока, не имеющего входа, может служить “принятие решения руководством”, где для принятия решения анализируется несколько факторов, но ни один из них непосредственно не преобразуется и не потребляется в результате принятия какого-либо решения.
Стрелки управления. Стрелки управления отвечают за регулирование того, как и когда выполняется функциональный блок, и, если он выполняется, какой выход получается в результате его выполнения. Так как управление контролирует поведение функционального блока для обеспечения создания желаемого выхода, каждый функциональный блок должен иметь, как минимум, одну стрелку управления. Стрелки управления всегда входят в функциональный блок сверху.
Управление часто существует в виде правил, инструкций, законов, политики, набора необходимых процедур или стандартов. Влияя на работу блока, оно непосредственно не потребляется и не трансформируется в результате. Может оказаться, что целью функционального блока является как раз изменение того или иного правила, инструкции, стандарта и т.п. В этом случае стрелка, содержащая соответствующую информацию, должна рассматриваться не как управление, а как вход функционального блока.
Управление можно рассматривать как специфический вид входа. В случаях, когда неясно, относить ли стрелку к входу или к управлению, предпочтительно относить ее к управлению до момента, пока неясность не будет разрешена.
Стрелки выхода. Выход — это продукция или информация, получаемая в результате работы функционального блока. Каждый блок должен иметь, как минимум, один выход. Действие, которое не производит никакого четко определяемого выхода, не должно моделироваться вообще (по меньшей мере, должно рассматриваться в качестве одного из первых кандидатов на исключение из модели).
При моделировании непроизводственных предметных областей выходами, как правило, являются данные, в каком-либо виде обрабатываемые функциональным блоком. В этом случае важно, чтобы названия стрелок входа и выхода были достаточно различимы по своему
29
смыслу. Например, блок “Прием пациентов” может иметь стрелку “Данные о пациенте” как на входе, так и на выходе. В такой ситуации входящую стрелку можно назвать “Предварительные данные о пациенте”, а исходящую — “Подтвержденные данные о пациенте”.
Стрелки механизма исполнения. Механизмы являются ресурсом, который непосредственно исполняет моделируемое действие. С помощью механизмов исполнения могут моделироваться: ключевой персонал, техника и (или) оборудование. Стрелки механизма исполнения могут отсутствовать в случае, если оказывается, что они не являются необходимыми для достижения поставленной цели моделирования.
Комбинированные стрелки. В IDEF0 существует пять основных видов комбинированных стрелок: выход — вход, выход — управление, выход — механизм исполнения, выход — обратная связь на управление и выход — обратная связь на вход.
Стрелка выход — вход применяется, когда один из блоков должен полностью завершить работу перед началом работы другого блока. Так, на рис. 2.4 формирование счета должно предшествовать приему заказа.
Рис. 2.4. Комбинация стрелок выход — вход
Стрелка выход — управление отражает ситуацию преобладания одного блока над другим, когда один блок управляет работой другого. На рис. 2.5 принципы формирования инвестиционного портфеля управляют поведением брокеров на бирже.
Рис. 2.5. Комбинированная стрелка выход — управление
Стрелки выход — механизм исполнения встречаются реже и отражают ситуацию, когда выход одного функционального блока применяется в качестве оборудования для работы другого блока. На рис. 2.6 зажим, устройство, используемое для закрепления детали во время ее сборки, должно быть собрано для того, чтобы выполнить сборку детали.
Рис. 2.6. Комбинированная стрелка выход — механизм исполнения
Обратные связи на вход и на управление применяются в случаях, когда зависимые блоки формируют обратные связи для управляющих ими блоков. На рис. 2.7 получаемая от брокеров информация о текущих биржевых курсах применяется для корректировки стратегии игры на бирже.
Информация о текущих курсах
Рис. 2.7. Комбинированная стрелка выход — обратная связь на управление
Стрелка выход — обратная связь на вход обычно применяется для описания циклов повторной обработки чего-либо. Рис. 2.8 может служить примером применения стрелки такого типа. Кроме того, связи выход — обратная связь на вход могут применяться в случае, если бракованная продукция может заново использоваться в качестве сырья, как это происходит, например, при производстве оконного стек-
31
Деталь, нуждающаяся в повторной покраске
Рис. 2.8. Комбинированная стрелка выход — обратная связь на вход
ла, когда разбитое в процессе производства стекло перемалывается и переплавляется заново вместе с обыкновенным сырьем.
Разбиение и соединение стрелок. Выход функционального блока может использоваться в нескольких других блоках. Фактически чуть ли не главная ценность IDEF0 заключается в том, что эта методология помогает выявить взаимозависимости между блоками системы. Соответственно IDEF0 предусматривает как разбиение, так и соединение стрелок на диаграмме. Разбитые на несколько частей стрелки могут иметь наименования, отличающиеся от наименования исходной стрелки. Исходная и разбитые (или объединенные) стрелки в совокупности называются связанными. Такая техника обычно применяется для того, чтобы отразить использование в процессе только части сырья или информации, обозначаемых исходной стрелкой (рис. 2.9). Аналогичный подход применяется и к объединяемым стрелкам.
Рис. 2.9. Разбитая на две части и переименованная стрелка
Туннели
Понятие связанные стрелки используется для управления уровнем детализации диаграмм. Если одна из стрелок диаграммы отсутствует на родительской диаграмме (например, ввиду своей несущест- 32
венности для родительского уровня) и не связана с другими стрелками той же диаграммы, точка входа этой стрелки на диаграмму или выхода с нее обозначается туннелем. На рис. 2.10, например, стрелка “корпоративная информационная система” — важный механизм исполнения для данной диаграммы, но, возможно, она более нигде не используется в модели. Туннель в данном случае используется как альтернатива загромождению родительских диаграмм помещением на них несущественных для их уровня стрелок.
Рис. 2.10. Пример применения туннеля
Кроме того, туннели применяются для отражения ситуации, когда стрелка, присутствующая на родительской диаграмме, отсутствует в диаграмме декомпозиции соответствующего блока. На рис. 2.11 тун-
Рис. 2.11. Еще один пример применения туннеля
нель у стрелки “модуль производственного отдела” обозначает, что на диаграмме декомпозиции производственного отдела отсутствует стрелка механизма управления с соответствующим наименованием.
2.2 Построение моделей IDEF0
В этом подразделе мы рассмотрим методику построения моделей IDEF0 более подробно.
Диаграммы
На рис. 2.12 типовая диаграмма IDEF0 показана вместе с находящейся на ее полях служебной информацией. Служебная информация состоит из хорошо выделенных верхнего и нижнего колонтитулов
USED АТ:USED АТ:AUTHOR: Семенов Илья Олегович PROJECT: Отдел учета и отчетностиAUTHOR: Семенов Илья Олегович PROJECT: Отдел учета и отчетностиNSIE^d^A££7££jl0__NSIE^d^A££7££jl0__DATE: 15.03.97REV: 17.12.97DATE: 15.03.97REV: 17.12.97DBAEIDBAEICONTEXT:CONTEXT:IpUBUSATISNIpUBUSATISNMODE:MODE:TITLE:Отдел учета и отчетностиTITLE:Отдел учета и отчетностиNUMBER:NUMBER:ГГРис. 2.12. IDEF0-диаграмма со служебной информацией на поляхРис. 2.12. IDEF0-диаграмма со служебной информацией на полях
USED АТ:
USED АТ:
AUTHOR: Семенов Илья Олегович PROJECT: Отдел учета и отчетности
AUTHOR: Семенов Илья Олегович PROJECT: Отдел учета и отчетности
NSIE^d^A££7££jl0__
NSIE^d^A££7££jl0__
DATE: 15.03.97
REV: 17.12.97
DATE: 15.03.97
REV: 17.12.97
DBAEI
DBAEI
CONTEXT:
CONTEXT:
IpUBUSATISN
IpUBUSATISN
MODE:
MODE:
TITLE:Отдел учета и отчетности
TITLE:Отдел учета и отчетности
NUMBER:
NUMBER:
Г
Г
Рис. 2.12. IDEF0-диаграмма со служебной информацией на полях
Рис. 2.12. IDEF0-диаграмма со служебной информацией на полях
(заголовка и “подвала”). Элементы заголовка используются для отслеживания процесса создания модели. Элементы “подвала” отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели.
Все элементы заголовка диаграммы перечислены в табл. 2.1.
Таблица 2.1
Элементы заголовка диаграммы IDEF0
Поле
Назначение
USED АТ
Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную)
Author, date, project
Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась
Notes 1 ... 10
При ручном редактировании диаграмм пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное исправление
Status
Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса публикации с шагами пересмотра и утверждения
Working
Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы
Draft
Диаграмма достигла некоторого приемлемого для читателей уровня и готова для представления на утверждение
Recommended
Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся
Publication
Диаграмма готова для окончательной печати и публикации
Reader
ФИО читателя
Date
Дата знакомства читателя с диаграммой
Context
Набросок расположения функциональных блоков на родительской диаграмме, на котором подсвечен декомпозируемый данной диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР
Все элементы “подвала” диаграммы перечислены в табл. 2.2.
Таблица 2.2
Элементы “подвала” диаграммы IDEF0
Поле
Назначение
Node
Номер диаграммы, совпадающий с номером родительского функционального блока.
Title
Имя родительского функционального блока.
Number (еще называют С- Number)
Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия данной диаграммы будет иметь новое значение в этом поле. Как правило, C-Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного уникального идентификатора, например SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки — SDO005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели.
2.2.2 Цикл “эксперт-аналитик”
Подобно циклу автор-редактор, применяющемуся в книгоиздательском деле, диаграммы IDEF0 пересматриваются и изменяются для обеспечения точности отражения предметной области и улучшения своего качества.
Для каждого рецензента автором, как правило, подготавливается свой набор диаграмм. Предложения по изменениям и исправлениям возвращаются рецензентами автору для внесения их в модель. При возникновении разногласий между автором и рецензентом спорная диаграмма обычно рассылается всем рецензентам для достижения группового консенсуса.
Формально механизм рецензирования и модификации диаграмм поддерживается полями Status и нумерацией диаграмм, контроль истории изменений — полем Field (см. табл. 2.1).
| Построение моделей
Ни одна модель не должна строиться без ясного осознания объекта и целей моделирования. Выбранное определение цели моделирования должно отвечать на следующие вопросы:
Почему моделируется данный процесс?
Что выявит данная модель?
Как ознакомившиеся с этой моделью смогут ее применить?
Следующее предложение может служить примером формулирования цели моделирования. Выявить задачи каждого работника компании и понять в целом взаимосвязь между отдельно взятыми задачами для разработки руководства по обучению новых сотрудников.
Модели строятся для того, чтобы ответить на набор поставленных вопросов. Такие вопросы формулируются на ранних стадиях моделирования и впоследствии служат основой для четкого и краткого определения цели моделирования. Примерами таких вопросов могут быть: • Каковы задачи менеджера?
Каковы задачи клерка?
Кто контролирует работу?
Какая технология нужна для выполнения каждого шага? и т.п.
| Точка зрения
С методической точки зрения при моделировании полезно использовать мнение экспертов, имеющих разные взгляды на предметную область, однако каждая отдельно взятая модель должна разрабатываться исходя из единственной заранее определенной точки зрения. Часто другие точки зрения вкратце документируются в прикрепленных диаграммах FEO (см. ниже) исключительно для наглядности изложения.
Точку зрения нужно подбирать достаточно аккуратно, основой для выбора должна служить поставленная цель моделирования. Наименованием точки зрения может быть наименование должности, подразделения или роли (например, руководитель отдела или менеджер по продажам). Как и в случае с определением цели моделирования, четкое определение точки зрения необходимо для обеспечения внутренней целостности модели и предотвращения постоянного изменения ее структуры. Может оказаться необходимым построение моделей с разных точек зрения для детального отражения всех особенностей выделенных в системе функциональных блоков.
| Границы моделирования
Одним из положительных результатов построения функциональных моделей оказывается прояснение границ моделирования системы в целом и ее основных компонентов. Хотя и предполагается, что в
37
процессе работы над моделью будет происходить некоторое изменение границ моделирования, их вербальное (словесное) описание должно поддерживаться с самого начала для обеспечения координации работы участвующих в проекте аналитиков. Как и при определении цели моделирования, отсутствие границ затрудняет оценку степени завершенности модели, поскольку границы моделирования имеют тенденцию к расширению с ростом размеров модели.
Границы моделирования имеют два компонента: ширину охвата и глубину детализации. Ширина охвата обозначает внешние границы моделируемой системы. Глубина детализации определяет степень подробности, с которой нужно проводить декомпозицию функциональных блоков.
Чтобы облегчить правильное определение границ моделирования при разработке моделей IDEF0, существенные усилия затрачиваются на разработку и рецензирование контекстной диаграммы IDEF0 (диаграммы “самого верхнего” уровня). Иногда даже прибегают к построению дополнительной диаграммы для отображения уровня, более высокого, чем контекстный, для данной модели, что позволяет обозначить систему, внутри которой располагается объект для моделирования. Существенные затраты на разработку контекстной диаграммы вполне оправданы, поскольку она является своего рода “точкой отсчета” для остальных диаграмм модели и вносимые в нее изменения каскадом отражаются на все лежащие ниже уровни.
Когда границы моделирования понятны, становятся ясными и причины, по которым некоторые объекты системы не вошли в модель.
2 6 Выбор наименования е ' контекстного блока
Рекомендуемой последовательностью действий при построении модели “с нуля” являются: формулирование цели моделирования, выбор точки зрения, определение границ моделирования. Наименование контекстного блока — функционального блока самого высокого уровня — обобщает определение границ моделирования.
Правила подбора имени для контекстного блока в целом не отличаются от общих правил наименования функциональных блоков, поэтому для них обычно подбирают обобщающие названия, типа “Управление отделом по работе с клиентами”, “Обработка заказов” и т.п.
2.2.72.2.7Определение стрелок на контекстной диаграмме
2.2.7
2.2.7
Стрелки диаграмм IDEF0 обычно проще проектировать в следующем порядке: выход, вход, механизм исполнения, управление. Каждый функциональный блок обозначает отдельную функцию, и эта функция часто имеет ясно и кратко описываемые результаты работы. Наличие неясностей при анализе выходов того или иного функционального блока — возможный сигнал необходимости проведения реинжиниринга рассматриваемого бизнес-процесса.
Определение выходов. После идентификации возможных выходов полезно провести анализ модели на предмет покрытия ею всех возможных сценариев поведения процесса. Это означает, что если существует вероятность возникновения той или иной ситуации в ходе процесса, модель отражает возможность возникновения такой ситуации. Многие начинающие аналитики забывают отразить негативные результаты работы функциональных блоков. Например, блок “Провести экзамен по вождению” определенно произведет поток водителей, только что получивших права, но вполне правомерно ожидать и потока лиц, не сдавших экзамен. Негативные результаты часто используются в качестве обратных связей, анализ на их наличие должен проводиться для каждого блока. Важным также является необходимость включения в модель спорных стрелок, принятие решения о наличии которых в модели вполне можно переложить на плечи рецензирующих модель экспертов.
Определение входов. Входы можно рассматривать как особым образом преобразуемые функциональными блоками для производства выхода сырье или информацию. В производственных отраслях определить, как входное сырье преобразуется в готовую продукцию, обычно довольно просто. Однако при моделировании информационных потоков входной поток данных может представляться не потребляемым и не обрабатываемым вообще. Случаи, когда входящие и исходящие стрелки называются в точности одинаково, крайне редки и в основном указывают на бесполезность данного блока для системы в целом или на некорректный выбор имени для исходящей стрелки. Решением может служить применение более подробного описания для входящих и исходящих потоков данных. Например, вход может иметь название “Предварительный диагноз пациента”, а выход — “Уточненный диагноз пациента”.
Определение механизмов исполнения. После создания входов и выходов можно приступить к рассмотрению механизмов исполнения, или ресурсов, относящихся к функциональному блоку. В понятие механизма исполнения входят персонал, оборудование, информационные системы и т.п. Например, функциональный блок “Собрать деталь” может потребовать использования какого-либо оборудования, например гаечного ключа. При приеме экзаменов на водительские права механизмом исполнения является инспектор ГИБДД. Как правило, определить механизмы исполнения для функциональных блоков довольно просто.
Определение управления. Должно быть определено управление, контролирующее ход работы функционального блока. Все функциональные блоки в IDEF0 должны иметь хотя бы одно управление. В случаях, когда не ясно, относить ли стрелку к входу или к управлению, следует ее рисовать как управление. Важно помнить, что управление можно рассматривать как особую форму входа функционального блока.
Когда контекстная диаграмма представляется завершенной, попробуйте задать следующие вопросы:
Обобщает ли диаграмма моделируемый бизнес-процесс?
Согласуется ли диаграмма с границами моделирования, точкой зрения и целью моделирования?
Подходит ли выбранный уровень детализации стрелок для контекстного блока? (Обычно на контекстной диаграмме рекомендуется рисовать не более шести стрелок каждого типа.)
2.2.8 | Нумерация блоков и диаграмм
Все функциональные блоки IDEF0 нумеруются. В номерах допускается использование префиксов произвольной длины, но в подавляющем большинстве моделей используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет номер АО.
Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок АО декомпозируется в блоки А1, А2, АЗ и т.д. А1 декомпозируется в All, А12, А13 и т.д. Al 1 декомпозируется вА111,А112, А113 и т.д. Для каждого уровня декомпозиции в конец номера добавляется одна цифра.
40
2.2.92.2.9Связь между диаграммой и ее родительским функциональным блоком
2.2.9
2.2.9
Функциональный блок декомпозируется, если необходимо детально описать его работу. При декомпозиции блока полезно рассмотреть его жизненный цикл, это поможет определить функциональные блоки получающейся “детской” диаграммы. Например, жизненный цикл блока “Поджарить бифштекс” может выглядеть как следующая последовательность: “Подготовить продукты”, “Отбить мясо”, “Разогреть масло” и т.д.
При моделировании IDEF0 важно иметь в виду, что граница детской диаграммы есть граница родительского функционального блока. Это означает, что вся работа выполняется блоками самого нижнего уровня. В отличие от иерархии, применяемой в структурном программировании, блоки верхнего уровня не являются субъектами управления для блоков нижнего уровня. Это означает, что в IDEF0 дети — это те же объекты, что и их родители, только показанные с большей детализацией. Действия генерального директора компании на диаграммах IDEF0 могут отражаться рядом с действиями простых рабочих.
На концах граничных стрелок (начинающихся или заканчивающихся за пределами диаграммы) детских диаграмм помещаются коды ICOM, чтобы показать, где находится соответствующая стрелка на родительской диаграмме (рис. 2.13). Они нужны для проверки целостности модели и могут быть полезны, когда порядок расположения стрелок на детской диаграмме отличается от порядка их расположения на родительской диаграмме. Код ICOM состоит из латинской буквы I, С, О или М и числа, показывающего расположение стрелки на родительской диаграмме в порядке сверху вниз или слева направо.
Рис. 2.13. ICOM-коды на граничных стрелкахРис. 2.13. ICOM-коды на граничных стрелкахС1 С2
Рис. 2.13. ICOM-коды на граничных стрелках
Рис. 2.13. ICOM-коды на граничных стрелках
И
I2
2.2.102.2.10Два подхода к началу моделирования (”в ширину” и “в глубину”)
2.2.10
2.2.10
Модели могут проектироваться с использованием подхода “в ширину”, когда каждая диаграмма максимально детализируется перед своей декомпозицией, и с подходом “в глубину”, когда сначала определяется иерархия блоков, а затем создаются соединяющие их стрелки. Естественно, возможно применение комбинации этих подходов, причем иерархия блоков может иногда немного измениться после того, как нарисованы стрелки. Это происходит из-за того, что создание стрелок может изменить понимание внутренней архитектуры моделируемого объекта.
Когда остановиться?
Сформулированная цель моделирования содержит вопросы, на которые должна отвечать модель. Когда становится возможным получение ответов на них с помощью модели, модель считается удовлетворяющей поставленным требованиям и рассматривается как завершенная. При построении декомпозиции первого уровня нужно следить за тем, чтобы все блоки на диаграмме лежали внутри определенных ранее границ моделирования. Перед декомпозированием блока нужно удостовериться, не приведет ли это к превышению установленной ранее глубины детализации для данной модели. Еще одно правило состоит в том, что моделирование IDEF0 должно продолжаться до тех пор, пока стрелки предшествования (вход и выход) преобладают на диаграммах.
При необходимости дальнейшей детализации отдельных процессов могут быть использованы диаграммы IDEF3.
| Другие диаграммы IDEF0
В дополнение к контекстным диаграммам и диаграммам декомпозиции при разработке и представлении моделей могут применяться другие виды IDEFO-диаграмм.
Дерево модели. Это обзорная диаграмма, показывающая структуру всей модели. На рис. 2.14 приведен фрагмент такой диаграммы. Обычно вершина дерева соответствует контекстному блоку, под вершиной выстраивается вся иерархия блоков модели. Однако не запрещается назначать вершиной произвольный блок, помещая под ним все 42
его детские блоки. Из-за высокой итеративности функционального моделирования можно ожидать, что дерево модели будет неоднократно изменяться существенным образом до тех пор, пока не будет получена его стабильная версия. Обзор модели с использованием дерева помогает сконцентрироваться на функциональной декомпозиции модели.
Рис. 2.14. Фрагмент дерева модели
Презентационные диаграммы. Презентационные диаграммы (For Exposition Only diagrams — FEO diagrams) часто включают в модели, чтобы проиллюстрировать другие точки зрения или детали, выходящие за рамки традиционного синтаксиса IDEF0. Диаграммы FEO допускают нарушение любых правил построения диаграмм IDEF0 в целях выделения важных с точки зрения аналитика частей модели. Естественно, если диаграмма FEO включена в модель исключительно для отображения другой точки зрения на систему, она скорее всего будет выглядеть как обыкновенная диаграмма IDEF0, удовлетворяя всем ограничениям IDEF0.
Один из способов использования FEO-диаграмм состоит в отделении функционального блока от его окружения посредством создания диаграммы с единственным блоком и всеми относящимися к нему стрелками наподобие контекстной диаграммы (рис. 2.15). Это может оказаться полезным в ситуациях, когда необходимо быстро получить информацию об интерфейсе (стрелках) функционального блока, а соответствующая диаграмма декомпозиции содержит слишком много объектов.
Кроме того, встречаются следующие виды презентационных диаграмм:
копия диаграммы IDEF0, которая содержит все функциональные блоки, и стрелки, относящиеся только к одному из функциональных блоков, — это позволяет отразить взаимодействие между этим блоком и другими объектами диаграммы;
Рис. 2.15. Диаграмма FEO для выделения функционального блока и его стрелок
копия диаграммы IDEF0, которая содержит все функциональные блоки, и стрелки, непосредственно относящиеся только к входу и (или) к выходу родительского блока;
различные точки зрения, как правило, на глубину одного уровня декомпозиции.
Взаимосвязь моделей IDEF0 и IDEF3
Действия, выполняемые в функциональных блоках
Как правило, при работе с пластиковой картой клиент не производит всех доступных ему при этом действий, выполняя ограниченный набор операций. Например, при оплате покупки не производится сня- 44
тие наличных, а при проверке баланса состояние счета вообще не изменяется (это верно, конечно, только в случае, если карта обслуживается приличным банком). Мы можем декомпозировать функциональный блок “Обработка операций с пластиковыми картами”, создав дополнительные блоки для оплаты покупок, снятия наличных, проверки баланса и т.п. Вместо этого можно создать отдельные модели IDEF3 для каждого из этих действий. Это, в частности, полезно, если в дальнейшем предполагается заняться оцениванием соответствующих операций по тем или иным параметрам.
Более простой альтернативой предложенным выше двум подходам может служить так называемая таблица вызова (activation table), описывающая различные комбинации входов, выходов, управлений и механизмов исполнения для каждого способа вызова функционального блока на исполнение. Вызов — это уникальная конфигурация значений входа, управления и требований к механизмам исполнения (табл. 2.3). Каждому вызову присваивается уникальное имя в пределах блока и перечисляются значения различных стрелок. Комбинация значений стрелок должна быть уникальной для каждого вызова, из чего следует, что для каждого вызова любые две одинаковые стрелки не могут иметь одинаковых значений.
Таблица 2.3
Таблица вызовов для блока “Подсчитать наличные”
Вызов
Стрелка
Значение стрелки
Значительная сумма наличных денег
Наличные деньги
Более 1 000 руб.
Счетчик банкнот
1 требуется
Мелкая сумма наличных денег
Наличные деньги
Не более 1000 руб.
Счетчик банкнот
0 требуется
Информация о вызовах из табл. 2.3 также дает определенную информацию о стрелках управления данного функционального блока. Например, мы можем предположить, что политика банка при подсчете сумм наличных заключается в использовании счетчиков банкнот для сумм, превышающих 1000 руб.
2 3 2 Создание моделей IDEF3 * ' для отображения блоков IDEF0
Для иллюстрирования вызовов листовых функциональных блоков IDEF0 (т.е. блоков, не имеющих диаграмм декомпозиции) может быть применено построение моделей IDEF3. Если развитие модели IDEF0
45
предполагается аналитиками именно таким способом, моделями IDEF3 должен быть тщательно документирован каждый возможный вызов функционального блока. Соответствующие таблицы вызовов (наподобие табл. 2.3) можно будет получить впоследствии из соответствующих диаграмм IDEF3.
* * *
Ит^к, методология функционального моделирования IDEF0 — это технология описания системы в целом как множества взаимозависимых действий, или функций. IDEF0 имеет функциональную направленность. IDEF0 — функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. Одной из основных идей моделей IDEF0 является построение двух видов моделей: “как есть” и “как должно быть”. Это нужно при проведении реинжиниринга бизнес-процессов организации. Кроме того, IDEF0 обеспечивает удобный язык обмена информацией о моделируемой системе.
ГЛАВАГЛАВАСТРУКТУРНЫЙ анализ ПОТОКОВ ДАННЫХ (DFD — DATA FLOW DIAGRAMS)
ГЛАВА
ГЛАВА
3.13.1Назначение диаграмм потоков данных
3.1
3.1
Так же, как и диаграммы IDEF0, диаграммы потоков данных моделируют систему как набор действий, соединенных друг с другом стрелками. Диаграммы потоков данных также могут содержать два новых типа объектов: объекты, собирающие и хранящие информацию — хранилища данных и внешние сущности — объекты, которые моделируют взаимодействие с теми частями системы (или другими системами), которые выходят за границы моделирования. На рис. 3.1 приведен внешний вид диаграммы потоков данных.
В отличие от стрелок в IDEF0, которые иллюстрируют отношения, стрелки в DFD показывают, как объекты (включая и данные) реально перемещаются от одного действия к другому. Это представление потока вкупе с хранилищами данных и внешними сущностями обеспечивает отражение в DFD-моделях таких физических характеристик системы, как движение объектов (потоки данных), хранение объектов (хранилища данных), источники и потребители объектов (внешние сущности).
Построение DFD-диаграмм в основном ассоциируется с разработкой программного обеспечения, поскольку нотация DFD изначально была разработана для этих целей. В частности, графическое изображение объектов на DFD-диаграммах этой главы соответствует принятому Крисом Гейном (Chris Gane) и Тришем Сарсоном (Trish Sarson), авторами DFD-метода, известного как метод Гейна — Сарсона. Другой распространенной нотацией DFD является так называемый метод Йордана — Де Марко (Yourdon — DeMarco).
ДанныеИнформация
Рис. 3.1. Пример диаграммы DFD
Синтаксис и семантика диаграмм потоков данных
В отличие от IDEF0, рассматривающего систему как множество взаимопересекающихся действий, в названиях объектов DFD-диаграмм преобладают имена существительные. Контекстная DFD-диаграмма часто состоит из одного функционального блока и нескольких внешних сущностей. Функциональный блок на этой диаграмме обычно имеет имя, совпадающее с именем всей системы (рис. 3.2).
Добавление на диаграмму внешних ссылок не изменяет фундаментального требования, что модель должна строиться с единственной точки зрения и должна иметь четко определенные цель и границы, что уже обсуждалось ранее.
Рис. 3.2. Контекстная диаграмма DFD
| Функциональные блоки
Функциональный блок DFD моделирует некоторую функцию, которая преобразует какое-либо сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Хотя функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они
Департамент по работес пластиковыми картамиДепартамент по работес пластиковыми картамиПерсоналОборудованиеПерсоналОборудованиеРесурсыРесурсыРис. 3.3. Элемент DFD-диаграммы, построенной в нотации Гейна — СарсонаРис. 3.3. Элемент DFD-диаграммы, построенной в нотации Гейна — Сарсонапочти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как IDEF0. В некоторых интерпретациях нотации DFD Гейна — Сарсона механизмы исполнения IDEF0 моделируются как ресурсы и изображаются в нижней части прямоугольника (рис. 3.3).почти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как IDEF0. В некоторых интерпретациях нотации DFD Гейна — Сарсона механизмы исполнения IDEF0 моделируются как ресурсы и изображаются в нижней части прямоугольника (рис. 3.3).
Департамент по работес пластиковыми картами
Департамент по работес пластиковыми картами
ПерсоналОборудование
ПерсоналОборудование
Ресурсы
Ресурсы
Рис. 3.3. Элемент DFD-диаграммы, построенной в нотации Гейна — Сарсона
Рис. 3.3. Элемент DFD-диаграммы, построенной в нотации Гейна — Сарсона
почти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как IDEF0. В некоторых интерпретациях нотации DFD Гейна — Сарсона механизмы исполнения IDEF0 моделируются как ресурсы и изображаются в нижней части прямоугольника (рис. 3.3).
почти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как IDEF0. В некоторых интерпретациях нотации DFD Гейна — Сарсона механизмы исполнения IDEF0 моделируются как ресурсы и изображаются в нижней части прямоугольника (рис. 3.3).
Внешние сущности
Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы (функционируя как поставщик) и принимать выходы (функционируя как по-
1 Клиент1 КлиентРис. 3.4. Обозначениевнешней сущностиРис. 3.4. Обозначениевнешней сущностилучатель). Внешние сущности изображаются как прямоугольники (рис. 3.4) и обычно размещаются у краев диаграммы. Одна внешняя сущность может быть размещена на одной и той же диаграмме в нескольких экземплярах. Этот прием полезно применять для сокращения количества линий, соединяющих объекты на диаграмме.
1 Клиент
1 Клиент
Рис. 3.4. Обозначениевнешней сущности
Рис. 3.4. Обозначениевнешней сущности
Стрелки (потоки данных)
Стрелки описывают передвижение (поток) объектов от одной части системы к другой. Поскольку все стороны обозначающего функциональный блок DFD прямоугольника равнозначны (в отличие от IDEF0), стрелки могут начинаться и заканчиваться в любой части блока. В DFD также используются двунаправленные стрелки, которые нужны для отображения взаимодействия между блоками (например, диалога типа приказ — результат выполнения). На рис. 3.5 двунаправленная стрелка обозначает взаимный обмен информацией между департаментами маркетинга и рекламы и пластиковых карт.
Рис. 3.5. Двунаправленный поток между блоком и внешней сущностьюРис. 3.5. Двунаправленный поток между блоком и внешней сущностью
Рис. 3.5. Двунаправленный поток между блоком и внешней сущностью
Рис. 3.5. Двунаправленный поток между блоком и внешней сущностью
Хранилища данных
В то время как потоки данных представляют объекты в процессе их передвижения, хранилища данных моделируют их во всех остальных состояниях. При моделировании производственных систем хранилищами данных служат места временного складирования, где хранится продукция на промежуточных стадиях обработки. В инфор
1
Заказы
Рис. 3.6. Обозначение хранилища данных на DFD-диаграммеРис. 3.6. Обозначение хранилища данных на DFD-диаграммемационных системах хранилища данных представляют любой механизм, который поддерживает хранение данных для их промежуточной обработки. На рис. 3.6 приведен пример обозначения хранилищ данных на DFD-диаграммах.
Рис. 3.6. Обозначение хранилища данных на DFD-диаграмме
Рис. 3.6. Обозначение хранилища данных на DFD-диаграмме
Ветвление и объединение
Стрелки на DFD-диаграммах могут быть разбиты (разветвлены) на части, и при этом каждый получившийся сегмент может быть переименован таким образом, чтобы показать декомпозицию данных, переносимых данным потоком (рис. 3.7).
Почтовый ’ индекс
Ор.2
Проверить почтовый индекс
Ор.1
Записать
Адрес
Городг
Ор.з
Проверить город
адрес клиента
клиента
Улица_
Ор.4
Проверить улицу
Рис. 3.7. Разветвление стрелки, иллюстрирующее декомпозицию данных
Рис. 3.8. Объединение потока в одинРис. 3.8. Объединение потока в один
Рис. 3.8. Объединение потока в один
Рис. 3.8. Объединение потока в один
Стрелки могут и соединяться между собой (объединяться) для формирования так называемых комплексных объектов. Пример такого объединения приведен на рис. 3.8.
3.33.3Построение диаграмм потоков данных
3.3
3.3
| Два подхода к построению DFD-моделей
Диаграммы DFD можно строить с использованием подхода, аналогичного структурному методу анализа и проектирования, применяемому в IDEF0. Вначале строится модель физической реализации реальной системы, которая используется пользователями в настоящее время. Затем создается логическая модель текущего состояния системы для моделирования основных требований существующей системы. После этого создается новая логическая модель для отражения основных параметров предлагаемой разрабатываемой системы. Наконец, создается новая физическая модель, реализующая логическую модель новой системы.
В настоящее время при разработке информационных систем завоевывает все большую популярность альтернативный подход, известный как разделение событий, в котором для моделирования системы строится несколько моделей DFD. Вначале строится логическая модель, отображающая систему как набор действий и описывающая, что должна делать система.
52
Затем строится модель окружения, описывающая систему как объект, отвечающий на события, порождаемые внешними сущностями. Такая модель обычно состоит из описания назначения системы, одной диаграммы контекстного уровня и списка событий. Контекстная диаграмма содержит один функциональный блок, представляющий систему в целом, и внешних сущностей (окружения), с которыми система взаимодействует.
На заключительном этапе создается модель поведения, показывающая, как система обрабатывает те или иные события. Эта модель начинается с единственной диаграммы с одним функциональным блоком на каждый ответ системы на событие, описанное в модели окружения. Хранилища данных в модели поведения используются для моделирования данных, которые должны сохраняться в промежутках между обработкой событий. Потоки применяются для соединения элементов диаграмм между собой и для проверки согласованности моделей поведения и окружения.
При подготовке такого рода моделей к различным презентациям обычно необходима их “чистка”. При этом может применяться как создание упрощенных родительских диаграмм посредством объединения нескольких функциональных блоков в один, так и декомпозиция некоторых элементов для более ясного восприятия модели.
| Нумерация объектов
В DFD каждый номер функционального блока может включать в себя префикс, номер родительской диаграммы и собственно номер объекта (рис. 3.9). Номер объекта уникальным образом идентифицирует функциональный блок на диаграмме. Номер родительской диаграммы и номер объекта в совокупности обеспечивают уникальную идентификацию каждого блока модели.
Уникальные номера присваиваются также каждому хранилищу данных и каждой внешней сущности вне зависимости от расположения объекта на диаграм-
_г ПрефиксНомер объекта
ме. Каждый номер храни--
лища данных содержитА37
префикс D (от английско-/
го Data Store) и уникаль-Номер диаграммы
ный номер хранилища врИСе 3,9. Компоненты номера
модели (например, D3).функционального блока DFD
Аналогично каждый номер каждой внешней сущности содержит префикс Е (от английского External entity) и уникальный номер сущности в модели (например, Е5).
* * *
Итак, диаграммы потоков данных (DFD) обеспечивают удобный способ описания передаваемой информации как между частями моделируемой системы, так и между системой и внешним миром. Это качество определяет область применения DFD — они используются для создания моделей информационного обмена организации, например модели документооборота. Кроме того, различные вариации DFD широко применяются при построении корпоративных информационных систем.
4ГЛАВА4ГЛАВА4.14.11 About I his I utorisl1 About I his I utorislо Business Modeling£ Overview 'о Business Modeling£ Overview '3Underst£mdmQ the Workpiece* Building the Context Diagramj- Decomposing Use Model3Underst£mdmQ the Workpiece* Building the Context Diagramj- Decomposing Use Model6 Enhancing the Model6 Enhancing the Model1КЙ51—I1КЙ51—I? Other №F9* Diagramsa Adding Value to” the Modeling Effort9 PrintingBPwin Diagrams? Other №F9* Diagramsa Adding Value to” the Modeling Effort9 PrintingBPwin DiagramsЮ ReportingЮ ReportingCopyright 1998 PLATINUM technologyCopyright 1998 PLATINUM technology
4
ГЛАВА
4
ГЛАВА
4.1
4.1
1 About I his I utorisl
1 About I his I utorisl
о Business Modeling
£ Overview '
о Business Modeling
£ Overview '
3Underst£mdmQ the Workpiece
* Building the Context Diagram
j- Decomposing Use Model
3Underst£mdmQ the Workpiece
* Building the Context Diagram
j- Decomposing Use Model
6 Enhancing the Model
6 Enhancing the Model
1КЙ51—I
1КЙ51—I
? Other №F9
* Diagrams
a Adding Value to
” the Modeling Effort
9 Printing
BPwin Diagrams
? Other №F9
* Diagrams
a Adding Value to
” the Modeling Effort
9 Printing
BPwin Diagrams
Ю Reporting
Ю Reporting
Copyright 1998 PLATINUM technology
Copyright 1998 PLATINUM technology
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IDEF-МОДЕЛИРОВАНИЯ
Platinum BPWin — руководство пользователя программного пакета компьютерной поддержки технологии моделирования IDEF
В этом подразделе приведено описание работы с наиболее популярным в настоящее время пакетом IDEF-моделирования Platinum BPWin. С использованием BPWin получено большинство иллюстраций этой книги. В приложении приведено краткое описание работы с другим пакетом, поддерживающим технологию IDEF-моделирования — Design/IDEF.
BPwin Tutorial
Click on the blue labels to find out about this topic.Click a Try It button to perform the task using BPwin.
Рис. 4.1. Главное окно “Наставника”
Platinum BPWin имеет в своем составе программу “Наставник”, позволяющую быстро ознакомиться как с основами IDEF-моделирования, так и с их реализацией в BPWin. Приведенное ниже описание работы с BPWin по сути является сокращенным вариантом учебного курса, предлагаемого пользователям программой “Наставник”. На рис. 4.1 изображено главное окно этой программы.
Обучающая программа построена на выполнении типичных для BPWin задач делового моделирования. Каждый раздел обучающей программы строится на информации, полученной при изучении предыдущего раздела, поэтому рекомендуется изучать их в предлагаемой последовательности. Рассмотрим последовательно разделы, предлагаемые “Наставником”.
Краткий обзор
Этот подраздел предназначен для тех, кто плохо знаком с деловым моделированием. Он начинается с обзора, охватывающего базовые идеи делового моделирования и основную терминологию. Каждый подраздел этой темы также содержит описание типовых меню и диалогов, с которыми придется работать при выполнении различных задач. Для более подробных пояснений по содержанию экранов достаточно просто щелкнуть на соответствующей области.
Рис. 4.2. Кнопка “Try It”
После ознакомления с кратким обзором можно приступить к выполнению заданий на типовой модели, предоставляемой совместно с обучающей программой. Для этого на последней странице изучаемой темы всегда появляется Кнопка “Try It” — “попробовать” (рис. 4.2). Щелчок на ней позволяет перейти к пошаговому выполнению практических упражнений. Типовые модели подготавливаются и используются совместно с тренировочными упражнениями.
После нажатия кнопки “Try It” обучающая программа пред-
0 Try и ВВЕЗ0 Try и ВВЕЗStep 2: Name the Context ActivityNotice that a blank activity box has been created and the title bar shows the new model name and:[(A-0) - Order Fulfillment]Right-click on the context activity.The shortcut menu is displayed.* Select Name Editor...The IDEFO Name Properties dialog box is displayed. The cursor is in the name entry field.Type:PROCESS[Enter key]ORDERthen press OK.^-The (Enter key] places each word on a separate line.The context activity is now named. ■Click Next Step >[jfprgj^Step 2: Name the Context ActivityNotice that a blank activity box has been created and the title bar shows the new model name and:[(A-0) - Order Fulfillment]Right-click on the context activity.The shortcut menu is displayed.* Select Name Editor...The IDEFO Name Properties dialog box is displayed. The cursor is in the name entry field.Type:PROCESS[Enter key]ORDERthen press OK.^-The (Enter key] places each word on a separate line.The context activity is now named. ■Click Next Step >[jfprgj^Рис. 4.3. Подсказка “Наставника”Рис. 4.3. Подсказка “Наставника”ставляет набор последователь
0 Try и ВВЕЗ
0 Try и ВВЕЗ
Step 2: Name the Context Activity
Notice that a blank activity box has been created and the title bar shows the new model name and:
[(A-0) - Order Fulfillment]
Right-click on the context activity.
The shortcut menu is displayed.
* Select Name Editor...
The IDEFO Name Properties dialog box is displayed. The cursor is in the name entry field.
Type:
PROCESS[Enter key]
ORDER
then press OK.
^-The (Enter key] places each word on a separate line.
The context activity is now named. ■
Click Next Step >
[jfprgj^
Step 2: Name the Context Activity
Notice that a blank activity box has been created and the title bar shows the new model name and:
[(A-0) - Order Fulfillment]
Right-click on the context activity.
The shortcut menu is displayed.
* Select Name Editor...
The IDEFO Name Properties dialog box is displayed. The cursor is in the name entry field.
Type:
PROCESS[Enter key]
ORDER
then press OK.
^-The (Enter key] places each word on a separate line.
The context activity is now named. ■
Click Next Step >
[jfprgj^
Рис. 4.3. Подсказка “Наставника”
Рис. 4.3. Подсказка “Наставника”
ных подсказок (Que Cards) для облегчения выполнения задания, при
этом в качестве наглядных примеров используется типовая модель (рис. 4.3).
В “Наставнике” имеется также возможность перейти непосредственно к выполнению практических упражнений без просмотра теоретического материала. Для этого достаточно нажать кнопку Try It в любом разделе главного меню “Наставника”.
4.1.24.1.2Проверка правильности выполнения задания
4.1.2
4.1.2
В “Наставнике” существует возможность проверки правильности выполнения каждой задачи — для этого достаточно нажать кнопку “Check”. Проверка покажет, как должна выглядеть модель в случае, если были бы выполнены все рекомендации обучающей программы. Чтобы возвратиться к кнопке “Try It”, на подсказке достаточно закрыть окно просмотра результатов работы. Чтобы возвратиться к обучающей программе, достаточно щелкнуть по кнопке “Done” окна “Try It”.
4.1.34.1.3Зачем нужно усовершенствование бизнес-процессов?
4.1.3
4.1.3
Сегодня в сложном и постоянно изменяющемся мире интересы деловых людей должны быть сосредоточены на процессе удовлетворения потребностей клиентов. Работаете ли Вы в маленькой или большой организации, процесс производства, поставки товаров или услуг определяют качество и в конечном итоге успех Вашего бизнеса.
Усовершенствование бизнес-процессов включает отображение и моделирование всех стадий деятельности компании для лучшего понимания и усовершенствования проводимых операций. Можно моделировать деятельность организации в целом или ее части, например процесс формирования требований к принятым в организации информационным технологиям.
Деловое моделирование
Моделирование — один из наиболее эффективных методов для понимания и установления связи между деловыми правилами и биз- нес-процессами компании. В процессе моделирования устраняются посторонние детали, а важная информация выдвигается на первый план для упрощения изучения системы.
Графика (блоки и стрелки) используется для улучшения понимания структуры модели, поэтому большинство людей думают о моделях как об иллюстрированных представлениях. С использованием моделирования бизнес-процессов Вы можете оценить систему так широко, чтобы все аспекты работы вашей организации могли быть проанализированы, поняты и, возможно, что наиболее важно, сообщены другим.
Что такое BPWin?
BPWin — мощный инструмент моделирования для анализа, документирования и понимания комплексных бизнес-процессов.
Моделирование полезно:
для устранения избыточных или ненужных блоков (функций);
для сокращения затрат;
для совершенствования работы компании;
для повышения качества обслуживания клиентов.
| Модель BPWin
С использованием BPWin строятся диаграммы бизнес-процессов, ясно показывающие бизнес-процессы (блоки), результаты их работы и ресурсы, необходимые для их функционирования. BPWin-модель обеспечивает объединенную картину того, как организация добивается выполнения своих целей, от маленьких отделов до всей компании в целом. На рис. 4.4 изображено главное окно программы BPWin.
Также можно использовать BPWin для моделирования потоков работ, потоков процессов и потоков данных.
Dffi^__ТТШПаШя!^^Dffi^__ТТШПаШя!^^ВеройВерой®4®4|Д PLATINUM BPwtn [|A 0| Фнжциондяьиый 6:юк • g [Г даонам дин: рампа UH Т (I bp11||Д PLATINUM BPwtn [|A 0| Фнжциондяьиый 6:юк • g [Г даонам дин: рампа UH Т (I bp11|RDORDOAUTHOR:PROJECT! gAUTHOR:PROJECT! gРАТЕ! 24.07ЛО fcvgfWlРАТЕ! 24.07ЛО fcvgfWlREV: 01.08.00REV: 01.08.00iNQTESi 1 ? З.Л.5.Л7 J.i lliNQTESi 1 ? З.Л.5.Л7 J.i llDRAFT RECOMMENDED риккдтюы-DRAFT RECOMMENDED риккдтюы-BEABfiLBEABfiLJ2AIEJ2AIECONTEXT:TOPCONTEXT:TOPуправленияуправленияФункциональный блокФункциональный блок
Dffi^__
ТТШПаШя!^^
Dffi^__
ТТШПаШя!^^
Верой
Верой
®4
®4
|Д PLATINUM BPwtn [|A 0| Фнжциондяьиый 6:юк • g [Г даонам дин: рампа UH Т (I bp11|
|Д PLATINUM BPwtn [|A 0| Фнжциондяьиый 6:юк • g [Г даонам дин: рампа UH Т (I bp11|
RDO
RDO
AUTHOR:
PROJECT! g
AUTHOR:
PROJECT! g
РАТЕ! 24.07ЛО fcvgfWl
РАТЕ! 24.07ЛО fcvgfWl
REV: 01.08.00
REV: 01.08.00
iNQTESi 1 ? З.Л.5.Л7 J.i ll
iNQTESi 1 ? З.Л.5.Л7 J.i ll
DRAFT RECOMMENDED риккдтюы-
DRAFT RECOMMENDED риккдтюы-
BEABfiL
BEABfiL
J2AIE
J2AIE
CONTEXT:
TOP
CONTEXT:
TOP
управления
управления
Функциональный блок
Функциональный блок
механизма
NODE!NODE![TITLE:[TITLE:A-0A-0Функциональный блокФункциональный блок
NODE!
NODE!
[TITLE:
[TITLE:
A-0
A-0
Функциональный блок
Функциональный блок
Рис. 4.4. Главное окно BPWin
4.1.74.1.74.1.84.1.8BPWin поддерживает три методологии моделирования: функциональное моделирование (IDEF0);BPWin поддерживает три методологии моделирования: функциональное моделирование (IDEF0);BPwinBPwin^1 woutiiketo^ £reate model"-^ gushes» Process (IDEFO)■• Г ^orkfow№;-;Г Дрект^^л'v^ ~; С Openirpdelfr^^х^^f7 0«р1^#й dialog сп^ ,ОК |, Cancel| / < Hehv | '^1 woutiiketo^ £reate model"-^ gushes» Process (IDEFO)■• Г ^orkfow№;-;Г Дрект^^л'v^ ~; С Openirpdelfr^^х^^f7 0«р1^#й dialog сп^ ,ОК |, Cancel| / < Hehv | 'Рис. 4.5. Выбор нотации моделированияРис. 4.5. Выбор нотации моделирования
4.1.7
4.1.7
4.1.8
4.1.8
BPWin поддерживает три методологии моделирования: функциональное моделирование (IDEF0);
BPWin поддерживает три методологии моделирования: функциональное моделирование (IDEF0);
BPwin
BPwin
^1 woutiiketo
^ £reate model"
-^ gushes» Process (IDEFO)■
• Г ^orkfow№;-
;Г Дрект^^л'v^ ~
; С Openirpdelfr^^х^^
f7 0«р1^#й dialog сп^ ,
ОК |, Cancel| / < Hehv | '
^1 woutiiketo
^ £reate model"
-^ gushes» Process (IDEFO)■
• Г ^orkfow№;-
;Г Дрект^^л'v^ ~
; С Openirpdelfr^^х^^
f7 0«р1^#й dialog сп^ ,
ОК |, Cancel| / < Hehv | '
Рис. 4.5. Выбор нотации моделирования
Рис. 4.5. Выбор нотации моделирования
Методологии моделирования, поддерживаемые BPWin
описание бизнес-процес- сов (IDEF3);
диаграммы потоков данных (DFD).
Поддержкой трех методологий моделирования в одной программе BPWin объединяет три ключевых подхода к моделированию бизнес-процессов, что вполне удовлетворяет потребности как системных аналитиков, так и специалистов- технологов.
При создании новой модели достаточно просто выбрать нужную методологию в диалоговом окне, появляющемся каждый раз при создании новой модели BPWin (рис. 4.5).
Функциональное моделирование (IDEF0)
Функциональное моделирование является технологией анализа системы в целом как набора связанных между собой действий или функций. Действия системы анализируются независимо от объекта (ов), который обеспечивает их исполнение. Моделировать деловой процесс можно исходя из различных перспектив и временных рамок. Например, Вы можете смоделировать процесс заказа услуг клиентом так, как Вы видите его в идеале, а не так, как это происходит в настоящее время.
Рис. 4.6. Пример диаграммы IDEFO
С функциональной точки зрения Вы можете также абстрагироваться от проблем физической реализации модели.
На рис. 4.6 показан пример простой диаграммы IDEF0.
Диаграммы потоков данных (DFD)
Диаграммы потоков данных (DFD) моделируют системы как взаимосвязанный набор действий, которые обрабатывают данные в “хранилище” как внутри, так и вне границ моделируемой системы. Диаграммы потоков данных обычно применяются при моделировании информационных систем.
На рис. 4.7 приведен пример диаграммы потоков данных.
Стрелки в DFD показывают, как объекты (данные) фактически взаимодействуют между собой. Это представление, объединяющее хранимые в системе данные и внешние для системы объекты, дает DFD-моделям большую гибкость для отображения физических характеристик системы, таких, как проблемы обмена данными, разработка схем их хранения и обработки.
Описание бизнес-процессов (IDEF3)
Методология IDEF3 — это методология моделирования, предназначенная для обеспечения структурированного подхода к описанию бизнес-процесса как упорядоченной последовательности событий 61
ДанныеИнформация
Рис. 4.7. Пример диаграммы DFD
Рис. 4.8. Пример диаграммы IDEF3
одновременно с описанием любых участвующих в бизнес-процессе объектов и относящихся к ним правил.
Создание диаграмм потоков работ — техника, хорошо подходящая для сбора данных о системе и применяющаяся как часть структурного подхода к анализу и проектированию системы. В отличие от других методов моделирования бизнес-процессов, IDEF3 требует строгого использования синтаксиса и семантики во избежание получения неполного или противоречивого описания системы.
На рис. 4.8 приведен пример диаграммы IDEF3.
Диаграммы IDEF3 применяются:
для улучшения понимания результатов моделирования бизнес- процессов;
для определения момента окончания моделирования;
для сбора информации о схеме работы моделируемой компании.
Построение моделей IDEF3 иногда позволяет упростить функциональное моделирование системы по методологии IDEF0 и получило заслуженное признание как довольно удобный способ анализа потенциальных усовершенствований системы. Диаграммы IDEF3 обеспечивают дискретность моделирования процесса, что может использоваться для контроля за ходом выполнения работ.
4.1.11 | Когда и какие методологии применять?
IDEF0 лучше всего применять как средство анализа и логического моделирования систем, что, как правило, выполняется на ранних стадиях работы над проектом. Данные анализа, полученные с использованием моделирования IDEF0, обычно используются на стадии разработки моделей IDEF3 и диаграмм потоков данных DFD (рис. 4.9).
ANALISYSREQ’sDESIGNANALISYSREQ’sDESIGNJan Feb Mar Apr May Jun Jul Aug SepJan Feb Mar Apr May Jun Jul Aug SepРис. 4.9. Временная шкала использования разных методологий моделированияРис. 4.9. Временная шкала использования разных методологий моделирования
ANALISYS
REQ’s
DESIGN
ANALISYS
REQ’s
DESIGN
Jan Feb Mar Apr May Jun Jul Aug Sep
Jan Feb Mar Apr May Jun Jul Aug Sep
Рис. 4.9. Временная шкала использования разных методологий моделирования
Рис. 4.9. Временная шкала использования разных методологий моделирования
4.1.124.1.12Рабочее место BPWinРабочее место BPWin
4.1.12
4.1.12
Рабочее место BPWin
Рабочее место BPWin
Рабочее место BPWin выполнено в виде рабочего стола, состоящего из нескольких окон. На рабочем столе размещены: • меню;
стандартная панель инструментов;
панель инструментов ModelMart;
дерево модели;
область для рисования;
панель инструментов BPWin;
статусная строка.
Панель Меню BPWin. Панель Меню BPWin соответствует стандартам Windows и обеспечивает доступ ко всем функциям BPWin. Некоторые из них:
Печать. Чтобы открыть окно печати, на панели Меню выберите File, затем Print.
Масштаб. На панели Меню выберите View, затем измените масштаб изображения для активной диаграммы или для всех диаграмм в модели на тот, который Вам нужен.
Стандартная панель инструментов. Стандартная панель инструментов (рис. 4.10) обеспечивает быстрый доступ к часто выполняемым задачам.
Рис. 4.10. Стандартная панель инструментов BPWinРис. 4.10. Стандартная панель инструментов BPWin
Рис. 4.10. Стандартная панель инструментов BPWin
Рис. 4.10. Стандартная панель инструментов BPWin
Как и любая другая панель инструментов BPWin, стандартная панель может быть расположена в любой стороне экрана или находиться в любом месте в области диаграммы. Вы можете также показывать или скрывать ее, используя функцию View на панели Меню.
4.1.13 | Дерево модели
Дерево модели BPWin (рис. 4.11) — мощный инструмент, который используется для просмотра структуры модели и изменения любых объектов диаграмм в любой открытой модели BPWin. Одновре-
65
'■PLATINUM BPwin - ИА21 Ведение лицевых карточек n'■PLATINUM BPwin - ИА21 Ведение лицевых карточек nЛ^> Eh ModsIMart. Edt View Ite^ Report Tools ^rdbwЛ^> Eh ModsIMart. Edt View Ite^ Report Tools ^rdbwI f^j21M<d±lzl5^ II f^j21M<d±lzl5^ I|®1НМ
'■PLATINUM BPwin - ИА21 Ведение лицевых карточек n
'■PLATINUM BPwin - ИА21 Ведение лицевых карточек n
Л^> Eh ModsIMart. Edt View Ite^ Report Tools ^rdbw
Л^> Eh ModsIMart. Edt View Ite^ Report Tools ^rdbw
I f^j21M<d±lzl5^ I
I f^j21M<d±lzl5^ I
||3yS||S®
Ыщ1 Отдел учета м сггчетности Г ЙфЭ Отдел учета и отчетности v
Обработка дан- ных о поступ/
НачисленияОтсрочки•Данные о налогоплательщиках ПоступленияНачисленияОтсрочки•Данные о налогоплательщиках ПоступленияРис. 4.11. Дерево модели BPWin
Начисления
Отсрочки•
Данные о налогоплательщиках Поступления
Начисления
Отсрочки•
Данные о налогоплательщиках Поступления
менно работая с несколькими моделями, можно рассматривать все диаграммы или только активные при свернутой и развернутой структуре иерархического дерева. Для любой используемой методологии перечень исследуемых моделей дает полное представление о всей модели. С использованием дерева можно также выполнять задачи моделирования.
Вы можете показывать и скрывать дерево модели, щелкая кнопкой Model Explorer. Когда дерево модели активно, оно находится в раздвигающемся окне слева, а активная диаграмма — в правом.
Дерево модели (см. рис. 4.11) используется:
для просмотра разных моделей, построенных с использованием различных методологий моделирования;
для переключения режимов просмотра диаграмм или действий;
для немедленного перехода к просмотру или работе с соответствующей диаграммой в рабочем пространстве BPWin посредством щелчка на названии диаграммы или действия;
для просмотра действий и объектов диаграммы согласно уровням декомпозиции;
для редактирования имени модели, диаграммы или действия посредством двойного нажатия на соответствующем названии;
для просмотра соответствующих FEO-диаграмм, Node Tree или родственных диаграмм посредством щелчка на названии объекта диаграммы в иерархическом дереве.
4.1.144.1.14Область для рисованияОбласть для рисования
4.1.14
4.1.14
Область для рисования
Область для рисования
Область для рисования — это большая площадь справа от главного окна BPWin, в котором расположено дерево модели. Она состоит из трех областей:
заголовок;
область для рисования;
название.
Когда дерево моделей скрыто, рисунок занимает полную область окна. Вы можете создавать диаграммы BPWin, редактировать их, управлять ими в области для рисования. По Вашему желанию диаграмма может быть масштабирована при помощи инструментов настройки масштаба.
| Панель инструментов BPWin
Панель инструментов BPWin содержит инструменты для рисования объектов в диаграмме BPWin. Эти инструменты могут быть размещены в любой стороне экрана или находиться где-то в области диаграммы. Вы можете показывать или скрывать панель инструментов, используя функцию View на панели Меню. В BPWin существуют три разные панели инструментов — по числу поддерживаемых программой методологий (рис. 4.12).
IDEF0IDEF0IDEF3IDEF3Рис. 4.12. Три вида инструментальных панелейРис. 4.12. Три вида инструментальных панелейГТ о->□с2т|-*О,о►▼ГТ о->□с2т|-*О,о►▼BPwin ToolboxйBPwin ToolboxйDFDDFD
IDEF0
IDEF0
IDEF3
IDEF3
Рис. 4.12. Три вида инструментальных панелей
Рис. 4.12. Три вида инструментальных панелей
ГТ о
->
□
с
2
т|-*О,
о
►
▼
ГТ о
->
□
с
2
т|-*О,
о
►
▼
BPwin Toolboxй
BPwin Toolboxй
DFD
DFD
Нужная панель инструментов подбирается программой автоматически при выборе одной из предлагаемых при первоначальном создании модели методологий.
| Помощь
При возникновении проблем в процессе работы с BPWin использование Help — самый быстрый способ их решения. Чтобы приступить к работе с BPWin Online Help, выберите раздел Help на панели
67
1. Choose one of the following to open the Name tab in the Activity Property Sheet
To add or change an activity name
eg
Double-click the diagram activity.
•"R s^<•"R s^<Double-click the activity tree
•"R s^<
•"R s^<
object in the Mad*J.E«itoJM.
Choose one of the following options to name a new activity or change the name of an existing activity:
To use an existing activity name from the dictionary, select a name from the Unused Activity Names list.
To assign a new name, type a name in the text box.
To change the current name, type the change in the text box.
Click OK.
Hint To modify all occurrences of the
Рис. 4.13. Окно контекстно-зависимой помощи
Меню, затем выберите один из предложенных вариантов и продолжите поиск интересующей Вас темы.
Вы можете также нажать F1 в любом поле ввода, чтобы просмотреть контекстно-зависимую помощь для текущего диалогового окна или варианта меню. Заметьте, что кнопка “Помощь” имеется также в диалоговом окне на рис. 4.13. Вы найдете кнопки Помощь на большинстве диалоговых окон.
Построение контекстных диаграмм
Контекстная диаграмма — это модель, которая представляет систему как набор действий, в которые каждое действие преобразует некоторый объект или набор объектов. Модель представляется как набор иерархических действий. Высшее действие иерархии называется действием контекста. Это самый высокий уровень, который непосредственно описывает систему. Уровни ниже называются порожденными декомпозициями и представляют подпроцессы родительского действия.
При создании модели сначала необходимо изобразить самый высокий уровень, действие контекста. Наименование действия описыва- 68
ет систему непосредственно и, как правило, состоит из одного активного глагола в сочетании с обобщающим существительным, которое разъясняет цель деятельности с точки зрения самого общего взгляда на систему.
Каждый блок может иметь различные типы связанных с ним стрелок. Стрелки обозначают людей, места, вещи, понятия или события. Стрелки связывают границы диаграммы с блоками, а также действия (блоки) на диаграмме между собой. В диаграммах IDEF0 имеются четыре основных типа стрелок.
Вход блока представляет материал или информацию, которая должна быть использована или преобразована блоком, чтобы произвести продукцию (выпуск). Стрелки входа всегда направляются в левую сторону блока. Стрелки входа необязательны, так как некоторые действия не могут преобразовать или изменять (заменять) что-либо.
Каждый блок должен иметь, по крайней мере, одну стрелку контроля (управления). Управление всегда входит в вершину блока. Управление представляется в виде правил, инструкций, политики, процедур или стандартов. Оно влияет на деятельность без фактического преобразования чего-либо. Управление может также использоваться для описания процедуры начала или окончания выполнения действия.
Стрелки выхода (выпуска) — это материал или информация, произведенная блоком. Каждый блок должен иметь, по крайней мере, одну стрелку выхода (выпуска). Процессы, которые не производят продукции (выпуска), лучше не моделировать вообще.
Механизмы исполнения — это те ресурсы, которые обеспечивают выполнение действия. В качестве механизма исполнения могут быть рассмотрены персонал компании, машины или оборудование, которые обеспечивают выполнение деятельности. Стрелка механизма может отсутствовать, если определено, что это не важно для работы блока.
Контекстная диаграмма изображает деятельность самого верхнего уровня и обозначает границу моделирования относительно цели, возможностей, и точки зрения. Название контекстной диаграммы находится в дереве модели непосредственно под общим описанием.
Для создания контекстной диаграммы необходимо сначала создать новую модель, выбрав пункт “New” в меню “File”. В появившемся диалоговом окне необходимо набрать имя модели и выбрать ее тип. Этот диалог также отображается при запуске BPWin.
После создания модели можно задать ее параметры. Список свойств модели — это диалог, в котором можно задать такие параметры, как полное наименование модели, ее словесное описание и состояние, в котором находится модель, например “в работе” или “для публикации” (рис. 4.14).
Декомпозиция
Декомпозиционное разложение модели используется в моделировании бизнес-процессов, чтобы дать более подробное описание блоков. Каждое из этих действий может в свою очередь быть декомпозировано. При каждой декомпозиции блока создается новая диаграмма. Число декомпозиций не ограничено и полностью зависит от уровня сложности, который необходимо показать в модели. Обратите внимание на кружок на рис. 4.15. Если действие не было декомпозировано, в верхнем левом углу блока будет появляться символ “листа”. После декомпозиции данного блока символ “листа” исчезнет.
I1ОбработатьзаказыI1ОбработатьзаказыРис. 4.15. Обозначение блока,не имеющего декомпозицииРис. 4.15. Обозначение блока,не имеющего декомпозицииКак декомпозировать блоки с использованием BPWin? Это может быть сделано двумя способами. В диаграмме нужно выбрать действие, которое необходимо декомпозировать. Для этого выберите необходимый инструмент в наборе инструментов BPWin или в дереве модели, затем щелкните на действии, которое нужно декомпозировать. Выбранное меню содержит команду декомпозиции. В появившемся диалоговом окне необходимо задать тип и число необходимых подблоков. При декомпозиции блока BPWin создает новую диаграмму, которая является диаграммой разложения “родительской” диаграммы. Заметьте, что новые действия не связаны между собой и не поименованы — это Ваша следующая задача. Вы должны задать взаимодействие между блоками и “привязать” к новым блокам стрелки, которые автоматически унаследованы от родительской диаграммы.
I1
Обработатьзаказы
I1
Обработатьзаказы
Рис. 4.15. Обозначение блока,не имеющего декомпозиции
Рис. 4.15. Обозначение блока,не имеющего декомпозиции
Имя блока и его другие свойства вводятся в закладке “Name” списка свойств блока. Для вывода свойств блока на экран достаточно дважды щелкнуть на блоке.
Следующим шагом при создании диаграммы должно быть соединение всех использованных на диаграмме блоков с использованием стрелок, представляющих входы, результаты работы, средства управления и механизмы. Для этого достаточно соединить исходящую точку стрелки с точкой ее окончания. Окончанием стрелки может быть одна из сторон функциональных блоков и граница диаграммы. BPWin автоматически выделяет допустимые окончания для создаваемых стрелок. Для рисования стрелки необходимо выбрать инструмент “стрелка” из комплекта инструментов.
Задание имени стрелки производится в закладке “Name” диалога свойств стрелок. Для вызова этого диалога достаточно дважды щелкнуть на нужной стрелке.
Если стрелка заканчивается на границе диаграммы BPWin, она помечается “туннелем” из квадратных скобок. Аналогично помечаются стрелки в родительской диаграмме, если в диаграмме декомпозиции удаляется перенесенная из нее стрелка. Квадратный туннель на начале стрелки указывает, что стрелка “не решена” в пределах иерархии модели (не имеется никакой другой стрелки с таким же именем в любой другой диаграмме модели). Для поддержания целостности модели не-
обходимо “разрешать” стрелки, помеченные “туннелями” из квадратных скобок, одним из следующих способов:
преобразованием в “туннель” из круглых скобок;
добавлением новой стрелки, соединяющей соответствующий блок с границей диаграммы;
созданием внешней ссылки (ссылки на объект, не описанный в данной модели) в соответствии с методологией IDEF0;
созданием ссылки на блок, расположенный на другой диаграмме.
В любой момент работы с диаграммой существует возможность добавления на нее новых блоков с использованием инструмента “Activity box Tool” панели инструментов. Для добавления блока необходимо щелкнуть на этом инструменте, а затем — на диаграмме в том месте, где необходимо расположить новый блок. После того как дополнительный блок создан, вы можете связать его стрелками с другими блоками, задать его название и другие свойства.
Нумерация блоков производится автоматически при их создании. Номера могут быть относительными или постоянными, они отражают иерархическое положение блока в пределах модели. Вы можете управлять нумерацией блоков на диаграмме, используя закладку “Presentation” диалога ввода свойств модели.
Перемещение любых объектов на диаграмме осуществляется с помощью их “захвата” мышью и перемещения в новое место. При перемещении блоков одновременно перемещаются и связанные с ними стрелки. Функциональные блоки могут быть также перемещены между диаграммами с использованием команд Cut/Paste из меню “Edit”. Номера блокам диаграммы BPWin присваивает автоматически. При изменении взаимного расположения блоков эти номера могут изменяться.
Изменение размеров объектов диаграммы может быть сделано перемещением их границ. Существует возможность запрета изменения размера объектов: это можно сделать на вкладке “Layout” диалога ввода свойств модели.
Если включен просмотр дерева модели, существует возможность просмотра модели как дерева диаграмм или дерева функциональных блоков. Вершина дерева модели имеет кнопку переключателя Diagrams/Activities для отображения соответственно дерева диаграмм или дерева действий. Дерево диаграмм открывается по умолчанию при запуске BPWin. Дерево моделей BPWin использует специальный набор графических символов для представления диаграмм и действий 72
в пределах дерева объектов. Вы можете использовать это дерево, чтобы переключиться на соответствующую модель, диаграмму или действие для выполнения редактирования.
Оформление моделей
Использование цветовой палитры. В диаграмме BPWin Вы можете устанавливать цветовые свойства для действий, стрелок и текстовых блоков. Использовать цвет в диаграммах не обязательно, но это может быть полезным:
для выделения недостаточно проработанных моментов;
для выделения внесенных изменений;
для отображения похожих по смыслу объектов.
Изменение цвета блоков диаграммы. Изменение цвета объекта осуществляется с использованием цветового редактора (рис. 4.16). Чтобы изменить цвет объекта, необходимо:
щелкнуть правой кнопкой мыши на объекте, выбрать в появившемся меню пункт “Color editor”;
выбрать необходимый цвет объекта из предложенной палитры.
Set Activity ColorsSet Activity ColorsSub*patette:Sub*patette:TEXTTEXT^ Text Color^ Background ColorC Diagram Tide Color^ Text Color^ Background ColorC Diagram Tide ColorП Set as default for new activities.P Set for ай occurrences of activity.П Set as default for new activities.P Set for ай occurrences of activity.
Set Activity Colors
Set Activity Colors
Sub*patette:
Sub*patette:
TEXT
TEXT
^ Text Color
^ Background Color
C Diagram Tide Color
^ Text Color
^ Background Color
C Diagram Tide Color
П Set as default for new activities.
P Set for ай occurrences of activity.
П Set as default for new activities.
P Set for ай occurrences of activity.
Рис. 4.16. Цветовой редактор
Выбор атрибутов шрифта. Атрибуты шрифта (рис. 4.17), такие как тип, размер и стиль, могут использоваться для выделения или группировки функциональных блоков. Для изменения шрифта необходимо:
щелкнуть правой кнопкой мыши на объекте, выбрать в появившемся меню пункт “Font editor”;
выбрать нужный шрифт и, при необходимости, задать его атрибуты.
2020Sample'Sample'Fopt Style: x ^ОбычныйFopt Style: x ^ОбычныйКурсив Полужирный ■ . Полужирный К ЛIКурсив Полужирный ■ . Полужирный К ЛI■2’- Cancel■2’- CancelPLATINUM BPwinPLATINUM BPwinСделанные изменения можно применить и ко всем аналогичным объектам на диаграмме, включив соответствующие опции в левом нижнем углу окна диалога.
20
20
Sample'
Sample'
Fopt Style: x ^Обычный
Fopt Style: x ^Обычный
Курсив Полужирный ■ . Полужирный К ЛI
Курсив Полужирный ■ . Полужирный К ЛI
■2’- Cancel
■2’- Cancel
PLATINUM BPwin
PLATINUM BPwin
Activity Name Font
Font-
Verdana
Т^ Webdings ^' Wingdings
> Effects
I F Strikeout ' ' F Underline
F Change al activities
in the current diagram
F Change al occurrences of this font in the model
Рис. 4.17. Выбор шрифта
Оформление стрелок. Использование стилей стрелок, применяемых на диаграмме, важно для целостности и удобочитаемости создаваемых диаграмм IDEF0. Вы можете изменять вид стрелок, устанавливая их толщину, форму и цвет. Цвет стрелки устанавливается с использованием редактора цветов, как описано выше. Толщина стрелок также может быть изменена, что может применяться для выделения отдельных процессов на диаграмме. Для изменения толщины стрелки необходимо:
щелкнуть правой кнопкой на стрелке и выбрать в меню пункт “Style editor”;
выбрать необходимую толщину стрелки в разделе “Thickness”.
Обратите внимание на то, что форма стрелки определена в соответствии с используемой методологией. Стрелки типа “Relational” не описаны в методологии IDEF0, но могут использоваться, если строгое следование IDEF0 не обязательно. Диалог выбора вида и оформления стрелки приведен на рис. 4.18.
74
IDEFO Arrow Properties
Name SW | Definition | Status | UDP Values ] Arrow Data] UOW ]
Arrow Name:
Unnamed Arrow/17
? Thickness ~'
:F ^pply thickness to al=
;’instances
|F Set thickness as default for
j new arrows.
>F Set thickness to arrow
| '' , ■ - , segment
г Shape ——
I _ #Г& al instances
=►precedenceof arrow in the model
;.*,Г^elaticmal< pSet shape as default tar
j»ГDbjeet flownew «rows.
F Set shape to arrow segmenti
only. ’|
OK| Отмена | ^£^2J21J Спевка
Рис. 4.18. Выбор вида и оформления стрелки
| Ветвление и объединение стрелок
Ветвление и объединение стрелок необходимо для обеспечения связи одной стрелки с несколькими функциональными блоками и наоборот. Объединенные стрелки используются для создания общего перехода от нескольких функциональных блоков к одному или к границе. Ветви и объединения создаются с использованием инструмента “Стрелка”. Для удобства чтения диаграммы желательно именовать каждую ветку разделенной стрелки.
Названия стрелок отображаются автоматически и могут быть перемещены с помощью “захвата” мышью. Для соединения стрелки с ее названием может быть использован инструмент “Squiggle” с панели инструментов IDEF0 или IDEF3.
Для прояснения содержимого диаграмм можно помещать на них текстовые блоки, содержащие произвольные пояснения. Для добавления текстового блока на диаграмму необходимо:
выбрать инструмент “Text” и нажать на том месте диаграммы, где необходимо разместить пояснения;
■V^-|(Л»ЙЙЙИ*7^^^'V gatatiSRkN*^^ *v '$йй^$й^' а^||^$0^ ;<ё Д''У ^^$!1^^, ;■V^-|(Л»ЙЙЙИ*7^^^'V gatatiSRkN*^^ *v '$йй^$й^' а^||^$0^ ;<ё Д''У ^^$!1^^, ;Рис. 4.19. Опции отображенияРис. 4.19. Опции отображения
■V
^-|(Л»ЙЙЙИ*7^^^
'V gatatiSRkN*^^ *
v '$йй^$й^' а^||^$0^ ;<ё Д''
У ^^$!1^^, ;
■V
^-|(Л»ЙЙЙИ*7^^^
'V gatatiSRkN*^^ *
v '$йй^$й^' а^||^$0^ ;<ё Д''
У ^^$!1^^, ;
Рис. 4.19. Опции отображения
Рис. 4.19. Опции отображения
в появившемся текстовом окне необходимо ввести текст пояснения.
К текстовым блокам применимы все описанные выше инструменты оформления.
Опции отображения
Вы можете отображать или скрывать определенные объекты диа-
граммы и отдельные элементы оформления. Например, Вы можете переключать тени функциональных блоков на диаграмме. Параметры меню “View” (рис. 4.19) относятся одновременно ко всем диаграммам Вашей модели.
В этом же меню производится настройка рабочего места BPWin. Например, можно отобразить или скрыть стандартную панель инструментов, панель инструментов “ModelMart”, панель инструментов “BPWin”, дерево модели и строку состояния. Обратите внимание на пункт меню “Zoom”, позволяющий изменять масштаб просматриваемых диаграмм. Этот пункт меню дублирует инструмент “Zoom” стандартной панели инструментов.
Другие виды диаграмм IDEF0
В дополнение к контекстным диаграммам и диаграммам декомпозиции другие типы диаграмм BPWin позволяют упростить представление и разработку модели. Например, может оказаться необходимым разработать сценарий “что-если” для модели.
В этом подразделе будет рассмотрено создание двух типов моделей:
диаграммы “только для представления” (For Exposition Only — FEO);
древовидные диаграммы.
При правильном использовании эти типы диаграмм упрощают документирование моделей.
76
Создание диаграмм FEO. Диаграмма FEO может быть использована для пояснения какой-либо части процесса, отражения особой точки зрения или выделения функциональных деталей, которые невозможно показать с использованием синтаксиса IDEF0. Они могут снабжаться дополнительным поясняющим текстом и не обязательно должны разрабатываться с учетом ограничений стандарта IDEF0. Диаграммы FEO могут быть ассоциированы с любой существующей в модели диаграммой, но не являются иерархической частью модели. Диаграмма FEO — копия любой существующей в модели диаграммы. Диаграмма идентифицируется с помощью: • задаваемого разработчиком имени;
идентификатора вида AxF, где х показывает исходную диаграмму, а символ F показывает, что диаграмма имеет тип FEO.
FEO-диаграммы добавляются в модель с использованием пункта “FEO diagram” меню “Insert”. В диалоговом окне “Create New FEO Diagram” выберите один из следующих типов диаграммы для копирования:
если Вы выбираете “Context”, просто напечатайте имя новой диаграммы в поле “Name”;
если Вы выбираете “Decomposition”, активизируется выпадающий список “Copy From”, показывающий все диаграммы декомпозиции в модели.
После нажатия кнопки ОК будет создана и отображена на рабочем столе BPWin.
Так же, как и для любой другой диаграммы, Вы можете открыть диалог ввода свойств FEO диаграммы для ввода ее свойств.
Создание древовидных диаграмм (Node Tree Diagrams). Древовидные диаграммы используются для отображения структуры модели в целом. В них, как правило, вершина (самый верхний узел) соответствует диаграмме контекстного уровня. Однако в качестве вершины может быть использован любой функциональный блок модели, при этом его подблоки будут показаны в качестве ветвей дерева.
Просмотр моделей с использованием древовидных диаграмм позволяет акцентировать внимание на функциональной декомпозиции модели безотносительно к существующим внутри и вовне модели потокам. При изменении структуры модели древовидная модель перестраивается автоматически по мере внесения изменений в модель.
Древовидные модели нумеруются по шаблону AxN аналогично диаграммам FEO.
Древовидные диаграммы добавляются в модель с использованием пункта меню “Node tree” меню “Insert”. При этом выводится диалоговое окно “Node tree definition”, в котором задаются:
имя;
функциональный блок вершины;
количество уровней, на которые диаграмма показывается вниз;
параметры форматирования.
После нажатия кнопки ОК древовидная диаграмма создается и высвечивается на рабочем столе BPWin.
Открытие древовидных и FEO-диаграмм
Древовидные и FEO-диаграммы объединяются под названием “родственные” диаграммы. Они не отражаются непосредственно в дереве модели, однако дерево модели может быть использовано для их открытия. Для этого нужно, во-первых, переключить дерево модели в режим “Diagram view”, а затем щелкнуть правой кнопкой мыши на названии диаграммы. При этом BPWin выдаст соответствующий список родственных диаграмм. Для открытия родственных диаграмм также можно использовать инструмент “Sibling diagram tool” на панели инструментов BPWin.
| Разбиение и объединение моделей
Разбиение моделей в BPWin используется, как правило, для поддержки коллективной разработки моделей. Единая модель может быть разделена на части, чтобы позволить нескольким разработчикам создавать собственные функциональные блоки модели. По завершении разработки разделенная на части модель может быть объединена в одну для отображения бизнес-процесса в целом. При разбиении моделей на две каждая из них поддерживает собственный набор функциональных блоков, стрелок и других объектов BPWin.
Разбиение модели. Для разбиения модели на части необходимо придерживаться следующего алгоритма:
определите часть модели, которую необходимо отделить;
щелкните правой кнопкой мыши на выбранном функциональном блоке;
выберите пункт меню “Split model”;
в диалоговом окне “Split options” введите имя, соответствующее имени функционального блока (использование этого имени позволит впоследствии объединить модель);
включите опцию “Copy entire dictionaries”, чтобы скопировать словари объектов в отделяемую часть модели;
нажмите кнопку ОК.
В дереве модели будет создана и отображена новая модель. Обратите внимание на следующие моменты:
блок, с которого производилось разбиение, становится диаграммой контекстного уровня в новой модели;
в исходной связи появляется стрелка связи с именем, соответствующим имени новой модели;
все дочерние диаграммы функционального блока перенесены в новую модель;
разбитый функциональный блок остается в исходной модели.
После создания новой модели можно использовать диалог ввода свойств модели для определения свойств созданной модели.
Объединение моделей. По завершении разработки разделенных моделей BPWin позволяет их объединение в одну. Для объединения моделей:
название стрелки связи должно соответствовать названию импортируемой модели;
название функционального блока в контекстной диаграмме импортируемой модели должно соответствовать названию аналогичного функционального блока в основной модели.
При слиянии BPWin копирует все функциональные блоки, стрелки и другую информацию (кроме контекстной диаграммы) из импортируемой модели в основную. BPWin пропускает диаграмму контекстного уровня в импортируемой модели, поскольку она уже существует в основной модели. Все декомпозиции в импортируемой модели относятся в основной модели к целевому функциональному блоку. Целевой функциональный блок в основной модели всегда должен иметь исходящую из него стрелку связи.
После открытия основной и импортируемой модели нужно:
щелкнуть правой кнопкой мыши на функциональном блоке основной модели, к которому нужно импортировать данные;
выбрать из меню пункт “Merge Model”;
диалог “Continue with merge?” подтверждает, что именно Вы хотите объединить, и позволяет задать опции объединения.
По завершении объединения можно заметить, что дерево модели обновляется для отражения изменений в основной модели.
4 1 25Оценивание бизнес-процессов
" *с использованием BPWin
Добавление оценок к функциональным блокам BPWin обеспечивает задание таких характеристик, как стоимость, время выполнения работы, метрики качества. Рассмотрим два метода задания этой информации:
задание оценок для функциональных блоков;
задание свойств блока, определяемых пользователем.
Добавление стоимостных оценок для функциональных блоков основано на применении метода “Activity based costing” (АВС). Основная идея этой технологии состоит в задании оценки отдельных функциональных блоков системы для получения суммарной оценки затрат на работу всей системы (модели). Затраты на работу родительских функциональных блоков, как правило, принимаются равными затратам на функционирование всех входящих в них подблоков. Таким образом, АВС может использоваться для определения оценки затрат на функционирование системы в целом. Например, АВС может использоваться для определения:
стоимости производимой продукции;
затрат на сервисные услуги;
затрат на предполагаемые изменения в технологии производства;
мест технологического процесса, требующих наибольших затрат.
Технология АВС предполагает объединение затрат в “центры затрат” (под которыми понимается любой бизнес-процесс, функциональный блок или состояние системы, влияющие на стоимость функционирования системы) с последующим размещением стоимостей по объектам модели. Перед началом оценивания затрат необходимо убедиться, что существующая модель полна и устойчива. Оценивание функциональных блоков производится в три этапа:
определение единиц измерения;
определение “центров затрат”;
применение ценовых оценок к объектам модели.
Выбор единиц измерения. При установке единиц измерения необходимо выбрать вид валюты, который будет для этого использоваться, а также определить вид представления денежных единиц на экране. Кроме того, нужно определить единицы времени, которые будут использоваться (минуты, часы и т.п.). Эти параметры являются глобальными по отношению к модели, задаются в закладе “ABC costs” диалога задания свойств модели (рис. 4.20).Выбор единиц измерения. При установке единиц измерения необходимо выбрать вид валюты, который будет для этого использоваться, а также определить вид представления денежных единиц на экране. Кроме того, нужно определить единицы времени, которые будут использоваться (минуты, часы и т.п.). Эти параметры являются глобальными по отношению к модели, задаются в закладе “ABC costs” диалога задания свойств модели (рис. 4.20).' Genetti] -''Ptitpaw- |Л>й^Н1й^\^, МЫШ- j 'ЛЙ<М-М^* 1 :' '' ? vгV'' Genetti] -''Ptitpaw- |Л>й^Н1й^\^, МЫШ- j 'ЛЙ<М-М^* 1 :' '' ? vгV'■Г——3/'' NumbweideeiweN ^ь*^^^И*и|1т# - / А ;" ;Sumhet ,:■Г——3/'' NumbweideeiweN ^ь*^^^И*и|1т# - / А ;" ;Sumhet ,:Цп&^|вемметй:'1|0v*“Э |rg .' (ГЗ- 'Цп&^|вемметй:'1|0v*“Э |rg .' (ГЗ- 'Рис. 4.20. Диалог задания единицизмеренияРис. 4.20. Диалог задания единицизмерения
Выбор единиц измерения. При установке единиц измерения необходимо выбрать вид валюты, который будет для этого использоваться, а также определить вид представления денежных единиц на экране. Кроме того, нужно определить единицы времени, которые будут использоваться (минуты, часы и т.п.). Эти параметры являются глобальными по отношению к модели, задаются в закладе “ABC costs” диалога задания свойств модели (рис. 4.20).
Выбор единиц измерения. При установке единиц измерения необходимо выбрать вид валюты, который будет для этого использоваться, а также определить вид представления денежных единиц на экране. Кроме того, нужно определить единицы времени, которые будут использоваться (минуты, часы и т.п.). Эти параметры являются глобальными по отношению к модели, задаются в закладе “ABC costs” диалога задания свойств модели (рис. 4.20).
' Genetti] -''Ptitpaw- |Л>й^Н1й^\^
, МЫШ- j 'ЛЙ<М-М^
* 1 :' '' ? vгV'
' Genetti] -''Ptitpaw- |Л>й^Н1й^\^
, МЫШ- j 'ЛЙ<М-М^
* 1 :' '' ? vгV'
■Г——3/
'' NumbweideeiweN ^ь*^^^И*и|1т# - / А ;" ;
Sumhet ,:
■Г——3/
'' NumbweideeiweN ^ь*^^^И*и|1т# - / А ;" ;
Sumhet ,:
Цп&^|вемметй:'1
|0v*“Э |rg .' (ГЗ- '
Цп&^|вемметй:'1
|0v*“Э |rg .' (ГЗ- '
Рис. 4.20. Диалог задания единицизмерения
Рис. 4.20. Диалог задания единицизмерения
Определение “центров затрат” (“Cost Centers”). Далее необходимо определить “центры затрат”, которые будут использоваться. “Центры затрат” — это категории стоимости, которые будут присваиваться функциональным блокам модели. Примеры “центров затрат”: • маркетинг и реклама;
закупки комплектующих изделий;
техническая поддержка.
“Центры затрат” задаются с использованием пункта “Cost center editor” меню “Edit” (рис. 4.21).
Ввод информации о затратах. Для каждого функционального блока модели Вы должны задать стоимость его работы. Какой бы ни была общая стоимость работы функционального блока, она должна состоять из затрат, определенных на предыдущем этапе при задании “центров затрат”. Для этого используется Activity cost editor, вызываемый из соответствующего меню при щелчке правой кнопкой мыши на функциональном блоке (рис. 4.22). Для каждого функционального блока определяются:
частота его выполнения;
продолжительность работы;
затраты на работу блока из “центра затрат”.
ююид aodiswuduu хннхэоииою iroag ТГР *D1I<1
- exsedug
?' ;^q" ХЮОО'О <fowmb#yxw>«Q :
''| :<$3U6Hb6M3
1ИйМ111И111111И^^
I#4С^^{КШЮ39р WQj) Я|П^1Ж^ ^
00'0 .,^MJ8«b#y x^|epi *Moi||$odwa9«pep^
00'0^oo|ejoi "$исх|^шск)б10 ша^»eieQ
Л': ^,<'S;' 'S' <//, Si'^N^WV
^И|11^^И|Н^^^^И^^^^Й1|вв
saipadoid A^aipv 0J3QI
Общие затраты на работу функционального блока вычисляются автоматически, она показывается в левом нижнем углу функционального блока, для которого задана оценка затрат.
Оценка затрат с использованием свойств, определяемых пользователем. Свойство, определяемое пользователем (User-defined property — UDP), создается для отображения произвольной информации, относящейся к конкретному функциональному блоку или стрелке. BPWin поддерживает различные типы UDP, включая:
“выпадающие списки”, например, для хранения информации об организации процесса или оценки его уровня;
исполнимые UDP, которые содержат ссылки на прикрепленные объекты, обрабатываемые другими программами;
текстовые списки, используемые, например, для хранения информации типа “критических факторов успеха”.
UDP могут использоваться для более полной детализации модели и задания, например, таких свойств, как время, стоимость, качество и ответственные лица.
UDP задаются с помощью пункта “User-Defined Property Name Editor” меню “Edit”. Для этого нужно:
задать имя свойства;
назначить свойству тип данных;
при необходимости уточнить характеристики свойства (это нужно для некоторых типов данных).
После создания UDP существует возможность присвоения им значений с помощью закладки “UDP values” диалога редактирования свойств функционального блока или стрелки.
Печать диаграмм BPWin
После того как Вы создали модель, Вы захотите продемонстрировать ее другим на бумаге. BPWin поможет Вам в этом с помощью разнообразных функций для печати диаграмм. Некоторые из них:
выбрать диаграмму (или диаграммы), которую Вы хотите напечатать;
включить сообщения диаграммы с распечатками диаграммы;
включить родительскую диаграмму для диаграммы, которую Вы будете печатать;
определить спецификацию диаграммы для печати: цветовая гамма, внешние границы диаграммы;
отправить диаграмму в файл для последующей печати;
определить, как печатать диаграммы: каждая диаграмма на одном листе по выбору, пакетная печать всех диаграмм модели с указанием количества их на листе.
Вы можете печатать диаграммы BPWin из меню Печати Диаграммы BPWin, которое может быть открыто из меню “File” командой “Print” или нажатием изображения принтера в панели инструментов (рис. 4.23). Этот режим позволяет Вам определять опции печати, упомянутые ранее.
Рис. 4.23. Диалог выбора опций печати
Как Вы уже смогли понять, вид напечатанной модели зависит от выбора опций печати, которые Вы установили. Вы можете поэкспериментировать перед печатью для определения, какие установки работают лучше для вашего случая.
| Получение отчетов по модели
BPWin предоставляет набор отчетов для публикации информации, которая помещена в Вашу модель. Существуют средства настройки отчетов.
84
Отчеты BPWin разделяются на стандартные и нестандартные. Отличие их заключается в том, что для получения стандартного отчета не требуется задания никаких дополнительных параметров. Для получения нестандартного отчета необходимо указать объекты, которые должны быть отражены в отчете. Перечислим стандартные отчеты BPWin:
отчет по диаграммам (diagram report) — включает информацию об объектах в активной диаграмме BPWin;
отчет о стрелках (arrow report) — включает информацию о стрелках (связях) в BPWin модели;
отчет о затратах (activity cost report) — содержит информацию о затратах функциональных блоков и о “центрах затрат” в BPWin модели;
отчет об объектах диаграммы (diagram object report) — содержит информацию об объектах, размещенных на диаграмме (функциональных блоках, хранилищах данных и внешних ссылках) в BPWin-модели;
отчет об использовании данных (data usage report) — содержит информацию о таблицах базы данных или сущностях и атрибутах;
отчет о целостности модели (model consistency report) — содержит информацию о том, насколько активная IDEFO-модель соответствует выбранной IDEFO-методологии;
отчет о модели (model report) — содержит общую информацию относительно модели BPWin (IDEFO, IDEF3 или DFD). Отчет о модели может включать один элемент или большее количество элементов, указанных в диалоговом окне Model Definition Editor.
Для получения отчета необходимо проделать следующие основные шаги:
выбрать нужный отчет в меню Reports;
выбрать элементы модели, которые необходимо включить в отчет (рис. 4.24);
выбрать, куда нужно вывести сформированный отчет.
Рассмотрим более сложный отчет, например отчет об объектах диаграммы. Как показано на рис. 4.24, это диалоговое окно имеет намного больше параметров, чем в предыдущем примере. Сложность отчета определяется количеством данных, которые нужно отразить в отчете. Для выполнения отчета об объектах диаграммы нужно:
определить объекты диаграммы и степень детализации отчета;
Diagram Object Report
Standardly
Reports: I
Report err P Activities Г Data stores Г External References Model: rt /Report err P Activities Г Data stores Г External References Model: rt /Start From f--*“^^^ Active I s.dumber of Levels: |“"t'P/Mame:/^ f^ AitoNams Г Number ^■ * T* Двййюп' ^C/E^; - <iStart From f--*“^^^ Active I s.dumber of Levels: |“"t'P/Mame:/^ f^ AitoNams Г Number ^■ * T* Двййюп' ^C/E^; - <i",Г Ngtd / Г T“ Desaigtwn- Г Souks'- - Г Constraints '",Г Ngtd / Г T“ Desaigtwn- Г Souks'- - Г Constraints '- Arrow Options—-—— “= П Input Name I• Г Input DefinitionГ Cohti^Name5 Г Control Definition ' 4Г Output Masse -4, Г DytputDefinitron j, Г Meeh NameIX* MechDefinitionjГ Call Arrow N ame!1 Г CallArrow Definitton- Arrow Options—-—— “= П Input Name I• Г Input DefinitionГ Cohti^Name5 Г Control Definition ' 4Г Output Masse -4, Г DytputDefinitron j, Г Meeh NameIX* MechDefinitionjГ Call Arrow N ame!1 Г CallArrow DefinittonReport Format( ^ Labeled'' C Fyed ColumniГ Jab DelimitedpC Comma Deftrated ^£DE Table!21M^L™- Mu^i-Valued Fermat—j Г Repeating Group i C gied : ' - j ^ Hegde» P Me^JP Remove Special CharReport Format( ^ Labeled'' C Fyed ColumniГ Jab DelimitedpC Comma Deftrated ^£DE Table!21M^L™- Mu^i-Valued Fermat—j Г Repeating Group i C gied : ' - j ^ Hegde» P Me^JP Remove Special CharUser-Defined Properties:User-Defined Properties:OoseOoseArrow Ordering—C Alphabetical ' i 4s* Arrow Number jArrow Ordering—C Alphabetical ' i 4s* Arrow Number jActivity Ordering C Alphabetical ^ Hierarchical C Breadth FirstActivity Ordering C Alphabetical ^ Hierarchical C Breadth First
Report err P Activities Г Data stores Г External References Model: rt /
Report err P Activities Г Data stores Г External References Model: rt /
Start From f--*“^^^ Active I s.
dumber of Levels: |“
"t'P/Mame:/^ f^ AitoNams Г Number ^
■ * T* Двййюп' ^C/E^; - <i
Start From f--*“^^^ Active I s.
dumber of Levels: |“
"t'P/Mame:/^ f^ AitoNams Г Number ^
■ * T* Двййюп' ^C/E^; - <i
",Г Ngtd / Г T“ Desaigtwn- Г Souks'- - Г Constraints '
",Г Ngtd / Г T“ Desaigtwn- Г Souks'- - Г Constraints '
- Arrow Options—-—— “
= П Input Name I
• Г Input Definition
Г Cohti^Name
5 Г Control Definition ' 4
Г Output Masse -4
, Г DytputDefinitron j
, Г Meeh NameI
X* MechDefinitionj
Г Call Arrow N ame!
1 Г CallArrow Definitton
- Arrow Options—-—— “
= П Input Name I
• Г Input Definition
Г Cohti^Name
5 Г Control Definition ' 4
Г Output Masse -4
, Г DytputDefinitron j
, Г Meeh NameI
X* MechDefinitionj
Г Call Arrow N ame!
1 Г CallArrow Definitton
Report Format( ^ Labeled'
' C Fyed Columni
Г Jab Delimitedp
C Comma Deftrated ^£DE Table!
21M^L™
- Mu^i-Valued Fermat—j Г Repeating Group i C gied : ' - j ^ Hegde» P Me^J
P Remove Special Char
Report Format( ^ Labeled'
' C Fyed Columni
Г Jab Delimitedp
C Comma Deftrated ^£DE Table!
21M^L™
- Mu^i-Valued Fermat—j Г Repeating Group i C gied : ' - j ^ Hegde» P Me^J
P Remove Special Char
User-Defined Properties:
User-Defined Properties:
Oose
Oose
Arrow Ordering—
C Alphabetical ' i 4s* Arrow Number j
Arrow Ordering—
C Alphabetical ' i 4s* Arrow Number j
Activity Ordering C Alphabetical ^ Hierarchical C Breadth First
Activity Ordering C Alphabetical ^ Hierarchical C Breadth First
Рис. 4.24. Диалог задания параметров отчета
выбрать элементы данных, которые нужно включить в отчет (обратите внимание, что можно включать в отчет определяемые пользователем свойства — UDP);
определить дополнительные параметры форматирования для печати или имена дисковых файлов;
В дополнение к имеющимся в BPWin Вы можете определять и сохранять ваши собственные отчеты следующим образом: напечатать название в соответствующем поле, выбрать параметры отчета, нажать кнопку New. Определение отчета будет сохранено, добавлено к списку для использования в следующий раз.
Кнопки Update и Delete позволяют изменять существующие параметры отчета или удалять созданные отчеты.
При разработке модели одним из наиболее полезных является отчет о ее целостности. Он содержит информацию о том, как хорошо Ваша модель соответствует выбранной IDEF0 методологии. Это помогает следить за соблюдением методологии и выявлять любые нарушения целостности модели.
При выборе отчета о целостности модели из меню Report BPWin отображает соответствующий диалог, не имеющий никаких параметров. BPWin автоматически генерирует отчет, когда Вы нажимаете кнопки Предварительного просмотра, Печати или Report.
* * ♦
Итак, в этой главе мы познакомились с программным средством Platinum BPWin — наиболее распространенным сегодня пакетом, поддерживающим создание моделей IDEFO, IDEF3 и DFD. Богатый набор функций этой программы позволяет применять ее для разработки программного обеспечения корпоративных информационных систем и для решения задач по реинжинирингу бизнес-процессов.
ПРАКТИЧЕСКИЕ ЗАНЯТИЯПРАКТИЧЕСКИЕ ЗАНЯТИЯ
ПРАКТИЧЕСКИЕ ЗАНЯТИЯ
ПРАКТИЧЕСКИЕ ЗАНЯТИЯ
5
ГЛАВА
В качестве примера рассмотрим деятельность вымышленной компании Quill, которая существует 5 лет и занимается в основном сборкой и продажей настольных компьютеров и ноутбуков. Годовой оборот компании составляет примерно 20 млн долл. Компания закупает компоненты для компьютеров от трех независимых поставщиков, а не производит компоненты самостоятельно. Она только собирает и тестирует компьютеры. Компания реализует продукцию через магазины и специализируется на покупателях, для которых главный критерий при покупке — стоимость компьютера. Предполагаемый объем рынка для компании Quill в последующие 2 года — 50 млн долл.
Несмотря на некоторое увеличение объема продаж, прибыли уменьшаются, растет конкуренция на рынке. Чтобы не потерять позиции, компания решает проанализировать текущие бизнес-процессы и реорганизовать их с целью увеличения эффективности производства и продаж. Основные процедуры в компании таковы:
продавцы принимают заказы клиентов;
операторы группируют заказы по типам компьютеров;
операторы собирают и тестируют компьютеры;
операторы упаковывают компьютеры согласно заказам;
кладовщик отгружает клиентам заказы.
В настоящее время компания Quill использует купленную бухгалтерскую информационную систему, которая позволяет оформить заказ, счет и отследить платежи по счетам.
Улучшение деятельности компании должно касаться структуры управления компанией, эффективности производства и внутреннего контроля. В результате реорганизация может потребовать внедрения новой корпоративной информационной системы (состоящей не только из одного бухгалтерского модуля).
Однако перед тем как пытаться производить какие-то улучшения, необходимо разобраться в существующих бизнес-процессах.
88
Создание контекстной диаграммы
Для создания контекстной диаграммы выполните следующие действия.
Запустите BPWin. (Кнопка Start-Пуск / BPWin.)
Появляется диалоговое окно ModelMart Connection Manager. Нажмите на кнопку Cancel.
Появляется диалоговое окно I would like to. Внесите имя модели {Деятельность компании Quill} и выберите Туре — IDEF0. Нажмите кнопку ОК.
Автоматически создается контекстная диаграмма.
Обратите внимание на кнопку *hl на панели инструментов. Эта кнопка включает и выключает инструмент просмотра и навигации — Model Explorer (появляется слева). Кнопка Activities/Diagrams переключает режим Model Explorer. В режиме Activities щелчок правой кнопкой по объекту в Model Explorer позволяет редактировать его свойства.
Если Вам непонятно, как выполнить то или иное действие, Вы можете вызвать помощь — клавиша F1 или меню Help.
Перейдите в меню Edit / Model Properties. В закладке General диалогового окна Model Properties следует внести имя модели {Деятельность компании Quill}, имя проекта {Модель деятельности Quill}, имя автора и тип модели — Time Frame {AS-IS}.
В закладке Purpose внесите Цель {Purpose: Моделировать текущие (AS-IS) бизнес-процессы компании Quill} и Точку зрения {Viewpoint: Директор}.
В закладке Definition внесите определение {Это учебная модель, описывающая деятельность компании Quill} и Scope {Общее управление бизнесом компании: исследование рынка, закупка компонентов, сборка, тестирование и продажа продуктов}.
В закладке Source внесите {Материалы курса по BPWin}.
В закладке Status установите WORKING и нажмите кнопку ОК.
Перейдите в меню Edit / Diagram Properties и установите свойства диаграммы.
Перейдите в меню File / Page setup и установите опции страницы для печати диаграммы. В этом диалоговом окне устанавливается “логический” размер страницы. Если принтер не поддерживает такой размер, диаграмма может быть разбита на несколько страниц.
Перейдите на контекстную диаграмму и правой кнопкой мыши щелкните по работе. В контекстном меню выберите Name Editor. В закладке Name внесите имя {Деятельность компании Quill}.
В закладке Definition внесите определение {Текущие бизнес- процессы компании Quill}.
В закладке Status установите WORKING.
В закладке Source внесите {Материалы курса по BPWin} и щелкните по ОК.
Создайте стрелки на контекстной диаграмме (табл. 5.1).
Таблица 5.1
Контекстная диаграмма
Наименование стрелки
Описание
Тип
Бухгалтерская система
Оформление счетов, оплата счетов, работа с заказами
Mechanism
Звонки клиентов
Запросы информации, заказы, техническая поддержка и т.д.
Input
Правила и процедуры
Правила продажи, инструкции по сборке, процедуры тестирования, критерии производительности и т.д.
Control
Проданные продукты
Настольные и портативные компьютеры
Output
С помощью кнопки Tj внесите текст в поле диаграммы—точку зрения и цель.
Создайте отчет по модели (рис. 5.1, 5.2). Меню Report / Model Report.
ffggg^^-,а|^Model Наше: Деятельность Компании Quil . Definition: Это учебная модель, описываемая де - Scope: Обеее управление бизнесом компании: нее,? тестирование и продаже продуктов 7Viewpoint: Viewpoint: ДиректоргTime Frame: (AS-IS);7Status: WORKING Propouse: Propouse: Моделировать текуеие (AS-:,V $ бизнес процессы компании QuillжSource: Материалы курса no BPQWin№ffggg^^-,а|^Model Наше: Деятельность Компании Quil . Definition: Это учебная модель, описываемая де - Scope: Обеее управление бизнесом компании: нее,? тестирование и продаже продуктов 7Viewpoint: Viewpoint: ДиректоргTime Frame: (AS-IS);7Status: WORKING Propouse: Propouse: Моделировать текуеие (AS-:,V $ бизнес процессы компании QuillжSource: Материалы курса no BPQWin№833S^д" л!
ffggg^^-,а|^
Model Наше: Деятельность Компании Quil . Definition: Это учебная модель, описываемая де - Scope: Обеее управление бизнесом компании: нее,? тестирование и продаже продуктов 7
Viewpoint: Viewpoint: Директорг
Time Frame: (AS-IS);7
Status: WORKING Propouse: Propouse: Моделировать текуеие (AS-:,V $ бизнес процессы компании Quillж
Source: Материалы курса no BPQWin№
ffggg^^-,а|^
Model Наше: Деятельность Компании Quil . Definition: Это учебная модель, описываемая де - Scope: Обеее управление бизнесом компании: нее,? тестирование и продаже продуктов 7
Viewpoint: Viewpoint: Директорг
Time Frame: (AS-IS);7
Status: WORKING Propouse: Propouse: Моделировать текуеие (AS-:,V $ бизнес процессы компании Quillж
Source: Материалы курса no BPQWin№
Model фукч
ModMBepcMDiiidiiQrimyOi^^ \~\
'; tP ModelHme -ГР>НИГ >> ^'\<< 7 L' 2Р ДЫНюп- / х BP Sjawteer' ^ I " \;:L:, ^, " '$P&bpb~«7‘ SP й^ЙаНав» V ^V/1' 7 4р'м^Рй*'' " 1QP СМЬпМ /Ч" , ;..v'/
Рис. 5.2Рис. 5.2. 5Р I«w Frame \ ;ИР $$^1^Й««йэп&а^ ' 6Р 5йМ^/7 ' 1X^'1^Ц<Яе*М*р* > /' /
Рис. 5.2
Рис. 5.2
СЗоае ^ ■^wj^M^^**'* ^* * E^^w^^оо^*+* ^ >'w ^fdje
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
окончание — файл 01 d 1 .bp 1.
5.25.2Создание диаграммы декомпозиции
5.2
5.2
Выберите кнопку перехода на нижний уровень в палитре инструментов, в диалоговом окне Activity Box Count установите число работ 3 на диаграмме нижнего уровня и нажмите кнопку ОК (рис. 5.3).
^|р|н.|о|^|т|о|>|лГт
iActivity Box CountiActivity Box Count
iActivity Box Count
iActivity Box Count
^ 1DER> ЛС fiR> Г;№3?
, Г Jr^uJ^f4e|^« ^C^>^? ' 7
Рис. 5.3
Автоматически будет создана диаграмма декомпозиции. Правой кнопкой мыши щелкните по работе, выберите Name Editor и внесите имя работы. Повторите операцию для всех трех работ. Затем внесите определение, статус и источник для каждой работы согласно табл. 5.2.
91
Описание работ для диаграммы декомпозиции
Функциональный блок
Описание
Статус
Источник
Продажи, маркетинг
Телемаркетинг, презентации, выставки
WORKING
Материалы курса BPWin
Сборка, тестирование компьютеров
Сборка и тестирование настольных и портативных компьютеров
WORKING
Материалы курса BPWin
Отгрузка, получение
Отгрузка заказов клиентам и получение компонентов от поставщиков
WORKING
Материалы курса BPWin
Для изменения свойств работ после их внесения в диаграмму можно воспользоваться словарем объектов модели. Вызов словаря — Edit/Diagram Object Dictionary (рис. 5.4).
Если Вы опишете имя и свойства работы в словаре, ее можно будет внести в диаграмму позже с помощью кнопки В] в палитре инструментов. Вы не можете удалить работу из словаря, если она используется на какой-либо диаграмме. Если Вы удалите работу из диаграммы, из словаря она не удаляется. Имя и описание такой работы может быть использовано в дальнейшем. Для добавления работы в словарь щелкните по кнопке Clear, внесите имя и свойства работы, затем щелкните по Add. Для удаления всех имен работ, не использующихся в модели, щелкните по Purge.
Перейдите в режим рисования стрелок. Свяжите граничные стрелки (кнопка ^J на палитре инструментов) с остальными так, как показано на рис. 5.5.
Рис. 5.5
Правой кнопкой мыши щелкните по ветви стрелки управления работы “Сборка и тестирование компьютеров” и переименуйте ее в “Правила сборки и тестирования” (рис. 5.6).
Внесите определение для новой ветви: “Инструкции по сборке, процедуры тестирования, критерии производительности и т.д.”
Рис. 5.6
Правой кнопкой мыши щелкните по ветви стрелки механизма работы “Продажи и маркетинг” и переименуйте ее в “Систему оформления заказов”.
Альтернативный метод внесения имен и свойств стрелок — использование словаря стрелок (вызов словаря — меню Edit / Arrow Dictionary). Если Вы опишите имя и свойства стрелки в словаре, ее можно будет внести в диаграмму позже. Вы не можете удалить стрелку из словаря, если она используется на какой-либо диаграмме. Если Вы удалите стрелку из диаграммы, из словаря она не удаляется. Имя и описание такой стрелки может быть использовано в дальнейшем. Для
добавления стрелки в словарь щелкните по кнопке Clear, внесите имя и свойства работы, затем щелкните по Add. Для удаления всех имен стрелок, не использующихся в модели, щелкните по Purge Unused.
Создайте новые внутренние стрелки так, как показано на рис. 5.7.
Создайте стрелку обратной связи (по управлению) “Результаты сборки и тестирования” (рис. 5.8), идущую от работы “Сборка и тестирование компьютеров” к работе “Продажи и маркетинг”. Для большей наглядности измените стиль стрелки (толщина линий) и установите опцию Extra Arrowhead (из контекстного меню). Методом drag&drop перенесите имена стрелок так, чтобы их было удобнее читать. Если необходимо, установите Squiggle (из контекстного меню).
Результаты сборки и тестированияРезультаты сборки и тестированияРис. 5.8Рис. 5.8
Результаты сборки и тестирования
Результаты сборки и тестирования
Рис. 5.8
Рис. 5.8
Создайте новую граничную стрелку выхода “Маркетинговые материалы” из работы “Продажи и маркетинг”. Эта стрелка автоматически не попадает на диаграмму верхнего уровня и имеет квадратные скобки на наконечнике ^. Из палитры выберите кнопку О;,
щелкните мышью по квадратным скобкам и в диалоговом окне Border Arrow Editor выберите Resolve Border Arrow.
Для стрелки “Маркетинговые материалы” выберите опцию Trim из контекстного меню.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 04dl.bpl, окончание — файл 01d2.bpl.
5.35.3Задание. Создание диаграммы декомпозиции
5.3
5.3
Декомпозируется работа “Сборка и тестирование компьютеров”. В результате проведения экспертизы получена следующая информация:
производственный отдел получает заказы клиентов от отдела продаж по мере их поступления;
диспетчер координирует работу сборщиков, сортирует заказы, группирует их и дает указание на отгрузку компьютеров, когда они готовы;
каждые 2 часа диспетчер группирует заказы отдельно для настольных компьютеров и ноутбуков и направляет на участок сборки;
сотрудники участка сборки собирают компьютеры согласно спецификациям заказа и инструкциям по сборке. Когда группа компьютеров, соответствующая группе заказов, собрана, она направляется на тестирование. Тестировщики тестируют каждый компьютер и в случае необходимости могут заменить неисправные компоненты;
тестировщики направляют результаты тестирования диспетчеру, который на основании этой информации принимает решение о передаче компьютеров соответствующей группы заказов на отгрузку.
На основе этой информации внесите новые работы и стрелки (табл. 5.3 и 5.4).
Таблица 5.3
Описание бизнес-процессов для работы “Сборка и тестирование компьютеров”
Функциональный блок
Описание
Статус
Отслеживание расписания и управление сборкой и тестированием
Просмотр заказов, установка расписания выполнения заказов, просмотр результатов тестирования, формирование групп заказов на сборку и отгрузку
WORKING
Сборка настольных компьютеров
Сборка настольных компьютеров в соответствии с инструкциями и указаниями диспетчера
WORKING
Функциональный блок
Описание
Статус
Сборка ноутбуков
Сборка ноутбуков в соответствии с инструкциями и указаниями диспетчера
WORKING
Тестирование компьютеров
Тестирование компьютеров и компонент.
Замена неработающих компонент.
WORKING
Таблица 5.4
Описание стрелок для декомпозиции работы“Сборка и тестирование компьютеров”
Стрелка
Источник
Тип
Назначение
Тип назначения
Диспетчер
Персонал производственного отдела
Mechanism
Отслеживание расписания и управление сборкой и тестированием
Mechanism
Заказы клиентов
{Border}
Control
Отслеживание расписания и управление сборкой и тестированием
Control
Заказы на настольные компьютеры
Отслеживание расписания и управление сборкой и тестированием
Output
Сборка настольных компьютеров
Control
Заказы на ноутбуки
Отслеживание расписания и управление сборкой и тестированием
Output
Сборка ноутбуков
Control
Компоненты
{ Tunnel}
Input
Сборка настольных компьютеров
Input
Сборка ноутбуков
Input
Тестирование компьютеров
Input
Настольные компьютеры
Сборка настольных компьютеров
Output
Тестирование компьютеров
Input
Стрелка
Источник
Тип
Назначение
Тип назначения
Ноутбуки
Сборка ноутбуков
Output
Тестирование компьютеров
Input
Персонал производственного отдела
{ Tunnel}
Mechanis m
Сборка настольных компьютеров
Mechanism
Сборка ноутбуков
Mechanism
Правила сборки и тестирования
Правила и процедуры
Control
Сборка настольных компьютеров
Control
Сборка ноутбуков
Control
Тестирование компьютере^
Control
Результаты сборки и тестирования
Сборка настольных компьютеров
Output
{ Border }
Output
Сборка ноутбуков
Output
Тестирование компьютеров
Output
Результаты тестирования
Тестирование компьютеров
Output
Отслеживание расписания и управление сборкой и тестированием
Input
Собранные компьютеры
Тестирование компьютеров
Output
{ Border }
Output
Тестировщик
Персонал производственного отдела
Тестирование компьютеров
Mechanism
Указание передать компьютеры на отгрузку
Отслеживание расписания и управление сборкой и тестированием
Output
Тестирование компьютеров
Control
Туннелируйте и свяжите на верхнем уровне граничные стрелки, если это необходимо.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 01 d2 .bp 1, окончание — файл 01 s.bp 1.
5.4 Создание диаграммы узлов
1. Выберите меню Insert / Node Tree. Установите опции диалогового окна Node Tree Definition, как показано на рис. 5.9.
Node free Definition
• Model Name: Деятельное RoiectNamer Мсегалмеятельн^
Diagram Barner (Деятельность компании Quill;
.., Вок Width'
Pa*tu*iu«i> ffR^txxtoteKti Pw
P Dfdw NcdeNumbgR j Г Qne$izepef row. : ^ Include Jitfe P Draw Всуе» ' ; Г* Alonesige.'
Рсдо Numbeef
C-Nuobet: |NTOO1
U«^At Г
Siat^-'
Г fiRAFT™"
Г gECOMMENDED r PUBLICATION Г Other
PeationDate: (03Ш01 UtefLa^RevraarDate: | SystemLatfRevi^nDate: f™ " IOK | cweei I Be» |
Рис. 5.9
2. Щелкните по кнопке ОК. Создается диаграмма дерева узлов.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл Ols.bpl, окончание — файл 02d.bpl.
5.5
Задание. Создание диаграммы дерева узлов
Для проведения деловой встречи директору компании необходимо иметь общую картину происходящих в компании бизнес-процес- сов. Создайте диаграмму дерева узлов.
Установите фокус на диаграмме дерева узлов, перейдите в меню Edit / Diagram Properties, в закладке Style диалогового окна Node Tree Properties отключите опцию Bullet Last Level. Щелкните по кнопке ОК. Посмотрите результат.
5.6 Создание FEO-диаграммы
При обсуждении бизнес-процессов возникла необходимость детально рассмотреть взаимодействие работы “Сборка и тестирование компьютеров” с другими работами. Чтобы не модифицировать диаграмму декомпозиции, создайте FEO-диаграмму, на которой будут только стрелки работы “Сборка и тестирование компьютеров" (рис. 5.10):
Выберите пункт меню Insert / FEO Diagram.
В диалоговом окне Create FEO Diagram выберите тип и внесите имя диаграммы FEO. Щелкните по кнопке ОК.
Для определения диаграммы перейдите в Edit / Diagram Properties и в закладке Diagram Text внесите определение.
Удалите лишние стрелки на диаграмме FEO.
Для перехода между стандартной диаграммой, деревом узлов и FEO используйте кнопку О| на палитре инструментов.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 02s.bpl, окончание — файл 03d.bpl.
Рис. 5.10Рис. 5.10
Рис. 5.10
Рис. 5.10
5.75.7Задание. Создание FEO-диаграммы
5.7
5.7
В результате проведения экспертизы от сотрудников производственного отдела получена дополнительная информация — оказалось, что неисправные компоненты направляются на отгрузку. Для уточне- 100
ния информации необходима дополнительная экспертиза в отделе отгрузки. Создайте FEO для проведения такой экспертизы.
Постройте FEO на основе диаграммы АО и добавьте стрелку “Неисправные компоненты”. Стрелка должна идти с выхода “Сборка и тестирование компьютеров” на вход “Отгрузка и получение” (рис. 5.11).
Рис. 5.11Рис. 5.11
Рис. 5.11
Рис. 5.11
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл O3d.bpl, окончание — файл O3s.bpl.
5.85.8Расщепление и слияние моделей
5.8
5.8
Расщепление модели:
Перейдите на диаграмму АО. Правой кнопкой мыши щелкните по работе “Сборка и тестирование компьютеров” и выберите Split model.
В диалоговом окне Split Option внесите имя новой модели “Сборка и тестирование компьютеров”, установите опции, как на рис. 5.12, и щелкните по кнопке ОК.
Split Options
Hew Model Heme: [Сборка и тестирование компьютеров
Г fnaWeMerge/Ovetwrle .,
OK I Caned | Н* |
Рис. 5.12
Посмотрите на результат: в Model Explorer существует новая модель, на диаграмме АО модели “Деятельность компании Quill” появилась стрелка вызова “Сборка и тестирование компьютеров”.
В модели “Деятельность компании Quill” внесите цель и точку зрения.
Цель: документировать работу по сборке и тестированию компьютеров.
Точка зрения: Директор.
Создайте в модели “Сборка и тестирование компьютеров” новую стрелку “Неисправные компоненты”. На диаграмме А-0 это будет граничная стрелка выхода, на диаграмме АО — граничная стрелка выхода от работ «Сборка настольных компьютеров», «Тестирование компьютеров» и «Сборка ноутбуков».
Слияние модели:
Перейдите на диаграмму АО модели “Деятельность компании Quill”.
Правой кнопкой мыши щелкните по работе “Сборка и тестирование компьютеров” и выберите Merge model.
В диалоговом окне Merge Model включите опцию Paste/Merge Dictionaries и щелкните по кнопке ОК.
Посмотрите на результат. В Model Explorer видно, что две модели слились. Модель “Сборка и тестирование компьютеров” осталась и может быть сохранена в отдельном файле. На диаграмме АО модели “Деятельность компании Quill” исчезла стрелка вызова “Сборка и тес- 102
тирование компьютеров”. Появилась неразрешенная граничная стрелка “Неисправные компоненты”. Направьте эту стрелку к входу работы “Отгрузка и получение”.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл O3s.bpl, окончание— файл 04dl.bpl.
5.9 Создание диаграммы IDEF3
Перейдите на диаграмму А2 и декомпозируйте работу “Сборка на
стольных компьютеров”. В диалоговом окне Activity Box Count установите число работ 4 и нотацию IDEF3 (рис. 5.13).
| Activity Box Count| Activity Box Count^ ЮЕ-л C LED ^ IDEQNumber of At^ies in thisОесстпройюпр^ I 3^ ЮЕ-л C LED ^ IDEQNumber of At^ies in thisОесстпройюпр^ I 3OK I Cancel | HelpOK I Cancel | HelpРис. 5.13Рис. 5.13Возникает диаграмма IDEF3, содержащая работы (UOW). Правой кнопкой мыши щелкните по работе, выберите в контекстном меню Name Editor и внесите имя работы — “Подготовка компонент”. Затем в закладке Definition внесите определение “Подготавливаются все компоненты компьютера согласно спецификации заказа”.
| Activity Box Count
| Activity Box Count
^ ЮЕ-л C LED ^ IDEQ
Number of At^ies in this
Оесстпройюпр^ I 3
^ ЮЕ-л C LED ^ IDEQ
Number of At^ies in this
Оесстпройюпр^ I 3
OK I Cancel | Help
OK I Cancel | Help
Рис. 5.13
Рис. 5.13
В закладке UOW внесите следующую информацию:
Objects Компоненты: винчестеры, корпуса, материнские платы, видеокарты, звуковые карты, дисководы CD-ROM и флоппи, модемы, программное обеспечение
Facts Доступные операционные системы: Windows 98, Windows NT
Constrains Установка модема требует установки дополнительного программного обеспечения
Внесите в диаграмму еще 3 работы (кнопка О]).
Внесите другие имена работ:
установка материнской платы и винчестера;
установка модема;
установка дисковода CD-ROM;
установка флоппи-дисковода;
инсталляция операционной системы;
инсталляция дополнительного программного обеспечения.
С помощью кнопки И] палитры инструментов создайте объект ссылки. Внесите имя объекта внешней ссылки —“Компоненты”.
Свяжите стрелкой объект ссылки и работу “Подготовка компонентов”.
Свяжите стрелкой работы “Подготовка компонентов” (выход) и “Установка материнской платы и винчестера”. Измените стиль стрелки на Object Flow (рис. 5.14).
ВIDEF3 имя стрелки может отсутствовать, хотя BPWin воспринимает отсутствие имени как ошибку.
КомпонентыКомпонентыУстановка флоппи- дисководаА22.1.5 | ""Установка флоппи- дисководаА22.1.5 | ""ПодготовкакомпонентовА22.1.1 IПодготовкакомпонентовА22.1.1 IУстановка материнской платы и винчестера А22.1.2 IУстановка материнской платы и винчестера А22.1.2 IИнсталляцияоперационнойсистемыА22.1.6 IИнсталляцияоперационнойсистемыА22.1.6 IУстановка дисковода CD-ROMА22.1.4 I ”Установка дисковода CD-ROMА22.1.4 I ”7 УстановкамодемаА22.1.3 |""7 УстановкамодемаА22.1.3 |""ИнсталляциядополнительногопрограммногообеспеченияА22.1.7 I ИнсталляциядополнительногопрограммногообеспеченияА22.1.7 I
Компоненты
Компоненты
Установка флоппи- дисковода
А22.1.5 | ""
Установка флоппи- дисковода
А22.1.5 | ""
Подготовкакомпонентов
А22.1.1 I
Подготовкакомпонентов
А22.1.1 I
Установка материнской платы и винчестера А22.1.2 I
Установка материнской платы и винчестера А22.1.2 I
Инсталляцияоперационнойсистемы
А22.1.6 I
Инсталляцияоперационнойсистемы
А22.1.6 I
Установка дисковода CD-ROM
А22.1.4 I ”
Установка дисковода CD-ROM
А22.1.4 I ”
7
Установкамодема
А22.1.3 |""
7
Установкамодема
А22.1.3 |""
Инсталляциядополнительногопрограммногообеспечения
А22.1.7 I
Инсталляциядополнительногопрограммногообеспечения
А22.1.7 I
Рис. 5.14
Сохраните модель.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 04d2.bpl, окончание — файл 04d3.bpl.
5.10 Создание перекрестка
С помощью кнопки @] на палитре инструментов внесите два перекрестка типа “асинхронное или” и свяжите работы с перекрестками, как показано на рис. 5.15.
Правой кнопкой щелкните по перекрестку для разветвления (fanout), выберите Name Editor и внесите имя “Компоненты, требуемые в спецификации Заказа”.
104
Рис. 5.15
Создайте два перекрестка типа “исключающее или” и свяжите работы, как показано на рис. 5.16.
Рис. 5.16
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 04d3.bpI, окончание — файл 04d4.bpl.
5.115.11Задание. Создание диаграммы IDEF3
5.11
5.11
В результате проведения экспертизы с тестировщиками выявлена следующая информация:
каждый тестировщик имеет собственную периферию (монитор, клавиатуру, мышь) для проверки компьютера;
каждый тестировщик подсоединяет кабель питания и периферию для настольного компьютера и кабель питания для ноутбука;
каждый тестировщик запускает с дискеты программу диагностики, которая тестирует компоненты компьютера;
если программа диагностики определяет неработающий компонент, тестировщик заменяет его исправным. Тестирование и замена компонентов проводится до тех пор, пока все компоненты компьютера не будут исправлены;
каждый проверенный компьютер хранится до тех пор, пока диспетчер не даст распоряжение об отгрузке партии;
неисправные компоненты направляются на отгрузку для возврата поставщикам.
На основании этой информации необходимо декомпозировать (в нотации IDEF3) работу “Тестирование компьютеров” диаграммы А2.
Создайте UOW:
подключение периферии;
запуск программы диагностики;
формирование партии;
замена неисправных компонентов. Создайте четыре объекта ссылок:
периферия;
компьютер;
заказы;
компоненты.
Соедините работы и объекты ссылок стрелками, как показано на рис. 5.17.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 04d4.bpl, окончание — файл 04s.bpl.
Рис. 5.17
Создание сценария
Выберите пункт меню Insert / FEO Diagram.
Создайте диаграмму FEO на основе диаграммы IDEF3 “Сборка настольных компьютеров” А22.1 (рис. 5.18).
Рис. 5.18
Удалите элементы, не входящие в сценарий.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 04s.bpl, окончание — файл O5d.bpl.
Задание. Создание сценария
На основе диаграммы IDEF3 “Тестирование компьютеров” (А24.1) создайте сценарий, описывающий путь неисправных компонентов. В сценарий должны входить только объекты, содержащие неисправные компоненты (рис. 5.19).
Рис. 5.19
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл O5d.bpl, окончание — файл O5s.bpl.
Затратный (Cost) анализ
Исходные данные для анализа (Activity Based Costing).
На производственном участке работают 5 сборщиков и 1 тестировщик.
В среднем в день собирается 12 настольных компьютеров и 20 ноутбуков.
Двое сборщиков являются стажерами.
601
ors ЭНД
1:1:.я***^ p5P^f^^
1:
1:
Ш5й6л^^д^А^ <^?>^:^Й1»^*^ :
flilli
*e~^s^l^*e~^s^l^
*e~^s^l^
*e~^s^l^
' ^ <«< А ' V'- 'И V, ^^ , " ~'^ f^ ^-V'' ^/ ' * ч\'
>' w:'; ^' '^ ■ "^ *^ 1 **«V I - *w*a I '**н -:,#w**/"4 c*№x | ;**»s 1, mgr J_**мбйк
Е]
(OZ'S эиф л\э1Д ошэи ики sspjQdoJd ppopQ энмо монолокеи!/ я jn(j/bdJj/)SO9 Хцлцэу omhiio яиьоишю ‘Э8У 9° ииПвндофни кинэжяйдою мижас! чхиьоишю этдооя эхэжои ид s)iuf| J8V snuXdj я ияионмоиКвд эхин -oiifMadan и XegdsiQ яя^вкяве ‘saiuadojj ppopj онио эонохокви!/ я эхиН -yadau wxogud иxooнчIfэxижIfoto'odц ики нхоховь кинэжвdgoxo кф
BHHH4E0jX0WKdH
XlcjX иояэк иэнжин я кoxэEжвdgoxo Hxogud ио№вм чхэомиохэ
•рру ЭЛИОНЯ Oil ЭХИНЯКЭЙ! и эин -airafaduo ‘эинвяонэиивн axndaguH xudiEE EdxHali кинэээня Kirff •£
9О1НЭНОЦИОЯ КяиХяВЕ ЕН I4iedLe£ I41H9HOUWO){godaioMuwoa
waHHEaodHioax и yoMdogo хшкнбе ‘xHhogBd Xlbihio eh mEdxE£ вино квьодв^ woHHBaodmooi и yoxdogo
Квн wonodxHOM ‘aodoioiqujMOM HHidEii иэинвяodиJмdoф ‘xogBd
ЕМИфвсЬ МЭИНЭКЯЕХЭОЭ О Э1ЧННВЕКЯЭ ‘OHHOKflBduX BH I4XBdXB£ OHHOKflBdnA эииэкэКадиоxbcLlbe dxHag
•xudxEE flodxHati aHHaifal/aduo и эинвяеен ахиэаня зхэщээ jsoj □ду эняо иояохоитиК я и дхэщээ )§оэ Э8У / 1!РЗ 9 oxHKyadan 3
•HHawadfl и хэнэК KHHodowEH нйиниГэ эхияонвхэХ s^iuq ЭЯ V эяКеюгее я (ура синаи ей КОХЭЕЯ1ЧЕ1ЧЯ) sagxadoxj рроэд эняо иояохокви# д ‘ {
'$00tl — вяХдхХон Kiftf ‘$008 хэккявхэ
-ОЭ ^ЭХО1Ч11ИОЛ ОХОНЧ1ГОХЭЕН KlfK ЯОХНЭНОПИОЯ ЧХЭОИИОХЭ KKHtod3
OBh Я $£ OUIчdaжвxэ ‘ЭВЬ Я $01 ОЦ XOIBh -Хкои яиПIЯodиxээx и яиП^одэ ‘Пкээи я $QOS BdohxoiiaHr BXBifudBg
Для указания стоимости работы следует щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню Cost Editor.
Внесите следующие параметры АВС (табл. 5.5).
Таблица 5.5
Параметры АВС для назначения стоимости работы
Функциональный блок
Cost Center
Затраты
Продолжительность
Частота
Отслеживание расписания и управление сборкой и тестированием
Управление
25,00
1,00
1,00
Сборка настольных компьютеров
Рабочая сила
5,00
1,00
12,00
Компоненты
800,00
Сборка ноутбуков
Рабочая сила
7,50
1,00
20,00
Компоненты
1 400,00
Тестирование компьютеров
Рабочая сила
2,00
1,00
32,00
Посмотрите результат — стоимость работы верхнего уровня.
Сгенерируйте отчет Activity Cost Report.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл O5s.bpl, окончание — файл 06d.bpl.
Задание
Определите стоимость работы “Отгрузка и получение”.
В среднем собирается в день 12 настольных компьютеров и 20 ноутбуков. 80% потребителей расположены ближе 100 км, 20% — дальше. Стоимость доставки компьютера ближе 100 км обходится в среднем в 10$, дальше 100 км — в 20$.
Создайте центр затрат “Транспортные расходы”.
Подсчитайте и назначьте стоимость работе “Отгрузка и получение”. Частота — 32 (компьютера в день). Продолжительность — 1. Стоимость по центру затрат “Транспортные расходы”: 0.8*10+0.2*20=12$.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 06d.bpl, окончание — файл 06s.bpl.
ПО
Использование категорий UDP
Выполните следующие действия.
Перейдите в Edit / UDP Definition и в диалоговом окне User- Defined Property Name Editor внесите название категорий (табл. 5.6).
Для внесения категории необходимо в поле New Category / Member внести наименование категории и щелкнуть по кнопке Add Category (рис. 5.21).
Categerieae' " '' "\ \ ^yV^vS*
Information systemж
; Quality measure^
Resources consumption‘
<h'аж^йой^I >;ftjtti^^
Рис. 5.21
Внесите следующие категории:
Resources Consumption (расход ресурсов);
Documentation (документация);
Information System (информационная система);
Quality Measure (мера измерения качества).
Создайте UDP. Для этого в поле User-Defined Property (UDP) to be added after selected property внесите имя UDP, например, “Quality”. Затем выберите тип UDP из комбобокса Datatype — “Text List (Single selection)”, после чего щелкните по кнопке Add.
Для UDP типа List необходимо задать список значений. В поле New Category/Member внесите значение “A-Terrific” и щелкните по кнопке Add Member. Затем внесите другие значения UDP Quality:
B-Good;
С-ОК;
Список UDP для модели
Наименование UDP
Тип
Члены
Категория
Application (приложения)
Text List (Multiple Selection)
COS — Customer Order System (модуль оформления заказов) ESS — Employee Sheduler System (модуль создания и контроля расписания выполнения работ)
PIS — Parts and Inventory System (модуль учета комплектующих и оборудования)
PTS — Procedures and Troubleshooting System (модуль процедур сборки и поиска неисправностей)
Information System
Screen
Command
Information System
Additional Documentation (дополнительная документация)
Command List
Winword.EXE samplel.doc
1 Winword.EXE sample2.doc
POWERPNT.EXE sample3.ppt
Documentation
Change History (история изменения)
Paragraph Text
Documentation
Electricity Consumption (расход электроэнергии)
Real Number
Resources
Consumption
Внесите значения UDP для следующих работ (табл. 5.7).
Значения UDP для модели
Таблица 5.7
Функциональный блок
Дополнительная документация
Приложение
История изменений
Потребление энергии
Качество
Отслеживание расписания и управление сборкой и тестированием
Winword.EXE sample2.doc
COS — Customer Order
System ESS — Employee Sheduler System
История изменения спецификаций
10,00
B-Good
Продолжение
Функциональный блок
Дополнительная документация
Приложение
История изменений
Потребление энергии
Качество
Сборка настольных компьютеров
PIS — Parts and Inventory System
PTS — Procedures and Troubleshooting System
20,00
A-Terrific
Сборка ноутбуков
PIS — Parts and Inventory System
PTS — Procedures and
Troubleshooting System
25,00
С-ОК
Тестирование компьютеров
PIS — Parts and Inventory System
PTS — Procedures and Troubleshooting System
40,00
B-Good
После внесения UDP типа Command или Command List щелчок по кнопке *t| приведет к запуску приложения.
В диалоговом окне IDDEFO Activity Properties щелкните по кнопке Categories. В появившемся новом диалоговом окне Activity Categories Editor отключите категорию Information System. Щелкните по кнопке ОК. Посмотрите результат.
Свойства UDP можно присвоить не только работам, но и стрелкам. Щелкните по стрелке правой кнопкой и выберите в контекстном меню UDP Editor.
Задайте значения UDP следующим стрелкам:
Наименование стрелкиКачество
Заказы на настольные компьютерыB-Good
НоутбукиB-Good
Собранные компьютерыA-Terrific
Посмотрите отчетпо UDP. Меню Report / Diagram Object
Report. Выберите опции отчета:
Start from Activity : A2. Сборка и тестирование компьютеров.
Number of Levels : 2.
User Defined Properties: Electricity Consumption.
Report Format: RPTwin.
Щелкните по кнопке Report. В появившемся диалоговом окне “Сохранение файла” щелкните по кнопке “Сохранить”.
Запускается генератор отчетов RPTwin и появляется диалоговое окно New Report. Выберите тип отчета Columnar (рис. 5.22).
Рис. 5.22Рис. 5.22
Рис. 5.22
Рис. 5.22
Автоматически создается шаблон отчета (рис. 5.23).
О Sb: &<” jgmjjhMX &«**; йрбйт \&H*w ЙФ' - >О Sb: &<” jgmjjhMX &«**; йрбйт \&H*w ЙФ' - >£1£|..^5ЙЖ12;£31&<^i£LjLJLi&uLialib^£1£|..^5ЙЖ12;£31&<^i£LjLJLi&uLialib^—HReport Header—HReport Header9;<НвРАСТоое5 9*039;<НвРАСТоое5 9*03Ft**ЙFt**Й'***—*< f'age Meader'***—*< f'age Meader°J *jr*ttyN6*e°J *jr*ttyN6*es.s.55«г«г^ Activity Neme^ Activity Neme0;0;
О Sb: &<” jgmjjhMX &«**; йрбйт \&H*w ЙФ' - >
О Sb: &<” jgmjjhMX &«**; йрбйт \&H*w ЙФ' - >
£1£|..^5ЙЖ12
;£31&<^i£LjLJLi&uLialib^
£1£|..^5ЙЖ12
;£31&<^i£LjLJLi&uLialib^
—HReport Header
—HReport Header
9;
<НвРАСТоое
5 9*03
9;
<НвРАСТоое
5 9*03
Ft
**Й
Ft
**Й
'***—*< f'age Meader
'***—*< f'age Meader
°J *jr*ttyN6*e
°J *jr*ttyN6*e
s.
s.
5
5
«г
«г
^ Activity Neme
^ Activity Neme
0;
0;
Рис. 5.23
Нажатие на кнопку “Предварительный просмотр” позволяет просмотреть отчет.
Отразите в отчете суммарный расход электроэнергии.
Выберите в меню Insert / Formula Field, затем переместите маркер в секцию отчета Page Footer, после чего щелкните один раз. Появляется диалоговое окно Formula Editor (рис. 5.24).
В поле Formula внесите текст формулы:
Sum ({Electricity Consumption})
F ormula F diloi
Sum ((Etectiicity Consumption)) 1 3$?
' О^#'С^кпЙ;' О^#'С^кпЙ;:R**8««^:R**8««^■Dptwata»■Dptwata»*•” 4 5 S*•” 4 5 SC*x*iC*x*iSign (NUMBER?) Sin (NUMBER?)Sign (NUMBER?) Sin (NUMBER?)Tan(NUMBER?)4Time()VToDate (DATETIMESTR?. FOR-* ToNumber (STRING?) ДTan(NUMBER?)4Time()VToDate (DATETIMESTR?. FOR-* ToNumber (STRING?) ДРис. 5.24Рис. 5.24ЖЖ
' О^#'С^кпЙ;
' О^#'С^кпЙ;
:R**8««^
:R**8««^
■Dptwata»
■Dptwata»
*•” 4 5 S
*•” 4 5 S
C*x*i
C*x*i
Sign (NUMBER?) Sin (NUMBER?)
Sign (NUMBER?) Sin (NUMBER?)
Tan(NUMBER?)4
Time()V
ToDate (DATETIMESTR?. FOR-* ToNumber (STRING?) Д
Tan(NUMBER?)4
Time()V
ToDate (DATETIMESTR?. FOR-* ToNumber (STRING?) Д
Рис. 5.24
Рис. 5.24
Ж
Ж
Затем щелкните по кнопке ОК.
Просмотрите отчет.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 06s.bpl, окончание — файл 07d.bpl.
5.175.17Задание. Использование категорий UDP
5.17
5.17
Создайте еще два UDP (табл. 5.8).
Таблица 5.8
Категории UDP
Наименование UDP
Тип
Члены
Категория
Responsibility (ответственность)
Text List (Single Selection)
Ivanov Petrov Sidorov
Quality Measure
Customer Satisfaction (оценка клиента)
Integer List (Single Selection)
1
2
3
4
5
Quality Measure
Задайте свойства работам (табл. 5.9).
Свойства работ UDP
Таблица 5.9
Функциональный блок
Ответственный
Удовлетворенность заказчика
Отслеживание расписания и управление сборкой и тестированием
Манышкин
4
Сборка настольных компьютеров
Морковин
4
Сборка ноутбуков
Нечаева
5
Тестирование компьютеров
Шобанов
4
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 07d.bpl, окончание — файл 07s.bpl.
5.18 Расщепление модели
Перейдите на диаграмму АО и щелкните правой кнопкой мыши по работе “Отгрузка и получение”. В контекстном меню выберите Split Model.
В появившемся диалоговом окне Split Option установите опцию Enable Merge/Overwrite Option, внесите имя новой модели — “Отгрузка и получение” и щелкните по кнопке ОК.
Обратите внимание, что у работы “Отгрузка и получение” появилась стрелка вызова.
BPWin создал также новую модель “Отгрузка и получение”.
Внесите свойства новой модели:
Time Frame: AS-IS;
Purpose: документировать работу “Отгрузка и получение”;
Viewpoint: начальник отдела;
Definition: модель создается для иллюстрации возможностей BPWin по расщеплению и слиянию моделей;
Scope: работы по получению комплектующих и отправке готовой продукции.
Декомпозируйте контекстную работу на следующие работы.
Функциональный блок Получить комплектующиеДоставить комплектующиеОтгрузить товар и возвратФункциональный блок Получить комплектующиеДоставить комплектующиеОтгрузить товар и возвратРис. 5.25Рис. 5.25
Функциональный блок Получить комплектующие
Доставить комплектующие
Отгрузить товар и возврат
Функциональный блок Получить комплектующие
Доставить комплектующие
Отгрузить товар и возврат
Рис. 5.25
Рис. 5.25
Описание
Физически получить комплектующие и сделать соответствующие записи в информационной системе
Доставить комплектующие сборщикам и тестировщикам
Отгрузить товар клиентам и неисправные компоненты (возврат) поставщикам.
Свяжите граничные стрелки, как показано на рис. 5.25.
Внесите следующие внутренние и граничные стрелки:
НаименованиеВозврат поставщикуКомпонентыКомпоненты от поставщикаПроверенные компонентыНаименованиеВозврат поставщикуКомпонентыКомпоненты от поставщикаПроверенные компонентыОписание
Наименование
Возврат поставщику
Компоненты
Компоненты от поставщика
Проверенные компоненты
Наименование
Возврат поставщику
Компоненты
Компоненты от поставщика
Проверенные компоненты
Неисправные компоненты
Выберите название из списка (словаря)
Выберите название из списка (словаря) Проверенные и подготовленные для передачи сборщикам и тестировщикам компоненты.
Туннелируйте граничные стрелки (Resolve Border Arrow) — рис. 5.26.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 07s.bpl, окончание — файл O8dl.bpl и split.bp 1.
117
Рис. 5.26
5 19 Слияние расщепленной модели* с исходной («as is») моделью
Выполните следующие действия.
Перейдите в модель “Деятельность компании Quill”. На диаграмме АО щелкните правой кнопкой мыши по работе “Отгрузка и получение”. В контекстном меню выберите Merge Model.
В появившемся диалоговом окне Continue with Merge? установите опцию Paste/Merge entire dictionaries и щелкните по кнопке ОК.
Обратите внимание, что у работы “Отгрузка и получение” исчезла стрелка вызова и появилась новая декомпозиция.
Появились новые стрелки с квадратными скобками. Туннелируйте эти стрелки (Resolve Border Arrow).
На диаграмме АО туннелируйте и свяжите стрелки согласно рис. 5.27.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл O8dl.bpl и split.bpl, окончание — файл 08d2.bpl.
Рис. 5.27
5.20 Копирование работ
Копирование работ в другую модель.
Создайте новую модель “ТЕСТ”. Декомпозируйте контекстную работу в новой модели, но не вносите имена работ.
Переключите Model Explorer в режим Activity. Используя drag&drop, перенесите какую-нибудь работу из модели “Деятельность компании Quill” на диаграмму декомпозиции модели “ТЕСТ”. В появившемся диалоговом окне Continue with Merge? установите опцию Paste/Merge entire dictionaries и щелкните по ОК. Посмотрите результат.
Перемещение работ в той же самой модели.
Щелкните по работе в модели “ТЕСТ” и переместите работу на место неназванной работы на другой диаграмме. В появившемся диалоговом окне Continue with Merge? щелкните по ОК. Посмотрите результат.
Закройте модели без сохранения.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 08d2.bpl.
5.215.21Задание. Создание нормативной («to-be») модели
5.21
5.21
Оценка бизнес-процессов модели AS-IS показала недостаточную эффективность деятельности компании Quill. В первую очередь это касается производственного отдела. Собираемые компьютеры не всегда пользуются достаточным спросом. Закупаемые компоненты часто чрезмерно дороги при посредственном качестве. Функциональность компьютеров не соответствует требованиям рынка.
В результате анализа компания принимает решение реорганизовать функции производства и тестирования компьютеров. Кроме того, принимается решение оставить функциональность “Продажи и маркетинг” и “Отгрузка и получение” пока без изменений.
Принято решение сформировать отдел дизайна, который должен формировать конфигурацию компьютеров, разрабатывать корпоративные стандарты, подбирать приемлемых поставщиков, разрабатывать инструкции по сборке, процедуры тестирования и устранения неполадок для всего производственного отдела.
Работа “Сборка и тестирование компьютеров” должна быть реорганизована и названа “Производство продукта”. Сначала мы создадим работы “Разработать конфигурацию”, “Планировать производство” и “Собрать продукт”.
Рассмотрим новые роли персонала:
дизайнер должен разрабатывать систему;
дизайнер должен разрабатывать стандарты на продукцию, документировать и передавать спецификации в отдел маркетинга и продаж;
дизайнер должен определять, какие компоненты (software и hardware) должны закупаться для сборки компьютеров;
дизайнер должен обеспечивать документацией и управлять процедурами сборки, тестирования и устранения неполадок.
Функции диспетчера в работе “Сборка и тестирование компьютеров” должны быть изменены:
диспетчер должен обрабатывать заказы клиентов и генерировать заказы на сборку;
диспетчер должен получить коммерческий прогноз из отдела маркетинга и формировать требования на закупку компонент;
диспетчер должен собирать информацию от поставщиков и должен быть ответствен за оформление заказов на поставку;
диспетчер должен составлять расписание производства на основании заказов на сборку, полученных в результате работы “Планировать производство”;
диспетчер также должен получать копии заказов клиентов и отвечать за упаковку и комплектацию заказанных компьютеров, передаваемых в работу “Отгрузка и получение”.
Задание состоит из пяти этапов. Выполняя каждый этап, Вы должны использовать приобретенные навыки.
Расщепление и модификация модели.
Слияние расщепленной модели с исходной моделью.
Использование Model Explorer для реорганизации дерева декомпозиции.
Модификация диаграммы IDEF3 “Собрать продукт” с целью отображения новой информации.
Добавление декомпозиции работы “Продажи и маркетинг”.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 08d2.bpl, окончание — файл 08s4.bpl.
Этап 1 | Расщепление модели
Сохраните модель 08d2.bpl в файл 08d2b.bpl и отредактируйте свойства модели:
Model Name: Предлагаемая модель компании Quill.
Time Frame: TO-BE
Purpose: документировать предлагаемые изменения бизнес-про- цессов компании Quill.
Переименуйте работу “Сборка и тестирование компьютеров” в “Производство продукта”. Расщепите эту работу в модель с тем же названием.
Модифицируйте отщепленную модель. Переместите работу “Тестирование компьютеров” с диаграммы АО “Производство продукта” на диаграмму А2.1 “Сборка настольных компьютеров”.
Переименуйте работу “Сборка настольных компьютеров” на диаграмме АО в “Сборку продукта”.
Удалите работу “Сборка ноутбуков”.
Переименуйте стрелку “Заказы на настольные компьютеры” в “Заказы на изготовление”.
Переименуйте “Отслеживание расписания и управление сборкой и тестированием” в “Планирование производства”.
Создайте работу “Разработать конфигурацию”.
Создайте ветвь стрелки “Персонал производственного отдела”, назовите ее “Дизайнер” и направьте как механизм к работе “Разработать конфигурацию”.
Создайте стрелку “Стандарты на продукцию” и направьте ее от выхода “Разработать конфигурацию” к границе диаграммы. Туннелируйте эту стрелку (Resolve Border Arrow). Создайте ветвь этой стрелки, идущую к управлению работы “Планирование производства” и назовите ее “Список необходимых компонентов”.
Удалите стрелку “Правила сборки и тестирования”. Создайте ветвь стрелки “Стандарты на продукцию”, идущую к управлению работы “Сборка продукта” и назовите ее “Правила сборки и тестирования”.
Переименуйте стрелку “Диспетчер” в “Планировщик производства”.
Добавьте стрелку “Прогноз продаж” как граничную управляющую к работе “Планирование производства”.
Добавьте стрелку “Информация от поставщика” как граничную управляющую к работе “Планирование производства”.
Информация от поставщикаИнформация от поставщикаПрогноз продажПрогноз продажЗаказы клиентов ~,
Информация от поставщика
Информация от поставщика
Прогноз продаж
Прогноз продаж
Заказ поставщикуЗаказ поставщикуПланированиепроизводстваПланированиепроизводстваКомпонентыКомпонентыЗаказына изготов-лениеЗаказына изготов-лениеПравила сборки и тестирования Результаты сборки —и тестированияПравила сборки и тестирования Результаты сборки —и тестированияСборкапродукта2Сборкапродукта2Неисправные компонентыНеисправные компонентыСобранные компьютерыСобранные компьютерыПланировщик производстваПланировщик производстваРазработкаконфигурациизРазработкаконфигурациизСтандартына продукциюСтандартына продукциюПерсонал производственного отделаПерсонал производственного отделаДизайнерДизайнерСписок необходимых компонентов
Заказ поставщику
Заказ поставщику
Планированиепроизводства
Планированиепроизводства
Компоненты
Компоненты
Заказына изготов-ление
Заказына изготов-ление
Правила сборки и тестирования Результаты сборки —и тестирования
Правила сборки и тестирования Результаты сборки —и тестирования
Сборкапродукта
2
Сборкапродукта
2
Неисправные компоненты
Неисправные компоненты
Собранные компьютеры
Собранные компьютеры
Планировщик производства
Планировщик производства
Разработкаконфигурации
з
Разработкаконфигурации
з
Стандартына продукцию
Стандартына продукцию
Персонал производственного отдела
Персонал производственного отдела
Дизайнер
Дизайнер
Информация от поставщикаИнформация от поставщикаЗаказы клиентовЗаказы клиентовПрогноз продажПрогноз продаж
Информация от поставщика
Информация от поставщика
Заказы клиентов
Заказы клиентов
Прогноз продаж
Прогноз продаж
—Результаты сборки и тестирования Заказ поставщику
КомпонентыКомпонентыПроизводствоНеисправные компоненты
Компоненты
Компоненты
продуктовСобранные компьютеры
0 Стандарты на продукцию
Рис. 5.29
Добавьте стрелку “Заказ поставщику” как граничную стрелку выхода от работы “Планирование производства”.
Туннелируйте эти стрелки (Resolve Border Arrow).
На диаграмме АО туннелируйте стрелку (Resolve Border Arrow) “Собранные компьютеры” и свяжите ее на диаграмме АО с выходом работы “Сборка продукта”.
Результат приведен на рис. 5.28, 5.29.
Сохраните модифицированную модель как 08sla.bpl, а модель верхнего уровня (Деятельность компании Quill) как O8slb.bpl.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл O8d2.bpl, окончание — файлы 08d2b.bpl, 08s4.bpl,08slb.bpl.
Этап 2 Слияние модели
Перейдите к работе “Производство продукта” в модели “Деятельность компании Quill”. Щелкните правой кнопкой мыши по работе. В контекстном меню выберите Merge Model.
В появившемся диалоговом окне Continue with Merge? установите опцию Paste/Merge entire dictionaries, опцию Overwrite existing fields и щелкните по кнопке OK.
Модели должны слиться.
На диаграмме АО туннелируйте стрелки (Resolve Border Arrow) “Информация от поставщика” и “Заказ поставщику”.
Направьте стрелку “Прогноз продаж” с выхода “Продажи и маркетинг” на управление “Производство продукта”.
Направьте стрелку “Стандарты на продукцию” с выхода “Производство продукта” на управление “Продажи и маркетинг”.
Удалите ветвь стрелки управления “Правила и процедуры” работы “Производство продукта”.
Закройте модель “Производство продукта”.
Результат приведен на рис. 5.30, 5.31.
Рис. 5.30Рис. 5.30Правила и процедурыПравила и процедурыИнформация от поставщикаИнформация от поставщика
Рис. 5.30
Рис. 5.30
Правила и процедуры
Правила и процедуры
Информация от поставщика
Информация от поставщика
Маркетинговые материалы
Звонки клиентовЗвонки клиентовКомпоненты от поставщикаКомпоненты от поставщикаДеятельность компании QuillДеятельность компании QuillЗаказ поставщикуЗаказ поставщикуВозврат поставщикуВозврат поставщику$9685$9685ооПроданные продуктыПроданные продукты
Звонки клиентов
Звонки клиентов
Компоненты от поставщика
Компоненты от поставщика
Деятельность компании Quill
Деятельность компании Quill
Заказ поставщику
Заказ поставщику
Возврат поставщику
Возврат поставщику
$9685
$9685
о
о
Проданные продукты
Проданные продукты
Viewpoint Директор
Бухгалтерская системаБухгалтерская системаPurpose Моделировать текущие (AS-IS) бизнес-процессы компании Quill
Бухгалтерская система
Бухгалтерская система
Рис. 5.31
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файлы 08sla.bpl, 08slb.bpl, окончание — файл
08s2.bpl.
Этап 3Этап 3Использование Model Explorer
Этап 3
Этап 3
Существуют причины, по которым работа “Разработать конфигурацию” должна быть на верхнем уровне, на диаграмме АО. Действительно, дизайнер разрабатывает стандарты на продукцию, включая правила сборки и тестирования и список необходимых для закупки компонентов. Тем самым дизайнер управляет производством продукта в целом, кроме того, управляет работой “Продажи и маркетинг”.
Было бы логично перенести эту работу на уровень выше.
Используя возможности Model Explorer, перенесите работу “Разработать конфигурацию” с диаграммы А2 “Производство продукта” на диаграмму АО.
Разрешите и перенаправьте стрелки согласно рис. 5.32, 5.33.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файлы 08s2.bpl окончание — файл O8s3.bpl.
Рис. 5.33
Этап 4Этап 4Модификация диаграммы IDEF3 “Сборка продукта”
Этап 4
Этап 4
Так же как в модели «as is», сборка продукта включает сборку компонентов и установку программного обеспечения. Однако теперь в работу “Сборка продукта” включена работа “Тестирование компьютера”.
Тестирование начинается после окончания процесса сборки компьютера и окончания процесса установки программного обеспечения. Если компьютер неисправен, в процессе тестирования у него заменяют компоненты, информация о неисправных компонентах может быть направлена на работу “Подготовка компонентов”. Такая информация может помочь более тщательно подготавливать компоненты к сборке. Результатом процесса тестирования являются заказанные компьютеры и неисправные компоненты.
Модифицируйте диаграмму IDEF3 “Сборка продукта” в соответствии с приведенной информацией. Результат сверьте с рис. 5.34.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файлы O8s3.bpl окончание — файл 08s4.bpl.
Этап 5Этап 5Декомпозиция процесса “Продажа и маркетинг”
Этап 5
Этап 5
Работа по продажам и маркетингу заключается в ответах на телефонные звонки клиентов, предоставлении клиентам информации о ценах, оформлении заказов, внесении заказов в информационную систему и исследовании рынка.
На основе этой информации декомпозируйте работу “Продажи и маркетинг” (IDEF0).
Создайте следующие работы:
предоставление информации о ценах;
оформление заказов;
исследование рынка.
Результат декомпозиции представлен на рис. 5.35.
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файлы 08s4.bpl, окончание — файл O8s5.bpl.
5.22 Создание диаграммы DFD
При оформлении заказа важно проверить, существует ли такой клиент в нашей базе данных и, если не существует, внести его в БД и затем оформить заказ. Оформление заказа начинается со звонка клиента. В процессе оформления заказа БД клиентов может просматриваться и редактироваться. Заказ должен включать информацию о клиенте и информацию о заказанных продуктах. Оформление заказа подразумевает чтение и запись информации о прочих заказах.
В процессе декомпозиции согласно правилам DFD мы преобразу
ем граничные стрелки во внутренние, начинающиеся и заканчиваю
щиеся на внешних ссылках.
Декомпозируйте работу “Оформление заказов” на диаграмме А2.
В диалоговом окне Activity Box Count выберите количество ра
Activity Box CountActivity Box CountИИГ jDEFO ^ &F0 Г IDEF3 .Г jDEFO ^ &F0 Г IDEF3 .бот 2 и нотацию DFD (рис. 5.36).
Activity Box Count
Activity Box Count
И
И
Г jDEFO ^ &F0 Г IDEF3 .
Г jDEFO ^ &F0 Г IDEF3 .
Щелкните по кнопке ОК и внесите на новой диаграмме DFD А22 имена работ:
проверка и внесение клиента;
внесение заказа.,
Используя кнопку Q на палитре инструментов, внесите хранилища данных:
список клиентов;рИСе 5.35
список продуктов;
список заказов.
Удалите граничные стрелки с диаграммы DFD А22.
Используя кнопку □, на палитре инструментов, внесите внешнюю ссылку: звонки клиентов.
Создайте внутренние ссылки согласно рис. 5.37. При именовании стрелок используйте словарь.
Обратите внимание, что стрелки “Информация о клиентах” и “Заказы клиентов” двунаправленные. Для того чтобы сделать стрелку
Рис. 5.37
двунаправленной, щелкните правой кнопкой по стрелке, выберите в контекстном меню пункт Style Editor и в диалоговом окне Style Editor выберите опцию Bidirectional.
На родительской диаграмме А2 туннелируйте (Change to Tunnel) стрелки, подходящие и исходящие из работы “Оформление заказов” (рис. 5.38).
Рис. 5.38
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл O8s5.bpl, окончание — файл 09dl.bpl.
5.235.23Использование стрелок IDEF0 на диаграмме DFD
5.23
5.23
Некоторые стрелки с диаграммы IDEF0 (не только с родительской) могут показываться на диаграмме DFD. Для отображения таких стрелок используется инструмент Off-Page Reference.
Декомпозируйте работу “Исследование рынка” на диаграмме А2 на диаграмму DFD. Удалите граничные стрелки. Создайте следующие работы:
разработка прогнозов продаж;
разработка маркетинговых материалов;
привлечение новых клиентов.
Используя кнопку EZj на палитре инструментов, внесите хранилища данных:
список клиентов;
список продуктов;
список заказов.
Добавьте две внешние ссылки:
маркетинговые материалы;
прогноз продаж.
Свяжите объекты диаграммы DFD стрелками, как показано на рис. 5.39.
На родительской диаграмме А2 туннелируйте (Change to Tunnel) стрелки, подходящие и исходящие из работы “Исследование рынка”.
Проверка и внесение клиента 2
Информация о новом клиенте ^
Рис. 5.40Рис. 5.40В случае внесения новых клиентов в работу “Проверка и внесение клиента” на диаграмме А22 “Оформление заказов” информация должна направляться к работе “Привлечение новых клиентов” диаграммы А23 “Исследование рынка”. Для этого необходимо использовать инструмент Off-Page Reference. На диаграмме А22 “Оформление заказов” создайте новую граничную стрелку, исходящую от работы “Проверка и внесение клиента”, и назовите ее “Информация о новом клиенте” (рис. 5.40).
Рис. 5.40
Рис. 5.40
Правой кнопкой щелкните по наконечнику стрелки и выберите в меню Off-Page Reference. В появившемся диалоговом окне Off-Page Arrow Reference выберите в качестве диаграммы A23D “Исследование рынка” (рис. 5.41).
Off-Page Arrow Reference
Diagram?У г
', .и©®ЯПаП13П12^7 ; ч; ' Г ' V '" й А ч| ' V ,
>Л^т\'/^' ч*'?1* ” < *,ч%'ч^ «W*A^t*t*WWW*****WWW*WWW*MMwW*^^
*™^^?V*^ 'v '” ^ "sl***W***l*WWW*№N«w**iiH5fMww^^
Рис. 5.41
Перейдите в меню Edit / Model Properties, далее — закладка Display. Установите опцию Off-Page Reference label — Node number.
Перейдите на диаграмму A23D “Исследование рынка” и на-
Информация о новом клиентеИнформация о новом клиентеПривлечение новых клиентов 3Привлечение новых клиентов 3Рис. 5.42Рис. 5.42правьте стрелку “Информация о новом клиенте” на вход работы “Привлечение новых клиентов”. Результат представлен на рис. 5.42.
Информация о новом клиенте
Информация о новом клиенте
Привлечение новых клиентов 3
Привлечение новых клиентов 3
Рис. 5.42
Рис. 5.42
Проверить правильность
выполнения задания мож
но с использованием файлов, полученных из Интернета: начало — файл 09d 1 .bp 1,' окончание — файл 09d2.bp 1.
5.245.24Интеграция процессов и данных на базе Erwin и BPWin
5.24
5.24
Импорт модели данных из Erwin в BPWin.
Создайте папку для сохранения файлов импорта-экспорта C:\BPCLASS/
Загрузите Erwin. Откройте (меню File/ Open...) модель QUILL.ER1.
Перейдите в меню File/BPWin /Export (рис. 5.43).
rEte ModeNart ^ ^' £fer* ^°^ ^^-^о""-. ■' • V rtesM ЛrEte ModeNart ^ ^' £fer* ^°^ ^^-^о""-. ■' • V rtesM ЛРис. 5.43Рис. 5.43
rEte ModeNart ^ ^' £fer* ^°^ ^^-^
о""-. ■' • V rtesM Л
rEte ModeNart ^ ^' £fer* ^°^ ^^-^
о""-. ■' • V rtesM Л
Рис. 5.43
Рис. 5.43
Сохраните файл экспорта в папке C:\BPCLASS.
Перейдите в BPWin.
Перейдите в меню File/Import/Erwin (ЕАХ).
В появившемся диалоговом окне Open выберите файл экспорта ЕАХ (в папке C:\BPCLASS — рис. 5.44).
|>ЖЖ EjBpda*
КВ
Хмпфайяож (е^ЯмЕми)
у,
*3 OtMww |;
В диалоговом окне Import Differences Preview просмотрите результаты импорта и закройте диалоговое окно (Close).
В диалоговом окне Import From EAX Verification щелкните по
Рис. 5.45Рис. 5.45кнопке Accept Changes (рис. 5.45).
Рис. 5.45
Рис. 5.45
Перейдите в меню Edit / Entity / Attribute Dictionary и просмотрите результаты импорта.
В закладке General диалогового окна Model properties включите опцию Apply CRUD/IRUN Restrictions.
Назначение ассоциаций сущностей и атрибутов:
Перейдите к диаграмме А2.
Правой кнопкой мыши щелкните по стрелке “Заявки на заказ” и выберите пункт меню Arrow Date.
В диалоговом окне IDEFO Arrow Properties выберите “чекбоксы” Q сущностей и атрибутов, которые необходимо ассоциировать со стрелкой.
Таблица 5.10
Сущности и их атрибуты
Наименование стрелки
Наименование сущности
Наименование атрибута
Заявки на заказ
CUSTOMER
Customer City
Customer Company Name
Customer Fax Number
Customer First Name
Customer Last Name
Customer Number
Customer Phone Number
Customer State
Customer Street Address
Customer Zip Code
LINE ITEM
Line Item Quantity
Line Item Sequence Number
Line Item Total
Product Code
Sales Order Number
Продолжение
Наименование стрелки
Наименование сущности Наименование атрибута
Заявки на заказ
Customer Number Employee Id
Payment Number Sales Order Datetime
Sales Order Number
SALES ORDERSales Order shlPment
Charge Sales Order Shipment Datetime Sales Order Status Sales Order Total Shipment Method Code
Правой кнопкой мыши щелкните по стрелке “Заказы клиентов” и выберите пункт меню Arrow Date.
Используя кнопку Copy In в диалоговом окне IDEFO Arrow Properties, ассоциируйте тот же самый набор сущностей и атрибутов со стрелкой “Заказы клиентов” в соответствии с табл. 5.10.
Назначение CRUD/IRUN ассоциаций:
Правой кнопкой щелкните по работе “Оформление заказов”. В контекстном меню выберите Data Usage Editor (рис. 5.46).
Типы атрибутовТипы атрибутовВ диалоговом окне BPWin Data Usage Editor выберите CRUD/IRUN, которые необходимо ассоциировать со стрелкой “Заявки на заказ” в соответствии с табл. 5.11.
Типы атрибутов
Типы атрибутов
Наименование атрибута
R (CRUD)
U (CRUD)
R (IRUN)
U (IRUN)
Customer City
R
U
R
U
Customer Company Name
R
U
R
U
Customer Fax Number
R
U
R
U
Customer First Name
R
U
R
U
Customer Last Name
R
U
R
U
Customer Number
R
U
R
U
Customer Phone Number
R
U
R
U
Customer State
R
U
R
U
Customer Street Address
R
U
R
U
Customer Zip Code
R
U
R
U
Line Item Quantity
R
U
R
U
Line Item Sequence Number
R
U
R
U
Line Item Total
R
U
R
U
Product Code
R
U
R
U
Sales Order Number
R
U
R
U
Customer Number
R
U
R
U
Employee Id
R
U
R
U
Sales Order Datetime
R
U
R
U
Sales Order Number
R
U
R
U
Sales Order Shipment Charge
R
U
R
U
Sales Order Status
R
U
R
U
Sales Order Total
R
U
R
U
Shipment Method Code
R
U
R
u
Таблица 5.11
Создание новых объектов модели данных в BPWin:
Перейдите в меню Edit / Entity/Attribute Dictionary.
В поле Entity диалога Entity and Attribute Editor внесите имя сущности “SALES FORECASTS щелкните no Add.
136
Entity and Attribute Editor
В
I* (smisSrecast peripheral" _
PROBLEM
PROBLEM ACTION
PRODUCT
PRODUCT PROBLEM
PRODUCT SOLUTION
: |$еЭЭЭ0ВЭО5@ВЯ1^^
' Г 1Рж>«ф ■
"2 ; г* I
w»m ^ШЯВШГ“"~
Ss^t Forecast uxl Dare
Safes Foi^csD Preduet Qimih
$^« F^ecas? Start 0 ate
П IPww^
II
Рис. 5.47
В поле Attribute диалогового окна Entity and Attribute Editor внесите имя атрибутов и щелкните по Add (рис. 5.47):
Product Code;
Sales Forecast End Date;
Sales Forecast Product Quantity;
Sales Forecast Start Date.
Щелкните по кнопке Close.
Экспортируйте данные в Erwin. Перейдите в меню File /Export Erwin (BPX) и укажите имя файла экспорта (в папке C:\BPCLASS).
Перейдите в Erwin. Выберите пункт меню File / BPWin Import.
В диалоговом окне Erwin Open File укажите имя файла импорта (.Ьрх, в директории C:\BPCLASS).
В диалоговом окне Erwin/BPWin Entity Sync щелкните по Execute.
В диалоговом окне Erwin/BPWin Subject Area Sync создайте дополнительную Subject Area “Оформление заказов” и щелкните по Execute (рис. 5.48).
Просмотрите статистику импорта и щелкните по кнопке ОК.
Просмотрите результат импорта (рис. 5.49). Для синхронизации внутренних идентификаторов повторите процесс импорта из
137
^Pwm 5fnc - ERwtn/8Pwm Subject Axea Sync
Рис. 5.48
SALES FORECASTSALES FORECASTSales Forecast Start DateSales Forecast Product QuantitySales Forecast End Date Product CodeSales Forecast Start DateSales Forecast Product QuantitySales Forecast End Date Product Code
SALES FORECAST
SALES FORECAST
Sales Forecast Start Date
Sales Forecast Product Quantity
Sales Forecast End Date Product Code
Sales Forecast Start Date
Sales Forecast Product Quantity
Sales Forecast End Date Product Code
CUSTOMER
Customer Number Customer First Name Customer Last Name Customer Company Name Customer Street Address Customer City.
Customer State Customer Zip Code Customer Phone Number Customer Fax Number
SALES ORDER
Sales Order Number
Sales Order Datetime
Sales Order Shipment Charge
Sales Order Total
Sales Order Shipment Datetime Sales Order Status
LINE ITEM
Line Item Sequence Number
Line Item Quantity Line Item Total
Erwin в BPWin. В результате импорта Вы должны получить следующее сообщение (рис. 5.50).
Проверить правильность выполнения задания можно с использованием файлов, полученных из Интернета:
начало — файл 09d2.bpl, окончание — файл 09d3.bpl.
PLATINUM BFWi
Рис. 5.50
5.255.25Генерация отчетов и печать диаграмм
5.25
5.25
Перейдите в меню Report / DataUsage Report.
Установите опции отчета, как показано на рис. 5.51, и щелкните по Preview для просмотра отчета.
Запустите Excel. В BPWin переключите Report Format на DDE и экспортируйте отчет в Excel.
Перейдите в меню Report / Model Consistency Report. Щелкните по кнопке Preview и просмотрите отчет о синтаксических ошибках.
Перейдите в меню File / Print, выберите диаграммы для печати и нажмите кнопку ОК.
Data Usage Report8^^|ВИИЯЗЙЙ*| Update) New | Delete [Data Usage Report8^^|ВИИЯЗЙЙ*| Update) New | Delete [Modet Прецлагаемаямоое/ь компании ~ Entity Usage Options^Modet Прецлагаемаямоое/ь компании ~ Entity Usage Options^Report FormatReport Formatг Activity Options^г Activity Options^| 1P Activi^Name^J| 1P Activi^Name^J■ • ArrowOptiemF Amasa Name F Arrow JypeNote: The order tf column selection wit determine the sorting order.F Dictionary Report■ • ArrowOptiemF Amasa Name F Arrow JypeNote: The order tf column selection wit determine the sorting order.F Dictionary ReportГ Definition .3 Р Seated "Г Definition .3 Р Seated "' 4 P fietiieved $P Updated 6 P deleted-Attribute Usage Options-' 7 P ^ЛхЛеНата. F DefinitionBP inserted BP Retrieved10 P Undated ► 1lP&u№ed' 4 P fietiieved $P Updated 6 P deleted-Attribute Usage Options-' 7 P ^ЛхЛеНата. F DefinitionBP inserted BP Retrieved10 P Undated ► 1lP&u№edfOSiHiilM^ Fged Column FXabOdtoited ' F gemma Delimited. F^DETabb F SPTwin- Multivalued Format-n f gw j * 'F Heecter P МЙ»] P RemoveSpecialCharfOSiHiilM^ Fged Column FXabOdtoited ' F gemma Delimited. F^DETabb F SPTwin- Multivalued Format-n f gw j * 'F Heecter P МЙ»] P RemoveSpecialChar
Data Usage Report
8^^|ВИИЯЗЙЙ
*| Update) New | Delete [
Data Usage Report
8^^|ВИИЯЗЙЙ
*| Update) New | Delete [
Modet Прецлагаемаямоое/ь компании ~ Entity Usage Options^
Modet Прецлагаемаямоое/ь компании ~ Entity Usage Options^
Report Format
Report Format
г Activity Options^
г Activity Options^
| 1P Activi^Name^J
| 1P Activi^Name^J
■ • ArrowOptiem
F Amasa Name F Arrow Jype
Note: The order tf column selection wit determine the sorting order.
F Dictionary Report
■ • ArrowOptiem
F Amasa Name F Arrow Jype
Note: The order tf column selection wit determine the sorting order.
F Dictionary Report
Г Definition .
3 Р Seated "
Г Definition .
3 Р Seated "
' 4 P fietiieved $P Updated 6 P deleted
-Attribute Usage Options-' 7 P ^ЛхЛеНата. F Definition
BP inserted BP Retrieved
10 P Undated ► 1lP&u№ed
' 4 P fietiieved $P Updated 6 P deleted
-Attribute Usage Options-' 7 P ^ЛхЛеНата. F Definition
BP inserted BP Retrieved
10 P Undated ► 1lP&u№ed
fOSiHiilM
^ Fged Column FXabOdtoited ' F gemma Delimited. F^DETabb F SPTwin
- Multivalued Format-n f gw j * 'F Heecter P МЙ»] P RemoveSpecialChar
fOSiHiilM
^ Fged Column FXabOdtoited ' F gemma Delimited. F^DETabb F SPTwin
- Multivalued Format-n f gw j * 'F Heecter P МЙ»] P RemoveSpecialChar
I Oose | - Prev«w... | Print.. | fieport... | Jje|p |
ПРИЛОЖЕНИЯ
П1П1Применение стандартов моделирования семейства IDEF для совершенствования Регламента Государственной Думы Российской Федерации
П1
П1
Появившись в начале 80-х годов, семейство стандартов моделирования IDEF к настоящему времени утвердилось де-факто как общепризнанная универсальная методология описания систем. Использование этой методологии для решения задачи совершенствования Регламента Государственной Думы Российской Федерации может быть предопределено, с одной стороны, простотой и наглядностью результатов моделирования, с другой стороны, возможностью достаточно полного описания и анализа поведения объектов, обеспечивающих функционирование системы и взаимосвязей между ними.
В качестве примера использования стандартов IDEF для моделирования Регламента ГД РФ была использована его глава № 3, “Депутатские объединения”. На рис. П1.1-П1.5 представлены результаты моделирования с использованием методологий IDEF0 и IDEF3.
Регламент ГД РФРегламент ГД РФМатериалыМатериалыне являющиеся членами депутатских группне являющиеся членами депутатских группДепутатскиефракцииДепутатскиефракцииДепутатскиегруппыДепутатскиегруппы
Регламент ГД РФ
Регламент ГД РФ
Материалы
Материалы
не являющиеся членами депутатских групп
не являющиеся членами депутатских групп
Депутатскиефракции
Депутатскиефракции
Депутатскиегруппы
Депутатскиегруппы
Временный секретариат ГД РФВременный секретариат ГД РФ
Временный секретариат ГД РФ
Временный секретариат ГД РФ
Комитет ГД РФ по регламенту и организации работы
Рис. П1.1. Контекстная диаграмма (IDEF0)
Рис. Ш.2. Регистрация депутатских объединений (IDEF0)
Рис. П1.3. Регистрация депутатских фракций (IDEF0)
Рис. П1.4. Регистрация депутатских групп (IDEF3)
Рис. Ш.5. Прекращение членства в депутатских группах (IDEF3)
Как видно из рис. П1.1-П1.5, к очевидным преимуществам такого рода моделирования можно отнести наглядность получаемых моделей (в методологиях IDEF0 и IDEF3 модель определяется как иерархи- 142
чески упорядоченная совокупность диаграмм, аналогичных приведенным на рисунках) и возможность типизации объектов и связей между ними, что особенно важно для юридических систем, к каковым можно отнести Регламент Государственной Думы РФ, так как именно в юридических системах количество взаимодействующих объектов относительно велико по сравнению с системами других предметных областей.
Другим важным моментом является существенное упрощение операции выявления и отображения взаимосвязей между объектами. В качестве иллюстрации верности этого утверждения приведем следующий пример. В уже упоминавшейся третьей главе Регламента п. 2 статьи 16 гласит: “Фракции и депутатские группы обладают равными правами, определенными настоящим Регламентом”. Однако раздел Регламента, озаглавленный “Права фракций и депутатских групп”, отсутствует. Таким образом, даже задача простого перечисления уже существующих прав фракций превращается в задачу подробного изучения документа, состоящего из более сотни страниц. В то же время при наличии достаточно строго типизированной IDEF-модели Регламента и использовании соответствующих программных средств ответ на этот и подобные вопросы получается практически мгновенно.
Еще одним положительным результатом применения IDEF-моделирования может стать выявление несогласованностей в исследуемой системе. В нашем случае это наличие взаимоисключающих пунктов и статей в Регламенте.
Необходимо упомянуть и о возможной научной новизне ожидаемых результатов, так как работ по IDEF-моделированию юридических систем в России до настоящего времени не публиковалось.
На основании изложенного считаем допустимым рекомендовать применение IDEF-моделирования в качестве одного из инструментов решения задачи совершенствования Регламента Государственной Думы Российской Федерации.
П2П2IDEF-моделирование в налогообложении
П2
П2
Реализацию задачи построения моделей бизнес-процессов некоторой предметной области обязательно должно предварять детальное обследование рассматриваемой области. Необходимо на словесном уровне описать проблему, которая должна быть решена методами структурного анализа L
П2.1 | Постановка задачи
В рыночных условиях налоги становятся практически основным инструментом государственного воздействия на экономику. В первую очередь они являются финансовым фундаментом государства, так как созданы прежде всего для финансирования общественно необходимых благ и услуг. Вместе с тем налоги все больше используются в качестве инструмента регулирования и стимулирования. С их помощью государство оказывает влияние на темпы роста отдельных предприятий, отраслей и территорий.
Проблема стабильности налоговых поступлений зависит прежде всего от используемого налогового инструментария, слаженности работы налоговой системы, а также от множества макроэкономических факторов. Налоги служат индикатором макроэкономических проблем, и поэтому их поступление в бюджетную систему зависит в основном от колебаний экономической конъюнктуры, финансовой политики государства, организационно-правовых проблем. В то же время среди определяющих причин неудовлетворительного поступления налоговых платежей в бюджетную систему страны необходимо выделить проблемы налогового механизма, нерациональную структуру налоговой системы, недостаточно эффективную работу по планированию налоговых платежей.
Ситуация со сбором налогов нестабильна, даже несмотря на увеличение числа принимаемых нормативных актов и проведенных административных мероприятий. Анализ структуры и динамики налоговых поступлений показывает, что налоговая система России неэластична по отношению к быстро меняющейся экономической
1 Здесь и далее в этой главе курсивом выделено руководство по построению модели в рамках практического примера применения технологии моделирования.
144
конъюнктуре. Так, например, собираемая в системе Министерства Российской Федерации по налогам и сборам налоговая информация не позволяет правильно оценить объем и структуру налоговых платежей.
По всей видимости, в этих фактах кроется не отсутствие практических навыков информационно-аналитической работы у сотрудников финансовых органов, а недостаточность собираемой информации, отсутствие модели функционирования налоговой системы, продуманной системы аналитической обработки данных.
Разработка структурной функциональной модели деятельности инспекции МНС РФ позволит построить модель деятельности, представляющей собой “снимок” технологии функционирования налоговой инспекции на момент обследования. Данная модель позволит проанализировать бизнес-процессы, происходящие на территориальном уровне с использованием методов системного анализа, и сформулировать, обобщить подходы по реинжинирингу налогового механизма.
К рассматриваемым объектам моделирования относятся процессы, осуществляемые на местном уровне налоговой службы, в целях контроля своевременности и полноты начисления и уплаты налоговых платежей юридическими и физическими лицами.
П2.2 | Основные элементы модели
После проведения детального обследования предметной области необходимо четко определить цель будущего проекта, достижение которой позволит создать инструмент для решения рассматриваемой проблемы. Перед началом реализации модели следует определить методологию функционального моделирования, точку зрения, в соответствии с которыми будет разрабатываться модель. Модель может быть построена как на бумаге, так и с помощью программного обеспечения, поддерживающего выбранную методологию моделирования, или с помощью графических редакторов.
Перед началом построения необходимо по результатам проведенного обследования предметной области определить перечень функций и список данных, которые будут использованы при реализации модели.
Название проекта: Моделирование деятельности инспекции МНС РФ.
Цель проекта: Реализация структурной функциональной модели деятельности инспекции МНС РФ.
Точка зрения: Руководство налоговой службы.
Технология моделирования: метод функционального моделирования IDEF0.
Инструментарий: программный продукт BP Win 1.8.0.
Список данных:
методология;
кадровый состав;
техническое обеспечение;
программное обеспечение;
данные о налогоплательщиках;
бухгалтерская, налоговая отчетность;
платежные документы;
входящие документы;
отчетность;
сведения по начислениям;
сведения о состоянии лицевых счетов;
выходящие документы;
налоговые предписания.
При формировании списка данных необходимо проводить группировку понятий в случае такой возможности в целях повышения читаемости диаграммы модели. Например, управлением рассматриваемой модели могут служить: законодательство, инструктивные материалы МНС РФ, должностные инструкции. Все эти понятия могут быть заменены термином “методология ”. Примечания к модели могут содержать раскрытие каждого из понятий для лучшего понимания построенной модели.
Уровень детализации и декомпозиции модели зависит от потребностей пользователя, который будет ею руководствоваться. Построение модели является итеративным процессом, т.е. первый реализованный вариант модели, скорее всего, не будет окончательным и будет дополняться в дальнейшем.
Список функций:
В модели фигурируют следующие функциональные блоки:
Деятельность инспекции МНС РФ — АО
Деятельность отдела налогообложения юридических лиц — А1
Регистрация налогоплательщиков — АП
Камеральные проверки — А12
Документальные проверки — А13
Оперативно-бухгалтерский учет — А14
Анализ состояний предприятий — А15
Формирование отчетности — А16
Работа с электронной выпиской по банку — А17
Деятельность отдела налогообложения физических лиц — А2
Регистрация налогоплательщиков — А21
Налогообложение по подоходному налогу — А22
Налогообложение по имущественным налогам — А23
Оперативно-бухгалтерский учет — А24
Ведение лицевых карточек по подоходному налогу, налогу на рекламу, налогу с продаж — А241
Ведение лицевых карточек по имущественным налогам — А242
Ведение реестра платежных документов — А243
Ведение реестра поступлений — А244
Ведение реестра заключений — А245
Ведение реестра требований — А246
Формирование отчетных форм — А247
Контроль за финансовым состоянием граждан — А25
Формирование отчетности — А26
Работа со сведениями взаимодействующих структур — А27 Деятельность отдела информатизации — АЗ
Деятельность отделов административно-хозяйственного обеспечения — А4.
П2.3 | Словарь
Создание и актуализация словаря необходимы для упрощения понимания реализованной модели пользователем, для которого она предназначается. Кроме того, указанный словарь терминов позволяет исключить возможную неоднозначность трактования модели в дальнейшем.
Бухгалтерская, налоговая отчетность — данные, предоставляемые налогоплательщиком, на основании которых будет производиться расчет налога.
Входящие документы — данные, предоставляемые от внешнего источника и связанные с деятельностью налогового органа, например, сведения из банков о движении на счетах граждан сумм свыше 10 000$, запросы налогоплательщика и т.д.
Выходящие документы — данные, предоставляемые внешним источникам в результате деятельности налогового органа, например требования об уплате налога, ответы на запросы и т.д.
Данные о налогоплательщиках — данные, предоставляемые внешними источниками, отражающие информацию о налогоплательщике, например, документы, подтверждающие право на пользование льготой, расчетные счета налогоплательщика и т.д.
Кадровый состав — сотрудники инспекции.
Методология — совокупность приемов и методов налогообложения.
Отчетность — стандартная отчетность, предназначенная для передачи в вышестоящие структуры либо для внутреннего пользования.
Платежные документы — данные о налоговых поступлениях.
Программное обеспечение — совокупность программных приложений для автоматизации деятельности сотрудников инспекции.
Сведения о состоянии лицевых счетов — данные, предназначенные для внутренней работы инспекции либо предоставляемые налогоплательщику.
Сведения по начислениям — данные — результаты расчета налога, необходимые для ведения лицевого счета налогоплательщика.
Техническое обеспечение —совокупность аппаратных средств.
П2.4 IDEFO-диаграммы модели
Диаграммы модели представлены на рис. П2.1-П2.4.
Методология
Данные о плательщикахБухгалтерская отчетностьВходящие документыПлатежные документыДанные о плательщикахБухгалтерская отчетностьВходящие документыПлатежные документыДеятельностьИМНС РФДеятельностьИМНС РФОтчетностьОтчетностьВыходящие документыВыходящие документы
Данные о плательщиках
Бухгалтерская отчетность
Входящие документы
Платежные документы
Данные о плательщиках
Бухгалтерская отчетность
Входящие документы
Платежные документы
ДеятельностьИМНС РФ
ДеятельностьИМНС РФ
Отчетность
Отчетность
Выходящие документы
Выходящие документы
Кадровый составКадровый составПрограммное обеспечениеПрограммное обеспечениеТехническое обеспечениеТехническое обеспечение
Кадровый состав
Кадровый состав
Программное обеспечение
Программное обеспечение
Техническое обеспечение
Техническое обеспечение
Рис. П2.1. Контекстная диаграмма модели деятельности ИМНС РФ
Проводить дальнейшую декомпозицию не представляется целесообразным с точки зрения руководства МНС РФ, так как рассмотренный третий уровень и его декомпозиция предполагают уже рассмотрение с г.,очки зрения методологов Управления МНС РФ по оперативно-бухгалтерскому учету.
148
КО
Методология
Рис. П2.2. Декомпозиция первого уровня
Lh ОLh ОРис. П2.3. Одна из декомпозиций второго уровняРис. П2.3. Одна из декомпозиций второго уровня
Lh О
Lh О
Рис. П2.3. Одна из декомпозиций второго уровня
Рис. П2.3. Одна из декомпозиций второго уровня
Рис. П2.4. Одна из декомпозиций третьего уровня
П2.5 | Описание функциональных блоков
Целесообразным является краткое описание задач, которые решаются на уровне каждого из функциональных блоков, и принципы его декомпозиции.
Очевидно, что диаграммы первого и второго уровня могут быть объединены. Однако для лучшей читаемости модели следует отдельно рассматривать деятельность отдела юридических и физических лиц путем рассмотрения их на следующем уровне.
А1. Деятельность отдела налогообложения юридических лиц.
На данном этапе рассматривается методология деятельности отдела налогообложения юридических лиц в целом. Декомпозиция проведена в соответствии с организационно-штатной структурой отдела.
А2. Деятельность отдела налогообложения физических лиц.
На данном этапе рассматривается методология деятельности отдела налогообложения физических лиц в целом. Декомпозиция проведена также в соответствии с организационно-штатной структурой отдела.
А24. Оперативно-бухгалтерский учет.
В отделе учета и отчетности ведется учет произведенных налогоплательщикам начислений, поступивших от них платежей, расчет сумм пени за несвоевременную уплату налогов (ведение лицевых карточек налогоплательщиков) и т.д.
Декомпозиция производится в соответствии с функциями, возложенными на отдел оперативно-бухгалтерского учета.
А243. Ведение реестра платежных документов.
Данные собираются и вводятся в информационную систему на основании выписки по банку, после чего данные поступлений, возвратов разносятся в лицевые карточки.
Разработанная модель содержит еще ряд достоинств, позволяющих повысить эффективность работы налоговой службы:
анализ технологии работы на основе этой модели позволяет выявить узкие места и увеличить производительность труда сотрудников налоговых инспекций;
возможность быстрого и качественно иного обучения новых сотрудников инспекции МНС РФ.
пзпзМоделирование управленческого учета на предприятии
пз
пз
П3.1 Постановка задачи
В условиях конкуренции руководству предприятия требуется оперативная информация для принятия решений. Финансовая отчетность предоставляет лишь часть необходимой информации в виде ограниченного круга обобщенных стоимостных показателей. Бухгалтерский учет в первую очередь предназначен для предоставления информации для внешних пользователей. Этим обусловлено наличие нормативных требований к его ведению (документирование, стандартные методы и формы отчетности), которые делают данные бухгалтерского учета не пригодными для принятия решений. Функцию обеспечения руководства предприятия необходимой информацией выполняет управленческий учет, который не регламентируется законодательно, а определяется прежде всего целями предприятия.
Институт дипломированных бухгалтеров в области управления (Charted Institute of Management Accountants) определяет управленческий учет как деятельность по обеспечению руководства информацией, которая необходима ему для управления предприятием с максимально возможной степенью эффективности. Информация, которую обеспечивает управленческий учет, может быть представлена в любой форме по выбору руководства.
Большинство работ по управленческому учету российских авторов и переводных работ иностранных авторов описывают отдельные элементы управленческого учета: методики учета и распределения затрат, учет по центрам ответственности, систему управленческой отчетности и другие, но не дают целостного представления о бизнес- процессе, что затрудняет их использование для организации управленческого учета на предприятии. Восполнить этот пробел можно с помощью разработки модели данного процесса.
П3.2 Основные элементы модели
Название проекта: Организация управленческого учета на предприятии.
Цель проекта: подготовить рабочую модель бизнес-процесса управленческого учета для внедрения на предприятии.
Точка зрения: руководство предприятия.
Инструментарий: методология функционального моделирования IDEF0 и программное приложение BPWin 1.8.0.
Список данных:
потребность в управленческой информации;
стратегия предприятия;
управленческая информация;
информационная система;
финансовая функция;
центры ответственности;
руководство предприятия;
данные;
методология управленческого учета;
финансовая отчетность;
обработанные данные;
стратегия управленческого учета;
имеющиеся ресурсы;
квалификация персонала;
первичные документы;
данные в информационной системе;
подтвержденные данные;
отчетность в разрезе центров ответственности;
сводная отчетность;
отчетность по требованию.
ПЗ.З | Список функций
В модели использованы следующие функции:
Организовать управленческий учет — АО
Разработать методологию управленческого учета — А1
Определить стратегию управленческого учета — АП
Оценить имеющиеся ресурсы — А12
Разработать приемы и методы управленческого учета — А13
Собрать и обработать данные — А2
Получить и ввести данные — А21
Подтвердить данные —А22
Обработать данные —А23
Подготовить управленческую отчетность — АЗ
Подготовить отчетность по центрам ответственности — АЗ 1
Сделать сводную отчетность — А32
Подготовить отчетность по требованию — АЗЗ
П3.4П3.4СловарьСловарь
П3.4
П3.4
Словарь
Словарь
Данные — факты, характеризующие деятельность предприятия, подлежащие количественному выражению.
Данные в информационной системе —данные, введенные в информационную систему и разнесенные по аналитическим признакам.
Имеющиеся ресурсы — персонал и информационная система в распоряжении предприятия.
Информационная система — совокупность программных приложений, баз данных, используемых для управления предприятием.
Квалификация персонала — совокупность знаний, умений и навыков персонала в конкретной профессиональной области.
Методология управленческого учета — совокупность приемов и методов ведения управленческого учета.
Обработанные данные — данные, разнесенные по объектам учета и центрам ответственности.
Отчетность в разрезе центров ответственности — стандартная управленческая отчетность, составленная для каждого центра ответственности. Эта отчетность используется руководителями центров ответственности для принятия решений в рамках их должностных полномочий.
Отчетность по требованию — управленческая отчетность нестандартной формы, используемая для пояснения стандартной отчетности.
Первичные документы — документы, подтверждающие факты совершения хозяйственных операций, оформленные в соответствии с действующим законодательством и нормативными актами.
Подтвержденные данные — данные, соответствующие первичным документам. Данные в информационной системе, обозначенные как соответствующие первичным документам.
Потребность в управленческой информации — обоснованная необходимость получения управленческой информации.
Руководство предприятия — должностные лица, несущие конечную ответственность за принимаемые ими управленческие решения в пределах своей компетенции.
Сводная отчетность — стандартная управленческая отчетность, характеризующая деятельность предприятия в целом. Деятельность центров ответственности представлена обобщающими показателями.
Стратегия предприятия — совокупность целевых ориентиров, определяющих деятельность предприятия в долгосрочном периоде.
Стратегия управленческого учета — формализованные потребности руководства предприятия в управленческой информации.
Управленческая информация — информация, необходимая для принятия управленческих решений.
Управленческая отчетность — управленческая информация, представленная в удобной для прочтения форме. Может быть стандартной, подготавливаемой регулярно в установленной форме, и нестандартной, подготавливаемой по требованию.
Управленческий учет — деятельность по обеспечению руководства предприятия информацией, необходимой для принятия управленческих решений.
Финансовая отчетность — агрегированная отчетность, подготавливаемая на регулярной основе для внешних пользователей информации. Требования к составу, порядку составления и срокам предоставления финансовой отчетности устанавливаются законодательством или стандартами бухгалтерского учета.
Финансовая функция — бухгалтерия и финансовые подразделения предприятия.
Центры ответственности — структурные сегменты предприятия, руководители которых несут ответственность за конкретные показатели деятельности (например, руководитель центра затрат отвечает за затраты своего сегмента, руководитель центра прибыли — за затраты и выручку и т.д.)
П3.5 IDEFO-диаграммы модели
IDEF-диаграммы модели представлены на рис. П3.1-ПЗ.З.
П3.6 | Описание функциональных блоков
AL Определить цели управленческого учета
На этом этапе разрабатывается методология управленческого учета, которая является контролем для следующих этапов. От его организации во многом зависит успешность процесса управленческого учета в целом.
Al 1. На первом этапе декомпозиции руководством определяется стратегия управленческого учета на основе потребностей в управленческой информации. Его задача формализовать потребности и увязать их со стратегией предприятия.
156
Потребности в управленческой информацииПотребности в управленческой информацииУправленческая информация ,Управленческая информация ,Стратегия предприятия
Потребности в управленческой информации
Потребности в управленческой информации
Управленческая информация ,
Управленческая информация ,
Организоватьуправленческий учет
Руководство предприятияРуководство предприятияЦентры ответственностиЦентры ответственностиФинансовая функцияФинансовая функцияИнформационная системаИнформационная система
Руководство предприятия
Руководство предприятия
Центры ответственности
Центры ответственности
Финансовая функция
Финансовая функция
Информационная система
Информационная система
Рис. П3.1. Контекстная диаграмма модели управленческого учетаРис. П3.1. Контекстная диаграмма модели управленческого учета
Рис. П3.1. Контекстная диаграмма модели управленческого учета
Рис. П3.1. Контекстная диаграмма модели управленческого учета
Рис. П3.2. Декомпозиция первого уровня
Рис. ПЗ.З. Одна из декомпозиций второго уровня
А12. На следующем этапе определяются ресурсы для реализации стратегии управленческого учета, оценивается эффективность стратегии с точки зрения затрат имеющихся ресурсов и необходимость привлечения дополнительных ресурсов.
А13. На третьем этапе стратегия трансформируется в конкретные приемы и методы ведения управленческого учета с учетом ресурсов, имеющихся в распоряжении предприятия.
А2. Собрать и обработать данные
На этом этапе готовятся данные, составляющие основу управленческой информации.
А21. Данные собираются и вводятся в информационную систему непосредственно центрами ответственности, что обеспечивает оперативность поступления информации. Состав данных, аналитические признаки и сроки их учета определяются методологией.
А22. По мере поступления первичных документов бухгалтерия подтверждает данные в информационной системе. В случае расхождений данные корректируются на основе первичных документов. Подтвержденные данные используются для составления финансовой отчетности.
А23. Данные в информационной системе разносятся по объектам учета и центрам ответственности. При наличии достаточной аналитики это осуществляется автоматически.
АЗ. Подготовить управленческую отчетность
На этом этапе формируется управленческая отчетность. При хорошо разработанной методологии отчетность может формироваться автоматически. Роль финансовой функции как механизма зависит от возможностей информационной системы.
АЗ 1. Разнесение данных по объектам учета и центрам ответственности позволяет сформировать отчетность в разрезе центров ответственности. Форма отчетов и сроки их предоставления определяются методологией.
А32. Сводная отчетность формируется на основе консолидации отчетности центров ответственности и других обработанных данных. В части подтвержденных данных контролем выступает финансовая отчетность.
АЗЗ. Отчетность по требованию также основана на обработанных данных. Поскольку ее формы не предусмотрены методологией, они предварительно разрабатываются финансовой функцией.
П4П4Моделирование процесса создания и организации реинвестиционной деятельности холдинговой компании в Республике Австрия
П4
П4
П4.1 | Постановка задачи
В течение последних лет налоговыми и финансовыми органами РФ был предпринят ряд мер, накладывающих существенные ограничения на инвестиционную деятельность российских компаний. В этой связи особо следует упомянуть Положение ЦБ РФ “О порядке выдачи Банком России разрешений на проведение отдельных видов валютных операций, связанных с движением капитала”, которое в обязательном порядке предусматривает получение разрешений на осуществление любых инвестиционных операций, связанных с осуществлением взноса в уставный капитал любой зарубежной компании, превышающего сумму в 1 млн долл. США (взносы в уставный капитал финансовых и оффшорных компаний попадают под действие Положения даже в тех случаях, когда их объем меньше 1 млн долл., т.е. в любом случае). Это разрешение выдает Центральный банк Российской Федерации, требующий в свою очередь представления специального разрешения Минэкономики, которое должно вынести суждение о том, не противоречит ли инвестиционная сделка интересам российской экономики.
Подобные ограничения особенно неудобны для российских компаний, активно работающих на зарубежных рынках посредством организованных за границей дочерних компаний, а также для молодых перспективных компаний, планирующих выход на западный рынок. Эти компании часто сталкиваются с необходимостью осуществления инвестиционных операций за рубежом (к примеру, требуется увеличить уставный капитал дочерней компании). Несмотря на то, что подобные операции необходимы для поддержания нормальной жизнедеятельности компании, их осуществление напрямую российской
компанией зачастую является невозможным без нарушения отечественного законодательства.
Возможным выходом из сложившейся ситуации является создание базисной холдинговой компании в одной из развитых западноевропейских стран, имеющих репутацию “холдинговых центров”, например в Австрии. Австрия упомянута в данном контексте не случайно, поскольку законодательство этой страны, а также Конвенция об избежании двойного налогообложения между Россией и Австрией предоставляют для базисных холдинговых компаний, принадлежащих российским резидентам, уникальные возможности (например, дивиденды, получаемые холдингом от дочерних компаний, при определенных условиях освобождаются в Австрии от налогообложения).
Создание подобного холдинга и организация его деятельности являются для российской компании, как правило, непростой задачей. К сожалению, приходится констатировать, что в нашей стране на данный момент ощущается дефицит сотрудников, досконально знакомых с западноевропейским налоговым правом и западными деловыми обычаями. Недостаток подобного рода кадров даже в некоторых крупных российских компаниях нередко приводил к плачевным результатам. По этой причине задача создания базисной холдинговой компании в последнее время все чаще перенимается специализированными компаниями — резидентами Австрии. Специализированная компания сначала создает холдинг в Австрии, затем продает его российскому заказчику и впоследствии осуществляет от лица последнего доверительное управление холдингом (представители специализированной компании избираются в совет директоров холдинга). Доверительное управление длится до тех пор, пока не будет налажена бесперебойная деятельность базисной холдинговой компании. Речь идет в первую очередь о выполнении трех основополагающих задач:
осуществить внесение в холдинг пакетов акций дочерних компаний российского заказчика (создание первичной структуры холдинга);
осуществить покупку дополнительных пакетов акций дочерних компаний и (или) произвести повышение их уставного капитала;
наладить механизмы перевода средств дочерних компаний и их консолидации на счетах холдинга.
После этого базисная холдинговая компания оказывается в состоянии без серьезных осложнений осуществлять свою инвестицион-
161
ную и реинвестиционную деятельность. В этот момент задачу специализированной компании можно считать выполненной.
Поскольку в данном случае речь идет о сверхсложном и достаточно продолжительном процессе, представляется целесообразным решать возникающие при его осуществлении проблемы при помощи создания модели IDEF0.
П4.2П4.2Решение поставленной задачипри помощи технологии IDEF0
П4.2
П4.2
Точка зрения. Возможные точки зрения:
менеджмент российской компании-заказчика;
менеджмент специализированной компании — резидента Авст
рии.
Представляется целесообразным в качестве точки зрения принять позицию специализированной австрийской компании, поскольку именно она отвечает за успешное выполнение поставленных задач и осуществляет непосредственный контроль над рассматриваемым процессом.
П4.3П4.3Некоторые особенности рассматриваемой проблемы
П4.3
П4.3
Основная задача, стоящая перед менеджером, как это следует исходя из специфики рассматриваемой проблемы, заключается в реинвестировании денежных средств клиента через созданную холдинговую компанию в Австрии. Он получает от клиента:
информацию (о самой компании-клиенте и ее дочерних ком
паниях);
денежные средства и пакеты акций дочерних компаний, которые будут вноситься в холдинг.
Информация и средства, получаемые от клиента, вместе со средствами, самостоятельно инвестируемыми специализированной компанией, представляют собой вход. Единственным желательным с точки зрения выполнения поставленной задачи выходом являются средства, реинвестируемые холдинговой компанией. Это обстоятельство особенно важно принимать во внимание, если учесть, что при реализации рассматриваемого процесса будет возможен лишь один выход, поскольку неудача на одном из функциональных этапов выполнения 162
поставленной задачи, имеющая результатом выходящие данные типа “отказ в ...”, автоматически предполагает невозможность достижения менеджментом специализированной компании целей, стоящих в рамках выполнения поставленной задачи. Напротив, получение на выходе желаемых данных возможно лишь при достижении положительных результатов в рамках “критических” функциональных блоков. Это означает, что в рамках рассматриваемого процесса каждый отдельный вариант выхода исключает все остальные варианты. Соответственно реализация процесса может иметь либо сугубо положительный, либо сугубо отрицательный результат. По этой причине возможности для реинжиниринга процесса в данном случае являются достаточно ограниченными. Следовательно, для менеджмента специализированной компании целесообразно сконцентрироваться в первую очередь на выявлении источников экзистен- циональных рисков.
Цели. Исходя из вышесказанного можно выявить основные цели, стоящие при моделировании рассматриваемого процесса.
Помимо множества “микроцелей”, можно выделить также несколько основных целей, преследуемых ее составителем:
Определить последовательность шагов.
Определить четкую последовательность действий, осуществление которых необходимо для достижения поставленных задач с целью точного определения величины и характера возможных временных и финансовых затрат.
Выявить “критические функциональные блоки”.
Из общего числа функциональных блоков большинство интересуют нас лишь с точки зрения возможных, связанных с ними затрат. Особый же интерес представляют так называемые “критические функциональные блоки”. Последние, в отличие от большинства остальных функциональных блоков, характеризуются тем, что неудача при выполнении поставленных в их рамках задач может быстро привести к срыву всего проекта. В рамках рассматриваемой модели критическими являются те функциональные блоки, выходным результатом которых могут быть отказ в регистрации, открытии счета или отказ в предоставлении налоговых льгот.
Выявить количество правовых экспертиз, проведение которых необходимо в рамках осуществления проекта.
Это достаточно важный аспект, поскольку, с одной стороны, каждая экспертиза стоит немалых денег, а с другой — отказ от своевре-
163
менного проведения экспертизы может привести к негативным результатам в ближайшем критическом функциональном блоке.
Анализ отдельных функций. Поставленная задача будет решаться путем построения функциональной модели процесса, представляющей собой иерархию функций, связанных материалами и информационными потоками согласно правилам построения IDEFO-модели.
Рассматриваемый процесс можно разбить на два основных функциональных блока:
Создать базисную холдинговую компанию в Австрии и организовать ее структуру.
Организовать реинвестиционную деятельность холдинга.
Каждый блок содержит в себе определенное число (системных) функций, большинство которых, в свою очередь, имеют сложную структуру.
Далее предлагается анализ отдельных системных функций с учетом стоящих в рамках решения поставленной проблемы задач.
Разработать концепцию создания и развития холдинга.
Выполнение данной функции лишь маргинально различается в рамках выполнения различных задач, поэтому в нашем случае она не рассматривается подробнее.
Создать и зарегистрировать холдинговую компанию в Австрии.
В рамках рассматриваемой системной функции присутствуют целых 2 системных блока, являющихся источниками экзистенциональ- ных рисков — “зарегистрировать компанию” и “открыть банковский счет”. При этом риск отказа в регистрации компании следует оценивать как значительно более высокий. По этой причине подача регистрационных документов должна предваряться экспертизой некоторых из них в торговой палате.
Осуществить продажу холдинговой компании российскому заказчику.
В рамках данной системной функции присутствует лишь один “критический” блок — “зарегистрировать нового владельца компании”. Тем не менее риск негативного выхода в данном случае является достаточно низким, расходы на проведение дополнительной экспертизы представляются в данном случае неоправданными.
Внести пакеты акций дочерних компаний в холдинг.
“Критические” блоки отсутствуют. Тем не менее на данном этапе необходимо проведение правовой экспертизы с учетом трудностей, которые могут возникнуть в ходе процесса организации реинвестици- 164
онной деятельности компании (основной риск, величину которого следует оценить, — риск отказа в предоставлении налоговых льгот). Стратегические решения должны приниматься именно на этом этапе, поскольку выход из процесса в позднейшие промежутки времени будет связан с дополнительными необоснованными затратами.
Приобрести дополнительный пакет акций одной из дочерних компаний.
“Критический” блок — “зарегистрировать увеличение уставного капитала компании”. Риск негативного выхода невысок.
Организовать финансовые потоки австрийской компании.
“Критический” блок — всего один (“подать заявку на предоставление налоговых льгот”), зато связанный, пожалуй, с наиболее существенным экзистенциональным риском. Неудача на данном этапе приводит не только к негативному результату в рамках выполнения поставленной задачи, но и к максимально высоким финансовым потерям. Правовая экспертиза проводится ранее.
Варианты реинжиниринга. В том случае, если разработанная модель на практике доказывает свою неэффективность, возникает потребность в ее “перестройке” (реинжиниринге). Причины неэффективности модели могут быть внешними и внутренними. К внутренним причинам относятся преимущественно ошибки, допущенные при составлении модели, к внешним — изменения параметров внешней среды, которые не были (и, возможно, не могли быть) учтены при составлении модели.
В качестве примера рассмотрим следующую ситуацию (в рамках вышеописанной модели; причем в ходе дальнейших анализов будем исходить из того, что ошибок при построении модели допущено не было, и, следовательно, все “помехи” будут иметь исключительно внешний характер): допустим, акционер холдинговой компании (компания-заказчик) отказывается предоставить ряд документов, необходимых для получения холдингом налоговых льгот (см. декомпозицию 3-го уровня “консолидировать финансовые потоки холдинговой компании”). Отказ происходит уже после того, как первая поставленная задача — увеличение уставного капитала дочерней оффшорной компании уже является выполненной. Выполнение же основной задачи — реинвестирования денежных средств клиейта через созданную холдинговую компанию в Австрии, в рамках разработанной модели является в сложившейся ситуации невозможным. То, что соответствующий риск не был учтен при построении исходной модели, нельзя
считать ошибкой ее составителей — согласие клиента (российской компании) с условиями сделки (в число которых входило и предоставление соответствующей документации) явилось одной из базовых предпосылок, исходя из которых конструировалась модель. В принципе специализированная компания в сложившейся ситуации имела бы право расторгнуть контракт с компанией-заказчиком, но мы будем исходить из того, что речь идет о “стратегическом” клиенте, которого специализированная компания ни в коем случае не захочет утратить и по этой причине предпочтет “перестройку” модели расторжению контракта. Далее приводятся два возможных варианта реинжиниринга процесса (общая задача предполагается неизменной).
Перевод средств в виде “доверительного кредита”.
Поскольку компания-заказчик отказывается предоставлять в Министерство финансов Австрии необходимые документы, министерство отказывает холдинговой компании в предоставлении налоговых льгот. Следовательно, средства, перечисленные дочерней компанией в виде дивидендов, будут облагаться налогом (по ставке, близкой к стандартной). Следовательно, возникает необходимость поиска иных каналов перевода денежных средств. Возможным вариантом решения проблемы была бы организация дочерней компанией выдачи холдингу так называемого “доверительного” кредита.
Схема будет выглядеть следующим образом: банк, связанный тесными и доверительными отношениями либо с компанией-заказчиком, либо со специализированной компанией, выдает холдингу кредит под залог денежных средств, перечисляемых дочерней компанией на свой счет в банке. После того как холдинг не выплачивает кредит обратно, банк просто забирает средства со счета дочерней компании, т.е. фактически речь идет о перечислении денег (дивидендов) дочерней компанией холдингу, которое со стороны, тем не менее, выглядит как кредит, выданный холдингу банком. Перечисленные средства, разумеется, налогами облагаться не будут. Произошедшие изменения затрагивают исключительно функцию “консолидировать средства на счетах холдинговой компании” (декомпозиция А22).
Поглощение дочерней компании холдингом.
В том случае, если холдинг владеет более чем 90% акций дочерней компании, возможен вариант ее поглощения холдингом. В дальнейшем бывшая дочерняя компания будет считаться постоянным представительством холдинговой компании в Лихтенштейне и пользоваться существенными налоговыми льготами (между Лихтенштейном и Австрией существует конвенция об избежании двойного налогооб- 166
ложения). В результате возникнет лишь необходимость интегрировать в модель новую функцию “осуществить поглощение дочерней компании холдингом” (что не будет связано с существенными сложностями), а функция “консолидировать финансовые потоки холдинговой компании настолько упростится, что потребность в ее декомпозиции исчезнет (поглощение может производиться сразу при внесении пакета акций дочерней компании в холдинговую или на дальнейших этапах); по этой причине может быть составлено несколько альтернативных вариантов соответствующей модели.
Основные понятия, использованные в модели
Законодательство Республики Австрия:
положение “О государственных налогах и сборах” (ВАО);
Закон “О налоге на прибыль предприятий и организаций” (kestg);
Закон “О налоге на доходы физических лиц” (estg);
Закон “О реорганизации предприятий” (umgrstg);
Торговый кодекс Республики Австрия (HGB);
Закон “Об инвестиционных фондах” (invfg);
Закон “Об обществах с ограниченной ответственностью” (gmbhg);
Закон “Об акционерных обществах” (aktg);
Закон “О рынке ценных бумаг” (KMG);
Закон “О торговом регистре” (FBG).
Законодательство Княжества Лихтенштейн:
Кодекс торгового и гражданского права (PGR);
Закон “О государственном надзоре за деятельностью предприятий и организаций с особым налоговым статусом”;
Закон “Об акционерных обществах” (aktg);
Закон “О банках и банковской деятельности” (BWG).
Информация о компании-заказчике:
учредительные документы;
баланс.
Помимо указанной информации, желательна информация о физических лицах, с юридической точки зрения прямо или косвенно являющихся собственниками компании-заказчика (они должны быть нерезидентами Австрии).
Информация о существующих заграничных дочерних компаниях заказчика включает в себя следующие сведения о дочерних компаниях:
о количестве;
о правовом статусе;
о характере осуществляемой деятельности;
о продолжительности существования;
о финансовом положении.
Специализированная (консалтинговая) компания — компания, специализирующаяся на организации базисных холдинговых компаний в Австрии.
Компания-заказчик — российская компания, для которой специализированная компания создает базисную холдинговую компанию в Австрии и от лица которой осуществляет управление последней.
Заграничная дочерняя компания компании-заказчика — заграничная компания, в которой компания-заказчик владеет участием или пакетом акций более 25%.
Учредительный договор (базисной холдинговой компании) — один из основных учредительных документов — подписывается физическими и/или юридическими лицами с целью создания ООО, содержит в себе положения, регулирующие дальнейшую деятельность компании.
Экспертиза торговой палаты — законодательно предписанная проверка торговой палатой отдельных положений учредительного договора на предмет их соответствия национальному законодательству.
Правовая экспертиза (специализированной компании) — правовая экспертиза проводимых холдингом операций, осуществляемая экспертами специализированной компании.
Справка банка, подтверждающая зачисление средству — письменное уведомление банка, подтверждающее поступление средств на указанный счет.
Протокол учредительного собрания (акционерного собрания) — документ, в котором в письменном виде фиксируются решения, принимаемые учредительным (акционерным) собранием.
В ходе решения поставленной задачи планируется дважды проведение учредительного собрания базисной холдинговой компании, которая должна существовать в форме GmbH (общество с ограниченной ответственностью), и проведение акционерного собрания дочерней компании в Лихтенштейне. Учредительные собрания холдинга должны принять решения соответственно об утверждении совета директоров и покупке дополнительного пакета акций дочерней компании в Лихтенштейне. Акционерное собрание дочерней компании должно принять решение о выплате дивидендов материнской компании. Все решения должны быть зафиксированы в соответствующем протоколе. 168
Концепция консолидации финансовых активов — зафиксированная в письменном виде концепция, призванная определить более подробную структуру финансовых потоков холдинга. Принимается после решения ряда важных организационно-правовых вопросов (т.е. уже после того, как завершается формирование первичной организационной структуры компании).
Реинвестируемые средства (холдинга) — финансовые средства холдинга, за счет которых осуществляется приобретение активов (материальных и нематериальных), поступающих в фактическое распоряжение компании-заказчика (как владельца базисной холдинговой компании).
IDEFO-диаграммы модели представлены на рис. П4.1-П4.9.
Информация о дочерней компании заказчика
Инст
Законо
Законода
рукции
датель
тельство
заказ
ство Рес
Княжества
чика
публики
Лихтен
Австрия
штейн
Отказ в регистрации компанииОтказ
Iв открытии
Lсчета
Отказ в регистрации сделки купли-продажи компании
заказчика
Создать холдинговуюкомпанию в Австриии организовать еереинвестиционнуюдеятельность
О
Реинвестируемые средства
Министерство финансов Республики Австрия
Банки
Торговая палата
Менеджмент компании и заказчика
Акционеры дочерней компании
Министерство финансов Княжества Лихтенштейн
Свидетельство о регистрации компании
Отказ в предоставлении налоговых льгот
Отказ в регистрации уставного капитала компании
Рис. П4.1. Контекстная диаграмма создания холдинга
Информация о заказчике
Пакет акций дочерней компании
Платежные средства заказчика
Создать холдинговую компанию в Австрии
Платежные средства консалтинговой компании
Информация о дочерней компании заказчика
Инструкции заказчика
Свидетельство о регистрации внесения пакета акций дочерней компании
Законодательство
Республики Австрия
1
Отказ в открытии счета
Учредительный договор
Свидетельство о регистрации сделки купли- продажи компании
Законодательство
Княжества Лихтенштейн
Отказ в регистрации сделки купли-продажи компании
Свидетельство о регистрации компании
Отказ в регистрации компании
Организоватьреинвестиционнуюдеятельность компании
2
Отказ в регистрации увеличения уставного капитала компании
Министерство финансов Республики Австрия
Банк
Торговая палата
Менеджмент компании и заказчика
Акционеры дочерней компании
Министерство финансов Княжества Лихтенштейн
Отказ в предоставлении налоговых льгот
Реинвестируемые средства
Рис. П4.2. Первый уровень декомпозиции
Рис. П4.3. Создать холдинговую компанию в Австрии
Рис. П4.4. Создание компании
Рис. П4.5. Продажа компании заказчику
Рис. П4.6. Внесение пакета акций дочерней компании
Учредительный договор
Законодательство Республики Австрия
Инструкции заказчика
Законодательство Княжества Лихтенштейн
Отказ в регистрации увеличения уставного капитала компанииОтказ в регистрации увеличения уставного капитала компанииОтказ в предоставлении налоговых льготОтказ в предоставлении налоговых льгот
Отказ в регистрации увеличения уставного капитала компании
Отказ в регистрации увеличения уставного капитала компании
Отказ в предоставлении налоговых льгот
Отказ в предоставлении налоговых льгот
Платежные средства заказчика
Свидетельство о регистрации сделки купли- продаяпгкбмпзтт
Свидетельство о регистрации внесения пакета акций дочерней компании
Информация о заказчике
J£Z
Приобрестидополнительныйпакет акцийдочерней компании
Консолидироватьсредствана счетах компании
2
Министерство финансов Княжества Лихтенштейн
Акционеры дочерней компании
Банк
Министерство финансов Республики Австрия
Реинвестируемые средства
Менеджмент компании- заказчика
Рис. П4.7. Организация реинвестиционной деятельности компании
Свидетельство о регистрации сделки купли- продажи компании
Законодательство
Республики Австрия
У Провести
учредительное
у'Пр^/ЦИ I та юп
\ собрание
Учредительный договор
Решение об увеличении уставного капитала
zУвеличить
* уставный , капитал компании 2
Инструкции заказчика
Законодательство Княжества Лихтенштейн
Свидетельство о регистрации внесения пакета акций дочерней компании
Платежные средства заказчика
'зарегистрироватьувеличениеуставного капи-тала компании3
Менеджмент компании- заказчика
Документы, подтверждающие перечисление средств
Регистрационное свидетельство
Банк
Министерство финансов Республики Австрия
Документы, подтверждающие перечисление средств
Заключить договор купли-продажи дополнительного пакета акций дочерней компании
Договор купли- продажи
Акционеры дочерней компании
Провестирасчетыс продавцом
Рис. П4.8. Получение дополнительного пакета акций дочерней компании
Отказ в регистрации увеличения уставного капитала компании
Свидетельство о регистрации сделки по приобретению дополнительного пакета акций дочерней компании
Зарегистриро-вать сделку6
'Министерство финансов Княжества Лихтенштейн
Рис. П4.9. Консолидирование средств на счетах компании
ГЛОССАРИЙ
IDEFO — стандарт моделирования, поддерживающий графическое описание бизнес-функций как набора взаимозависимых действий и информации о ресурсах, необходимых для каждого действия. Назначение модели IDEF0 состоит в документировании и пересмотре назначения и состава функций для повышения эффективности функционирования организации.
IDEF3 — стандарт моделирования бизнес-процессов, поддерживающий графическое описание непосредственного механизма функционирования системы или организации. IDEF3 содержит правила разработки двух видов сетевых диаграмм:
потоков для бизнес-процессов*,
изменения состояния объекта.
DFD — технология моделирования, показывающая, как объекты (включая и данные) реально перемещаются от одного действия к другому.
Бизнес-процесс (Business-process) — термин, используемый для описания того, как в процессе функционирования организации выполняются те или иные действия. IDEF3 обеспечивает поддержку моделирования бизнес-процессов посредством применения нотации, ориентированной на идее задания последовательности выполнения действий и определении времени их выполнения.
Бизнес-функция (Business-function) — термин, используемый для описания того, что в процессе функционирования организации выполняют те или иные действия. IDEF0 обеспечивает поддержку моделирования бизнес-функций посредством нотации, использующей действия и стрелки.
Вход (Input arrow) — стрелка, входящая в левую часть блока диаграммы IDEF0. Вход обозначает сырье или информацию, потребляемые действием, обозначенной данным блоком, и которые необходимы для получения выхода.
Выход (Output arrow) — стрелка, выходящая из правой стороны блока диаграммы IDEF0. Выход обозначает изделия или информацию, полученные в результате выполнения действия, обозначенного блоком.
Границы моделирования (Scope) — ширина охвата и глубина детализации при описании моделируемого набора объектов.
Действие (Activity) — описание набора мероприятий, имеющего целью обработку или передачу данных или ресурсов (например, “Обработать заказ” или “Провести технический контроль”). Модели IDEF0 выделяют неэффективные действия (у которых отсутствует управление или выход) и, таким образом, способствуют работе по проведению реинжиниринга бизнес-процессов. Действие в модели IDEF3, называемое также единицей работы, описывает обработку, мероприятие, принятие решения или другую процедуру, выполняемую системой или организацией. Действия в диаграммах DFD отображают обработку или передачу данных.
Механизм исполнения (Mechanism arrow) — стрелка, входящая в блок диаграммы IDEF0 снизу и обозначающая персонал, оборудование и другие, не потребляемые в процессе функционирования ресурсы, используемые для выполнения действия, обозначаемого блоком.
Стрелка (Arrow) — стрелка на диаграмме IDEF0 представляет вход, управление, выход или механизм выполнения действия. На диаграммах IDEF3 стрелки обозначают порядок выполнения действий (стрелки, нарисованные сплошной линией), отношения (стрелки, нарисованные прерывистой линией) или поток (двухконечные стрелки, нарисованные сплошной линией). В DFD стрелка обозначает поток данных между действиями, хранилищами данных и внешними ссылками.
Управление (Control arrow) — ограничение для блока диаграммы IDEF0, определяющее как, когда и при каких условиях выполняется действие, обозначенное этим блоком. Это правила, стандарты, законы, должностные инструкции и т.п. Стрелки, обозначающие управление, входят в блоки диаграммы IDEF0 сверху.
РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
Вендров А.М. CASE-технологии — современные методы и средства проектирования информационных систем. - М: Финансы и статистика, 1998.
Книга представляет собой введение в проектирование информационных систем с помощью современных методов и средств. Содержит сведения по методологиям проектирования, структурному и объектно-ориентированному подходам, характеристикам CASE-средств.
Дружинин А.И., Малышева Л.А. Использование CASE-технологий (ИПК УГТУ, Екатеринбург) ИТО-99: Тезисы докладов. - М., 1999.
Представлена концептуальная основа преподавания курса по использованию CASE-технологий для проектирования и разработки информационных систем в системе повышения квалификации Уральского государственного технического университета
Ефимов В. Опыт использования функционального моделирования при разработке банковских систем. - DiasoftNFO И Банковские технологии. - 1998. - Сентябрь. - С. 64-68.
В статье излагается опыт, накопленный компанией “Диасофт” в области структурного системного анализа банковской сферы. Показано, что методологии функционального моделирования, лежащие в основе системного структурного анализа, позволяют добиться значительного повышения конкурентоспособности программного обеспечения, снижают производственные издержки и время разработки.
Калянов Г.Н. CASE. Структурный системный анализ. - М.: Лори, 1996.
Изложены методологические основы области CASE-технологий. Содержит описание основных методов структурного анализа и проектирования программного обеспечения систем обработки информации. Акцент на последовательное рассмотрение наиболее важных аспектов системного структурного анализа делает эту книгу особенно
181
полезной для аналитиков предметных областей, руководителей программных проектов, системных аналитиков, проектировщиков и разработчиков информационных систем и систем реального времени.
Калянов Г.Н. Консалтинг при автоматизации предприятий. - М.: Синтег, 1997.
Обобщение опыта разработки консалтинговых проектов, выполненных для банков, промышленных и торговых предприятий, офисных учреждений и т.д. Подробно рассматривается методологическая и инструментальная база выполнения консалтинговых проектов (CASE-технологии), анализируются подходы к реорганизации деятельности предприятий; предлагается методология выполнения консалтинговых проектов, апробированная на крупнейших российских предприятиях. Полезна как учебное пособие для “продвинутых” слушателей.
Клейменова М.С. Системный подход к проектированию сложных систем И Журнал д-ра Добба. - 1993. - № 1. - С. 9-14.
Весьма удачное с точки зрения подачи материала пособие для “непродвинутых” слушателей, в котором представлены фрагменты истории структурного подхода, а также основные моменты (с примерами) технологий SADT и IDEF.
Кукушкин А.А., Овсянников А.А. CASE-моделирование информационных процессов. - Орел: ВИПС, 1998.
Пособие по курсовому проектированию для слушателей военных учреждений, включающее все необходимое для исполнения проекта: требования к проекту, общие положения по CASE-моделированию, методика построения модели, методические примеры, а также описание основных функций поддерживающего технологию моделирования программного продукта BPWin.
Маклаков С.В. BPWin, ERWin. CASE-средства разработки информационных систем. - М.: ДИАЛОГ-МИФИ, 1999.
Практическое руководство по созданию информационных систем с помощью CASE-средств фирмы Platinum BPWin и ERWin. Изложена методология создания модели процессов в BPWin и модели данных с помощью ERWin. Связывание модели процессов и модели данных. Создание объектной модели и ее связывание с моделью данных при помощи ERWin Translation Wizard. Создание качественных отчетов с помощью RPTWin. Очень хорошее, к тому же и современ-
ное учебное пособие в обсуждаемой области, к сожалению, малопригодное для “непродвинутой” аудитории.
Марка Д.А., МакГоуэн К. SADT — методология структурного анализа и проектирования. - М.: Метатехнология, 1993.
Классический труд, в котором изложены основные концепции методологии SADT-IDEF (Structured Analysis and Design Technique). Подробно описан процесс построения функциональных моделей процессов. Множество примеров, взятых из реальных аналитических проектов, иллюстрируют различные способы применения SADT в широком спектре областей. Представляет большую ценность как учебно-методическое пособие для начинающих изучать предмет, не потерявшее своей ценности за прошедшее с момента выхода время.
Ручкин В.С. Вербальная модель функционирования отдела учета и отчетности физических лиц территориальной налоговой инспекции. Новые информационные технологии в финансово-кредитной сфере. - М.: Международная академия информатизации, 1997.
Пример использования IDEF-моделирования для автоматизации одной из задач налогообложения для физических лиц.
Семенов И.О. Вербальная модель функционирования отдела учета и отчетности юридических лиц территориальной налоговой инспекции. Новые информационные технологии в финансово-кредитной сфере. - М.: Международная академия информатизации, 1997.
Пример использования IDEF-моделирования для автоматизации одной из задач налогообложения юридических лиц.
Тельнов Ю.Ф. Реинжиниринг бизнес-процессов. - М.: Московский гос. университет экономики, статистики, информатики, 1999.
Теория и практика для выполнения лабораторных работ.
Черемных С.В., Ручкин В.С., Семенов И.О. Структурный анализ систем. IDEF-технологии. - М.: Финансы и статистика, 2001.
Изложена технология современного структурного анализа бизнес-процессов на основе пакета международных стандартов моделирования IDEF. Благодаря доступной, хорошо структурированной форме подачи материала, а также тщательно подобранным примерам специалисты, прежде всего в области менеджмента, имеют возможность использовать рассмотренную в книге технологию в качестве рабочего инструмента в своей практической деятельности.
Черемных О.С., Черемных С.В. Моделирование и реинжиниринг бизнес-процессов. Вводный курс. - М.: Финансовая академия, 2002.
Конспект лекций. Приведены толковый словаоь терминов и подробный список литературы.
BPwin Methods Guide. - Logic Works Inc., 1997.
Хорошее пособие для изучения подходов семейства IDEF и их отражения в программе BPwin.
Интернет-источники
WWW.IDEF.COM
Сайт группы разработчиков IDEF, содержит множество материалов по стандартам IDEF и их практическому применению. Имеет ссылки на форумы пользователей IDEF со всего мира.
WWW.IDEFINE.COM
Сайт одной из ведущих компаний по реинжинирингу корпораций, расположенной в Великобритании. Есть несколько статей по практическому применению IDEF в реинжиниринге.
www.interface.ru
Сайт основного дистрибьютера компании Computer Associates в России.
Оглавление
К читателю 3
Предисловие 7
Глава 1. Методология описания бизнес-процессов IDEF3 .9
Синтаксис и семантика моделей IDEF3 10
Модели IDEF3 10
Диаграммы, 10
Единица работы. Действие 11
Связи 11
Соединения 15
Указатели 21
Декомпозиция действий 22
Требования IDEF3 к описанию бизнес-процессов 22
Определение сценария,границ моделирования,
точки зрения 23
Определение действий и объектов 23
Последовательность и параллельность 24
Глава 2. Методология функционального моделирования IDEF0 25
Синтаксис и семантика моделей IDEF0 26
Модели IDEF0 26
Действия 27
Границы исвязи 27
Туннели 32
Построение моделей IDEF0 34
Диаграммы 34
Цикл “эксперт-аналитик” 36
Построение моделей 36
Точка зрения 37
Границы моделирования 37
Выбор наименования контекстного блока 38
185
Глава 2. Методология функционального моделирования IDEF0
Определение стрелок на контекстной диаграмме 39
Нумерация блоков и диаграмм 40
Связь между диаграммой и ее родительским функциональным блоком 41
Два подхода к началу моделирования (”в ширину” и “в глубину”) 42
Когда остановиться? 42
Другие диаграммы IDEF0 42
Взаимосвязь моделей IDEF0 и IDEF3 44
Действия, выполняемые в функциональных блоках 44
Создание моделей IDEF3 для отображения блоков IDEF0 45
Глава 3. Структурный анализ потоков данных DFD 47
Назначение диаграмм потоков данных 47
Синтаксис и семантика диаграмм потоков данных 49
Функциональные блоки 49
Внешние сущности 50
Стрелки (потоки данных) 50
Хранилища данных 51
Ветвление и объединение 51
Построение диаграмм потоков данных 52
Два подхода к построению DFD-моделей 52
Нумерация объектов 53
Глава 4. Программное обеспечение IDEF-моделирования 55
Platinum BPWin — руководство пользователя программного пакета компьютерной поддержки технологии моделирования IDEF 55
Краткий обзор 56
Проверка правильности выполнениязадания...57
Зачем нужно усовершенствованиебизнес-про-
цессов? 58
Деловое моделирование 58
Что такое BPWin? 58
Глава 4. Программное обеспечение IDEF-моделирования
Модель BPWin 59
Методологии моделирования, поддерживаемые BPWin 60
Функциональное моделирование (IDEF0) 60
Диаграммы потоков данных (DFD) 61
Описание бизнес-процессов (IDEF3) 61
Когда и какие методологии применять? 64
Рабочее место BPWin 65
Дерево модели 65
Область для рисования 67
Панель инструментов BPWin 67
Помощь 67
Построение контекстных диаграмм 68
Декомпозиция 70
Оформление моделей 73
Ветвление и объединение стрелок 75
Опции отображения 76
Другие виды диаграмм IDEF0 76
Открытие древовидных и FEO-диаграмм 78
Разбиение и объединение моделей 78
Оценивание бизнес-процессов с использованием BPWin 80
Печать диаграмм BPWin 83
Получение отчетовпо модели 84
Глава 5. Практические занятия 88
Создание контекстной диаграммы 89
Создание диаграммы декомпозиции 91
Задание. Создание диаграммы декомпозиции 96
Создание диаграммы узлов 99
Задание. Создание диаграммы дерева узлов 99
Создание FEO-диаграммы 100
Задание. Создание FEO-диаграммы 100
Расщепление и слияние моделей 101
Создание диаграммы IDEF3 103
187
Глава 5. Практические занятия
Создание перекрестка 104
Задание. Создание диаграммы IDEF3 106
Создание сценария 107
Задание. Создание сценария 108
Затратный (Cost) анализ 108
Задание 110
Использование категорий UDP 111
Задание. Использование категорий UDP 115
Расщепление модели 116
Слияние расщепленной модели с исходной моделью... 118
Копирование работ 119
Задание. Создание модели ТО-BE (реинжиниринг биз- нес-процессов) 120
Этап 1. Расщепление и модификация модели 121
Этап 2. Слияние модели 123
Этап 3. Использование Model Explorer для реорганизации дерева декомпозиции 125
Этап 4. Модификация диаграммы IDEF3 “Сборка продукта” с целью отображения новой информации 127
Этап 5. Декомпозиция работы “Продажи и маркетинг” . 128
Создание диаграммы DFD 129
Использование стрелок IDEF0 на диаграмме DFD 131
Интеграция процессов и данных на базе Erwin и BPWin 133
Генерация отчетов и печать диаграмм 139
Приложения 140
П1. Применение стандартов моделирования семейства IDEF для совершенствования Регламента Государственной Думы Российской Федерации 140
П2. IDEF-моделирование в налогообложении 144
П2.1.Постановка задачи 144
П2.2.Основные элементы модели 145
П2.3.Словарь 147
П2.4.IDEFO-диаграммы модели 148
П2.5.Описание функциональных блоков 152
Приложения
ПЗ. Моделирование управленческого учета на предприятии 153
ПЗ. 1.Постановка задачи 153
П3.2.Основные элементы модели 153
ПЗ.З.Список функций 154
П3.4.Словарь 155
П3.5.IDEFO-диаграммы модели 156
П3.6.Описание функциональных блоков 156
П4. Моделирование процесса создания и организации реинвестиционной деятельности холдинговой компании в Республике Австрия 160
П4.1. Постановка задачи 160
П4.2. Решение поставленной задачи при помощи технологии IDEF0 162
П4.3. Некоторые особенности рассматриваемой проблемы 162
Глоссарий 179
Рекомендуемая литература 181
Интернет-источники 183
Производственное издание
Черемных Станислав ВладимировичСеменов Илья Олегович
Ручкин Владимир Сергеевич
МОДЕЛИРОВАНИЕ И АНАЛИЗ СИСТЕМ.IDEF-ТЕХНОЛОГИИ:
ПРАКТИКУМ
Заведующая редакцией Л.А. ТабаковаРедактор Л.Д. Григорьева
Младший редактор Н.А. ФедороваХудожественный редактор Ю.И. АртюховТехнический редактор ГС. МарининаКорректоры Г.В. Хлопцева, Н.П. СперанскаяКомпьютерная верстка А.Н. КанатниковаОбложка художника О.В. Толмачева
ИБ № 4461
Подписано в печать 10.07.2006
Формат 60x88/16. Печать офсетнаяГарнитура «Таймс». Усл. п. л. 11,76. Уч.-изд. л. 10,72
Тираж 2000 экз. Заказ 1934. «С» 136
Издательство «Финансы и статистика»101000, Москва, ул. Покровка, 7Телефон (495) 625-35-02, факс (495) 625-09-57E-mail: mail@finstat.ru http://www.finstat.ru
ООО« Великолукская городская типография»182100, Псковская область, Великие Луки,ул. Полиграфистов, 78/12
Тел./факс: (811-53) 3-62-95E-mail: zakaz@veltip.ru