03 авг 2022

Как грамотно собрать бизнес-архитектуру для системы управления проектами

Для кого:
  • Руководители проектных офисов
  • Руководители проектов
  • Кураторы проектной деятельность
Знания и навыки:
  • Управление проектами
  • Управление ИТ-проектами
  • Настройка инструментов управления
Время на чтение:
  • 10 минут

В статье «Зачем вам автоматизировать проектное управление?» я уже говорил о том, как важно при внедрении информационной системы управления проектами (далее — ИСУП) соблюсти баланс между пользой, которую она приносит заказчикам, и усилиями, необходимыми для ее функционирования.

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

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

Однако  при внедрении ИСУП могут возникать различные препятствия. Одно из них— разработка требований к системе.

 

Многие из тех, кто сталкивался с внедрением ИСУП, знают, сколько нужно приложить усилий для формирования требований. Подробное, «выстраданное» техническое задание зачастую готовится месяцами (мой личный рекорд — девять месяцев), и все равно в итоге оказывается неполным. Это может привести к тому, что внедренная система сильно разочарует заказчиков.

 

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

 

С No-Code- / Low-Code-инструментами (например, Coda, Fibery, Airtable, Jira) ситуация обратная. Полноценные требования к такой ИСУП часто вовсе не формируются, а разработка ведется с помощью итеративного прототипирования решения. Но, как я говорил в статье «NoCode-инструменты для управления проектами: преимущества и недостатки», хаотичное добавление объектов, полей, атрибутов может привести к потере взаимосвязи между данными. Из-за этого пользователям будет сложно получить цельную картину, например, сформировать отчетность по проекту или портфелю.

 

Ключом к решению данных проблем может стать построение модели ИСУП до начала или в самом начале ее внедрения.

 

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

 

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

 

Давайте рассмотрим основные этапы объектного моделирования.

 

Этап 1. Выделение аспектов

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

Аспект проектной деятельности — область внимания в проекте, на которой фокусируется руководство организации и/или руководитель проекта, так как она несет выгоды организации, позволяет соблюсти ограничения или решает наиболее острые проблемы в управлении.

В стандартах проектного менеджмента, например, в PMBoK, аспекты называют предметными областями, а в PRINCE2 — темами.

 

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

 

1. Структурирование деятельности компании в виде проектов всегда имеет какие-то цели: достижение определенного эффекта, применение результатов в процессах компании.

 

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

 

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

 

Классификации аспектов можно найти в любом стандарте по управлению проектами. Я в своей практике выделяю двенадцать основных аспектов:

 

  • «сроки»,
  • «содержание и качество»,
  • «финансы»,
  • «команда»,
  • «выгоды»,
  • «риски и открытые вопросы»,
  • «заинтересованные стороны»,
  • «коммуникации»,
  • «знания»,
  • «документооборот»,
  • «приживаемость»,
  • «закупки».


Вы можете использовать этот список аспектов либо сформировать свой.

 

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

 

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

 

Кроме того, одно и то же явление можно отнести к разным аспектам. Например, регулярные встречи команды можно отнести как к аспекту «команда», так и к аспекту «коммуникации», а можно и к аспекту «заинтересованные стороны», если ключевым для вас в этих встречах является именно согласование ожиданий от проекта с заинтересованными сторонами.

 

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

 

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

 

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

Этап 2: Определение объектов

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

 

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

 

Если вам хочется видеть, соответствует ли процесс работы над проектом графику «внутри» этих сроков, то у вас появляется еще один объект — «работа», и у него тоже есть сроки начала и окончания.

 

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

Объект — это элемент проектной деятельности, с помощью которого можно управлять процессами в рамках аспекта, т. е. осуществлять планирование и контроль.

Чем больше объектов вы выделите в рамках аспектов, тем сложнее, но одновременно и полнее будет ваша модель проектного управления.


Выделение объекта в системе проектного управления и дальнейшее управление им с помощью ИСУП позволят вам:
  • планировать параметры проекта — сроки, бюджеты и т. д.;
  • оперативно контролировать динамику состояний и параметров объекта и своевременно принимать управленческие решения;
  • формировать единое понимание текущего состояния и параметров объекта у всех участников проекта, исключая возможности для субъективного толкования, фиксировать все договоренности на общедоступной платформе;
  • формировать у всех участников проектной деятельности четкое и единообразное представление о процедурах управления проектами в рамках каждого из аспектов.
Примеры аспектов и соответствующих им объектов

Мы видим, что объект может не быть уникальным для какого-либо аспекта. Например, такой объект, как «работа», будет присутствовать и в аспекте «сроки» для контроля сроков исполнения, и в аспекте «содержание и качество» для определения состава работ. А возможно, и в аспекте «финансы», если вы контролируете затраты на выполнение конкретной работы.

 

То есть не обязательно увеличивать количество объектов, вы можете просто задать необходимые свойства (см. 3-й этап).

Этап 3: Определение свойств объектов

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

 

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

Свойство — это параметр объекта, его характеристика.

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

 

На этапе формирования объектной модели инвентаризировать все свойства (поля) необязательно, их список можно уточнить, когда будет конфигурироваться проектная отчетность.

 

Я выделяю две группы свойств объектов ИСУП:

 

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


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

 

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

 

Самым распространенным способом описания состояний являются статусы. Например, в процессе исполнения работ можно использовать такие статусы, как:

 

  • «к исполнению» — все плановые параметры работы определены, и исполнитель может приступать к ее выполнению;
  • «в работе» — исполнитель выполняет работу;
  • «приемка» — исполнитель закончил выполнение работы, и ответственное лицо должно оценить качество ее результатов и принять решение о завершении;
  • «завершено» — деятельность по работе закончена, а ее результаты признаны достаточно качественными.


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

 

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

 

При описании состояний объекта необходимо сформировать полный перечень состояний с описанием их смысла и условий переходов между ними.

 

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

 

Несмотря на некоторую сложность определения, а скорее даже сложность согласования состояний при использовании ИСУП, они значительно упрощают подготовку и восприятие управленческой отчётности.

Этап 4: Определение взаимосвязей между объектами и свойствами

Заключительный этап формирования объектной модели — определение взаимосвязей между ее элементами. Это наиболее сложный этап, так как вам необходимо проверить наличие взаимозависимостей между каждой парой объектов. Например: «цель — проект», «проект — задача», «цель — метрика». Также взаимосвязи могут быть выстроены и между объектами одного типа.

 

Определенные в рамках ИСУП взаимосвязи позволяют:

 

  • использовать иерархию и/или логическую связь при отображении объектов, например, работы, как составные части конкретного проекта, и последовательность выполнения работ;
  • формировать обобщенную отчетность, например, рассчитывать занятость сотрудника во всех проектах, в которых он участвует, на основании трудоемкости выполнения задач или суммирование в программе значений аналогичных показателей всех входящих в нее проектов, допустим, значений фактического бюджета;
  • автоматизировать заполнение отдельных свойств. Это могут быть свойства из выпадающих списков других объектов — например, ответственный за работу выбирается из общего списка участников проектной деятельности. А могут быть и расчетные формулы: скажем, при заданных датах начала и окончания работы длительность рассчитывается автоматически.


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

 

Таким образом, объектная модель формирует смысловой скелет ИСУП, обеспечивает полноту и достаточность требований к системе.

 

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

 

Для решений No-Code / Low-Code объектная модель становится каркасом, позволяющим избежать дублирования данных и не связанных ни с чем данных («повисших в воздухе»). При этом большинство No-Code- / Low-Code-решений (например, Coda, Jira) позволяет создать иерархию объектов любой сложности, настроить изменения их свойств, в том числе автоматизированный переход по фазам жизненного цикла объекта, и задать взаимосвязи между ними.

 

Однако важно помнить, что объектная модель, как и сама ИСУП, является вспомогательным инструментом для повышения качества управления, и если у вас в организации не будут налажены сами процессы проектной деятельности, с применением ИСУП эффективность проектов вряд ли вырастет.

Еще больше актуальной информации про полезные методы и инструменты проектного менеджмента, внедрения организационных изменений и ИТ-решений ищите в нашем Телеграм-канале: Уж&Ёж. Управление проектами. PMLogix

Авторы статьи:
Андрей Малахов
Прокомментировать статью
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Смотрите также:
31 Мая 2024
Что такое PMBok и как его применять
В этой статье подробнее расскажем о международном стандарте по управлению проектами PMBoK: что это такое, для каких проектов лучше всего подходит, из чего состоит, преимущества и недостатки стандарта.
13 Мая 2024
Что такое уровни управления
Уровни управления в организации — это ступени иерархической структуры, которая обеспечивает порядок, а также распределение ответственности и полномочий между сотрудниками. Во главе структуры стоит тот, кто управляет компанией: генеральный или исполнительный директор, которому подчиняются управленцы нижестоящего уровня. Менеджеры, стоящие “под” главой предприятия, контролируют следующий, также нижестоящий, уровень руководителей.
26 Апр 2024
Что такое проектный треугольник и зачем он нужен проджекту
Что из себя представляет проектный треугольник и как его применяют в  управлении проектами? Как использование этого инструмента позволяет объяснить заказчику, что качественный продукт, сделанный в короткие сроки, стоить дешево не может?  В чем отличия треугольника при использовании в гибких методологиях от применения в классическом подходе Waterfall?
Подписаться на рассылку
Высылаем анонсы статей и полезные материалы
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

Комментарий успешно отправлен

Произошла ошибка при отправке. Попробуйте еще раз

Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена