Новый взгляд на традиционный подход к построению статусной модели
Аналитики, как правило, представляют статусную модель любого объекта в виде графа. В его вершинах находятся статусы, ребра показывают возможные переходы между статусами, а ориентация ребер показывает направление перехода.
Является ли такой подход универсальным и применимым в любой ситуации? Гарантирует ли он отсутствие необходимости вмешательства команды разработки в процесс движения объекта по статусам? К сожалению, есть ситуации, когда классическая модель не подходит. В этой статье расскажу о другом подходе к построению статусной модели и его особенностях.
Задача
Рассмотрим довольно широко распространенную ситуацию на рынке: вы разработали для заказчика (например, сети магазинов розничной торговли) мобильное приложение с возможностью оформления заказа на самовывоз. Но в скором времени планируется добавить возможность оформления заказа с доставкой на дом. У клиента нет собственной службы доставки, для оказания данной услуги будут привлекаться партнеры.
Для снижения тарифов на доставку и риска попадания в зависимость от конкретного партнера, клиент принял решение заключить договор сразу с несколькими курьерскими службами. Как итог: команде разработки необходимо реализовать несколько интеграций с системами курьерских служб.
После изучения процессов обработки заказов курьерскими службами заметим, что бизнес-процесс обработки заказа у каждого партнера имеет существенные отличия.
Как видно на рисунке выше:
- один партнер сам определяет список точек сети, из которых он сможет доставить заказ, а другой ожидает, что точка сети определяется магазином самостоятельно и передается в заявке на доставку;
- один партнер при получении заявки сразу приступает к поиску курьера, а другому партнеру для поиска курьера требуется дополнительное подтверждение заявки магазином;
- один партнер предусматривает возможность отмены заказа магазином после передачи заказа курьеру, а другой – нет.
Различия в бизнес-процессах, естественно, оказывают влияние на статусную модель заявки в системе курьерской службы. Поэтому у каждой курьерской службы статусная модель будет своя:
Первое решение, которое приходит в голову, это разработка статусной модели заказа в приложении индивидуально для каждого партнера по доставке. Очевидно, что такой подход довольно рискованный и вот почему:
- поддержка нескольких процессов обработки заказа будет существенно дороже, чем поддержка единого процесса для всех партнеров;
- риск ошибки кратно возрастает, так как каждый процесс подразумевает не только движение заказа по статусной модели, но и реализацию бизнес-логики внутри приложения;
- подключение нового партнера потребует существенных затрат по времени и финансам, так как необходимо будет реализовать еще одну полноценную интеграцию;
- курьерские службы тоже развивают свои ИТ-системы. Их статусная модель может со временем меняться, что приведет к необходимости изменения статусной модели в приложении.
А есть другие варианты?
Давайте попробуем абстрагироваться немного от нашей задачи и представим, что нет никакого приложения, все заказы принимает оператор по телефону. Доставляют заказы несколько курьеров-иностранцев, о ходе процесса доставки они сообщают с помощью коротких sms-сообщений на родном языке. Учет заказов и их актуальный статус оператор ведет на листке бумаги.
В зависимости от особенностей национальной культуры, личных качеств и темперамента оператор будет получать от курьеров совершенно разную информацию. Например:
- немец сообщит о получении заказа в точке сети и о его передаче клиенту, а в случае задержки всегда предупредит о причине и времени;
- итальянец дополнительно расскажет все, что произошло с ним по дороге, заодно поинтересуется, как дела у оператора;
- француз же не заметит опоздания, но обязательно в первом сообщении поздоровается и пожелает хорошего дня.
Первая проблема, которую нужно решить, это перевод текста sms-сообщений на русский язык. Чтобы не переводить каждое сообщение, создадим справочник, отображающий текст сообщения от курьера и его перевод на русский язык. При получении sms-сообщения оператор сверит его текст со справочником. Если перевод отсутствует, значит, курьер сообщил новую информацию. Ее необходимо перевести и добавить в список сообщений. Для всех курьеров справочник должен быть единым, ведь совершенно не важно, кто из них сообщил о вручении заказа клиенту – немец или француз.
Поскольку часть sms-сообщений не будет иметь к заказу никакого отношения, если оператор будет фиксировать на листе учета заказов все полученные сообщения, он очень быстро запутается. Если позвонит клиент и спросит: “Где сейчас находится мой заказ?”, оператору придется пролистать переписку, чтобы найти сообщение, касающееся именно заказа. Поэтому необходимо фильтровать сообщения, которые курьеры присылают оператору.
А на листке учета заказов фиксировать только важную информацию.
Кажется, я все понял!
Курьеры-иностранцы – это партнеры по доставке, а sms-сообщения, которые они присылают оператору – это статусы заявки на доставку, которые наше приложение получает от систем курьерских служб. Оператор, принимающий заказы – это и есть наше приложение.
Для того, чтобы решить задачу нам остается только:
- определить статусную модель заказа внутри приложения;
- проанализировать статусные модели заявок на доставку в системах партнеров и выбрать из них важные для приложения;
- разработать справочник соответствий статусов заказа в системах курьерских служб статусам заказа внутри приложения.
Предлагаемый подход имеет ряд преимуществ перед классическим подходом к построению статусной модели:
- поддержка единой модели для всех партнеров обойдется заказчику гораздо дешевле;
- подключение нового партнера займет гораздо меньше времени, так как достаточно произвести базовую интеграцию;
- в случае изменения статусной модели партнера внесение изменений в статусную модель в приложении потребует минимум времени (конечно, если изменения не затрагивают важные для приложения статусы в системе партнера, но это происходит крайне редко). Главное – настроить систему уведомлений администратора о получении от системы курьерской службы статуса, которого ранее не было;
- но самое главное, предлагаемый подход позволяет расширять статусную модель приложения индивидуально для каждого партнера без необходимости ее переработки.
И что, никаких подводных камней?
Предлагаемый подход не дает нам гарантию отсутствия ошибок при движении заказа по статусной модели, равно, как и классическая модель.
Независимо от того, какой подход вы используете, ошибки возникают не из-за наличия/отсутствия связей между статусами, а в случае некорректно настроенной бизнес-логики, выполняемых проверок и правил движения заказа от статуса к статусу.
Заключение
Навык абстрагирования – это один из ключевых навыков аналитика. Он позволяет взглянуть на задачу под совершенно другим углом и найти нестандартное, но эффективное решение задачи.
В данном случае мы отказываемся от стандартного понимания статусной модели как графа и смотрим на нее как на справочник, в котором устанавливается соответствие статуса объекта вашей системы статусам объектов в других системах. Движение заказа по статусной модели обеспечивается выполнением проверок и правил, которые должны выполняться при присвоении объекту определенного статуса, а не связями между статусами внутри самой модели.
Если у вас тоже есть подобный опыт, поделитесь, пожалуйста, в комментариях.