Когда клиент получает предварительную смету по проекту и видит, что на интеграцию заложена сумма, равная половине стоимости всех работ, а то и больше — он сразу хочет такую смету развидеть. Мы в его глазах превращаемся в выпускников строительного колледжа, которые пришли делать ремонт и пытаются продать ему цемент из соседнего магазина по цене Х5. Как BMW X5 🙂
Нет, мы решили написать этот большой текст не потому, что хотим больше зарабатывать. Хотя и это тоже 🙂 А потому, что мы видим сотни случаев, когда клиенты экономят на интеграции, а потом бизнес-процессы просто останавливаются, например, из-за банального несоответствия форматов данных. Итак, поехали.
Что такое интеграция и зачем она нужна
Как правило, в компаниях есть разные системы — CRM, ERP, WMS и другие. Одна считает остатки товаров в штуках, другая оценивает их в деньгах, третья решает, что с этим можно сделать. Когда данных немного, то можно их переносить из одной системы в другую руками — просто копировать-вставить. Но когда в компании большие объемы данных, то комбинация “копировать-вставить” обходится уже дорого и занимает много времени, так как на это тратится куча человеко-часов. В этом случае и необходима интеграция, которая позволит всем системам обмениваться данными друг с другом автоматически.
Интеграция позволяет:
1. Сделать процессы в компании прозрачными, сквозными и бесперебойными.
То есть, менеджер может на одном экране видеть, что происходит на каждом этапе всех сделок. Ему не нужно рыться в базах разных систем, чтобы в одной найти точное наименование клиента, в другой узнать его статус, в третьей — историю заказов. Если системы интегрированы друг с другом, то одна сигнализирует, что у такого-то клиента возник долг и передает другой системе задачу связаться с этим человеком.
Или еще пример. Клиент попросил просчитать стоимость нестандартной металлоконструкции. Если в компании нет интеграции, менеджеру нужно в одной системе узнать наличие металла на складе, в другой — где заказать, если не хватает, в третьей — стоимость и т.д. Все это время клиент ждет.
Если компания небольшая и такие случаи — редкость, то проблем не возникает. Возникают они, когда такие запросы сыпятся десятками в день.
2. Унифицировать данные в компании.
В одной системе один и тот же контрагент может быть записан как ООО “Ромашка”, в другой — “Холдинг “Ромашковое поле”. Если в компании 10 таких записей — окей, менеджер может удержать это в голове. Но если их тысячи?…
Образно говоря, интеграция — это фундамент, на котором держится весь будущий проект. Да, клиент заказывает “дом”, он хочет, чтобы зашел — и красиво. А что там в основании — его мало интересует. Но, без фундамента, любой дом просто рухнет.
Цели и процессы
Итак, вроде бы мы понимаем, что такое интеграция. Теперь нужно разобраться, с чего ее начать.
Сначала анализируем цели компании, и какие процессы в них участвуют. Например, цель — сделать продажи прозрачными. Мы смотрим на следующие моменты:
- какая информация у нас движется в процессе продаж,
- в каких системах и в каком виде она присутствует,
- рисуем потоки данных между этими системами.
После такого описания бизнес-процессов, выбираем варианты интеграции.
Логические варианты интеграции
Прежде, чем создаем техническое решение, мы прорабатываем так называемые логические варианты интеграции.
Какой может быть интеграция?
- Онлайн. Обмен данными идет в реальном времени. Допустим, интернет-магазин выставляет счет в CRM, но формируется он в ERP. Соответственно, эти две системы должны сконнектиться немедленно.
- По расписанию. Например, остатки за день система WMS обрабатывает ночью и отправляет данные в CRM.
- Вручную. Например, если номенклатура товаров небольшая и меняется редко, то новые позиции можно добавлять или удалять вручную.
Причем, чаще всего, в компании эти варианты интеграции сочетаются. Продолжим последний пример. Можно добавлять товары вручную, а вот цены, например, если они зависят от курсов валют или объемов товара, меняются часто. И эти данными соответствующие системы уже должны обмениваться в режиме онлайн.
Технические способы интеграции
Сейчас самый распространенный способ связать разные системы — через API, программный интерфейс приложения. Это, по большому счету, язык, на котором разговаривают разные системы.
Вот мы с вами, читателями, разговариваем на русском. Но у нас есть много всяких технических словечек, которые вы можете и не понять. Так же и системы в какой-то момент могут не понять “сленг” друг друга и им нужно расширить “словарный запас”. Программисты называют это “методами”. То есть, существующий API нужно дополнить какими-то методами, чтобы системы обменивались определенными типами данных в рамках различных процессов, которые необходимы для достижения конкретных бизнес-целей. В общем, то, о чем мы писали выше. Вы же внимательно прочитали, верно? 🙂
Да, есть так называемые коннекторы, у которых имеется определенный набор дополнительных методов и они позволяют подключить одну систему к другой. Этот как usb-кабель, который может соединять совершенно разные устройства. Коннекторы упрощают и, соответственно, удешевляют интеграцию. Но они обладают ограниченным функционалом, которого может в какой-то момент не хватить бизнесу.
Какие это могут быть ситуации?
- Разный “темперамент” систем. Бывают “быстрые” и медленные” системы. Пример первой — телефония: звонок поступает, и с ним нужно что-то сделать прямо сейчас. Но может понадобиться запросить информацию о клиенте на том конце провода — не должник ли он. И этот запрос кидается в “медленную” систему — ERP, которая в это время занята совсем другими задачами. Когда она обработает тот или иной запрос? Что будет, если таких запросов скопится много? А если такой коллапс случится не с одной системой, а с несколькими? На эти вопросы нужно дать ответы заранее, чтобы в один прекрасный (на самом деле — не очень) день весь бизнес просто не остановился.
Объясним на пальцах, почему случаются коллапсы. Если в какую-то систему накидываются запросы, они могут накопиться в таком объеме, что память закончится. Чтобы разгрести этот завал, система кинет туда все силы, и мощности процессора может не хватить. Тогда система приляжет, а все процессы, связанные с ней, остановятся.
- Нештатные ситуации. Их куча. Например, разрыв на линии, когда данные из точки “А” в точку “В” не пришли. У большинства известных нам коннекторов нет системы контроля передачи данных. Тот, кто отправил, должен получить подтверждение, что информация принята. А если такого подтверждения не приходит — что делать? Или “на том конце провода” вообще никогда больше не ответят?
Все исключительные ситуации создают дополнительную нагрузку на системы. Что с этим делать? Можно ничего не делать. Если нужно из одной системы в другую раз в неделю перенести 10 строчек, то исключительные ситуации здесь будут крайне редкими. Но если речь идет о том, что ежечасно системы отправляют друг другу тысячи сообщений — ошибки неизбежны, и их обработку лучше автоматизировать.
Что же можно “прикрутить” к интеграции через API, чтобы укрепить тот фундамент, на котором будет работать бизнес.
Система мониторинга ошибок. Она позволит выявлять разные сбои в системах и отправлять их специалистам на разбор. Ошибки можно разбирать руками, если их не много. Сисадмины видят журнал ошибок и могут их устранять или предупреждать. Но когда объем данных большой и самих систем много — человек за всем не может физически уследить. И тут на помощь приходят системы мониторинга, которые сообщают администраторам, что вот в таком-то месте образовался пожарчик.
Диспетчеры очередей. Это что-то вроде ленточек в аэропорту. Если их убрать — толпа пассажиров рванет к стойкам регистрации. На каких-то стойках соберутся слишком большие очереди и регистратор будет перегружен. Так же и при работе систем. Диспетчеры очередей позволяют направлять потоки запросов, сортировать их — например, эти важные, как бизнес-класс в аэропорту, поэтому их пропускаем впереди всех.
Шина данных. Отдельный класс систем, которые управляют потоками данных. Так, если системе А нужны данные от систем В, C, D, E, она не будет связываться с каждой, а отправит запрос просто в шину, и каждой новой системе не надо соединяться со всеми, только с шиной. Шина — это как сам аэропорт. Теоретически аэропорт можно убрать — будет летное поле, куча самолетов и людей. Но и никто никуда в реальности не улетит.
А интеграторы, собственно, зачем?
Интегратор имеет бесценную коллекцию грабель, на которые успел наступить, и щедро этим опытом делится. Хороший интегратор — как врач. Он может, например, прописать лекарство в виде коннектора. Принимайте — и будет вам счастье. А может сказать: “Никакого самолечения, тут резать надо”. А сам же пациент себя не прооперирует. Хотя герои голливудских боевиков такое частенько проворачивают 🙂 Но тут действительно надо быть супер-героем.
Хороший интегратор не будет накручивать допработы. Мы, например, вовсе не хотим делать лишнего. Если можем использовать коннектор или какие-то штатные методы, которые прописаны в API — мы их используем. Это упрощает и ускоряет работу. А лишние сложности — это всегда дополнительные риски, за которые самим же придется нести ответственность.
