Может ли общий протокол доступа к данным заменить компании ИТ-отдел, которого у неё нет. Промежуточные выводы по проектам, которые мы вели сами.
Потому что интеграцию некому содержать. Связь двух систем пишется один раз, а живёт ровно до первого обновления на любой из сторон: меняется формат выгрузки, и через неделю кто-то замечает, что цифры разошлись.
В компании с ИТ-отделом это задача на полдня. В компании без него это тишина: никто не знает, что сломалось, пока расхождение не вылезет в деньгах. Поэтому владелец выбирает ручную работу - она хотя бы предсказуема.
Больше, чем владелец называет на первом разговоре. Обычно перечисляют две-три: кассу, бухгалтерию, может быть склад. На разборе процессов выясняется, что к ним добавлены банк, зарплата, доставка, бронирование, закупки у поставщиков и таблицы, в которых сводится всё остальное.
Нас интересует не количество само по себе, а количество стыков между ними. Именно на стыке живёт ручная работа, и именно он ломается при обновлении.
MCP (Model Context Protocol) описывает один способ дать программе доступ к данным системы. Вместо отдельной связи под каждую пару систем появляется один слой, к которому подключаются и системы, и агенты.
Для компании без разработчиков важно не то, что это новый протокол, а то, что он снимает сопровождение. Подключение описывается один раз и переиспользуется: следующий отчёт, следующий агент и следующая система работают через тот же слой.
Это и есть то, что мы называем интеграционным стандартом: не продукт и не вендор, а договорённость о том, как системы отдают данные.
Окупается там, где одна и та же сверка делается каждую неделю и всегда руками. Такую работу считают в часах, и после подключения часы видно.
Не окупается там, где процесс меняется чаще, чем успевает устояться. Если порядок работы переписывают каждый месяц, интеграция фиксирует вчерашний порядок и становится ещё одной вещью, которую надо переделывать.
Отдельный случай - разовые задачи. Перенести данные один раз дешевле руками, и мы так и говорим клиенту, вместо того чтобы продавать подключение.
Порядка в учёте. Если номенклатура ведётся в двух вариантах написания, а приходные документы заносят с задержкой в неделю, протокол ничего не исправит: он просто быстрее принесёт те же данные.
Это самый частый источник разочарования. Компания ждёт, что доступ к данным заменит их качество, и получает аккуратно собранную неправду.
Выводы собраны по проектам, которые ITHS вёл сам: внедрения, интеграции и запуск агентов в Латвии, 150+ проектов по внутреннему учёту ITHS на 7 октября 2026. Данные клиентов не раскрываются, используются только обезличенные наблюдения. Пока выборка не закрыта, сводных цифр по теме мы не публикуем - в записке только то, что повторяется из проекта в проект.