Процессный подход к управлению как основа организационно-экономического моделирования.

В основе процессного подхода к управлению лежит PDCA - цикл управления (цикл Деминга). Цикл включает четыре шага: планирование процесса (Plan), выполнение процесса (Do), анализ показателей эффективности (Check), корректировка процесса (Act).

Базовые требования процессного подхода к управлению стандартизированы, сформулированы в МС ИСО 9000: 2000 и включают следующие основные положения.

1. Система управления складывается как минимум из двух уровней. Управленческие решения принимают высшее руководство («первое лицо») и владелец процесса (руководитель, отвечающий за эффективность работы; лицо, принимающее решение (ЛПР)). Взаимодействие владельцев нескольких процессов должно быть определено и формализовано.

2. Система управления бизнес-процессом основана на обязательных регламентированных обратных связях, описанных в цикле PDCA.

3. Все этапы цикла PDCA выполняются по регламентам. Регламент представляет собой подробное описание бизнес-процесса. В основе регламента лежат должностные инструкции, типовые процессы принятия решений, опыт организации аналогичного производственного процесса, директивы вышестоящих организаций и подразделений и т.д.

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

5. Стандарт требует установить характеристики этих информационных потоков, определить методики сбора и обработки информации, границы показателей для нормального хода процесса и критерии для принятия корректирующих действий (КД). Управленческое решение об изменении регламентов или ресурсов должно приниматься на основании строгих фактов.

6. Принцип PDCA при необходимости тиражируется на нижние уровни управления.

Каждый бизнес-процесс, построенный на принципах PDCA, представляет собой систему, исследование которой основывается на принципах системного анализа. Системный анализ – это научный метод познания, представляющий собой последовательность действий по установлению структурных связей между переменными или элементами исследуемой системы. Он опирается на комплекс общенаучных, экспериментальных, естественнонаучных, статистических, математических методов.

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

При решении системной задачи должны выполняться следующие общие принципы:

1. Четко формулируется цель исследования и ставится задача реализации этой цели.

2. Определяется критерий эффективности решения.

3. Разрабатывается развернутый план исследования с указанием основных этапов решения.

4. Выполняется продвижение по этапам решения с организацией последовательных приближений и повторных циклов исследования.

5. Соблюдается принцип нисходящей иерархии анализа и восходящей иерархии синтеза при решении отдельных подзадач.

Центральное понятие системного анализа - система. Система - объект, взаимодействующий с внешней средой и обладающий сложным внутренним строением, большим числом составных частей и элементов. Элемент системы - самостоятельная и условно неделимая единица. Элементы взаимодействуют между собой и окружающей средой, т.е. между ними существует материальная, энергетическая и информационная связь. Пространственно-временные агрегаты взаимодействующих элементов, обладающие определенной целостностью и целенаправленностью, выделяются в функциональные подсистемы. Процедура образования подсистем из системы - декомпозиция.

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

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

При внедрении процессного подхода и применении структурного анализа к управлению, организация получает возможность решать следующие задачи.

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

2. Использование системы показателей и критериев оценки эффективности управления на каждом этапе управленческой цепочки.

3. Обоснование нацеленности системы управления на повышение эффективности работы организации.

4. Получение сертификата МС ИСО 9000: 2000.

5. Обеспечения четкого порядка функционирования организации и распределение ответственности за разработку, согласование, утверждение и ведение документации.

6. Принятие решений на основе информации о деятельности организации с использованием информационной системы предприятия.

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

Основу большинства современных подходов к моделированию бизнес-процессов составляют методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования), семейство нотаций IDEF (Icam DEFinition, где Icam - это Integrated Computer-Aided Manufacturing) и алгоритмические языки.

Основные типы методологий моделирования и анализа бизнес-процессов включают:

· Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемые методологии описания бизнес-процессов - нотации IDEF0 и ARIS. Модели в этих нотациях предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.

· Описание потоков работ (Work Flow Modeling). Нотация IDEF3 предназначена для описания рабочих процессов и близка к алгоритмическим методам построения блок-схем.

· Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отобразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.

· Прочие методологии (например, блок-схемы).

Главная цель применения методологий (нотаций) – возможность описывать различные бизнес-процессы организации на одном формальном языке при четком определении цели реализации процесса.

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

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

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

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

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

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

Регламент процесса содержит следующие разделы.

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

2. Владелец процесса - назначенное должностное лицо, отвечающее за результат процесса, имеющее в своем распоряжении все необходимые ресурсы, информацию о ходе процесса и полномочия для управления им.

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

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

5. Показатели процесса — перечень показателей процесса, по которым вла­делец процесса оценивает его ход и принимает управленческие решения. Формы сбора информации и отчетности по процессу.

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

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

Таким образом, зная регламент бизнес-процесса, строится его логико-математическое описание, отображающее структуру модели процесса.

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

IDEF0

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

· Управляющая информация входит в блок сверху.

· Входная информация входит в блок слева.

· Результаты выходят из блока справа.

· Механизм (человек или автоматизированная система), который осуществляет операцию, направляются в блок снизу.

Каждый компонент модели может быть декомпозирован (расшифрован более подробно) на другой диаграмме. Рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цели. Общее число уровней в модели не должно превышать 5-6. Необходимо размещать на каждой диаграмме от 3 до 7 функций процессов, не загромождая диаграммы несущественными на данном уровне деталями.

IDEF3

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

Диаграммы IDEF3 отображают действие в виде прямоугольника. Все связи в IDEF3 являются однонаправленными и организуются слева направо.

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

Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.

DFD

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

Основными компонентами диаграмм потоков данных являются:

· внешние сущности (материальный объект или физическое лицо, являющиеся источником или приёмником информации, например, заказчики, персонал, поставщики, клиенты, склад);

· системы и подсистемы (например, подсистема по работе с физическими лицами);

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

· накопители данных (блоки или абстрактные устройства для хранения информации);

· потоки данных (стрелки на диаграмме).

ARIS

В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, основанных на методологии SADT, которые проявляются в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.

ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуемой системы:

· организационные модели, представляющие структуру системы — иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;

· функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;

· информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;

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

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

Основная бизнес-модель ARIS - eEPC (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, MS Project.

Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - " функции", " события", " структурные подразделения", " документы" и т.д. Между объектами определённых видов могут быть установлены связи определённых видов (" выполняет", " принимает решение", " должен быть проинформирован о результатах" и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.

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

Для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных, представляющая собой иерархическое хранилище моделей. Предусмотрены различные функции по администрированию базы данных, например, управление доступом.

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

• сбор информации об объекте;
• построение модели объекта " как есть";
• анализ построенных моделей;
• построение моделей " как должно быть";
• проектирование информационной системы (в случае необходимости).

Сбор информации является первым этапом реализации проекта по реорганизации предприятия. Полученная в результате исследования объекта информация формализуется и структурируется с использованием системы ARIS. С помощью данного программного продукта строятся модели объекта, отражающие его жизнедеятельность с разных сторон. Это может быть организационная структура предприятия, дерево его целей, информационные модели, отражающие структуру информации, используемой на предприятии и т.п. Конкретный набор методов, используемых для построения таких моделей, формируется в зависимости от целей проекта из числа тех восьмидесяти трех методов, которые поддерживает система ARIS.

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

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

При моделировании бизнес-процессов и в особенности процедур управления предпочтение отдается IDEF0. Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Work Flow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться «за кадром» на 30-90%.

ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией – «Соглашениями по моделированию». Разработка этих «Соглашений» само по себя является сложной, дорогой и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90%.

В свою очередь, IDEF0 отличается простотой в использовании, и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более «тяжелым» инструментом, по сравнению с IDEF, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.