Для начала давайте попробуем разобраться, что вообще из себя представляет интеграция информационных систем. Интеграция информационных систем – это объединение двух и более программных продуктов в единую, целостную систему. Но это совсем не значит, что на выходе мы получим совсем другой продукт. Просто автоматизированный бизнес процесс, реализуемый несколькими программными продуктами, не потребует в будущем дублирования данных вручную из одной системы в другую. В чем же заключается сложность?
Все мы с вами знаем, что всё уже давно придумано за нас. Различные ERP, CRM, SCM, WM и прочие системы внедряются уже с готовым функционалом, который нужно только кастомизировать под потребности бизнеса. Внедрение таких систем (особенно «классических», как 1C, SAP или IBM) давно уже не вызывает особых сложностей, процесс отлажен годами и от проекта к проекту не так уж и сильно отличается по своей сути. Остается только собрать все кирпичики воедино и заставить наш комплекс информационных систем дышать как один живой организм. Но так ли это легко? Давайте разберем на примере.
Представьте себе маленькую компанию, которая покупает товары подешевле у поставщиков и продает эти товары розничным сетям, типичный такой дистрибьютер, коих на российском рынке очень много. Компания начинает расти, обзаводится своим сайтом, расширяет складские помещения, появляются новые клиенты, в общем, дела идут отлично. Начинают внедряться различные информационные системы для складской логистики и работы с клиентами (естественно самые дешевые, мы же не идиоты, чтобы переплачивать, в самом-то деле), все более-менее автоматизируется, и мы начинаем создавать интерфейсы для взаимодействия наших систем. Например, пишем простой модуль-брокер, который принимает данные о клиенте с сайта и передает их в базу нашей системы по работе с клиентами. К тому же, новых информационных систем в компании становится все больше и больше. Я, например, видел компании, где только корпоративных информационных систем (уровня CRM и EWM) – больше 20, что уж говорить про различный мелкий софт, нужный для какой-то одной конкретной задачи.
Дела становятся все лучше, компания превращается в крупного игрока на рынке, и тут к руководству приходит понимание того, что старые, дешевые системы не справляются с задачами. Где-то не хватает функционала, где-то просто мощностей системы и оборудования. А так как дела все еще идут отлично и бюджет позволяет, принимается решение о замене старых, уже бесполезных систем на новые – более дорогие, производительные и обладающие гораздо более широким функционалом. Система закупается, внедряется, весь функционал настраивается под действующий бизнес процесс (на что, кстати, уходит весь бюджет проекта) и.. ничего не работает. Почему? Да просто при закупке новой системы не учли, что для нормальной эксплуатации будет необходимо переписать каждый интерфейс, объединяющий старую информационную систему со всеми остальными системами компании. А таких интерфейсов может быть больше сотни, ведь мы же все делали правильно с точки зрения архитектуры: нужен процесс заведения нового клиента через сайт? Сделаем интерфейс между сайтом и CRM. Нужен процесс изменения данных клиента? Добавим еще один. А может его и удалить когда-нибудь понадобится? Да не вопрос, добавим еще интерфейс!
И такая ситуация – вполне нормальная, единственная ошибка, которую совершили ответственные за проект лица, заключается в том, что они не учли бюджет на доработку старых интерфейсов. Изначально, создавая эти интерфейсы, разработчики все делали правильно. И действительно, на первых этапах развития компании, когда выбор падает на самые дешевые системы, которые решают только насущные проблемы «здесь и сейчас» об архитектуре интеграции даже думать смысла нет, это просто нецелесообразно с точки зрения вложений. Но при росте информационного обеспечения компании начинают возникать две основные проблемы:
Во-первых, это технологические различия систем – различные системы могут использовать различные протоколы передачи данных, различные форматы для хранения данных и т.д.
Во-вторых, архитектурные различия систем — по сути своей концептуальные различия в принципах работы и хранения данных. Чаще всего подобные проблемы встречаются в самописных системах, в которых разработчики просто не учли возможность интеграции в модульную архитектуру компании.
Что же делать в таком случае и как избегать таких проблем?
Для начала при разработке интерфейсов нужно озаботится корпоративным стандартом интеграции. Да, если внедряемая информационная система была закуплена как готовое решение, это не очень-то и поможет, но при заказе разработки новой системы «под себя» проблема интеграции решится сама собой.
Также стоит использовать единые модели данных для всех систем компании. Даже «коробочные» решения требуют кастомизации модели данных под конкретный бизнес. Тогда почему бы не делать все в едином формате для каждой внедряемой информационной системы? Вся сложность тут – в убеждении конечного пользователя продукта, что так будет лучше для всей компании.
К тому же необходимо сразу объединять все разрабатываемые интерфейсы в единую систему интеграции. Это будет первым шагом на пути к созданию своей полноценной интеграционной шины.
В следующих статьях мы поговорим о различных видах интеграции и перейдем к современным тенденциям в интеграции, а также почему интеграция информационных систем, сервисов и приложений – ключевой элемент Интернета вещей.
Автор статьи: специалист компании «SOLMIX Consulting» Запивахин Игорь
