Функциональная структура
Функция (операция) представляет собой некоторый преобразователь входных объектов в выходные.
Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс.
Функция бизнес-процесса может порождать объекты любой природы (материальные, денежные, информационные). Например, функция отгрузки готовой продукции осуществляется на основе документа «Заказ». Этот документ, в свою очередь, порождает документ «Накладная», который сопровождает партию отгруженного товар.
Функция может быть представлена одним действием или совокупностью действий. В последнем случае каждой функции может соответствовать некоторый процесс. В этом процессе каждой подфункции могут соответствовать свои подпроцессы и т.д., пока каждая подфункция не будет представлять некоторую не декомпозируемую последовательность действий.
На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15-20.
На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций.
На внутреннем уровне отображается структура информационного процесса в компьютере, т.е. определяются иерархические структуры программных модулей, которые реализуют автоматизируемые функции.
Структура управления
В совокупности функций бизнес-процесса возможны альтернативные или циклические последовательности в зависимости от различных условий протекания процесса.
Эти условия связаны с событиями, происходящими во внешней среде или в самих процессах. Условия приводят к образованию определенных состояний объектов (например, заказ принят, отвергнут, отправлен на корректировку).
События вызывают выполнение функций. В свою очередь выполнение функций изменяет состояния объектов и формирует новые события и т.д., до тех пор, пока не будет завершен бизнес-процесс.
Такая последовательность событий составляет конкретную реализацию бизнес-процесса.
Каждое событие описывается с двух точек зрения: информационной и процедурной.
Информационно некоторое событие отражается в виде некоторого сообщения. Это сообщение фиксирует факт выполнения некоторой функции изменения состояния или появление нового объекта.
Процедурно событие вызывает выполнение новой функции. Поэтому для каждого состояния объекта должны быть заданы описания этих вызовов.
Таким образом, события выполняют связующую роль для выполнения функций бизнес-процессов.
На внешнем уровне определяются список внешних событий, вызываемых взаимодействием предприятия с внешней средой (платежи налогов, процентов по кредитам, поставки по контрактам и т.д.) и список целевых установок, которым должны соответствовать бизнес-процессы (регламент выполнения процессов, поддержка уровня материальных запасов, уровень качества продукции и т.д.).
На концептуальном уровне устанавливаются бизнес-правила, которые определяю условия вызова функций при возникновении событий и достижении состояний объектов.
На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей.
Организационная структура
Организационная структура представляет собой совокупность взаимосвязанных организационных единиц, которые связаны иерархическими и процессными отношениями.
Организационная единица – это подразделение, представляющее собой объединение людей для выполнения совокупности общих функций или бизнес-процессов.
В функционально-ориентированной организационной структуре организационная единица выполняет набор функций, относящихся к одной функции управления и входящих в различные процессы.
В процессно-ориентированной организационной структуре организационная единица выполняет набор функций, входящих в один процесс и относящихся к разным функциям управления.
На внешнем уровне моделирования строится структурная модель предприятия в виде иерархии подчинения организационных единиц или списков взаимосвязанных подразделений.
На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).
На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы.
Техническая структура
Топология определяет территориальное размещение технических средств по структурным подразделениям предприятия, а коммуникация – технический способ реализации взаимодействия структурных подразделений.
На внешнем уровне модели определяются типы технических средств обработки данных и их размещение по структурным подразделениям.
На концептуальном уровне определяется способ коммуникаций между техническими комплексами структурных подразделений, а именно: физическое перемещение документов, машинных носителей, обмен информацией по каналам связи и т.д.
На внутреннем уровне строится модель «клиент-серверной» архитектуры вычислительной сети.
Все описанные модели проблемной области нацелены на проектирование отдельных компонентов ИС:
- данных;
- функциональных программных модулей;
- управляющих программных модулей;
- программных модулей интерфейсов пользователей;
- структуры технического комплекса.
Для более качественного проектирования этих компонентов требуется построение моделей, которые увязывают рассмотренные модели между собой.
Важно осуществить совместное моделирование взаимодействующих компонентов, особенно с содержательной точки зрения объектов и функций.
В настоящее время существует большой количество различных методологий моделирования проблемной области.
Однако все многообразие этих методологий можно разделить на две группы:
1. методологии структурного анализа и проектирования ИС (функционально-ориентированные методологии);
2. методологии объектно-ориентированного анализа и проектирования ИС (объектно-ориентированные методологии).
Отметим, что все эти методологии базируются на использовании графических (визуальных) моделей. Графические модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы. Каждая модель определяет конкретный аспект системы, использует набор диаграмм и документов заданного формата и является объектом деятельности различных людей с конкретными интересами, ролями или задачами.
Хорошие модели являются основой взаимодействия участников проекта (проектировщиков и менеджеров заказчика) и гарантируют корректность архитектуры разрабатываемой системы.
В функциональных моделях (DFD-диаграммы потоков данных, SADT-диаграммах) главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связываются между собой потоками объектов.
Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу «сверху-вниз», когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д. Таким образом, выполняется модульное проектирование ИС.
В функциональном подходе объектные модели данных разрабатываются отдельно в виде ER-диаграмм «сущность-связь».
Для проверки корректности моделирования между функциональными и объектными моделями устанавливаются взаимно однозначные связи.
Основной недостаток функциональных моделей связан с неясностью условий выполнения процессов обработки информации, которые могут динамически изменяться.
Кроме того, возможна повторяемость использования одинаковых функций, а, следовательно, и программных модулей в различных процессах. В последнем случае одни и те же функции в различных иерархиях могут быть спроектированы несколько раз, либо общее определение может содержать не все необходимые детали.
Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях.
Главным компонентом таких моделей является класс объектов с набором функций, которые могут обращаться к атрибутам этого класса (скрытые данные).
Для класса объектов характерна иерархия обобщения, которая позволяет осуществлять наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов).
В случае наследования функций можно абстрагироваться от конкретной реализации процедур (абстрактные типы данных), которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам (полиморфизм) и осуществлять повторное использование программного кода при модификации программного обеспечения.
Таким образом, адаптивность объектно-ориентированных систем к изменению проблемной области значительно выше по сравнению с функциональным подходом.
Для объектно-ориентированного подхода разработаны графические методы моделирования проблемной области, которые обобщены в языке моделирования UML.
Однако по наглядности представления модели пользователю-заказчику объектно-ориентированные модели явно уступают функциональным моделям.
При выборе подхода для построения модели предметной области обычно в качестве критерия выбора выступает степень ее динамичности. Для более регламентированных задач больше подходят функциональные модели, а для более адаптивных бизнес-процессов, например управление рабочими потоками, реализация динамических запросов к информационным хранилищам - объектно-ориентированные модели.
Однако в рамках одной и той же ИС для различных классов задач могут требоваться различные виды моделей. В таких случаях должны использоваться комбинированные модели проблемной области.
В полной мере комбинированный подход к моделированию проблемной области реализован в инструментальном средстве ARIS-Toolset (Architecture of Integrated Information System). Это инструментальное средство реализует множество различных методологий, соответствующих различным взглядам на проектирование ИС: объекты, функции, организационная структура.
В рамках каждого из перечисленных подходов создаются соответственные модели. Кроме того, существует подход, комбинирующий все три подхода вместе. Он позволяет увязать организационную структуру с функциями и данными через возникающие события, отражая динамическую структуру бизнес-процессов. Таким образом существенно сближаются функциональный и объектно-ориентированный подходы к модулированию проблемной области.
DFD-диаграммы и SADT-технология стали основой для разработки в 80-х годах ХХ-века в США серии стандартов методологий структурного анализа, получивших название методологии IDEF (Integrated Computer Automated Manufacturing DEFinition). Они применялись для моделирования как сложных военных систем и структур, так и в корпоративном управлении.
Всего было создано 14 стандартов IDEF, в том числе:
1. IDEF0 - моделирование функций;
2. IDEF1 - информационное моделирование;
3. IDEF1X - моделирование данных;
4. IDEF2 - динамическое моделирование;
5. IDEF3 - описание процессов;
6. IDEF4 - объектно-ориентированные методы проектирования;
7. IDEF8 - интерфейс пользователя;
8. IDEF14- проектирование вычислительных сетей.
Детальное описание стандартов IDEFможно найти по адресу http://www.indel.com
В конце 90-х годов увеличилась конкуренция, и рентабельность деятельности предприятий стала резко падать. Руководители столкнулись с огромными сложностями, пытаясь оптимизировать затраты и сделать продукцию одновременно и прибыльной, и конкурентоспособной. Четко обозначилась необходимость иметь модель деятельности предприятия, отражающую все механизмы и принципы взаимосвязи различных подсистем в рамках одного бизнеса.
Понятие "моделирование бизнес-процессов" вошло в обиход большинства аналитиков одновременно с появлением на рынке сложных программных продуктов (КИС), предназначенных для комплексной автоматизации управления предприятием. Внедрение подобных систем всегда подразумевает проведение глубокого предпроектного исследования деятельности компании.
Результатом такого исследования становится экспертное заключение, где отдельно даются рекомендации по устранению "узких мест" в управлении деятельностью организации. На основании экспертного заключения, непосредственно перед началом проекта, проводится так называемая реорганизация бизнес-процессов, часто достаточно серьезная и болезненная для компании.
С помощью методологий семейства IDEF можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом глубина исследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.
В настоящий время наиболее широко используются следующие стандарты IDEF:
· IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0 представляет изучаемую систему в виде набора взаимосвязанных функций ("функциональных блоков"). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;
· IDEF1 - методология моделирования информационных потоков внутри системы. Позволяет отображать и анализировать их структуру и взаимосвязь;
· IDEF1X (IDEF1 Extended) - методология построения реляционных структур. IDEF1X относится к типу методологий "Сущность-взаимосвязь" (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;
· IDEF2 - методология динамического моделирования развития систем. Из-за серьезных сложностей, связанных с анализом динамических систем, от этого стандарта сейчас практически отказались, и его развитие приостановилось на самом начальном этапе. Существующие алгоритмы и их компьютерные реализации позволяют превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе "раскрашенных сетей Петри" (CPN - Color Petri Nets);
· IDEF3 - методология документирования процессов, происходящих в системе. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 напрямую связана с методологией IDEF0: каждая функция (функциональный блок) может быть представлена средствами IDEF3 в виде отдельного процесса;
· IDEF4 - методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и принципы их взаимодействия, позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
· IDEF5 - методология онтологического исследования сложных систем. С помощью словаря терминов и правил позволяет описать онтологию системы. В итоге могут быть сформированы достоверные утверждения о состоянии системы в некоторый момент времени, на основе которых делаются выводы о дальнейшем развитии системы и производится её оптимизация.