B2E платформа управления корпоративной архитектурой
Спроектировал ключевые сценарии внутренней B2E платформы управления корпоративной архитектурой и передал продакшен-макеты в разработку.
Внутренняя B2E платформа объединяет бизнес-архитектуру, ИТ-ландшафт и технологическую архитектуру. Внутри продукта связаны стратегии, бизнес-способности, бизнес-процессы, проекты, ИТ-сервисы и технологии.
Продукт рассчитан на три основные роли. Бизнес-пользователи просматривают опубликованные данные. Архитекторы поддерживают модель и готовят изменения. Корпоративные архитекторы рассматривают изменения, управляют версиями и публикуют согласованное состояние архитектуры.
Задача
Бизнес-задача
- Создать единую платформу управления корпоративной архитектурой
- Сделать прозрачными связи между стратегиями, бизнес-способностями, ИТ-сервисами и проектами
- Сократить ручную работу при обновлении моделей и подготовке отчетов
Проблемы пользователей
- Разрозненные архитектурные данные быстро устаревали, поэтому пользователям было сложно увидеть актуальные связи между объектами
- Сверка данных, обновление моделей и подготовка отчетов требовали ручной работы
Моя роль
Участвовал в создании платформы с нуля: проектировал пользовательские сценарии и интерфейсы ключевых разделов. Также участвовал в развитии дизайн-системы.
Погружение
В начале проекта требования были распределены между документами, таблицами, схемами и комментариями бизнеса.
Я сопоставлял требования с пользовательскими сценариями и собирал структуру интерфейса.
Изменение технологии может затронуть ИТ-сервисы, бизнес-процессы и бизнес-способности. Изменение стратегии может повлиять на проекты и архитектурные приоритеты. Поэтому интерфейс должен был показывать связи между объектами.
Исследование пользователей
Мы с продакт-менеджером провели 12 интервью. Во время встреч я уточнял текущие сценарии работы пользователей, их проблемы и привычные инструменты.
| Проблема | Участники |
|---|---|
| Архитектурные данные быстро устаревали | 8 и более |
| Сбор информации требовал ручной координации | 7 и более |
| Пользователи работали в нескольких несвязанных системах и файлах | 7 и более |
| Подготовка отчетов и визуализаций требовала отдельной ручной работы | 6 и более |
Каждого участника учитывали не более одного раза в каждой теме. Выводы из интервью я использовал при проектировании ключевых сценариев.
Решение
Я описал сценарии для разных ролей и состояний данных: от просмотра опубликованной версии до подготовки и согласования изменений.
Для каждого сценария были определены роли, права доступа, состояния объектов и переходы между черновыми и опубликованными данными.
Ниже два примера на разных уровнях: техрадар показывает работу с технологическим портфелем, а swimlane диаграмма помогает редактировать отдельный бизнес-процесс.
Решение 1. Техрадар как управляемая технологическая политика
В интервью не менее четырех участников рассказывали, что оценивают новые технологии, проверяют их применимость на пилотных проектах и поддерживают технологический радар.
На одной карте архитектор видит технологии и рекомендации: использовать, тестировать, изучать или временно не применять.
Квадранты делят технологии по категориям, кольца показывают рекомендации.
Из карты архитектор открывает карточку с описанием технологии, рекомендацией и связями с другими объектами архитектуры.
Архитектор может предложить новую технологию или изменить рекомендацию. Предложение попадает в очередь запросов на изменение (RFC); ответственный архитектор изучает контекст и принимает решение.
Опубликованная версия радара не меняется. Прежние версии хранятся в истории, следующую готовят в черновике.
Решение 2. Бизнес-процесс как связная swimlane диаграмма
Для бизнес-процесса я спроектировал единую модель с табличным и графическим представлениями. Она связывает участников, этапы, действия и другие объекты корпоративной архитектуры.
На диаграмме строки соответствуют участникам, колонки этапам, а линии показывают переходы между действиями.
Чтобы видеть контекст отдельного шага, пользователь открывает карточку действия с описанием, участником и этапом, связанными процессами, документами и переходами.
Архитектор редактирует процесс в черновике: добавляет участников, этапы и действия, настраивает переходы и отправляет версию на рассмотрение.
На уровне отдельного действия архитектор задает связи с другими процессами, бизнес-способностями, ИТ-сервисами и документами.
После проверки версию можно опубликовать. Бизнес-пользователи видят только опубликованные данные.
Результат
Я спроектировал ключевые сценарии платформы и передал макеты в разработку. Платформа стала доступна руководителям высшего звена и операционным департаментам. Я сопровождал реализацию, собирал обратную связь и участвовал в развитии функций.