2015-04-08
3628
SADT – методология (Structured Analysis and Design Technics) получила столь широкое распространение благодаря тому, что ориентирована на комплексное представление структуры материальных, информационных, финансовых и управленческих потоков, отображение организационной структуры. В силу этого, SADT – методология в большей степени нацелена на реорганизацию всей системы управления, чем другие методологии функционального моделирования, основанные на использовании диаграмм потоков данных, главная цель которых проектирование информационных процессов. Функциональная модель бизнес-процессов состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, которые отображают последовательности взаимосвязанных через общие объекты функций (операций, действий, работ – activity) бизнес-процесса. Достоинство функциональной модели заключается в графической простоте, в которой используются всего два конструктивных элемента:
• функциональный блок – описание функции, операции, действия, работы;
• интерфейсная дуга, связывающая два функциональных блока – описание объекта, потока объектов.
Функциональная модель начинается с построения общего описания процесса, которое представляется в диаграмме нулевого уровня или контекстной диаграмме (рис. 3.1.). На этом уровне весь процесс рассматривается как один функциональный блок со всеми связанными обрабатываемыми и управляющими объектами. На этой диаграмме также отражается цель структурного анализа (например, сокращение длительности выполнения процесса, или сокращение издержек, или повышение качества обслуживания и т.д.) и точка зрения, с позиции которой рассматривается модель (дирекция, отдел информатизации, экономический отдел и т.д.).
Диаграммы следующих уровней детализируют функции процесса каждого предыдущего уровня (рис. 3.2.). Так, функциональный блок А0 декомпозируется на совокупность взаимосвязанных подфункций А1, А2, А3, …. В свою очередь, каждый функциональный блок 1-го уровня может быть декомпозирован на совокупность подфункций, на- пример А2 на А21, А22, А23, А24... и так дальше, пока на последнем уровне не получатся элементарные действия. На каждом уровне рекомендуется размещать не более 6 функциональных блоков. Число уровней декомпозиции не ограниченно. Обычно для структурного анализа бизнес-процессов достаточно 2 – 3 уровней декомпозиции, последующие уровни декомпозиции требуются для алгоритмизации информационных процессов и раз- работки инструкций для исполнителей бизнес-процессов.
Для каждого функционального блока определяются интерфейсные дуги различных типов (стрелки), которые отражают потоки объектов. Объекты могут быть различной природы: материальные, финансовые, информационные. По характеру использования объектов в функциональных блоках различают: входные (input) объекты слева от блока, выходные (output) объекты справа от блока, управляющие (control) объекты сверху от блока и механизмы (mechanize) снизу от блока. Объекты обозначаются метками на стрелках, которые обязательны. Входные объекты преобразуются в функциональных блоках в выходные. При этом выходной объект – это новый созданный объект или преобразованный старый объект. В последнем случае новое качество объекта, как правило, обозначается прилагательным, например, принятый заказ, отложенный заказ, удаленный заказ, выполненный заказ и т.д. Управляющие объекты соответствуют нормативным актам (законодательным актам, инструкциям, планам, приказам), на основе которых выполняются процессы. Кроме того, управляющие объекты рассматриваются как ограничения, обстоятельства, условия выполнения процесса, например номенклатуры-ценники, списки клиентов и поставщиков, состояние запасов, состояние расчетного счета, наличие производственных мощностей и т.д. Управляющие объекты должны обязательно отражаться в функциональной модели, а входные объекты не обязательно. В последнем случае какой-либо управляющий объект одновременно является и входным, например, заказ, на основе которого выполняется работа, преобразуется внутри функционального блока в готовый продукт. Механизмы – это объекты, которые исполняют процессы (исполнители). К механизмам относят структурные подразделения предприятия, персонал, автоматизированные рабочие места, оборудование. Объекты могут выступать в различных блоках в разных ролях, например, когда выходной объект одного блока является входным объектом, или управляющим объектом, или механизмом для другого функционального блока. Объекты, которые выступают только в одной роли, обозначаются метками, с которыми связаны пограничные дуги. При этом объекты, передаваемые в детальную диаграмму из вышестоящих диаграмм, обозначаются ICOM метками (рис. 3.2.):
I1, I2, I3, …. – входные объекты;
О1, О2, О3, … – выходные объекты;
С1, С2, С3, …. – управляющие объекты;
М1, М2, М3, …. – механизмы.
ППП Design/IDEF (Фирма-разработчик: MetaSoftware (США), дистрибьютор: «Весть-Метатехнология») предназначен для проведения структурного и стоимостного анализа бизнес-процессов и относится к классу «легких» систем автоматизированного проектирования информационных систем (CASE-технологий), позволяющий построить структуру логического проекта системы. В основе ППП Design/IDEF лежит SADT – методология (структурного анализа и техники проектирования) [2,25], которая дает возможность строить функциональные модели бизнес-процессов. Данная методология реализована также в ППП BPWin.
К функциональным возможностям ППП Design/IDEF относятся:
• Графическое представление функциональной структуры (технологии выполнения) бизнес-процессов на различных уровнях детализации.
• Разработка функциональной модели с указанием исполнителей операций и используемых информационных технологий и управляющих воздействий.
• Графическое представление структуры предметной области в виде информационной модели «Объект-связь».
• Расчет стоимостных затрат на выполнение бизнес-процессов с возможностью экспорта расчетных данных в электронную таблицу Excel, Lotus.
• Документирование моделей предметной области в виде глоссария и составления текстовых отчетов.
• Автоматизация проектирования информационной системы, в частности, определение структуры базы данных.
• Возможность экспорта функциональной модели в пакеты программ динамического имитационного моделирования, поддерживающие сети Петри.
ППП Design/IDEF состоит из трех основных компонентов:
• IDEF0 – инструмент функционального моделирования;
• IDEF1x – инструмент информационного моделирования;
• IDEF/CPN (Workflow Analyzer) – инструмент динамического имитационного моделирования (отдельно поставляемый программный продукт).
