Введение. Типичные проблемы
Зачастую, IT специалисты не вникают, зачем именно пользователи просят разработать тот или иной отчет и просто делают то, что от них требуют. С другой стороны, далеко не все пользователи знают возможности системы, обладают аналитическим мышлением и могут четко сформулировать свои пожелания. В результате, спустя какое то время, реальная аналитическая работа перекочевывает в Excel, доверие к 1С как источнику данных снижается и системой могут просто перестать пользоваться.
Результат: данные системы не используются для принятия решений.
Ключевым пользователем управленческих отчетов являются линейные руководители и топ-менеджемент. Как раз эти люди обычно являются стейкхолдерами проекта и падение их интереса к автоматизируемой системе не может не беспокоить руководителя проекта.
Эта статья написана по итогам мастер-класса для РП и аналитиков, в рамках перехода на продуктовый подход к разработке. Мы преследовали две цели:
- Превратить разрозненный набор отчетности в целостный компонент конфигурации, развитие которого можно организовать в виде регулярного процесса.
- Увеличить доверие к отчетности, ее качество и как главное следствие - количество принимаемых решений
Часть 1. Кратко о процессе принятия решений
Цикл Деминга. Мониторинг и регулярная отчетность.
Процесс регулярного менеджмента основан на цикле из четырех повторяющихся действий (наверняка, многие из вас слышали такой термин - цикл Деминга - см. подробнее wiki)
Отчетность может потребоваться на любом этапе, но чаще всего, это "Plan" и "Check".
|
Цель (сценарий верхнего уровня) |
Сценарий использования |
Вид отчетности |
|---|---|---|
|
Регулярный (операционный) менеджмент. Поддержание текущего процесса в рамках заданных нормативных показателей (плана) |
Контроль (мониторинг) отклонений. Достижение заданных показателей |
Регулярная Обычно, один и тот же отчет используется с определенной периодичностью. |
| Организационное развитие. Рост. Внедрение изменений |
Выявление трендов Формулирование гипотез |
Моделирование Отчет формируется один-два раза для проверки гипотезы |
Проверка гипотез. Моделирование.
Все организационное развитие строится на проверке гипотез. Есть целая методология - HADI для проверки гипотез. В консервативном бизнесе это может явно не декларироваться, но фактический процесс будет очень похож.
Так как же оценить полезность отчета для бизнеса?
Ключевой критерий: количество принимаемых решений. То есть, если на основании отчета не принимают решений - он не нужен. К сожалению, заставить пользователей фиксировать принимаемые решения - не всегда реальная задача. На практике, можно попробовать использовать косвенный показатель - количество формирований того или иного отчета. Мы для этого разработали специальный механизм "Аудит использования отчетов".
Если принимать за ключевую метрику эффективности отчетности "количество принимаемых решений", то можно сформулировать два правила для проектировщиков:
Правило 1: Начинать проектировку отчета с формулирования его цели
На практике, это обычно означает необходимость использования методологии user story и построения user story map для аналитического блока. В консервативной корпоративной среде такая инициатива может встретить серьезное сопротивление. Чтобы направить дискуссию в конструктивное русле, важно донести до заказчиков следующую мысль:
Аналитика, как инструмент, является третьим звеном в цепочке
(1) Цель -> (2) Задача - > (3) Решение\инструмент
- За постановку цели и задачи отвечает полностью заказчик (бизнес-пользователь). Под задачей здесь подразумевается бизнес-задача, без упоминания технических инструментов.
- За выбор решения (инструмента) отвечает технический эксперт.
Таким образом, технический эксперт не сможет правильно выбрать решение, если не знает цель и задачу. И, соответственно, не может и не должен нести ответственность за их качество.
Правило 2: Рассматривать "Отчетность" как единый компонент\систему
Это позволит снизить вероятность реализации следующих рисков:
- Разрозненность
- Противоречивость
- Не полнота
У вас получится матрица функциональная подсистема \ логическая подсистема. Вариант визуализации - в виде майнд-карты.
В терминологии гибких методологий управления проектами - это user story map. То есть мы берем кусок бэклога, посвященный аналитике и показываем, как связаны между собой крупные блоки (например, общий маркетинг - > event-маркетинг), сценарии использования и конкретные отчеты.
Где уместно использовать 1С
В 1С, к сожалению, удобно использовать только регулярные отчеты. Структура настроек достаточно жесткая, поэтому процесс моделирования плохо ложится на 1С. Например, не получится без разработчика соединить несколько таблиц (ВПР) и сделать их визуализацию в виде сводной диаграммы. Поэтому, мне кажется, имеет смысл разделить:
- В 1С - хранения данных с грамотно проработанной структурой
- В BI - выгрузка и весь процесс моделирования
Часть 2. Краткий гайд-лайн* по проектированию отчетности
*guideline - генеральная линия, руководящий принцип.
Это вариант правил, разработанных для аналитиков. Здесь собраны советы, помогающие на самом нижнем уровне проектирования направлять усилия команды в русло увеличения ключевой метрики.
Сравнение форм визуализации данных
| Таблица | Диаграмма | Списки | Уведомления | |
|
Ключевой пользователь
|
Аналитик | Линейный руководитель | Специалист | Топ-менеджер |
|
Основные сценарии
|
Проверка и формулирование гипотез |
Мониторинг |
Работа с первичными данными (валидация, исправление данных) |
|
|
Плюсы и минусы
|
|
|
|
|
Сложно принимать решения
Максимально подробная информация
Таблицы
Таблицы удобны "профессиональным пользователям" (бухгалтер, экономист) и аналитикам (маркетолог, системный аналитик). Этим группам пользователей важно видеть первичные данные, чтобы самостоятельно выявлять какие то тренды и зависимости.
На что обратить внимание:
В случае с регулярной отчетностью, можно ввести понятие нормы и с помощью условного оформления выделять отклонения от нее в большую или меньшую стороны. Например, продажи > 100 000 выделить красным.
Диаграммы
В рамках 1С обычно использует два варианта проектирования с использованием диаграмм:
- Дашборды рабочего стола
- Диаграммы в составе классических отчетов
На что обратить внимание:
- В составе отчетов: диаграммы размещать выше таблиц (то есть принцип "от общего - к частному")
- Для дашбордов рабочего стола: объединять в аналитические панели, полностью закрывающие какой либо сценарий или группу смежных сценариев.
Списки
На что обратить внимание
- Состав колонок
- Условное оформление
- Индикаторы
- Агрегированные показатели
Первый симптом плохо проработанных списков - пользователи активно используют отчеты типа "простыня" ( большое количество колонок с первичными данными)
Уведомления
При проектировании уведомлений важно продумать
- состав данных
- периодичность
- способ доставки
- возможность реакции (ответа)
Состав данных зависит от варианта использования
- Мониторинг - тогда это должны быть сводные показатели за проверяемый период, показывающие полную картину
- Сообщение об инциденте - показывает нормальное значение и текущее (то есть, в чем собственно заключается инцидент)
Способ доставки может быть
- sms
- мобильное приложение
- бот в мессенджере
Резюме
- В качестве ключевой метрики для оценки эффективности отчетности имеет смысл использовать "количество принимаемых решений". Косвенно можно оценить по "количеству формирований отчета"
- Чтобы донести это до команды и согласовать действиях всех участников - полезно разработать некий гайд-лайн\руководство по проектированию.
- По опыту нашей компании, чтобы связать метрику, проектировку и процесс разработки эффективно использовать методологию user story.
А чтобы все не казалось так легко и просто, вот почти альтернативный взгляд: "Хватит автоматизировать отчеты!"
