До 40% бюджета на BI-проекты в финансовом секторе съедают доплаты за «неучтенный функционал», который возникает из-за размытого ТЗ. Для финдиректора цена ошибки в описании логики сбора данных — это не просто перерасход в 300–700 тысяч рублей, а получение некорректного P&L; и CashFlow, которые невозможно использовать для принятия решений.
Архитектура данных: забудьте про «список отчетов»
Главная ошибка — описывать ТЗ через визуализацию (дашборды). В итоге вы получаете красивые картинки, но данные в них не бьются, так как не описана модель данных. Требуйте от исполнителя проектирования схемы «Источник → ETL → Хранилище (DWH) → Витрина». Если в ТЗ нет описания гранулярности данных (например, до конкретной транзакции, а не до агрегата за месяц), вы не сможете сделать Drill-down анализ.
Кейс: компания внедрила отчет по выручке за 2 недели, но при попытке детализировать цифру до клиента выяснилось, что данные из CRM подтягиваются агрегировано. Переделка архитектуры стоила 150 000 руб. и заняла еще 10 дней. Экспертный вывод: ТЗ должно начинаться с карты источников и правил трансформации данных, а не с макетов экранов.
Методология учета: фиксация формул и логики
BI-интегратор — это технарь, а не бухгалтер. Если вы не пропишете формулу расчета EBITDA или правила распределения косвенных расходов по центрам финансовой ответственности (ЦФО), исполнитель придумает их сам. В ТЗ должен быть раздел «Справочник показателей», где для каждого KPI указана математическая формула и источник данных. Например: «Валовая прибыль = Выручка (из 1С:ERP, счет 90.01) минус Себестоимость (счет 90.02) с учетом НДС».
Обычно на согласование формул уходит 20–30% времени проекта. Пропуск этого этапа ведет к тому, что 5 из 10 отчетов будут содержать ошибки в расчетах, которые вскроются только при приемке. Экспертный вывод: любое понятие, которое можно трактовать двояко, должно быть зафиксировано формулой в ТЗ.
Технические требования к обновлению и доступам
Частая «дыра» в ТЗ — отсутствие регламента обновления данных. Разница между обновлением раз в сутки и в реальном времени (Real-time) в стоимости разработки может составлять от 100 000 до 500 000 рублей. Четко укажите частоту обновления: например, «финансовые показатели — 1 раз в сутки в 08:00, остатки по кассе — каждые 15 минут». Также пропишите матрицу прав доступа: кто видит только свои отделы, а кто — всю компанию.
Пример: финдиректор забыл указать необходимость разграничения прав по филиалам. В итоге данные утекли к региональным менеджерам, и пришлось переписывать систему безопасности с доплатой в 20% от стоимости этапа. Экспертный вывод: требования к безопасности и частоте обновления — это фундамент, который нельзя оставлять на «откуп» разработчику.
Критерии приемки и тестовые сценарии
Чтобы избежать бесконечных правок, введите понятие «приемочного теста» (UAT). В ТЗ должен быть раздел с конкретными сценариями проверки. Например: «При выборе фильтра по периоду Январь 2023 и компании А, сумма чистой прибыли должна совпасть с данными из регламентированного отчета 1С с точностью до копейки». Без таких тестов приемка превращается в субъективное «мне не нравится этот цвет графика».
Практика показывает, что наличие чек-листа приемки сокращает срок сдачи проекта на 15–20%. Если исполнитель отказывается фиксировать критерии успеха в ТЗ, значит, он планирует работать по модели Time & Materials с бесконечными допами. Экспертный вывод: нет критерия приемки — нет завершенного этапа.
Вывод
Идеальное ТЗ на BI — это документ, который превращает финансовую логику в технический алгоритм. Избегайте общих интеграторов, которые обещают «сделать всё под ключ» без детального анализа данных; выбирайте тех, кто настаивает на этапе проектирования модели. Начните с фиксации источников и формул расчета, а затем переходите к визуализации. Самый надежный способ минимизировать риски — использовать фиксированную стоимость за конкретный набор витрин данных, а не за «внедрение системы» в целом.