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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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