Как повысить доверие к управленческой отчетности

B статье В. Зубова (Intersoft Lab) в АБЖ представлено 4 группы проблем с качеством данных при подготовке управленческой отчетности и показано, как они решаются в ИТ-проектах на основе платформы «Контур».

Если в докризисный период задача подготовки управленческой отчетности с помощью хранилища данных было целью каждого четвертого проекта, то в посткризисные годы – уже каждого третьего. Практика показывает, что критерием передачи созданного решения в промышленную эксплуатацию является не способность системы формировать отчетные формы, а уверенность специалистов финансовых департаментов банков в том, что данным в отчетах можно доверять. Типовой цикл подготовки отчетности включает сбор информации из различных источников в хранилище, консолидацию и последующую интерпретацию, говоря иначе, обработку (классификацию, вычисление расчетных показателей, их агрегацию и тому подобные действия) для представления в виде витрин данных либо готовых отчетных форм. Ошибки обработки, безусловно, встречаются, но их количество и частоту можно считать незначительными по сравнению с недостоверностью отчетных цифр, порожденной низким качеством первичных данных, поступающих в хранилище из учетных моделей.

Выделим четыре группы наиболее существенных проблем с качеством первичных данных и покажем на реальных примерах, как они решались в ходе реализации ИТ-проектов по  подготовке управленческой отчетности на базе ПО «Контур» производства Intersoft Lab.

Ошибки в данных

Ошибки в исходных данных – это некорректно заполненные или незаполненные значения атрибутов информационных объектов в АБС, учетных модулях и других первичных системах. Эти ошибки, как правило, определяет человеческий фактор, нарушение регламентов ввода первичных данных либо недостаточная проработка (детальность) регламентов. Например, при вводе информации о клиенте в CRM-систему могут быть неверно указаны значения КЛАДР, а при заполнении карточки по договору пропущен такой важный атрибут, как клиентский менеджер – он необходим для получения управленческой отчетности в соответствующем аналитическом разрезе.

Для выявления подобных случаев в платформе «Контур» предусмотрен целый ряд проверок, осуществляемых на разных этапах загрузки и обработки данных в хранилище и приложениях для финансовой консолидации и подготовки управленческой отчетности. Например, контроль полноты и правильности заполнения атрибутов информационных объектов, корректность первичной информации с точки зрения бухучета, точности классификационных и идентификационных кодов, соответствия данных синтетического учета и аналитического учета и т. д. В настоящий момент в совокупности поддерживается более 400 различных проверок. Результаты их выполнения фиксируются в специальных журналах, которые становятся основой для анализа и исправления данных в исходных системах. Например, упомянутые выше ошибки с КЛАДР и незаполненные значения атрибута «Клиентский менеджер» целесообразнее устранять в источнике.

Ошибки, связанные с «белыми пятнами» в АБС

Нередко анализ качества данных на стороне хранилища выявляет ошибки в работе учетных систем. Вот ситуация из проектной практики: при закрытии счета механизмы АБС не контролируют, чтобы остаток по счету был равен нулю. В результате в хранилище загружается остаток по закрытому счету. Возникает неоднозначная ситуация, например из-за того, что остаток мог попасть в расчет баланса, который был выполнен в АБС. В хранилище данных «Контур» эта ошибка выявляется на этапе загрузки данных, после чего соответствующий лог загрузки (журнал, в котором фиксируются ее результаты) анализируют сотрудники банка, ответственные за выгрузку информации из АБС. На основании данных журнала принимается решение, каким образом следует устранить возникшую проблему: исправлять ли ошибки в исходной системе или же в хранилище у закрытого счета нужно проставить признак «Открыт».

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

Проблематика клиентских данных

Данные о клиентах – отдельный больной вопрос. Причинами ошибок в отчетности. может быть дублирование данных о клиентах, которые заводят разные операционисты в разных функциональных модулях и в разных подразделениях банка, пропущенные или неверно заполненные значения атрибутов и др. Так, чтобы получить управленческую отчетность по клиентам банка в отраслевом разрезе на основе ОКВЭД, при занесении в учетную систему информации о клиенте нужно указывать вид его хозяйственной деятельности. Однако в реальности любое коммерческое предприятие может быть одновременно отнесено к нескольким видам деятельности. Поэтому, если у операционистов банка нет инструкции по идентификации клиента, они будут заносить значение ОКВЭД по своему усмотрению, что может исказить информацию и в итоге отчетность окажется некорректной. Для обеспечения надлежащего качества данных скорее всего потребуется решать проблему не в хранилище данных, а обеспечить комплекс организационных мер: разработать регламенты работы с оперативными системами и хранилищем данных, закрепить за сотрудниками права и ответственности при заполнении сведений о контрагенте, научить сотрудников, как проверять коды и пр.

Другой источник этой категории проблем – высокая изменчивость клиентских данных. Рассмотрим такой случай: на протяжении какого-то времени размер бизнеса клиента банка менялся (например, от микро к малому, от среднего к крупному), а в АБС история изменения этого атрибута не хранилась. Если не отслеживать такие изменения в хранилище, пострадает отчетность. В хранилище «Контур» поддерживается историзация значений атрибутов контрагента, что способствует корректности отчетности.

Несогласованность данных в различных исходных системах

Нередко данные, полученные из специализированных учетных модулей и основной банковской системы, не совпадают.

Например, в проекте по автоматизации подготовки управленческой отчетности возникла ситуация, когда в разрезе продуктов данные аналитического учета в «карточном» модуле (в нем хранилась информация по более чем 6 млн пластиковых карт) не совпадали с данными бухучета в модуле «Главная книга» в АБС. Когда их загрузили в хранилище данных «Контур», запустили штатную процедуру, проверяющую суммарные остатки субсчетов и остатки сводных лицевых счетов на соответствие. После исполнения проверки было выявлено расхождение между остатками по субсчетам «карточном» модуле и остатками по сводному счету, загруженному из модуля «Главная книга». В связи с тем что данные на лицевом счете входят в бухгалтерскую отчетность и являются эталоном, в этом конкретном случае банком было принято решение исправлять указанную нестыковку в рамках приложения «Управленческий учет», входящего в состав платформы «Контур». В управленческую отчетность добавили корректирующую статью, где прописывалась разница между «эталонным» значением и итоговой суммой остатков по субсчетам. То есть банк воспользовался штатными инструментами приложения «Контур».

Нехватка данных в исходных системах

Нередко в АБС не хватает исходных данных для подготовки управленческой отчетности. Чаще всего это связано с тем, что в этих системах ведения требуемых для отчетности аналитических атрибутов не предусмотрено. Скажем прямо, установка необходимой аналитики непосредственно в учетном модуле не всегда возможна. Например, не стоит поручать операционистам устанавливать на лицевых счетах признак статьи управленческого учета, так как это не свойственная им задача, которая, с одной стороны, создает необходимость разработать регламент заполнения признака, а с другой, даже с таким дополнительным регламентом определение статьи в каждом конкретном случае замедлит основную работу исполнителя.

Ситуации, когда недостающие аналитическими признаки в бухгалтерский учет можно добавить из данных других источников встречаются в проектах очень часто. Чтобы выполнить такое обогащение, в хранилище данных или приложении для подготовки управленческой отчетности должны быть предусмотрены необходимые инструменты, осуществляющие, как минимум, классификацию первичных данных недостающими аналитическими признаками. Например, чтобы получить управленческую отчетность по финансовым результатам в разрезе продуктов, в одном из проектов компании Intersoft Lab была использована информация об оказанной банком услуге, которая фиксировалась при выполнении операций (в учетных данных АБС информация о продукте отсутствовала). В хранилище «Контур» был создан справочник банковских продуктов, который помог установить связь между банковскими продуктами и услугами, что позволило с помощью механизмов классификации приложения «Управленческий учет» обогатить данные бухгалтерского учета признаком «Банковский продукт» и выпустить отчетность в требуемом разрезе.

Бывает, что для решения проблемы нехватки исходных данных для управленческой отчетности, приходится идти на определенные допущения. Так, в практике Intersoft Lab  в АБС одного из банков отсутствовал аналитический признак ЦФО. Чтобы построить управленческую отчетность в разрезе ЦФО, было введено правило, что каждый клиент закрепляется за «своим» клиентским менеджером. В справочнике ЦФО, который сформировали в хранилище «Контур», была настроена связь «Клиент – ЦФО», что позволило проставить на всех учетных объектах, связанных с клиентом, аналитику ЦФО. Упомянутые выше интерфейсы классификации помогли снабдить данные бухучета признаками ЦФО, после чего управленческую отчетность в этом аналитическом разрезе была получена.

Подведем итог

Как показывает опыт, существенная часть недостатков в исходных данных для управленческой отчетности можно выявить заранее – при  развертывании хранилища данных Для этого в ходе проекта внедрения ошибки в исторических данных исправляются непосредственно в учетных системах; принимаются организационные меры, которые помогут избежать определенных типовых ошибок и проблем в дальнейшем, дорабатываются интерфейсы ввода данных и пр., настраиваются механизмы обогащения.

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

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

Автор: В. Зубов

Источник: Аналитический банковский журнал, 2014, № 3, с 64-67