Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Проектирование сложных бизнес-объектов на основе системного анализа. Монография

.pdf

Скачиваний:

Добавлен:

08.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 6 7 89 / 159 10 11 12 13 14 15 > Следующая >>>

Рисунок 4.4. Цикл формирования архитектуры

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

− изучение новых технологий для обеспечения анализа современных

тенденций и оценки возможности практического использования инновационных технологий;

− архитектура решений, включающая процесс разработки прикладных

систем;

− целевая архитектура, описывающая желаемое будущее состояние

предприятия (фактически создание модели «КАК БУДЕТ»);

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

вания и поддержания в актуальном виде информации о состоянии предприятия (модель «КАК ЕСТЬ»).

К настоящему моменту дисциплина «архитектура предприятия» достигла определенной зрелости: возникли и модифицировались методики, накопилась практика реорганизации компаний, осуществляется преподавание данной дисциплины в учебных учреждениях. Вместе с тем причины, почему архитектура предприятия не стала общепризнанной практикой, указанные Дж. Захманом в статье «Enterprise Architecture: Looking Back and Looking Ahead» в 1999 году до сих пор не потеряли своей актуальности [51].

В заключение раздела следует перечислить ключевые эффекты от управления архитектурой:

1) эффект, измеряемый миллионами долларов, был получен в первый

год эксплуатации системы управления архитектурой предприятия за счет обеспечения соответствия лучшим практикам и стандартам

(Международная ассоциация финансовых директоров, журнал BusinessWeek и аналитики Ernst & Young);

2) экономия до 15% стоимости ИТ- проектов только за счет сокращения

расходов на сбор данных об ИТ- инфраструктуре (Deloitte);

3) многократное снижение времени (до шести раз) подготовки и расчета

бизнес-кейсов (IDS Scheer);

4) экономия до 20% за счет сокращения количества работ по реализации

и переделке, связанных с некорректными требованиями (Standish Group);

5) экономия до 30% за счет механизма выбора приоритетных инвести-

ций в ИТ (McKinsey);

6) экономия общих операционных расходов до 30% за счет планирова-

ния и стандартизации ИТ-инфраструктуры (Meta Group);

7) экономия до 40% неоперационных расходов на персонал и сокраще-

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

5 Основные методологии моделирования и анализа

бизнес-процессов

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

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

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

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

(IDEF0, IDEF3, ARIS, UML и пр.) хорошо изложены в методической литературе [16, 67, 71, 82, 107]. В данном разделе кратко освещаются наиболее распро-

страненные методики.

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

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

Например, если рассматривать методику UML (Unified Modeling Language, унифицированный язык моделирования), то ее можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Затем осуществляется дальнейшее развитие концептуальной модели проектируемой системы в логическую в виде создания диаграммы классов. Ну и заключительным шагом является построение физической модели в виде диаграмм размещения.

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

В общем случае модель бизнес-процесса должна давать ответы на следующие вопросы [32]:

− какие функции (работы, операции) необходимо выполнить для полу-

чения заданного конечного результата;

− кто выполняет функции процесса;

− как происходит взаимодействие исполнителей при выполнении этих

функций, в какой последовательности;

− какие механизмы управления существуют в рамках рассматриваемого

бизнес-процесса;

− какие входящие документы / информацию использует каждая функ-

ций процесса;

− какие исходящие документы / информацию генерирует каждая функ-

ция процесса;

− какие ресурсы необходимы для выполнения каждой функции процес-

са;

− какая документация регламентирует выполнение каждой функции;

− какие параметры характеризуют выполнение каждой функции в от-

дельности и процесса в целом.

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

Ниже кратко рассмотрены следующие методики:

1) семейство стандартов обследования организаций и проектирования

информационных систем IDEF, основанное на технологии структурного анализа и проектирования SADT (Structured Analysis and Design

Technique);

2) DFD (Data Flow Diagrams), диаграммы потоков данных совместно со

словарями данных и спецификациями процессов или миниспецификациями;

3) UML (Unified Modeling Language, унифицированный язык моделиро-

вания);

4) ARIS (Architecture of Integrated Information Systems, архитектура ин-

тегрированных информационных систем) доктора Шеера (IDS Scheer

AG);

5) BPMN (Business Process Modeling Notation), стандарт «Нотация мо-

делирования бизнес-процессов».

5.1 IDEF – семейство стандартов обследования организаций и проектирования информационных систем

В США в конце 70-х годов XX века была предложена и реализована Программа интегрированной компьютеризации производства ICAM (Integrated Computer Aided Manufacturing), направленная на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий.

В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было требование обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта. Для удовлетворения этой потребности в рамках программы ICAM была разработана методология моделирования IDEF (IDEF=ICAM DEFinition), позволяющая исследовать структуру, параметры и характеристики производственно-технических и организационных систем.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. Данная методология широко поддерживается Министерством обороны США, которое и было инициатором разработки стандарта IDEF0 как подмножества SADT. Это, наряду с растущей авто-

матизированной поддержкой, сделало ее более доступной и простой в употреблении.

Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique).

Методология структурного анализа и проектирования SADT была разработана Дугласом Т. Россом в 60-70-х годах XX века. SADT была создана и впервые опробована на практике в период с 1969 по 1973 г. Исходная работа над

SADT началась в 1969 г. Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта, когда она была не-

сколько пересмотрена сотрудниками SofTech, Inc. В 1974 г. SADT была еще улучшена и передана одной из крупнейших европейских телефонных компаний. Появление SADT на рынке произошло в 1975 г. после годичного оформления в виде продукта. К 1981 г. SADT уже использовали более чем в 50 компаниях при работе более чем над 200 проектами, включавшими более 2000 людей и охватывавшими дюжину проблемных областей, в том числе телефонные сети, аэрокосмическое производство, управление и контроль, учет материальнотехнических ресурсов и обработку данных.

C 1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

В настоящее время к семейству IDEF можно отнести следующие стандарты:

1) IDEF0 – Integration Definition for Function Modeling – методология

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

2) IDEF1 – Information Modeling – методология моделирования инфор-

мационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

3) IDEF1X (IDEF1 Extended) – Data Modeling – методология построения

реляционных структур. IDEF1X относится к типу методологий «Сущность-взаимосвязь» (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

4) IDEF2 – Simulation Modeling – методология динамического модели-

рования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN – Color Petri Nets);

5) IDEF3 – Process Description Capture – методология документирования

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

6) IDEF4 – Object-oriented Design – методология построения объектно-

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

7) IDEF5 – Ontology Description Capture – методология онтологического

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

8) IDEF6 – Design Rationale Capture;

9) IDEF7 – Information System Audit Method;

10) IDEF8 – User Interface Modeling;

11) IDEF9 – Scenario-driven Info Sys Design Spec;

12) IDEF10 – Implementation Architecture Modeling;

13) IDEF11 – Information Artifact Modeling;

14) IDEF12 – Organization Modeling;

15) IDEF13 – Three Schema Mapping Design;

16) IDEF14 – Network Design.

К настоящему времени наибольшее распространение и применение с точки зрения бизнес-моделирования имеют методологии IDEF0 и IDEF3.

5.2 Методология IDEF0

Методология IDEF0 является, пожалуй, одной из наиболее полно освещенных в литературе [24, 71, 75]. В частности, существует ГОСТ Р 50.1.0282001, посвященный методологии функционального моделирования.

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

В основе методологии лежат следующие понятия:

− Понятие функционального блока (Activity Box), который изобража-

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

− Понятие интерфейсной дуги (Arrow), изображаемой в виде однона-

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

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

Рисунок 5.1. Пример работы и интерфейсных дуг в IDEF0

−

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. При декомпозиции любого функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на диаграмме декомпозиции. Этим достигается структурная целостность IDEF0 – модели.

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

Рисунок 5.2. Иерархия и декомпозиция IDEF0-диаграмм

− Глоссарий, который подразумевает создание и поддержание набора

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

Как видно, IDEF0 досконально соответствует основным положениям системного подхода: деление целого на части (так называемый принцип «разделяй и властвуй») путем формирования иерархической упорядоченной картины.

Обычно IDEF0-модели несут в себе сложную и концентрированную ин-

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

<<< < Предыдущая 1 2 3 4 5 6 7 89 / 159 10 11 12 13 14 15 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]