Руководитель тонет в отчётах. Финансы присылают выгрузку из 1С, продажи – Excel с десятком вкладок, производство – свою таблицу, а ИТ – логи систем. Цифры не сходятся, актуальность под вопросом, а на сборку единой картины уходит неделя. К моменту, когда отчёт готов, решение уже неактуально. BI (business intelligence) решает именно эту задачу: собирает данные из разных систем в один слой и показывает их в виде дашбордов, по которым видно состояние дел за секунды.

Дашборд – не красивый график, а инструмент решения

Главная ошибка – относиться к дашборду как к презентации. Красивая визуализация без управленческого смысла бесполезна. Хороший дашборд отвечает на конкретный вопрос руководителя: укладываемся ли в план по выручке, где растёт дебиторка, какой филиал проседает по марже, сколько заявок зависло в обработке.

Поэтому проектирование начинается не с выбора инструмента (QlikView, SAP BusinessObjects, Microsoft SQL Server Reporting Services или Oracle BI), а с вопросов, на которые руководитель отвечает каждый день. Дальше – набор ключевых показателей (KPI), по три-пять на экран. Десятки метрик на одном дашборде гарантированно превращают его в шум, который никто не читает.

Второй принцип – детализация по запросу. Верхний уровень показывает агрегат: выручка по компании. Клик – разбивка по регионам. Ещё клик – по конкретным договорам. Руководитель сам решает, на какую глубину спускаться.

Данные решают, а не картинки

Дашборд хорош ровно настолько, насколько хороши данные под ним. Если источники противоречат друг другу, красивый интерфейс лишь маскирует проблему. Поэтому под BI всегда лежит вопрос архитектуры хранения: куда складывать данные, как их чистить и согласовывать. Мы подробно разбирали выбор между классическим хранилищем и озером данных в материале про DWH и Data Lake – для управленческой отчётности обычно нужен именно структурированный слой с выверенными витринами.

Отдельная боль – частота обновления. Для стратегических показателей хватает суточного обновления ночным регламентом. Для операционных (загрузка склада, очередь обращений) нужен поток, близкий к реальному времени. Здесь вступают в игру распределённые СУБД, способные держать нагрузку без потери согласованности, – о подходе Google к этой задаче мы писали в обзоре Spanner.

В госсекторе добавляется специфика. Данные приходят из разных ведомственных систем, а доступ к ним регулируют требования к защите информации и персональным данным. Дашборд для главы ведомства собирает показатели оказания госуслуг, и здесь важна привязка к единым механизмам – например, к идентификации граждан через УЭК и портал, о которой шла речь в статье про вход на Госуслуги.

Что мешает внедрению

Технически BI разворачивается быстро. Проваливают проекты обычно по другим причинам. Первая – дашборд строят айтишники без участия тех, кто будет им пользоваться, и он отвечает не на те вопросы. Вторая – нет владельца данных, поэтому цифры некому согласовать и защитить. Третья – в систему заливают грязные данные, доверие к ней падает после первого же расхождения с реальностью, и руководитель возвращается к привычному Excel.

Поэтому BI работает только тогда, когда становится управленческим инструментом на данных: сначала вопросы бизнеса, затем выверенный слой хранения и лишь потом дашборды.

Вывод

BI не заменяет руководителя – он убирает разрыв между событием и решением. Когда данные собраны, выверены и показаны в понятном виде, решение опирается на факт, а не на ощущение. Это и есть управление на данных: меньше совещаний ради сверки цифр, больше времени на сами решения.