Новый взгляд на традиционный подход к построению статусной модели

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

Является ли такой подход универсальным и применимым в любой ситуации? Гарантирует ли он отсутствие необходимости вмешательства команды разработки в процесс движения объекта по статусам? К сожалению, есть ситуации, когда классическая модель не подходит. В этой статье расскажу о другом подходе к построению статусной модели и его особенностях.

Рассмотрим довольно широко распространенную ситуацию на рынке: вы разработали для заказчика (например, сети магазинов розничной торговли) мобильное приложение с возможностью оформления заказа на самовывоз. Но в скором времени планируется добавить возможность оформления заказа с доставкой на дом. У клиента нет собственной службы доставки, для оказания данной услуги будут привлекаться партнеры.

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

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

Как видно на рисунке выше:

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

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

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

• поддержка нескольких процессов обработки заказа будет существенно дороже, чем поддержка единого процесса для всех партнеров;
• риск ошибки кратно возрастает, так как каждый процесс подразумевает не только движение заказа по статусной модели, но и реализацию бизнес-логики внутри приложения;
• подключение нового партнера потребует существенных затрат по времени и финансам, так как необходимо будет реализовать еще одну полноценную интеграцию;
• курьерские службы тоже развивают свои ИТ-системы. Их статусная модель может со временем меняться, что приведет к необходимости изменения статусной модели в приложении.

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

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

• немец сообщит о получении заказа в точке сети и о его передаче клиенту, а в случае задержки всегда предупредит о причине и времени;
• итальянец дополнительно расскажет все, что произошло с ним по дороге, заодно поинтересуется, как дела у оператора;
• француз же не заметит опоздания, но обязательно в первом сообщении поздоровается и пожелает хорошего дня.

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

Поскольку часть sms-сообщений не будет иметь к заказу никакого отношения, если оператор будет фиксировать на листе учета заказов все полученные сообщения, он очень быстро запутается. Если позвонит клиент и спросит: “Где сейчас находится мой заказ?”, оператору придется пролистать переписку, чтобы найти сообщение, касающееся именно заказа. Поэтому необходимо фильтровать сообщения, которые курьеры присылают оператору.

А на листке учета заказов фиксировать только важную информацию.

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

Для того, чтобы решить задачу нам остается только:

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

Предлагаемый подход имеет ряд преимуществ перед классическим подходом к построению статусной модели:

• поддержка единой модели для всех партнеров обойдется заказчику гораздо дешевле;
• подключение нового партнера займет гораздо меньше времени, так как достаточно произвести базовую интеграцию;
• в случае изменения статусной модели партнера внесение изменений в статусную модель в приложении потребует минимум времени (конечно, если изменения не затрагивают важные для приложения статусы в системе партнера, но это происходит крайне редко). Главное – настроить систему уведомлений администратора о получении от системы курьерской службы статуса, которого ранее не было;
• но самое главное, предлагаемый подход позволяет расширять статусную модель приложения индивидуально для каждого партнера без необходимости ее переработки.

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

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

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

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

Если у вас тоже есть подобный опыт, поделитесь, пожалуйста, в комментариях.