Найдите процесс, который живёт в нескольких версиях
Подходящий кандидат обычно заметен по повторяющимся письмам, выгрузкам, актам расхождений и ручному сопоставлению идентификаторов. Поставщик считает обязательство выполненным, заказчик ещё не принял результат, перевозчик использует третий статус, а финансовая система каждой стороны строит собственную картину.
Зафиксируйте стоимость такого устройства: время на сверку, число спорных операций, задержку закрытия периода, объём ручных исправлений и длительность поиска доказательств. Эти показатели станут базовой линией проекта. Если расхождения редки и один доверенный оператор уже ведёт эталон, распределённый реестр, скорее всего, не окупится.
Создайте единый бизнес-объект
Не начинайте со структуры блоков. Опишите объект, который проходит через организации: заказ, поставку, партию, обязательство, сертификат или расчёт. У объекта должны быть стабильный идентификатор, допустимые состояния и формальные переходы между ними.
Для каждого перехода определите инициатора, подтверждающую сторону, минимальный набор доказательств и срок. Например, статус «принято» появляется не после сообщения поставщика, а после подтверждения заказчика либо наступления заранее согласованного условия. Такой жизненный цикл превращает разрозненные записи в общий процесс.
Разделите общий факт и закрытые данные
В общий реестр помещают минимум, необходимый для совместной проверки: идентификатор, состояние, время, стороны, хеш доказательства и подписи. Цены, персональные данные, договоры, сканы и внутренние комментарии остаются в системах участников или в закрытых коллекциях с ограниченным доступом.
Это важнее выбора конкретной платформы. Чем больше закрытой информации копируется между узлами, тем сложнее выполнять требования доступа, исправления, хранения и удаления. Реестр должен доказывать согласованное событие, а не становиться вторым корпоративным архивом.
Спроектируйте исключения до автоматизации
Реальный процесс включает частичную поставку, отказ, возврат, ошибочный статус, замену документа и спор. Неизменяемость означает, что ошибку нельзя молча переписать: её исправляют новой связанной записью с основанием и полномочиями.
Заранее определите кворум, срок ожидания, процедуру разногласий, аварийный режим и ответственность за исходные данные. Отдельно проверьте, кто может приостановить операции, обновить правила или исключить участника. Технический консенсус не заменяет договор управления сетью.
Интеграция должна быть идемпотентной
ERP, 1С, WMS и другие системы отправляют команды через интеграционный слой, который проверяет схему, назначает ключ идемпотентности, подписывает транзакцию и отслеживает подтверждение. Повтор после тайм-аута не должен создавать вторую поставку или оплату.
В бизнес-системе различаются состояния «отправлено», «принято сетью», «подтверждено требуемым кворумом» и «отклонено». Единый correlation ID связывает исходный документ, сообщение очереди, транзакцию и событие реестра.
Пилот измеряет устранённую сверку
Возьмите один объект, две-три стороны и ограниченный набор переходов. Не оценивайте пилот количеством транзакций. Сравните время закрытия процесса, число расхождений, долю автоматических подтверждений, стоимость расследования и срок получения доказательств.
Результатом должен стать не только работающий код, но и регламент участников, схема данных, модель ключей, журнал решений, сценарии отказа и расчёт полной стоимости эксплуатации. Только после этого можно понять, действительно ли общий реестр устраняет организационную задержку или лишь переносит её в новую технологию.