Автор – Алексей Кунчукин, бизнес-архитектор, выпускник курса «Enterprise Architect».
Контекст
Производственно-инжиниринговый холдинг планирует строительство ремонтного завода.
Цель организации: обеспечить реверс-инжиниринг узлов двигателей для обеспечения ремонта и техобслуживания двигателей иностранного производства.
Цель проекта: выстроить систему управления деятельностью с учётом следующих ограничений:
- Основная деятельность состоит из комплекса проектов по конструированию, отработке производства, ремонта деталей и узлов двигателей.
- Необходимо обеспечить управление взаимосвязанными проектами во всех аспектах: бюджета, ресурсов, сроков и требований.
Модель бизнеса
Опираемся на контекст и строим бизнес-модель Остервальдера. Выделяем в модели ключевую ценность, с которой будем работать в проекте – «повышение эффективности реализации инжиниринговых проектов».
Мотивация
Строим модель мотивации и определяем целевую способность. Эту способность мы будем развивать для повышения ключевой ценности.
Легенда
Архитектура
Поток создания ценности
На примере потока создания ценности определяем способности, которые помогут создать сертифицированную конструкторскую документацию. Наша целевая способность – управление проектами.
Легенда
Информационная модель
Для целевой способности формируем информационную модель:
Легенда
Автоматизация целевой способности: «Тепловая карта»
Декомпозируем целевую способность и формируем карту покрытия информационными системами.
Легенда
Цвета показывают, какие информационные системы автоматизируют наши способности.
Выбор технического решения
Действующее решение на базе MS Project и Jira не удовлетворяет бизнес-требованиям по управлению инжиниринговыми проектами. Задача компании – определить целевую информационную систему.
Но так как собственных ресурсов для разработки подобных систем у компании нет, мы ищем готовое решение: аналоги Jira и системы класса ИСУП (информационная системы управления проектами).
Исследуем рынок, отбираем пять систем и сравниваем их с действующей (Jira).
Отбор по отсекающим критериям
Отбор показывает, что необходимо рассматривать системы класса ИСУП, а также позволяет выделить двух потенциальных кандидатов. Сравним этих кандидатов и оценим по расширенному списку требований.
Интеграционная модель
В планах – встраивать решение ИСУП в действующий системный ландшафт.
В этом ландшафте:
- системы на платформе 1С интегрируются через Kafka
- остальные системы интегрируются напрямую через API
Тип приложений – stateful.
Инфраструктура
Требования к инфраструктуре:
| Требование | Измерение |
| Надёжность | |
| Доступность, % | 95 |
| RTO, ч | 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% требования заказчика | 3 | 3 | 9 | Развернуть тестовую среду для проверки соответствия требованиям |
| Низкий уровень технической поддержки вендора | Обеспечить должный уровень поддержки | 2 | 2 | 4 | Сформировать собственные компетенции по системе |
Ещё одной формой риска может быть технический долг. Его также необходимо учитывать при планировании проекта.
Технический долг
| Название задачи | Описание | Последствия | Подход к исправлению | Ответственный |
| Технический долг по интеграции с финансовой системой | ИСУП могут внедрить без интеграции с финансовыми системами в части обмена данными по бюджету и оплатам (для такой интеграции нужны дополнительные ресурсы) | Ручная обработка бюджетных заявок и платёжных документов | Интеграция с финансовыми системами | Команда разработки финансовой системы |
С учётом выявленных рисков планируем этап тестирования выбранной системы – проверку соответствия требованиям. Также нам предстоит оценить уровень технической поддержки поставщика решения.
Дорожная карта
План перехода в целевое состояние
Проект решения
- Утвердить поток создания ценности для инжинирингового проекта.
- Утвердить проект внедрения информационной системы управления проектами (ИСУП).
- Финансовой департамент должен обеспечить финансирование проекта по внедрению ИСУП.
- Архитектор должен проконтролировать:
- этап тестирования решения перед запуском закупочной процедуры;
- передачу решения в промышленную эксплуатацию с контролем соответствия плановой архитектуре и стоимости владения.
