- •Профессор Шеер
- •Издание второе Содержание
- •Предисловие к русскому изданию
- •Предисловие ко второму изданию
- •Об этой книге
- •Классификация содержания
- •А. Преимущества aris для пользователя
- •А. 1. Преимущества для управления бизнесом и организационных процессов
- •А. 2. Преимущества для пользователя при разработке информационных систем
- •Б. Базовая модель бизнес-процесса в aris
- •Б.1. Исходная модель бизнес-процесса
- •Б. 1.1. Субъекты ответственности и их отношения
- •Б. 1.2. Поток функций
- •Б. 1.3. Поток выходов
- •Б.1.4. Информационный поток
- •Б.1.5. Объединенная модель бизнес-процесса
- •Б.2. Aris-модель бизнес-процесса
- •Б.2.1. Пример расширенной версии процесса
- •Б.2.2. Обобщенная модель бизнес-процесса
- •В. Разработка архитектуры интегрированных информационных систем (здание aris)
- •В.1. Типы моделей в aris
- •В. 2. Фазовая модель aris
- •В. З. Предварительная информационная модель aris
- •В.4. Предварительная процедурная модель aris
- •Г. Управление бизнес-процессами на базе aris. Aris — архитектура бизнес-инжиниринга
- •Г.1. Инжиниринг бизнес-процессов
- •Г.1.1. Моделирование продуктов и бизнес-процессов
- •Г. 1.2. Модели-прототипы
- •Г. 1.3. Управление знаниями
- •Г. 1.4. Оценка процессов
- •Г. 1.5. Эталонное сравнение процессов
- •Г. 1.6. Имитация
- •Г. 1.7. Обеспечение качества
- •Г. 1.8. Хранилище процессов
- •Г.2. Планирование и управление бизнес-процессами
- •Г.2.1. Мониторинг процессов
- •Г.2.2. Составление графиков и регулирование мощностей
- •Г.2.3. Управленческие информационные системы (eis)
- •Г.2.4. Непрерывное совершенствование процессов — адаптивный инжиниринг бизнес-процессов
- •Г. З. Управление потоками работ (workflow)
- •Г.4. Прикладные системы
- •Г.4.1. Традиционные стандартные программные решения
- •Г.4.2. Компонентное программное обеспечение
- •Г.4.2.1. Объекты
- •Г.4.2.2. Бизнес-объекты
- •Г.4.2.3. Java-аплеты
- •Г.4.2.4. Проблемы стандартизации
- •Г.5. Рабочее пространство (инфраструктура) г.5.1. Концепция рабочего пространства
- •Г.5.2. Концепции реализации
- •Г.5.2.1. Рабочее пространство (инфраструктура) aris
- •Г.5.2.2. Рабочее пространство sap
- •Г.5.2.4. Проект San Francisco компании ibm
- •Г.5.3. Перспективы развития индустрии программного обеспечения
- •Д. Моделирование стандартов в aris
- •Д.1. Общепринятые принципы моделирования
- •Д.2. Уровни моделирования
- •Д. З. Степени структурирования и детализации
- •Д.4. Варианты моделей
- •Е. Сравнение aris с другими концепциями
- •Е.1. Объектно-ориентированное моделирование
- •Е.2. Архитектура cimosa
- •Е.З. Ifip — Методология информационных систем
- •Е.4. Инфраструктура Захмана
- •Е.5. Результаты исследований Санкт-Галленского университета, Швейцария
- •Е.6. Другие архитектурные решения
- •Ж. Внедрение aris — практические процедуры
- •Ж.1. Реинжиниринг бизнес-процессов на базе модели aris ж. 1.1. Корпоративный инжиниринг, ориентированный на процессы
- •Ж. 1.2. Процедурная модель для оптимизации бизнес-процессов
- •Ж.1.3. Фазы оптимизации бизнес-процессов ж. 1.3.1. Подготовительные меры
- •Ж. 1.3.2. Стратегическое планирование
- •Ж. 1.3.3. Анализ «как есть»
- •Ж.1.3.4. Целевая концепция
- •Ж. 1.3.5. Спецификация проекта
- •Ж. 1.3.6. Реализация
- •Ж. 1.3.7. Регулярный мониторинг и непрерывное совершенствование процессов
- •Ж. 1.4. Резюме
- •Ж. 2. Сертификация соответствия стандарту iso 9000 на базе модели aris ж.2.1. Управление качеством (ук) на базе aris с ориентацией на процессы
- •Ж.2.2. Процедурная модель для сертификации iso ж.2.2.1. Процедурная модель: общее описание
- •Ж.2.2.2. Процедурная модель: преимущества
- •Ж.2.3. Фазы процедурной модели
- •Ж.2.3.1. Стратегическое планирование
- •Ж.2.3.2. Фаза подготовки к управлению качеством
- •Ж.2.3.3. Анализ системы управления качеством «как есть»
- •Ж.2.3.4 «iso 9000 на базе aris»: целевая концепция
- •Ж.2.3.5. Структурирование системы ук
- •Ж.2.3.6. Применение и пересмотр систем ук
- •Ж.2.3.7. Сертификация
- •Ж.2.3.8. Перспективы и инфраструктура: системное управление качеством
- •Ж. З. Использование моделей aris для управления знаниями ж.3.1. Использование знаний для получения конкурентных преимуществ
- •Ж.3.2. Процедуры реинжиниринга процессов знаний
- •Ж.3.3. Фазы реинжиниринга процессов знаний ж.3.3.1. Стратегическое планирование знаний
- •Ж.3.3.2. Анализ процесса обработки знаний «как есть»
- •Ж.3.3.3. Анализ состояния «как есть»
- •Ж.3.3.4. Целевая концепция обработки знаний
- •Ж.3.3.5. Организационно-кадровая концепция реализации
- •Ж.3.3.6. Концепция реализации средствами ит
- •Ж.3.3.7. Реализация концепций
Г.4. Прикладные системы
Системы workflow инициируют работу приложения на уровне АБИ посредством команды CALL, избавляя пользователей от необходимости разбираться в тонкостях прикладной системы. Как только команда CALL активизирует обработку варианта (экземпляра) процесса, система workflow вызывает экран соответствующее приложение вместе с информацией, необходимой для данного процесса. Наряду с комментариями относительно используемых программ обработки эта информация содержит комментарии базы данных, хранящиеся в электронной папке событий.
Для управления программами при помощи системы workflow требуется достаточно высокая степень структурирования программных модулей. Кроме того, эти модули должны быть доступны извне для системы workflow.
Далее мы кратко обсудим различные возможности управления традиционными стандартными программами посредством процессов. Затем рассмотрим объектно-ориентированные методы, которые становятся все более актуальными и подводят к идее компонентного программного обеспечения. Принципы построения инфраструктуры, заложенные в концепции АБИ, позволяют получить информацию об архитектуре, а также многократно использовать программные компоненты.
Г.4.1. Традиционные стандартные программные решения
Традиционные стандартные программные решения для различных аспектов бизнеса представляют собой интегрированные прикладные системы, управляемые транзакциями. Нередко эти решения состоят из интегрированных программ и предполагают программное управление процессами, что не вполне вписывается в концепцию АБИ, где управление реализуется системами workflow.
Однако при условии разбивки прикладных систем на компоненты и при наличии у них интерфейса для вызова удаленных процедур (RPC) системы workflow могут инициировать выполнение этих программных модулей или транзакций. Например, SAP R/3 располагает интерфейсом для вызова удаленных функций (RFC). При применении независимых систем workflow для управления стандартными программами последние разделяются на функции обработки и поток управления, поступающий от workflow. Это означает, что производитель больше не отвечает за целостность решения. Для переноса этого гибкого метода на архитектуру стандартных программных решений в этих решениях используются специализированные системы workflow для управления процессами. К сожалению, такие системы workflow зачастую тесно связаны с конкретной системой и не подходят для решений, в основе которых лежат гетерогенные системы.
Эти модели позволяют конфигурировать стандартные программы при условии, что такие программы описаны семантическими моделями, связанными с репозиторием системы.
Рис. 50. Индивидуализация моделей-прототипов
С помощью перекрещивающихся линий можно убрать с экрана ненужные функции бизнес-процесса, предлагаемого прикладной системой. На рис. 50 схематически изображена процедура работы с моделями в системе SAP R/3. Сначала определяется модель-прототип соответствующей области бизнеса, (розничная торговля, банковское дело, промышленность и т. д.). В нашем примере мы взяли в качестве вертикального рынка «промышленность». В рамках решения для вертикального рынка выбираются конкретные бизнес-процессы. В нашем примере это производство, закупка и продажа. Для получения бизнес-процессов, специфических для данного клиента из данной области деятельности, из процессов, представленных в виде диаграмм EPC, удаляются ненужные функции и зависящие от них события. В процедуру правки заложены определенные правила, позволяющие проследить возможные комбинации и взаимозависимости в рамках осуществляемых бизнес-процессов. Например, отмена функции «хранение на складе» требует и удаления функции «выдача со склада».
Информация о вносимых изменениях передается непосредственно модулю управления конфигурацией системы.
Каждая бизнес-функция позволяет ввести дополнительные параметры. Например, функция «формирование заказа на поставку» может относиться к отделу отправки, стороннему поставщику, складу или отделу продаж. Очевидно, что такой заказ требует более подробной спецификации. Руководство по управлению реализацией (IMG) системы SAP R/3 содержит дополнительные компьютеризованные средства поддержки. Как и в моделях процессов, для конфигурирования стандартного программного обеспечения можно использовать другие типы моделей, такие как модели данных, функциональные и организационные модели. Можно, например, удалять информационные объекты из модели данных стандартной программы или, напротив, добавлять новые. Можно удалять атрибуты или изменять их длину. Эта информация также передается системе, которая автоматически изменяет настройку экранов.
Непосредственное взаимодействие между средствами моделирования, семантическими моделями и прикладной системой видоизменяет стратегию реализации стандартного ПО. Прежде было принято придерживаться жесткого разделения на фазы с применением анализа «как есть» для выявления слабых мест. Позже были разработаны целевые концепции, независимые от конкретного стандартного обеспечения, которые реализовывались с помощью методов индивидуальной настройки. В настоящее время разные фазы все чаще реализуются одновременно и во взаимодействии друг с другом, что открывает путь к тесному сотрудничеству между теми, кто непосредственно занимается бизнесом, и персоналом по внедрению системы, позволяя параллельно решать вопросы бизнеса и вопросы внедрения. Это иллюстрирует пример на рис. 51. Для наглядности все четыре окна показаны отдельно. В реальном приложении эти окна отображаются на одном экране, предоставляя пользователю всю информацию сразу.
В верхнем правом окне представлен фрагмент модели бизнес-процесса, выполненной с помощью ARIS Toolset, демонстрирующий часть процесса, которая должна быть удалена. Здесь же добавляется дополнительная ветвь процесса, отсутствующая в стандартной программе.
Функция «формирование запроса» запрашивает пользователя, какой экран используется в SAP R/3. В соответствии с моделью процесса щелкнув на этой функции (или выбрав команду), пользователь может, не углубляясь в тонкости, вызвать SAP R/3. Этот экран изображен внизу слева.
Для индивидуальной настройки этой функции вызывается инструмент настройки, содержащийся в Руководстве по управлению реализацией (IMG). В верхнем левом окне показаны доступные параметры функции.
С помощью инструмента моделирования результаты обсуждений, выбранные параметры, нерешенные вопросы и т. п. сохраняются в функции, как показано в нижнем правом окне. Это позволяет подробно документировать инжиниринг бизнес-процессов как с точки зрения самого бизнеса, так и с точки зрения ИТ. Такая документация впоследствии поможет разрешить проблемы, возникающие при использовании этого ноу-хау для мониторинга текущего проекта и для реализации последующих.
Поскольку сопровождение высокоинтегрированных систем и оперативное обновление руководств по обучению и документированию для всей системы требуют больших усилий, а производители обычно «неповоротливы» с разъяснением их политики по основным версиям, эти системы следует разбивать на более простые блоки (модули, компоненты, агенты, бизнес-объекты). Для компонентов такие алгоритмы вполне удовлетворительны. Кроме того, отсутствие жесткой связи между компонентами облегчает их сопровождение, а обновление их документации менее трудоемко.
Разбиение прикладных систем на модули — идея не новая. Модули предоставляют в распоряжение пользователей четко описанные интерфейсы, которые являются для них единственным средством обмена информацией. Пользователи не обременены деталями, связанными с реализацией модуля (эта информация от них «спрятана»).
Рис. 51. Интерактивное построение бизнес-процесса и настройка стандартной программы
И все же модульный принцип имеет один недостаток — во многих случаях он не допускает никаких вариаций. Внесение модификаций в какой-нибудь модуль для некоторых приложений немедленно требует изменений в программном коде. Иногда даже возникает необходимость в разных версиях. Это приводит к нагромождению модульных концепций и ограничивает возможность их многократного применения.
С другой стороны, объектно-ориентированные концепции описываются на уровне типов, что позволяет при внесении изменений создавать подтипы определенного типа объекта, устраняя необходимость изменять исходный тип объекта. Подтипы описывают лишь отклонение от исходного типа объекта. Это придает системе гибкость и повышает многократность использования спроектированных объектов.
Дробление монолитных прикладных систем на все более мелкие составные части прекрасно согласуется с расширяющимися возможностями объектно-ориентированных концепций. Это подводит нас к понятию «компонентного программного обеспечения», на котором, собственно и базируется внедрение реальных приложений.