Дашборд перестают открывать не из-за платформы и не из-за дизайна. Семь причин ниже покрывают почти все случаи, и шесть из них закладываются в первые три недели проекта — до того, как написана хоть одна строка кода витрины. Поэтому список полезнее читать не после провала, а на второй неделе своего проекта: у каждой ошибки есть ранний признак, который видно уже тогда.
Общая механика простая. Дашборд не создаёт данные — он показывает то, что уже есть в учёте. Если справочники грязные, определения не согласованы, а данные обновляются реже, чем принимаются решения, отчёт получится красивым и неверным. Это опаснее его отсутствия: по отсутствующему отчёту решения не принимают, а по красивому — принимают.
Ниже — семь ошибок с ранними признаками, таблица цены исправления на трёх стадиях, короткая проверка живого контура и разбор того, почему аналитика не чинит сломанный процесс ввода данных. Расчёты — на той же модели, что в разборе бюджета BI-проекта: компания на 40 человек, два источника, восемь дашбордов, 20 именованных пользователей, 600 000 ₽ работ.
Семь ошибок и их ранний признак на второй неделе
Ранний признак — это то, что можно увидеть или спросить, не будучи специалистом по данным. Все семь проверяются за один разговор с проектной командой и одним взглядом в план проекта.
| Ошибка | Ранний признак на второй неделе | Чем это заканчивается |
|---|---|---|
| Начали с визуализации | Показывают макеты экранов, а списка показателей с письменными формулами ещё нет | Первый спор о цифре обнуляет доверие, витрины переделывают целиком |
| Не назначили владельцев метрик | На вопрос «кто утверждает определение выручки» отвечают «обсудим на встрече» | Определения плывут, каждый отдел приносит на планёрку свою цифру |
| Взяли все данные вместо нужных | В требованиях стоит «выгрузим всё, потом разберёмся» или список из сорока показателей | Загрузка тяжелеет, половина данных не используется, сроки растут |
| Дашборд без действия | Ни у одной плитки нет ответа на вопрос «что делать, если она красная» | Красиво и бесполезно: смотреть интересно один раз |
| Обновление раз в неделю при ежедневных решениях | В требованиях «обновление по понедельникам», а склад и продажи решают ежедневно | Пользуются выгрузкой из учётной системы, дашборд открывают на совете директоров |
| Доступ только через заявку в ИТ | Учётные записи заводятся по служебной записке со сроком три дня | Через месяц половина пользователей не заходила ни разу |
| Обучение не заложено | В плане на обучение стоит один час на всех, приёмка — это демонстрация | Пользуются двое, остальные просят «присылать в почте, как раньше» |
Первые две ошибки — самые дорогие и самые незаметные. Они выглядят как ускорение проекта: команда не тратит недели на согласования и сразу показывает результат. Почему согласование определений занимает больше времени, чем рисование экранов, и как это отражается в календаре, разобрано в материале сроки проекта аналитики.
Три вертикальных столбца одинаковой ширины и разной высоты с подписями сверху: «На обследовании — 27 000 ₽», «Сразу после запуска — 366 000 ₽», «Через год — 1 006 000 ₽». Рядом с третьим столбцом пунктирная горизонтальная линия с подписью «весь проект — 600 000 ₽», проходящая заметно ниже его вершины. Под столбцами общая подпись: «одни и те же семь ошибок». Чертёжный стиль, подписи по-русски.
Цена одной и той же ошибки на трёх стадиях
Таблица считает работы подрядчика по ставке 3 000 ₽/час. Ноль в первой колонке означает не «бесплатно», а «стоит решения, а не денег»: назначить владельца показателя или сократить список метрик на обследовании можно за один разговор. Платить за эти пункты начинают ровно тогда, когда решение не принято.
| Ошибка | На обследовании | Сразу после запуска | Через год эксплуатации |
|---|---|---|---|
| Начали с визуализации | 0 ₽ | 90 000 ₽ | 260 000 ₽ |
| Не назначили владельцев метрик | 0 ₽ | 45 000 ₽ | 180 000 ₽ |
| Взяли все данные вместо нужных | 0 ₽ | 60 000 ₽ | 150 000 ₽ |
| Дашборд без действия | 0 ₽ | 30 000 ₽ | 120 000 ₽ |
| Обновление раз в неделю | 15 000 ₽ | 75 000 ₽ | 140 000 ₽ |
| Доступ только через заявку в ИТ | 0 ₽ | 24 000 ₽ | 60 000 ₽ |
| Обучение не заложено | 12 000 ₽ | 42 000 ₽ | 96 000 ₽ |
| Итого | 27 000 ₽ | 366 000 ₽ | 1 006 000 ₽ |
Через год исправление всех семи стоит 1 006 000 ₽ — в 1,7 раза дороже, чем весь проект целиком. Разница набегает не из-за инфляции работ, а из-за того, что за год поверх ошибочной модели вырастает наследие: пользователи привыкли к своим выгрузкам, часть отчётов обросла ручными правками в таблицах, а переделка витрины тянет за собой пересборку всех восьми дашбордов и повторную приёмку.
Самая крупная строка — 260 000 ₽ за первую ошибку через год — раскладывается так: заново собранный словарь метрик и согласование восьми определений, перестроенные витрины под новые правила расчёта, пересборка восьми дашбордов и повторная сверка на трёх закрытых периодах. Это примерно 87 часов, то есть 44 % объёма всего исходного проекта, при том что сам проект уже оплачен полностью. Ровно та же работа на этапе обследования занимает один разговор и попадает в смету бесплатно, потому что порядок этапов ещё можно поменять.
Третья ошибка кажется безобидной: раз уж подключаем данные, возьмём побольше. На практике каждая лишняя метрика тянет за собой определение, владельца, сверку и сопровождение, а внимание читателя дашборда — ресурс конечный. Правило отбора простое: за каждой цифрой должно стоять решение, которое по ней принимают; как отбирать показатели и во что обходится лишняя плитка, разобрано в материале метрики на дашборде руководителя.
Проверка живого контура: три вопроса и один запрос
Если система уже сдана, диагностика занимает полчаса. Три вопроса задаются руководителю, который считается основным читателем отчёта, а четвёртая проверка делается по журналу посещений платформы — он есть у любой BI-системы.
- 1«Какое решение вы приняли по этому дашборду за последний месяц?» Если конкретного решения нет, у контура ошибка номер четыре: показатели есть, действия за ними не стоит.
- 2«Если цифра на экране разойдётся с бухгалтерией, кому вы позвоните?» Если названа должность из ИТ, а не владелец показателя, — ошибка номер два: за определения никто не отвечает.
- 3«Когда данные обновлялись последний раз и откуда вы это знаете?» Если руководитель не знает или узнаёт по косвенным признакам, — ошибка номер пять: частота обновления не совпадает с частотой решений.
- 4Запрос в журнал посещений: сколько именованных пользователей заходили хотя бы четыре раза за последние 30 дней. Норма для двадцати пользователей — не меньше двенадцати. Шесть и меньше означают, что контур пора не расширять, а сокращать.
Ряд из двадцати одинаковых фигурок-пользователей, из них пять закрашены плотно и подписаны «заходят четыре и более раз в месяц», три закрашены наполовину — «заходят реже», двенадцать оставлены контуром — «ни одного входа за 30 дней». Под рядом две горизонтальные метки: пунктирная «норма — 12 из 20» и сплошная «факт — 5 из 20». Справа выноска: «лицензии оплачены на всех двадцать». Чертёжный стиль, подписи по-русски.
Результат этой проверки не всегда означает «чинить». Если из двадцати именованных пользователей реально работают пятеро, разумный ход — сократить лицензии до пяти, вернуть остальным отчёт по расписанию в почту или мессенджер и сэкономить на подписке. Расширять контур, которым не пользуются, дороже вдвойне: платится и за лицензии, и за сопровождение экранов, которые никто не открывает. Кто и за какие деньги должен вести этот контур дальше, разобрано в материале кто ведёт отчётность после сдачи проекта.
Аналитика поверх сломанного процесса ввода
Восьмой пункт, который не входит в список семи ошибок, потому что это не ошибка внедрения, а её причина. BI не заводит данные в систему — он читает то, что завели люди. Если источник заявки в CRM заполняется у 78 % сделок, дашборд по каналам посчитает по этим 78 % и покажет убедительную картину, отличить которую от правильной по внешнему виду невозможно.
Не стоимость самой ошибки в данных, а сумма решений, принятых на её основе до момента обнаружения. Считается как обычные управленческие расходы: изменённая скидочная политика, перераспределённый бюджет, замороженные в закупке деньги. Практическая мера здесь одна: чем реже сверяется витрина, тем длиннее период накопления таких решений.
Модельный случай из обычной практики сопровождения. В учёте завели три новые статьи затрат, в витрину их не перенесли — расходы ушли в «прочее», и маржа одной товарной группы оказалась завышена на 4 процентных пункта. По этой цифре за квартал приняли три решения.
Горизонтальная схема из пяти блоков со стрелками: «три новые статьи затрат в 1С» → «не перенесены в витрину» → «расходы уходят в «прочее»» → «маржа группы завышена на 4 пункта» → «три решения за квартал: скидка 84 000 ₽, реклама 90 000 ₽, замороженная закупка 27 000 ₽». Над вторым блоком тонкая вертикальная выноска вниз: «правка — 6 часов, 18 000 ₽». Под последним блоком итог «201 000 ₽». Чертёжный стиль, подписи по-русски.
Отсюда простое правило приёмки: пока витрина не сошлась с закрытым месяцем учётной системы, дашборд остаётся гипотезой. И столь же простое правило эксплуатации: сверка после каждого закрытия месяца, с журналом расхождений. Как проверить состояние данных до старта проекта своими силами, разобрано в материале качество данных для аналитики: семь проверок по выгрузке делаются за вечер и дают конкретную долю строк с браком.
Если обязательные поля не заполняются, чистка базы даёт временный результат: доля пустых полей возвращается к прежнему уровню примерно за квартал. Сначала минимальный набор обязательных полей — не больше шести — и правило их заполнения, потом отчёты. BI, поставленный поверх сломанного процесса ввода, не улучшает данные, а придаёт им авторитет.
Когда дашборд честнее выключить
Не всякий неработающий контур надо чинить. Иногда правильное решение — остановить оплату лицензий и вернуться на ступень назад, к выгрузке по расписанию. Это не поражение проекта: подготовка данных, словарь метрик и порядок в справочниках остаются и пригодятся любому следующему инструменту.
- Читателей меньше трети от оплаченных лицензий. Пять активных пользователей из двадцати — повод сократить подписку до пяти и раздавать остальным отчёт по расписанию, а не добавлять новые экраны в надежде на интерес.
- Решения по показателям всё равно принимаются по выгрузке. Если руководитель перед планёркой выгружает данные в таблицу и пересчитывает, дашборд не встроен в процесс. Чинить надо процесс принятия решения, а не визуализацию.
- Данные обновляются реже, чем нужны. Недельное обновление при ежедневных решениях делает контур декоративным. Либо переводить загрузку на ежедневную, либо признать, что задача закрывается регулярной выгрузкой.
- Некому владеть определениями показателей. Без человека, который отвечает за формулу и принимает изменения, модель данных расходится с реальностью примерно за квартал. Здесь дешевле сознательно вернуться к таблице, чем оплачивать медленную деградацию.
Если же ошибки нашлись рано и контур в целом нужен, порядок исправления обычный: сначала владельцы показателей и словарь метрик, потом частота обновления, потом доступы и обучение, и только в последнюю очередь — экраны. Порядок здесь не вкусовой: каждая следующая работа опирается на предыдущую, и переделка экранов до согласования определений просто повторится через квартал. Практический ориентир по бюджету: исправление, начатое в первые два месяца после запуска, укладывается в 366 000 ₽ на все семь пунктов, а через год те же пункты стоят как проект и ещё две трети сверху. Состав и цену готового контура можно посмотреть в решении BI-дашборды.
