Process Management (Немецкая школа процессного управления)

Немецкая школа процессного управления (Geschäftsprozessmanagement) — систематический подход к моделированию, анализу и оптимизации бизнес-процессов, наиболее известный через концепцию ARIS (Architecture of Integrated Information Systems, «Архитектура интегрированных информационных систем») профессора Аугуста-Вильгельма Шеера. В отличие от более общих подходов к процессному управлению, немецкая школа делает акцент на строгой формализации процессов через многослойное моделирование, напрямую связывающее бизнес-процессы с реализующими их информационными системами.

Что такое немецкая школа процессного управления и когда она нужна

ARIS-подход нужен там, где процессная модель должна быть не просто понятной картинкой для обсуждения, а прямой основой для конфигурации ИТ-системы — прежде всего в крупных организациях с ERP-системами (исторически и по сей день чаще всего SAP), где расхождение между «как процесс описан» и «как он реализован в системе» стоит дорого. Это принципиально отличает немецкую школу от лёгких инструментов картирования вроде SIPOC, которые дают быстрый обзорный взгляд на процесс, но не претендуют на прямую связь с конфигурацией системы, и от Lean Six Sigma, сфокусированного на статистическом устранении дефектов и потерь, а не на архитектурной связке «модель — система». ARIS выбирают не вместо этих инструментов, а тогда, когда нужна именно архитектурная строгость и прослеживаемость от модели до кода.

Происхождение и исследовательская база

Аугуст-Вильгельм Шеер — немецкий профессор делового администрирования и информационных систем в университете Саара, защитил докторскую диссертацию в Гамбургском университете в 1972 году и хабилитацию там же в 1974 году по теме контроля проектов. В 1975 году Шеер занял одну из первых кафедр информационных систем и основал институт информационных систем (IWi) при университете Саара, которым руководил до 2005 года.

В 1984 году Шеер основал компанию IDS Scheer — разработчика программного обеспечения для управления бизнес-процессами (BPM), которую широко считают основателем самой индустрии BPM как таковой. Разработанный им метод ARIS для процессов и ИТ используется практически во всех компаниях, входящих в немецкий фондовый индекс DAX, а также во многих средних предприятиях и на международном уровне — его книги признаны стандартными работами по немецкому процессному управлению. Ключевой практический элемент методологии — нотация событийных цепочек процессов (Ereignisgesteuerte Prozesskette, EPC) — разработана в 1992 году Герхардом Келлером, Маркусом Нюттгенсом и самим Шеером в Саарском университете именно как исследовательский проект СОВМЕСТНО с SAP для полуформального описания бизнес-процессов при внедрении SAP R/3. Это не случайное партнёрство постфактум: связь модели процесса с ИТ-системой заложена в методологию буквально с момента её создания, а не добавлена позже как опция. SAP использовала и продолжает использовать EPC-диаграммы для документирования собственных эталонных процессов R/3 — прямое историческое подтверждение принципа «модель как основа системы», а не абстрактная декларация.

Ключевая особенность подхода ARIS — многослойное моделирование процесса одновременно в нескольких взаимосвязанных представлениях (организационном, функциональном, информационном, процессном), что позволяет напрямую связать описание бизнес-процесса с последующей реализацией в конкретной информационной системе, а не оставлять этот переход неформализованным.

Формально «дом ARIS» (ARIS-Haus), представленный Шеером в его основополагающей работе 1992 года, организует все элементы предприятия в пять взаимосвязанных видов: организационный (кто выполняет), функциональный (что делается), данные (какая информация обрабатывается), выходной/продуктовый (что производится) и — в вершине дома — процессный (управляющий), объединяющий первые четыре вида в связную динамическую последовательность через EPC-диаграммы. По масштабу претензий «дом ARIS» ближе не к отдельным техникам картирования процесса, а к полноценным фреймворкам корпоративной архитектуры вроде TOGAF — оба описывают предприятие на нескольких взаимосвязанных архитектурных уровнях, а не только процесс сам по себе.

Ключевые идеи и принципы

1. Принцип: многослойное моделирование процесса вместо единой упрощённой диаграммы.

   Вместо одной обобщённой блок-схемы процесса, ARIS-подход явно разделяет разные аспекты — кто выполняет процесс (организационная структура), что делается (функции), какие данные обрабатываются (информационная структура) и в каком порядке это происходит (управление процессом) — что даёт значительно более детальную и практически применимую модель для последующей реализации в информационных системах.

2. Принцип: прямая связь между моделью процесса и реализующей его ИТ-системой.

   Немецкая школа процессного управления исторически сильно ориентирована на практическую реализуемость — модель процесса создаётся не как абстрактная документация, а как основа для непосредственной конфигурации или разработки поддерживающей информационной системы, что сокращает разрыв между документацией процесса и его реальным ИТ-воплощением.

3. Принцип: систематическая методология применима в масштабе крупной организации.

   Широкое распространение метода в компаниях индекса DAX подтверждает применимость подхода не только к отдельным процессам, но и к масштабной, комплексной архитектуре процессов и систем крупного предприятия — систематичность и строгость формализации особенно ценны именно на таком масштабе, где неформальное описание процессов быстро становится неуправляемым. Это прямое следствие происхождения метода: EPC разрабатывалась не как учебная нотация, а как рабочий язык описания процессов реальной ERP-системы промышленного масштаба (SAP R/3), что с самого начала задало требование выдерживать сложность, типичную для крупного предприятия, а не только для отдельного упрощённого примера из учебника.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: применяют полную многослойную формализацию к простым, некритичным процессам.

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

   Как избежать

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

2. Ошибка 2: не синхронизируют модель процесса с фактическими изменениями в ИТ-системе.

   Информационная система, реализующая процесс, изменяется без соответствующего обновления модели процесса — со временем модель перестаёт отражать реальность, теряя ключевое преимущество прямой связи модели и реализации.

   Как избежать

   встраивать обновление модели процесса как обязательный шаг любого изменения поддерживающей информационной системы.

3. Ошибка 3: рассматривают выбор методологии в отрыве от привязки к конкретному инструментарию.

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

   Как избежать

   явно оценивать долгосрочные последствия зависимости от конкретного коммерческого инструментария при выборе методологии процессного моделирования.

4. Ошибка 4: связь модели с ИТ-системой считается автоматической, а не проектируется явно.

   Команда предполагает, что раз EPC исторически связана с SAP, любая нарисованная модель «сама собой» превратится в конфигурацию системы — на деле связь требует явного проектирования маппинга элементов модели на объекты системы (как это описано в официальной методике ARIS for SAP Solutions).

   Как избежать

   явно проектировать и документировать маппинг между элементами модели ARIS и объектами конфигурации целевой ИТ-системы, а не полагаться на историческую связь методологий по умолчанию.

5. Ошибка 5: организационный, функциональный и информационный виды моделируются несогласованно друг с другом.

   Разные слои «дома ARIS» создаются разными людьми в разное время без сверки — например, функциональная модель ссылается на роли, отсутствующие в организационной модели, что делает итоговую процессную (EPC) модель формально некорректной.

   Как избежать

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

Как измерить эффект

• Доля процессных моделей, синхронизированных с текущей конфигурацией ИТ-системы: снижение расхождения между «как задокументировано» и «как реально работает система» — прямой индикатор того, что ключевое преимущество метода не потеряно со временем.

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

• Согласованность видов модели: доля элементов функционального и информационного видов, у которых есть явное соответствие в организационном виде (роли, ответственные) — отсутствие несогласованных «повисших» ссылок.

• Время от изменения бизнес-требования до отражения в модели и системе: сокращение этого цикла говорит о реально работающей связке модель-система, а не только задекларированной.

План внедрения

1. Неделя 1: выбрать комплексный критичный процесс для детального моделирования

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

2. Неделя 2: смоделировать организационный и функциональный слои процесса

   Описать, кто выполняет процесс (организационная структура) и какие функции выполняются (функциональная модель).

3. Неделя 3: смоделировать информационный слой и последовательность выполнения

   Описать, какие данные обрабатываются и в каком порядке выполняются шаги процесса.

4. Неделя 4: связать модель с реализующей информационной системой

   Использовать построенную модель как основу для конфигурации или разработки поддерживающей ИТ-системы.

   Далее: синхронное обновление — при любом изменении ИТ-системы обновлять соответствующую модель процесса, поддерживая их соответствие.

Как реализовать этот план с помощью фрейма «Process Management (ARIS)» в OrgDevTools

Фрейм проводит вас по плану внедрения: выбрать процесс, разложить его по слоям, привязать к ИТ-системе и следить, чтобы модель не отставала от системы. Это бесплатный тренажёр. Часть расчётов фрейм делает сам: баллы кандидатов, полноту слоёв и долю синхронизированных изменений. На вкладке «Итоги» он выдаёт вердикт. Заранее заполненных данных нет, все таблицы и списки стартуют пустыми.

Книги по теме

Аугуст-Вильгельм Шеер — «ARIS — от бизнес-процесса к прикладной системе» (ARIS — Vom Geschäftsprozess zum Anwendungssystem). Первоисточник методологии ARIS от её создателя.

Аугуст-Вильгельм Шеер — «Введение в управление бизнес-процессами» (Einführung in das Geschäftsprozessmanagement). Систематическое введение в немецкую школу процессного управления.