Post #436

Одним из последних проектов у меня была проработка требований и проектных решений системы по построению управленческой отчетности. Работа шла с нуля, поэтому набор артефактов получился вот такой: 1. Требования к бизнесу: что бизнес должен делать с точки зрения государственных органов, владельца, клиентов и подрядчиков. Систем здесь нет, это самый абстрактный уровень. Тут выявляем роли, которые отвечают за выполнение требований. Обычно это топы. 2. Мотивации и цепочка создания ценности. В этот раз не делал, но вообще нужно, и хорошо моделируется через Strategy Layer и Motivation Layer в Archimate™. Поток ценности — это вернеуровневый процесс компании + бизнес-возможности (capability). Мотивация показывает, кому и почему нужен этот проект и эта отчетность. Требования к бизнесу транслируются обычно в драйверы, управляющие мотивацией. 3. Бизнес-требования. Из мотивации ролей становятся видны бизнес-требования. Мы их записывали в виде юзер-сторей, но с добавлением: какое решение я, как роль, должен принять по этому значению или изменению этого показателя, какие действия я буду совершать? Это одна из самых трудных частей, потому что требует глубокой рефлексии от стейкхолдера, а то обычно получается "мне нужно видеть число продаж, чтобы скорректировать продажи" — понятно, что "скорректировать" здесь просто наукообразный синоним "ну, что-то с ними сделать". Что именно сделать — неплохо бы всё-таки выяснить, может, нужно дополнительные показатели вывести для принятия решения. 4. Реестр показателей. Это ключевой артефакт. Берем названия показателей из бизнес-требований, уточняем — как именно нам показатель нужно отображать: — в абсолютных числах? — в долях/процентах? (от чего?) — как среднее? — в сравнении (с чем?) — в динамике? — выбросы? (значительные отклонения) В каких разрезах нас интересует каждый показатель? Тут мы выявляем структуру бизнеса, то, что называется основными данными и справочниками. Реестр показателей мы будем обогащать дополнительной информацией. 5. Добавляем в реестр, во-первых, владельцев показателя (из потока ценности) и связанные БТ. Во-вторых — систему-источник, в которой этот показатель впервые появляется. Потом добавим конкретное поле в конкретной таблице, или формулу расчета. Как правило, здесь возникают интересные вопросы, у нас, например, был вопрос — какой датой учитывать платеж для управленческих целей. Здесь развилка: в одном направлении прорабатываем системы, в другом — состав и визуал отчетов/дэшбордов/оповещений. Начинаем с самого важного, для этого просим стейкхолдеров расставить приоритеты показателям. 6а. Раз мы добрались до систем, и нам нужен их реестр — с указанием, для каких данных это первоисточник. Также нам понадобится диаграмма потоков данных или sequence. Заодно здесь выявляем ручной перенос данных и всякие эксельки, на которых всё держится. Потом посмотрим, откуда удобнее брать данные для наполнения отчетов. 6б. Рисуем отчеты, как бы они могли выглядеть в идеале, без привязки к конкретному инструменту. Тут мы можем объединить показатели, которые раньше разделили, поэтому отчетов может получиться меньше. В реестре отчетов для каждого указываем: — назначение (для чего он); — связь с бизнес-требованиями; — основной объект, от которого строится отчет; — вид отчета (плоская таблица или сводная); — поля таблицы (для сводной — по вертикали и по горизонтали + формулы показателей на пересечении); — агрегаты под строками (сумма, среднее и т.п.) — возможные группировки; — куда можно провалиться из строки отчета (drill down); — откуда брать данные; — какие справочники и какие основные данные в отчете используются; — внешний вид отчета (мы моделировали в Google Sheets). Отсюда начинается встречное движение — что и как мы хотим показать, и что позволяет сделать выбранный инструмент. Про системный анализ, выбор архитектуры и инструментов напишу в следующей части, пост и так получился огромный.