Файл: Применение процессного подхода для оптимизации бизнес-процессов.pdf

Гибкие отчеты.

Отчеты в процессной системе строятся по всем параметрам и условиям, которые присутствуют в процессах. Руководители подразделений выделяют ключевые показатели эффективности (KPI), отлеживают их в режиме реального времени и могут посмотреть отчетность по нужному показателю за любой прошлый период. [2, c.272]

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

Внедрение процессных систем.

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

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

2. Графическое описание бизнес-процессов

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

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

• Basic Flow Chart и IDEF0.
• CFFC (Cross Functional Flow Chart. Кросс-функциональная модель, или «диаграмма дорожек»). По мнению многих экспертов, она наиболее проста для разработки и чтения. Данная нотация интуитивно понятна сотрудникам и имеет очень широкое распространение.

Но есть два недостатка: ограничение по количеству «дорожек» (субъектов — исполнителей бизнес-процесса) на листе А4, недостаточный набор фигур для отображения всех необходимых сущностей и атрибутов (например, отсутствие фигур «базы данных» и «программный продукт»).

Рис. 3. Нотация «Cross Functional Flow Chart» — модель процедуры «Оформление и выдача кредита»

• EPC (Event driven Process Chain. Цепочка процесса, управляемая событиями) . Содержит большой набор фигур для отображения всех основных сущностей и атрибутов на моделях бизнес-процессов. Имеет хорошую визуализацию и цветовое оформление.

---

Рис. 4. Нотация «EPC» — модель процедуры «Разработка / модификация продукта банка»

• BPMN (Business Process Model Notation. Модель и нотация бизнес-процесса). Является наиболее сложной и многофункциональной нотацией. Есть организации, которые полностью описывают все свои бизнес-процессы в BPMN и имеют более 200 моделей в формате А4 с постоянной актуализацией.

Рис. 5. Нотация «BPMN» — модель процедуры «Прием сотрудников на работу»

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

Каждый программный продукт поддерживает разный набор нотаций. Подробное описание всех нотаций утверждается в документе «Соглашение по бизнес-моделированию».

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

Форматы описания бизнес-процессов по их формализации.

Рассмотрим 3 основных формата.

1. Текстовый формат. Для сложных бизнес-процессов это обычно несколько текстовых регламентов с общим объёмом более 100 страниц А4. У этого формата есть немало минусов и недостатков, тем не менее, он является самым распространённым на сегодняшний день.
2. Табличный формат  — более формализованный (структурированный) и компактный. Бизнес-процесс представляется в виде таблицы со следующими столбцами: функции (действия), вход, источник входа, выход, потребитель выхода, требования к срокам, комментарии и др.
3. Графический формат. В России уже известны организации, которые имеют все свои процессные регламенты в графическом формате (т. е. они состоят только из моделей). Такая практика с каждым годом получает всё более широкое распространение – все организации, которые ориентированы на долгосрочное и эффективное ведение бизнеса в условиях конкурентной среды, перейдут к графическому описанию бизнес-процессов.

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

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

---

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

Это описание бизнес-процесса в формате презентационных слайдов (например, MS Power Point), состоящих из «живых» картинок (Clipart), фотографий и текстовых пояснений. Данному формату нельзя придать юридическую силу (официально утвердить), но, как это ни странно, бизнес-процессы в течение многих лет работают на основе этого формата описания. Работают с ошибками, операционными рисками и проблемами, но руководители не понимают этого или не хотят менять подход.

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

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

• Визуализировать (представить наглядно) логику бизнес-процесса. Например, для коллективного обсуждения и анализа.
• Быстро и точно выявить ошибки и операционные риски в бизнес-процессах. Также очень удобно на моделях отметить те места, в которых могут реализоваться операционные риски, и заранее принять необходимые меры.
• Найти «узкие места» и причины неэффективности в бизнес-процессе.
• Полноценно применить методы оптимизации, разработать модели «как надо» («TO-BE» или версию 2.0). Большое количество методов оптимизации основано на использовании графических моделей.
• Провести имитационное моделирование (Simulation) и функционально-стоимостный анализ (ФСА) бизнес-процесса с помощью программных продуктов бизнес-моделирования.
• Объяснить порядок выполнения бизнес-процесса сотрудникам, быстро вспомнить или понять основные моменты и детали. В некоторых организациях графические модели наиболее важных и сложных процедур постоянно находятся на рабочих столах сотрудников.
• Отследить все взаимосвязи с другими бизнес-процессами и объектами в компании, что особенно актуально для крупных и территориально разделённых организаций.
• Организовать качественный контроль бизнес-процесса (в том числе процедуры внутреннего аудита). Отметим, что в банках инициатором описания бизнес-процессов иногда выступает служба внутреннего контроля.
• Построить комплексную электронную бизнес-модель организации. Именно системный подход, т. е. разработка системы взаимосвязанных моделей по всем областям работы и управления в организации, позволяет добиться максимальных результатов.
• Обеспечить синхронизацию одинаковых объектов в разных бизнес-процессах. Например, если бизнес-аналитик изменил название должности (субъекта) в организационной структуре, то на моделях всех бизнес-процессов, в которых участвует данная должность (как исполнитель), должны автоматически измениться названия соответствующих фигур. При текстовом описании бизнес-процессов синхронизацию и актуализацию регламентов приходится выполнять вручную, поэтому при больших объёмах информации часто возникают неточности и даже противоречия.
• Автоматически сгенерировать текстовые и табличные регламенты с помощью программных продуктов бизнес-моделирования (например, Business Studio).

---

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

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

3.1 AllFusion Process Modeler (Bpwin) — ERwin Process Modeler

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

Рис.6 Интерфейс AllFusion Process Modeler (Bpwin)

Моделирование предметной области, как правило, выполняется с помощью CASE-средств. К таким средствам относятся BPwin (AllFusion Process Modeler), Oracle Designer (Oracle) и др.

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

BPwin предоставляет средства для изучения операций и управления операциями на различных уровнях детализации. Например, иногда бывает важно сосредоточиться на определенной части бизнеса организации. BPwin позволяет вам разделить сложный процесс на множество управляемых частей, обеспечивая группам разработчиков модели возможность сосредоточиться на интересующих их аспектах. [5, c.128]

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

---

BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0) — верхнеуровневое; описание бизнес-процессов (IDEF3) — поток работ и диаграммы потоков данных (DFD). Чаще всего применяется для создания функциональной модели предметной области на начальных этапах проектирования информационной системы, а также для анализа существующей или проектируемой ИС.

Функциональная модель включает в себя:

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

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

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

Рис 7. Функциональный блок

IDEF0 требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования.

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

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

Выход — объекты, в которые преобразуются входы. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как исходящая из правой грани работы.

Механизм — ресурсы, выполняющие работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. По усмотрению аналитика стрелки механизма могут не изображаться на модели.

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

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

---