
- •Министерство образования и науки рф
- •Учебное пособие
- •Оглавление
- •Введение
- •1. Процессный подход в менеджменте качества
- •Описание системы менеджмента качества
- •1.2. Акцент на процесс
- •1.3. Реинжиниринг бизнес-процессов
- •1.4. Непрерывное улучшение
- •1.5. Создание карты процесса
- •Структурный анализ процессов
- •Графики информационных потоков
- •Рекомендации для использования spa
- •Схемы алгоритмов
- •Максимизация использования spa
- •Управление изменениями
- •Контрольные вопросы
- •2. Процессный подход
- •2.1. Применимость процессного подхода
- •2.2. Основные понятия процессного подхода
- •Классификация процессов
- •2.3. Способы выделения процессов Процессы подразделений (внутрифункциональные процессы)
- •Сквозные (межфункциональные) процессы
- •Процессная или функциональная системы управления
- •Правила расчета размера и числа процессов
- •Комментарии к проекту сети процессов:
- •2.4. Управление процессами
- •Процесс управления организацией
- •Система показателей для управления процессами
- •Контрольные вопросы
- •3. Методологии описания бизнес-процессов
- •3.1.Формальная модель
- •Основные способы проектирования процессов
- •Применимость процессного подхода к разработке субп
- •Предпосылки создания sadt
- •Принципы функционального моделирования
- •Описание нотаций idef0, idef3
- •Диаграммы потоков данных
- •Методология idef1x
- •Определение сущностей и атрибутов
- •Логические взаимосвязи
- •Проверка адекватности логической модели
- •Модель данных, основанная на ключах
- •Выбор первичного ключа
- •Контрольные вопросы
- •4. Методолгия описания бизнес-процессов aris
- •4.1. Исходная модель бизнес-процесса
- •4.2. Объединенная модель бизнес-процесса
- •4.3. Обобщенная модель бизнес-процесса
- •4.4. Разработка архитектуры интегрированных информационных систем (здание aris)
- •4.5. Типы моделей в aris
- •4.5.1. Фазовая модель aris
- •4.5.2. Предварительная информационная модель aris
- •4.6. Управление бизнес-процессами на базе aris. Aris — архитектура бизнес-инжиниринга
- •4.7. Оценка процессов
- •4.8. Имитация
- •4.9. Обеспечение качества
- •4.10. Описание нотации aris eepc
- •Применение aris bsc 6.2 при построении карт стратегии компании
- •Построение карты целей (Cause-and-effect diagram)
- •4.11. Сравнение aris с другими концепциями
- •4.11.1. Объектно-ориентированное моделирование
- •4.11.2. Архитектура cimosa
- •4.11.3. Ifip — Методология информационных систем
- •Результаты исследований Санкт-Галленского университета, Швейцария
- •4.11.4. Другие архитектурные решения
- •Контрольные вопросы
- •5.1. Проблема сложности больших систем
- •5.2. Взаимосвязь структурного и объектно-ориентированного подходов
- •5.3. Средства uml
- •Диаграммы взаимодействия
- •Диаграммы последовательности
- •Кооперативные диаграммы
- •Сравнение диаграмм последовательности и кооперативных диаграмм
- •Двухэтапный подход к разработке диаграмм взаимодействия
- •5.4. Диаграммы классов Общие сведения
- •Стереотипы классов
- •5.5. Механизм пакетов
- •Атрибуты
- •Операции
- •5.6.Диаграммы состояний
- •5.6.Диаграммы деятельностей
- •5.7.Диаграммы компонентов
- •5.8.Диаграммы размещения
- •Контрольные вопросы
- •6. Статистические методы оценки эффективности бизнес-процессов
- •6.1 Контрольный листок
- •6.2. Гистограмма
- •Диаграмма разброса (рассеивания)
- •6.4. Метод стратисфакции (расслаивания данных)
- •Диаграмма парето
- •6.6. Причинно-следственная диаграмма (диаграмма исикавы)
- •6.7. Контрольные карты
- •Типы контрольных карт
- •6.8. Система проверки результативности бизнес-процессов
- •Этапы аудита
- •Роль аудитора
- •Контрольные вопросы
- •7. Методы измерения результативности бизнес-процессов
- •7.2. Методология функционально-стоимостного анализа abc (фса) с использованием программного продукта business studio
- •Контрольные вопросы
- •8. Практические приемы управления бизнес-процессами
- •8.1.Создание функциональной модели с помощью bpwin 4.0
- •8.1.1. Создание контекстной диаграммы
- •Методика выполнения
- •8.1.2. Создание диаграммы декомпозиции Методика выполнения
- •8.1.3. Создание диаграммы декомпозиции а2
- •Методика выполнения
- •8.1.4. Создание диаграммы узлов Методика выполнения
- •8.1.5. Создание feo диаграммы
- •Методика выполнения
- •8.1.6. Расщепление и слияние моделей Методика расщепления
- •Методика слияния
- •8.1.7. Создание диаграммы idef3 Методика выполнения
- •8.1.8. Создание сценария Методика выполнения
- •8.1.9. Дополнение моделей процессов диаграммами dfd
- •Пример выполнения работы
- •8.1.10. Стоимостный анализ (Activity Based Costing) Методика выполнения
- •Центры затрат abc
- •8.1.11. Использование категорий udp Методика выполнения
- •8.2. Моделирование с использованием методологии idef 1x Цель работы
- •Назначение пакета erWin
- •Основные приемы работы с пакетом erWin
- •Пример выполнения работы
- •Задание
- •8.3. Создание диаграмм описания бизнес-процессов в нотациях uml
- •8.3.1. Создание диаграммы вариантов использования
- •Порядок выполнения работы
- •8.3.2. Создание диаграмм взаимодействия
- •Порядок выполнения работы
- •8.3.3. Создание диаграммы классов
- •Порядок выполнения работы
- •8.3.4. Добавление атрибутов и операций
- •Порядок выполнения работы
- •8.3.5. Добавление связей
- •Порядок выполнения работы
- •8.3.6. Создание диаграммы состояний
- •Порядок выполнения работы
- •8.3.7. Создание диаграмм компонентов системы обработки заказов
- •Порядок выполнения работы
- •8.3.8. Создание диаграммы размещения
- •Порядок выполнения работы
- •Заключение
- •Библиографический список
- •Словарь терминов
- •Примечания
- •Примечание
- •Приложение 1 Методика проведения обследования бизнес-процессов компании
- •1.2.2.2. Составление отчета.
- •1.2.2.3. Подготовка положения о классификации бизнес-процессов.
- •1.2.2.4. Уточнение полученной информации о функционировании подразделений.
- •1.3.2.3. Документирование бизнес-процессов.
- •1.3.2.4. Уточнение зафиксированной последовательности выполнения бизнес-процессов.
- •1.3.3. Результат.
- •2. Моделирование.
- •2.1.1. Структурное моделирование.
- •2.1.2. Детальное моделирование бизнес-процессов.
- •Форма запроса данных об общей деятельности организации.
- •Структуры документов, содержащих результаты обследования
- •Приложение 2
- •Примеры заполнения чек листов.
4.11.2. Архитектура cimosa
В рамках программы ESPRIT, финансируемой Европейским Союзом (ЕС), осуществлено несколько исследовательских проектов по разработке архитектуры открытых систем (CIMOSA) для компьютеризованных систем управления производством (CIM). Первоначально в проекте CIMOSA участвовало 30 организаций, среди которых были производственники в качестве пользователей, разработчики ИТ и исследовательские институты. Хотя в прикладном отношении проект был ориентирован на системы CIM, его стратегическая задача заключалась в получении результатов для общего моделирования предприятий. Одной из целей CIMOSA была разработка архитектуры и методологии для создания систем, ориентированных на конкретного потребителя, путем «стыковки» стандартизованных модулей CIM независимо от их производителей (принцип «Plug and Play»).
Инфраструктура моделирования CIMOSA представляется в форме куба (рис. 4.33).
Архитектура CIMOSA — трехмерная. Каждое из трех измерений представлено одной из осей куба. На вертикальной оси («ступенчатая деривация») представлены три уровня описания фазовой концепции: определение требований, спецификация проекта и описание реализации. Эти уровни в значительной мере идентичны фазам жизненного цикла ARIS.
Горизонтальная ось («поэтапная конкретизация») описывает последовательную индивидуализацию понятий. На первом этапе определяются базовые требования (общие требования, стандартные блоки), которые на следующем, втором этапе конкретизируются с учетом специфики отрасли (частные требования), а на третьем этапе дифференцируются применительно к специфике предприятия (конкретные требования).
Рис. 4.33. Архитектура моделирования CIMOSA (куб CIMOSA)
Эта «проекция» наглядно показывает, что, согласно концепции CIMOSA, общие стандартные блоки следует использовать для определения стандартов, после чего блоки группируются в модели-прототипы для конкретных отраслей. На последнем этапе они используются для выработки решений, предназначенных для конкретных организаций. В инфраструктуре ARIS степень детализации информационной модели определяется при решении вопросов структурирования.
Непосредственно введение моделей-прототипов, связанных с содержанием, наглядно свидетельствует о том, что архитектура CIMOSA сочетает общие положения методологии информационных систем с прикладными областями CIM.
Третья ось («поэтапная генерация») описывает различные типы моделей информационной системы. Цели этой «проекции» аналогичны целям ARIS: речь здесь тоже идет о создании типов описаний, хотя результаты не во всем тождественны. В архитектуре CIMOSA типы описания подразделяются на «модель функций», «информационную модель», «модель ресурсов» и «организационную модель». «Модель функций» представляет собой описание событий, хотя она также охватывает другие элементы, такие как события и процессы, включая выполнение и обработку исключений. «Информационная модель» относится к представлению данных или описанию объектов. «Модель ресурсов» описывает ИТ и производственные ресурсы, а «организационная модель» — организационную иерархию.
В архитектуре CIMOSA все содержание также разбивается на различные типы представлений, но здесь, в отличие от ARIS, где имеются модели управления и модели процессов, отсутствует их уровень. В результате в CIMOSA описания разных типов комбинируются друг с другом. Например, при описании ресурсов одновременно выполняется их привязка к функциям. В концепции моделирования CIMOSA не предусмотрена модель выходов.
Концепция CIMOSA предоставляет адекватную архитектуру для описания информационных систем, которую можно наполнять содержанием в виде стандартизованных моделей-прототипов на протяжении всего процесса создания реального программного обеспечения. Несмотря на упомянутые выше недостатки, у нее есть и важные достоинства. Концепция CIMOSA позволяет классифицировать методы моделирования и описывать их метамоделями, не отступая при этом от событийной модели, ориентированной на бизнес-процессы. Более того, она рассматривает предприятия как серию взаимодействующих друг с другом агентов.
Несмотря на внушительные затраты финансовых и интеллектуальных ресурсов, практическая отдача CIMOSA пока минимальна. Судя по сообщениям пользователей из реального бизнеса, участвующих в проекте, число специальных приложений, разработанных при помощи этой архитектуры, еще крайне незначительно. Исключение составляют автомобильная компания Renault, внедрившая прикладную систему для ремонтного обслуживания производственных установок, и компания TRAUB AG, внедрившая прикладную систему для оптимизации индивидуальной разработки инструментов. На сегодняшний день инструментальные средства моделирования на базе CIMOSA не нашли широкого практического применения.
Главная причина отсутствия успеха в сфере практической реализации, вероятно, кроется в излишне теоретизированной платформе, которая не охватывает уже имеющиеся коммерческие ИТ-решения (например, стандартное программное обеспечение). Довольно слабый интерес к концепциям CIM, похоже, можно объяснить тем, что предельно узкая направленность этого подхода идет ему во вред.