Файл: О.А. Бияков Моделирование бизнес-процессов в стандарте IDEF0.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 01.06.2024
Просмотров: 34
Скачиваний: 0
МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «КУЗБАССКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»
Кафедра вычислительной техники и информационных технологий
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ В СТАНДАРТЕ
IDEF0
Методические указания к лабораторной работе по дисциплине «Проектирование информационных систем» для студентов специальности 351400 «Прикладная информатика в экономике»
Составители О.А. Бияков Н.Ю.Коломарова
Утверждены на заседании кафедры Протокол № 8 от 30.04.03
Рекомендованы к печати учебнометодической комиссией специальности 351400 Протокол № 4 от 30.04.03
Электронная копия находится в библиотеке главного корпуса ГУ КузГТУ
Кемерово 2003
1
ВВЕДЕНИЕ
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель. Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования – вопросы, на которые построенная модель должна дать ответ. IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.
Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы и ее взаимодействия с внешней средой, называется контекстной диаграммой. После описания в целом проводится разбиение системы на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы: эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются и, только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Таким образом достигается соответствие модели реальным бизнеспроцессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Работы (Activity), которые означают некие поименованные процессы, функции или задачи, изображаются в виде прямоугольников. Именем
2
работы должен быть глагол или отглагольное существительное (например, "Изготовление детали", "Прием заказа" и т.д.). Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, "Заготовка", "Изделие", "Заказ").
1. Принципы построения модели бизнес-процесса
При построении модели бизнес-процесса в стандарте IDEF0 необходимо руководствоваться следующими принципами.
Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций.
Принцип ограничения сложности. При работе с IDEF0диаграммами существенным является условие их разборчивости и удобочитаемости. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0-модели, хорошо структурированы, понятны и легко поддаются анализу.
Принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок – главная бизнес-функция моделируемой системы. Если речь идет о моделировании целого предприятия или даже крупного подразделения, главная бизнес-функция не может быть сформулирована как, например, “продавать продукцию”. Главная бизнес-функция системы – это “миссия” системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии. При определении главной бизнес-функции необходимо всегда иметь в виду цель моделирования и точку зрения на модель. Одно и то же предприятие может быть описано по-разному в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговый инспектор видят организацию совершенно по-разному. Контекстная диаграмма играет еще одну роль в функциональной модели. Она “фик-
3
сирует” границы моделируемой бизнес-системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную бизнес-функцию.
2. Декомпозиция модели в стандарте IDEF0
Функциональный блок декомпозируется, если необходимо детально описать его работу. Построение IDEF0-модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг
– они также представляют полный набор внешних интерфейсов системы в целом.
Блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию.
Модель IDEF0, таким образом, представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец ос-
4
тается неприсоединенным. Неприсоединенные дуги соответствуют ВХОДАМ, УПРАВЛЕНИЯМ и ВЫХОДАМ родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть затем детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. В номерах допускается использовать префиксы произвольной длины, но обычно используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет номер А0.
Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок А0 декомпозируется в блоки А1, А2, А3 и т.д. Блок А2, например, декомпозируется в А21, А22, А23 и т.д. А21 – в А211, А212,
А213 и т.д.
3.Последовательность построения модели бизнес-процесса
3.1.Описание общих свойств модели
Для создания новой модели необходимо либо выбрать в меню
пункт File/New, либо щелкнуть по иконке . После этого на экране появится окно (рис. 1), где необходимо указать имя создаваемой модели и ее тип (IDEF0). Название модели должно быть кратким и емким, отражать сущность моделируемого бизнес-процесса. Например, «Сбор налогов», «Управление персоналом».
В следующем окне (рис. 2) необходимо указать фамилии и инициалы авторов модели.
Далее необходимо выбрать пункт меню Model/ Model Properties и перейти на закладку General (рис. 3). В пункте Project укажите название проекта. Например, если было дано имя модели «Деятельность компании», то название проекта может быть таким: «Модель деятельности
5
Рис. 1. Окно идентификации модели бизнес-процесса
Рис. 2. Окно описания свойств модели (авторы)
компании». Кроме имени авторов модели должен быть указан тип модели. Если идет построение на основе ранее созданной вербальной модели, то указывается тип AS-IS (как есть). Если модель этого типа была построена ранее и на ее основе строится улучшенная модель, то укажите тип TO-BE (как должно быть).
Далее необходимо перейти на вкладку Purpose (рис. 4) и указать цель моделирования и точку зрения. Выбранное определение цели моделирования должно отвечать на вопросы: почему моделируется данный процесс; что выявит данная модель; какие результаты может принести применение данной модели. Например, формулировка цели может быть следующей: идентифицировать роли и ответственность работников компании для написания должностных инструкций. Другая формулировка – определить текущие проблемы, сделать анализ потенциальных улучшений. Еще одна формулировка – выявить задачи каждого работника компании и понять в целом взаимосвязь между отдельными задачами для оптимизации штатного расписания компании.
6
Рис. 3. Окно описания свойств модели (General)
Основой для выбора точки зрения должна служить поставленная цель моделирования. Наименованием точки зрения может быть должность, название подразделения, например, руководитель отдела или менеджер по продажам. Четкое определение точки зрения необходимо для обеспечения внутренней целостности модели и предотвращения постоянного изменения ее структуры.
На следующей вкладке Definition (рис. 5) необходимо дать описание сущности моделируемого бизнес-процесса на основе ранее полученной вербальной модели. Из описания должно быть понятно: почему происходит процесс, где, когда, с какой периодичностью и т.д. В пункте Scope необходимо указать, в каком контексте рассматривается биз- нес-процесс. Например, бизнес-процесс «Оптимизация штатного расписания организации» может рассматриваться в следующих контекстах: сокращение лишних должностей; появление новых должностей в
7
связи с расширением деятельности организации; перераспределение фонда заработной платы и т.д.
Рис. 4. Окно описания свойств модели (цель моделирования и точка зрения)
Последнее свойство модели, которое обязательно необходимо описать, находится на вкладке Source (рис. 6). В этом пункте должны быть кратко отражены сведения об организации, чей бизнес-процесс моделируется, источники информации (эксперты).
Кроме этого, можно на вкладке Status указать вид модели: working
– рабочая, draft – черновик, recommended – готовая для ознакомления экспертов, publication – полностью законченная модель. На вкладке Display указываются компоненты, которые должны быть отражены на диаграммах. На вкладке Numbering определяется принцип нумерации блоков при их декомпозиции (изменять не рекомендуется). На вкладке
8
Page Setup указывается формат листа бумаги, на котором можно получить модель при печати (масштаб изображения модели).
Рис. 5. Окно описания свойств модели (описание и контекст)
Рис. 6. Окно описания свойств модели (источники)
9
3.2. Описание свойств функционального блока (работы)
После определения основных свойств модели на экране появляется контекстная диаграмма с единственной работой, изображающей систему в целом. Двойной щелчок на контекстной диаграмме блока позволит дать его описание (рис. 7). На вкладке Name необходимо дать название блока (работы). Название должно быть в форме отглагольного существительного. Например, «Прием заказа», «Изготовить деталь».
Далее, перейдите на закладку Definition и опишите суть работы в данном функциональном блоке (рис. 8). Следует заметить, что по умол-
Рис. 7. Окно описания функционального блока (название функционального блока)
Рис. 8. Окно описания функционального блока (описание сути функционального блока)
чанию все надписи в модели имеют кегль 10, что затрудняет чтение модели, особенно в распечатанном варианте, поэтому рекомендуется в каждом из пунктов описания использовать закладку Font для изменения кегля на 14.