Методология процессного бизнес - моделирования ЯМТ(TML)

В статье изложены элементы аппарата методологии процессного бизнес - моделирования и, в частности, эмпирические данные синтеза языка процессного бизнес - моделирования ЯМТ (TML).

В настоящее время на отечественном рынке представлено достаточно большое количество CASE-систем (Computer Aided Software Engineering), многие из которых позволяют создавать описания бизнес-процессов предприятий в той или иной форме графического представления. Очевидно, что выбор конкретной CASE-системы в значительной мере определит качество описания бизнес-процессов и, следовательно, в целом, успех проекта по внедрению процессного менеджмента на предприятии. В основе каждой CASE-системы лежит использование определенного стандарта нотации графического описания бизнес - процессов. Наиболее известными нотациями графического описания бизнес-процессов являются IDEF (IDEF0, IDEF3 реализуется программным инструментом BPwin), ARIS (реализуется программным инструментом ARIS Toolset). Сравнительному анализу этих нотаций в части недостатков посвящено много публикаций, в частности [3 -10]. Проведенный нами анализ существующих публикаций результатов описания бизнес - процессов украинских и российских предприятий с использованием нотаций IDEF0 и ARIS убеждает нас присоединиться к выводам автора публикации [6] о том, что методические ошибки возникающие при использовании данных нотаций для описания и последующей регламентации бизнес-процессов предприятий, в общем контексте могут быть сгруппированы так:

  • неправильный выбор объектов описания: описание какого-либо вида

деятельности предприятия в качестве отдельного бизнес - процесса (например,
выделяется бизнес - процесс «Планирование на предприятии»). Причина:
некорректное определение объекта рассмотрения. В результате
нарушается целостность описания бизнес - процессов как объектов для
управления (границы ответственности за процессы определить практически
невозможно);

  • описание «чужого» процесса внутри своего. Причина: нечеткое

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

  • в модели описывают только часть действий (функций), составляющих

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

  • несоответствие уровней организационной структуры предприятия и уровней

его пирамиды процессного менеджмента [1] , т.е. процессный подход к
управлению является декларацией, а реальное управление предприятием и далее
остается структурно-функциональным. Причина: ТОП-менеджмент не
осознал до конца сути процессного подхода к управлению (отсутствует
убежденность и решимость перейти на систему процессно - ориентированного
управления) и / или задачу описания и регламентации деятельности выполняют
сотрудники далекие от реального управления бизнесом, но весьма неплохо
знакомые с формальными нотациями моделирования. В результате модель
финансовой структуры по центрам финансовой ответственности не совпадает с
бюджетной структурой (моделью). В данной ситуации на предприятии
проблематично внедрить эффективную систему управленческого учета и
попроцессного бюджетирования;

  • «нереальные» потоки документов и ресурсов: в модели процесса используются

обобщенные потоки документов (информации) и ресурсов, в то время как
руководители и исполнители работают с реальными документами и конкретными
ресурсами. Причина: технология IDEF0 и ARIS основана на принципе
каскадного водопада детализации описания процессов, когда контекстная
диаграмма верхнего уровня должна быть последовательно трансформирована в
отдельные описания дочерних иерархических диаграмм по принципу русской
матрешки. При такой технологии описания на одной схеме затруднительно
отображать потоки реальных документов, т.к. слишком много графических
элементов на одной диаграмме ограниченного физического размера, например,
размера А4. Поэтому необходимо показывать агрегированные потоки. Если же
стоит задача представить реальные потоки, то при описании процессов резко
увеличивается количество дочерних диаграмм нижнего уровня.
В результате схема описания процесса становится очень сложной для
восприятия. Анализ такой схемы сопряжен с большими затратами времени.
Поэтому руководители, получив эти схемы от специалистов, которым была
поставлена задача описания процессов, через некоторое время после
малоуспешных попыток работы с ними перестают их использовать и, как
правило, выбрасывают в корзину. В результате идея описания и регламентации
процессов дискредитируется в глазах руководителей из-за применения
неадекватных задачам методов описания;

  • попытка использовать модель IDEF0 статичную по существу для описания

потока работ в динамике. Причина: непонимание назначения
нотации IDEF0 и присущей ей статичности описания. Здесь налицо
диалектическое противоречие: то, что необходимо практике модель IDEF0 дать в
принципе не может. В контексте этой причины следует указать на отсутствие в
IDEF0 возможности отображать точки ветвления процесса (в азбуке IDEF0 нет
логических элементов).

Полностью текст статьи размещен на сайте www.tupkalo.com.ua


Залишити коментар
Будь ласка, введіть ваше ім’я
Будь ласка, введіть коментар.
1000 символів

Будь ласка, введіть email
або Відмінити

Інші статті в категорії Менеджмент, керування, KPI