Наводим порядок в отчетах

УПРАВЛЕНИЕ ДАННЫМИ  Наводим Категория:  УПРАВЛЕНИЕ ДАННЫМИ ОТЧЕТЫ
Опубликовал:         04.11.2018               print

По мере роста компании её бизнес-процессы покрываются различными информационными системами: CRM, E-Commerce, CMS, ERP, FRP, ABS, HRM, SCM, WMS, DWH, Business Intelligence и другими. Каждая система порождает N-ое количество отчетов: контрольно-оперативных, аналитических, обязательных/регламентных (для регулирующих организаций). Настаёт момент, когда необходимо организовать контроль, провести опись корпоративной отчетности.

Предпосылки, вводная для инвентаризации отчетности

  1. Расхождения в отчетах, путаница в цифрах и определениях;
  2. Утеря экспертизы по отчетам, методологии сбора и обработки данных;
  3. Не определены ответственные лица - специалисты по отчетам;
  4. Стихийное умножение новых отчетов, информационная интоксикация;
  5. Всё возрастающие расходы, операционные издержки на сопровождение, разработку отчетов;
  6. Персональные данные, детальный слой коммерческой тайны утекли наружу, за пределы предприятия или к конкурентам;
  7. Миграция IT-систем, переход на новые платформы, технологии;
  8. Реорганизация компании, объединение/поглощение предприятий;
  9. Требования регуляторов, персональные предпочтения ЛПР.


Каковы же методы систематизации отчетности?

  1. Офлайн опрос пользователей отчетов, лучше подготовить и использовать структурированные шаблоны опросников;
  2. Интервьюирование фокус-групп пользователей отчетов (большие собрания, хуралы, как правило, неплодотворны);
  3. Рабочие предметные встречи с ключевыми пользователями;
  4. Системный анализ данных, макетов отчетов, анализ чужого программного кода (может оказаться малоэффективным занятием восстановление сложной бизнес-логики по исходным кодам);
  5. Изучение нормативных документов, положений, инструкций, документации;
  6. Разработка "с нуля" новых отчетов взамен существующих;
  7. Наличие опыта, знание бизнес-процессов также помогает наведению порядка.


Каким образом, куда сводить, где накапливать получаемую информацию об отчетах?

  1. Первое, что приходит на ум, - в файл MS Excel - просто, быстро, почти бесплатно. Однако Excel - не база данных, не структурированный формат хранения, не обеспечивает разделяемый по полномочиям многопользовательский доступ. К тому же всяческих локальных файлов в сетевых папках и без того предостаточно. "Москва автоматизировала нас экселями" - что-то из эпохи XX века;
  2. Публиковать реестр отчетов на корпоративном портале, например, MS SharePoint в виде списков или таблицы Excel Serviсes. Затратно и по-прежнему местечковый способ, в отрыве от описания метаданных IT-систем (см. следующий пункт);
  3. Разработать подсистему справочников в рамках промышленной системы управления мастер-данными (MDM) компании, например, Microsoft Master Data Services (см. пример в прикрепленном к данной статье файле). Формализация знаний о метаданных баз данных, отчетности, IT-инфраструктуре - это тоже Master Data! При таком подходе метаданные взаимосвязаны между собой, доступны механизмы оповещения и уведомлений при изменениях, многопользовательский ролевой доступ, различные инструменты поиска и представления информации, web и custom интерфейс, Data API, подсистемы проверяемых бизнес-правил и ссылочной целостности данных, аудит изменений, отказоустойчивость;
  4. Если MDM решение недоступно по каким-либо причинам, то можно приспособить какой-то из имеющихся программных продуктов, об этом далее подробнее.


Вашему вниманию предлагается свободная модель Free model (FEM) флагманского CASE-продукта SAP PowerDesigner, адаптированная для каталога отчетов. Модель можно просматривать в бесплатной версии PowerDesigner Viewer, совместимой только с операционной системой MS Windows. Детально - подборка ссылок про PowerDesigner.
Каждый отчет - это Extended Object, которые можно компоновать на диаграмме по предметным областям (Area). В случае большой модели объекты можно логически декомпозировать на несколько диаграмм. Настраиваемое табличное представление дозволяет просматривать, редактировать и экспортировать данные в Excel.



Поскольку произвольная модель FEM предоставляет простор для творчества, то были созданы дополнительные обязательные, факультативные атрибуты, детерминированные списки, web-ссылочные поля, поля-ссылки на объекты других моделей, а также пользовательская форма-карточка и VB-скрипт проверки вводимых данных. Форма-карточка вызывается по двойному щелчку на указателе строки в табличном представлении или на объекте в иерархическом списке слева или на графическом представлении в диаграмме.



Атрибуты Код (Code) и Наименование (Name) - системные, обязательные для заполнения, должны иметь уникальные значения. Код - автоматически генерируемый счетчик с возможностью редактирования подходит как инвентарный номер отчета, который надобно представить в макете отчета. Желательно не закладывать никакую логику в номер отчета, а использовать простое синтетическое число, так проще. Если уж требуется особого смысла в номере, то можно разделить номера на диапазоны, например, до 1000 - это отчеты по продажам, от 1000 до 2000 - отчеты по логистике и т.д. Хотя наименование отчета обязано отражать его бизнес смысл, всё же сквозная идентификация отчетов по номерам удобнее, поскольку наименования могут быть схожими, а содержания отчетов претерпевать изменения.


Чем больше качественных характеристик определено для каждого отчета, тем лучше. Так, разнообразная классификация отчетов помогает подобрать, выбрать интересные профильные отчеты и только потом запрашивать к ним доступ, приступать к формированию. Хорошо продуманные ключевые слова, заполненные теги упрощают мультиселект поиск отчетов.


Непременно должны быть зафиксированы системные наименования, технологии разработки и пути к местонахождению шаблонов последних версий отчетов. Потребители и разработчики вправе знать, где хранятся эти макеты, а не подключаться к "сарафанному радио" и не прибегать к широковещательным рассылкам-опросам.


Данные о заказчиках, специалистах и разработчиках важны, потому что извещают к кому обращаться в случае проблем, получения консультаций. Поскольку кадровые, организационно-структурные изменения весьма имеют место быть, то соответствующие строковые поля носят свободный характер. Заказчик - это владелец ввереных отчетов, методолог, эксперт в предметной области. Развитие, изменение ведомых отчетов надлежит обсуждать и согласовывать с заказчиком, что может способствовать оптимизации отчетности, ее количеству и качеству. Институт заказчиков, владельцев следует развивать, поскольку это не только персональная ответственность, но и нематериальная мотивация. Также не должно быть бойцов невидимого фронта, компания должна знать своих героев - разработчиков интересных отчетов.
Дата создания, последней модификации позволяют судить насколько древний или современный тот или иной отчет. Более того, данные об авторах, заказчиках, инвентарный номер, даты сотворения и реконструкции, входные параметры, ограничения подобает публиковать в самих отчетах, дабы они не выглядели бесхозными и неполными.
Если предстоит / осуществляется реинжиниринг отчетности, то будут полезными поля о статусе отчете и заменяющем отчете, т.е. храним всё в одном реестре.


И, пожалуй, самое сложное:

  • • Содержательное описание бизнес-логики отчетов, допущений и ограничений, если они есть;
  • • Аккумулировать примеры принятия решений на основании отчетов (user story);
  • • Приводить пояснения как интерпретировать графики, диаграммы, тренды, цифры в таблицах - что считать благоприятным развитием бизнеса, а какие ситуации являются проблемными.


Кратко некоторые тезисы по отчетам

  1. В теле (содержании) каждого отчета должны быть представлены:
    инвентарный номер отчета,
    наименование отчета,
    Заказчик(и) (ФИО, подразделение, должность),
    Разработчик (ФИО, подразделение, должность),
    особые условия / допущения / ограничения отчета,
    дата создания и дата последней доработки,
    дата-время формирования отчета,
    значения входных параметров (фильтров данных);
  2. Наименования (заголовки) столбцов табличной части отчетов должны соответствовать бизнес-именованиям атрибутов сущностей модели данных DWH (использоваться корпоративный бизнес-словарь), а также сопровождаться системными английскими наименованиями соответствующих атрибутов модели данных;
  3. В широких таблицах столбцы необходимо логически компоновать вместе, применять группировки, использовать "заморозку" колонок при горизонтальной прокрутке;
  4. Дизайн отчетов должен быть выдержан в едином корпоративном стиле, органичным для восприятия, без обжигающих глаза цветов;
  5. Шрифты должны быть отчетливыми, комфортными для прочтения;
  6. Аналитические сводные таблицы желательно сопровождать графиками, диаграммами, уместны Dashboard (информационные панели);
  7. Пространство макета следует заполнять по-максимуму: диаграммы и все объекты необходимо компактно располагать на странице, но читабельными;
  8. В процедурах формирования данных отчетов должна быть предусмотрена защита от сверх нагрузок, т.е. в случае запрашиваемого большого объема данных к выдаче (сотни тысяч, миллионы записей) надобно информационное сообщение пользователю;
  9. Доступ пользователей к собственно отчетам и данным в отчетах - согласно разработанной и утвержденной ролевой матрице доступа;
  10. На корпоративном портале / web-сайте, в разделе "Отчеты" можно ввести рубрикатор, отбор отчетов по ключевым словам-тегам - 4 поля, мультиселект с выбором из списка;
  11. В разделе "Отчеты" (как предложение) можно сделать функциональность голосования (+1 нравится, -1 не нравится) по каждому отчету. Голосование - однократное по каждому отчету с опциональной возможностью оставить комментарии;
  12. В разделе "Отчеты" уместно создать быстрые web-ссылки, галерею скриншотов, область "Избранное" для наиболее популярных отчетов (обеспечение посещения в 1-2 клика).


Data Governance подразумевает процесс сертификации отчетов: отчет считается не сертифицированным, если его владельцы не могут показать прослеживаемость данных по всему пути происхождения. Отчет должен быть активом, которому можно доверять. Сертификация отчетов - это не только хороший способ показать ценность активов, но и отличный способ отсеять избыточные, устаревшие, неправильные отчеты.

Основные этапы сертификации отчета:

  1. Установление владельца отчета;
  2. Владельц отчета определяет критические элементы данных;
  3. Обеспечение прослеживаемости потоков и преобразований данных от источника(ов) до отчета;
  4. Измерение показателей качества данных на различных этапах их прохождения в организации;
  5. Подтверждение соответствия данных отчета [отраслевым] корпоративным стандартам и правилам качества данных.


Подведем итоги. Создание единого каталога корпоративной отчетности - трудоемкая регулярная работа, важная часть Управления Данными. Используя удобные инструменты можно определять различные полезные классификационные атрибуты отчетов с целью контроля, управления отчетностью.



Энергия идеи   dvbi.ru                    Последнее изменение: 2021-12-12 23:03:41Z         Возрастная аудитория: 14-70         Комментариев:  0
Прикрепленные файлы:
 

Пример реестра отчетов в MS Master Data Services (MDS)

              Размер: 505.4 Кб            Скачали раз: 35
 

Пример модели данных (FEM) SAP PowerDesigner, адаптированной для каталога отчетности

              Размер: 38.26 Кб            Скачали раз: 22

Теги:   Примеры Управление
Связанные статьи:

Пожалуйста, проголосуйте и ниже поставьте лайк:   rating


  Комментарии



Следующая статья:    Размышления о Яндекс MDM
Предыдущая статья:  Сила иерархий аналитических измерений