Ознакомительная версия. Доступно 9 страниц из 42
Точка дислокации этой группы может быть разной. В организациях, где директор по данным (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) – все, что реально было, отражено корректно с точки зрения оценки этих объектов. К примеру, ценные бумаги, которыми владеет организация, должны быть отражены по самой последней рыночной котировке и так далее.
Третья группа уже касается непосредственно раскрытий и пояснений финансовой отчетности:
1. Существование (Occurrence) – все, что было раскрыто и пояснено в отчетности, оно действительно случилось. Если в отчетности написано, что сгорел завод, значит, он действительно сгорел.
2. Полнота (Completeness) – все, что в реальности было, тоже раскрыто. Если еще сгорел амбар помимо завода, и это важно, то это нужно раскрыть.
3. Классификация и понимание (Classification and understanability) – вся финансовая информация должна быть представлена таким образом, чтобы было все просто и понятно. Никаких сложных раскрытий и сложных описаний.
Ознакомительная версия. Доступно 9 страниц из 42
