Процессный офис: как организовать работу

Начиная с версии 6, в Business Studio представлены две нотации для проектирования процессов на верхнем уровне: VAD и IDEF0. Моделировать в VAD можно с использованием встроенного в систему редактора, в IDEF0 – при помощи MS Visio. В 7-й версии Business Studio доступен только встроенный редактор, который поддерживает две рассматриваемые нотации моделирования.

На рис. 11 представлен еще один пример модели архитектуры бизнес-процессов компании, выполненной в нотации VAD.

Рис. 11. Архитектура бизнес-процессов в нотации VAD

На самом верхнем уровне архитектурная модель в нотации VAD выглядит как плитка (реестр в графической форме), состоящая из категорий процессов («рыбок») без каких-либо визуальных связей в виде стрелок между ними (в самой же модели Business Studio создается связь типа «Композиция» через вложение в родительскую фигуру). Если визуальная связь между объектами в виде стрелок есть (в Business Studio можно выбрать для этого связь «предшествует»), то она может рассматриваться в качестве «декоративной». Никакой осмысленной нагрузки с точки зрения системной модели связи такого типа на диаграмме верхнего уровня не несут, так как никакого потока работы (work flow), непосредственно запускающего один процесс строго после завершения другого, на верхнем уровне не бывает. Это диаграммы структурного типа, а не алгоритмов.

В Business Studio можно создавать несколько представлений архитектуры, в том числе:

1) строить диаграммы с использованием группы функций VAD (как показано на рис. 11, использован тип связи «Композиция»);

2) строить дерево бизнес-процессов на одной диаграмме VAD с использованием типа связи «Композиция»;

3) строить дерево бизнес-процессов в виде отдельной диаграммы (рис. 12) с использованием типа связи «Агрегация»; далее можно привязать эту диаграмму к существующему объекту справочника «Архитектура бизнес-процессов компании».

Рис. 12. Архитектура бизнес-процессов (фрагмент) в нотации VAD в виде дерева, построенная с использованием типа связи «Агрегация»

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

Если при работе в Business Studio 6 выбран редактор MS Visio, то можно моделировать бизнес-процессы верхнего уровня в нотации IDEF09. При этом функциональные возможности по настройке визуального вида модели (вывод на показ параметров, визуальные стили) будут работать так же, как было в версии 5. Нужно понимать, что при использовании встроенного редактора и нотации VAD визуальная настройка модели может быть выполнена с использованием совершенно других, новых функциональных возможностей Business Studio 6 (7) – через стили, которые дают широкие и гибкие возможности по «кастомизации» визуального вида диаграмм.

Многие бизнес-аналитики задаются вопросом: «А какую нотацию лучше использовать для моделирования архитектуры бизнес-процессов компании?» С точки зрения профессионального процессного архитектора разницы нет. Главное – иметь правильный методический подход к созданию архитектуры. Но тем не менее я приведу здесь таблицу сравнительного анализа этих двух нотаций10 (таблица 9).

Чем нотация VAD привлекает многих руководителей и бизнес-аналитиков? Схемы можно «нарисовать» быстро. Это очевидно ключевое преимущество. Но какой ценой достигается эта быстрота? «Плитку» из «рыбок» в VAD можно сделать, но обоснование структуры бизнес-процессов на каждом уровне остается как бы за кадром. Процессный архитектор обязан использовать четкую методику построения архитектуры, определить границы каждого процесса и увязать их между собой по входам и выходам. Эта информация может быть структурирована в виде таблицы MS Excel, например. Но также она может остаться только в голове архитектора модели, что крайне плохо. Кроме того, отсутствие информации о границах процессов на схеме в нотации VAD может привести к ненужным дискуссиям руководителей при обсуждении архитектурных моделей компании.

Использование нотации VAD на среднем уровне также вызывает вопросы. Дело в том, что это почти BPMN, только без четкой логики – нет движения токенов, нет событий и шлюзов. Но зачем нужна такая «недонотация» – ни структурная, ни исполняемая?

Интересно разобраться, как вообще возникла нотация VAD. Концепция выявления и анализа цепочек создания ценности организации принадлежит Майклу Портеру. Это продуманная и практически полезная методология. Но вот нотация VAD, насколько я понимаю, – это детище профессора А. В. Шеера. Когда-то давно Шееру с его фирмой IDS Scheer нужно было (с маркетинговой точки зрения) отмежеваться от якобы «устаревшего метода функциональной декомпозиции IDEF0» и прикрыться красивой методологией цепочек создания ценности Майкла Портера. Только и всего… Какой-то глубокой методологии рисования «зеленых рыбок» у Шеера не было. Но вернемся к вопросу работы с архитектурой бизнес-процессов.

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

Они обусловлены:

• изменениями структуры компании и границ бизнес-процессов;

• изменением существующих бизнес-процессов;

• созданием новых бизнес-процессов;

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

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

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

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

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

По ходу работы создается большое количество моделей в нотации BPMN (eEPC). Необходимо контролировать их соответствие «Соглашению по моделированию» (формальное соответствие) и содержательное качество моделей.

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

4. Поддержание справочников архитектурной модели компании

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

• организационная структура;

• ролевая структура;

• документы;

• информация;

• события;

• программные продукты;

• хранилища (базы) данных;

• материальные объекты;

• цели и показатели;

• термины и определения;

• риски;

• проекты;

• прочие.

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

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

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

В последнее время некоторые клиенты в качестве одного из ключевых критериев выбора системы рассматривают «возможность быстро начать моделировать процессы» – открыл систему и «нарисовал», что нужно. Изучать нотации и методы построения архитектуры не обязательно, ошибки система должна выявлять сама, «токены должны красиво бегать по схеме» и т. п. Не хочется говорить о плохом, но это очень похоже на следствие фрагментированного, клипового мышления. В интернете нашел такое определение: «Клиповое мышление – это вид сознания, при котором человек воспринимает информацию через короткие форматы и яркие образы и способен быстро переключаться с одной информации на другую из-за поверхностного погружения в ее суть. Принято считать, что при клиповом мышлении мозг воспринимает информацию фрагментарно и небольшими порциями. Этому виду сознания приписывают самые разные симптомы и свойства – рассеянность внимания и концентрации, неспособность строить логические связи, неумение воспринимать большие объемы данных…» Если у процессных аналитиков компании будет преобладать такой тип мышления, то потребность в сложных, системных решениях постепенно будет сходить на нет.

Как проявляется такой подход при создании корпоративной процессной архитектуры? В справочнике процессов возникает куча папок по фамилиям сотрудников, в которых они создают модели процессов, например, в нотации BPMN. При этом единые справочники документов, событий и другие наполняются хаотично, бессистемно, как попало. Различные, ненормированные названия, множество дублирующих друг друга объектов. При этом никакая архитектура бизнес-процессов (в нотации IDEF0 или VAD) не создается.

Однако через какое-то время руководители организации все-таки задают вопрос руководителю процессного офиса: «А можно как-то в целом посмотреть на наши процессы? Где у вас общая модель (ландшафтная карта, архитектура) бизнес-процессов?» Возникновение этого вопроса свидетельствует о том, что руководство в определенной степени «дозрело» до реального использования процессной модели для целей управления и развития компании (например, для описания и оптимизации кросс-функционального бизнес-процесса закупок и пр.). И тут начинаются проблемы. Собрать из огромного числа разрозненных, не связанных между собой общей архитектурой процессов что-то стройное и понятное крайне сложно. Справочники забиты мусором, для расчистки которого нужно потратить титанические усилия и т. п. Через это проходят практически все, кто начал с «простого и быстрого рисования процессов». Поэтому я очень скептически отношусь к ситуации, когда представитель организации говорит, что хочет «быстро начать моделировать процессы в системе».

Есть ли альтернатива клиповому моделированию бизнес-процессов? Да, конечно.

Во-первых, как я неоднократно писал выше, в организации должны быть процессный архитектор и процессный методолог – специалисты с опытом работы (если их нет, то нужно учить того, кто есть). Во-вторых, нужно разработать внутренний стандарт – «Соглашение по моделированию» – и строго ему следовать. В-третьих, нужно обучить сотрудников нотациям моделирования, методам построения архитектуры и знанию функциональных возможностей Business Studio (или любой другой выбранной системы класса Enterprise Architecture).

На рис. 13 показан пример, как выглядит справочник «Деятельность» при создании процессной архитектуры организации с использованием нотации VAD в программном продукте Business Studio 6.

На рис. 14 показан справочник организационной и ролевой структуры (в Business Studio 6 он называется «Оргединицы»). Почему этот справочник должен быть частично заполнен в первую очередь? При создании архитектуры бизнес-процессов на схемах верхнего уровня желательно показывать должности владельцев процессов и наименование подразделений – исполнителей. Руководители верхнего уровня при работе с архитектурными схемами всегда хотят видеть эту информацию.

Рис. 13. Справочник «Деятельность» при использовании нотации VAD в Business Studio 6

Привязка владельцев процессов к процессам верхнего уровня дает возможность сформировать матрицу ответственности – Business Studio делает это на любую глубину процессного дерева. Матрица ответственности – это важнейший инструмент управления. Потребителями этого документа являются собственники и топ-менеджеры компании.

Рис. 14. Справочник организационной и ролевой структуры

в Business Studio 6

При переходе на уровень операционных исполняемых бизнес-процессов (модели в нотации BPMN) в Business Studio нужно создавать дорожки на основе должностей или ролей (также можно использовать программное обеспечение). Если каждый процессный аналитик будет создавать эти должности и роли «на ходу» и как попало, то очень скоро справочник будет представлять собой информационную помойку. Например, один сотрудник создаст должность «Руководитель отдела продаж», другой – «Начальник Отдела продаж», третий – «Руководитель ОП» и т. д. То же самое касается ролевой структуры. Поэтому лучше всего, если первичное заполнение справочника «Оргединицы» в части организационной структуры компании выполнит процессный методолог с учетом требований и правил, сформулированных в «Соглашении по моделированию» организации.

Роли в процессах и информационных системах (например, в 1С: ДО) могут создаваться по ходу проектирования бизнес-процессов компании. Заранее неизвестно, какие именно роли потребуются. Но папки для группировки ролей можно и нужно создать заранее. Правильный подход – создавать папки по названию процессных категорий компании.

Но можно и по названию крупных структурных подразделений. Обычно мы используем два уровня группировки ролей в виде папок. На третьем уровне можно создавать сами роли. Кстати, Business Studio позволяет создавать дочерние роли, например у роли «ИТ-администратор» может быть дочерняя роль «Администратор 1С: ДО» и т. п.

Кроме ролей и должностей, Business Studio позволяет создавать так называемые «Группы оргединиц». В такого рода объекты можно включать любые должности и роли из основного справочника с использованием типа связи «Агрегация». Это очень удобно для моделирования различных коллегиальных органов управления, например «Процессный комитет», «Правление», «Временная рабочая группа по проекту оптимизации бизнес-процесса» и т. п.

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

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

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

Рис. 15. Справочник документов в Business Studio 6

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

Вторая часть справочника «Документы» – это папка «Утвержденные ВНМД». ВНМД – внутренние нормативно-методические документы: политики, стандарты, регламенты, положения, инструкции и т. д. Частично эти документы могут быть сформированы на основе моделей бизнес-процессов, выгружены из Business Studio, согласованы, утверждены, отсканированы. Все утвержденные и отсканированные ВНМД помещаются в справочник Business Studio.

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

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

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

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

Отмечу, что документы в справочнике мы рассматриваем в широком смысле, например «Карточка контрагента» в 1С или «Запрос клиента через форму сайта» – это тоже документы.

На рис. 16 показан справочник, в котором я моделирую так называемые статусы документов.

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

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

Для создания статусов используется раздел «Термины» в справочнике «Функциональные объекты». Создавать статусы должен процессный методолог. Более того, желательно запретить остальным участникам проекта создавать свои статусы. Иначе через какое-то время в справочнике будет много мусора – неадекватно определенных, ненужных для моделирования статусов.

Рис. 16. Справочник статусов документов в Business Studio 6

Приведу несколько примеров использования статусов документов:

1) «Договор с клиентом», статусы «Согласован» и «Word»;

2) «Бюджет закупки», статусы «Утвержден» и «Excel»;

3) «Приказ», статусы «Утвержден» и «Бум.»;

4) «Контрагент», статусы «1С: ДО» и «Помечен на удаление»;

5) «Заявление на отпуск», статусы «Шаблон» и «Word».

На рис. 17 показан пример заполнения справочника «Программные продукты».

Рис. 17. Справочник «Программные продукты» в Business Studio 6

Можно группировать программное обеспечение с использованием папок, например «Корпоративное ПО», «Пользовательское ПО» и пр.

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

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

На рис. 18 показан справочник «Базы данных». На схемах в нотации BPMN объект из такого справочника выглядит как бочонок. Для описания процессов удобно интерпретировать эти «базы данных» в широком смысле – как хранилища для документов. Пример:

1) договор в формате MS Word разработан и хранится на компьютере – используется объект «ПК работника»;

2) далее договор отправляется по e-mail другому сотруднику – используется объект «Outlook», то есть файл с договором некоторое время «живет» в Outlook;

3) затем сотрудник загружает договор с 1С: ДО – используется объект «1С: ДО»;

Рис. 18. Справочник «Базы данных» в Business Studio 6

4) после согласования договор распечатывается, подписывается и потом попадает в архив – используется объект «Бум. архив».

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

Справочники «Информация» мы, как правило, в проектах не используем, поскольку вполне достаточно справочника «Документы». Если посмотреть свойства объектов «Документ» и «Информация» в Business Studio, то видно, что они практически не отличаются.

Но при моделировании крайне нежелательно плодить лишние сущности, дублирующие друг друга.

Что касается справочника «Материальные объекты», то он используется весьма редко. Для моделей процессов в нотации BPMN вполне достаточно объектов из справочника «Документы».

4.4. Описание и анализ бизнес-процессов компании

1. Формирование временных рабочих групп из сотрудников компании

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

На рис. 19 представлен пример структуры ВРГ. Она включает руководителя ВРГ, несколько (2—3) экспертов в предметной области (руководители и специалисты), бизнес-аналитика процессного офиса. В некоторых случаях может быть внешний эксперт – консультант по управлению, отраслевой эксперт и пр. Общая численность ВРГ не должна превышать 5—7 человек. Если проект сложный, то лучше создать несколько ВРГ по 3—5 человек, чем одну большую группу из 15—20 человек.

Рис. 19. Структура временной рабочей группы

Бизнес-аналитики процессного офиса помогают формировать ВРГ. У каждой группы должен быть руководитель. Это может быть как владелец процесса, так и руководитель или ведущий специалист структурного подразделения.

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