Интеграционная платформа для управления сервисным циклом 1,7 млн платежных терминалов по всей России

«Инженерный стапель» – российская технологическая компания, работающая с платежной инфраструктурой: банковскими терминалами, онлайн-кассами и другими устройствами для приема платежей. Масштаб бизнеса заказчика – 1,7 млн произведенных и поставленных устройств, а его решения ежедневно используются миллионами людей.

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

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

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

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

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

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

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

Отдельное внимание требовалось уделить массовой работе с данными. Оборудование поступает партиями, поэтому система должна поддерживать работа по API, а также массовый импорт и экспорт XLSX/CSV, фильтрацию, сортировку и пакетную обработку записей. Для пользовательских интерфейсов отдельно предусматривалась работа с массивами порядка 500 тыс. записей оборудования.

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

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

Проект изначально создавался с расчетом на промышленную эксплуатацию: работа 24×7 и потенциально до нескольких миллионов сервисных заявок в системе.

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

Мы разработали iSTAPEL как отдельную интеграционную платформу между корпоративной CRM сервисного центра и внешней информационной системой банка.

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

Сквозной сервисный цикл

В основе платформы лежит последовательная модель движения оборудования по сервисному процессу.

Когда устройство направляется в сервис, iSTAPEL получает данные из внешней системы и создает запись. После физической приемки информация фиксируется в CRM, выгружается и загружается в iSTAPEL, после чего платформа передает подтверждение во внешний контур.

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

В итоге для каждой единицы оборудования система понимает, на каком этапе она находится:

передано в сервис → принято → диагностировано → ремонт согласован или отклонен → отремонтировано → подготовлено к возврату → возвращено

Так iSTAPEL стал не просто транспортом для API-запросов, а системой, которая управляет состоянием оборудования между двумя независимыми информационными контурами.

Рабочий интерфейс для сервисного подразделения

Интерфейс платформы построили вокруг реальной логики работы сотрудников.

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

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

Сотруднику не нужно разбираться в технических методах API и внутренних кодах обмена. Платформа переводит технические состояния интеграции в понятную логику сервисного процесса.

Массовая обработка оборудования

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

Мы реализовали массовый импорт и экспорт данных через XLSX и CSV, фильтрацию, сортировку и пакетную обработку записей.

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

Это позволяет выявить ошибочные данные до того, как они попадут во внешний контур.

Интерфейсы проектировались с учетом работы с массивами в сотни тысяч записей, а архитектура хранения – с расчетом на несколько миллионов сервисных заявок.

Контроль проблемных и зависших процессов

Отдельной частью решения стала система контроля отклонений.

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

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

Для разных этапов используются собственные временные правила контроля.

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

Работа с партиями и актами

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

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

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

Это позволило работать не только с отдельными серийными номерами, но и с партиями оборудования как с самостоятельными бизнес-объектами.

Поддержка реальных сценариев ремонта

В процессе ремонта идентификаторы оборудования могут изменяться.

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

Мы предусмотрели эти сценарии в модели данных и процессе возврата оборудования.

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

Надежный интеграционный контур

Для всех взаимодействий с внешней системой реализовано журналирование.

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

Отдельно журналируются изменения данных внутри платформы.

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

Архитектура и эксплуатация

iSTAPEL реализован как самостоятельное веб-приложение на 1С-Битрикс/Laravel.

Для промышленной эксплуатации предусмотрены HTTPS, фоновые задачи, резервное копирование, документирование API и работа в режиме 24×7.

Интеграционная логика выделена в отдельный слой, поэтому дальнейшее развитие интерфейсов и бизнес-процессов не требует вмешательства непосредственно в CRM сервисного центра.

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

В результате проекта для «Инженерного стапеля» была создана самостоятельная интеграционная платформа iSTAPEL, которая связала внутреннюю CRM сервисного центра с внешней банковской системой и сформировала единый цифровой контур управления сервисным циклом платежного оборудования.

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

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

Для работы с большими объемами оборудования реализованы массовые операции, импорт и экспорт XLSX/CSV, фильтрация, сортировка и группировка записей по партиям и актам. Интерфейсы проектировались с учетом массивов порядка 500 тыс. записей, а архитектура системы – с потенциальным объемом до нескольких миллионов сервисных заявок.

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

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

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

В итоге iSTAPEL стал не просто API-интеграцией, а полноценным операционным инструментом сервисного бизнеса: единым цифровым слоем, который связывает две независимые информационные системы, контролирует состояние оборудования и помогает управлять сервисным процессом в масштабе сотен тысяч и миллионов записей при работе 24×7.