Изменения в законодательстве или требования внешних систем могут затронуть сразу несколько продуктов компании. При этом работать часто приходится в условиях жестких сроков и зависимости от внешних участников. С такой задачей мы столкнулись при подготовке систем S7 к расчетам цифровым рублем.
Рассказываем, как мы определили необходимый объем доработок, выстроили сквозной процесс и организовали работу нескольких продуктовых команд в условиях внешней зависимости.
Что меняется с появлением цифрового рубля
С 1 сентября компании, которые попадают под требования законодательства, должны предоставить клиентам возможность рассчитываться цифровыми рублями. Для S7 это означает появление еще одного способа оплаты авиабилетов и других услуг.
Сам платеж проходит не в системах заказчика. Покупатель сообщает кассиру, что хочет рассчитаться цифровыми рублями, получает на банковском терминале QR-код и сканирует его в приложении банка. Там он выбирает цифровой рубль как способ расчета и подтверждает операцию. После успешной оплаты банковский терминал получает подтверждение и печатает чек с идентификатором операции.
Задача наших систем начинается после этого. Нужно зафиксировать новый способ оплаты и идентификатор операции, провести продажу по кассе, сверить ее с банковскими данными и корректно отразить в бухгалтерском, финансовом и управленческом учете.
Почему нельзя просто добавить еще один способ оплаты
На уровне интерфейса изменение действительно небольшое: у кассира появляется новая форма оплаты. Но за ней стоит сквозной процесс, который проходит через несколько систем.
Smart Ticketing (терминал продаж), должен зафиксировать, что пассажир рассчитался цифровым рублем, и сохранить идентификатор операции. SCS (система для автоматизации продаж) — распознать эту форму оплаты, провести заказ по кассе, сформировать необходимые движения и затем сверить их с банковским отчетом. Sigma (учетная система) — правильно распознать новый способ оплаты в перевозочных документах и передать данные дальше в финансовый и управленческий учет.
Если изменить только одну из систем, цепочка не будет работать целиком. Поэтому анализировать такую задачу на уровне отдельных продуктов недостаточно: сначала нужно понять весь процесс, а уже затем определить изменения для каждого его участника.
Вторая особенность проекта — зависимость от банка. Требование о поддержке цифрового рубля было известно заранее, но конкретные детали реализации со стороны банка появились значительно позже. В результате у компаний оставалось гораздо меньше времени непосредственно на проектирование и разработку своих изменений.
Как мы выстроили работу над изменениями
Сначала определили обязательный минимум
Мы начали с анализа законодательных требований и ответственности за их нарушение. Это помогло определить, какие изменения должны обязательно заработать к установленному сроку, а какие можно внедрить позже.
Затем собрали сквозной сценарий расчета цифровым рублем — от выбора способа оплаты в кассе до отражения операции в учете. На каждом этапе определили участвующие системы, данные, которые между ними передаются, и точки зависимости от внешних участников.
Сняли зависимость от банка до завершения его разработки
Главным внешним ограничением была готовность банка. Ждать полного завершения банковской разработки означало терять время.
Поэтому мы не стали ждать готового решения целиком. После разбора процесса собрали конкретные вопросы, которые блокировали нашу часть работ: какой идентификатор будет использоваться для операции, в каком формате банк передаст данные о платежах и где этот идентификатор появится на терминале.
Ответы согласовали напрямую с представителями банка. Этого оказалось достаточно, чтобы зафиксировать точки интеграции и начать разработку в системах S7 параллельно с доработками на стороне банка.
Разложили один процесс на изменения в трех системах
После того как сквозной сценарий и внешние зависимости были понятны, мы описали изменения для каждого продукта и встроили их в планы трех команд с минимальным влиянием на текущую разработку.
Smart Ticketing
В Smart Ticketing нужно было поддержать новую форму оплаты «Цифровой рубль» и сохранение идентификатора операции. Мы встроили это в существующий сценарий работы кассира: после подтверждения платежа он выбирает новый способ оплаты и переносит идентификатор из банковского чека в систему.
SCS
Основной объем изменений пришелся на SCS. Система должна распознать новый способ оплаты, получить его из Smart Ticketing или позволить ввести вручную, сформировать новый тип безналичного движения и сохранить идентификатор операции.
Этот же идентификатор используется при сверке: банк передает S7 файл с операциями, а SCS сопоставляет их с проведенными продажами. Если данные расходятся, операция требует проверки. Кроме того, для цифрового рубля предусмотрен отдельный субсчет, поэтому SCS должен формировать соответствующие бухгалтерские проводки.
Sigma
В Sigma задача была другой: система получает данные из системы бронирования и должна корректно распознать новый способ оплаты, чтобы операция дальше правильно попала в финансовый и управленческий учет.
На момент подготовки статьи основная часть разработки по поддержке цифрового рубля завершена. Продолжаются работы в бэк-офисе, связанные с корректным бухгалтерским учетом таких операций.
Наши выводы
В проектах с обязательным сроком и внешними зависимостями мы придерживаемся трех правил:
- Сначала определяем обязательный минимум. Это позволяет не расширять объем работ там, где срок уже зафиксирован.
- Проектируем изменения на уровне сквозного процесса. Если в нем участвуют несколько систем, доработки каждой из них нельзя рассматривать отдельно.
- Снимаем внешние зависимости как можно раньше. Не обязательно ждать готовности внешней системы целиком — достаточно определить и согласовать данные, без которых нельзя начать разработку.
Такой подход помогает быстрее перейти от анализа к разработке и сохранить больше времени на сами доработки и их проверку. В случае с цифровым рублем это особенно важно: от получения необходимых данных от банка до обязательного запуска у команд S7 оставалось около трех месяцев.