Итак, в компании возникло понимание того, что ситуация с нормативно-справочной информацией уже очень существенно ограничивает возможности развития компании и требует срочного решения.
Идеи, которые предлагаются на этой стадии, обычно представляют собой крайние точки диапазона возможных вариантов. Некоторые компании склонны недооценивать масштаб вопроса и предполагают, что справочники легко почистят имеющиеся специалисты, потратив на это месяц рабочего времени. Другая крайность – появляются мысли о «тяжеловесных» ИТ-решениях, которые объявляются панацеей от всех бед, связанных с качеством данных, но обычно требуют значительного объема ресурсов, выраженных как в деньгах на консультантов, внедряющих эти решения, так и в человеко-часах своей команды. Истина же, как водится – посередине.
Следует избавиться от иллюзии о том, что раз проблемы создавались изо дня в день привычными действиями специалистов не очень высокого уровня (бухгалтеров, кладовщиков, менеджеров по закупкам – кто реально формирует ваши справочники?) – то пусть они и будут решены усилиями этих же специалистов. Легко предписать этим людям необходимость в ближайший месяц отредактировать номенклатуру – но действительно ли они способны с этим справиться? Это как раз та ситуация, выход из которой нельзя найти на том уровне, на котором она возникла. Раз проблема с данными зашла так далеко, то компания почувствовала ее значимость – то необходимость управлять ситуацией, создавать для нее правила и контролировать их исполнение порождает новую роль с новым функционалом, который сложно приписать кому-то из имеющихся сотрудников. На высоком уровне развития такое решение приводит к появлению в компании позиции Chief Data Officer – человека, который вместе со своими подчиненными отвечает за управление данными как одним из основных активов компании и обеспечивает всем подразделениям компании полноту, непротиворечивость и необходимую структурированность того общего массива данных, на основании которых принимаются бизнес-решения. Однако такая роль становится актуальна в компаниях, оперирующих большими объемами записей – на первых ступенях развития системы управления данными дополнительный функционал обычно присоединяется к имеющейся позиции директора по закупкам, финансового директора, бизнес-аналитика, специалиста по консолидированной отчетности.
Для экономии дальнейших усилий также нелишним было бы разделить для себя вопросы качества мастер данных и качества тех бизнес-процессов, в рамках которых мастер-данные лишь используются. Качество данных не является «волшебной таблеткой», которая склеит те разрывы в бизнес-процессах, которые существуют в компании. Нередко приходилось видеть компании, в которых различные системы существуют изолированно друг от друга – например, процесс закупок организован на базе отдельной системы и не обменивается данными с бухгалтерской системой, или система технического обслуживания не связана с системой складского хранения и с бухгалтерской системой. Созданная на базе отдельного модуля система управления основными данными, безусловно, сможет обеспечить единый «язык» внутри вашей компании и выгрузить во все используемые программы данные из единого источника, но не заставит ваших подрядчиков называть товары в накладной так, как они называются в ваших внутренних документах, и не расскажет кладовщику, что именно ему сейчас приходовать на склад – все эти процессы все равно придется организовывать дополнительно.
В том же ряду стоит задача применения различных классификаций – правильно организованные классификации соответствуют специфике бизнес-процессов компании и поддерживают их, предоставляя именно ту группировку данных, которая полезна конкретной группе пользователей. Однако внесение таких дополнительных признаков группировки может быть одним из этапов каталогизации, но не заменять ее как процесс идентификации записи по принципу «Что это?», а не «Для чего это?» или «Где это используется?» - такие признаки являются дополнительной информацией к описанию продукта. Эта ошибка очень характерна для ситуации, когда знаний об управлении качеством данных недостаточно, и компания в целом еще находится в начале пути к зрелому управлению данными. Добросовестно выполненный проект по нормализации качества мастер-данных предоставляет прочную базу для применения любых принципов группировки данных, но разработка таких принципов является частью бизнес-консалтинга, направленного на оптимизацию конкретных бизнес-процессов. Часто консультанты по качеству данных под давлением заказчиков включают в объем своих контрактов и разработку или оптимизацию классификаций. Однако если речь идет не о том, что выбранная классификация некорректно применялась в прошлом, и теперь нужно в процессе идентификации записей проверить также правильность их отнесения к конкретным группам, в большинстве случаев предложение консультанта сводится к применению одной из общепринятых классификаций и в результате обеспечит потребности лишь части пользователей. Тем не менее, если ваши предполагаемые консультанты ранее осуществляли проекты для компаний вашей отрасли (и особенно лидеров рынка), то, вероятно, они смогут предложить вам скопировать ту классификацию, которая применялась в каком-то из таких проектов – и тогда по сути это означает, что ваши данные обогащаются за счет применения лучших практик лидеров, что иногда является оправданным решением. Тем не менее, такая копируемая система классификации все равно нуждается в адаптации под уникальные требования вашей компании, которую должны выполнить специалисты, глубоко понимающие, как и для чего ее применять.