В предыдущей части мы классифицировали сложившиеся формы коллективной работы: проекты, процессы, кейсы, документооборот, инциденты. Там же было сказано, что разделить их можно лишь умозрительно, в реальности они взаимосвязаны.
Характерно, что свод знаний по проектному управлению PMOK рассказывает не столько про проекты, столько про процессы управления проектами. В свою очередь, значительная часть свода знаний по процессному управлению CBOK посвящена проектам совершенствования бизнес-процессов.
Взаимозависимость проявляется в следующих формах:
1. Интероперабельность: инициирование коллективной работы одного вида из работы другого вида.
Примеры: кейсы инициируют процессы (лечение больного от поступления в больницу до выписки – кейс, процедура или анализ – процесс), процессы инициируют проекты (управление проектами согласно PMBOK).
2. Миграция: пересмотр взглядов на отнесение деятельности к определенному виду коллективной работы со временем.
Зачастую отнесение коллективной работы к проекту, процессу или кейсу – вопрос трактовки. Пример: фармацевтическая компания традиционно рассматривала разработку нового лекарственного препарата как проект. Затем пришла к идее типового шаблона проекта, а от нее – к пониманию того, что эту деятельность целесообразнее рассматривать как процесс.
Другой пример: популярность идей кейс-менеджмента отчасти объясняется тем, что по сравнению с процессами, работа с кейсами требует меньших начальных затрат. Поэтому, даже там, где деятельность является предсказуемой – процессной, рассматривать ее как кейс может быть более прагматичным вариантом. Вместо того чтобы заранее продумывать все варианты протекания процесса, рисовать и отлаживать схему процесса, исполнителям дают возможность самим выбирать траектории, а уже потом, накопив опыт кейсов и отобрав лучший, реализуют его в виде процесса.
3. Сквозное управление задачами и ресурсами: все формы коллективной работы в итоге порождают атомарные задачи, назначаемые зачастую одним и тем же исполнителям.
С точки зрения исполнителя содержание работы не меняется от того, выполняет ли он задачу в рамках проекта, процесса или кейса. Меняются только способы координации работ. Существенной разницы нет и с точки зрения руководителя: вне зависимости от того, по какому каналу поступают задачи, все они требуют ресурсов.
Классы ПО коллективной работы
Рассмотрим типичную функциональность различных классов программного обеспечения:
1. Электронная почта. Была и остается, пожалуй, самым распространенным средством. Не обеспечивает ни повторяемости, ни предсказуемости, ни структурированности – средство низкоуровневое, но зато универсальное и общедоступное.
2. Сетевые диски и файлообменники. Взаимодействие обычно по-прежнему обеспечивается электронной почтой, но становится более цивилизованным: по почте больше не пересылаются тяжелые вложения, версии документов как-то контролируются.
3. ECM-системы. Своему основному назначению поддержки жизненного цикла документа соответствуют идеально. Обладают массой преимуществ по сравнению с файлообменниками: контроль доступа, версионность, индексация и быстрый поиск по контенту, сканирование и преобразование контента, многоуровневая архивация. Поддержка процессов, как правило, на достаточно примитивном по сравнению с BPMS уровне (документоориентированные потоки работ), хотя известны программные продукты, сочетающие функциональность ECM и BPMS (EMC Documentum, связка Alfresco и Activiti).
4. Трекеры. Исходно появились как баг-трекеры (работа с дефектами ПО), со временем развились в средства управления и другими аспектами разработки ПО (пожелания по доработке, релизы и т.п.). Контролируют назначение ответственных, сроки и приоритеты. Позволяют вести обсуждение и прикреплять файлы. Благодаря появившейся таким образом универсальности стало возможным использовать их в качестве средства управления инцидентами, чем и воспользовались многие организации. Иногда используются для управления процессами, но возможности в этой части ограничены: только контроль жизненного цикла через атрибут «состояние».
5. Кейс-менеджмент (ACM, Adaptive Case Management). Этот класс систем еще формируется, и не всегда легко отделить рекламные обещания от реальной функциональности конкретного продукта. Тем не менее, можно сформулировать общие черты: динамически формируемые самими пользователями списки задач (чек-листы), поддержка структурированного и неструктурированного контента, экранные формы задач, бизнес-правила. К продвинутой функциональности можно отнести возможность сохранять кейс в виде шаблона, который будет помогать работать со следующими экземплярами.
6. ПО для управления проектами. Перечень задач и зависимости (последовательность выполнения), план-график (прогноз сроков), планирование ресурсов (трудозатрат), формирование сметы. Расширенная функциональность: расчет критического пути, планирование портфеля проектов с учетом конкуренции за общие ресурсы. Возможность работы со структурированными данными ограничена.
7. ПО для управления бизнес-процессами (BPMS, Business Process Management Suite). Моделирование процессов и данных, быстрая разработка экранных форм и скриптов, исполнение процессов движком, отчетность и аналитика. Расширенная функциональность: поддержка бизнес-правил, интеграция с внешними базами данных и информационными системами.
Итак, что мы видим: все четыре квадранта на рис. 2 из прошлой статьи покрыты:
- Трекер для инцидентов
- ACM для кейсов
- Проектное ПО для проектов
- BPMS для процессов
Это новость хорошая. Плохая же заключается в том, что обойтись одним инструментом не получится. Разве что у вас доминирует какая-то одна форма коллективной работы – например, вы рассматриваете свою организацию как чисто проектную.
Еще вариант – использовать более универсальный, но менее функциональный продукт, мирясь с его недостатками. Например, управлять процессами с помощью трекера или ECM. С помощью почты и файлообменника можно управлять вообще всем, но контролировать работу при этом придется вручную.
Можно поступить и наоборот: например, реализовать управление инцидентами и поручениями средствами BPMS. Это не так уж сложно, но решение получится более дорогим и более громоздким по сравнению со специализированным трекером.
Еще ближе друг к другу задачи кейс-менеджмента и управления инцидентами – покрыть и те, и другие средствами ACM выглядит вполне разумным решением.
Преимущества единой среды коллективной работы
Почему несколько средств поддержки коллективной работы – это плохо? Помимо стандартных доводов – усложнение IT-архитектуры, более дорогая IT-поддержка и т.п. – можно привести ряд конкретных доводов в пользу интегрированной среды:
1. Интероперабельность.
2. Поддержка миграции.
3. Единое управление задачами. Как уже отмечалось выше, с точки зрения исполнителя нет особой разницы между задачами, назначаемыми ему в рамках проекта, процесса, кейса или инцидента. Но если всеми этими видами работ управляют разные информационные системы, то разница появляется, и существенная. Ведь у каждой системы свой интерфейс (свой веб-портал), каждый надо освоить.
Кроме того, отличаться будет и функциональность на уровне управления задачами. Скажем, одна система умеет автоматически делегировать задачи на время отпуска, другая – нет, одна умеет автоматически учитывать затраты времени исполнителя, другая – нет. У каждой свой способ уведомления о назначении задач, у каждой свой аудиторский журнал…
4. Сквозное управление ресурсами. Часто ли сотрудники участвуют только в проектах или только в процессах? И как быть в тех случаях, когда они участвуют и в тех, и в других, а сверх этого им назначаются разовые поручения? Как понять – отлынивает сотрудник от участия в проекте, только ссылаясь на текучку, или действительно перегружен, и рассчитывать на его плотное участие в проекте объективно означает ставить проект под угрозу?
Если проекты и процессы управляются с помощью разного ПО, сделать это будет проблематично. Помимо простого наличия двух сред и механических проблем агрегации данных, здесь есть проблема методическая: проекты и процессы принципиально по-разному подходят к планированию ресурсов. Для людей, привыкших иметь дело с проектами, первое знакомство с процессной системой может быть шоком. Они задают естественный, на их взгляд, вопрос: «Как здесь узнать, когда процесс завершится?» И получают ответ: «Когда завершится данный экземпляр процесса – неизвестно. В среднем продолжительность процесса составляет столько-то». То есть в процессах продолжительность и трудозатраты оцениваются в вероятностных терминах. В отличие от проектов, где план-график дает точный ответ на эти вопросы.
Ну как точный? Если присмотреться, точность проектных оценок условна. График проекта может быть пересмотрен, сроки и трудоемкость изменятся. Так что это тоже, в общем-то, оценка вероятностная, просто обычно на этом не акцентируют внимание.
5. Общая платформа. К любой системе коллективной работы сегодня предъявляются стандартные требования: возможность работы в «облаке», поддержка мобильных устройств (планшетов и смартфонов), поддержка социального взаимодействия (по образцу Facebook и Twitter, но внутри компании). Удовлетворить эти требования непросто и объективно дорого. А если эти функции реализовывать для каждой среды коллективной работы по отдельности, то очень дорого.
Кроме того, кому нужны несколько социальных сетей внутри компании? Скорее всего, при таком подходе ни одна не наберет критической массы активных участников, и идея засохнет на корню, как это произошло с идеей интранета.
Требования к среде коллективной работы
На сегодняшний день единую среду, поддерживающую все рассмотренные формы коллективной работы, не может предложить ни один производитель программного обеспечения. Но проблема, судя по всему, назрела, и ряд компаний ведет работы в этом направлении – например, OpenText, IBM, SAP, российская EleWise. Компания Comindware сделала разработку такой среды своей миссией, что отражено в ее названии.
Попробуем представить себе облик перспективной единой среды, поддерживающей все рассмотренные формы коллективной работы:
1. В кейс-менеджменте есть все необходимое для управления инцидентами и документооборотом.
От документооборота кейс-менеджмент отличается поддержкой структурированных данных. Неструктурированную информацию (контент) поддерживают оба. От инцидента кейс отличается повторяемостью. То есть по отношению к обоим кейс-менеджмент обладает избыточностью, но не критичной.
Вывод: отдельные функции для управления поручениями, инцидентами, документами не требуются, все покрывается кейсами.
2. Кейсы и процессы – разные, но органично дополняющие друг друга формы коллективной работы.
Разница между ними в том, что процесс – предсказуемая, кейс – непредсказуемая работа. В случае процесса задача создается и ее исполнитель назначается в соответствии со схемой процесса, в случае кейса и то, и другое делается по усмотрению пользователя. Можно сказать, что кейс – это динамически формируемый процесс, не требующий предопределенной схемы.
Вывод: поддержка кейсов и процессов должна быть максимально интегрирована. Мониторинг и аналитика могут и должны быть унифицированы.
3. Кейсы отличаются от проектов структурированностью, повторяемостью и непредсказуемостью. Процессы отличаются от проектов структурированностью и повторяемостью.
Как и в случае инцидентов и документов, структурированность может рассматриваться как избыточная функциональность. Повторяемость – аналогично. Более интересна ситуация с непредсказуемостью кейсов. Возможность спланировать все задачи проекта от начала до конца (пусть и внося корректировки в этот план в дальнейшем) – обязательная функциональность управления проектами. Теоретически, можно добавить к кейсам возможность создавать задачи не только «на сейчас», но и на будущее. Это потребует планирования продолжительности и ресурсов, описания всех вариантов зависимости задач и т.д. Реализовать это можно, но это сделает систему намного более громоздкой, и в результате потеряется главное преимущество управления кейсами – легкость использования.
Поэтому проекты, процессы и кейсы – разные сущности. Но при этом должны быть обеспечены интероперабельность и миграция.
4. Относительно предсказуемости процессов и проектов.
Как было отмечено выше, предсказуемость эта разная: проект предсказуем на уровне экземпляра (что наглядно отображается диаграммой Генри Ганта), процесс – на уровне статистических характеристик совокупности экземпляров процесса. Впрочем, при более внимательном рассмотрении обнаруживается, что это различие не принципиальное: никто не мешает отобразить уже завершенные задачи процесса в виде диаграммы Ганта, снизив таким образом барьер между проектами и процессами.
Что касается будущих задач процесса, то спрогнозировать их – задача более сложная, но тоже решаемая. Опираясь на историю выполнения предыдущих экземпляров процессов, статистическими методами можно спрогнозировать наиболее вероятную последовательность задач текущего экземпляра, сроки завершения и т.п. Чтобы прогноз был более точным, можно принять во внимание значения атрибутов данного экземпляра процесса.
Общие функциональные требования
1. Поддержка как неструктурированных, так и структурированных данных.
Неструктурированные данные поддерживаются в проектах, процессах и кейсах. Структурированные данные в процессах и кейсах обязательны, в проектах – опциональны. Система должна предоставлять возможность работы с данными и напрямую, без участия процесса или кейса. Существующие системы BPMS имеют для этого все необходимое – средства моделирования данных, средства разработки экранных форм, но возможность работы с данными напрямую в них, как правило, не предусмотрена. Это выглядит как искусственное ограничение, от которого следует избавиться.
2. Унифицированное управление задачами.
Вне зависимости от того, откуда пришла задача – из проекта, процесса или кейса – она должна отображаться в общем списке задач, на нее должны распространяться общие правила делегирования и т.д.
3. Сквозное управление ресурсами.
Учет трудозатрат и планирование загрузки ресурсов должны осуществляться с учетом задач и проектных, и процессных, и порожденных кейсами. Для планирования будущей загрузки ресурсов в процессах и кейсах необходимо использовать вероятностные методы, упомянутые выше.
4. Поддержка социального взаимодействия.
Ленты комментариев к проектам, задачам, бизнес-объектам, людям. Лайки, подписки, инвайты, уведомления и т.п.
Системные требования
1. База данных. Если системам управления процессами, с их разделением на среду разработки и среду исполнения, достаточно реляционной базы данных, то кейс-менеджмент требует возможности добавлять атрибуты бизнес-объектов «на лету». Такую гибкость способны обеспечить семантические базы данных.
2. Размещение в облаке или локально. По усмотрению заказчика, система должна быть доступной в виде облачного сервиса по подписке или в виде традиционного дистрибутива для инсталляции на собственных серверах заказчика.
3. Клиентское ПО. Все сто процентов функциональности (включая моделирование схем процессов, проектирование структур данных, экранных форм, бизнес-правил и т.п.) должны быть доступны через веб-браузер. Должны поддерживаться мобильные клиенты для основных платформ (iOS, Android). Должна поддерживаться работа с задачами из Outlook.
Требования к интеграции с онлайновыми сервисами, унаследованными системами и источниками данных мы оставим за рамками статьи.
Нужно уметь работать с людьми.
Умение работы с людьми - это одно, а IT-инструменты для работы с данными - это совершенно другое! IT-инструменты не работают с людьми. И без умения работы с людьми никакие IT-инструменты ничего не дадут - проверенный факт!
А что действительно интересно выяснить - так это то, для кого написана данная статья.
относительно ''На сегодняшний день единую среду, поддерживающую все рассмотренные формы коллективной работы, не может предложить ни один производитель программного обеспечения. '':
очень спорное утверждение, я лично знаю решение и автора разработки ИС в РФ, создаваемые по единой модели деятельности в ОДНОЙ ИС, с ОДНОЙ СУБД, с инструментами управления для менеджмента, а не для ИТ, позволяющее избавиться от внедрения интегрированного пространства и работать в едином информационном пространстве не только в своей организации или холдинге, включая все дочерне-зависимые организации, но и взаимодействовать с контрагентами на входе и выходе используя единую ИС. Нужно просто поставить себе правильную цель. Если ставить изначально цель создавать интегрированную среду для работы это одно, если ставить цель быть эффективным это совсем другая история.
так все таки - цель статьи ''Как создать интегрированную среду для коллективной работы'' заниматься интеграцией или делать бизнес, используя то, что дает эффективность, следовательно, минимизировать себестоимость?
Заниматься интеграцией ужа с ежом, это не задача бизнеса. Продукты для интеграции возникли как предложение бизнесу от ИТ отрасли, при отсутствии в момент поиска решений альтернатив интеграционному подходу при создании ИС.
Цель бизнеса в отношении ИТ проста и определена мной как:
Создание систем управления бизнесом с единым контуром ИТ, например, с процессно проектным управлением. Реализуемые системы управления должны позволять организации взаимодействовать во внутренней среде и с внешним миром через сквозные и кросс-функциональные процессы в системе.
Следовать ИТ-отрасли этой цели, означает синергию усилий бизнеса в достижении своих целей, а ИТ получение спроса на продукт, предлагаемый бизнесу.
Ключевые слова ''интегрированная среда'' и ''коллективная работа'' точно определяют содержание статьи.
В целом считаю публикацию интересной и полезной, но хотелось бы сделать некоторые комментарии.
1. В статье не определены виды содержательной деятельности организаций, в которых и для которых рассматриваются и развиваются феномены интегрированности и коллективизма. Одно дело, департамент какого-нибудь министерства, хлопочущий, как осложнить жизнь народу своими новыми выдумками, и другое дело, например, проектная компания, реально отвечающая за деньги.
Первым никакие кейсы (кроме шаблонов писем) не требуются, а из процессов там воспринимается только процедура согласования очередной бумаги на подпись большому начальнику, для чего почты вполне достаточно на много лет вперед.
Хотя в моей практике был случай, когда идеалом групповой работы министерского департамента был признан вордовский механизм заметок (когда он появился в микрософте) от разных читателей, разноцветными вставками закрывающий весь горизонт представлений о счастье бюрократа. Очень это нравилось, поскольку видно, что и кто когда сказал или промолчал. Но затея эта не получила распространения, никто не стал свою умность или наоборот, вставлять в тексты, при этом торможение другим процессам создания передовой и современной среды задала серьезное.
По содержанию статьи можно полагать, что разбор ситуации ведется все же для разрабатывающей компании, а точнее - для IT.
Но есть масса промежуточных объектов между этими крайними случаями, хотелось бы понять, что в отношении например, холдинговых, и особенно производственных структур, там как с интегрированностью и групповой работой дело обстоит.
2. В любой структуре интегрированность будет неполной, если не учитывать такие аспекты управления как кадровая служба, плановики, финансисты и т.д. Т.е., например, группа разработчиков проекта работает не в вакууме, а в составе подразделений организации и требуется понимание, как соответствующие корпоративные системы включать в некую идеальную среду и как они будут влиять на групповую работу. А оттуда есть чему влиять на тот же проект...
3. Понимаю, что доказательную часть преимуществ интегрированной коллективной среды добыть нелегко, однако именно этого не хватает в статье, чтобы составить представление, что такое хорошо и что такое плохо с этим делом в организации. Пусть хотя бы на качественном уровне, для начала.
Потому что, в противном случае возникает ощущение типа ''иного не дано'', ''или - или'' и подобных безысходных заключений.
Что, очевидно, в жизни не так.