Внедрение системы управления проектами производственно-инжинирингового предприятия OTUS
2026-03-10 01:42 Diff

Автор – Алексей Кунчукин, бизнес-архитектор, выпускник курса «Enterprise Architect».

Контекст

Производственно-инжиниринговый холдинг планирует строительство ремонтного завода.

Цель организации: обеспечить реверс-инжиниринг узлов двигателей для обеспечения ремонта и техобслуживания двигателей иностранного производства.

Цель проекта: выстроить систему управления деятельностью с учётом следующих ограничений:

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


Модель бизнеса

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

Мотивация

Строим модель мотивации и определяем целевую способность. Эту способность мы будем развивать для повышения ключевой ценности.

Легенда

Архитектура

Поток создания ценности

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

Легенда

Информационная модель

Для целевой способности формируем информационную модель:

Легенда

Автоматизация целевой способности: «Тепловая карта»

Декомпозируем целевую способность и формируем карту покрытия информационными системами.

Легенда

Цвета показывают, какие информационные системы автоматизируют наши способности.

Выбор технического решения

Действующее решение на базе MS Project и Jira не удовлетворяет бизнес-требованиям по управлению инжиниринговыми проектами. Задача компании – определить целевую информационную систему.

Но так как собственных ресурсов для разработки подобных систем у компании нет, мы ищем готовое решение: аналоги Jira и системы класса ИСУП (информационная системы управления проектами).

Исследуем рынок, отбираем пять систем и сравниваем их с действующей (Jira).

Отбор по отсекающим критериям

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

Интеграционная модель

В планах – встраивать решение ИСУП в действующий системный ландшафт.
В этом ландшафте:

  • системы на платформе 1С интегрируются через Kafka
  • остальные системы интегрируются напрямую через API

Тип приложений – stateful.

Инфраструктура

Требования к инфраструктуре:

ТребованиеИзмерениеНадёжностьДоступность, %95RTO, ч4Стоимость приобретения, не более руб.10 000 000Стоимость поддержки, не более руб. в год2 000 000Настройка / восстановлениеВстраивается в существующий системный ландшафт:1. PLM — управление жизненным циклом продукта2. RQM — управление рисками и качеством3. 1С УХ — Финансовый учет4. 1С ЗУП — штатное расписаниеТехнологическое окнопервый понедельник месяца с 5:00 до 8:00 МСКВозможность кастомизации системы силами сторонних подрядчиков (партнёров поставщика)Список подрядчиковВозможность экспорта данных из системыформаты: .xlsx, .csvВозможность масштабированияне планируетсяБезопасностьСистема должна предусматривать аутентификацию пользователейчерез SSOБлокировка действий пользователя при нарушении установленных ограниченийПодтверждение авторства электронных документов, изменений, комментариевНадёжность хранения данныхRPO, ч1

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

План реализации

Для качественной реализации проекта выявляем всех заинтересованных лиц и определяем стратегию работы с ними.

Стратегия работы с заинтересованными лицами

Заинтересованное лицоОсновные ожидания КлассАртефактыГенеральный директорАктуальный статус по деятельности холдингаУдовлетворять потребностиМетрики проектов и варианты их отслеживанияДиректор по проектированию (КБ)В любой момент времени иметь достоверную информацию о загрузке ресурсов.Ключевой стейкхолдерМетодика балансировки ресурсов по проектамПроектный департаментКонтролировать исполнение плана проекта и обеспечивать достижение результата в контрольных точках.Ключевой стейкхолдерПроцедура планирования проекта, структура проектов (портфели, программы)Финансовый департаментКонтролировать исполнение бюджета проекта и получить стоимость результата проекта.Мин. взаимодействияБюджет проектаДиректор по ИТОбеспечить оптимальную ИТ-поддержку на всех этапах проекта.Ключевой стейкхолдерИТ-ландшафт проектного управления, диаграмма развёртыванияИБ группы компанийОбеспечить защиту:
— информации по проекту;
— результатов интеллектуальной деятельности.ИнформироватьТребования ИБ

Риски и технический долг

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

Риски

Фактор
рискаЦельВероятностьПоследствияВеличина рискаМерыЗаявленные вендором параметры системы не соответствуют ожиданиям заказчикаОбеспечить исполнение не менее 90% требования заказчика339Развернуть тестовую среду для проверки соответствия требованиямНизкий уровень технической поддержки вендораОбеспечить должный уровень поддержки224Сформировать собственные компетенции по системе

Ещё одной формой риска может быть технический долг. Его также необходимо учитывать при планировании проекта.

Технический долг

Название задачиОписаниеПоследствияПодход к исправлениюОтветственныйТехнический долг по интеграции с финансовой системойИСУП могут внедрить без интеграции с финансовыми системами в части обмена данными по бюджету и оплатам (для такой интеграции нужны дополнительные ресурсы)Ручная обработка бюджетных заявок и платёжных документовИнтеграция с финансовыми системамиКоманда разработки финансовой системы

С учётом выявленных рисков планируем этап тестирования выбранной системы – проверку соответствия требованиям. Также нам предстоит оценить уровень технической поддержки поставщика решения.

Дорожная карта

План перехода в целевое состояние

Проект решения

  • Утвердить поток создания ценности для инжинирингового проекта.
  • Утвердить проект внедрения информационной системы управления проектами (ИСУП).
  • Финансовой департамент должен обеспечить финансирование проекта по внедрению ИСУП.
  • Архитектор должен проконтролировать:
  • этап тестирования решения перед запуском закупочной процедуры;
  • передачу решения в промышленную эксплуатацию с контролем соответствия плановой архитектуре и стоимости владения.