Одна система или несколько: как навести порядок в данных

Однако проблема чаще не в количестве программ, а в отсутствии ясных правил:

• Где создаются данные?

• Какая система может их изменять?

• Откуда брать показатели для отчётов?

Если это определено, несколько специализированных систем могут работать как единое целое. Если нет, новая платформа лишь перенесёт беспорядок в более дорогую среду.

Одна компания — несколько авторитетных систем

У бизнеса может быть несколько систем, каждая из которых отвечает за свою область:

• касса фиксирует завершённые продажи;

• складская система хранит оперативные остатки и движения товаров;

• CRM отвечает за контакты, историю взаимодействия и работу менеджеров;

• сайт создаёт онлайн-заказы;

• бухгалтерская или ERP-система ведёт финансовые проводки, расчёты и регламентированную отчётность.

Это не временный компромисс и не признак незавершённой автоматизации, а нормальная архитектура: разные системы могут быть главными источниками для разных данных (Systems of Record, SoR). Бизнесу не нужна одна программа, которая «главнее» всех остальных, — важно чётко определить, какая система отвечает за каждый тип данных.

System of Record и Single Source of Truth — не одно и то же

Термин Единый источник данных (Single Source of Truth (SSOT)) часто понимают слишком буквально: как требование хранить все данные в одной программе. Из-за этого аналитическую задачу пытаются решить заменой операционных систем.

System of Record отвечает на вопрос: где данные создаются и поддерживаются в актуальном состоянии?

Source of Truth отвечает на другой вопрос: откуда следует брать данные для конкретного решения?

Например, CRM знает имя клиента, его контакты и ответственного менеджера. Бухгалтерская система знает выставленные счета и оплаты. Сервис поддержки хранит обращения. Ни одна из этих систем не содержит полного представления о клиенте, хотя каждая остаётся авторитетной в своей области.

Чтобы рассчитать прибыльность клиента, данные можно объединить в хранилище или аналитической платформе. Там появится согласованное представление, пригодное для отчётов. Но хранилище не должно превращаться в место, где менеджер редактирует номер телефона, а бухгалтер проводит оплату. Операции остаются � исходных системах.

Следовательно, единый источник правды для отчётности не равен единственной программе для всей компании.

Как выглядит распределённая архитектура на практике

Представим компанию с магазинами, интернет-заказами и программой лояльности.

Покупка на кассе создаётся в POS-системе. Именно касса хранит первичную запись о продаже: состав чека, скидки, способ оплаты и время операции.

После продажи информация передаётся в другие системы:

• склад уменьшает доступный остаток;

• CRM добавляет покупку в историю клиента;

• ERP получает данные для финансового учёта;

• аналитическое хранилище использует чек при расчёте выручки, маржи и эффективности акции.

Копии записи могут существовать во всех этих системах. Но исправлять исходный чек разрешено только там, где он был создан. Остальные системы получают обновление через интеграцию.

Тот же принцип действует для остатков. Сайт может показывать доступность товара, но не должен самостоятельно назначать фактическое количество на складе. Его задача — получить актуальное значение из складской системы или из специально рассчитанного контура доступности.

Так архитектура перестаёт быть набором программ и превращается в карту ответственности.

Эта таблица важнее формального назначения «главной программы». Она показывает, какой системе можно доверять в каждом конкретном вопросе.

Обмен данными не должен быть одинаковым для всех процессов

Распределённая архитектура не означает, что каждую систему нужно связать со всеми остальными в реальном времени.

Способ обмена зависит от того, для чего нужны данные и насколько допустима задержка.

• Оформленный заказ и изменение доступного остатка обычно нужно передавать сразу или с минимальной задержкой.

• Каталог товаров, справочники или данные для финансовой сверки часто можно обновлять по расписанию.

• Данные для аналитики обычно собирают из рабочих систем в отдельном хранилище. Там их объединяют и приводят к единому виду, чтобы строить отчёты и анализировать историю. Для текущих операций, например резервирования товара при оформлении заказа, такое хранилище не используют.

Если систем немного и правила обмена между ними редко меняются, их можно связать напрямую. Когда появляются новые каналы продаж, партнёры и многочисленные потоки данных, такими связями становится трудно управлять. Тогда обмен выносят в отдельный интеграционный слой: он передаёт данные между системами, приводит их к нужному формату и позволяет отслеживать и повторно запускать неудачные операции.

Но интеграционный слой — это ещё одна система, которую нужно обслуживать и защищать. Если он спроектирован неудачно, сбой может остановить обмен сразу между несколькими системами, а любое изменение будет требовать лишнего времени и затрат.

Когда несколько систем становятся проблемой

Несколько систем становятся проблемой, когда сотрудники перестают понимать, данным из какой программы можно доверять, и начинают сверять их вручную. Одного и того же клиента заводят несколько раз, остатки на сайте не совпадают со складом, заказ не доходит до кассы или учётной системы, а разные отделы получают разные показатели.

Обычно причина не в количестве программ, а в отсутствии правил. Компания должна определить:

• какая система отвечает за клиентов, товары, заказы, остатки и платежи;

• где эти данные можно изменять, а где хранится только их �опия;

• как записи об одном клиенте, товаре или заказе сопоставляются между системами;

• насколько быстро должны передаваться изменения;

• кто и как узнаёт об ошибке при обмене данными.

Даже при настроенном обмене данные нужно периодически сверять. Это помогает вовремя заметить пропущенные заказы, расхождения в суммах и неверные остатки.

Если правила определены, несколько систем могут работать устойчиво. Если же ручные сверки занимают всё больше времени, ошибки влияют на продажи, а подключение каждого нового канала превращается в отдельный сложный проект, архитектуру пора пересматривать. Но это ещё не означает, что все программы обязательно нужно заменить одной.

Почему перенос всего в одну платформу не гарантирует порядок

Единая платформа может сократить количество внутренних интеграций и упростить работу с данными. Но она не устраняет внешние системы: сайт, банки, маркетплейсы, службы доставки и другие сервисы всё равно придётся подключать отдельно.

Не решит новая платформа и накопившиеся противоречия в данных. Перед переносом нужно удалить дубли, привести к общему виду справочники, согласовать статусы и определить, какая информация считается правильной. Без этого старый беспорядок просто переедет в новую систему.

Кроме того, универсальная платформа не всегда одинаково хорошо поддерживает продажи, склад, работу с клиентами и онлайн-каналы. Недостающие возможности придётся дорабатывать или закрывать отдельными сервисами — и интеграции появятся снова.

Поэтому консолидация полезна не сама по себе. Она оправданна, когда сокращает реальные издержки и упрощает процессы, а не просто уменьшает количество программ.

Когда единая платформа всё-таки оправданна

Отказываться от централизации как принципа тоже было бы ошибкой. Она полезна, когда решает конкретную проблему.

Единая ERP может быть оправданна, если:

• несколько программ дублируют одни и те же функции;

• финансовые, складские и закупочные процессы требуют постоянной ручной сверки;

• действующие системы больше не поддерживаются или не имеют пригодных интерфейсов;

• процессы достаточно стандартны и укладываются в модель новой платформы без масштабных дора�оток;

• стоимость текущих интеграций и исправления ошибок выше стоимости консолидации;

• компания готова не только установить программу, но и пересмотреть процессы, очистить данные и обучить сотрудников.

При этом внедрение ERP не означает, что все остальные системы нужно заменить. ERP может быть ядром финансов и операций, CRM — управлять продажами, сайт — клиентским опытом, а хранилище — аналитикой. Централизация одной области не требует централизации всех остальных.

С чего начинать

Не с выбора новой CRM или ERP. Сначала нужно составить реестр данных и процессов.

Сначала нужно разобраться, как компания работает с информацией о клиентах, товарах, ценах, заказах, остатках и платежах. Для каждой группы важно ответить на несколько вопросов:

1. Где она создаётся.

2. Какая система отвечает за её актуальность.

3. Какие поля разрешено изменять в других системах.

4. Куда и с какой задержкой передаются изменения.

5. По какому идентификатору записи сопоставляются.

6. Что происходит при ошибке или конфликте.

7. Откуда показатель берётся для оперативной работы и откуда — для аналитики.

После такого разбора становится понятно, где именно возникает проблема и насколько серьёзные изменения нужны. Иногда достаточно наладить обмен между двумя программами и определить, в какой из них должны обновляться данные. В других случаях потребуется отдельное решение для обмена или отчётности. Заменять все системы одной платформой стоит только тогда, когда это действительно дешевле и надёжнее.

Важно не то, насколько просто всё выглядит на схеме. Важно, чтобы сотрудники понимали, где искать нужные данные, системы правильно передавали их друг другу, а ошибки не оставались незамеченными.

Компании не нужна программа, которая знает всё. Нужно, чтобы всегда было понятно, какая система отвечает за конкретные данные и как они попадают туда, где необходимы.