Привет, Хабр! Мы — Константин Архипов и Татьяна Базанкова, руководители проектов в МТС Digital и МТС соответственно (да, это разные компании в одной экосистеме). Мы расскажем о личном опыте разработки и внедрения электронного документооборота с подписанием документов простой электронной подписью (ПЭП) для логистики. Перечислим продукты, которые нам понадобились в процессе, поговорим о возникших трудностях, способах их преодоления и дадим советы тем, кто намерен внедрить такой тип документооборота.
Для тех, кто предпочитает смотреть видео, а не читать текст — статья доступна на YouTube.
Среди современных WMS‑ и ERP‑систем, используемых на складах, электронный документооборот (далее — ЭДО) рассматривается как дополнительная опция и часто даже не упоминается в обзорах таких систем. Производители рассматривают ЭДО как «черный ящик», куда посредством коннекторов, API или вообще вручную, можно отправить документ, а контрагент его получит. Как на почте: мы приходим в отделение, отправляем письмо, а что будет с ним дальше — это уже зона ответственности почты.
Но это слишком упрощенное понимание ЭДО. Всю ответственность производители WMS‑ и ERP‑систем перекладывают на операторов ЭДО, которых в России несколько. На слуху продукты Диадок, СБИС, Калуга Астрал, Корус и другие. При работе с внешними операторами ЭДО оператор склада и его партнеры вынуждены переходить на подписание документов усиленной квалифицированной электронной подписью (далее — УКЭП). Однако, не для всех логистических операций УКЭП удобна, так как для нее нужен носитель УКЭП и устройство, к которому этот носитель необходимо подключать. В некоторых случаях проще использовать простую электронную подпись (ПЭП), но тогда сама WMS‑ или ERP‑система должна быть готова к работе с таким видом подписания.
Справка
УКЭП или усиленная квалифицированная электронная подпись — это электронный аналог подписи от руки. Документ, подписанный УКЭП, равнозначен собственноручно подписанному. УКЭП — это файлы, в которых хранится зашифрованная информация, подтверждающая вашу личность и подлинность подписанного документа. Для использования УКЭП нужен носитель, на который будет записана подпись: флешка, токен или другие хранители. Кроме того, при использовании нужно устройство, куда этот носитель можно подключить.
ПЭП — это обычный пароль, код, который только подтверждает личность создателя документа или пользователя сервиса. Примеры — пин‑код банковской карты или пароль, который можно установить для открытия документа Word.
В рамках экосистемы МТС мы работаем с несколькими внешними операторами ЭДО. В целом уровень автоматизации для ЭДО достаточно высокий, чтобы мы попробовали поискать себе новые кейсы и заказчиков на просторах экосистемы. В конце 2019 года к нам пришли коллеги из Блока управления закупками и предложили достаточно простой, на первый взгляд, кейс перевода на ЭДО складских документов: накладных на отгрузку товаров со склада подрядчику по форме М-8 и М-15, где УКЭП не подходил.
Справка
М-8 — это накладная на отгрузку оборудования в монтаж, М-15 ‑накладная на внутреннее перемещение для сторонних организаций.
Мы поставили перед собой амбициозную задачу — реализовать внутренний ЭДО для этих документов на основе ПЭП с низким порогом вхождения контрагентов. Метрикой данного проекта стал процент контрагентов, которые перейдут на ЭДО складских документов в течение календарного года после запуска в эксплуатацию.
Наш рассказ будет о том, с какими вопросами и проблемами можно столкнуться при реализации подобной задачи.
Постановка задачи
На момент старта проекта у нас уже был внутренний ИТ‑продукт DocFlow, интегрированный со многими продуктами экосистемы МТС. DocFlow может получать первичные документы от 8 биллинговых систем МТС, документы от персональных менеджеров, которые работают в двух CRM‑системах. Для всех этих документов мы можем фиксировать факт подписи с помощью ПЭП и с помощью операторов ЭДО — УКЭП. Подписанные нашим продуктом документы отправляем в собственный электронный архив.
Кейс
При выдаче оборудования со складов ответственного хранения (далее — СОХ) для строительства сети МТС подрядчиками подписывались формы М-8 и М-15. Задача была такая — перевести формы М-8 и М-15 на ЭДО, чтобы экспедитор в момент получения оборудования со склада подписывал документы от имени подрядчика электронной подписью (далее — ЭП) без получения ключа УКЭП.
Верхнеуровневая оценка
Предварительное решение казалось простым и быстро реализуемым. Вместо бумажных форм мы даем экспедитору подписать электронную версию документов. Варианты подписания УКЭП в данном случае не подходили, так как тогда каждый экспедитор должен иметь свой электронный ключ подписи. Как минимум это неудобно и «стоимость вхождения» в такой бизнес‑процесс будет слишком большой.
Решили остановиться на ПЭП. Это самая простая подпись, которая фиксируется нажатием одной кнопки — «Согласен», «Ок» или «Подписать». Факт подписания должен фиксировать наш продукт и формировать после этого файл ЭП. Кроме того, для визуализации факта подписания на самом электронном документе должны были проставляться плашки ЭП со стороны сотрудника СОХ и со стороны подрядчика.
Ценность проекта
Перед стартом проекта мы задумались над тем, какой будет эффект от перевода форм М-8 и М-15 на ЭДО.
Первое, что мы решили посчитать — это экономический эффект от прямой экономии бумаги, сокращению затрат на печать и пересылку документов, организацию, каталогизацию и утилизацию бумаг в архиве. В связи с тем, что сумма капитальных затрат была высокой, а объемы отправок документов — средние, срок окупаемости проекта составил примерно 5 лет.
Второе — экономический эффект от непрямых затрат. Например, от повышения лояльности контрагентов и СОХ при использовании ЭДО, от сохранности всех документов в собственном электронном архиве, возможности для компании подрядчика просматривать пакет документов подписанный с двух сторон на нашей витрине и так далее.
Третье — возможность масштабирования концепции внутреннего ЭДО на основе ПЭП на другие продукты экосистемы МТС, например на складскую форму ТОРГ-12.
Именно совокупная эффективность всех трех эффектов стала предпосылкой для реализации проекта.
Исследование вопроса
После постановки задачи мы провели анализ и при общении с заинтересованными сторонами поняли, что объем требуемого функционала увеличился, как и задействованные роли в командах. Были выявлены следующие требования:
Требование № 1. Заказчик со стороны бизнеса потребовал подписание через код в СМС. В этом плане есть ошибочное мнение, что код из СМС для ПЭП более правильный и безопасный, чем просто нажатие кнопки «Да» или аналогичной сценарий. На самом деле для ПЭП все варианты одинаковы и код из СМС — это только моральное спокойствие и удовлетворение для заказчиков проекта, на что мы и согласились. Для подписания через СМС мы привлекли внутренний продукт «МТС Маркетолог».
Требование № 2. Юридическая служба потребовала, чтобы с каждым контрагентом было заключено доп. соглашение с описанием всех принципов работы ПЭП.
Требование № 3. Представители СОХ потребовали подробное «Руководство пользователя», даже при условии, что весь интерфейс предполагался интуитивно понятным. Юридическая служба такое требование поддержала и попросила включить «Руководство пользователя» в дополнительное соглашение с контрагентом. Для решения вопросов с интерфейсом мы провели UX/UI исследования с кладовщиками СОХ на прототипах, которые отрисовал наш дизайнер в FIGMA.
Требование № 4. Заказчик проекта попросил показывать электронные формы экспедитору, чтобы он смог сверить содержание формы и самой поставки с СОХ. Это требование вылилось в согласование со службой информационной безопасности. Как мы будем показывать внутренний документ МТС экспедитору во внешней сети? Из контактов экспедитора у нас есть только номер телефона. Значит, мы можем только отправить ему SMS. Что можно отправить по SMS? Ссылку на документ! Но только короткую. А для короткой ссылки нужны интеграция с соответствующим внутренним продуктом экосистемы.
В результате мы приняли решение, что показывать электронную форму можно только до подписания экспедитором. После подписания на электронном документе уже стоит плашка подписи с персональными данными. Поэтому отправлять ссылку на внешний номер телефона (то есть не защищенную сеть без авторизации) с уже подписанным документом нельзя.
У разработчиков совместно с представителями бизнеса возникли сомнения — с каким телефоном приезжает экспедитор, как проверяет состав заказа при отгрузке и другие детали? Провели UX/UI исследования «в полях» — на СОХ в Московской области и на Дальнем Востоке. В результате мы выяснили интересные факты. На московских складах экспедиторы всегда разные, объем отгрузки большой и заказ комплектуется заранее. Экспедитор проверяет состав отгрузки только по грузовым местам. При наличии расхождения уже после перевозки составляется претензия.
А вот на складе на Дальнем Востоке объемы меньше, экспедитор от подрядчика всегда один и тот же. Есть возможность досконально сверить весь заказ по позициям перед отгрузкой согласно документам. Это исследование дало нам много информации, но практически не дало системных знаний, кроме одного — экспедиторы в большинстве случаев приезжают со смартфонами и открыть электронный документ на смартфоне смогут.
А что делать, если экспедитор приедет с кнопочным телефоном? В этом случае М-8/М-15 предоставит для сверки кладовщик на СОХ: на компьютере в офисе, на планшете при сверке позиций или в крайнем случае на бумаге.
Требование № 5. Необходимо вместе с формами М-8 и М-15 перевести на ЭДО доверенности, так как в электронный архив необходимо передавать весь комплект документов, и бумажная доверенность не встраивается в новый процесс. Для работы с доверенностями представителей подрядчиков понадобилась «витрина» или интерфейс, который доступен из внешней сети.
Такая витрина для работы с партнерами у МТС есть — Портал Партнерских Отношений, но вот работать с доверенностями она не умела. Был спроектирован бизнес‑процесс работы с доверенностями для контрагентов и также интерфейс для складских работников СОХов для работы как с доверенностями, так и с формами М-8 и М-15.
На первом этапе мы решили поддерживать в электронном виде только генеральные доверенности. Подрядчик может оформить на витрине доверенность на своего экспедитора, а также отредактировать и отозвать ее. Последующие этапы внедрения процесса будут включать поддержку доверенностей по форме М-2 и машиночитаемых доверенностей (МЧД).
В результате перечень систем, задействованных в проекте, увеличился, и решение стало выглядеть так:
В качестве итога нашего проекта мы можем сказать следующее:
создать собственный внутренний ЭДО реально, но это потребует большого количества интеграций с другими продуктами ландшафта и подключение команды юристов. В нашем кейсе мы сделали интеграцию с 6 продуктами. При этом продуктов «с нуля» не было разработано ни одного. Мы переиспользовали возможности существующих продуктов экосистемы и дорабатывали только три продукта из шести;
нужна отдельная интеграционная команда, куда будет входить минимум руководитель проекта, аналитик и архитектор. Эта же команда будет отвечать за новый процесс в целом и драйвить смежные команды;
нужна более реалистичная оценка проекта. Достаточно много времени потребовалось на интеграционное тестирование, настройки на продуктовой среде и пилотные отгрузки. При оценке проекта эти затраты учитывались, но по факту оказались недостаточными.
В качестве планов на будущее мы хотим реализовать процесс массового подписания документов и расширить сферу применения процесса на дочерние компании.
Спасибо за уделенное статье время! Если у вас есть вопросы, замечания или истории из личного опыта про переход на ЭДО — ждем вас в комментариях!
