Проектирование и внедрение процессов по категориям

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

  graph TD
    classDef high fill:#ffebee,stroke:#e53935,stroke-width:2px
    classDef standard fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
    classDef result fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px

    subgraph "Высокозначимые процессы ≈20%"
        H1[Инновационный подход] --> HR1[Оптимизация на основе факторов роста ценности]
        H2[Сложные методы моделирования] --> HR2[Имитационное моделирование анимация]
        H3[Проектирование от продукции и рынков] --> HR3[Интегрированные продуктовые предложения]
        H4[Прозрачность процесса] --> HR4[Модель как источник инноваций]
    end

    subgraph "Стандартные процессы ≈80%"
        S1[Референтные модели] --> SR1[Отраслевые стандарты]
        S2[Минимальная адаптация] --> SR2["Только при необходимости<br/>(законодательство, специфика)"]
        S3[Традиционные методы] --> SR3[Бережливое производство,<br/>шесть сигм]
        S4[Следование стандарту] --> SR4[Нет смысла делать лучше<br/>среднего по отрасли]
    end

    class H1,H2,H3,H4 high
    class S1,S2,S3,S4 standard

Сравнительная таблица подходов к проектированию#

Проектирование от продукции и рынков (Product/Market Design) — это подход, который увязывает процессы и факторы роста ценности с ценностным предложением, соответствующим ожиданиям потребителя.

Суть подхода:#

  graph LR
    classDef step fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef result fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    S1[Продукт/услуга<br/>для клиента] --> S2[Ценностное<br/>предложение]
    S2 --> S3[Факторы роста<br/>ценности]
    S3 --> S4[Бизнес-процессы,<br/>создающие ценность]
    S4 --> S5[Интегрированные<br/>продуктовые предложения]

    class S1,S2,S3,S4,S5 step

Когда применяется:#

Как выявить стратегические высокозначимые процессы:#

  graph TD
    classDef step fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef result fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    S1["Все высокозначимые процессы (≈20%)"] --> S2[Дополнительная<br/>классификация]
    S2 --> S3{Стратегический<br/>или нестратегический?}
    S3 -->|Стратегический| S4["Требуют проектирования от продукции и рынков (≈5%)"]
    S3 -->|Нестратегический| S5[Достаточно инновационной<br/>оптимизации без полного<br/>перепроектирования]

    class S1,S2,S3,S4,S5 step

Ключевой принцип: основное внимание должно уделяться высокозначимым стратегическим процессам . Это те процессы, которые создают реальное конкурентное преимущество.

Новые технологии, в частности информационные технологии, должны оцениваться исходя из тех же факторов роста ценности.

Процесс оценки технологий:#

  graph TD
    classDef step fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef criteria fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef decision fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    subgraph "Оценка технологий для высокозначимых процессов"
        S1[Моделирование нескольких<br/>сценариев процесса]
        S2[Различная глубина<br/>автоматизации]

        C1[Ожидаемые значения<br/>KPI] --> D[Выбор оптимального<br/>варианта]
        C2[Требуемые инвестиции<br/>на внедрение] --> D
        C3[Технологическая<br/>сложность] --> D
    end

    class S1,S2 step
    class C1,C2,C3 criteria
    class D decision

Критерии оценки:#

Методы поиска лучшего решения:#

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

Референтные модели — это готовые процессные модели, отражающие общепринятые отраслевые практики. Они служат отправной точкой для проектирования стандартных процессов.

Источники референтных моделей:#

  graph TD
    classDef source fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef benefit fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    subgraph "Источники референтных моделей"
        S1[Отраслевые<br/>организации] --> B1[Проверенные<br/>практики]
        S2[Консалтинговые<br/>компании] --> B2[Готовые<br/>методологии]
        S3["ИТ-компании (ERP, SCM, CRM)"] --> B3[Встроенные модели,<br/>отраслевые настройки]
    end

    class S1,S2,S3 source
    class B1,B2,B3 benefit

Процесс проектирования стандартных процессов:#

  graph LR
    classDef step fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef adapt fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef result fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    S1[Выбор референтной<br/>модели] --> S2[Сравнение с текущим<br/>процессом]
    S2 --> S3{Необходима<br/>адаптация?}
    S3 -->|Да| S4[Адаптация только<br/>при необходимости]
    S3 -->|Нет| S5[Реализация<br/>отраслевого стандарта]
    S4 --> S5
    S5 --> S6[Внедрение как<br/>типовое решение]

    class S1,S2,S5,S6 step
    class S3,S4 adapt

Когда требуется адаптация:#

Ключевой принцип: даже при необходимости адаптации следует стремиться максимально следовать отраслевому стандарту.

Традиционные методы оптимизации:#

Для стандартных процессов допустимо применение:

Важно: стремиться сделать стандартные процессы лучше, чем средние показатели по отрасли, обычно не имеет смысла. Это требует ресурсов, которые лучше направить на высокозначимые процессы.

Подход к автоматизации должен соответствовать категории процесса.

Автоматизация высокозначимых процессов:#

  graph TD
    classDef aspect fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef solution fill:#fff3e0,stroke:#e65100,stroke-width:2px

    subgraph "Автоматизация высокозначимых процессов"
        A1[Специфические<br/>для организации] --> S1[Разработка конкретных<br/>прикладных модулей]
        A2[Исполнение людьми<br/>с передовыми<br/>технологиями] --> S2[BPMS для управления<br/>потоками работ]
        A3[Требуют управления<br/>изменениями] --> S3[Обучение, коммуникации<br/>вовлечение]
        A4[Связь со стратегией<br/>через KPI] --> S4[Модели с KPI и факторами<br/>роста ценности]
    end

    class A1,A2,A3,A4 aspect
    class S1,S2,S3,S4 solution

Автоматизация стандартных процессов:#

  graph TD
    classDef aspect fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
    classDef solution fill:#fff3e0,stroke:#e65100,stroke-width:2px

    subgraph "Автоматизация стандартных процессов"
        A1[Типовые<br/>для отрасли] --> S1["Коробочные продукты (ERP, SCM, CRM)"]
        A2[Референтные<br/>модели] --> S2[Входящие в состав ПО,<br/>отраслевые настройки]
        A3[Статическая<br/>архитектура] --> S3[Конфигурирование<br/>из предопределённых<br/>вариантов]
        A4[Минимальные<br/>затраты] --> S4[Использование готовых<br/>решений и интерфейсов]
    end

    class A1,A2,A3,A4 aspect
    class S1,S2,S3,S4 solution

Сравнительная таблица подходов к автоматизации:#

Сервис-ориентированная архитектура (SOA — Service-Oriented Architecture) — это подход к автоматизации, в котором функциональное программное обеспечение и логика процесса (потока работ) отделены друг от друга.

Схема SOA:#

  graph LR
    classDef process fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef service fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef integration fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    subgraph "Сервис-ориентированная архитектура (SOA)"
        P[Модели процессов<br/>Логика потока работ] --> I["Среда интеграции приложений (EAI)"]
        S[Программные сервисы<br/>Функциональность] --> I
        I --> R[Автоматизированный<br/>процесс]
    end

    class P process
    class S service
    class I integration

Преимущества SOA:#

Недостатки SOA:#

Использование SOA в BPM:#

  graph TD
    classDef use fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef result fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    subgraph "Использование SOA в BPM"
        U1[Модели процессов →<br/>программирование потоков работ] --> R1[Управление маршрутами<br/>и эскалациями]
        U2[Модели процессов →<br/>разработка сервисов] --> R2[Дополнение готовых<br/>библиотек]
        U3[Референтные модели<br/>в составе ПО] --> R3[Начальное приближение<br/>для проектирования]
    end

    class U1,U2,U3 use
    class R1,R2,R3 result

Взаимодействие с процессными моделями:#

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

Модель процессов, показывающая, как интегрированы различные её компоненты, является залогом эффективного использования этих инструментов.

Одна из важнейших составляющих внедрения процесса — подготовка вовлечённых в него людей к работе в новой среде.

Роль моделей процессов в управлении изменениями:#

  graph TD
    classDef role fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef activity fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef result fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    subgraph "Модели процессов в управлении изменениями"
        R1[Информирование] --> A1[Что меняется и почему]
        R2[Коммуникации] --> A2[Как изменения влияют<br/>на работу каждого]
        R3[Обучение] --> A3[Как работать<br/>в новой среде]
    end

    A1 --> R[Успешное внедрение]
    A2 --> R
    A3 --> R

    class R1,R2,R3 role
    class A1,A2,A3 activity
    class R result

Связь с категорией процесса:#

Методологии внедрения:#

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

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

Роль бизнес-архитектора:#

  graph TD
    classDef role fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    classDef action fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef result fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    subgraph "Задачи бизнес-архитектора"
        R1[Обеспечить соответствие<br/>бизнес-процессов<br/>бизнес-способностям] --> A1[Понимание текущих<br/>возможностей]
        R2[Обеспечить соответствие<br/>направлений эволюции<br/>стратегии] --> A2[Определение будущих<br/>способностей]
        R3[Определить необходимые<br/>изменения и сроки] --> A3[Дорожная карта<br/>трансформации]
    end

    A1 --> R[Связь стратегии<br/>и процессов]
    A2 --> R
    A3 --> R

    class R1,R2,R3 role
    class A1,A2,A3 action
    class R result

Связь бизнес-способностей и процессов:#

  graph TD
    classDef level fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px

    subgraph "Иерархия связей"
        S[Стратегия] --> C["Бизнес-способности (Capabilities)"]
        C --> F[Бизнес-функции]
        F --> P[Подпроцессы]
        P --> PR[Процессы]
    end

    class S,C,F,P,PR level

Как работает связь:#

1. Бизнес-способности связаны с бизнес-функциями
2. Бизнес-функции образуют подпроцессы
3. Подпроцессы связаны с процессами

Ключевой вывод: бизнес-функции собираются из множества подпроцессов и содержат части множества процессов. Из-за этих взаимозависимостей процесс часто поддерживается несколькими бизнес-функциями.

Применение в трансформации:#

Декомпозиция бизнес-способности позволяет:

1. Выявить, как необходимо изменить подпроцессы
2. Через подпроцессы — как изменить процессы
3. Обеспечить реализацию стратегии

Эта связь стратегии с процессной трансформацией, а трансформации — с бизнес-способностями отражается в информационной системе и её способности поддерживать стратегию и развиваться вместе со стратегией.