Кейс: Как создать интегрированную среду для коллективной работы

Кейс: Как создать интегрированную среду для коллективной работы

Анатолий Белайчук Нач. отдела, зам. начальника, Москва

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-помощь и т.п. – возможно привести последовательность конкретных аргументов в пользу интегрированной среды:

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.

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

отладки и Средства разработки


К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer