Управление данными и их качеством — важный компонент общего процесса управления бизнесом. О том, какие практические задачи решает модель данных и как грамотно ее спроектировать, рассказывает архитектор информационных систем IBS Елена Юрина.
Данные как корпоративный актив
В современном цифровом мире информация поступает из множества источников и непрерывно накапливается. Если хранить ее бессистемно, любая база данных быстро теряет ценность, а для взвешенных управленческих решений нужна качественная аналитика. Закономерно, что бизнес все чаще обращает внимание на управление данными и рассматривает этот процесс как одну из важных корпоративных функций наряду с управлением производством, финансами, логистикой и персоналом.
Управление данными представляет собой организационную инициативу, направленную на оптимизацию, защиту и использование информации как корпоративного актива. К основным характеристикам качественных данных относятся достоверность, достаточность, своевременность, надежность, прозрачность и непротиворечивость. Поскольку источниками информации являются все участники бизнес-процессов компании, управление данными становится стратегическим сквозным процессом, неотделимым от управления бизнесом в целом.
Типичные проблемы
Данные нередко появляются быстрее, чем их удается обработать. Классический пример — подразделения компании заключают большое количество хозяйственных договоров, причем на различных условиях, затем начинаются операции по их исполнению, часть из них с нарушением графиков, часть — с отходом от прочих договорных условий. В результате могут возникать проблемы с оборотным капиталом и платежеспособностью. Чтобы найти причину, сотрудникам приходится тратить много времени на анализ документов: сверять операции по учету, анализировать корреспонденцию с контрагентами, выполнять большой объем ручного труда.
Еще одно узкое место — отчеты, формируемые вручную. Они создают возможности как для случайной ошибки, так и для умышленного сокрытия негативных моментов. Например, прогноз до последнего дается в оптимистическом варианте, а затем внезапно обнаруживается провал в бизнес-показателях. К подобным данным доверия быть не может. Выводы, сделанные на их основе, будут некорректными. Кроме того, подготовка отчетности вручную не позволяет достичь нужного уровня оперативности в предоставлении данных руководству.
Зачастую схожие или идентичные показатели в разных системах или отчетах не совпадают. Случается, что компания не располагает даже точной информацией о выручке, потому что в операционной системе отображается одно значение, в бухгалтерской — другое, а в управленческом учете — третье. Так происходит из-за того, что системы считают завершением операции различные действия. Например, в них отличаются даты признания выручки или по-разному отражаются возвраты, претензии и корректировки.
Долгая подготовка данных, отсутствие уверенности в происхождении цифр, построение аналитики на неполных данных — список сложностей можно продолжать. Ответ на подобные вызовы — автоматизированные алгоритмы обработки данных, которые не зависят от исполнителя и обеспечивают необходимую скорость и точность обработки информации. Нужна единая версия правды, когда информация вводится в контур компании строго однократно и далее преобразуется по определенным правилам. Для этого требуется грамотная организация хранилища данных с возможностью построения над ним систем отчетности, планирования, моделирования и др. Спроектировать такое хранилище помогает модель данных (МД).
Уровни модели данных
На каждом уровне корпоративного управления — стратегическом, тактическом, оперативном — решается свой круг задач, при этом потоки данных пронизывают всю структуру компании. Если не выстроить единую модель, охватывающую все сквозные цепочки появления и преобразования данных, могут возникнуть информационные разрывы. Например, на практике часто приходится наблюдать, как у компаний теряется связь между ключевыми показателями эффективности, установленными на стратегическом уровне, и оперативными результатами на местах. Модель данных обеспечивает целостность информационной картины, связывая между собой все показатели и их детализацию.
Выделяют три уровня модели данных:
- На концептуальном уровне формируется общее представление о составе мест возникновения данных и их основных потоках в разрезе бизнес-процессов компании. Основные задачи — анализ методологии процессов и архитектуры целевого ИТ-ландшафта, выделение релевантных сущностей с их аналитическими признаками и определение связей между ними.
- Логический уровень более детально описывает информационные потоки и содержимое проектируемой базы данных. На этом уровне определяется конкретный состав показателей и источники их получения, продумываются перспективные направления развития управленческой аналитики, формируется перечень справочников, определяется их структура и наполнение, а также закрепляются ответственные за их ведение. Важными компонентами моделей данных на логическом уровне являются алгоритмы и таблицы соотношений между различными объектами МД (формулы расчета производных показателей, контрольные соотношения и т. п.).
- Физический уровень определяет, как логическая модель данных воплощается в фактическую структуру базы данных в конкретной аппаратно-программной среде. На этом уровне выполняется настройка хранилища.
Что входит в модель данных
Модель данных включает каталог показателей, которые необходимы владельцам и участникам автоматизируемых процессов. Например, для процесса формирования управленческой отчетности нужен полный перечень всех показателей этой отчетности, а также вспомогательных данных, задействованных в их расчете.
Следующий компонент модели данных — правила формирования показателей: ручной ввод, загрузка или расчет. В случае загрузки дополнительно прописывается источник, периодичность и срезы данных; для расчета — формула.
Помимо этого, в модели содержится перечень и подробное описание всех справочников, классификаторов и перечислений, задающих аналитические разрезы показателей. Для каждого справочника раскрывается его структура: иерархия элементов, атрибутивный состав, возможные значения, либо требования к ним.
Если справочник аналитический, редко изменяется и применяется разными пользователями, в модели данных приводится его конкретное наполнение. Классический пример — статьи затрат. Некоторые справочники являются транзакционными. Например, договоры. В этом случае фиксировать в модели данных перечень самих договоров не имеет смысла, но нужно указать, какие поля обязательны для заполнения во всех документах, а какие релевантны только для отдельных видов.
Для всех показателей должны быть определены:
- уникальный код, уровень иерархии;
- источник получения показателя;
- используемые аналитики (срезы, измерения) и при возможности их значения;
- форма ввода или отчета, документ или процесс, в которых используется каждый показатель.
Для всех аналитик нужно определить:
- уникальные коды и значения;
- элементный и атрибутивный состав;
- соотношение с другими аналитиками.
Модель данных также содержит мэппинги — таблицы с описанием соответствий объектов данных как в рамках одной системы, так и между различными системами. Например, это могут быть связи между показателями и аналитиками принимающей системы и систем-источников при организации сбора фактических данных. В этом случае дополнительно решается задача по разработке методики сбора факта. МД также описывает и внутрисистемные мэппинги: например, соотношение статей бюджета доходов и расходов (БДР) и бюджета движения денежных средств (БДДС) в модели данных системы бюджетирования.
Задачи, которые решает модель данных
Системный подход к разработке модели данных дает вполне определенные практические результаты. Каталогизация показателей в привязке к их потребителям обеспечивает гарантию востребованности данных. Если у показателя нет владельца и он не используется ни в одной отчетной форме, он избыточен. Конкретные ID показателей дают четкую идентификацию данных при интеграции. Присвоение показателям квалификационных и функциональных признаков облегчает навигацию по модели данных, упорядочивает ее. Функциональные признаки закрепляют отношение показателя к процессам, владельцам и формам. Квалификационные — определяют его тип и место: первичный он или групповой, какой уровень занимает в иерархии, какой у него родительский показатель и т. п. База расчетных показателей с формулами гарантирует полноту исходных данных для любого расчета, ведь каждая формула строится строго на объектах, которые есть в модели. Если данных не хватает, это сразу выявляется, и недостающие элементы добавляются в МД.
Грамотно построенную модель данных также отличает правильная компоновка аналитик относительно друг друга. Если значение одной аналитики можно задать на основании другой, такая связь реализуется либо через атрибутивный состав справочника, либо через механизм мэппинга. Например, если у статьи затрат есть однозначный ЦФО-владелец, то аналитику финансовой структуры целесообразно сразу включить в справочник статей как атрибут. Если заранее предусмотреть в справочнике квалификационные признаки для его элементов, впоследствии на их основе можно будет строить различную отчетность, включая гибкую. Особенно полезен подобный подход для больших, информационно нагруженных справочников, таких как номенклатура или статьи затрат.
Системное ведение в модели данных описания всех ее справочников трудно переоценить, потому что это залог нормализованной НСИ, а мэппинги между различными объектами модели — один из способов минимизировать пользовательские ошибки и основа для контрольных процедур.
Построение модели данных с нуля — серьезная задача, но не менее важно и в дальнейшем поддерживать ее в актуальном состоянии. При изменении одних объектов необходимо отслеживать и актуализировать все внутренние взаимосвязи, прослеживая каждую цепочку до конца. Для этого разрабатываются специальные инструкции по управлению изменениями.
При создании хранилища данных и автоматизации процессов подготовки отчетности целевая модель данных выстраивается до начала работ, выполняемых в информационной среде. Это фундамент будущей системы и ее опора. Чем детальнее и продуманнее она будет, тем более качественным получится результат.
Источник: Елена Юрина, архитектор информационных систем IBS
