Я обнаружил, что самая эффективная реализация функции дата-стюардов находится в бизнес-подразделении[129]. Дам вам десять баллов, если сможете засунуть их в департамент разбора жалоб клиентов, где они на месте смогут разбираться в проблемах с качеством клиентских данных.
Да, именно «там», где пишут жалобы через сайтик, контакт-центр или от руки (на бумажечке), должны сидеть дата-стюарды, которые работают с клиентскими данными.
К сожалению, все проблемы дата-стюарды решить не могут, иначе бы они рассыпались на много маленьких некрасивых кусочков.
На сцену выходит вторая боевая группа, которую я называю дата-инженеры. Как, надеюсь, понятно из слова «инженер», эти ребята должны что-то строить и проектировать. И все действительно так: они проектируют единую архитектуру управления качеством данных (проверки, средства контроля и, конечно, дизайн самих IT-систем и цифровых интерфейсов[130]). Если сравнивать обе команды, то инженеров должно быть меньше, потому что это более высококвалифицированные единицы.
Точка дислокации этой группы может быть разной. В организациях, где директор по данным (CDO) не является ключевым сотрудником компании и находится где-нибудь на уровне Board-2[131], такая команда может находиться как внутри финансового блока, так и внутри IT-блока.
Эффективнее будет расположить инженеров ближе к команде IT-блока, так как эти ребята должны непосредственно изучать IT-системы, углубляться в процессы и предлагать решения.
В случае, когда организация слишком продвинутая и зрелая, CDO обычно выступает уже на уровне Board входит в Правление или стоит максимум на одну ступень ниже, но по-прежнему остается ключевым сотрудником.
Теперь вопрос. Где взять таких людей для позиции инженера по качеству данных на рынке? Если начать поиски на HeadHunter или на других подобных порталах, то достаточно быстро станет ясно, что количество релевантных кандидатов для обеих позиций оставляет желать лучшего.
Я выкручивался тем, что брал людей из других подразделений, создавая таким образом возможности для горизонтального роста. Происходило это как внутри компании, так и с привлечением соискателей из вне.
Инженеров я искал и брал как из службы IT-поддержки, так и из смежных департаментов, где есть бизнес-экспертиза. В службах IT-поддержки я руководствовался тем, что люди при разборе тех или иных инцидентов и проблем в IT-сервисах, вынуждены погружаться в то, как работают сами IT-решения.
Бизнес-экспертиза необходима, потому что инженер должен понимать, как влияет на бизнес выявленная ошибка в данных.
Бизнес-экспертиза необходима, потому что инженер должен понимать, как влияет на бизнес выявленная ошибка в данных.
В качестве инструмента сведения и демонстрации общего эффекта проблем с качеством данных, я выбрал подход так называемого документа «аппетит к риску».
«Аппетит к риску» это специальный документ, отражающий размер потенциальных рисков, которые несет в текущий момент организация, он политика относительно текущей позиции и ее фиксирования.
История документа лежит в Базельских требованиях. Это требования, которые были приняты международным сообществом (Базельским комитетом) как достаточные требования для управления банковским капиталом, чтобы иметь возможность управлять риском банковского банкротства (дефолта), а точнее, иметь возможность его предсказывать.
Так вот, «аппетит к риску» это внутренний документ, который готовит организация для того, чтобы в момент измерить, достаточно ли у нее капитала для покрытия возможных убытков, которые могут возникнуть, если что-то пойдет не так. Сюда в том числе относятся действия и самой организации, когда она решается на более рискованные стратегии или запуск сложных продуктов. Надеюсь, кратко, но понятно. Этот документ обычно режет глаз, он должен показывать то, что у организации больше нет возможностей для маневров, и служить отрезвляющим душем для менеджеров.
После участия в проектах управления Базельскими требованиями внедрения сложных механизмов расчета достаточности капитала, мне показалось интересным применить логику построения этого документа к оценке рисков, которые содержат в себе некачественные данные.
И если раньше, когда я приходил в Правление организации, мне было сложно объяснить важность управления качеством данных, то, создав такой документ, где мы наглядно отразили размер потенциальных убытков от плохих данных (те же штрафы за поле «ИНН»), я смог сфокусировать внимание менеджмента на самом важном. На бабках.
Только такой язык сегодня понятен внутри бизнеса. Если ты явно покажешь, что качество данных создает убыток для организации, с высокой степенью вероятности, ты получишь новый ресурс для решения этой проблемы или митигации этого риска.
Есть много подходов и визуализаций отражения и создания классического документа «аппетит к риску». Все они применимы к созданию аналогичного документа в отношении качества данных.
В классическом варианте такой документ выделяет виды капитала (регуляторный, экономический) и виды рисков, но что же он должен показывать в отношении данных?
Как измерять качество данных?
Не буду претендовать на уникальность и вернусь к работе аудиторов. Уж очень она яркий отпечаток оставила в моей памяти. Мое вечное желание все вокруг связывать и комбинировать в поисках прорывных решений не дает мне об этом просто так забыть.
Как проверить что конкретная цифра в весьма конкретной отчетности верна?
Оказалось, очень просто: аудитор в своей работе использует так называемые «assertions» или «допущения», которые разбиты на определенные группы, коих опять конечное количество. Есть такой стандарт по международному аудиту номер 315[132], которым обязаны руководствоваться международные компании по аудиту. Так вот он говорит, что этих самых «assertions» в части финансовой отчетности всего 13 штук и они все поделены на три определенные группы.
Первая группа таких допущений относится к транзакциям и формируемой прибыли:
1. Наличие (Occurrence) транзакция или событие действительно имело место и реальности произошло.
2. Полнота (Completeness) транзакции, которые произошли, были отражены полностью.
3. Точность (Accuracy) все данные касательно транзакций отражены без искажений.
4. Срез (Cutoff) транзакции произошли в правильном отчетном периоде.
5. Классификация (Classification) транзакции были отражены на правильном счете и правильной строчке.
Вторая группа уже касается остатков и самого баланса, и выглядит она следующим образом:
1. Существование (Existence) актив, обязательство или указанный капитал действительно существуют.
2. Права и обязанности (Rights and Obligations) то, что отражено в отчетности, и организация непосредственно это контролирует.
3. Полнота (Completeness) все, что реально существует, все это отражено полностью во всех соответствующих строчках отчетности (активы, обязательства, капитал).
4. Оценка и распределение (Valutation and allocation) все, что реально было, отражено корректно с точки зрения оценки этих объектов. К примеру, ценные бумаги, которыми владеет организация, должны быть отражены по самой последней рыночной котировке и так далее.
3. Полнота (Completeness) все, что реально существует, все это отражено полностью во всех соответствующих строчках отчетности (активы, обязательства, капитал).
4. Оценка и распределение (Valutation and allocation) все, что реально было, отражено корректно с точки зрения оценки этих объектов. К примеру, ценные бумаги, которыми владеет организация, должны быть отражены по самой последней рыночной котировке и так далее.
Третья группа уже касается непосредственно раскрытий и пояснений финансовой отчетности:
1. Существование (Occurrence) все, что было раскрыто и пояснено в отчетности, оно действительно случилось. Если в отчетности написано, что сгорел завод, значит, он действительно сгорел.
2. Полнота (Completeness) все, что в реальности было, тоже раскрыто. Если еще сгорел амбар помимо завода, и это важно, то это нужно раскрыть.
3. Классификация и понимание (Classification and understanability) вся финансовая информация должна быть представлена таким образом, чтобы было все просто и понятно. Никаких сложных раскрытий и сложных описаний.
4. Точность и оценка (Accuracy and valuation) все посчитано честно и аккуратно.
Надеюсь, сознание после этих трех групп еще не потухло, идем дальше. Когда работает аудитор, он оценивает материальные искажения в каждом из этих тринадцати измерений. Материальность отклонения также определяют по разным правилам. Так управляется риск контроля качества информации в финансовой отчетности.
Мне показался данный подход достаточно зрелым, поэтому я взял его за основу и попробовал упростить для того, чтобы сделать единую методологию.
Прежде стоит отметить, что раньше аудиторам помогали специальные напарники, которые аудировали, как работают IT-системы, хранящие первичную информацию для отчетности.
Эти люди при проверке IT-систем изучали, как работает контроль в отношении данных. Должны были быть ответы на такие простые вопросы: «Откуда данные?», «Кто может их изменить?», «Как проверяется корректность значений?», «Какие программные средства использует организация для исправления проблем?» и так далее.
Они используют опросы, изучают логи[133] подключений к системам и на выходе, по результатам своей работы, они могут сказать, в каких из измерений, скорее всего, будет проблема.
Эти самые «assertions» можно смело назвать «измерениями», то есть некоторым разделением того, как я воспринимаю объект в реальном мире.
Главное, что они должны говорить пользователю любое число или любые данные само по себе объект многомерный.
Вот я держу книгу. В стандартной проекции у нее три оси ширина от края разворота до середины, длина от одного края страницы до другого края страницы и толщина, то есть количество страниц. Книгу мы воспринимаем как физический объект в трех измерениях.
Так вот, информация сама по себе имеет много измерений, больше трех. И не факт, что их именно тринадцать. Чтобы управлять качеством этой информации, нужно управлять представлением этой информации в этих измерениях. Это сложный контекст, отчасти поэтому в качество данных мало инвестируют и мало этим занимаются, хотя, на мой персональный взгляд, ценность этого очевидна.