ФЗ-63 - о чем этот закон:
ФЗ-63 – это федеральный закон №63, в рамках которого нужно автоматизировать машиночитаемые доверенности (МЧД) и обеспечить подписание электронных документов с использованием КЭП физического лица (КЭП ФЛ) вместо КЭП юридического лица (КЭП ЮЛ).
Меня зовут Северов Михаил, и уже третий год я занимаюсь электронным документооборотом (ЭДО) в федеральной торговой сети «Лента». Сегодня я расскажу, как внедрение машиночитаемых доверенностей (МЧД) оказалось для нас шагом к импортозамещению в ЭДО и заодно помогло оптимизировать процессы управления разрозненным документооборотом.
Об импортозамещении все начали задумываться задолго до известных событий. Санкции, блокировка лицензий и отключение компаний РФ от известных западных сервисов вогнали последний гвоздь туда, где «лежал вопрос» – идти в эту историю или нет.
Но заявлять и делать – это разные вещи. Мало компаний готовы выложить миллионы просто потому, что надо пересаживаться со «старой и проверенной годами иномарки» на новенькую «Ладу».
![](https://habrastorage.org/getpro/habr/upload_files/da7/55f/d26/da755fd268a5d6fbcf01d7f02a6b86cb.png)
Препятствия на уровне компаний и проектов, «мешающие танцевать» в импортозамещение:
ИТ-бюджеты ограничены и уже распределены по бизнес-проектам;
бизнес не готов на повторное внедрение, апробацию и тестирование новой системы с нуля;
отсутствуют актуальные требования к системам;
мало кто понимает все подводные камни;
нет ресурсов, все заняты на других проектах;
сложность с экспертизой и профильными специалистами на рынке;
сомнения в выборе новых платформ: на словах все хороши, но на деле проверить это сложно;
если новая система не взлетит или не потянет нагрузку, кто примет на себя риски остановки бизнеса.
Каким же путем решили идти мы, чтобы поставить МЧД на рельсы импортозамещения
В общем, состав под названием «Импортозамещение ЭДО» ехал очень плохо, а временами даже откатывался назад. Когда мы приняли решение автоматизировать МЧД, опираясь на ФЗ-63, я подозревал, что часть «граблей» мы все-таки соберем. Расскажу о нашем пути по порядку.
Первая проблема: паровоз не заводится! Что делать?
Первым препятствием для меня стал собственно ФЗ-63 – абсолютно новый закон, в котором, увы, никто не разбирался. Важно было разобраться в ИТ-специфике, юридических аспектах, бизнес-процессах, а главное – прояснить общий «вижн» того, как это все можно спроектировать и подготовить ИТ-архитектуру.
![](https://habrastorage.org/getpro/habr/upload_files/db8/5bc/b83/db85bcb83068f9e65d3b8b14296f7979.png)
Совет: Начните с аудита ваших процессов
Да-да, это банально, но именно аудит позволил нам ответить на главные вопросы:
1. сколько процессов ЭДО у нас вообще существует;
2. кто является владельцем каждого процесса ЭДО;
3. где в этих процессах используется обязательное электронное подписание;
4. на какие группы можно разделить эти процессы по типам подписания;
5. на какие группы можно разделить эти процессы по типам бизнес-процессов.
Получив ответы на эти вопросы, мы составили реестр процессов ЭДО и удивились: первоначально мы предполагали, что процессов у нас плюс-минус 48 , но эта цифра вдруг стала расти и в итоге превратилась в 89 (почти удвоилась)!!!
Реестр стал для нас целым откровением: мы обнаружили новые процессы, и когда свели все в одну картинку, то поняли, что некоторые из них важно разделять или, наоборот, ликвидировать. Мы поняли реальный объем ЭДО в компании.
Совет: Определите ответственных за каждый процесс
Как ни странно, у многих процессов владельцы были лишь формально обозначены. При этом именно владелец должен не только отвечать за работу процесса, но и грамотно формировать требования к ней, отвечать за выделение ответственных сотрудников. Мы нашли и назначили реальных ответственных за каждый процесс.
В чем заключалась сложность для владельцев процессов ЭДО
Владельцы процессов должны были организовать поиск сотрудников, которые согласятся использовать свою личную КЭП ФЛ (Квалифицированная Электронная Подпись Физического Лица) при подписании документов. Если ранее закон позволял подписывать документы КЭП ЮЛ и ответственность за подписанный документ лежала на ЮЛ, то теперь, согласно ФЗ-63, нужно использовать личную подпись физического лица (со всеми вытекающими из этого рисками и последствиями).
Найти такого ответственного сотрудника было не так просто: надо, чтобы он согласился на использование своей личной КЭП ФЛ в процессах подписания документов компании. При этом, если такой сотрудник увольняется или меняет должность, нужно искать нового ответственного и запускать заново процесс получения им КЭП ФЛ, записывать ее на USB-токен, выпускать новую МЧД.
Для команды проекта и компании это был серьезный вызов, с которым пришлось разбираться вплоть до общения с первыми лицами и подготовки объясняющих презентаций. В результате мы смогли определить владельцев для всех процессов ЭДО – и это была первая важная контрольная точка нашего проекта! После этого настал черед проектирования ИТ-решения и создания архитектуры для автоматизации.
Вторая проблема: угля для паровоза понадобилось больше, чем вмещал сам паровоз
Первоначально мы решили просто доработать точки электронного подписания в тех системах, где они раньше выполнялись. Ну а что? Не нужно ломать то, что уже работает.
Однако, при погружении в специфику, я понял, что такой поход скрывает в себе определенные подводные камни и спрятанные грабли.
Проблема, как ни странно, находилась на стыке «Кадры-Процессы-ИТ». Дело в том, что сотрудники на местах меняются: увольняются или переходят на другие позиции внутри компании. То есть выделяя ключевого специалиста для подписания документов его КЭП ФЛ, ты должен выделить и резервного сотрудника с КЭП ФЛ, который готов моментально подменить коллегу на случай увольнений и различных нештатных ситуаций.
![](https://habrastorage.org/getpro/habr/upload_files/416/1d5/eae/4161d5eae878bb6e568af8f88b7b2d73.png)
Примеры инцидентов с токенами и КЭП ФЛ, которые могут остановить процессы ЭДО:
потерял токен с КЭП ФЛ;
3 раза неправильно ввел ПИН-код и токен заблокировался;
сломал токен с КЭП ФЛ;
заболел, не вышел на работу;
забыл токен дома;
внезапно решил уволиться;
отозвал свою КЭП ФЛ (ага, и такое может быть, для особо разбирающихся в этой области);
не обновил истекшую КЭП ФЛ (забыл, заболел).
Все эти ситуации приводили к тому, что процесс электронного подписания останавливается и приводит к остановке всего бизнес-процесса.
Теперь представим, что таких подписантов у нас, например, 5 000 человек. Для каждого нужно выделить еще 5 000 резервных подписантов, которые должны получить свою КЭП ФЛ и записать ее на токен. Итого - 10 000 человек.
Для всех этих сотрудников нужно обеспечить процессы поддержки:
выпуска КЭП ФЛ (куда идти, что делать, какие документы предоставлять);
использования КЭП ФЛ (как подписывать, что делать, если токен не читается);
перевыпуска КЭП ФЛ (если истек срок или произошла компрометация, или потерял);
выпуска МЧД (без машиночитаемой доверенности ты ничего не подпишешь);
доставки самих токенов в места их работы (практически по всей РФ);
отзыва МЧД (если сотрудник увольняется).
В результате всего этого накладные скрытые расходы начинали расти в геометрической прогрессии и стремиться в космос. Как же решить эту проблему?
Совет: Не пытайтесь автоматизировать задачу «в лоб»
Мне пришла в голову интересная мысль: а зачем вообще пытаться автоматизировать задачу в лоб? Лучше подумать над оптимизацией самих процессов электронного подписания и сократить количество самих подписантов. И мы нашли уникальное решение, которое лежало на стыке управления процессами и ИТ-архитектурой.
Оно заключалось в том, что типовые операции подписания можно вынести на сторону ОЦО (Общий Центр Обслуживания): нужно было выделить дежурных подписантов, которые будут подписывать документы своей КЭП ФЛ только после того, как эти документы акцептованы сотрудниками в системах с использованием ПЭП (Простой Электронной Подписи).
В этом случае не надо было держать армию из 10 000 подписантов (5 000 основных и 5 000 резервных) и обеспечивать их такой же армией сотрудников техподдержки, отправляя бесконечные коробки с токенами по всем уголкам РФ.
Мы просто договорились, что сотрудники на местах подтверждают документ в своей системе (т.е. с помощью ПЭП в виде подтверждения документа от имени авторизованного персонального аккаунта в системах). И только после этого такой акцептованный документ уходит в ОЦО, чтобы сотрудник ОЦО подписал его своей КЭП ФЛ.
Посчитав оптимизированный процесс, мы ОЧЕНЬ удивились: количество подписантов КЭП ФЛ удалось сократить с 5000 до 120 человек, т.е. в 80 раз!!!
Но это не все, теперь перед нами встала другая проблема, связанная с тем, что документы подписывались в разных системах.
Третья проблема: десятки одинаковых рычагов управления в кабине машиниста
Сотрудникам ОЦО приходилось бы в этом случае непросто: они вынуждены постоянно переключаться между десятком разных систем для подписания документов своей КЭП ФЛ. А учитывая, что некоторые из них должны подписываться в считанные минуты, из-за скорости человеческий фактор увеличивал количество ошибок. Не будем говорить и про уровень раздражения сотрудников от такой работы. Нужно было срочно искать решение проблемы.
Совет: переносите однотипные процессы в одну систему – единое окно удобнее, коллеги порадуются
Я придумал уникальное архитектурное решение, на которое мы вынесли повторяющиеся задачи подписания электронных документов и назвали его «ЭДО HUB».
В моей целевой концепции он становится единым оркестратором ЭДО с контрагентами и универсальной площадкой для централизации разрозненного документооборота, включая интеграцию с внешними сервисами и архивом налогового мониторинга.
Упрощенно целевая концепция ЭДО HUB выглядит так:
Все системы, в которых создаются документы, отправляют их в ЭДО HUB. Он, в свою очередь, отвечает за обеспечение процесса электронного подписания и взаимодействие с операторами ЭДО, блокчейном МЧД, облачными и партнерскими сервисами.
![Целевая концепция внедрения ЭДО HUB Целевая концепция внедрения ЭДО HUB](https://habrastorage.org/getpro/habr/upload_files/590/5c4/451/5905c4451141e641b6c5e6aaf1c195d7.png)
Смотрите, чем еще оказался полезен ЭДО HUB для процессов ЭДО:
проверки легитимности подписантов и благонадежности контрагентов;
проверки экономической безопасности в рамках контроля мошенничества;
повышение уровня информационной безопасности;
синергия и сокращение расходов в других проектах;
снятие части нагрузки с перегруженных ЭДО–систем и возможность «легче дышать»;
получение единой точки интеграции с Операторами ЭДО и узлами Блокчейн МЧД.
После того, как мы определились с концепцией и архитектурой, сразу приступили к выбору платформы автоматизации.
Начиная поиск платформы, я понимал, что от выбора будет зависеть успех всего проекта. Хотелось выбрать решение, которое, с одной стороны, позволяло бы держать нагрузку и выполнять масштабирование серверных ресурсов. А с другой – давало нам возможности конструктора для Low-code доработок, которые бы мы смогли выполнять своими силами.
Совет: не верьте сейлзам, которые рассказывают, что их платформа - лучшая
Вместо этого готовьте свою матрицу функциональных и нефункциональных требований, проводите скоринг самостоятельно.
На рынке было несколько таких платформ и, конечно, все вендоры заявляли, что их платформа самая крутая. Я же решил пойти путем собственного скоринга:
подготовил матрицу требований, которые предъявлялись к платформе. В нее вошли как функциональные, так и нефункциональные требования;
всего получилось 182 параметра, на основании которых выполнялся скоринг платформ-кандидатов;
помимо скоринга смотрели еще и на то, как быстро вендор поддерживает новые изменения законодательства, в частности - на наличие готовых решений для ФЗ- 63.
В результате по совокупности факторов для ЭДО HUB как ни странно лучше всего подошла платформа ЭЛМА365.
Справедливости ради стоит отметить, что аналогичные скоринги мы проводим и для других задач. Например, для кадрового электронного документооборота у нас была выбрана платформа Directum, а для электронного архива налогового мониторинга АИС Налог-3 лучше подошла платформа WSS.
Главный вопрос: а превратился ли наш паровоз в современный локомотив, и с какой скоростью он двигается сегодня?
Мы успешно запустили проект МЧД. ЭДО HUB, на базе которого выполняется подписание КЭП ФЛ, выдерживает нагрузку свыше 100 000 документов в день. При этом мы уже сейчас готовимся к тому, чтобы увеличивать эту нагрузку в 2 и даже в 3 раза.
![RoadMap развития ЭДО HUB в Lenta Tech RoadMap развития ЭДО HUB в Lenta Tech](https://habrastorage.org/getpro/habr/upload_files/9b0/75f/a93/9b075fa934182d26b88b1f1c456eb342.png)
Как архитектор решения, я сразу заложил в RoadMap ЭДО HUB ряд перспективных способностей:
универсальные переключаемые коннекторы к Операторам ЭДО;
визуализацию формализованных документов «как нам нужно», а не «как визуализируют операторы ЭДО»;
автодетект FRAUD (борьба с мошенничеством);
искусственный интеллект в задачах распознавания, классификации и обработки входящих документов;
универсальные инструменты подписания, как с использованием личной КЭП ФЛ, так и с обезличенной КЭП, выданной на систему;
умные очереди, позволяющие распределять пиковую нагрузку подписания во времени согласно приоритетам и тем самым экономить серверные ресурсы;
BPM-оркестратор процессов ЭДО, позволяющий настраивать собственные процессы в конструкторе в нотации BPMN;
интеграция с электронным архивом налогового мониторинга АИС Налог-3;
возможность запуска идеи «Виртуального секретариата ЭДО».
Помимо этого также стараемся активно развивать и связанные с ЭДО HUB системы:
отдельный сервис визуализации формализованных и неформализованных документов;
отдельный сервис массового пакетного подписания;
отдельный архив для налогового мониторинга АИС Налог-3.
Итак, подведу итог какие преимущества удалось получить за счет моего архитектурного решения, воплощенного в виде ЭДО HUB:
сократили в 80 раз количество подписантов в процессах ЭДО (с 5000 до 120);
избежали увеличения штата техподдержки для обеспечения процесса управления токенами, МЧД, электронными подписями;
снизили нагрузку на остальные системы (где ранее выполнялось подписание), давая им возможность легче "дышать" за счет того, что типовые операции подписания были перенесены в ЭДО HUB;
получили удобную платформу для централизации разрозненного документооборота (теперь мы можем в одном месте реализовывать новые идеи управления исходящим и входящим документооборотом с Контрагентами);
сократили в несколько раз первоначально оцененный бюджет проекта за счет того, что не пришлось делать доработки для МЧД и КЭП ФЛ во всех системах, где ранее выполнялось подписание документов;
получили идеальное место для дальнейшего внедрения процессов информационной и экономической безопасности (все потоки документов проходят через одну точку, которую проще и легче обезопасить и контролировать);
сделали важный шаг в направлении импортозамещения ЭДО, переведя типовые процессы проверки, подписания и интеграции с Операторами ЭДО на отечественную платформу.
Считаю, мы сделали хороший шаг в направлении импортозамещения ЭДО. А за счет проекта МЧД получили «окно возможностей», чтобы построить перспективную платформу для дальнейшей централизации и оптимизации процессов ЭДО.
Буду рад вашей обратной связи и дискуссии в комментариях. Также интересно узнать, сталкивались ли вы с похожими вызовами в импортозамещении, какие трудности преодолевали и какими путями шли?
Комментарии (8)
dfreydin
05.08.2024 16:31Интересная статья. Спасибо. Подскажите, пожалуйста, как решаете вопрос репликации орг. структуры между учетными системами?
NewMike Автор
05.08.2024 16:31+1Есть 3 варианта (как на камне "налево пойдешь... направо пойдешь.... прямо пойдешь...."):
Интеграция с AD - ЭДО хаб поддерживает это "из коробки", мы пошли этим вариантом
Интеграция с HR-системой (есть опыт интеграции с SAP HR, но тут он не пригодился, 1-й вариант намного проще)
Интеграция с IDM (у нас это новый внедряемый проект на уровне идеи, который помимо орструктуры еще транслирует назначение прав доступа по все системы, чтобы раскатывать оргструктуру (включая ее изменения) и права доступа централизованно и автоматически)
Mi11er
Самое страшное , что закон вступит в силу в сентябре , а многие крупные компании даже не слышали про МЧД или тупо отнекивается и не понимают зачем им это внедрять
NewMike Автор
Согласен, выглядит странно. Более того, недавно узнал, что есть некоторые российские вендоры (разработчики собственного ПО), которые даже не начинали адаптировать свои платформы под МЧД, ожидая "запросов от клиентов". Как говорится: "до первого публичного наказания", после которого все поднимут приоритет этого проекта.