- •Профессор Шеер
- •Издание второе Содержание
- •Предисловие к русскому изданию
- •Предисловие ко второму изданию
- •Об этой книге
- •Классификация содержания
- •А. Преимущества 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.2.2. Бизнес-объекты
Степень структурирования в рамках объектно-ориентированных концепций (и как следствие программирования) для разработки «стиля сборки» программного обеспечения дает слишком мелкие объекты. Для этой цели требуются логические блоки «покрупнее». Например, объектно-ориентированная концепция UML предлагает использование так называемых «пакетов», описывающих более крупные объекты в соответствии с их прикладной функцией. Такой тип представления, рассчитанный на приложение, легче понять, если обозначить его как «бизнес-объект». Бизнес-объекты включают бизнес-процессы вместе с соответствующими данными и функциями, выполняемыми для их обработки. Таким образом, бизнес-объекты содержат несколько объектно-ориентированных объектов, о которых говорилось выше. Их характеристики, такие как инкапсуляция, многократное использование (благодаря наследованию) и нежесткая связь (построенная на обмене сообщений), вытекают из объектно-ориентированной концепции.
Пример обработки заказа, приведенный на рис. 52, содержит три бизнес-объекта: «прием заказа», «заказ на поставку» и «изготовление». На рис. 53 эти бизнес-объекты представлены через их характеристики. Интерфейсы различных объектов, активизируемых извне, «проходят через» бизнес-объекты и обозначаются точками вдоль внешних границ объектов. Однако интерфейсы, используемые только в рамках бизнес-объекта, остаются в пределах внутренних объектов. Бизнес-объекты не предполагают заранее заданную степень структурирования. Степень структурирования выбирается исходя из здравого смысла с ориентацией на рабочие единицы приложения, например на то, как тесно связаны их содержание и организационная структура, насколько прочны внутренние связи (и насколько слабы внешние). При выборе ее учитывается также возможность многократного использования бизнес-объектов и их эффективности.
Бизнес-объекты не обязательно должны создаваться из индивидуальных, жестко объектно-ориентированных объектов. Когда существующая система разбита по принципу «сверху-вниз», их можно формировать из обычных программных компонентов. Главным условием при этом является соответствие бизнес-объекта объектно-ориентированным принципам, как это реализовано, например, в SAP R/3. На сегодняшний день SAP предоставляет 170 бизнес-объектов, хранящихся в репозитории бизнес-объектов (BOR). Их внутренняя структура описана на языке АВАР 4GL, который (пока) не является объектно-ориентированным.
Г.4.2.3. Java-аплеты
Компонентное программное обеспечение поддерживается и программными концепциями, где используются простейшие аппаратные клиенты — так называемые сетевые компьютеры. Приложения хранятся в сети (Интернете или интрасетях) и запускаются клиентом по мере надобности. В этом отношении функциональные возможности Java представляют особую ценность. Благодаря использованию в качестве пользовательских интерфейсов Java-аплетов и популярных Web-браузеров стала реальна платформно-независимая обработка.
Для создания Java-аплета разрабатывается исходный код в среде разработки Java в любой системе. Затем законченная программа — так называемый байт-код — компилируется в среде разработки, а не в исполняемой программе. Байт-код не зависит от платформы, и чтобы обеспечить его соответствие техническим требованиям клиентской системы, перед исполнением его необходимо еще раз интерпретировать. Это осуществляется при помощи виртуальной машины Java (JVM) после загрузки. JVM адаптирует байт-код к различным клиентским требованиям.
Язык Java можно использовать на трех уровнях. Команды могут вводиться прямо в текст HTML-страницы как исходный код JavaScript. Этот код команд лишь отчасти идентичен Java, хотя оба языка основаны на C++. Однако JavaScript позволяет реализовать лишь небольшие приложения, например, для проверки значений или отображения «шапки» в строке состояния браузера. Кроме того, JavaScript не способен обеспечить осуществлять прямую связь между клиентом и сервером.
Далее байт-код аплета передается клиенту в дополнение к загружаемой HTML-странице. Переданный байт-код проверяется и интерпретируется на клиенте, после чего аплет выполняется. Аплеты запускаются только в среде браузера, без него их исполнение невозможно. Однако в рамках аплетов может происходить дальнейшее общение между сервером и клиентом. Аплеты способны загружать документы с сервера и обрабатывать их до того, как они будут отправлены обратно на сервер для завершения процесса. Приложения могут выполняться независимо от среды браузера. Все, что им нужно — это виртуальная машина Java для передачи байт-кода. Приложения позволяют разрабатывать независимые приложения, конструктивные блоки которых по мере необходимости загружаются на клиентский компьютер через сеть. Как аплеты, так и приложения поддерживают компонентное ПО. Установка и сопровождение ненужных модулей не требуются. Системы собираются индивидуально в соответствии со спецификациями заказчика.
Эту концепцию можно включить в инфраструктуру АБИ (см. рис. 54). Процессы, управляемые на уровне III системой workflow, описываются на уровне моделирования. Приложения на уровне IV могут быть доступны в виде байт-кода на серверах глобально распределенных приложений. При открытии папки для обработки какого-либо события система workflow создает Web-страницу, соответствующую данному этапу обработки. Эта Web-страница запускает аплет и вызывает сервер приложений. Подключившись к аплету, пользователи выполняют необходимые функции, после чего данные возвращаются и передаются системе workflow.
Данные включают также информацию о времени и продолжительности процесса, которая агрегируется с помощью системы workflow и возвращается для управления процессами. Этот процесс поддерживает любую операционную систему и аппаратную платформу. Нужные для обработки аплеты, включая обрабатываемый объект, загружаются через пользовательский интерфейс браузера. Пользователи могут выполнять функции децентрализовано. Клиенты имеют непосредственный доступ к любому методу. После обработки преобразованные объекты возвращаются на сервер, который передает их на дальнейшую обработку.
В процессе обработки событий серверы workflow постоянно контролируют запуск любых других серверов и обработку данных. Супервизоры могут запрашивать информацию о времени и продолжительности процесса, а также о состоянии процесса в любой момент, хотя доступ к объектам во время их обработки невозможен.