Тебе хана, если ты не влез в бизнес-процесс заказчика, а копаешься только в ИТ-процессе.
Это общее правило почти не знает исключений. Потому что ИТ-структура часто не владеет данными и не знает, зачем они дальше нужны. А когда речь про интеграцию (без которой не обходится ни одно внедрение цифрового инструмента, будь то модный чат-бот или олдскульный CRM) — это нужно очень точно и детально понимать.
Я видел много разных историй: и то, как один малюсенький сервис для работы с факсами после внедрения начал вести себя как вирус и бороться с почтовым сервером и другими сервисами компании (кстати, победил), и то, как сегмент «малый и средний бизнес» не включал в себя средний бизнес (к искреннему удивлению ИТ-отдела), и как люди просто не знали, в чём смысл обрабатываемых данных и зачем они нужны — это часто касается финансов.
Поэтому давайте расскажу пару баек про то, что случается, когда нужно просто взять и соединить несколько ИТ-систем. Делов-то!
Что такое интеграция в российском понимании
Самые частые примеры такие:
- Нужно получить что-то от имеющихся систем. Например, есть система бронирования билета на сайте, есть система регистрации в аэропорту. Если их соединить, то можно сделать онлайн-регистрацию. Естественно, не всё так просто — по ходу исполнения возникнет очень много вопросов.
- Нужно подключить что-то новое. Например, есть интернет-банк и есть старая добрая АБС для банковских служащих. Нужно разделить слой исполнения и слой интерфейса: то, что делает сотрудник в отделении, и то, что делает сам клиент в интернет-банке, — это интерфейсы. АБС плевать, кто запросил перевод со счёта на счёт: клиент онлайн или он же в отделении или по телефону. Главное — чтобы операция была достаточным образом авторизована.
- Надо построить цепочку. То есть чтобы несколько систем работали как единое целое, чтобы операции начинались, например, в одной из систем, продолжались во второй, а заканчивались в третьей. Так работают переводы в банках: если переводить с карты на вклад, то задействуются обычно сразу несколько систем — АБС по вкладам, процессинг по картам, мобильный или интернет-банк, SMS-шлюз и т. п.
Общий подход — между системами надо как-то налаживать обмен данными. Можно делать это по старинке, через обмен выгрузками и метание файлов на дальние дистанции, можно чуть современнее, можно через веб-сервисы и так далее. Важна не техническая реализация, а общий принцип. Под интеграцией мы понимаем ситуацию, когда ИТ-системы предприятия работают с издержками ниже заданного уровня. Да, можно сделать на коленке с бабушкой и дискетами, но помните, что у бабушки внуки, лунный календарь посадки рассады и всё такое, а ИТ-инфраструктура должна работать всегда как часы, быстро перестраиваться и не быть тормозом для бизнес-процессов, которые на этой инфраструктуре работают.
Вот для всего этого и нужна правильная интеграция.
Подходы разные. Иногда мы используем прямой обмен данными, но чаще разделяем интерфейсы (потребителей сервиса — web-приложения, мобильные приложения, системы партнёров и т. п.) и поставщиков сервисов (АБС, ERP и так далее). И затем построить шину для обмена данными. Если говорить о «бабушке-файлоперекладчице» как о самой древней технологии интеграции, то подход с шиной уже — индустриальный век. Интерфейсы отдают данные в шину, шина несёт их к исполняемым модулям и «говорит» им, что делать. По пути может выполняться преобразование форматов данных или протоколов взаимодействия, делаться дополнение данными из третьих систем, могут координироваться операции в разных системах и т. п. Потом результаты исполнения идут обратно к интерфейсам. Такой подход позволяет навешивать любое количество подсистем, но более сложен во внедрении на первых этапах, но при более-менее большой информационной инфраструктуре имеет смысл, потому что позволяет экономить время и деньги за счёт повторного использования, надёжности, прозрачности и целой кучи других плюшек.
Хотя видел один раз, что у заказчика было удивительно стабильное образование из пяти систем, которые напрямую бегали в базы друг друга и нормально обменивались данными. Года четыре это работало как часы. Потом они узнали, что можно сделать шину, и стало шесть глючных систем — пять имеющихся и ещё шина. Так что тоже не всегда идеальный вариант. Ошибка была в том, что они взяли шину и, не думая, перенесли как есть на неё свои прямые обмены данными. Дополнительный слой сложности и точку отказа получили, а выгод никаких от неё не получили — нужно было правильнее продумывать архитектуру и процессы.
В реальном мире в чистом виде идеальная архитектура получается крайне редко. Потому что чтобы построить всё правильно и работающим как часы, сначала надо:
- Понять, что происходит (причём у каждого отдела будет своё видение)
- Понять, что нужно бизнесу в итоге (то есть нужен тот, кто видит картину в целом, и это чаще всего даже не ИТ-директор)
- Понять, почему народ сопротивляется изменениям, не хочет пускать в свои системы и делиться своими данными (чаще всего — кому-то не выйдет воровать или кто-то потеряет контроль)
Именно тут начинается самое интересное.
Как начинается проект
Обычно заказчик существует не в вакууме, и какая-никакая интеграция у него есть. То есть что-то уже работает, и его стараются не трогать. Есть, например, кол-центр, он умеет подтягивать данные о клиентах из общей базы. Организовано это через задницу, но организовано, и всё, уже хорошо. Проходит пять лет, поддержка выстраивает вокруг этого костыли. Затем система начинает обрастать новым функционалом, который вообще-то не для неё. Например, на базе корпоративного мессенджера вдруг появляется обмен большими файлами, на базе кол-центровой CRM начинают строить бизнес-аналитику (потому что там были зачатки готового модуля, и решили быстро сделать на них) — и в итоге в систему передают на порядок больше данных со всей компании, только чтобы нарисовать графики, и так далее. Выглядит, с моей точки зрения, это так:
— Парни, вы же из ИТ, вы же умные. Сделайте нам вот такую мааааленькую штуку быстро и дёшево.
— Для этого нужна такая-то система, это непросто.
— Да ладно вам, слепите по-быстрому, это ж времянка.
А нет ничего более постоянного, чем такие времянки.
В итоге примерно раз в 5–7 лет заказчики понимают, что нужно внедрять новую большую систему или заменять совсем уже задыхающуюся старую — и вот здесь всплывает море всего того, с чем мирились годами. Начинается стадия разгребания ошибок.
Никогда не бывает так, что «с понедельника всё по-новому». Многие думают, что новая система — это когда все будут спать спокойно. Нет. Поначалу это чаще всего новые точки отказов, а не панацея.
Вот взять то же внедрение секси-интернет-банков. Это фронт к АБС, то есть ядру банка. Надо соединять АБС, кредитный офис и все подсистемы, нужна шина и интерфейсы. Поначалу «на костылях» лепят выгрузками, и получается не очень онлайн-то банк. Потом приходит понимание, что можно разбить каждую операцию фронт-офиса на абстракции и сделать API к системе, которой пользуются служащие банка, и это API отдать интернет-банку. И только потом уже приходит понимание, зачем шина.
Мы учим людей договариваться
Как я уже говорил выше, если не влезть в бизнес-процессы, то проект обречён.
Вот пример: сначала всё просто технически. Два отдела, в одном данные обрабатываются в 1С (бухгалтерия), во втором — в HRMS (система кадрового учёта). Пока сотрудников было две сотни, всё было хорошо: выгружали CSV, импортировали в другую систему, выдавали зарплату и всё хорошо учитывали. Через 6 лет сотрудников стало под тысячу. Шесть человек в отделе кадров занимались тем, что вручную выполняли такты скрипта. Мы пришли писать этот скрипт. Звучит просто, правда?
Пересадить кадровиков в 1С и наоборот нельзя (точнее, экономически необоснованно) — их приклад делает то, что прикладной софт другого отдела не может. Поэтому можно или сделать на основе одной из систем мастер-хранилище данных, или же сделать его снаружи.
И вот в этом месте уже начинается политическая грызня, чья система главнее. Потом — кто и как будет выгружать данные, в каких форматах, в какой кодировке. Эпический холивар между 1251 и UTF-8 в одной компании длился месяц совещаний (это в другом проекте, обычно конкретно этот вопрос как раз шина решает с лёгкостью).
Затем надо договориться, какой формат данных универсален. Здесь оба отдела рассказывают, что им нужно в базе данных и что они будут использовать. Только потом, когда они точно поймут, что и как, можно решать. В этой истории мы использовали индексное хранение — на сервере интеграции были ссылки к разным кускам базы (и конвертеры) — как картотека в библиотеке, отдельного data lake не было.
Ключевой момент — чтобы люди договорились между собой, какие данные, как и где будут использоваться, кто их туда кладёт, откуда и почему. Если это есть — всё остальное уже техника. Именно это мы и помогаем делать, и уже из того, что нужно бизнесу, рождаются технические решения.
Если пример с бухгалтерией и кадровиками слишком абстрактен и прост, представьте ситуацию, когда один банк поглощает другой. Просто подумайте, что вам нужно соединить и дописать, чтобы разные ИТ-системы работали вместе и позволяли в отделениях делать вообще всё, что привыкли делать клиенты. Я бы очень хотел почитать хроники такого ИТ-директора, например. Но это всё обычно под жёстким NDA.
Истории
Первая история — не байка. Просто посмотрите, как развивалась СМЭВ — интеграционная шина масштаба всей страны. Это обмен данными между ведомствами. Например, чтобы при получении загранпаспорта вам не пришлось собирать справки и приносить военник. Логично же, правда? Все документы на вас у государства есть, и надо просто запрашивать их внутри системы. Но нет. Кто знает эту историю — теперь подключиться к СМЭВ довольно сложно. Потому что сейчас в боевом виде работает уже третья реинкарнация шины. Первая версия была уровня беты — было очень сложно научить ведомства просто определять, что за данные у них есть и как их выгружать. Во второй подключали многих, и в результате появилось дикое количество функций без должного уровня абстракции, разработанных не всегда оптимально. В третьей версии обновили документацию, ввели больше проверок и аттестаций. Теперь данные приходят в систему в более-менее едином формате.
Вообще, части любой интеграции — это данные, интерфейсы, люди, приложения. Приложения — понятно, это обработчики данных. Например, если надо выдать зарплату Иванову, то обработчик может этим заняться. Данные — это абстракции в чистом виде, то есть информация о том, как отличить Иванова от других людей, какая у него зарплата и так далее. Интерфейсы — это откуда берутся команды, например, софт кадровика предприятия или XLS. Люди — это люди, которые что-то хотят и делают. Их обычно упускают из виду.
Вот ещё пример. Помогали одной организации выстроить клиентский сервис и продавать больше. При этом организация немолодая, информационных систем у неё много, а данных — ещё больше. Для начала надо было понять, а кто вообще клиенты этой организации. Один и тот же человек мог оказаться Васей Ивановым (или вообще «Пушистым Чепушилой», если данные из профиля соцсетей), Ивановым Василием, Ивановым В. А. или «паспорт номер 1234 5678901». Для начала нужно понять, сколько здесь человек: это всё один и тот же Вася или это ошибки типизации? У той организации было несколько миллионов записей о клиентах. Оценка была — по пять записей на человека. Сделали очистку, дедупликацию — сократили до 1,4 записи на человека. Было очень много неоднозначных данных ещё с бумаги, в том числе со старых гроссбухов — там могли оказаться только фамилия и инициалы.
Часто заказчик неправильно ставит ТЗ, не думая, что и как. Например, было у нас требование про 100 транзакций в секунду. Но при этом имеющаяся система умела обрабатывать всего 5 записей в минуту. Говорили, расширяются. Пришлось менять железо, лицензии, перестраивать очень многое в инфраструктуре. Оказалось, им нужно было около 2 записей в секунду (120 в минуту), и это можно было сделать на текущем железе с минимальными изменениями. И это требование на 5 следующих лет. Не посчитали — потратили много лишних денег. Спрашиваем: мол, почему сотня транзакций-то? Нам объясняют: это специальный аналитик посчитал. Когда мы потом отмечали запуск в эксплуатацию, то этот аналитик признался: мол, число красивое.
Само по себе внедрение редко делается долго. Больше — проектирование. На этом этапе владельцам систем надо договариваться, какие данные кто кому открывает, кто несёт ответственность за данные, какие процедуры контроля. Начинается разворашиваться муравейник — это дико сложно организационно и психологически. Потому что люди в России цари: «Мои системы, мои данные, не отдам снаружи, а то вдруг скажут, что плохо работаем. Не хочу такого». Большой риск, но при должной настойчивости решается.
Больше всего усилий на этой стадии могут потребовать совещания на выживание. Был, например, проект объединения нескольких подсистем в одной компании с госучастием. И за часть подсистем отвечали другие компании, которые там жили очень долго до этого. И привыкли работать в своём темпе. Самое страшное случилось в середине проектирования — одна из компаний очень хотела повысить свою значимость, и мы каждую неделю приезжали на совещания с ними. Полгода они вырабатывали решение, что разница между численными показателями внедряемых систем не очень важна, а важно, чтобы всё это работало.
Или другой пример: в одном банке собирали на совещания всех, при этом моего участия было явно минут на 5. В итоге — минус 3–4 часа. По сути — полностью потраченный день, что бывает очень обидно. Но если заказчику важно, ничего не поделаешь.
Есть мнение, что любой подход можно шаблонизировать, то есть у нас есть конкретная задача, которую можно декомпозировать до того, чтоб там сделать действие 1, действие 2, действие 3, переложить файлик. И потом под неё выбрать уже готовый инструмент либо написать свой, если ты понимаешь, что ты делаешь. Но надо сначала понять задачи, для чего мы это делаем. Когда сталкиваешься с конкретной интеграционной задачей, ты решаешь конкретную интеграционную задачу.
Бывает, после построения стучат к нам: мол, «шина ваша не работает». Правильно, появилась новая сущность — валите всё на неё! Поэтому в правильных проектах вводят специализированные системы мониторинга, чтобы долго и мучительно не разбираться в том, что и где упало. Такие инструменты сразу показывают, какая подсистема и где не отвечает. В одном из проектов всё равно первый алерт получали те, кто отвечал за шину, то есть мы.
— У вас шина не работает!
— Да не, это у вас вот тут не работает.
— Ааа, ну ладно. Не расслабляйтесь там.
Или вот сдача-приёмка. Есть 8 сервисов, надо сдать их за один тестовый день. Два модуля наши, остальные писали другие компании. Бизнес в субботу «играет» в свою деятельность в новой системе, по очереди испытывая модули. Всё отлично. Суббота закрыта, вечером все едут по домам. Переключение. Это правильный процесс.
Другой банк перенимал опыт, построил процесс так же. Только тестировал не на полной инфраструктуре, а по частям. Не сводя всё в полный процесс, не проверяя связки между модулями (точнее, проверяя базово, на уровне простых тестов). А в понедельник после переключения оказывается, что никому у заказчика в голову не пришло проверить взаимодействие систем при определённых условиях. То есть они протестировали все отдельные сервисы, но не то, как они взаимодействуют между собой, Карл! Начинают колбасить запросы, что-то отправлять, получать, ещё что-то. Вечером одна из подсистем начинает создавать поток данных, который просто перегружает другую, и начинается цепная реакция. Всё падает.
Причина — для того, чтобы ставить комплексные испытания или реализовывать комплексный проект, в идеале нужно, чтобы был единый генеральный подрядчик, заказчик, с которого можно спросить, чтобы он всех организовал, либо самим организовывать. Вы не поверите, но это далеко не всегда так. Сколько было проблем, когда больно из-за того, что за интеграцию от формочки до формочки отвечает много людей.
Широкополосное шоссе с данными
Мы, по сути, работаем переводчиками. Есть заказчик от бизнеса, который говорит: «Нам надо вот этот». А его никто не понимает дальше. Поэтому проблемы, цели и устремления бизнеса надо перевести на технический язык, чтобы донести разработчикам. А потом проблемы разработчиков донести до бизнеса так, чтобы им было понятно, что упадёт, если не учесть их потребности. И прежде всего — как это всё выстроить в архитектуру, потому что чаще всего на предприятии образуется некое лоскутное одеяло: здесь одно, здесь другое, здесь третье. Это совсем разные языки, разные справочники, разные команды. До каких-то пор они как-то друг с другом ладят, но задача всей интеграции заключается в том, чтобы из этого одеяла сделать такое широкополосное шоссе с данными, на которое приезжают со всех сторон, и всем всё понятно: откуда, куда, на каких автомобилях и зачем.
Самое страшное, что ИТ-отдел и бизнес живут в разных реальностях. ИТ далеко не всегда знает, что реально важно для бизнеса (какие операции наиболее ценны, например, где нужно оптимизировать прямо до зарезу, а где совершенно не важно), а бизнес не знает, какие проблемы у ИТ. «Серваки надо докупить, а то новый год не переживёте» — и вдруг всё становится понятно. А до этого они просто не знали, что «максимальная расчётная нагрузка» — это то, что имеет отношение к очередям на праздники. В таких случаях нужен кто-то, кто способен переводить ИТ-язык на бизнес и помогать им между собой договариваться.
А ещё я обожаю истории, когда кто-то молча что-то меняет в уже готовых системах. Был у нас один герой, который перед Новым годом «навёл порядок в справочнике», удалив записи, которые показались ему ненужными. В результате на таможне сгнило несколько фур продуктов, потому что данные не шли. Мы знали, что сломалось, но человек, который имеет доступ к маршрутизатору, был в отпуске. Это по регламенту мог сделать только он. По правилам безопасности нужно прийти в комнату, открыть один замок, потом второй замок, зайти в серверную, открыть клетку, там открыть консоль, записать информацию в консоли и сделать всё в обратном порядке.
Вот примерно так. Так что если решитесь что-то менять в ИТ — сначала надо договориться всей компанией между собой, а уже потом внедрять. А чтобы договариваться — нужны люди, которые поймут, в чём задача, что и как делать, переведут это на понятный всем участникам язык и помогут всё выстроить. Если сделать только часть работы, например спроектировать идеальную систему, но не убедить людей, что с ней надо работать, — будет провал.
Ну и на всякий случай моя почта: AnIvanov@croc.ru.
Автор: AnIvanov
