Концепция единой среды коллективной работы

Анатолий Белайчук, евангелист BPM Comindware, Inc к.т.н., CBPP

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

Характерно, что свод знаний по проектному управлению PMBOK рассказывает не столько про проекты, столько про процессы управления проектами. В свою очередь, значительная часть свода знаний по процессному управлению CBOK посвящена проектам совершенствования бизнес-процессов.

Взаимозависимость проявляется в следующих формах:

1)     Интероперабельность: инициирование коллективной работы одного вида из работы другого вида.

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

2)     Миграция: пересмотр взглядов на отнесение деятельности к определенному виду коллективной работы со временем.

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

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

3)     Сквозное управление задачами и ресурсами: все формы коллективной работы в итоге порождают атомарные задачи, назначаемые зачастую одним и тем же исполнителям.

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

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

Классы ПО коллективной работы

Рассмотрим типичную функциональность различных классов программного обеспечения:

Электронная почта. Была и остается, пожалуй, самым распространенным средством. Не обеспечивает ни повторяемости, ни предсказуемости, ни структурированности – средство низкоуровневое, но зато универсальное и общедоступное.

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

ECM-системы. Своему основному назначению поддержки жизненного цикла документа соответствуют идеально. Обладают массой преимуществ по сравнению с файлообменниками: контроль доступа, версионность, индексация и быстрый поиск по контенту, сканирование и преобразование контента, многоуровневая архивация. Поддержка процессов, как правило, на достаточно примитивном по сравнению с BPMS уровне (документо-ориентированные потоки работ), хотя известны программные продукты, сочетающие функциональность ECM и BPMS (EMC Documentum, связка Alfresco и Activiti).

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

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

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

ПО для управления бизнес-процессами (BPMS, Business Process Management Suite). Моделирование процессов и данных, быстрая разработка экранных форм и скриптов, исполнение процессов движком, отчетность и аналитика. Расширенная функциональность: поддержка бизнес-правил, интеграция с внешними базами данных и информационными системами.

Итак, что мы видим: все четыре квадранта на рис. 2 из прошлой статьи покрыты:

●   Трекер для инцидентов

●   ACM для кейсов

●   Проектное ПО для проектов

●   BPMS для процессов

Это новость хорошая.

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

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

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

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

Преимущества единой среды коллективной работы

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

Интероперабельность (см. выше).

Поддержка миграции (см. выше).

Единое управление задачами

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

Кроме того, отличаться будет и функциональность на уровне управления задачами. Скажем, одна система умеет автоматически делегировать задачи на время отпуска, другая – нет, одна умеет автоматически учитывать затраты времени исполнителя, другая – нет. У каждой свой способ уведомления о назначении задач, у каждой свой аудиторский журнал…

Сквозное управление ресурсами

Часто ли сотрудники участвуют только в проектах или только в процессах? И как быть в тех случаях, когда они участвуют и в тех, и в других, а сверх этого им назначаются разовые поручения? Как понять – отлынивает сотрудник от участия в проекте, только ссылаясь на текучку, или действительно перегружен, и рассчитывать на его плотное участие в проекте объективно означает ставить проект под угрозу?

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

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

Общая платформа

К любой системе коллективной работы сегодня предъявляются стандартные требования: возможность работы в «облаке», поддержка мобильных устройств (планшетов и смартфонов), поддержка социального взаимодействия (по образцу Фейсбука* и твиттера, но внутри компании). Удовлетворить этим требованиями непросто и объективно дорого. А если эти функции реализовывать для каждой среды коллективной работы по отдельности, то очень дорого.

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

Требования к среде коллективной работы

На сегодняшний день единую среду, поддерживающую все рассмотренные формы коллективной работы, не может предложить ни один производитель программного обеспечения. Но проблема, судя по всему, назрела, и ряд компаний ведет работы в этом направлении – например, OpenText, IBM, SAP, EleWise. Компания Comindware сделала разработку такой среды своей миссией, что отражено в ее названии.

Попробуем представить себе облик перспективной единой среды, поддерживающей все рассмотренные формы коллективной работы:

1.     В кейс-менеджменте есть все необходимое для управления инцидентами и документооборотом.

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

От инцидента кейс отличается повторяемостью.

То есть по отношению к обоим кейс-менеджмент обладает избыточностью, но не критичной.

Вывод: отдельные функции для управления поручениями, инцидентами, документами не требуются, все покрывается кейсами.

2.     Кейсы и процессы – разные, но органично дополняющие друг друга формы коллективной работы.

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

Вывод: поддержка кейсов и процессов должна быть максимально интегрирована.  Мониторинг и аналитика могут и должны быть унифицированы.

3.     Кейсы отличаются от проектов структурированностью, повторяемостью и непредсказуемостью. Процессы отличаются от проектов структурированностью и повторяемостью.

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

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

Поэтому проекты, процессы и кейсы – разные сущности.

Но при этом должны быть обеспечены интероперабельность и миграция.

4.     Относительно предсказуемости процессов и проектов.

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

Впрочем, при более внимательном рассмотрении обнаруживается, что это различие не принципиальное: никто не мешает отобразить уже завершенные задачи процесса в виде диаграммы Гантта, снизив таким образом барьер между проектами и процессами.

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

Общие функциональные требования:

5.     Поддержка как неструктурированных, так и структурированных данных.

Неструктурированные данные поддерживаются в проектах, процессах и кейсах.

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

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

6.     Унифицированное управление задачами.

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

7.     Сквозное управление ресурсами.

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

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

8.     Поддержка социального взаимодействия.

Ленты комментариев к проектам, задачам, бизнес-объектам, людям. Лайки, подписки, инвайты, уведомления и т.п.

Системные требования:

9.     База данных.

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

10.  Размещение в облаке или локально.

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

11.  Клиентское ПО.

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

Должны поддерживаться мобильные клиенты для основных платформ (iOS, Android).

Должна поддерживаться работа с задачами из Outlook.

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

Источник: Comindware Inc.

* - организация, признанна экстремистской на территории РФ