При создании любого бизнеса каждое из его подразделений автоматизирует само себя. Как правило сквозные потоки данных между ними единичны. Это приводит к тому, что данные нельзя сопоставить друг с другом, ведь каждый отдел считает их по-своему. Никаких проблем, если собирать какие-то метрики в целом по компании, но когда доходит дело до расчета сквозных показателей, прогнозов или решения задач моделирования и оптимизации, начинается хаос.
Хранилища данных (DWH) — не новая история. Традиционно они использовались для составления отчетности. А вот полноценное моделирование и прогнозирование сквозных бизнес-процессов на данных DWH началось относительно недавно. Используя собранные данные современные инструменты анализа позволяют не просто делать дашборды с выпадающими окнами, но еще и настраивать в отношении каждого атрибута алгоритмы прогнозирования и оптимизации, масштабировать алгоритмы теории игр на все предприятие в целом. А также строить и сразу же тестировать гипотезы о дальнейшем развитии бизнеса на реальных данных.
И вроде как звучит всё прекрасно. Но не все компании спешат брать с пример с передовиков (Booking.com, Amazon.com) и продолжают работать по старинке. Так что же им мешает? Как минимум, понимания целесообразности масштабных инвестиций в инструментарий по обработке данных, трудозатратность внедрения процессов описания данных, появления новых ролей (кураторы данных, ответственные за качество данных, инженеры и архитекторы данных и т.п.), научиться считать экономический эффект от внедрения управления данными, четко вычленять драйверы затрат, как сделать дата офис самоокупаемым, увязать со стратегией компании и из возможных вызовов выбрать те, которые продвинут компанию вперед, и многое другое.
Меня зовут Виктория Краснова, я руководитель Управления корпоративными данными СИБУРа. Вместе с моим коллегой, лидером команды Data Governance Ринатом Абдурахмановым, расскажем, как это делаем мы.
Когда начали оцифровываться крупные ритейлеры (Wallmart), им предстояло понять, какие цифровые следы и артефакты оставляет после себя один бизнес-процесс и что из этого принимает на вход следующий. То есть описать сквозной бизнес-процесс. То же самое требуется для цифровизации любой другой компании. Одним из способов ответить на этот запрос является концепция Управления данными и data-архитектура.
В прикладном смысле это означает: собрать наиболее важные и не очень данные компании в одном месте, описать их понятным языком, привязать к бизнес-процессам и создать user-friendly методы доступа к этим данным.
Архитектура данных, среди своих прочих функций, дает четкие ответы на вопросы «где считается?», «что считается?», «зачем считается?», «кто отвечает за качество?» и «где находится, в какой системе лежит?».
Важно, чтобы ответы на эти вопросы были отделены от самого бизнеса. Часто бывает так: аналитик хочет протестировать какую-нибудь гипотезу. Чтобы это сделать, ему нужно идти и выпрашивать нужные данные у их владельца, доказывать, почему и зачем это нужно и важно, тратить на это половину рабочего дня. В лучшем случае. И в итоге получить отказ. Почему? Потому что владелец данных несет ответственность за предоставление доступа к данным и их последующее распространение, потому что неизвестно как эти данные будут трактоваться аналитиком и возможно его это не устроит и т.п.
Поэтому нужно выстраивать такую структуру и логику, которая будет интуитивно понятна, работать по единым правилам и не будет отвлекать ни самого аналитика, ни владельца данных от непосредственных задач.
Для этих целей отлично походит логическая модель данных — описание данных бизнес-языком детализации до технических деталей, в комбинации с гибкой ролевой моделью. В этом случае аналитик получает доступ к хранилищу и набору данных на основании своей роли в компании. И требуемый набор данных он собирает исходя из здравого смысла, а не от знания, что в 2005 году в компании работал некий товарищ, в файлике которого и лежат искомые данные.
Такой подход к структурированию позволяет людям быстро проводить анализ, делает данные сопоставимыми, и в результате позволяет достичь вторичной выгоды – поэтапно оцифровать весь бизнес.
У нас в СИБУРе некоторые процессы оцифрованы достаточно хорошо, например, подготовка данных для маркетинга, финансы, управление цепями поставок, производственные данные и обходы производственных установок. Со всем остальным сложнее, потому что СИБУР — это производство с таким циклом, в котором с точки зрения бизнеса нет потребности собирать информацию с той же скоростью, как это нужно в ритейле, телекомах или банках. Соответственно, вопрос скорости при анализе данных тоже не стоял. Но сложно — не значит невыполнимо. В этом году мы планируем оптимизировать процессы, сделать подсчет данных более прозрачным, увеличить скорость передачи данных для принятия решений, также начать собирать цифровые следы на всех этапах процессов, где это возможно.
Почему в цифровых компаниях точность данных и скорость их передачи для принятия решений высока? Потому что у них практически нет запаса на то, чтобы совершить ошибку, если данные вдруг окажутся неправильными. В производстве все иначе — оно не остановится, заводы не встанут, если будет какая-то неточность в данных для аналитики. Поэтому архитектура данных — это та самая сила, которая вопреки всему ведет производство в цифровом направлении. А управление данными — библиотека, позволяющая навести упорядочить потоки данных по всей компании.
Недавно мы запустили направление, которое занимается описанием данных. Пока мы находимся в поисках инструмента для того, чтобы данные описывать, хранить и комфортно получать доступ к описаниям. Если инструмент для описания будет неудобный, и из-за этого мы не сможем поддерживать каталогизацию в актуальном состоянии, то пользоваться им уже не будет никакого смысла. Как следствие, сами данные в хранилище могут оказаться неактуальными. Зачем нам что-то строить на основе данных, срок годности которых уже истек?
Здесь перед нами стоит еще одна задача: как мотивировать архитекторов, сопровождающих уже существующие информационные системы, описывать данные и поддерживать их в актуальном состоянии. В цифровых компаниях популярен принцип “You build it, you run it”. У нас исторически внедряет сложилось так, что внедряют одни люди, а поддерживают другие. Часто документация не в самом актуальном состоянии, а некоторые алгоритмы живут только в головах старожилов. Поэтому описание систем — очень трудоемкая работа, особенно, когда она проводится с нуля (как в нашем случае). Ведь в реальности эффект от этой работы для них наступит сильно позже, только после описания критической массы данных. Но зато в итоге, при внедрении очередной новой системы, им не придется искать данные, чтобы ее запитать. Сейчас же на поиск этих данных уходит в среднем от двух недель и больше.
Данные нужны не только для того, чтобы внедрять новые системы, но и для тестирования гипотез. Их обычно возникает много, и тестируются они пачками. И по факту получается, что данные есть, их много, они разнообразные, но только на их поиск тратится уйма времени и денег.
Еще один момент, когда изменение данных «без предупреждения» в одном месте приводит к тому, что данные в другом месте становятся неправильными. Например, показатель «Объем производства» раньше учитывал потери на этапах переделов, а затем перестал. Систему поменяли, а остальные не в курсе, и продолжают использовать показатель как раньше. В итоге данные для принятия управленческого решения неправильные. Или в какой-то момент выясняется, что данные несопоставимы, люди начинают искать ошибки. А это тоже трудозатраты, только невидимые и несчитаемые.
В общем, как вы поняли, перед нами основательно встал вопрос выбора инструмента для работы с данными. А прежде, чем пойти и выбирать инструмент, надо написать адекватные критерии такого выбора.
Мы находимся в поиске инструмента, который поддерживал бы описание метаданных в виде объектной модели с возможностью самостоятельного добавления новых типов объектов. Не все продукты предлагают такую возможность. Например, некоторые инструменты позволяют отображать только физические таблицы в виде объектов, но отсутствует класс объектов под концептуальные или логические сущности.
Очень важна гибкая настройка связей между объектами. Например, сегодня у нас три логических уровня абстракции, но мы должны быть ограничены в возможности выкинуть или добавить любое количество уровней.
Другой важный критерий – наличие встроенных коннекторов к системам-источникам, особенно к SAP. У нас очень много SAPа (думаю, у любой большой компании в принципе очень много SAPa) — огромная инсталляция, и перелопачивать его руками — труд совершенно неблагодарный. Идеально, если он есть. Если такого коннектора нет, то его можно написать самостоятельно.
Не будем забывать про полнотекстовый поиск, семантический поиск с возможностью добавления собственных словарей синонимов (например, интегрированный Elasticsearch).
Важную роль играет возможность обратной связи. Причем в идеале должны быть возможности комментирования, оценки по принципу 1-5 звезд, прямой связи с ответственным за сущность или атрибут конкретной сущности, а также простановка флажков и тегов для обращения внимания, а также добавления объектов в «Избранное»
В придачу к этому хорошо бы иметь нативный коннектор к SAS DQ или любому другому инструменту, который можно использовать для оценки качества данных и отображения индекса здоровья конкретной сущности, чтобы пользователь мог сразу видеть, что данным можно доверять, потому что по ним пробежались с проверкой. И дать свою обратную связь по этому поводу.
В общем, нужно что-то такое:
Вот вам для примера типичный кейс: человек увидел, что данным можно доверять, посмотрел повнимательнее и нашел ошибку, и прямо написал владельцу с просьбой исправить. Получается такая витрина здоровья данных. Такая открытость и повсеместная доступность данных постепенно сбавляет градус недоверия как пользователей, так и владельцев. Аналитик даже с самым базовым доступом к данным может быстро получить нужную информацию, которая прошла проверку, и в то же время он не зависит от владельца данных, который эту информацию вносит. Win-win.
Но обычно все у всех в Excel, и это большая проблема (не сам Excel, конечно, а такая ситуация). Люди посчитали показатели, потом их у себя же в табличке поправили, а в общей системе ничего не изменилось. И аналитику страшно взять какую-нибудь цифру из общедоступных корпоративных источников, проще пойти к коллеге и попросить файл. С этим довольно сложно бороться. Фактически критерием успех внедрения дата – офиса можно считать создание сред, в которой сотрудники, как правило, при принятии решения опираются на результаты анализа, а из инструментов предпочитают SQL и Python.
Отдельно стоит упомянуть ведение актуальных статусов данных «Коммерческая тайна», «Публичные данные», «Персональные данные», «Корпоративные данные ограниченного распространения». То есть для аналитика данных важно знать, что именно он сейчас просматривает и выгружает или дает посмотреть коллегам.
Ведь когда среднестатистический человек обращается к законодательству, связанному с коммерческой тайной и конфиденциальной информацией, он видит обобщенную информацию о том, что может нанести компании вред. В частых случаях начинают считать критичными данными вообще все, что содержит цифры (вдруг чего). Соответственно, на просьбу предоставить данные для анализа владелец начинает спрашивать себя: «не коммерческая ли это тайна?», «не причинят ли действия просящего вред компании?», и, перестраховываясь, часто отказывает. Ведь он ответственный за эту информацию, и не знает, как аналитик будет ее использовать.
Был еще такой случай: когда мы работали над списком конфиденциальной информации для проекта по демократизации данных, оказалось, что в этом списке есть данные, которые владельцы называют конфиденциальными, а мы по закону обязаны их предоставлять на официальном сайте. И, естественно, они там опубликованы. То есть в условиях, когда нет какого-то единого инструмента, в котором все одномоментно могут увидеть однозначно выверенную информацию, очень много людей работают в режиме «как бы чего не вышло» и сильно перестраховываются.
Так вот, это все про критерии. А вот из чего именно мы выбирали.
Мы говорим “выбирали” потому, что еще не выбрали, мы все еще находимся в поиске идеального инструмента. Изначально мы выбирали из Collibra, SAS DG, Alation, Alteryx Connect и Informatica. Просматривали также зарубежные опенсорс-проекты, но их почти сразу отмели, потому что никто не умеет работать с кириллицей.
Потом случился неудачный опыт с Collibra. Мы практически завершили сделку, но она сорвалась — не договорились об условиях. В ближайшей перспективе они полностью переезжают в облако, и для любой российской компании это не вариант. По сути, они будут давать не продукт, а сервис: Collibra предоставляет подписку, а мы — свои данные. Формально это не коммерческая тайна, а метаданные, но фактически, если что-то пойдет не так, бизнес будет полностью парализован.
После этой истории мы поняли, что коробку будем выбирать еще долго: у нас длинные процессы, мы внимательно подходим к сделкам, к условиям, к контрагентам, проверяем все много раз, чтобы убедиться, что риск минимальный. Зная обо всех этих особенностях, мы пошли в собственную разработку, чтобы сделать хотя бы временное решение для пользователей. Ведь данные льются, а пользоваться ими без описания невозможно! Параллельно мы присматриваемся к Alation и Alteryx Connect и сравниваем их функциональности и стоимость со своим решением.
Логическую модель хранилища мы придумывали сами, нам тут немного сложнее, чем другим отраслям. Например, для банков и телекомов есть референсные архитектуры данных — общепринятые структуры и рекомендации, на что и как данные раскладывать. Для нефтехимии полного цикла источников для творческого заимствования в открытом доступе нет. Год ушел только на то, чтобы понять, как работает бизнес в целом. У СИБУРа сложное производство, огромное количество номенклатуры, процессов, бизнесов, что отражается в системах, а значит, требует анализа.
Тут нам помогло то, что присутствует так называемая наукоемкость руководства. Скажем, в других отраслях довольно часто менеджеры и управляющие не слишком сильно разбираются в самой отрасли. Так бывает, в принципе, это не что-то прямо ужасное, в конце концов, их дело проекты менеджерить, вот и получается, что каждое новое звено менеджеров обычно знает чуток меньше предыдущего. У нас же получилось так, что менеджерами являются люди, которые в состоянии тебе на пальцах объяснить все процессы, которые могут произойти с бутадиеном на всем его жизненном пути, например.
Так вот, про решение. Творческий поиск штука такая, что может занимать год, два, или пару жизней. Поэтому поиск — это хорошо, но на чем-то работать надо уже прямо сейчас.
Итак, мы пошли в собственную разработку, назвали ее dg_light. Разработка фронта заняла 4 недели (сказать по правде, не с «нуля», мы переиспользовали наработки недавно сошедшего с конвейера инструмента по анализу таймшитов).
Состав проекта:
Структура объектов хранения и методология поступила на вход от архитекторов данных. Для проработки дизайна фронта сажали рядом аналитиков разной степени зрелости и спрашивали: «а как тебе было бы удобно?». По сути, рисовали для себя.
Вся разработка заняла 6 недель.
Резонный вопрос, что мы будем делать с решением, когда купим промышленное? Изначально планировалось, что оба решения будут жить параллельно: в «большом» DG останутся модели данных, глоссарий, ролевая модель, а в dg_light отходят сложные фишки, которые непросто реализовать в коробочном решении типа data lineage. Что будет в дальнейшем покажет опыт использования.
Физика. Все началось с построения модели данных хранилища. Мы долго спорили о том, как строить детальный слой хранилища, и решили, что не возьмем в работу одну готовую концепцию, а скомбинируем Data Vault 2.0 и Anchor (6NF). Опять же потому, что источники данных у нас самые разные. С одной стороны это SAP, который в глубине где-то OLAP, а где-то OLTP, и бизнес-логика, живущая по своим законам и требующая максимальной детализации. С другой стороны живут насыщенной жизнью системы управления производственным процессом (MES – manufacturing execution system), в которых сплошняком идут потоки данных и key-value истории.
Комбинация хабов, сателлитов, линков из DV2.0 и максимальная гранулярность Анкора позволили поженить все это в одном месте. Да, вручную писать запросы в такой системе будет сложно, но зато все ее содержимое лежит правильно. И мы можем гарантировать целостность системы, даже если все вокруг внезапно начнет меняться или рушиться.
Логика. Решив вопрос с организацией архитектуры на физическом уровне, мы перешли к ее логическому описанию. И наша с коллегами дискуссия перенеслась в философскую плоскость в попытке определить для себя, что есть сущность и как они соотносятся друг с другом. Поспорив некоторое время, обратились к DAMA-DMBOK, вытащили из нее определения и наложили на свой контекст. В результате получилось, что сущности — это существительные, которыми мы оперируем в рамках СИБУРа, имеющие законченную бизнес-ценность и отвечающие на ряд вопросов. До сих пор ведутся споры о том, включать или не включать в сущности агрегаты и отчеты. У каждого архитектора есть свое мнение, свои расчеты, и сейчас мы пытаемся привести наши мысли к общему знаменателю. Это одна из задач, которую предстоит решать в том числе людям, которых мы ищем в команду.
Но логическая модель — это еще не все. Дополнительно на ее базе мы строили еще и концептуальную модель, необходимую руководству для понимания того, что вообще происходит. Логическая модель для них слишком детальная, поэтому мы сгруппировали все в домены данных, которые хорошо ложатся на описанные бизнес-процессы в компании. Сейчас пытаемся договориться с процессным офисом, чтобы каждую такую группировку логических сущностей привязывать к процессам в ARIS.
Дальше мы пошли вширь и еще выше: создали единую логическую модель данных, куда вписываем логические сущности каждой системы, указывая при этом системы источников с указанием связей систем между собой.
Это знание мы экспортируем корпоративным архитекторам в Sparx Enterprise Architect, им оно необходимо для привязки сущностей к интеграционным потоками и интерфейсам.
Такая организация архитектуры данных в дальнейшем поможет людям, которые планируют заниматься импакт-анализом, из нее можно будет построить полноценный Data Lineage. А вообще мы рассчитываем, что решением будут пользоваться не только архитекторы всех мастей, но люди от аналитики в бизнес-подразделениях, дата-саентисты и все, кто хоть как-то связан с анализом.
Теперь перед нами стоит более трудоемкая задача — как научить сотрудников всем этим пользоваться.
В глобальных планах у нас — сделать из СИБУРа data-driven-компанию, когда абсолютно любой сотрудник может что-то проанализировать. Общую стратегию мы поделили на три части — про людей, про процессы и про инструменты. С инструментами, можно сказать, вопрос решили, сделали свою платформу с данными. Теперь надо, чтобы люди начали этим пользоваться.
Главная особенность заключается в менталитете сотрудников. Они работают на опасном нефтехимическом производстве, где на каждый чих кровью написана техника безопасности. И люди обучены четко соблюдать инструкции, это буквально отпечатывается на подкорке. Такое состояние сильно противоречит свободному мышлению аналитика.
Мы начали с малого: постепенно отучать сотрудников делать презентации по любому мало-мальски значимому поводу и пересаживать их на дашборды. Поскольку люди в компании ответственные и исполнительные, они пытаются взять готовую презентацию и нарисовать все то же самое в интерактивном варианте. Но дашборды живут по другим законам, и для человека это совершенно другой уровень трудозатрат, это нужно подгрузить всю историю данных и выверять их. Данные становятся автоматически рассчитываемыми и неманипулируемыми — руками их не поменяешь, если изначально нормально не настроить.
Фактически вся автоматизация внутренних процессов заканчивается на связке Excel + почта. А пересаживать людей с Excel — задача практически невыполнимая. Ну правильно, зачем нам Python и SQL, ведь в Excel можно сделать все! И с этим довольно сложно бороться.
В предыдущих версиях системы управления данными в СИБУРе было такое понятие, как владелец информационного архива — сотрудник, который дает доступ к данным и знает, где какая цифра правильная. Такой подход создавал барьеры, о которых я писала выше. Чтобы их сломать, мы воспользовались «лучшими практиками» от Gartner и отдельно выделили куратора данных и ответственного за качество данных.
Куратор данных — это менеджер уровня директора подразделения, который определяет правила, по которым готов давать доступ к данным. Ответственный за качество данных работает непосредственно с самой информацией и знает, какая цифра правильная. Теперь мы работаем над тем, чтобы в отношении каждой цифры был человек, ответственный за качество, который будет реагировать на запросы коллег в случае ошибки или неточности. Уже сейчас мы делим данные на доступные всем внутри компании, на доступные в рамках конкретного подразделения и на информацию, представляющую коммерческую тайну.
И если какой-нибудь руководитель захочет закрыть конкретные данные, мы проводим челночные переговоры и объясняем, как закрытие информации повлияет на другие подразделения, прямо или косвенно работающие с ней. Таким образом, процент данных, открытых внутри компании, пересмотрелся кардинально. По меркам СИБУРа это настоящая революция.
У нас есть готовый инструмент, но пока очень мало людей, которые могут им пользоваться. И мы их воспитываем. Процесс заметно ускорился после того, как мы выстроили процесс веерного обучения, когда каждый сотрудник, которого мы обучили, берет на себя обязательства обучать следующих. Мы пошли по пути обучения собственных сотрудников вместо найма аналитиков, потому что в нашем случае проще научить богов макросов SQL и Python, чем офигенным аналитикам объяснить про пиролиз и его особенности. И смотреть на их лица при этом.
Как мы привлекаем людей и мотивируем учиться — история, достойная отдельного поста.
Помимо воспитания внутренних аналитиков мы находимся в поиске архитекторов, людей, которые разбираются в управлении данными. Это новое направление не только для России, но и мира в целом, и люди продолжают трактовать понятие архитектуры данных кто во что горазд. Есть понятные истории с бизнес-аналитикой, системной аналитикой, корпоративной архитектурой.
Мы в СИБУРе определяем архитектуру данных как дисциплину на стыке системных штук с базами данных и процессами, связанными с бизнесом. Человек должен понимать, как устроена организация, в которой он работает, и каким образом процессы оставляют о себе данные в разных системах. И как первое связать со вторым.
Хранилища данных (DWH) — не новая история. Традиционно они использовались для составления отчетности. А вот полноценное моделирование и прогнозирование сквозных бизнес-процессов на данных DWH началось относительно недавно. Используя собранные данные современные инструменты анализа позволяют не просто делать дашборды с выпадающими окнами, но еще и настраивать в отношении каждого атрибута алгоритмы прогнозирования и оптимизации, масштабировать алгоритмы теории игр на все предприятие в целом. А также строить и сразу же тестировать гипотезы о дальнейшем развитии бизнеса на реальных данных.
И вроде как звучит всё прекрасно. Но не все компании спешат брать с пример с передовиков (Booking.com, Amazon.com) и продолжают работать по старинке. Так что же им мешает? Как минимум, понимания целесообразности масштабных инвестиций в инструментарий по обработке данных, трудозатратность внедрения процессов описания данных, появления новых ролей (кураторы данных, ответственные за качество данных, инженеры и архитекторы данных и т.п.), научиться считать экономический эффект от внедрения управления данными, четко вычленять драйверы затрат, как сделать дата офис самоокупаемым, увязать со стратегией компании и из возможных вызовов выбрать те, которые продвинут компанию вперед, и многое другое.
Меня зовут Виктория Краснова, я руководитель Управления корпоративными данными СИБУРа. Вместе с моим коллегой, лидером команды Data Governance Ринатом Абдурахмановым, расскажем, как это делаем мы.
Когда начали оцифровываться крупные ритейлеры (Wallmart), им предстояло понять, какие цифровые следы и артефакты оставляет после себя один бизнес-процесс и что из этого принимает на вход следующий. То есть описать сквозной бизнес-процесс. То же самое требуется для цифровизации любой другой компании. Одним из способов ответить на этот запрос является концепция Управления данными и data-архитектура.
В прикладном смысле это означает: собрать наиболее важные и не очень данные компании в одном месте, описать их понятным языком, привязать к бизнес-процессам и создать user-friendly методы доступа к этим данным.
Архитектура данных, среди своих прочих функций, дает четкие ответы на вопросы «где считается?», «что считается?», «зачем считается?», «кто отвечает за качество?» и «где находится, в какой системе лежит?».
Важно, чтобы ответы на эти вопросы были отделены от самого бизнеса. Часто бывает так: аналитик хочет протестировать какую-нибудь гипотезу. Чтобы это сделать, ему нужно идти и выпрашивать нужные данные у их владельца, доказывать, почему и зачем это нужно и важно, тратить на это половину рабочего дня. В лучшем случае. И в итоге получить отказ. Почему? Потому что владелец данных несет ответственность за предоставление доступа к данным и их последующее распространение, потому что неизвестно как эти данные будут трактоваться аналитиком и возможно его это не устроит и т.п.
Поэтому нужно выстраивать такую структуру и логику, которая будет интуитивно понятна, работать по единым правилам и не будет отвлекать ни самого аналитика, ни владельца данных от непосредственных задач.
Для этих целей отлично походит логическая модель данных — описание данных бизнес-языком детализации до технических деталей, в комбинации с гибкой ролевой моделью. В этом случае аналитик получает доступ к хранилищу и набору данных на основании своей роли в компании. И требуемый набор данных он собирает исходя из здравого смысла, а не от знания, что в 2005 году в компании работал некий товарищ, в файлике которого и лежат искомые данные.
Такой подход к структурированию позволяет людям быстро проводить анализ, делает данные сопоставимыми, и в результате позволяет достичь вторичной выгоды – поэтапно оцифровать весь бизнес.
Какие задачи стоят перед нами
У нас в СИБУРе некоторые процессы оцифрованы достаточно хорошо, например, подготовка данных для маркетинга, финансы, управление цепями поставок, производственные данные и обходы производственных установок. Со всем остальным сложнее, потому что СИБУР — это производство с таким циклом, в котором с точки зрения бизнеса нет потребности собирать информацию с той же скоростью, как это нужно в ритейле, телекомах или банках. Соответственно, вопрос скорости при анализе данных тоже не стоял. Но сложно — не значит невыполнимо. В этом году мы планируем оптимизировать процессы, сделать подсчет данных более прозрачным, увеличить скорость передачи данных для принятия решений, также начать собирать цифровые следы на всех этапах процессов, где это возможно.
Почему в цифровых компаниях точность данных и скорость их передачи для принятия решений высока? Потому что у них практически нет запаса на то, чтобы совершить ошибку, если данные вдруг окажутся неправильными. В производстве все иначе — оно не остановится, заводы не встанут, если будет какая-то неточность в данных для аналитики. Поэтому архитектура данных — это та самая сила, которая вопреки всему ведет производство в цифровом направлении. А управление данными — библиотека, позволяющая навести упорядочить потоки данных по всей компании.
Недавно мы запустили направление, которое занимается описанием данных. Пока мы находимся в поисках инструмента для того, чтобы данные описывать, хранить и комфортно получать доступ к описаниям. Если инструмент для описания будет неудобный, и из-за этого мы не сможем поддерживать каталогизацию в актуальном состоянии, то пользоваться им уже не будет никакого смысла. Как следствие, сами данные в хранилище могут оказаться неактуальными. Зачем нам что-то строить на основе данных, срок годности которых уже истек?
Здесь перед нами стоит еще одна задача: как мотивировать архитекторов, сопровождающих уже существующие информационные системы, описывать данные и поддерживать их в актуальном состоянии. В цифровых компаниях популярен принцип “You build it, you run it”. У нас исторически внедряет сложилось так, что внедряют одни люди, а поддерживают другие. Часто документация не в самом актуальном состоянии, а некоторые алгоритмы живут только в головах старожилов. Поэтому описание систем — очень трудоемкая работа, особенно, когда она проводится с нуля (как в нашем случае). Ведь в реальности эффект от этой работы для них наступит сильно позже, только после описания критической массы данных. Но зато в итоге, при внедрении очередной новой системы, им не придется искать данные, чтобы ее запитать. Сейчас же на поиск этих данных уходит в среднем от двух недель и больше.
Данные нужны не только для того, чтобы внедрять новые системы, но и для тестирования гипотез. Их обычно возникает много, и тестируются они пачками. И по факту получается, что данные есть, их много, они разнообразные, но только на их поиск тратится уйма времени и денег.
Еще один момент, когда изменение данных «без предупреждения» в одном месте приводит к тому, что данные в другом месте становятся неправильными. Например, показатель «Объем производства» раньше учитывал потери на этапах переделов, а затем перестал. Систему поменяли, а остальные не в курсе, и продолжают использовать показатель как раньше. В итоге данные для принятия управленческого решения неправильные. Или в какой-то момент выясняется, что данные несопоставимы, люди начинают искать ошибки. А это тоже трудозатраты, только невидимые и несчитаемые.
В общем, как вы поняли, перед нами основательно встал вопрос выбора инструмента для работы с данными. А прежде, чем пойти и выбирать инструмент, надо написать адекватные критерии такого выбора.
Критерии выбора инструментов
Мы находимся в поиске инструмента, который поддерживал бы описание метаданных в виде объектной модели с возможностью самостоятельного добавления новых типов объектов. Не все продукты предлагают такую возможность. Например, некоторые инструменты позволяют отображать только физические таблицы в виде объектов, но отсутствует класс объектов под концептуальные или логические сущности.
Очень важна гибкая настройка связей между объектами. Например, сегодня у нас три логических уровня абстракции, но мы должны быть ограничены в возможности выкинуть или добавить любое количество уровней.
Другой важный критерий – наличие встроенных коннекторов к системам-источникам, особенно к SAP. У нас очень много SAPа (думаю, у любой большой компании в принципе очень много SAPa) — огромная инсталляция, и перелопачивать его руками — труд совершенно неблагодарный. Идеально, если он есть. Если такого коннектора нет, то его можно написать самостоятельно.
Не будем забывать про полнотекстовый поиск, семантический поиск с возможностью добавления собственных словарей синонимов (например, интегрированный Elasticsearch).
Важную роль играет возможность обратной связи. Причем в идеале должны быть возможности комментирования, оценки по принципу 1-5 звезд, прямой связи с ответственным за сущность или атрибут конкретной сущности, а также простановка флажков и тегов для обращения внимания, а также добавления объектов в «Избранное»
В придачу к этому хорошо бы иметь нативный коннектор к SAS DQ или любому другому инструменту, который можно использовать для оценки качества данных и отображения индекса здоровья конкретной сущности, чтобы пользователь мог сразу видеть, что данным можно доверять, потому что по ним пробежались с проверкой. И дать свою обратную связь по этому поводу.
В общем, нужно что-то такое:
Вот вам для примера типичный кейс: человек увидел, что данным можно доверять, посмотрел повнимательнее и нашел ошибку, и прямо написал владельцу с просьбой исправить. Получается такая витрина здоровья данных. Такая открытость и повсеместная доступность данных постепенно сбавляет градус недоверия как пользователей, так и владельцев. Аналитик даже с самым базовым доступом к данным может быстро получить нужную информацию, которая прошла проверку, и в то же время он не зависит от владельца данных, который эту информацию вносит. Win-win.
Но обычно все у всех в Excel, и это большая проблема (не сам Excel, конечно, а такая ситуация). Люди посчитали показатели, потом их у себя же в табличке поправили, а в общей системе ничего не изменилось. И аналитику страшно взять какую-нибудь цифру из общедоступных корпоративных источников, проще пойти к коллеге и попросить файл. С этим довольно сложно бороться. Фактически критерием успех внедрения дата – офиса можно считать создание сред, в которой сотрудники, как правило, при принятии решения опираются на результаты анализа, а из инструментов предпочитают SQL и Python.
Отдельно стоит упомянуть ведение актуальных статусов данных «Коммерческая тайна», «Публичные данные», «Персональные данные», «Корпоративные данные ограниченного распространения». То есть для аналитика данных важно знать, что именно он сейчас просматривает и выгружает или дает посмотреть коллегам.
Ведь когда среднестатистический человек обращается к законодательству, связанному с коммерческой тайной и конфиденциальной информацией, он видит обобщенную информацию о том, что может нанести компании вред. В частых случаях начинают считать критичными данными вообще все, что содержит цифры (вдруг чего). Соответственно, на просьбу предоставить данные для анализа владелец начинает спрашивать себя: «не коммерческая ли это тайна?», «не причинят ли действия просящего вред компании?», и, перестраховываясь, часто отказывает. Ведь он ответственный за эту информацию, и не знает, как аналитик будет ее использовать.
Был еще такой случай: когда мы работали над списком конфиденциальной информации для проекта по демократизации данных, оказалось, что в этом списке есть данные, которые владельцы называют конфиденциальными, а мы по закону обязаны их предоставлять на официальном сайте. И, естественно, они там опубликованы. То есть в условиях, когда нет какого-то единого инструмента, в котором все одномоментно могут увидеть однозначно выверенную информацию, очень много людей работают в режиме «как бы чего не вышло» и сильно перестраховываются.
Так вот, это все про критерии. А вот из чего именно мы выбирали.
Поиск решения
Мы говорим “выбирали” потому, что еще не выбрали, мы все еще находимся в поиске идеального инструмента. Изначально мы выбирали из Collibra, SAS DG, Alation, Alteryx Connect и Informatica. Просматривали также зарубежные опенсорс-проекты, но их почти сразу отмели, потому что никто не умеет работать с кириллицей.
Потом случился неудачный опыт с Collibra. Мы практически завершили сделку, но она сорвалась — не договорились об условиях. В ближайшей перспективе они полностью переезжают в облако, и для любой российской компании это не вариант. По сути, они будут давать не продукт, а сервис: Collibra предоставляет подписку, а мы — свои данные. Формально это не коммерческая тайна, а метаданные, но фактически, если что-то пойдет не так, бизнес будет полностью парализован.
После этой истории мы поняли, что коробку будем выбирать еще долго: у нас длинные процессы, мы внимательно подходим к сделкам, к условиям, к контрагентам, проверяем все много раз, чтобы убедиться, что риск минимальный. Зная обо всех этих особенностях, мы пошли в собственную разработку, чтобы сделать хотя бы временное решение для пользователей. Ведь данные льются, а пользоваться ими без описания невозможно! Параллельно мы присматриваемся к Alation и Alteryx Connect и сравниваем их функциональности и стоимость со своим решением.
Логическую модель хранилища мы придумывали сами, нам тут немного сложнее, чем другим отраслям. Например, для банков и телекомов есть референсные архитектуры данных — общепринятые структуры и рекомендации, на что и как данные раскладывать. Для нефтехимии полного цикла источников для творческого заимствования в открытом доступе нет. Год ушел только на то, чтобы понять, как работает бизнес в целом. У СИБУРа сложное производство, огромное количество номенклатуры, процессов, бизнесов, что отражается в системах, а значит, требует анализа.
Тут нам помогло то, что присутствует так называемая наукоемкость руководства. Скажем, в других отраслях довольно часто менеджеры и управляющие не слишком сильно разбираются в самой отрасли. Так бывает, в принципе, это не что-то прямо ужасное, в конце концов, их дело проекты менеджерить, вот и получается, что каждое новое звено менеджеров обычно знает чуток меньше предыдущего. У нас же получилось так, что менеджерами являются люди, которые в состоянии тебе на пальцах объяснить все процессы, которые могут произойти с бутадиеном на всем его жизненном пути, например.
Так вот, про решение. Творческий поиск штука такая, что может занимать год, два, или пару жизней. Поэтому поиск — это хорошо, но на чем-то работать надо уже прямо сейчас.
Итак, мы пошли в собственную разработку, назвали ее dg_light. Разработка фронта заняла 4 недели (сказать по правде, не с «нуля», мы переиспользовали наработки недавно сошедшего с конвейера инструмента по анализу таймшитов).
Состав проекта:
- Backend: Docker, Node.js, NGINX, Crossbar.io
- Frontend: React, Redux, Material UI, Highcharts, Autobahn.js
- Хранение данных: PostgreSQL
- Протоколы: WAMP, WebSocket, HTTP(S)
- ОС: CentOS 7
Структура объектов хранения и методология поступила на вход от архитекторов данных. Для проработки дизайна фронта сажали рядом аналитиков разной степени зрелости и спрашивали: «а как тебе было бы удобно?». По сути, рисовали для себя.
Вся разработка заняла 6 недель.
Резонный вопрос, что мы будем делать с решением, когда купим промышленное? Изначально планировалось, что оба решения будут жить параллельно: в «большом» DG останутся модели данных, глоссарий, ролевая модель, а в dg_light отходят сложные фишки, которые непросто реализовать в коробочном решении типа data lineage. Что будет в дальнейшем покажет опыт использования.
Модель данных
Физика. Все началось с построения модели данных хранилища. Мы долго спорили о том, как строить детальный слой хранилища, и решили, что не возьмем в работу одну готовую концепцию, а скомбинируем Data Vault 2.0 и Anchor (6NF). Опять же потому, что источники данных у нас самые разные. С одной стороны это SAP, который в глубине где-то OLAP, а где-то OLTP, и бизнес-логика, живущая по своим законам и требующая максимальной детализации. С другой стороны живут насыщенной жизнью системы управления производственным процессом (MES – manufacturing execution system), в которых сплошняком идут потоки данных и key-value истории.
Комбинация хабов, сателлитов, линков из DV2.0 и максимальная гранулярность Анкора позволили поженить все это в одном месте. Да, вручную писать запросы в такой системе будет сложно, но зато все ее содержимое лежит правильно. И мы можем гарантировать целостность системы, даже если все вокруг внезапно начнет меняться или рушиться.
Логика. Решив вопрос с организацией архитектуры на физическом уровне, мы перешли к ее логическому описанию. И наша с коллегами дискуссия перенеслась в философскую плоскость в попытке определить для себя, что есть сущность и как они соотносятся друг с другом. Поспорив некоторое время, обратились к DAMA-DMBOK, вытащили из нее определения и наложили на свой контекст. В результате получилось, что сущности — это существительные, которыми мы оперируем в рамках СИБУРа, имеющие законченную бизнес-ценность и отвечающие на ряд вопросов. До сих пор ведутся споры о том, включать или не включать в сущности агрегаты и отчеты. У каждого архитектора есть свое мнение, свои расчеты, и сейчас мы пытаемся привести наши мысли к общему знаменателю. Это одна из задач, которую предстоит решать в том числе людям, которых мы ищем в команду.
Но логическая модель — это еще не все. Дополнительно на ее базе мы строили еще и концептуальную модель, необходимую руководству для понимания того, что вообще происходит. Логическая модель для них слишком детальная, поэтому мы сгруппировали все в домены данных, которые хорошо ложатся на описанные бизнес-процессы в компании. Сейчас пытаемся договориться с процессным офисом, чтобы каждую такую группировку логических сущностей привязывать к процессам в ARIS.
Дальше мы пошли вширь и еще выше: создали единую логическую модель данных, куда вписываем логические сущности каждой системы, указывая при этом системы источников с указанием связей систем между собой.
Это знание мы экспортируем корпоративным архитекторам в Sparx Enterprise Architect, им оно необходимо для привязки сущностей к интеграционным потоками и интерфейсам.
Такая организация архитектуры данных в дальнейшем поможет людям, которые планируют заниматься импакт-анализом, из нее можно будет построить полноценный Data Lineage. А вообще мы рассчитываем, что решением будут пользоваться не только архитекторы всех мастей, но люди от аналитики в бизнес-подразделениях, дата-саентисты и все, кто хоть как-то связан с анализом.
Теперь перед нами стоит более трудоемкая задача — как научить сотрудников всем этим пользоваться.
Люди и данные
В глобальных планах у нас — сделать из СИБУРа data-driven-компанию, когда абсолютно любой сотрудник может что-то проанализировать. Общую стратегию мы поделили на три части — про людей, про процессы и про инструменты. С инструментами, можно сказать, вопрос решили, сделали свою платформу с данными. Теперь надо, чтобы люди начали этим пользоваться.
Главная особенность заключается в менталитете сотрудников. Они работают на опасном нефтехимическом производстве, где на каждый чих кровью написана техника безопасности. И люди обучены четко соблюдать инструкции, это буквально отпечатывается на подкорке. Такое состояние сильно противоречит свободному мышлению аналитика.
Мы начали с малого: постепенно отучать сотрудников делать презентации по любому мало-мальски значимому поводу и пересаживать их на дашборды. Поскольку люди в компании ответственные и исполнительные, они пытаются взять готовую презентацию и нарисовать все то же самое в интерактивном варианте. Но дашборды живут по другим законам, и для человека это совершенно другой уровень трудозатрат, это нужно подгрузить всю историю данных и выверять их. Данные становятся автоматически рассчитываемыми и неманипулируемыми — руками их не поменяешь, если изначально нормально не настроить.
Фактически вся автоматизация внутренних процессов заканчивается на связке Excel + почта. А пересаживать людей с Excel — задача практически невыполнимая. Ну правильно, зачем нам Python и SQL, ведь в Excel можно сделать все! И с этим довольно сложно бороться.
В предыдущих версиях системы управления данными в СИБУРе было такое понятие, как владелец информационного архива — сотрудник, который дает доступ к данным и знает, где какая цифра правильная. Такой подход создавал барьеры, о которых я писала выше. Чтобы их сломать, мы воспользовались «лучшими практиками» от Gartner и отдельно выделили куратора данных и ответственного за качество данных.
Куратор данных — это менеджер уровня директора подразделения, который определяет правила, по которым готов давать доступ к данным. Ответственный за качество данных работает непосредственно с самой информацией и знает, какая цифра правильная. Теперь мы работаем над тем, чтобы в отношении каждой цифры был человек, ответственный за качество, который будет реагировать на запросы коллег в случае ошибки или неточности. Уже сейчас мы делим данные на доступные всем внутри компании, на доступные в рамках конкретного подразделения и на информацию, представляющую коммерческую тайну.
И если какой-нибудь руководитель захочет закрыть конкретные данные, мы проводим челночные переговоры и объясняем, как закрытие информации повлияет на другие подразделения, прямо или косвенно работающие с ней. Таким образом, процент данных, открытых внутри компании, пересмотрелся кардинально. По меркам СИБУРа это настоящая революция.
Вывод
У нас есть готовый инструмент, но пока очень мало людей, которые могут им пользоваться. И мы их воспитываем. Процесс заметно ускорился после того, как мы выстроили процесс веерного обучения, когда каждый сотрудник, которого мы обучили, берет на себя обязательства обучать следующих. Мы пошли по пути обучения собственных сотрудников вместо найма аналитиков, потому что в нашем случае проще научить богов макросов SQL и Python, чем офигенным аналитикам объяснить про пиролиз и его особенности. И смотреть на их лица при этом.
Как мы привлекаем людей и мотивируем учиться — история, достойная отдельного поста.
Помимо воспитания внутренних аналитиков мы находимся в поиске архитекторов, людей, которые разбираются в управлении данными. Это новое направление не только для России, но и мира в целом, и люди продолжают трактовать понятие архитектуры данных кто во что горазд. Есть понятные истории с бизнес-аналитикой, системной аналитикой, корпоративной архитектурой.
Мы в СИБУРе определяем архитектуру данных как дисциплину на стыке системных штук с базами данных и процессами, связанными с бизнесом. Человек должен понимать, как устроена организация, в которой он работает, и каким образом процессы оставляют о себе данные в разных системах. И как первое связать со вторым.