Архитектура интеграции

Есть легенда, что когда Билл Гейтс с коллегами продумывали архитектуру будущей Windows 3.1, они рисовали её от руки на склеенных ватманах. Маленькие квадратики обозначали блоки и модули системы, а стрелочки между ними потоки данных из одной системы в другую. Эта схема поместилась целиком на полу в кабинете у самого Гейтса, правда, пришлось вынести в коридор стол и стулья.

Год спустя, при проектировании новой операционки Windows 95, ребята вынесли целую столовую. Но через пару месяцев работы стало понятно, что и в ней места уже не хватит. И если позволить приложениям и дальше общаться с операционной системой и друг с другом по-старому, получится истинный ад бесконечных взаимосвязей и зависимостей. Нужен был принципиально другой подход



В результате родился шедевр инженерной мысли Win32 API. Это набор функций для связи компонентов и приложений Windows друг с другом, один из факторов, обеспечивших небывалую популярность для Windows 95 и последующих версий ОС Windows.

Интеграция

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

Особенно остро ситуация проявляется в крупных компаниях, где в интеграционном контуре может оказаться 10-20 разных информационных систем, и необходимо обеспечить непрерывность бизнес-процессов при передаче данных во всех направлениях.



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

В этой статье я хочу описать основные этапы процесса, как он обычно стихийно складывается в крупных компаниях. Ввести шкалу интеграционного развития компании от 1 до 10. Эта шкала, конечно, будет отражать и сам рост компании, рост уровня развития административных технологий в компании. А также хочу наметить основные векторы развития: куда бежать, что делать и кто во всём этом виноват. Шутка.

Для живости взял пример абстрактной производственной компании. С ней будет проще показывать, что повышение сложности в IT не самоцель, а ответ на всё новые вызовы, появляющиеся перед растущей компанией. Если у вас компания не производственная, а например, сфера услуг разница невелика. Некоторые шаги могут быть сдвинуты на уровень-другой вверх или вниз при сохранении общего сценария.

Также в статье почти нет названий конкретных продуктов или технологий, т.к. в области интеграции нет дорог, есть направления. Нет конкретного продукта, который просто поставил и пользуешься. Речь всегда будет идти о разработке, как минимум, коннекторов. Упоминаются 1С, Windows, Office как широко распространённое ПО, но вместо них без потери смысла можно подставить SAP, Linux и т.д.

Конечно, примеры упрощены в целях наглядности. Несколько вопросов останутся открытыми. И сам подход, как это всегда бывает в IT, не является единственно верным, поэтому приглашаю всех к дискуссии.

Эта статья будет особенно интересна руководителям IT, архитекторам, интеграторам, а также всем, кто работает в достаточно крупных компаниях.

Уровень 0

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

Чтобы платить налоги (если у вас не вменённый доход), вам нужно как-то посчитать, сколько денег вы всего заработали за период. Маловероятно, что ИП сразу начнёт работать по безналу, а при работе с налом с недавних пор в России требуется кассовый аппарат.

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

Так на вашем ноутбуке появляется простенькая 1С-ка или любой другой аналогичный продукт.

Уровень 1: отрицание

Бизнес идёт отлично, у вас появился помощник, затем ещё один.

Вы открыли вторую точку в другом районе города, и там нужно поставить вторую кассу. Она уже не может быть подключена к вашему ноутбуку.

Вы читаете инструкцию к кассе, настраиваете подключение через мобильный интернет. Либо обращаетесь в компанию, где купили её, там вам с удовольствием помогают. Про какую-либо интеграцию речи пока не идёт.

Уровень 2

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

И ещё один договор, третий, с поставщиком, а то как-то с устными договорённостями о поставках у него не очень: нарушает сроки, есть вопросы по качеству.

С первым клиентом вы смогли договориться на предоплату, а второй убедил вас на постоплату, и вам теперь нужно вести учёт в разрезе клиентов, чтобы точно понимать, кому сколько было взвешено в граммах. К счастью, в вашей 1С есть справочник контрагентов, и вы торжественно занесли в него две первые записи. Ещё своего поставщика, на всякий случай. И ещё одну прочее.

После вчерашней вечеринки у вас разболелась голова. Вы сходили в банк за выпиской по счету и обнаружили там свой первый приход! Конечно, такой повод нельзя было пропустить и не отметить. И тут вы задумались, а что если однажды ваш бизнес вырастет настолько, что платёжки будут приходить каждый день?

Уровень 3: гнев

Несколько раз всё чуть не пропало. Обязательства заставили вас сильно изменить свой бизнес. Проблемы начали возникать, в общем-то, в самых простых вещах. Там, где вы их точно не ждали.

Во-первых, впервые за несколько лет напряжённой работы вы решили сходить в отпуск. Недавно был выполнен неплохой заказ, появились кое-какие свободные деньги, почему бы не отдохнуть?

Обо всём договорились, назначили самого смышлёного из сотрудников своим заместителем, сказали, чтобы звонил, если что-то пойдёт не так и уехали отдыхать на две недели.

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

Затем раздался звонок. Нет, не так. ЗВОНОК. Не так пошло не только лишь всё, вам пришлось в срочном порядке возвращаться домой и восстанавливать всё, что без вас чуть не поломали: отношения с клиентами, процессы, учёт.

С самым смышлёным пришлось расстаться, а для себя вы сделали два вывода:

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

2. Вы понимаете, что нужен инструмент, который позволит вам в любой момент понимать, как сейчас идёт бизнес. Регулярные отчёты. Ну, ладно, не в любой момент, но хотя бы раз в неделю? Нет? Хорошо, раз в месяц.

Во-вторых, в связи с образованием юрлица вам пришлось обратиться к франчайзи 1С, купить версию программы для юрлиц.

Недавно нанятый менеджер привел в компанию толковую бухгалтершу пока на неполный рабочий день, конечно. Она же объяснила, что для работы вам нужно будет заказать у франчайзи 1С разработку пары отчётов, без которых вот совсем никак. Также она взяла на себя расчёт зарплаты и кадровое делопроизводство, только начала вести их не в 1С, а в другой программе, которой их учили в колледже.

Уровень 4

Прошло ещё несколько лет. Были взлёты, были падения, было всякое. В стране отгремел кризис, но вас как-то особо не затронул. В том числе благодаря тому, что вы всегда чётко понимали состояние своего бизнеса, и могли оперативно резать косты там, где это необходимо.

У вас сформировалась репутация надёжного партнёра, число клиентов превысило 20, а в компании трудится уже около 50 человек. Появилось несколько отделов!

Отчётов для работы нужно всё больше, поэтому вы взяли в штат программиста 1С-ника, он же со временем освоил и начал дорабатывать ещё и кадровую систему. И ещё одного парня, айтишника на все руки для поддержки сотрудников, настройки компьютеров, принтеров и прочего оборудования.

Результаты вашей работы, товары, больше не помещаются в вашей спальне, коридоре, гараже и вы решаете арендовать склад.

Начали думать о программе для управления складом и поставками (было пару кейсов увезли товар не тому клиенту), но 1С-ник подсказал, что можно купить модуль склада для 1С. Или вообще ничего не покупать, он сам напишет лучше и именно с учётом ваших потребностей.

Ещё вы несколько раз перепутали скидки, которые обещали разным клиентам, а недавно вообще выставили счёт на несколько миллионов не тому клиенту, из-за чего он сильно напрягся. Все сотрудники как один твердят, что пришла пора внедрять CRM.

Паренёк-айтишник недавно закончил университет и предложил написать свою CRM, которая включала бы в себя и весь ваш производственный цикл. 1С-ник обещал ему помочь. И буквально за пару недель они набросали работающий прототип, им вполне можно было пользоваться!

Оба говорили и вели себя достаточно уверенно, и в этот момент вы серьёзно задумались: развивать ли свою собственную IT-службу, разрабатывать ли собственные решения или обратиться к какому-нибудь интегратору, воспользоваться услугами аутсорсинга?

Порядком подумав, выслушав и прочитав множество мнений, вы решили не выбирать аутсорсинг. Во-первых, он почти всегда дороже, чем сотрудники в штате, т.к. с него кормятся не только исполнители, но и их руководство, и ещё платится множество налогов.
Во-вторых, далеко не всегда гарантируется качество такой работы, даже если исполнители самые титулованные (в неформальной обстановке вы как-то раз спросили у них про процент успешно и вовремя выполненных проектов, ой, зря)
И, в-третьих, и это самое критичное: ни один аутсорсер не будет вам делать работу как для себя. Это противоречит его бизнес-интересам привязать вас к себе всеми возможными способами.

В итоге, вы поверили убедительным голосам своих айтишников и решили, что так будет лучше, иметь свои собственные разработки! Понятно, что позже понадобится взять ещё разработчика и не одного. Понятно, что они будут косячить со сроками, что будут делать не то, что будут отвлекаться. Тут главное, чтобы руководитель был толковый. А нюансы так они у всех нюансы, есть они и в бухгалтерии, и у охраны, и в АХО.

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

Также примерно на этом уровне появляется опасность наступить на одни из самых больших и неоднозначных граблей в истории корпоративной интеграции: позволить системам общаться друг с другом напрямую. См. на примере схемы ниже: CRM ходит за данными в складскую и кадровую системы напрямую.

Уровень 5: торг

С ростом бизнеса был открыт офис в соседнем областном центре, потом в северной столице. Настал очередной критический момент в развитии бизнеса и компании региональное масштабирование.

Много крови (зачеркнуто) кофе было выпито, много сигарет выкурено в поисках лучших сценариев. Вы с удивлением узнали, что для расширения в других офисах часто недостаточно просто умножить расходы на два. Например, чтобы из второго офиса можно было по внутреннему телефону бесшовно звонить в первый, нужно потратить заметно больше, чем просто на первый офис. Нужно создавать инфраструктуру, покупать оборудование и лицензии на ПО. К счастью, третий, четвертый и т.д. уже не требуют таких серьёзных инвестиций.

После нескольких инцидентов с утечкой информации вы решаете нанять специалиста по ИБ. Он, конечно, переворачивает вверх дном почти всю IT-инфраструктуру и завоевывает искреннюю любовь всех айтишников. К счастью, временно, т.к. умеет наглядно обосновывать свои требования, да и, в целом, сам айтишник, одной с ними крови. Первым его требованием было закрыть все ненужные порты и направить информацию по защищённым каналам. Он дал много добрых советов по мониторингу, бэкапам, защищённости, другим полезностям, но самое главное в контексте этой статьи принёс в компанию ещё пару информационных систем, которые нужно было интегрировать с остальными. Всего их у вас получилось уже 7-8.

Недавно был запущен корпоративный портал, интранет, он стал хорошим помощником для сотрудников. Однако, самым большим откровением для вас стало то, что на портале не получилось вывести структуру компании и список сотрудников. Нет, ребята что-то показали, но что это за структура, где они её взяли? Это просто какой-то гибрид ужа и ежа! А список сотрудников? Вы лично увольняли нескольких из них, почему они до сих пор показываются? Они есть в кадровой системе? А в 1С? Откуда эти данные?..

Разработчик 1С *) вышел с предложением купить и внедрить модуль для учёта мастер-данных это когда вся информация по всем общим справочникам (например, по структуре, сотрудникам, контрагентам) собирается и контролируется в одной системе. А также чтобы все обмены информацией шли через эту систему, тогда этот процесс будет наглядным и управляемым. Если будут какие-то ошибки, их сразу заметят а это особенно важно. Пару месяцев назад уже был прецедент, когда информация о зарплате не выгрузилась из кадровой системы в 1С, и зарплату сотрудникам не перечислили вовремя.

Что для этого нужно? Выбрать такую систему. Разработчики советуют решение на платформе 1С это конструктор, который нужно дорабатывать для себя. Будущее этого решения пока не очень понятно, но обоснование его нужности звучит понятно и логично. Берём!

*) повторю, что 1С здесь только для примера. Решения класса MDM (управление мастер-данными) и ESB (интеграционная шина предприятия) доступны почти у всех платформ и вендоров. Это может быть и SAP, IBM, Oracle, и бесплатные решения Fuse, Mule и др.

Уровень 6

Территориальную экспансию компании можно сравнить со взрывом! За пару лет было открыто несколько десятков офисов, штат компании увеличился в несколько раз. Были открыты первые зарубежные офисы в нескольких странах бывшего СССР. Люди там, в общем-то, нашенские, процессы все понятные, законодательство и налогообложение практически не отличаются от России.

Главный вопрос в планировании IT-ландшафта и интеграции на этот момент есть ли возможность каждой информационной системе работать для всех стран одновременно? На практике у каждой системы оказались свои нюансы. Бухгалтерская и кадровая системы их нужно вести строго в разных базах. MDM и ESB пришлось доработать таким образом, что в большинстве справочников появилась страновая привязка. Причём некоторые элементы (например, ФИО, должности, названия контрагентов) пришлось хранить сразу на нескольких языках.

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

На самом деле, вы довольны ситуацией в IT и IT-командой. Заложенные когда-то основы позволили без особых трудностей и стоп-факторов осуществить экспансию. Трудно представить, сколько сил и ресурсов у вас ушло бы сейчас, если бы в компании не было мастер-данных и шины данных. Про CRM вообще молчим!

Уровень 7: депрессия

Казалось бы, всё прекрасно. Обмены работают, данные ходят, бизнес-процессы выполняются. Но.

В последнее время всё чаще слышится с разных сторон, что данные неправильные. Все системы, всю интеграция многократно проверили, протестировали. Нет, никаких технических ошибок и сбоев нет, всё работает как часы.

Однажды корпоративный портал поздравил вас с годовщиной работы в компании. Всё бы хорошо, но стаж показался на несколько лет меньше, чем вы на самом деле работаете и дата не та. Вы задумались, вспомнили свой выпуск из университета, первые годы работы

Что-то пошло не так. Разработчики пошли разбираться, подняли историю. Оказалось, что при каком-то перезаключении трудового договора кадровик опечатался, ввёл неправильную дату. Понятно, обычный человеческий фактор, ничего страшного.

На следующий день вы заключили важный контракт. Предоплата? Нет, несколько дней деньги на счёт не поступают. Точно перечислили? Точно перечислили! А что не так? Звонок в банк, те говорят: ошибка! Оказалось, что в системе MDM устарели данные о реквизитах: они поменялись. А сотрудник, который должен был их исправить, заболел.

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

У вас даже возникли мысли, а не заменить ли используемые продукты. Вот, на одной презентации рассказывали, что продукты SAP (Oracle, IBM) не глючат! Разработчики возражают: нет, дело не в продуктах, дело в процессах. Провели внешний аудит, он подтвердил: технически системы работают корректно.

При больших объёмах информации обнаружилась проблема, на которую раньше никто не обращал внимания ввиду её незначительности качество мастер-данных. Данные устаревают, данные теряют актуальность, люди, которые вносят эти данные, постоянно ошибаются. И ничьей вины в этом нет: на объёмах в сотни тысяч записей ошибки появятся неминуемо.

Дополнительным фактором, повышающим вероятность ошибок, было то, что когда-то вы выбрали гармонизованный сценарий ввода данных. Это означает, что данные могут вноситься в любую систему, а потом собираются в MDM. Например, нового контрагента можно добавить в CRM, через корпоративный портал, в 1С любым способом, удобным для конкретного сотрудника в конкретный момент времени.

Проблема с качеством данных? Хорошо, у разработчиков, наверное, есть множество инструментов для контроля качества данных, для автоматизации процесса. Сколько-сколько? И что, только руками писать проверки?

К сожалению, простого решения у этой проблемы не нашлось. Её можно было бы проигнорировать на какое-то время, но в динамике стало понятно, что через пару уровней развития компании эта проблема вас просто похоронит. И никто конкретного не будет в этом виноват. Но как же тяжело внедрять сложные решения!

Уровень 8

Есть решение проблемы качества данных!

Да, для этого потребовалось качественно изменить подход к работе с данными во всём их многообразии. Проект по изменениям кем-то почти в шутку был назван качество для качества.

Появилось понятие ответственного за данные (очевидно, что им не может быть IT-департамент), за каждую конкретную запись в каждом справочнике. Были проанализированы все процессы и разработан механизм классификации ошибок, механизм создания проверок данных. Ведь по мере накопления данных появляются всё новые и новые виды ошибок, а, значит, процесс заведения правил и проверок должен быть встроен, по сути, в сам процесс ввода данных.

Шли долгие дискуссии на тему того, должна ли функция контроля качества данных быть централизованной или децентрализованной. Финансовый департамент считал, что качество данных по договорам и счетам их зона ответственности. Административно-хозяйственный считал своими данные по имуществу, и так далее. Быстро выяснилось, что с точки зрения разных мест в компании есть разные критерии по качеству данных.

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

Изменение процессов в компании вскрыло интересный факт: людям, которые вводят данные, как правило, не интересно, что их ошибки потом повлияют на других. И сложно замотивировать таких сотрудников следить за качеством и исправлять ошибки просто потому что. Но также выяснилось, что если им обрисовать последствия (вот здесь неактуальный реквизит, из-за него сотрудник Х не получит завтра зарплату; там ошибка, из-за которой деньги уйдут не туда), это повышает их заинтересованность в процессе.

Была разработана система контроля качества данных DQS, как модуль MDM. Она запускала проверки (по расписанию и при добавлении каждой записи) и сообщала об ошибке персонально тому, кто эту ошибку допустил. С описанием возможных последствий.

Правил в системе было сначала 100, потом 500, через год уже около тысячи! Департамент HR здорово помог с тренингами, подсказал варианты мотивации сотрудников, сделали инфографику и мультяшный индикатор количества ошибок, отмечая их уменьшение. Началось даже соревнование, кто найдёт больше ошибок и добавит больше правил!

Следующий уровень развития системы DQS интеллектуальные правила, нечёткие правила, агрегирующие правила (например, итоговое значение в двух отчётах, описывающих одну и ту же сущность с разных сторон, должно совпасть). Высший уровень DQS контроль качества мастер-данных и даже их системное наполнение на основании государственных открытых данных. Пример сервисы по контрагентам на сайте налоговых, они позволяют контролировать правильность реквизитов в вашей MDM.

Уровень 9: принятие

За качество данных, за правильность формируемых на их основе отчётов можно быть спокойным. Исправление ошибок внедрено в генетический код вашей компании и происходит само собой.

Чёткое понимание текущего состояния процессов, работа с отчётами в динамике, контроль качества производства, работа с клиентами позволили вам выйти на первое место на рынке. Название вашей компании стало фактически синонимом отрасли.

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

Оставим за скобками административную часть и бизнес-процессы. Если говорить про интеграцию, технически сама задача не очень сложная. Проводится обучение новых сотрудников, затем фиксируется некоторая точка во времени, час Икс. После часа Икс все вновь запускаемые процессы, новые контрагенты, новые договоры должны вестись строго в ваших основных системах. Рост на 10-20%, даже на 50% эти системы выдержат без особых проблем. Все современные системы класса MDM, ESB, CRM и др. позволяют масштабировать себя, просто докупая новое серверное оборудование.

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

Уровень 10

Выгрузив в очередной раз отчётность из BI-системы, вы загляделись на цифры и задумались. Численность сотрудников в вашей компании скоро будет шестизначной, это население целого города. Годовой оборот близок к 0.1% ВВП России и превысил ВВП республик Алтай и Тува. На территории бывш. СССР рынок весь ваш! И, честно говоря, он занят полностью. На нём расти больше некуда.

Недавно свершилось событие, о котором вы мечтали много лет! Вы поглотили небольшую компанию, работающую на рынке Евросоюза и поставили несколько новых флажков на карте.

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

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

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

И самое главное: данные должны храниться на серверах на территории Евросоюза. В дальнейшем эти или похожие требования будет появляться во всё новых и новых странах, а за их нарушение предусматриваются просто огромные штрафы. В случае Евросоюза это до 20 млн евро или до 4% от мирового оборота компании.

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

Местная компания, региональная, федеральная, что дальше? Глобальная?

Весь мир ждёт вас!

Итоги

Хочу поделиться несколькими выводами из рассказа выше. Не все выводы однозначные и предположу, что они могут вызвать возражения. Основное:

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

2. Важны не только сами мастер-данные, но и их качество. По мере роста вопрос качества данных выходит на первое место.

3. В то же время, каждый следующий уровень развития MDM, ESB, DQS дорог и влечёт за собой дополнительные расходы. Есть чёткая шкала, ориентируясь на которую, можно формировать текущую инфраструктуру. Создавать её с запасом больше, чем на 1-2 уровня не нужно.

4. Ответственность за качество данных должна нести не IT-служба, а сам бизнес. Задача IT предоставить удобные инструменты для реализации этой ответственности.

5. Функция управления качеством данных должна быть централизована. Процесс контроля качества распределён между всеми участниками работы с данными, начиная с их первичного ввода.

Приглашаю к дискуссии!

Самой дорогой ошибкой в истории, вызванной неправильными исходными данными, считается авария ракеты Ариан-5. Суммарный урон по итогу этого случая оценивают в 0.5 миллиардов долларов в ценах начала 1996 года.

Ещё одной, возможно, самой курьёзной, стала ошибка в огромном заказе от французских железных дорог SNCF на 2 тыс. поездов в 2014 году. Команда, которая формировала технические требования, собственноручно провела замеры габаритов перронов на нескольких десятках станций. Желая увеличить комфорт, они задали ширину составов впритык к максимальной. Измерения они проводили в окрестностях Парижа и о том, что в регионах на многих станциях перроны находятся ближе к путям, узнали уже при испытаниях. Цена ошибки модернизация всей инфраструктуры на сотни миллионов евро. Им бы там MDM с характеристиками станций



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

Эта статья продолжает статью "мастер-данные и интеграция" и более подробно освещает вопрос контроля качества данных, в первую очередь мастер-данных. Статья будет особенно интересна руководителям IT, архитекторам, интеграторам, а также всем, кто работает в достаточно крупных компаниях.

Содержание:

1. Словарь, виды бизнес-данных: мастер-данные, нормативно-справочная информация, операционные данные.
2. Коротенько о том, какие бывают ошибки.
3. Архитектура решений DQS.
4. Технические и нетехнические приёмы борьбы с ошибками:
4.1. НСИ.
4.2. Мастер-данные.
4.3. Операционка.
5. Что делать, когда ничего из перечисленного не помогло внедрять DQS.
6. И как делить ответственность?

Если терминология и проблематика вам уже знакомы, переходите сразу к части 3, про архитектуру DQS.

1. Словарь, виды бизнес-данных.

Уже пару десятков лет IT-евангелисты убеждают нас, что данные новая нефть. Что любой бизнес всё больше зависит от обладаемой информации. Аналитические и дата-отделы появляются не только в IT-компаниях, но и в максимально далёких от цифры индустриальных и промышленных отраслях.

Многим уже набил оскомину пример того, как компании General Electric и Boeing создают цифровых дочек и зарабатывают на огромном объёме информации, собираемой от владельцев их техники самолётов, турбин, электростанций. Эти данные позволяют им повышать надёжность техники, предсказывать возможные отказы, сильно экономя на потенциальном ущербе, наконец, просто спасать жизни людей!

Данных становится всё больше, и накопление их нелинейно зависит от роста бизнеса, рост опережающий. Любая растущая компания на определенном этапе своего развития (примерно на 6-7 уровне по шкале из прошлой статьи) сталкивается с проблемами некорректных данных, и обязательно происходит несколько случаев, когда цена этих ошибок оказывается достаточно высокой.


традиционная картинка про рост объёма данных почти всегда экспонента

По ходу деятельности особую важность для компании представляют собой три вида данных:

мастер-данные это информация, которая должна быть единой и синхронизированной во всех местах организации, во всех информационных системах. Это список клиентов компании, перечень товаров и услуг (со всеми дополнительными реквизитами: цена, категория, условия), организационная структура компании, персонал, имущество и т.д.;

нормативно-справочная информация (НСИ) это понятие близко к мастер-данным, и во многих компаниях объединяется с ними. Разница в том, что эти данные существуют независимо от вашей компании: список (классификатор) стран мира, адресный классификатор, реестры банков, курсы валют;

операционные (они же транзакционные) данные факт продажи конкретного товара конкретному клиенту, счета и акты, пройденные курсы, заказы курьеров и поездки на такси в зависимости от того, чем занимается ваша компания.

Если НСИ можно сравнить с несущим скелетом, мастер-данные с венами и артериями, то операционка это кровь, которая бежит по этим венам.

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

2. Коротенько о том, какие бывают ошибки.

Ошибки неизбежны, они возникают всегда и везде, и, видимо, отражают хаотическую природу самого мироздания. Можно считать их чем-то плохим, расстраиваться из-за них, но, задумайтесь: ошибки лежат в основе эволюции! Да, каждый следующий вид это предыдущий с несколькими случайными ошибками в ДНК, только последствия этих ошибок при определенных условиях оказались полезными.

Основные виды ошибок, от которых страдает бизнес:

человеческий фактор. Опечатки всех видов, перепутанные поля и не туда внесённая информация. Забытые или случайно пропущенные действия и шаги при её внесении (у вас ведь тоже в карточке клиента по 50 полей?) Статически это самый вероятный вид ошибок, поэтому частота и эффект от них может оказаться самым большим. К счастью, для борьбы с ними придумано и самое большое количество методов;

неполнота информации. Говорят, что полуправда хуже неправды, и в бизнесе это часто бывает критичным. Например, вы заключили крупный контракт с организацией и через некоторое время узнали, что в отношении руководства компании ведётся судопроизводство. Ваш контрагент может уклоняться от налогов или, чего хуже, заниматься противозаконной деятельностью. Через некоторое время с вами свяжутся конечно, ваш бизнес полностью легален, но кого обрадуют лишние проверки? А как хорошо было бы, если бы тогда, при нанесении контрагента в базу, ваша учётная система или CRM предупредила бы: внимание! Контрагент не прошёл проверку на благонадёжность!

сознательные ошибки. Сотрудник умышленно перевёл себе несколько миллионов и пропал. Это, конечно, экстремальный пример, криминал, но по дороге к нему есть немало шагов. Например, одному из клиентов в CRM назначена незаслуженно высокая скидка или стоимость товара установлена ниже себестоимости.

И если третье это предмет работы службы информационной безопасности, там есть свои методы, то с человеческим фактором и неполнотой мы поработаем предметно.

3. Архитектура решений DQS.

DQM data quality management, управление качеством данных.
DQS data quality system, система [управления] качеством данных.

Перед тем, как рассказать непосредственно о системах управления качеством данных (DQS это не столько конкретное программное обеспечение, сколько подход к работе с данными), опишу IT-архитектуру.

Обычно, к тому моменту, когда возникает вопрос управления качеством данных, IT-ландшафт представляет собой следующее:


(схема из предыдущей статьи)

Где MDM система для ведения мастер-данных и нормативки, а ESB единая шина данных предприятия. Часта ситуация, когда не все данные и потоки информации между системами пока ещё вовлечены в общий контур, и некоторые системы общаются напрямую друг с другом с этим нужно будет поработать, иначе ряд процессов будет слепой зоной для DQS.

Традиционно на первом этапе DQS подключается к системе MDM, поскольку управление качеством мастер-данных считается более приоритетным, чем операционки. Однако, в дальнейшем она включается в общую шину данных как один из этапов процессов, либо представляет свои услуги в формате API. В конкретных цифрах между первой и второй схемой примерно десятикратная разница в объёме данных или один уровень по шкале из прошлой статьи.

4. Технические и нетехнические приёмы борьбы с ошибками.

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

Однако, есть и хорошая новость: набор технических и организационных методов, описанных в этой статье ниже, позволит значительно сократить количество ошибок. Компании, внедряющие подход DQM, сокращают количество выявленных ошибок в 50-500 раз. Конкретная цифра это результат разумного баланса между эффектом, затратами и удобством работы.

4.1. Нормативно-справочная информация.

В случае нормативно-справочной информации (по сути, государственных классификаторов) есть максимально категоричное решение, и оно универсальное: вы не должны вести нормативку самостоятельно! Никогда, не при каких обстоятельствах!

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

Пример #1. Наверняка вам для работы понадобится список стран мира. На него будут ссылаться многие другие справочники: контрагенты и клиенты (страна регистрации), валюты (курс какой страны), ваша география (в какой стране и по какому адресу расположен офис).

Значит, любая сущность, которая содержит в себе страну мира (даже если вы в ней выбираете из двух-трёх стран) должна ссылаться на этот справочник. А сам справочник должен заполняться строго на основании официальных классификаторов, в случае РФ это ОКСМ (общероссийский классификатор стран мира).

Если вы работаете на международном рынке, обратите внимание на нюанс: в разных странах разное представление о странах мира и их количестве. И речь не только про такие частично-признанные республики, как Абхазия или Южная Осетия. Например, около двадцати стран не признают существование Израиля и Китайской Народной Республики. Есть и точечные непризнания на территории СНГ, например, Армения не признаётся Пакистаном.

Страны мира (в РФ это и ниже ОКСМ), валюты (ОКВ), виды экономической деятельности (ОКВЭД), адреса (ФИАС), банки и их счета, клиенты и поставщики (ЕГРЮЛ и ЕГРИП) эта и множество другой информации публикуется государственными органами практически всех стран в виде открытых API и сервисов, и она должна загружаться только таким образом.

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



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

4.2. Мастер-данные.

Главная стратегия в отношении мастер-данных прозвучит, возможно, парадоксально: превращайте их в нормативку!

Пример #2. Справочник контрагентов юридических лиц и ИП, являющихся вашими клиентами или поставщиками (в компаниях уровня выше 5-6 часто одновременно и тем, и тем).

Какой бы набор полей вы не решили добавить в справочник контрагентов в систему MDM, ваша цель такова: все данные должны заполняться автоматически, с поиском по одному из естественных полей. В случае контрагентов РФ это наименование или ИНН.

Это не значит, что вы должны занести в свой справочник контрагентов все несколько миллионов записей из открытых данных. Но новые записи должны добавляться как раз на их основании. Базовые реквизиты можно взять с сайта налоговой. Если вас интересуют данные бухгалтерской отчётности или среднесписочной численности (например, в целях аналитики, развивать отношения с наиболее крупными клиентами) берите их у Росстата (ссылка). Если у вас есть процедура проверки на благонадёжность берите данные с сайтов соотв. служб с помощью своей ИТ-команды, либо есть вариант покупать уже подготовленные и выверенные данные у провайдеров (например, СПАРК-Интерфакс). Цена вопроса, сотни тысяч рублей в год, при ваших масштабах окупается за несколько месяцев.

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

Пример #3. Физические лица, сотрудники вашей компании. Ошибки в паспортных данных, неправильные ФИО и дата рождения, СНИЛС. Сокрытая информация о судимости, просроченной задолженности перед госорганами, алиментах.

Список сотрудников почти всегда является мастер-данными в крупных компаниях. Как их сделать нормативкой? Самый простой способ наладить интеграцию с порталом Госуслуг. Возможен также вариант авторизации на ваших сервисах через портал Госуслуг. Ключевое слово для поиска: ЕСИА. Нужно будет обзавестись рядом сертификатов, но при ваших масштабах и уровне развития это не составит проблем.

Естественным продолжением этой истории будет электронный кадровый документооборот электронная трудовая книжка, электронные больничные и др., что значительно сэкономит трудозатраты у кадровиков. В пределе это позволит одному кадровику обслуживать не 200-300 сотрудников, а 1000+.

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

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

4.3. Операционка.

Здесь подходов уже больше. Первый аналогичен предыдущему подключать внешние источники информации.

Пример #4. Хорошо, скажете вы, контрагенты и физлица это просто. Но что делать с более бизнес-специфичными процессами и данными? Искать государственные классификаторы и другие гарантированные источники этой информации.

Попробуем разобрать точечный пример. У вас есть парк автомобилей. Не обязательно, что вы служба такси, в любой достаточно крупной компании будет техника для служебных нужд. Вам нужно наладить учёт этих автомобилей, заправок и поездок, т.е. учёт расходов.

Создаём справочник автомобилей это мастер-данные. Модель автомобиля, его нормы расхода топлива и характеристики выбираем из гос. классификатора моделей (не забывайте настроить регулярную интеграцию, чтобы данные не устаревали!)
Информацию о конкретном автомобиле заполняем строго по госномеру на основании подключаемого справочника (например, Автокод).

Откуда получить информацию, что конкретный водитель заправился на такую-то сумму в такой-то день? Оформить топливные карты (они стоят денег, но быстро окупят себя за счёт накопительной скидки) и забирать данные у провайдера топливных карт в автоматическом режиме. Конечно, сам список топливных карт в этом случае станет мастер-данными, но вестись он будет автоматически, на основании данных провайдера.

Пример #5. Командировки сотрудников: билеты, гостиницы и прочие расходы.

Для билетов и гостиниц пользоваться агрегаторами, все они позволяют, во-первых, значительно экономить на организации поездок (цены на билеты, гостиницы). Во-вторых, дают API со всей возможной информацией, вплоть до ЭДО. По всем прочим расходам пользоваться электронными чеками, они уже принимаются везде. Т.е. человеческий фактор будет если не исключён, то сведён к минимуму.

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

Информация (данные) новая нефть, и все государства стремятся к тому, чтобы получить максимально возможный объем информации о своих субъектах, включая бизнес, обо всех процессах, в которых они участвуют.

Нам даже тяжело представить, какую информацию государство собирает, могу сказать только, что на момент написания этой статьи на портале открытых данных России представлено около 20 тысяч наборов данных. И Россия только в начале этого пути, так, на аналогичном портале Евросоюза доступно больше миллиона наборов открытых данных!


www.europeandataportal.eu/en

Где же здесь DQS, спросит внимательный читатель?

А про неё ещё ничего и не было :)
Всё вышеперечисленное это, по сути, стандартные инструменты и методы для организации бизнес-процессов с минимальным количеством ошибок.

5. Что делать, когда ничего из перечисленного не помогло внедрять DQS.

Сунь-цзы учит, что лучшая битва та, которую удалось избежать.

Ситуация с внедрением DQS чем-то похожа.

Ваша задача постараться по максимуму превращать мастер-данные и даже операционку в НСИ, и в некоторых отраслях, особенно в сфере услуг, это возможно почти на 100%. Больше всего в банковской сфере, поэтому в ней степень автоматизации бизнес-процессов куда больше, чем у многих других.

Тем не менее, если битву избежать не получается, к ней нужно максимально правильно подготовиться.

На каком уровне развития компании нужно вводить DQS? Как процесс DQM на 4-5 (раньше MDM-системы!), как организационно выделенную функцию на 7-8.

5.1. DQM как процесс.

Если у вас в компании есть бухгалтерская или кадровая система, то и процесс DQM в каком-то виде у вас будет. Во все эти системы встроен определённый набор правил для вводимых данных. Например, обязательность и строгий формат даты рождения для сотрудника, обязательность наименования для контрагентов.

Ваша задача на данном этапе будет заключаться в выстраивании процесса DQM. Он следующий:

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

Если вы сумели внедрить в компании MDM, значит, пункты со второго и далее не должны вызвать у вас особых затруднений, это текущая планомерная работа.

Наибольшие затруднения в таком случае возникают с придумыванием новых правил.

5.2. Правила.

Если для такой сущности, как ФИО, ваша фантазия ограничивается обязательностью фамилии и имени, а для даты проверкой на не больше ста лет, не расстраивайтесь!

Существует шикарная методика разработки новых правил для проверки самых невообразимых данных. Для её освоения не нужно быть семи пядей во лбу и, как показывает практика, её в состоянии освоить любой начинающий системный или бизнес-аналитик, даже операторы по вводу мастер-данных.

По сути, это пошаговый скрипт, у которого на входе определение ваших данных, а на выходе набор правил на все случаи жизни. Методика, известная под названием таксономия грязных данных, была разработана группой европейских data-scientistов в начале XXI века.

Суть подхода, а также практические примеры приведены в их системной статье, к счастью, уже опубликованной в переводе здесь, на Хабре habr.com/ru/post/548164

Если проблема качества данных для вас не пустой звук, то после вдумчивого прочтения той статьи вы обнаружите себя в состоянии, близком к достижению нирваны :)

Пример #6. Строгая типизация. Если в справочнике используется тип данных дата, то структура даты должна быть максимально явной. Если вы решили сэкономить две секунды для операторов, и сделали шаблон вида __.__.__ с подсказкой день, месяц, год, будьте уверены, что в первый же день появятся записи 18.04.21, 21.04.18 и 04.18.21.

Хорошим способом ввода даты являются три поля с явным обозначением (день, месяц, год) и быстрым переходом при вводе двух цифр в каждом из полей. Если вы хоть раз платили за что-нибудь картой в интернете, поймёте.

Пример #7. Запрещённые символы в максимально широком списке полей, словарные проверки. Например, если речь идёт про образование (должность), и классификаторы специальностей не помогли, вы позволяете пользователю ввести данные в текстовом поле, пусть там будут запрещены точки, кавычки, отдельно стоящие чёрточки (список не полный). Пример информации, качество которой повышается: доктор технических наук, д.т.н., ДТН, д-р техн. наук и т.д.

Пример #8. Пустое и неуказанное значение (NULL) это два разных значения. Например, неуказанное высшее образование/отсутствие высшего образования, неуказанное отчество/отсутствие отчества разница велика, и она должна быть зафиксирована в явном виде. Хороший пример реализации сайты по продаже билетов справа от отчества размещают галочку нет отчества.

Кстати, про ФИО, и особенно про отчество. Если вы предполагаете работу с физическими лицами из стран Средней Азии или Ближнего Востока, кейсы с ибн, бен, кызы, оглы (и др.) могут стать критичными в вопросах качества данных, например, при поиске дубликатов. Аналогичная история с порядком употребления этих данных (Джон Смит, Смит, Джон) и с двойными именами (Анна Мария, Анна-Мария, Джон Чарьлз Смит). Также для многих не иметь фамилию это нормально. А ещё, с точки зрения одних, Наталья и Наталия разные имена, а с точки зрения других одинаковые. А ещё есть сэр, доктор

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

6. Кто несёт ответственность за DQS?

В вопросах управления и ответственности правильных ответов не бывает, скорее всё зависит от конкретных команд и личностей. Инженер-ракетчик может быть главным бухгалтером, художник финансовым директоров, а учительница начальных классов руководителем службы охраны.

Вопрос про ответственность за процесс DQM, на самом деле, даже более общий: кто несёт ответственность за качество данных в компании? Традиционно бизнес-пользователи и IT-департамент в ответе на этот вопрос выступают антагонистами.

Бизнес часто начинает диалог с утверждения мы заметили ошибку в вашей системе местер-данных.
Служба IT, напротив, считает, что её задача обеспечить бесперебойную работу систем, а какие конкретно данные бизнес-пользователи вводят в систему это зона ответственности бизнеса.

Выстраивание работающего процесса DQM и запуск DQS является тем самым компромиссом, удовлетворяющим обе стороны. Задача IT и аналитиков заключается в разработке максимально возможного количества правил и ограничений для вводимых данных, чтобы свести риск возникновения ошибки к минимуму.

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

Восхитительнейший пример и мотивацией и даже визуализацией последствий ошибок приведён в статье habr.com/ru/post/347838 в этом примере ответственным за процесс DQM выступает служба IT с развитыми компетенциями бизнес-анализа. Причём сами по себе компетенции в DQM не сложны, и могут быть развиты у любого аналитика за пару месяцев.

Ещё один пример, интересный тем, что в процесс DQM включено также управление качеством бизнес-процессов, приведён в статье habr.com/ru/company/otus/blog/526174.

Итоги

Общие выводы из этой статьи парадоксальны.

Если в вашей компании был задан вопрос кто несёт ответственность за качество данных, то вы попали в ловушку. На него нет правильного ответа, т.к. сам вопрос неправильный. Если вы попробуете сходить по этому пути, со временем поймёте, что единственный подходящий ответ на этот вопрос (все) ничего не даст вам на практике.

Правильный подход разделение вопроса на два блока.

Первый выстраивание DQM как процесса, внедрение DQS, формирование правил (не на разовой основе, а как постоянно идущий процесс). Этот блок живёт там, где сильны функции анализа, обычно, в IT, но необязательно.

Второй блок сам ввод первичных данных это место, где принимаются решения о конкретных данных, но не наобум, а на основании всех правил. Таким образом, внедрение DQS важный шаг в сторону data driven company.

Приглашаю к дискуссии!

Наверняка в вашей компании уже не раз появлялись ребята в дорогих костюмах и с хорошо подвешенным языком, увлекательно рассказывающие, что без современных айти-штучек компания не проживет и несколько лет!

Все эти data lake (болото данных), КХД (корпоративное кладбище данных), data mining (смотри, не подорвись), data governance (стань рабом своих данных) и им подобные не исчезают из их рассказов, периодически сменяя друг друга. Срок жизни очередного хайпа редко превышает год-два, но при желании для вас с большим удовольствием откопают любую почти забытую технологию.

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

В этой статье я постараюсь рассказать о старых-добрых технологиях, которые всё ещё работают. О том, что можно извлечь из перечисленных выше хайповых технологий и как всем этим пользоваться простым смертным, типа нас, не нанимая толпу дата-сайентологов с зарплатами >10 тысяч $ в месяц.




Статья продолжает цикл:
Создаём компанию мечты: мастер-данные и интеграция
Создаём компанию мечты: управление качеством данных

Содержание

1. Big data: постановка проблемы
2. Мастер-данные: бессмертная классика
3. Как хранить данные: нужны ли КХД
4. Нормализация, или зачем вам болота данных
5. Почему дата-сайентист получает больше аналитика, а делает меньше?
6. Шина данных vs микросервисы
7. Как вообще не попасть на хайп?

1. Big data: постановка проблемы

Роль big data в развитии современной цивилизации впечатляющая. Но не по той причине, которая вам кажется.

Если интернет в каждой деревне и каждом телефоне появился благодаря порно и соцсетям (мессенджерам), то big data подарила триллионы долларов производителям жёстких дисков и оперативной памяти.

Проблема в том, что реальная польза от современной big data (в широком смысле слова) для всего человечества близка к пользе от порнографии, т.е. за несколькими исключениями нулевая!

Как же так, удивитесь вы. Ведь любой консультант и продажник рассказывает целую дюжину примеров, начиная с General Electric с их диагностикой состояния авиадвигателей, заканчивая таргетированной рекламой от Гугла!

Проблема, если быть точнее, в повторяемости результатов. Скажу по секрету, что скамейка запасных у продажников big data короткая. Если вы попросите их привести ещё несколько примеров, список закончится на втором десятке. Уверен, что мессенджеров и порносайтов они смогут назвать куда больше :) потому что их просто физически больше.

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

А General Electric сформировала своё конкурентное преимущество основываясь на методах математического анализа и статистики, которые можно найти в любом курсе математики для университета. Понятия big data тогда ещё не было.

Но на матанализе хайп не сделаешь, и слушать про двухсотлетние методы Фурье и Коши большие менеджеры вряд ли будут. Ведь там всё скучно, занудно, нужно много думать, и точно нет серебряной пули и волшебной таблетки.

Что же делать? Работать! Долго, скучно и уныло, стараясь создать такую атмосферу, которая поощряла бы активное думание. Как в канонических примерах от Bell Labs или той же GE. Это вполне возможно, более того, на это способны самые обычные люди, как вы и я, если их нужным образом замотивировать.

А начать нужно с

2. Мастер-данные: бессмертная классика

Мастер-данные это такой подход в структурировании информации, которая есть в компании. Если вы в какой-то момент обнаруживаете, что та или иная сущность используется одновременно в двух или большем количестве систем в вашей компании (например, список сотрудников на внутреннем сайте, в базе 1С-Бухгалтерии или CRM-системе), нужно выносить его в отдельную систему мастер-данных (MDM) и заставлять все системы пользоваться только этим справочником. По ходу понадобиться всем участникам договориться о нужных полях и атрибутах, а также придумать множество правил для контроля качества этих данных.

В среде дата-сайентистов младше 30 лет встречается убеждение, что окно для внедрения систем MDM началось примерно в 2008 и закончилось в районе 2012-15 годов. Что после этого появилось так много новых инструментов (всякие hadoop и spark), что заморачиваться с мастер-данными уже не нужно, не нужно ходить и договариваться с владельцами всех систем, думать о последствиях выбора архитектуры MDM и каждого конкретного реквизита в каждом справочнике.

К сожалению для них и к счастью для вас, это окно не закрылось. MDM-системы всё так же актуальны, как и системы бухучета или взаимодействия с клиентами. И думать и договариваться всё ещё нужно.

3. Как хранить данные: нужны ли КХД

Нет, корпоративные кладбища данных вам не нужны.

Идея, что для целей аналитики нужно иметь специальным образом подготовленные наборы всех данных (идеологи КХД не только выделяют это слово жирным, но и подчёркивают его двойной чертой) в вашей компании, абсурда. Коэффициент реального использования этих данных минимальный, 99% из них не используются никогда.

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

4. Нормализация, или зачем вам болота данных

Это раздел про data lake, или болото данных. Легенды гласят, что можно сваливать все данные без разбору в одну большую кучу. Не нужно приводить все данные к одному формату, не нужно нормализовать и вычищать их!

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

На практике самый ценный вывод, который вы сможете сделать из data lake что ваша компания почти не работает на январских каникулах.

И главный вопрос как какие-то жулики сумели убедить хоть кого-то в работоспособности этого подхода. Я склоняюсь к гипнозу :)

5. Почему дата-сайентист получает больше аналитика, а делает меньше?

Маркетинг, грамотная самопрезентация, максимум уверенности в себе. Не исключаю также гипноз :)

6. Шина данных vs микросервисы

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

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

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

Как показывает практика, любые две системы прекрасно интегрируются через микросервисы. Любые три хорошо. Любые пять терпимо, если очень тщательно всё задокументировать и обвешать автотестами.

Уже на десяти системах прекрасно выглядевшая на старте архитектура, подход превращается в некий такой клубок, паутину, когда определённые потоки отваливаются и не работают месяцами.



На нескольких десятках систем (цифра только кажется внушительной, в любом энтерпрайзе используется куда больше информационных систем) подход хоронит сам себя. И спустя несколько лет возникает какая-то централизация и шина. Делают её, как правило, уже другие люди.

7. Как вообще не попасть на хайп?

Вы познакомились с несколькими примерами хайпа, когда какой-то подход или технология могут оказаться бесполезными. И это с учётом того, что, по мировой статистике, доля успешно выполненных проектов по разработке и внедрению в IT редко превышает 40%.

Послевкусие от проваленных или бесполезных проектов может оказаться таким, что компания на время вообще откажется от IT-инициатив до тех пор, пока очередной влиятельный менеджер не оседлает очередной хайп.

Чтобы не попасть на хайп, перед очередным внедрением нужно выяснить следующее:

у технологии есть большая скамейка запасных. Количество приводимых примеров успешного применения должно превышать пару десятков, и от них не должно возникать ощущения, что тут происходит какая-то магия;
технология должна проходить тест на бабушку (объяснение сути должны быть настолько понятным, что его осилит даже ваша бабушка повторю, никакой магии);
у технологии должен быть конкретный, оцифрованный список ачивок, которые в результате получит ваша компания. Внедренцы MDM, CRM или той же 1С-бухгалтерии могут часами рассказывать о пользе их решения на примере ваших конкретных задач. Внедренцы Big data вообще начинают рассказывать, что сначала соберём кучу данных, а потом посмотрим, что с ней делать;
и, наконец, технология должна быть фальсифицируемой (в смысле критерия Поппера), т.е. внедренец должен чётко понимать область её применения и актуальности и суметь привести доводы против (!) внедрения. Не нужно забивать гвозди микроскопом, и вообще, например, если у вас мало клиентов, нужна ли вам супер-пупер CRM?

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

Можете предложить ещё какие-нибудь критерии?
Приглашаю к обсуждению!