Post #437

Проектирование системы управленческой отчетности, часть 2. Итак, у нас есть реестр систем и набор показателей, которые нам нужно выводить. Теперь нужно понять, как это лучше сделать. Вариантов три: — вытащить все данные из всех систем в отдельное аналитическое хранилище, нормализовать и уже к нему прикрутить любую систему построения отчетности; — выбрать систему, в которой уже есть большинство данных и средства для построения отчетов (в данном случае это был, например, Битрикс24), и попробовать втащить туда недостающие данные; — "размазать" отчеты по системам: если данные есть в одной системе, и там же можно построить отчет — строим там. Если нужны данные из двух систем, которые ими не обмениваются сейчас — вытаскиваем данные в отдельное хранилище и строим отчет там. Решения отличаются по скорости реализации и по системности: можно быстро нашлепать отчетов в тех системах, где данные уже есть, но этим не очень удобно пользоваться; можно выстроить нормальную систему ETL, аналитическое хранилище и дэшборды. Напомню, что у нас было две развилки: анализ существующих систем (а) и анализ абстрактных требований к отчетам (б). Идём по ним так: 7б. На основе реестра отчетов и их макетов формируем требования к системе построения отчетности — для последующего выбора. Просто функциональные требования к системе. 7а. Смотрим, какие есть возможности систем-источников (отдельный документ): внешние API, в том числе вебхуки; какие можно делать выгрузки (в Excel, CSV, 1С), можно ли добраться до БД. Описываем все варианты интерфейсов, для каждого указываем нюансы использования и состав данных, имеющиеся ошибки. Например, Битрикс24 в вебхуках отдает только ID изменившегося объекта, но не говорит, что именно изменилось. А в выгрузке он запросто может отдать две строки для одной сделки, в которых будут одинаковые идентификаторы, одинаковые идентификаторы товара, но разные названия и разная стоимость. Вот все такие штуки мы фиксируем в ещё одном документе: 8. Недостающая информация и проблемы. У нас могут быть проблемы надежности выгрузки, недостаток данных, разные идентификаторы, дублирование или склеивание записей, отсутствие идентификаторов, дублирование идентификаторов; разный формат вводимых вручную идентификаторов; нерегулярность учетной модели (когда сделка фактически завершена, но в системе это не отражается, "все и так знают"); неоднозначность источника данных: одна и та же информация может быть записана в разных полях (для такого типа сделки смотри число товаров в этом поле, а для другого — в этом поле не смотри, там бред, смотри в дополнительной таблице, или признак оплаты, который может быть отмечен в четырех разных полях); значимая информация в комментариях в произвольном формате; в принципе отсутствие в электронном виде информации или классификаторов; нарушенная ссылочная целостность — и наверняка я забыл ещё множество других проблем с качеством данных. Без приведения в порядок структуры и содержания данных никакую достоверную отчетность мы не соберем. 9. Поэтому имеет смысл построить эталонную концептуальную модель данных бизнеса — инфологическую, то есть без опоры на какую-либо технологию. Сделать из неё базу данных и попробовать наполнить её реальными данными из бизнеса — узнаем много интересного. Физическая модель может быть в итоге совсем другой — Data Vault, или анкорной, или ещё какой. 10. Выбираем системы для построения отчетов (дэшбордов), в том числе встроенные в имеющиеся системы (к Битриксу, скажем, недавно прикрутили несколько урезанный Apache Superset), пытаемся в них собрать нужные нам отчеты и опытным путем проверить возможность реализации требований из п 7б. Заодно проверяем на дружелюбие к пользователю и понятность.