- •А. Г. Зуева, б. В. Носков, е. В. Сидоренко, е. И. Всяких, с. П. Киселев Практика и проблематика моделирования бизнес-процессов Введение
- •Глава 1 Зачем нужна модель бизнес-архитектуры: стандартные постановки задач по моделированию бизнес-процессов
- •Глава 2 Что такое модель бизнес-процессов. Типовая архитектура модели бизнес-процессов
- •Контекст и основные элементы бизнес-архитектуры
- •Структура организационной компоненты
- •Структура информационной компоненты
- •Организация компоненты «Приложения»
- •Базовые принципы, методы и определения моделирования бизнес-процессов
- •Определение моделирования
- •Типология моделей
- •Общие принципы моделирования
- •Базовые определения по архитектуре
- •Объектный анализ
- •Процессный анализ Понятие процесса
- •Компоненты процесса
- •Анализ процесса
- •Анализ топологии процесса
- •Анализ характеристик процесса
- •Анализ ошибок процесса
- •Анализ динамики процессов
- •Анализ рисков процесса
- •Анализ ресурсного окружения процессов
- •Анализ возможностей стандартизации процесса (создание эталонных, референтных моделей)
- •Основные методики моделирования
- •Idef-технологии
- •Глава 3 Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке Общий подход к проектированию
- •Определение параметров вариативности модели и ее реализации
- •Анализ и оптимизация моделей
- •Этапность создания модели Общие рекомендации
- •Построение информационной модели
- •Построение организационной модели
- •Построение функциональной модели
- •Построение модели выходов (результатов)
- •Построение модели управления
- •Разработка прикладных приложений для работы с моделями
- •Разработка Соглашения о моделировании
- •Основные этапы по проектированию
- •Проектирование моделей «как должно быть» и gap-анализ
- •Плюсы и минусы различных подходов к разработке бизнес-архитектуры
- •Глава 4 Современные инструментальные средства моделирования бизнес-процессов. Как выбирать инструментальную среду для бизнес-моделирования
- •Выбор инструментальных средств моделирования и методов
- •Глава 5 Организация проекта по моделированию бизнес-архитектуры организации: этапность, участники, роли, взаимодействия
- •Глава 6 Модель построена, что дальше? Масштабное внедрение и поддержка бизнес-модели
- •Глава 7 Чего нужно опасаться при моделировании бизнес-процессов. Проектные риски моделирования бизнеспроцессов
- •Глава 8 Моделирование бизнес-процессов в среде aris – иллюстрация частных решений и подходов
- •Прикладной функционал
- •Цветовое выделение «маршрута» на фоне общей модели
- •Сохранение маршрута модели в виде отдельной модели, связанной с общей базой модели бизнес-архитектуры
- •Группа прикладных функций аналитической обработки «маршрута» Технологическая карта
- •Должностная инструкция
- •Специализированные алгоритмы анализа (временного, стоимостного) бизнес-процесса с учетом влияния человеческих и технических ресурсов
- •Общесистемный функционал
- •Решения по визуализации и настройкам
- •Проектные решения
- •Тестирование
- •Интеграционные решения
- •Заключение
- •1. Введение
- •4. Ожидаемый эффект
- •5. Требования к разработке
- •5.1. Общие требования
- •5.2. Функциональные требования
- •5.3. Общие требования к разработке модели и формализованному описанию процессов
- •5.4. Требования к информационному обеспечению процессов
- •5.5. Требования к организационному обеспечению
- •5.6. Требования к нормативно-законодательному обеспечению
- •5.7. Требования к интеграции
- •5.8. Требования по обеспечению непрерывности рабочих процессов
- •6. Требования к составу работ
- •7. Требования к отчетным материалам
- •Приложение 4
- •2. Общие положения
- •3. Организация хранения моделей в базе aris
- •4. Синтаксические и семантические правила создания моделей
- •Приложение 5
- •Литература
- •Сокращения
Общие принципы моделирования
Перед тем как дать описание основных используемых на сегодняшний день методов моделирования, укажем общие принципы и особенности, которые должны быть учтены при построении модели.
1. Принцип осуществимости. Создаваемая модель прежде всего должна обеспечивать достижение поставленных целей. Таким образом, прежде чем приступить к сбору информации об объекте, нужно четко определить границы области моделирования, цели и количественные показатели их достижения; «моделирование ради моделирования» обычно создает негативное отношение к проекту в компании, снижает лояльность руководства.
2. Принцип информационной достаточности. При полном отсутствии информации об исследуемом объекте построение его модели невозможно. При наличии полной информации моделирование не имеет смысла. Существует некий критический уровень априорных сведений об объекте, при достижении которого имеет смысл переходить от этапа сбора информации к этапу собственно построения модели.
В данном случае закладываются условия для выполнения такого значимого требования, как адекватность модели, а именно достижение разумного баланса между детальностью и потребительскими качествами модели.
3. Принцип множественности модели. Создаваемая модель должна отражать те свойства реального объекта, которые влияют на выбранные показатели эффективности. При использовании любой конкретной модели познаются только некоторые области действительности. Для более полного исследования реального объекта необходим ряд моделей, позволяющих с разных сторон и с разной детализацией отражать рассматриваемый процесс.
4. Принцип агрегирования. В большинстве случаев сложную систему можно представить в виде совокупности агрегатов (подсистем), для адекватного описания которых оказываются пригодными некоторые стандартные схемы. Имея хорошо структурированные, относительно независимые блоки нижнего уровня, появляется возможность довольно гибко перестраивать модель в зависимости от меняющихся по ходу проекта требований, предлагать на выбор лицу, принимающему решение, различные варианты построения модели, лишь перегруппируя подсистемы и изменяя взаимосвязи между ними.
5. Принцип отделения. Исследуемая область, как правило, имеет в своем составе несколько изолированных компонент, внутренняя структура которых достаточно прозрачна или не представляет непосредственного интереса для целей проекта, в таком случае ее место в модели занимает условный пустой блок, для которого определяются только значимые входные и выходные информационные потоки.
Этот прием используется при определении границ области моделирования и при расстановке приоритетов внутри нее, он позволяет сократить объем и продолжительность моделирования, однако может негативно сказаться на адекватности модели.
Базовые определения по архитектуре
В качестве общих элементов определений, связанных с архитектурой, можно использовать следующий перечень [7]:
♦ архитектура определяет основные компоненты (бизнес-архитектура, архитектура приложений и т. д.);
♦ архитектура определяет взаимосвязи между компонентами и взаимодействия между ними;
♦ уровень детализации архитектуры выбирается таким, что «опускается» вся информация о компонентах, которая не имеет значения вне вопросов взаимодействия с остальными компонентами архитектуры;
♦ поведение компонент является частью архитектуры настолько, насколько это важно с точки зрения взаимодействия с другими компонентами;
♦ каждая система имеет архитектуру, даже система, которая состоит из одной компоненты;
♦ архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;
♦ определения архитектуры не содержат описания самих компонент.
Приведенные в вышеуказанном источнике примеры общих принципов, связанных с архитектурой в целом, также могут быть взяты за основу при осуществлении проектирования и использовании модели бизнес-архитектуры:
♦ все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для организации (правительства) в целом;
♦ архитектура должна обеспечивать решение вопросов бесперебойного выполнения организациями своих функций, безопасности и восстановления в случае катастрофических событий;
♦ функциональные (бизнес-) требования должны формировать архитектуру;
♦ архитектура должна обеспечивать совместимость и взаимодействие;
♦ архитектура должна быть расширяемой, масштабируемой и адаптивной;
♦ архитектура должна быть инструментом реализации изменений;
♦ архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов;
♦ тенденции рынка должны учитываться при проектировании технологической архитектуры.
