В статье Владимира Репина представлен пример описания бизнес-процесса и настройки среды моделирования Business Studio для создания технического задания на автоматизацию бизнес-процесса в BPMS. Обсуждаются вопросы вовлечения руководителей и сотрудников подразделений компании в работу по проектированию исполняемых процессов и формированию ТЗ на автоматизацию.

Возможная постановка задачи

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

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

Постановка задачи. Необходимо с использованием Business Studio:
а) перевести все подготовленные схемы в универсальный формат, при этом:
б) создать архитектуру бизнес-процессов компании;
с) сделать процессы исполняемыми;
д) подготовить ТЗ на автоматизацию процессов в BPMS.

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

В данном случае, я привел пример только одной схемы. Если бы речь шла об автоматизации одного процесса, то не было бы никакого смысла переводить схему из MS Visio сначала в Business Studio, а потом в BPMS. Но совсем другое дело, когда нужно подготовить сначала модели нескольких процессов, взаимосвязанных с точки зрения технологии и входов-выходов.

Если рассматривать/автоматизировать N процессов, не продуманных в единой архитектуре, можно упустить ряд важных деталей и не получить решение бизнес-задачи в целом. Поэтому роль среды моделирования при разработке и автоматизации нескольких взаимосвязанных процессов кардинально возрастает.

Специалист по Business Studio Иван Глебов, считает, что «дополнительным положительным результатом использования среды моделирования Business Studio для формирования ТЗ является документирование функциональной архитектуры информационных систем, используемых для автоматизации бизнес-процессов. Архитектура информационных систем формируется в разделе «Программные продукты» среды моделирования Business Studio».

Перевод схемы в нотацию BPMN в Business Studio

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

Замечу, что можно использовать полученную схему для создания имитационной модели процесса. Такая модель в Business Studio применяется для валидации процесса, то есть проверки, будет ли процесс на практике стабильно выдавать результат с установленными характеристиками по стоимости, времени и качеству. К слову, практически в каждой BPMS можно тестировать подготовленные схемы (т.е. запускать токены и смотреть, дойдет ли процесс до конца), но вот запускать имитацию и получать статистические параметры процесса для его анализа и оптимизации – нельзя.

Фрагмент схемы показан на рис. 3. Использованы маркеры операций, чтобы показать, какая операция будет выполняться пользователем в интерфейсе BPMS (Business process management system), а какая может быть выполнена скриптом (соответствующий маркер и серая заливка).

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

Так же показаны информационные системы, которые в текущий момент используются для выполнения операций процесса, например, «АИС «Управление планом ПИР». Кроме того, в качестве примера, показана возможность отобразить документооборот на схеме процесса и используемые для хранения документов базы данных компании.

Стоит упомянуть, что возможен импорт схем, созданных в MS Visio, в Business Studio. Но в данном случае было быстрее нарисовать «правильную» схему заново, чем редактировать схему, полученную после импорта. Но этот пример не говорит о том, что так поступать нужно всегда. Функция импорта полезна.

Настройка аналитики по бизнес-процессу и формирование ТЗ на автоматизацию

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

Кроме того, для настройки BPMS требуется дополнительная информация, которая не представлена на схеме. Необходимо определить, какие аналитические данные нужны автоматизации процесса в конкретной исполняемой системе. Затем настроить Business Studio путем расширения объектной модели с использованием модуля Meta Edit так, чтобы можно было удобно вносить данные через интерфейс системы. На рис. 4 показан пример возможной настройки. Для каждой операции процесса доступна закладка «ТЗ на автоматизацию», которая содержит ряд полей (атрибутов), которые необходимо заполнить.

Например, можно выбрать тип операции процесса: «в интерфейсе BPMS», «сценарий», «ручная операция» и т.д. Можно указать, что требуется настройка нормативного времени выполнения операции и указать это время. Можно добавить, что нужно измерять фактическое время выполнения т.п. Так же есть атрибут, показывающий необходимость интеграции с другой системой и проч.

После занесения информации по всем операциям процесса, можно автоматически сформировать готовое Техническое задание на автоматизацию бизнес-процесса. Для этого в Business Studio настраивается специальный шаблон отчета. Возможна выгрузка в MS Word или в MS Visio в зависимости от требований проекта. На рисунках 5 и 6 показаны фрагменты такого ТЗ. В данном случае, ТЗ сформировано в весьма упрощенной, демонстрационной форме.

Какая еще аналитика может и должна быть собрана при подготовке к автоматизации процесса в BPMS? В своей статье Андрей Чепакин предлагает следующую структуру:

1. Схема инициации процесса.
   1.1. Роль «Инициатор бизнес-процесса».
   1.2. Мотив инициации бизнес-процесса.
   1.3. Способы запуска бизнес-процесса.
2. Схема создания ценности.
   2.1. Типизация клиентов/заказчиков бизнес-процесса.
   2.2. Составляющие ценности, формируемой процессом, по типам клиентов.
   2.3. Сценарии использования процесса его клиентами.
3. Схема работы процесса.
   3.1. Спецификация входов процесса.
   3.2. Спецификация выходов процесса.
   3.3. Определение единицы потока и ее состояний.
   3.4. Ролевая модель процесса.
   3.5. Спецификация метрик и показателей процесса.
4. Схема данных процесса.
   4.1. Спецификация данных процесса.
   4.2. Определение источников данных для процесса.
5. Схема контроля процесса.
   5.1. Спецификация контролируемых метрик и показателей.
   5.2. Способы сбора и обработки данных.
   5.3. Способы доставки информации владельцам процесса.
6. Схема обратной связи процесса.
   6.1. Способы доставки обратной связи участникам процесса.
   6.2. Способы получения обратной связи от клиентов процесса.
   6.3. Способы доставки обратной связи высшему руководству.
7. Схема компетенций процесса.
   7.1. Требования к перечню участников процесса.
   7.2. Требования к компетенциям участников процесса.
   7.3. Реестр возможностей снижения требований к компетенциям.

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

Интересные мысли по аналитике высказывает Денис Котов в своей статье. Он рекомендует включать в ТЗ на автоматизацию процессов в BPMS (кроме схемы) следующую информацию:
• Модель данных.
• Объекты системы (например, договор, закупочная процедура или клиент).
• Данные процесса (информация, относящаяся к конкретному экземпляру процесса).
• Отчеты.
• Автоматизации: эскалации руководителям, расчеты («математика»), бизнес-правила, проверка из базы данных, триггеры, интеграции.

Многие специалисты считают, что модель данных, кроме схемы, является ключевой для эффективного решения задачи автоматизации процесса в BPMS. В текущей версии Business Studio, к сожалению, нельзя создать графическую модель структуры данных, как это можно быть сделать, например, в ERWin (ER модель — entity-relationship model, модель «сущность — связь» — модель данных, позволяющая описывать концептуальные схемы предметной области). В Business Studio можно только описать атрибуты для всех документов, которые используются в моделях бизнес-процессов, как показано на рис. 7.

Иван Глебов отмечает, «что хотя в настоящий момент в среде Business Studio нет возможности графически моделировать структуру данных для ТЗ, но зато в ней есть возможность давать детальное описание атрибутов документов, используемых в процессах, что позволяет достаточным образом смоделировать необходимую структуру данных в «текстово-табличном» виде. При этом, посредством MetaEdit, таблицу атрибутов документа можно дополнить колонкой, в которой, при необходимости, можно указать другой документ в бизнес-модели, с которым атрибут документа должен иметь связь при автоматизации документа в информационной системе».

Кто будет настраивать BPMS?

Настройка любой BPMS включает, как минимум:

1. создание модели организационной структуры компании;
2. создание графической модели процесса;
3. определение участников процесса и их прав;
4. определение необходимых данных;
5. настройка показателей для контроля и управления процессом;
6. создание экранных форм;
7. проверка процесса и публикация на исполняемом сервере.

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

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

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

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

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

Может быть создано несколько команд, состоящих из сотрудников разных подразделений, которые проектируют бизнес-процессы в Business Studio, проводят анализ и формулируют требования и пожелания (например, автоматизировать выполнение конкретных операций или применить RPA). Участникам рабочих групп не нужно знать нюансы настройки BPMS, поэтому они могут сосредоточиться на проектировании эффективных бизнес-процессов. Такой подход может существенно ускорить работу по оптимизации и автоматизации бизнес-процессов компании.

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

Сравнение двух подходов. Таблица.

В случае Варианта I (столбцы 3-4) руководители и специалисты подразделений владеют компетенциями:
• по описанию и анализу бизнес-процесса;
• по использованию базового функционала BPMS на уровне пользователей.

При этом бизнес-пользователей не нужно учить несвойственным и ненужным им аспектам.
Например, менеджера по продажам, цель которого продавать товар компании, не нужно учить программировать скрипты на C# или создавать ER-модель.

В свою очередь ИТ специалистов не нужно специально учить методам анализа и оптимизации процессов (TOC, Lean, KPI).

В случае Варианта II (столбцы 5-6) руководители и специалисты подразделений должны овладеть специальными компетенциями (см. красный шрифт) на весьма глубоком уровне.

Могут ли бизнес-пользователи проектировать процессы сразу в графическом редакторе BPMS? Да, могут. При этом они, в любом случае, должны в какой-то форме фиксировать требования к дальнейшей, более сложной настройке исполняемого процесса. Вопрос – где именно? На клочке бумаги, устно или все-таки в формализованном, структурированном виде?

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

Приведу пример. В моей книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» представлены модели трех процессов. Первый процесс называется «Подача заявки на оплату». В компании может быть одновременно инициировано несколько экземпляров этого процесса. Второй процесс – «Согласование графика платежей на неделю». Он запускается по таймеру и выполняется один раз в неделю. Третий процесс называется «Оплата счетов». Он инициируется процессом «Согласование графика платежей на неделю». Модели процессов были созданы в Business Studio в нотации BPMN. Используя семантику BPMN, я показал на схеме, что каждый экземпляр процесса «Подача заявки на оплату» должен получить сообщения из процессов «Согласование графика платежей на неделю» и «Оплата счетов». Далее эти три схемы были переданы в качестве ТЗ специалисту по Elma, который быстро настроил исполняемые процессы в этой системе (большое спасибо!). При настройке нужно было решить несколько задач, явно выходящих за пределы компетенций бизнес-пользователя, а именно: дополнение структуры данных, создание переменных процессов, создание скриптов на C#, управляющих отправкой сообщений, доработкой модели процесса с учетом технологических особенностей работы скриптов.

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

Стоит отметить, что компетенции участников проекта должны в разумной степени пересекаться, как показано на рисунке 9.

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Июнь 2019 г.

В статье представлены результаты имитационного моделирования процесса «Рассмотрение и согласование оперативных заявок» в среде Business Studio. Выполнен анализ процесса «как есть». Определены направления оптимизации процесса. Разработана модель «как должно быть». Путем имитации процесса определен потенциальный экономический эффект от возможного проекта оптимизации, в т.ч. за счет автоматизации в BPMS. Статья может быть интересна специалистам в области организационного развития, использующим модели процессов в нотации BPMN в среде Business Studio.

Введение

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

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

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

В данной статье рассматривается имитационная модель реального процесса «Рассмотрение и согласование оперативных заявок». крупной промышленной компании. Используемый инструмент имитационного моделировании – Business Studio 4.2.

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

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

Автоматизация процесса практически отсутствует.

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

Исходная модель процесса для анализа «как есть» (80% заявок, поступающих в процесс, содержат ошибки).

Диаграмма процесса «как есть» представлена на рис.1. Участниками процесса являются:
• Инициатор подачи заявки.
• Оперативный персонал, в оперативном ведении у которого находится оборудование.
• Технический руководитель объекта.
• Оперативный персонал, в оперативном управлении у которого находится оборудование.

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

На рис. 2 показана интенсивность запуска процесса (нагрузка на процесс). В месяц поступает около 1200 оперативных заявок на обработку. Фактически, заявки могут готовиться в любое время, но процесс запускается только в период с 16 до 18-00 ежедневно. В другое время заявки просто не рассматриваются.

На схеме процесса показано время выполнения каждой операции. Например, для операции «Рассмотреть и согласовать заявку (совместимость)» сверху указано «Норм.Константа (0:05:00)». Это означает, что нормативное время выполнения данной операции составляет 5 минут. Там, где снизу операции написано «Ож.Константа…» это означает время ожидания выполнения из-за, например, отсутствия ресурса и проч.

Обратим внимание, что время выполнения первой операции процесса «Оформить оперативную заявку» не является константой. Около 64% всех заявок оформляется 5 минут. В 27% случаев необходимо собирать данные для заявки, а это занимает 15 минут. В 9% случаев сбор данных занимает 20 минут.

Такое дискретное распределение было выбрано, т.к. реальный закон распределения времени формирования заявок неизвестен, учета нет. Со слов экспертов по процессу «в 20-30% случаев заявка формируется 15-20 минут из-за необходимости сбора данных». Довольно неточное определение, к сожалению.

На схеме процесса (см. рис. 1) красным цветом показана вероятность перехода по соответствующим стрелкам после шлюзов. Так, например, переход по стрелке «да» после шлюза «Имеются критичные ошибки в заявке?» будет осуществляться с вероятностью 80% и т.п.

Имитация процесса проводилась для одного месяца – ноября 2018 г. По результатам имитации получены следующие данные:
• среднее время выполнения одного экземпляра процесса — 2 часа 40 минут;
• суммарная стоимость процесса за месяц – 128 тыс. рублей.

Анализ отчета по результатам имитации, сгенерированного Business Studio, показывает, что самая дорогая операция в рамках одного экземпляра процесса – это операция «Оформить оперативную заявку». Она стоит 32 рубля.

Измененная схема процесса — 10% заявок с ошибками.

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

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

По результатам имитации для случая с 10% ошибочных заявок получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 день и 6 часов (!);
• суммарная стоимость процесса за месяц – 320 тыс. рублей.

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

Оптимизация процесса

Итак, какие же проблемы можно отметить в результате имитации процесса. Прежде всего это:

• ошибки при формировании заявок и долгий (относительно) поиск данных для их заполнения;
• 47% операций процесса – это операции типа «Передать» или «Получить, которые не добавляют никакой ценности (ни с точки зрения инициатора, ни с точки зрения компании);
• практически полностью ручной труд, ручная передача информации, риск ошибок (человеческий фактор);
• ключевые операции процесса не автоматизированы (сбор данных и выполнение расчетов выполняются вручную);
• данные, необходимые для выполнения процесса, дезинтегрированы (находятся в разных базах данных и программных продуктах, на бумаге);
• внутри процесса возникают (неоправданные) задержки.

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

Полный список предложений следующий:
• заполнение заявок должно выполняться без ошибок и без ожидания данных (данные должны быть доступны в функциональной информационной системе);
• необходимо сокращение времени формирования заявок до 3 минут в 80% случаев;
• необходимо устранить операции типа «Передать» и «Получить»;
• необходима автоматизация самого процесса в системе класса BPM (Business Process Management);
• ряд операций необходимо сделать полностью автоматическими, например, «Сформировать/Внести заявку в сменное задание»;
• требуется создание единой базы данных в рамках функциональной ИС по управлению работой и обслуживанием оборудования;
• для всех операций необходимо сокращение времени выполнения операций за счет автоматизации.

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

По результатам имитации оптимизированного процесса получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 час 34 минуты;
• суммарная стоимость процесса за месяц – 106 тыс. рублей.

Кстати, после оптимизации процесса операция «Оформить оперативную заявку» перестала быть самой дорогой…

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

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

Таблица. Сравнение процессов «как есть» и «как должно быть».

Таким образом, потенциальный годовой эффект от оптимизации процесса «Рассмотрение и согласование оперативных заявок» может составит 2,57 млн. рублей.

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

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

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»

Ю.А. Федосеев
Начальник отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»

А.Э. Мельникова
Ведущий специалист по стандартизации отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»

Декабрь 2018 г.

В статье Владимира Репина описана деловая игра по оптимизации бизнес-процесса, основанная на использовании имитационной модели, созданной в среде Business Studio. Цели игры – анализ процесса, поиск узких мест и «муды» (потерь), разработка предложений по оптимизации процесса. Рабочие группы анализируют процесс и предлагают ряд мероприятий по его оптимизации. Выполняется экспертная оценка предложений, отбираются практические реализуемые. Затем процессы перепроектируются в Business Studio с учетом обоснованных изменений. Проводится имитационное моделирование. Различные варианты моделей сравниваются между собой на основе показателей длительности выполнения и стоимости результата процесса. Игра может использоваться при проведении базового курса обучения процессному управлению в компаниях, в программах MBA и проч.

Введение

Цели деловой игры, предлагаемой вниманию читателя, следующие:

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

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

Сценарий игры

Организация

На группу участников (4-8 человек) распечатывается цветная схема процесса в формате А2.
Дополнительно распечатывается форма перечня предложений по оптимизации (2 листа на каждую группу, всего 6 листов).
Все участники делятся на 3 группы:

1. Команда «А» (выбирает себе название).
2. Команда «Б» (выбирает себе название).
3. Команда экспертов (желательно включить в нее несколько топ-менеджеров).
   Объявляются цели и правила игры. Цель игры – достижение лучших показателей за счет оптимизации бизнес-процесса. Используется два показателя: 1) длительность выполнения процесса; 2) стоимость результата процесса (в данном примере – это коммерческое предложение).

Демонстрация модели

Проводится демонстрация имитационной модели бизнес-процесса (с анимацией хода процесса в Business Studio).
Обсуждаются результаты имитации.
Обсуждаются целевые показатели процесса: 1) длительность выполнения; 2) стоимость результата процесса; 3) качество (количество ошибок и т.п.).

На рис. 1 представлена исходная схема процесса «Формирование КП клиенту». КП – коммерческое предложение. Речь идет о торгово-производственной компании B2B, которая выпускает стандартный ассортимент, но может по требованию заказчиков вносить конструктивные изменения в модели изделий, использовать другие материалы, цвета и т.п.

В процессе участвуют несколько сотрудников:
• Менеджер, ответственный за формирование КП клиенту (2 шт.);
• Начальник отдела продаж (1 шт.);
• Начальник Инженерно-технического отдела (1 шт.);
• Инженер Инженерно-технического отдела (1 шт.);
• Начальник ФЭО (1 шт.);
• Экономист ФЭО, ответственный за расчет стоимости изделия для КП (1 шт.);
• Коммерческий директор (1 шт.).

Каждая операция процесса имеет определенную длительность. Некоторые операции начинаются не сразу, а с задержкой. Это сделано для того, чтобы учесть факт загрузки руководителей в других процессах (которые не используются при имитации), что ведет к невозможности сразу приступить к выполнению операции. Время выполнения показано над операцией (Раб.Константа…). Задержка перед выполнением (если она есть) – под операцией процесса (Ож.Константа).

Процесс выполняется руководителями и специалистами. Практически после каждой операции процесса указаны шлюзы типа «Исключающее ИЛИ». Процесс ветвится – потоки работы разделяются с учетом вероятности. Например, после операции «Проверить расчет параметров изделия» в 20% случаев нужно переделать расчет, т.к. он содержит неточности (ошибки). Вероятности перехода показаны на схеме визуально в процентах красным шрифтом (это сделано вручную – в Business Studio нет возможности визуализировать вероятность перехода на схеме).

Стоимость рабочего времени участников процесса задана в модели. Менеджер получает 150 рублей в час, Начальник отдела продаж – 200 рублей в час и т.п. Другие показатели затрат (например, амортизация оборудования или затраты на аренду офиса) не заданы, т.к. не влияют на результаты игры.

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

На рис. 2 показан фрагмент пошаговой имитации процесса в Business Studio. Пошаговая имитация используется для демонстрации понятия потока работ (Work Flow) и понятия «экземпляр» процесса.

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

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

1. средняя длительность процесса формирования коммерческого предложения – 9 дней 5 часов 24 минуты;
2. средняя стоимость подготовки коммерческого предложения — 3203,18 рублей.

Очевидно, что при такой длительности клиент просто может не дождаться подготовки запрашиваемого коммерческого предложения.

Анализ процесса и формулирование предложений

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

Каждое предложение по изменению процесса должно быть обосновано, т.е. должна быть аргументирована возможность его практической реализации, определены необходимые условия, ресурсы и методы, оценены риски. Если предложения касаются автоматизации, то желательно оценить возможный бюджет и сделать оценку «затраты/эффективность».

Оценка предложений

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

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

Защита предложений

Команды представляют свои предложения по оптимизации процесса (3-5 минут).

Представили команды экспертов дают аргументированную оценку предложениям.
Затем группы могут потратить некоторое время на дискуссию.

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

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

Изменение модели процесса и выполнение имитации

Ведущим игры вносятся изменения в модели процессов. Это, кстати, хорошая возможность ознакомить участников с методами описания процессов в среде Business Studio.

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

Примеры результатов выполнения игры

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

Одну группу можно условно назвать «Сдержанной», а другую «Радикальной».

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

По результатам имитации оптимизированного процесса получены следующие данные:

1. средняя длительность процесса формирования коммерческого предложения – 2 дня 12 часов 48 минут;
2. средняя стоимость подготовки коммерческого предложения — 1361,25 рублей.

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

Предложения «Радикальной» группы могут быть реализованы, пожалуй, только в случае перехода на «бирюзовые» методы организации бизнеса и при тотальной автоматизации процесса, которая стоит заметных денег. Кроме того, компания должна быть достаточно проактивной, т.е. не пытаться подстроиться под всех клиентов, а выпускать только стандартный продукт (в данном случае я не хотел бы обсуждать корректность или некорректность этих тезисов – они были предложены группой).

Схема процесса, полученная после «внедрения» изменений, предложенных «Радикальной» группой, представлена на рис. 4.

По результатам имитации этого процесса получены следующие данные:

1. средняя длительность процесса формирования коммерческого предложения – 38 минут;
2. средняя стоимость подготовки коммерческого предложения — 47,98 рублей.

Таким образом, достигнуты следующие изменения после «оптимизации» процесса «Формирование КП клиенту»:

1. по длительности процесс улучшен в 350 раз;
2. по стоимости подготовки КП процесс улучшен в 67 раз.

Выводы

Вниманию читателя представлен сценарий деловой игры и примеры моделей процессов, полученные при ее проведении.

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

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

Кстати, при желании, можно организовать и провести такую деловую игру в вашей компании. Ее длительность около 4 часов. Буду рад сотрудничеству.

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»

Апрель 2018 г.

Статья адресована читателям, которые используют или предполагают использовать программный продукт Business Studio, в частности BS Portal (web-портал). Рассматриваются возможности и ограничения Business Studio и BS Portal для поддержки оперативного управления бизнес-процессами компании.

Введение

Business Studio – хороший инструмент для моделирования и регламентации бизнес-процессов. При грамотном методическом подходе можно получать качественные графические схемы процессов и автоматически сформированные регламенты, основанные на 100% понимании этих процессов. Кроме того, все эти модели и регламенты можно просматривать в виде гипертекстовых страниц при помощи приложения BS Portal, что дает возможность сотруднику относительно быстро находить нужную ему информацию регламентирующего или справочного характера.

Но процессное управление – это не создание регламентов. В первую очередь, это оперативное управление бизнес-процессами. Цель небольшого исследования, которое я провел, состоит в анализе возможностей Business Studio в комплекте с BS Portal для поддержки оперативного управления бизнес-процессами компании.

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

Предполагаю так же, что читатель уже имеет минимальный набор знаний об архитектуре Business Studio и видел в работе BS Portal (см. http://www.businessstudio.ru/load/portal/).

Оперативное управление бизнес-процессами

Функционал для регулярного оперативного управления бизнес-процессами – что в него должно входить? Какие инструменты может использовать владелец процесса (руководитель структурного подразделения)? Другими словами, нужен методически грамотный ответ на вопрос: «Что есть оперативное управления бизнес-процессами»? Ответ на этот вопрос не так прост, как может показаться на первый взгляд.

Замечу, что контроль прохождения экземпляров процессов в BPMS я рассматриваю как небольшую (не более 5-7%) часть задач оперативного управления процессами. Так что если у вас нет системы автоматизации процессов такого класса, это не означает, что у вас нет, или не должно быть управления бизнес-процессами.

К регулярному оперативному управлению процессами я бы отнес, как минимум, следующее:

1. Оперативное планирование процесса (деятельности подразделения).
2. Мониторинг и контроль процессов по показателям;
3. Анализ причин отклонений в процессе и принятие решений (выбор — коррекция или корректирующее действие);
4. Оформление, выдача и контроль исполнения разовых задач по процессу (в т.ч. коррекций).
5. Планирование, организация и контроль исполнения корректирующих действий по процессу.
6. Оперативный контроль исполнения требований нормативно-методических документов (регламентов).
7. Анализ процесса в целом (в т.ч. на основе статистики), планирование, организация и контроль исполнения внутренних проектов развития (PDCA).
8. Оперативный контроль экземпляров бизнес-процессов.

Хотел бы обратить внимание, что автоматизация задач 1-3 во многих компаниях до сих пор отсутствует. Руководители используют подручные средства для хранения и анализа информации: свою голову, ежедневник, файлы MS Excel и т.п. В более продвинутых компаниях применяют BI-системы, автоматизируют работу с поручениями, внедряют документооборот, BPMS и проч.

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

Посмотрим, насколько Business Studio и, в особенности, BS Portal смогут помочь нам в поддержке указанных выше задач.

Персональная страница на портале

Итак, заходим на портал Business Studio. В рассматриваемой компании (демо-базе) я назначил себя на должность Коммерческого директора (на Генерального – скромность не позволила).

Для входа на портал нужно ввести свой логин и пароль. Кстати, я поменял логотип производителя на логотип моего портала www.bpm3.ru (там можно купить Business Studio и заказать консалтинг, извините за продакт плейсмент).

Далее открывается персональная страница пользователя – см. рис. 2. Хотел бы обратить внимание, что какие-либо индикаторы обновления данных, наличия новых сообщений пользователю, приглашений и т.п. на персональной странице отсутствуют. Хотя большинство из нас, будучи пользователями социальных сетей, уже привыкло к таким фишкам, как например на ФБ. К сожалению, даже мое фото на персональную страницу вывести невозможно, не говоря уже о других индивидуальных настройках.
Стоит отметить, что в системе есть возможность отправлять уведомления об изменениях на почту пользователей.

Для настройки пиктограмм разделов нужно разместить новые файлы в системной папке BS Portal. Через интерфейс Business Studio сделать это не получится. А уж если говорить о настройке стилей, то придется редактировать файл css.

Разделы «Показатели», «Цели» и «Документы» формируются по умолчанию, хотя их можно отключить. Но я оставил – их вполне можно использовать. Было создано несколько новых разделов, внутри которых используются так называемые разделители. Например, есть раздел «Мои процессы и НСД». В нем первый разделитель – «Управление процессами». Внутри некоторых разделов в виде гиперссылок показаны названия отчетов, в некоторых – «Коммерческий директор». Дело в том, что движок Business Studio работает следующим образом. Для отчетов, сформированных по классу физические лица, он выводит название самого отчета. Для отчетов по классу «Субъекты» — название должности. Если бы я занимал две должности в рамках данной модели (например, был бы еще Директором ООО «СбытПромЗакупка» — дочерней компании), то кроме «Коммерческого директора» была бы видна должность «Директор». Дело в том, что разработчики считаю, что в компаниях физические лица часто занимают несколько должностей.

Кстати, функционал настройки персональной страницы в Business Studio выполнен весьма сложно – нужно провалиться вниз на 9 уровней различных меню (если я не сбился со счета), чтобы сделать все необходимые настройки. Чтобы их проверить – снова на 7 уровней вниз и т.п. Понятие «Предпросмотр» web-страницы отсутствует и проч. Нужно запустить портал на формирование, и только потом смотреть результат.

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

Контроль процесса по показателям

Давайте зайдем в раздел «Мои показатели» на персональной странице, выберем один из показателей и посмотрим, что покажет система как результат работы стандартного отчета. Результаты представлены на рис. 4.

Мы видим довольно унылый (с точки зрения дизайна) график изменения значений показателя. Но это даже неважно. В Business Studio нельзя:
• сделать график интерактивным;
• поменять тип диаграммы или цвета;
• гибко поменять видимую часть графика (подвигать шкалу времени), изменить масштаб;
• сравнить с другими показателями (на одном графике), посмотреть тренды;
• использовать диаграммы разного типа.

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

Так же в системе можно сделать своеобразный drill down. Если показатель является расчетным (т.е. считается по формуле на основе других показателей), то по гиперссылкам можно «провалиться» на отчет по соответствующему показателю.

Таким образом, если вы хотите контролировать показатели на BS Portal будьте готовы перемещаться между разными web-страницами с разными показателями (через Персональную страницу или Навигатор), с простейшей графикой и почти полным отсутствием интерактива. Можно сказать, что в BS Portal нет и 5% от функционала не самой дорогой BI-системы. Возможно, за свои деньги (1200 рублей за одну лицензию портала) это вполне адекватный функционал. Кроме того, хочу еще раз напомнить, что основное назначение системы – моделирование и регламентация деятельности организации. BS Portal нужен для вывода информации о моделях процессов и регламентов в интерактивном, гипертекстовом виде. Если эта задача для вас основная, то лучшего инструмента вы сегодня на рынке не найдете.

Мои процессы и НСД

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

Первый отчет – «Процессы, где я владелец» — позволяет быстро посмотреть все процессы, для которых сотрудник является владельцем. Таким образом ему не нужно перемещаться по навигатору и смотреть все процессы в базе знаний. На рис. 5 показан вид этого простого отчета – выводятся: название процесса, графическая схема, цели и показатели.

Возможность создания такого рода отчетов – «плюс» как самой Business Studio, так и BS Portal. Легкость доступа к разработанным моделям процессов очень важна. Часто, причем даже в крупных компаниях, процессная модель остается «военной тайной» подразделения организационного развития и не доводится до линейных руководителей. Но ведь именно они являются потребителями этой информации! BS Portal в такой ситуации может оказаться реальным решением проблемы информирования широких масс сотрудников о процессных наработках.

Следующий отчет – «Процессы, в которых я участвую». Его задача – показать все операции, которые выполняет сотрудник, занимающий данную должность. Важно быстро находить требования к работе, которую нужно выполнить. Перелистывать десятки (если не сотник) бумажных регламентов невозможно. Поэтому BS Portal дает отличную возможность доступа к информации регламентирующего характера. Результат работы отчета представлен на рис. 6. Хочу заметить, что вид таблицы определяется пользователем – можно вывести всё, что необходимо руководителю (например, требования к срокам, периодичность выполнения, даты и т.п.).

Пойдем далее. Отчет после разделителя «Мои НСД» выводит таблицу с перечнем нормативно-методических и справочных документов по всем процессам, в которых участвует сотрудник. При нажатии соответствующих гиперссылок можно перейти на стандартный отчет по документу и потом открыть его на просмотр – см. Рис. 7.

Вернемся к разделу «Мои процессы и НСД». Последний отчет в данном разделе подготовлен для демонстрации возможности вывода фотографий. В данном случае я создал справочник оборудования, используемого в процессе. Добавил (через Meta Edit) поле для закачки фотографий и сделал соответствующий отчет – см. рис. 8.

Естественно, кроме названия и фото можно добавить всё, что угодно – описание, технические характеристики, порядок подготовки к работе и проч.

Мои страт. карты

В разделе «Мои страт. карты» представлен простой отчет, который выводит стратегическую карту департамента, которым управляет должностное лицо (в данном случае – Коммерческий директор). Результат работы отчета представлен на рис. 9. Плюсом является тот факт, что схема стратегической карты является интерактивной – можно выбрать любую цель или показатель и перейти к соответствующему объекту.

Оперативный контроль

Рассмотрим, наконец, раздел «Оперативный контроль». В нем распложены несколько отчетов, которые связаны с задачей оперативного управления бизнес-процессами. Это важно.

Первый отчет – «Оперативный контроль процессов». Результат его работы показан на рис. 10. Фактически, представленная таблица – это электронный ежедневник владельца процесса, в котором он осуществляет фиксацию отклонений процесса от нормального хода. Делается это на основании контроля значений показателей (через тот же BS Portal). Почему не хватает только отчетов с показателями? Попытайтесь ответить на простой вопрос: «Как убедиться в том, что руководитель регулярно мониторил процесс, фиксировал отклонения и разбирался с ними?!» Всё в голове или ежедневнике… Если вы сторонник неконтролируемого, субъективного ручного управления, то для вас этот вопрос покажется надуманным.

Вернется к отчету. Он включает: дату проверки, показатель, суть отклонения, формулировку причины отклонения, выбор реакции (коррекция или корректирующее действие), описание коррекции (оперативной разовой задачи в рамках процесса, необходимой для устранения отклонения), плановую и фактическую даты и т.п. Возможна дополнительная аналитика, классификатор отклонений и т.п. В правой части таблицы (на рисунке не видна) указан ответственный исполнитель и статус («Выполнено», «Не выполнено»). В крайней правой ячейке – ссылка на так называемое «Сообщение о несоответствии», созданное владельцем процесса по факту выявления отклонения и принятия решения о выполнении корректирующего действия. Почему так? Дело в том, что в Business Studio создать корректирующее мероприятие можно путем создания «Сообщения о несоответствии» (функционал СМК), для которого нужно указать список мероприятий. Кроме того, мероприятия можно создать для объектов «Несоответствия» и «Причина». Кстати, посмотреть нужные мероприятия в системе можно, но это неудобно. Замечу, что при настройке отчетов я старался максимально использовать штатную структуру данных Business Studio, а не громоздить новые классы и объекты через Meta Edit.

Теперь хотел бы обратить внимание читателя на простой, но ключевой аспект – все указанные выше данные можно внести только через интерфейс Business Studio. Через BS Portal это сделать невозможно (как, впрочем, и редактировать регламенты в гипертекстовом виде – это моя мечта). Напомню, что одна лицензия Business Studio стоит 76 800 рублей. Т.е. если владелец процесса хочет вести ежедневник контроля отклонений в BS, ему нужно будет потратит эту сумму. Хотя, стоит отметить, что сообщения о несоответствиях можно вводить через модуль Cockpit, который стоит 980 рублей.

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

Следующий отчет, на котором я хотел бы остановиться – «Контроль исполнения НМД». Я считаю, что владелец процесса в рамках своих функциональных обязанностей должен оперативно (раз в день, раз в неделю) проводить выборочный контроль соблюдения требований регламентов сотрудниками. Результаты такого контроля могут быть занесены в соответствующую таблицу. По факту выявления отклонений могут быть запущены корректирующие мероприятия (в т.ч. изменение или актуализация самих регламентов). В своей новой книге «Бизнес по правилам: регламенты должны работать» (выходит осенью 2016 г.) я подробно описываю «Систему стандартизации бизнес-процессов». Оперативный контроль исполнения требований регламентов – это только ее часть.

Пример работы отчета представлен на рис. 11.

Как видно на рис. 11, в таблице есть такие столбцы, как: дата проверки, процесс, регламент (кстати по ссылке можно его открыть), пункт НМД (который проверялся), описание несоответствия и сообщение о несоответствии.

Следующий отчет – «КД, которые я контролирую». Расшифровка КД – корректирующие действия. Владелец процесса должен иметь оперативную информацию о статусе этих корректирующих действий. Иначе опять голова, ежедневник или Excel… Чуть не забыл 1С. Но в нем такие настройки есть далеко не во всех компаниях. Пример работы отчета представлен на рис. 12.

В отчете представлен перечень сообщений о несоответствии, корректирующие действия, даты и ответственный за выполнение КД, статус выполнения КД.

Последний отчет в рассматриваемом разделе – «Мои проекты» — см. рис. 13. При помощи этого отчета владелец процесса получает информацию по проектам внутреннего развития (PDCA), для которых он является контролирующим лицом. Опять же – приведена простейшая форма отчета. При желании можно вывести любые данные по проекту — даже График Ганта со статусом исполнения. Для этого можно присоединить соответствующий файл MS Project. При просмотре портала в MS Internet Explorer можно будет открывать этот файл на редактирование. На крайний случай, просто приложите скрин-шот из MS Project.

Но опять подчеркиваю, что для ввода данных потребуется полнофункциональная лицензия Business Studio. В BS Portal можно только просматривать информацию.

Другие разделы персональной страницы

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

Для прикола добавлен раздел «Мои фото», где сотрудник может что-то опубликовать. Однако механизм занесения фото в Business Studio таков – через текстовое поле формата rtf (тип атрибута «Изображение» хотя и есть в Meta Edit, но не поддерживается системой). Более правильный путь – создание специальных справочников через Meta Edit. В этом случае можно делать ссылки на файлы прямо из списка, доступного для каждой должности (процесса и т.п.).

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

Какие еще разделы можно добавить? Например, «Бенчмаркинг» или «Отзывы клиентов» и т.п. Важно помнить, для кого создается персональная страница. В этом контексте стоит обратить внимание на следующий момент. В BS Portal – внешний вид и структура персональной страницы (в т.ч. состав отчетов) не могут изменяться в зависимости от категории должности сотрудника. Например, для специалиста структура персональной страницы должна быть совершенно другой. Ему не нужны разделы по управлению процессом, аудитам и т.п. Но он увидит ту же страницу (как для «Коммерческого директора»), но большинство отчетов будут пустыми.

Резюме

Итак, подведем итоги. Что может Business Studio Portal в части поддержки оперативного управления бизнес-процессами:

Итог – соответствие функционала BS Portal задачам оперативного управления бизнес-процессами – всего 14%. Понятно, что моя оценка субъективна.

Таким образом, можно сделать вывод, что система Business Studio и ее модуль BS Portal в данной версии 4.1 не могут быть эффективно использованы для оперативного управления бизнес-процессами организации. Этот вывод нисколько не умоляет замечательных функциональных возможностей системы Business Studio в части моделирования и регламентации бизнес-процессов компании. Возможно, разработчики системы примут к сведению указанные выше моменты и доработают функционал BS Portal в следующих релизах системы.
Буду рад вашим вопросам и примерам использования BS Portal для организации управления процессами.

В.В. Репин, к.т.н., доцент, тренер, консультант по управлению.

Октябрь 2016 г.