Обзор возможностей российской системы проектного управления
Основная задача любой коммерческой деятельности — создание и донесение до клиента ценности. Каждая такая ценность — это результат либо проектной деятельности (создание нефтегазовой скважины, строительство, разработка заказного ПО), либо процессной (добыча и переработка нефти, коммунальное обслуживание здания, разработка продуктового ПО).
В обеих бизнес-моделях есть команды, работающие по противоположной схеме, но являющиеся неотъемлемой частью потока создания ценности, например, отдел снабжения в буровой компании или отдел маркетинга в управляющей. Существующие программные решения по управлению проектами или бизнес-процессами предлагают сделать упор на цифровую трансформацию только одной части этого потока, а любое включение сотрудников соседнего лагеря происходит через вспомогательные механизмы, автоматизация которых весьма поверхностна. Безусловно, это очевидная точка улучшения, и многие компании пытались ее так или иначе реализовать. Из тех, что я видел, были попытки решения с помощью задач Microsoft SharePoint в интеграции с Project Server, а также через Oracle Primavera P6, интегрированную с заданиями исполнителям в Directum 5.
В том числе и сами вендоры систем управления проектами придумывали всевозможные трюки для вовлечения всех конечных исполнителей в работу, но в основном безуспешно. Как и любые попытки интеграции, обычно это приводит к тому, что толком не работающая система отторгается либо «проектными», либо «процессными» представителями компании.
Проекты и процессы
Чтобы ярче подчеркнуть проблему, выше мы противопоставили эти два полушария мозга компании, но на самом деле это не совсем так. Если посмотреть сверху на весь жизненный цикл проектов, то он включает в себя минимум три процесса:
- Сбор проектных инициатив (к этому подталкивают всевозможные Lean, Кайдзен, 6-сигм и пр.).
- Планирование/контроль/актуализация планов проектов.
- Постпроектный мониторинг эффективности.
Обычно эти процессы формализуют в нормативной документации. Сотрудники ведут их с присущим им человеческим фактором. В рамках этих процессов порождаются и переиспользуются множество артефактов (обсуждения, документы, чертежи, расчеты, схемы и т. д.), которые необходимы всем задействованным участникам в соответствии с их ролевой моделью и в совершенно разных ситуациях. Если эти процессы проходят в разных информационных системах, то передача данных между ними сопровождается множеством проблем. Это еще одна очевидная причина реализации системы управления проектами внутри платформы с развитым ECM/BPM-движком. Но как за разумный срок реализовать весь огромный пласт функциональности, который есть в профессиональных системах, например, в таких как Primavera и Project Server? Возможно, не весь он действительно нужен.
Известный факт (согласно опроса Quora 2018 года), что от функциональности Word и Excel основная масса пользователей в жизни применяют меньше 10%.
Мы провели огромную работу по отделению зерен от плевел и выявлению реальных потребностей компаний из множества отраслей, организовали несколько сотен проблемных интервью с экспертами проектного управления, руководителями и конечными пользователями систем. Что в итоге получилось, предлагаем рассмотреть в нашем обзоре возможностей Directum Projects.
Инь и янь: первопричина создания решения
Directum Projects — кроссметодологическая система управления портфелями проектов. Она работает на той же высокопроизводительной платформе, что и ECM/BPM-решения компании Directum. Это позволяет воспользоваться преимуществами широкого проникновения системы среди конечных пользователей (в отличии от классических КСУП, с СЭД работают почти все задействованные сотрудники компании). За счет единого механизма хранения и доставки артефактов проектной деятельности (документов, чертежей и т. д.) до каждого участника, объединенного с двумя слоями методологически выверенных механизмов высокоуровнего (портфельного) управления, среднеуровневого календарно-сетевого и ресурсного планирования, удалось кратно сократить управленческие издержки компании и безболезненно включить в проектное управление все процессные подразделения. Так же эффективен и противоположный подход: в портфеле разработки линейки продуктов, пропустив уровни программы проектов и календарно-сетевого планирования, удается выстроить управление процессами компании на основе одной из agile-методологий, оставляя работы по организационным изменениям или модернизации производства на классической водопадной модели.
Болты и шестеренки: основные элементы системы
Чтобы воплотить наши методологические задумки, были выделены следующие базовые элементы новой системы:
- Верхний уровень управления — это портфели, программы и проекты. Это иерархия объектов управления, позволяющая собрать агрегаты и разрезы для всех уровней менеджмента (руководство, проектный офис и руководители проектов). В каждом объекте управления могут быть определены контрольные точки, которые привязываются к вехам планов проектов либо в качестве цели достижения, либо в качестве активатора следующих этапов работ.
- Следующий уровень — это либо календарно-сетевой и ресурсный план работ по проекту, либо бэклог работ на agile-доске. В первом случае единицей работы является этап плана, обрамленный разделами, вехами, связями и ограничениями в календарно-сетевую модель. Во втором случае — это тикет-эпик, декомпозирующийся на тикеты-подзадачи, которые формируют граф связей различными типами зависимостей с другими тикетами. Это стандартный подход, реализованный в множестве систем, но преимущество нашего решения — возможность из любого этапа плана породить зависимые тикеты, а в любой тикет вложить целый новый план подпроекта.
- На самом нижнем уровне, для ответственных за исполнение этапа сотрудников, есть механизм автоматической доставки до них запланированных работ с помощью входящих заданий и возможность фиксировать в них прогресс и фактические трудозатраты (как своих, так и всех подчиненных сотрудников). Кроме того, можно использовать свои собственные командные agile-доски для декомпозиции и распределения работ.
Для сохранения и переиспользования накопленного опыта реализована база знаний, базирующаяся на концепции облака знаний, сформированного из статей, и автоматически формирующегося графа связей. Разграничение доступа к знаниям выстроено с помощью иерархических областей знаний, за каждой из которых закреплены эксперты и владельцы, обеспечивающие модерирование статей.
Проблемы и решения
Чтобы понять, позволяет ли наш подход решить самое наболевшее, мы сформировали кейсы по бизнес-задачам.
Топ-менеджмент и проектный офис
Руководители проектов
Ответственные за исполнение работ
Планы и перспективы
Чтобы закрыть все основные задачи целепостановки в компании в гибридных проектно-процессных и гибко-водопадных методологиях, в нашем решении на текущий момент не хватает только возможностей от OKR (Objectives and Key Results), тогда мы покроем весь спектр уровней управления в современных компаниях. Данная задача станет для нас приоритетной на ближайший горизонт.