Показатель считается один раз
Совещание, на котором две таблицы показывают разную выручку за один месяц, — это не проблема аналитики. Это проблема определений.
Пока данные лежат в разных системах, у каждого отдела складывается собственная арифметика. Продажи считают заказ продажей в момент подтверждения, склад — в момент отгрузки, бухгалтерия — по документу. Все три ответа корректны в своей системе координат, и именно поэтому отчёты не сходятся.
Договориться раньше, чем строить
Прежде чем рисовать графики, нужен короткий документ: что такое заказ, когда он становится продажей, как учитываются возвраты и частичные отгрузки, из какой системы берётся цена. Это скучная работа на несколько встреч, которая экономит месяцы споров.
Дальше определения перестают быть словами и становятся кодом: одна модель данных, один расчёт, один источник для всех отчётов. Если показатель нужно изменить, он меняется в одном месте.
Аналитика начинается не с дашборда, а со словаря.
Как это устроено технически
Данные собираются из учёта, web-сервисов и внешних систем процедурами ETL, складываются в базу, организованную под отчётность, и обновляются по расписанию. Отчёты строятся на этой базе, а не на живом учёте: тяжёлые расчёты не мешают работе пользователей.
Обновление по расписанию — принципиальный пункт. Как только в цепочке появляется человек, который «выгружает и присылает файл», у отчёта появляется зависимость от отпуска этого человека.
Что получает бизнес
Один и тот же показатель на складе, в продажах и у собственника. Возможность спросить «почему цифра такая» и получить ответ с уровнем детализации до документа. И спокойные совещания, на которых обсуждают решения, а не расхождения в таблицах.
Похожая задача у вас?
Расскажите ситуацию — скажем, что делали в подобных проектах и с чего начать.