Есть легенда, что когда Билл Гейтс с коллегами продумывали архитектуру будущей Windows 3.1, они рисовали её от руки на склеенных ватманах. Маленькие квадратики обозначали блоки и модули системы, а стрелочки между ними — потоки данных из одной системы в другую (каждая система общалась с каждой напрямую). Эта схема поместилась целиком на полу в кабинете у самого Гейтса, правда, пришлось вынести в коридор стол и стулья.
Год спустя, при проектировании новой операционки Windows 95, ребята “вынесли” целую столовую. Но через пару месяцев работы стало понятно, что и в ней места уже не хватит. И если позволить приложениям и дальше общаться с операционной системой и друг с другом по-старому, получится истинный ад бесконечных взаимосвязей и зависимостей. Нужен был принципиально другой подход…
А что, если сделать единый механизм, через который все будут друг с другом общаться? Эврика!
В результате родился шедевр инженерной мысли — Win32 API. Это набор функций для связи компонентов и приложений Windows друг с другом, один из факторов, обеспечивших небывалую популярность для Windows 95 и последующих версий ОС Windows.
Среди менеджеров проектов и ответственных за интеграцию передача данных между разными системами вызывает ощущения, порой близкие к панике. С точки зрения управления процессом интеграция «радует» огромным количеством мелочей и узких мест, в которых что-то может пойти не так.
Особенно остро ситуация проявляется в крупных компаниях, где в интеграционном контуре может оказаться 10-20 разных информационных систем, и необходимо обеспечить непрерывность бизнес-процессов при передаче данных во всех направлениях.
Планирование и управление архитектурой такого комплекса приложений — задача нетривиальная, и, к сожалению, не может быть решена в духе «пусть все пользуются реббитом», «установим WSO2» или «а давайте всё заменим на микросервисы». Нет, примеры были и будут, но дело, в лучшем случае, заканчивается двумя или несколькими «ядрами» интеграции, в худшем — нарушением непрерывности бизнес-процессов с неприятными последствиями для участников.
В этой статье я хочу описать основные этапы процесса, как он обычно стихийно складывается в крупных компаниях. Ввести шкалу интеграционного развития компании от 1 до 10. Эта шкала, конечно, будет отражать и сам рост компании, рост уровня развития административных технологий в компании. А также хочу наметить основные векторы развития: куда бежать, что делать и кто во всём этом виноват. Шутка.
Для живости взял пример абстрактной производственной компании. С ней будет проще показывать, что повышение сложности в IT — не самоцель, а ответ на всё новые вызовы, появляющиеся перед растущей компанией. Если у вас компания не производственная, а например, сфера услуг — разница невелика. Некоторые шаги могут быть сдвинуты на уровень-другой вверх или вниз при сохранении общего сценария.
Также в статье почти нет названий конкретных продуктов или технологий, т.к. в области интеграции «нет дорог, есть направления». Нет конкретного продукта, который просто поставил — и пользуешься. Речь всегда будет идти о разработке, как минимум, коннекторов. Упоминаются 1С, Windows, Office как широко распространённое ПО, но вместо них без потери смысла можно подставить SAP, Linux и т.д.
Конечно, примеры упрощены в целях наглядности. Несколько вопросов останутся открытыми. И сам подход, как это всегда бывает в IT, не является единственно верным, поэтому приглашаю всех к дискуссии.
Эта статья будет особенно интересна руководителям IT, архитекторам, интеграторам, а также всем, кто работает в достаточно крупных компаниях.
Поздравляю вас, вы недавно выпустились из университета — и решили заняться бизнесом. Вы только что зарегистрировали ИП.
В ближайшем будущем вас ждёт знакомство с удивительным миром бизнеса, в котором будут как приятные моменты, так и не очень. Про один из них вы уже что-то слышали из социальной рекламы — налоги.
Чтобы платить налоги (если у вас не вменённый доход), вам нужно как-то посчитать, сколько денег вы всего заработали за период. Маловероятно, что ИП сразу начнёт работать по безналу, а при работе с налом с недавних пор в России требуется кассовый аппарат.
Конечно, вы захотите составить каталог своих товаров и услуг, чтобы можно было сразу выбрать его из списка — и пробить чек. А в конце месяца посчитать и увидеть, что позиция А вам приносит на х% больше, чем позиция Б.
Так на вашем ноутбуке появляется простенькая 1С-ка — или любой другой аналогичный продукт.
Бизнес идёт отлично, у вас появился помощник, затем ещё один.
Вы открыли вторую точку в другом районе города, и там нужно поставить вторую кассу. Она уже не может быть подключена к вашему ноутбуку.
Вы читаете инструкцию к кассе, настраиваете подключение через мобильный интернет. Либо обращаетесь в компанию, где купили её, там вам с удовольствием помогают. Про какую-либо интеграцию речи пока не идёт.
Бизнес идёт всё лучше, вам удалось войти в корпоративный сектор. Возможно, я немного приукрасил, но вы смогли заинтересовать две местные компании. Не очень большие, всё же это настоящие юрлица, с которыми вы заключили свои первые настоящие договоры!
И ещё один договор, третий, с поставщиком, а то как-то с устными договорённостями о поставках у него не очень: нарушает сроки, есть вопросы по качеству.
С первым клиентом вы смогли договориться на предоплату, а второй убедил вас на постоплату, и вам теперь нужно вести учёт в разрезе клиентов, чтобы точно понимать, кому сколько было «взвешено в граммах». К счастью, в вашей 1С есть справочник контрагентов, и вы торжественно занесли в него две первые записи. Ещё своего поставщика, на всякий случай. И ещё одну — «прочее».
После вчерашней вечеринки у вас разболелась голова. Вы сходили в банк за выпиской по счету — и «обнаружили» там свой первый приход! Конечно, такой повод нельзя было пропустить и не отметить. И тут вы задумались, а что если однажды ваш бизнес вырастет настолько, что платёжки будут приходить каждый день?
Несколько раз всё чуть не пропало. Обязательства заставили вас сильно изменить свой бизнес. Проблемы начали возникать, в общем-то, в самых простых вещах. Там, где вы их точно не ждали.
Во-первых, впервые за несколько лет напряжённой работы вы решили сходить в отпуск. Недавно был выполнен неплохой заказ, появились кое-какие свободные деньги, почему бы не отдохнуть?
Обо всём договорились, назначили самого смышлёного из сотрудников своим заместителем, сказали, чтобы звонил, если что-то пойдёт не так — и уехали отдыхать на две недели.
Первую неделю звонков не было, и это была, возможно, самая счастливая и спокойная неделя в вашей жизни. Последняя такая.
Затем раздался звонок. Нет, не так. ЗВОНОК. Не так пошло не только лишь всё, вам пришлось в срочном порядке возвращаться домой — и восстанавливать всё, что без вас чуть не поломали: отношения с клиентами, процессы, учёт.
С самым смышлёным пришлось расстаться, а для себя вы сделали два вывода:
1. Пришла пора нанять первого менеджера, руководителя. И дело пока даже не в том, что вы не успеваете, а в том, что просто не можете ни на день передохнуть. Поскольку схема работы ИП не подразумевает иерархию, значит, вы образуете юрлицо и становитесь ООО. С перезаключением всех договоров.
2. Вы понимаете, что нужен инструмент, который позволит вам в любой момент понимать, как сейчас идёт бизнес. Регулярные отчёты. Ну, ладно, не в любой момент, но хотя бы раз в неделю? Нет? Хорошо, раз в месяц.
Во-вторых, в связи с образованием юрлица вам пришлось обратиться к франчайзи 1С, купить версию программы для юрлиц.
Недавно нанятый менеджер привел в компанию толковую бухгалтершу — пока на неполный рабочий день, конечно. Она же объяснила, что для работы вам нужно будет заказать у франчайзи 1С разработку пары отчётов, без которых вот совсем никак. Также она взяла на себя расчёт зарплаты и кадровое делопроизводство, только начала вести их не в 1С, а в другой программе, которой их учили в колледже.
Прошло ещё несколько лет. Были взлёты, были падения, было всякое. В стране отгремел кризис, но вас как-то особо не затронул. В том числе благодаря тому, что вы всегда чётко понимали состояние своего бизнеса, и могли оперативно «резать косты» там, где это необходимо.
У вас сформировалась репутация надёжного партнёра, число клиентов превысило 20, а в компании трудится уже около 50 человек. Появилось несколько отделов!
Отчётов для работы нужно всё больше, поэтому вы взяли в штат программиста 1С-ника, он же со временем освоил и начал дорабатывать ещё и кадровую систему. И ещё одного парня, айтишника на все руки для поддержки сотрудников, настройки компьютеров, принтеров и прочего оборудования.
Результаты вашей работы, товары, больше не помещаются в вашей спальне, коридоре, гараже — и вы решаете арендовать склад.
Начали думать о программе для управления складом и поставками (было пару кейсов — увезли товар не тому клиенту), но 1С-ник подсказал, что можно купить модуль склада для 1С. Или вообще ничего не покупать, он сам напишет лучше — и именно с учётом ваших потребностей.
Ещё вы несколько раз перепутали скидки, которые обещали разным клиентам, а недавно вообще выставили счёт на несколько миллионов не тому клиенту, из-за чего он сильно напрягся. Все сотрудники как один твердят, что пришла пора внедрять CRM.
Паренёк-айтишник недавно закончил университет — и предложил написать свою CRM, которая включала бы в себя и весь ваш производственный цикл. 1С-ник обещал ему помочь. И буквально за пару недель они набросали работающий прототип, им вполне можно было пользоваться!
Оба говорили и вели себя достаточно уверенно, и в этот момент вы серьёзно задумались: развивать ли свою собственную IT-службу, разрабатывать ли собственные решения — или обратиться к какому-нибудь интегратору, воспользоваться услугами аутсорсинга?
Порядком подумав, выслушав и прочитав множество мнений, вы решили не выбирать аутсорсинг. Во-первых, он почти всегда дороже, чем сотрудники в штате, т.к. с него кормятся не только исполнители, но и их руководство, и ещё платится множество налогов.
Во-вторых, далеко не всегда гарантируется качество такой работы, даже если исполнители самые титулованные (в неформальной обстановке вы как-то раз спросили у них про процент успешно и вовремя выполненных проектов, ой, зря…)
И, в-третьих, и это самое критичное: ни один аутсорсер не будет вам делать работу «как для себя». Это противоречит его бизнес-интересам привязать вас к себе всеми возможными способами.
В итоге, вы поверили убедительным голосам своих айтишников — и решили, что так будет лучше, иметь свои собственные разработки! Понятно, что позже понадобится взять ещё разработчика — и не одного. Понятно, что они будут косячить со сроками, что будут делать не то, что будут отвлекаться. Тут главное, чтобы руководитель был толковый. А нюансы — так они у всех нюансы, есть они и в бухгалтерии, и у охраны, и в АХО.
Примерно с этого момента в бизнесе начинает происходить слишком много всего, и описывать в событиях развитие бизнеса я не буду, сконцентрируемся на увеличении сложности IT-инфраструктуры, повышении количества систем в контуре и развитии интеграции.
Также примерно на этом уровне появляется опасность наступить на одни из самых больших и неоднозначных граблей в истории корпоративной интеграции: позволить системам общаться друг с другом напрямую. См. на примере схемы ниже: CRM «ходит» за данными в складскую и кадровую системы напрямую.
С ростом бизнеса был открыт офис в соседнем областном центре, потом в северной столице. Настал очередной критический момент в развитии бизнеса и компании — региональное масштабирование.
Многокрови кофе было выпито, много сигарет выкурено в поисках лучших сценариев. Вы с удивлением узнали, что для расширения в других офисах часто недостаточно просто умножить расходы «на два». Например, чтобы из второго офиса можно было по внутреннему телефону «бесшовно» звонить в первый, нужно потратить заметно больше, чем просто на первый офис. Нужно создавать инфраструктуру, покупать оборудование и лицензии на ПО. К счастью, третий офис, четвертый и т.д. уже не требуют таких капитальных инвестиций.
После нескольких инцидентов с утечкой информации вы решаете нанять специалиста по ИБ. Он, конечно, переворачивает вверх дном почти всю IT-инфраструктуру — и быстро завоевывает искреннюю «любовь» всех айтишников. Но лишь на время, т.к. умеет наглядно обосновывать свои требования, да и, в целом, сам айтишник, одной с ними крови. Первым его требованием было закрыть все ненужные порты — и направить информацию по защищённым каналам. Он дал много добрых советов по мониторингу, бэкапам, защищённости, другим полезностям, но самое главное в контексте этой статьи — принёс в компанию ещё пару информационных систем, которые нужно было интегрировать с остальными. Всего их у вас получилось уже 7-8.
Недавно был запущен корпоративный портал, интранет, он стал хорошим помощником для сотрудников. Однако, самым большим откровением для вас стало то, что на портале не получилось вывести структуру компании и список сотрудников. Нет, ребята что-то показали, но что это за структура, где они её взяли? Это просто какой-то гибрид ужа и ежа! А список сотрудников? Вы лично увольняли нескольких из них, почему они до сих пор показываются? Они есть в кадровой системе? А в 1С? Откуда эти данные?..
Разработчик 1С *) вышел с предложением купить и внедрить модуль для учёта мастер-данных — это когда вся информация по всем общим справочникам (например, по структуре, сотрудникам, контрагентам) собирается и контролируется в одной системе **). А также чтобы все обмены информацией шли через эту систему, тогда этот процесс будет наглядным и управляемым. Если будут какие-то ошибки, их сразу заметят — а это особенно важно. Пару месяцев назад уже был прецедент, когда информация о зарплате не выгрузилась из кадровой системы в 1С, и зарплату сотрудникам не перечислили вовремя.
Что для этого нужно? Выбрать такую систему. Разработчики советуют решение на платформе 1С — это конструктор, который нужно дорабатывать для себя. Также разработчики настаивают на том, чтобы все обмены шли в реальном времени, никаких ночных обменов и обменов по расписанию. Будущее этого решения пока не очень понятно, но обоснование его нужности звучит ясно и логично. Берём!
Территориальную экспансию компании можно сравнить со взрывом! За пару лет было открыто несколько десятков офисов, штат компании увеличился в несколько раз. Были открыты первые зарубежные офисы в нескольких странах бывшего СССР. Люди там, в общем-то, нашенские, процессы все понятные, законодательство и налогообложение практически не отличаются от России.
Главный вопрос в планировании IT-ландшафта и интеграции на этот момент — есть ли возможность каждой информационной системе работать для всех стран одновременно? На практике у каждой системы оказались свои нюансы. Бухгалтерская и кадровая системы — их нужно вести строго в разных базах. MDM и ESB пришлось доработать таким образом, что в большинстве справочников появилась страновая привязка. Причём некоторые элементы (например, ФИО, должности, названия контрагентов) пришлось хранить сразу на нескольких языках.
Корпоративный портал также удалось сохранить единым, сделав несколько разделов на разных языках. CRM, включающая в себя, помимо клиентских функций, ещё и автоматизацию ваших основных бизнес-процессов, также успешно смогла работать во всех странах присутствия.
На самом деле, вы довольны ситуацией в IT и IT-командой. Заложенные когда-то основы позволили без особых трудностей и стоп-факторов осуществить экспансию. Трудно представить, сколько сил и ресурсов у вас ушло бы сейчас, если бы в компании не было мастер-данных и шины данных. Про CRM вообще молчим!
Казалось бы, всё прекрасно. Обмены работают, данные ходят, бизнес-процессы выполняются. Но.
В последнее время всё чаще слышится с разных сторон, что данные неправильные. Все системы, всю интеграция многократно проверили, протестировали. Нет, никаких технических ошибок и сбоев нет, всё работает как часы.
Однажды корпоративный портал поздравил вас с годовщиной работы в компании. Всё бы хорошо, но стаж показался на несколько лет меньше, чем вы на самом деле работаете — и дата не та. Вы задумались, вспомнили свой выпуск из университета, первые годы работы…
Что-то пошло не так. Разработчики пошли разбираться, подняли историю. Оказалось, что при каком-то перезаключении трудового договора кадровик опечатался, ввёл неправильную дату. Понятно, обычный человеческий фактор, ничего страшного.
На следующий день вы заключили важный контракт. Предоплата? Нет, несколько дней деньги на счёт не поступают. Точно перечислили? Точно перечислили! А что не так? Звонок в банк, те говорят: ошибка! Оказалось, что в системе MDM устарели данные о реквизитах: они поменялись. А сотрудник, который должен был их исправить, заболел.
И такого много, почти каждый день, почти с каждым справочником и по каждому процессу. Количество недовольных ситуацией в компании растёт, сотрудники во всём винят систему мастер-данных, операторы раз за разом оправдываются и говорят об ошибках сотрудников.
У вас даже возникли мысли, а не заменить ли используемые продукты. Вот, на одной презентации рассказывали, что продукты SAP (Oracle, IBM) не глючат! Разработчики возражают: нет, дело не в продуктах, дело в процессах. Провели внешний аудит, он подтвердил: технически системы работают корректно.
При больших объёмах информации обнаружилась проблема, на которую раньше никто не обращал внимания ввиду её незначительности — качество мастер-данных. Данные устаревают, данные теряют актуальность, люди, которые вносят эти данные, постоянно ошибаются. И ничьей вины в этом нет: на объёмах в сотни тысяч записей ошибки появятся неминуемо.
Дополнительным фактором, повышающим вероятность ошибок, было то, что когда-то вы выбрали гармонизованный сценарий ввода данных. Это означает, что данные могут вноситься в любую систему, а потом собираются в MDM. Например, нового контрагента можно добавить в CRM, через корпоративный портал, в 1С — любым способом, удобным для конкретного сотрудника в конкретный момент времени.
Проблема с качеством данных? Хорошо, у разработчиков, наверное, есть множество инструментов для контроля качества данных, для автоматизации процесса. Сколько-сколько? И что, только руками писать проверки?
К сожалению, простого решения у этой проблемы не нашлось. Её можно было бы проигнорировать на какое-то время, но в динамике стало понятно, что через пару уровней развития компании эта проблема вас просто похоронит. И никто конкретного не будет в этом виноват. Но как же тяжело внедрять сложные решения!
Есть решение проблемы качества данных!
Да, для этого потребовалось качественно изменить подход к работе с данными во всём их многообразии. Проект по изменениям кем-то почти в шутку был назван “качество для качества”.
Появилось понятие ответственного за данные (очевидно, что им не может быть IT-департамент), за каждую конкретную запись в каждом справочнике. Были проанализированы все процессы — и разработан механизм классификации ошибок, механизм создания проверок данных. Ведь по мере накопления данных появляются всё новые и новые виды ошибок, а, значит, процесс заведения правил и проверок должен быть встроен, по сути, в сам процесс ввода данных.
Шли долгие дискуссии на тему того, должна ли функция контроля качества данных быть централизованной или децентрализованной. Финансовый департамент считал, что качество данных по договорам и счетам — их зона ответственности. Административно-хозяйственный считал “своими” данные по имуществу, и так далее. Быстро выяснилось, что с точки зрения разных мест в компании есть разные критерии по качеству данных.
Для одного нужна одна нарезка, для другого другая — дошло до того, что некоторые требования оказались даже противоречивыми. Поэтому был составлен и реестр таких требований к данным, сам по себе являющийся мастер-данными, т.к. эта информация теперь нужна всем другим системам. И саму функцию управления качеством данных было решено централизовать, наделив серьёзными полномочиями вплоть до изменения любых процессов в компании.
Изменение процессов в компании вскрыло интересный факт: людям, которые вводят данные, как правило, не интересно, что их ошибки потом повлияют на других. И сложно замотивировать таких сотрудников следить за качеством и исправлять ошибки “просто потому что”. Но также выяснилось, что если им обрисовать последствия (вот здесь неактуальный реквизит, из-за него сотрудник Х не получит завтра зарплату; там ошибка, из-за которой деньги уйдут не туда), это повышает их заинтересованность в процессе.
Была разработана система контроля качества данных — DQS, как модуль MDM. Она запускала проверки (по расписанию и при добавлении каждой записи) — и сообщала об ошибке персонально тому, кто эту ошибку допустил. С описанием возможных последствий.
Правил в системе было сначала 100, потом 500, через год уже около тысячи! Департамент HR здорово помог с тренингами, подсказал варианты мотивации сотрудников, сделали инфографику и мультяшный индикатор количества ошибок, отмечая их уменьшение. Началось даже соревнование, кто найдёт больше ошибок и добавит больше правил! С квартальной премией, конечно.
Следующий уровень развития системы DQS — интеллектуальные правила, нечёткие правила, агрегирующие правила (например, итоговое значение в двух отчётах, описывающих одну и ту же сущность с разных сторон, должно совпасть).
Высший уровень DQS — контроль качества мастер-данных и даже их системное наполнение на основании государственных открытых данных. Пример — сервисы по контрагентам на сайте налоговых, они позволяют контролировать правильность реквизитов в вашей MDM.
За качество данных, за правильность формируемых на их основе отчётов можно быть спокойным. Исправление ошибок внедрено в генетический код вашей компании — и происходит само собой.
Чёткое понимание текущего состояния процессов, работа с отчётами в динамике, контроль качества производства, работа с клиентами позволили вам выйти на первое место на рынке. Название вашей компании стало фактически синонимом отрасли.
Однако, рост вашего бизнеса замедлился. Похоже, вы близки к тому, чтобы занять весь свободный рынок, и дальнейший рост возможен преимущественно за счёт поглощений и слияний. Одна из главных проблем в поглощениях — интеграция новой команды со всеми их сложившимися процессами в вашу компанию.
Оставим за скобками административную часть и бизнес-процессы. Если говорить про интеграцию, технически сама задача не очень сложная. Проводится обучение новых сотрудников, затем фиксируется некоторая точка во времени, час “Икс”. После часа “Икс” все вновь запускаемые процессы, новые контрагенты, новые договоры должны вестись строго в ваших основных системах. Рост на 10-20%, даже на 50% эти системы выдержат без особых проблем. Все современные системы класса MDM, ESB, CRM и др. позволяют масштабировать себя, просто докупая новое серверное оборудование.
Параллельно с этим, примерно в час “Икс” нужно заморозить информационные системы поглощённой компании — и сформировать их дамп, подготовить информацию, привести её к вашему формату. Может оказаться такое, что части данных будет не хватать — их необходимо будет либо дозаполнить, либо временно создавать фиктивные сущности, из которых будет понятно их назначение. Постепенно все они должны быть заменены, обогащены реальными данными. Сроки и ответственные за эту работу также должны быть определены.
Выгрузив в очередной раз отчётность из BI-системы, вы загляделись на цифры — и задумались. Численность сотрудников в вашей компании скоро будет шестизначной, это население целого города. Годовой оборот близок к 0.1% ВВП России — и превысил ВВП республик Алтай и Тува. На территории бывш. СССР рынок весь ваш! И, честно говоря, он занят полностью. На нём расти больше некуда.
Недавно свершилось событие, о котором вы мечтали много лет! Вы поглотили небольшую компанию, работающую на рынке Евросоюза — и поставили несколько новых флажков на карте.
Если с точки зрения бизнеса и административных вопросов это поглощение не сильно отличается от компаний внутри бывш. СССР, то технически их интеграция в вашу инфраструктуру вызывает куда большее беспокойство.
Основная причина — строгое законодательство Евросоюза в отношении персональных данных (а к персональным, как объяснят специалисты, в Евросоюзе можно отнести чуть ли не все данные), так называемый GDPR — положение о защите данных и конфиденциальности в Европейском союзе.
Помимо качества данных появляется ещё несколько категорий, в первую очередь — по отношению к персональным данным. Эти категории вы должны фиксировать сквозь все процессы: согласие, договор, публичное задание, жизненный интерес, законный интерес или законное требование. Вы должны быть готовы удалить любые персональные данные при наступлении определённых условий, по запросу самого человека (субъекта данных). Также вы должны не только обеспечивать защиту данных (это у вас давно есть, спасибо службе информационной безопасности), но и регулярно проводить аудиты этой защиты.
И самое главное: данные должны храниться на серверах на территории Евросоюза. В дальнейшем эти или похожие требования будет появляться во всё новых и новых странах, а за их нарушение предусматриваются просто огромные штрафы. В случае Евросоюза это до 20 млн евро или до 4% от мирового оборота компании.
Почти всегда в этот момент выясняется, что архитектура ваших информационных систем не позволяет непосредственно работать с географически распределёнными базами данных. Однако, если вы сумели успешно дойти до этого уровня, ваша команда IT наверняка предложит варианты решения. Поскольку эти изменения потребуют нескольких месяцев, а то и года, готовить их лучше заранее.
Местная компания, региональная, федеральная, что дальше? Глобальная?
Весь мир ждёт вас!
Хочу поделиться несколькими выводами из рассказа выше. Не все выводы однозначные — и предположу, что они могут вызвать возражения. Основное:
Приглашаю к дискуссии!
Год спустя, при проектировании новой операционки 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 и др.
**) ситуация, когда каждая система обращается к каждой (как вариант — микросервисы) здорово подходит в случае интеграции пары продуктов друг с другом или для открытых API. В корпоративном секторе, когда таких систем 20-30, у каждой по 40-50 микросервисов, и каждая система общается с каждой, получается невообразимый клубок связей. Выглядит примерно так.
Уровень 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 наверняка предложит варианты решения. Поскольку эти изменения потребуют нескольких месяцев, а то и года, готовить их лучше заранее.
Местная компания, региональная, федеральная, что дальше? Глобальная?
Весь мир ждёт вас!
Итоги
Хочу поделиться несколькими выводами из рассказа выше. Не все выводы однозначные — и предположу, что они могут вызвать возражения. Основное:
- Продуманный подход к организации мастер-данных и интеграции — вопрос стратегической важности для компании. Ошибки в них могут остановить рост компании, а то и вовсе её похоронить.
- Важны не только сами мастер-данные, но и их качество. По мере роста компании вопрос качества данных выходит на критическое место.
- В то же время, каждый следующий уровень развития MDM, ESB, DQS — дорог и влечёт за собой дополнительные расходы. Есть чёткая шкала, ориентируясь на которую, можно формировать текущую инфраструктуру. Создавать её с запасом больше, чем на 1-2 уровня — не нужно.
- Ответственность за качество данных должна нести не IT-служба, а весь бизнес. Задача IT — предоставить удобные инструменты для реализации этой ответственности.
- Функция управления качеством данных должна быть централизована. Процесс контроля качества — распределён между всеми участниками работы с данными, начиная с их первичного ввода.
Приглашаю к дискуссии!
