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

Удостоверяющий Центр выдал нам ключ и сертификат в одном PKCS#12 файле auth.p12
Я исхожу из того, что у нас в наличии есть linux и docker. Можно даже не локально - вполне можно закинуть наш документ куда-нибудь на хостинг и подключиться по SSH. Подробности установки docker и работы с докер-образами оставим за пределами этой заметки. Перейдём сразу к делу:

Прямо из папки, где лежит наш документ на подпись (document.pdf) и PKCS#12 файл (auth.p12) запускаем замечательный docker образ OpenSSL с поддержкой ГОСТ и заходим в контейнер:
sudo docker run --rm -i -t -v pwd:pwd -w pwd rnix/openssl-gost bash
Вытаскиваем из PKCS#12 файла приватный ключ и сохраняем его в pem-формате. Может потребоваться ввести ваш пароль от PKCS#12 файла.
openssl pkcs12 -in auth.p12 -out key.pem -engine gost -nodes -clcerts
Аналогично вытаскиваем из PKCS#12 файла и сертификат.
openssl pkcs12 -in auth.p12 -clcerts -nokeys -out pub.crt
Подписываем документ. Подпись будет отсоединенная, в формате PKCS#7 в отдельном файле (document.pdf.sig)
openssl smime -sign -signer pub.crt -inkey key.pem -engine gost -binary -noattr -outform DER -in document.pdf -out document.pdf.sig
Проверить подпись можно много где, как локально так и на сайте госуслуг, например.
Всё. Можно отправлять контрагенту документ и соответствующий sig файл.

Если вдруг у вас сертификат в формате DER (в Windows часто это файл с расширением .cer), то можно конвертировать такой сертификат в pem-формат:
openssl x509 -inform DER -in pub.cer -out pub.crt

Файлы в примерах команд выше:
auth.p12 - бинарный PFX-файл, содержащий сертификат и закрытый ключ
pub.crt - сертификат (содержащий открытый ключ) в текстовом формате PEM
pub.cer - сертификат (содержащий открытый ключ) в бинарном формате DER
key.pem - закрытый ключ
document.pdf - pdf-документ, который необходимо подписать
document.pdf.sig - файл куда будет сохранена отсоединённая подпись к документу

Источники вдохновения:
Работаем с реестром запрещенных ресурсов
Не ждем, а готовимся к переходу на новые стандарты криптографической защиты информации
Docker-образы с поддержкой ГОСТ-сертификатов в openssl, curl, php, nginx
OpenSSL: простое шифрование с открытым ключом
https://stackoverflow.com/questions/52980370/how-to-convert-p12-to-crt-file
https://www.emaro-ssl.ru/blog/convert-ssl-certificate-formats/
https://qna.habr.com/q/213942
http://rodji.net/blog/2013/12/27/openssl-по-гост-подписывание-шифрование-пр/
https://polikarpoff.ru/all/eksport-ecp-v-formate-pkcs-12/

Переход на юридически значимый документооборот (ЮЗДО) при всем влиянии на эффективность бизнеса остается сложной процедурой: нужно учесть многие нюансы, в том числе законодательные, перенастроить процессы, согласовать действия с контрагентами. Важна тщательная подготовка самостоятельная или с помощью опытных консультантов.

Меня зовут Владислав Степанов, я специализируюсь на внедрении и консалтинге в сфере автоматизации документооборота в ИТ-компании КОРУС Консалтинг. Хочу поделиться опытом и рекомендациями по переходу компаний на электронный документооборот и рассказать о нюансах: проблемах роуминга, типизации, маршрутизации, комплектности и обработки документов.

Для начала определимся с терминологией. Электронный документооборот (или ЭДО) это любой обмен цифровыми копиями документов как внутри компании, так и вовне. Как только штат организации преодолевает условную отметку в 100+ человек, потребность в ЭДО начинает ощущаться все более остро. Разница между обычным документооборотом и юридически значимым (ЮЗДО) в характере файлов, которыми обмениваются стороны. В последнем случае документ можно привлекать для доказательства прав. Таким образом, ЮЗДО это разновидность ЭДО.

Использование автоматизированных систем для ЮЗДО в бизнесе постепенно увеличивается несмотря на ряд объективных сдерживающих факторов. Полностью перейти на электронный документооборот мешает отсутствие законодательных норм для некоторых типов документов, не прописано разделение зон ответственности при использовании электронной подписи (ЭП).

Есть и хорошая новость: определенные государственные инициативы (в частности, вступившие в силу с 1 января 2020 года поправки в 63 ФЗ об использовании ЭП), распространение удаленной работы, рост количества мобильных сотрудников и растущая цифровая зрелость бизнеса стимулируют переход на ЮЗДО.

Насколько глубоко компания распространит ЮЗДО на свои бизнес-процессы, зависит от многих факторов. В крупных организациях, по нашим оценкам, до 75% документов на данный момент могут быть полностью и успешно оцифрованы, но на практике этот показатель гораздо ниже. Часть контрагентов по-прежнему не хочет переходить в цифру, хотя среди крупных игроков доля выбравших ЭДО достигает 30-50%, а в некоторых случаях даже больше. Тем не менее даже эти контрагенты зачастую предпочитают использовать ЭДО для обмена только какой-то частью документов, например, финансовой первичкой. А некоторые, наоборот, готовы обмениваться по ЭДО только полными комплектами.

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

Выбор системы для ЮЗДО

Платформой для автоматизации документооборота могут выступать разные внутренние системы: единая ECM (Enterprise Content Management) или несколько решений (СЭД/ECM, ERP и др). Еще на стадии выбора учитывайте возможности масштабирования ЭДО в будущем. Инструментария уже установленной в компании системы электронного документооборота, которая всех полностью устраивает, в будущем может не хватить для какого-то определенного процесса. Сейчас он не используется, но как только потребность возникнет, придется выбирать дополнительное решение, а это сопряжено с новыми затратами как на лицензии, так и на поддержку. Поэтому систему сразу необходимо примерить на вырост.

При выборе одной или нескольких ИТ-систем стоит учесть, что при ЮЗДО у каждой должны быть установлены свои коннекторы к операторам ЭДО, внешним и внутренним центрам хранения сертификатов подписей. Необходимо оценить, какие именно инструменты потребуются и, исходя из этого, очертить круг подходящих решений. Вполне возможно, что для полноценной реализации ЮЗДО вам может потребоваться не одна СЭД/ECM-система, но и ERP, CRM и другие, в зависимости от процессов.

Выбор оператора ЭДО

Сегодня на рынке представлено не менее двух десятков операторов ЭДО, которые предлагают услуги маршрутизации внешних документов: Диадок, СБИС, СФЕРА Курьер, Такском, Калуга Астрал, Синердокс и другие. С точки зрения взаимодействия и выбора подходящего SLA, проще работать через единого оператора ЭДО. Но так только кажется.

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

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

• Роуминг между операторами может занимать много времени, так как тех, кто подписал в рамках инициативы ассоциации разработчиков и операторов систем электронных услуг (РОСЭУ) интеграцию в один клик, пока немного. У прочих провайдеров настройка может растянуться на 10-15 дней и даже несколько месяцев.

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

• Существуют проблемы с наименованием документов (при роуминге используется транслитерация).

• У каждого оператора свое понимание того, как определять документы в полуформализованном виде (если для них нет установленных ФНС форматов). У кого-то существует единая сущность договора, у других несколько. Соответственно, может теряться типизация документов при передаче между провайдерами.

Не все операторы ЭДО работают с пакетами документов, которая необходима многим крупным компаниям.

Работа с контрагентами

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

Чтобы сделать выбор, нужно рассмотреть тех провайдеров, с которыми работает большинство контрагентов компании. Как правило, это СБИС, Диадок и Такском. Такую информацию даст опросник, рассылаемый клиентам/поставщикам: его можно составить как своими силами, так и с помощью консалтинговой компании. Он поможет выяснить, готов ли партнер перейти на ЭДО, что ему мешает и как можно помочь.

Если партнер принципиально готов работать в рамках ЭДО, определите, какими именно типами документов он будет с вами обмениваться. Если данная организация раньше никогда не работала с электронным документооборотом, нужно будет донести до неё потенциальную выгоду цифровизации процесса.

Крупные организации, как, например, Сбер или Магнит, могут себе позволить переход на ЭДО в уведомительном порядке, просто сделав его обязательным условием с оговоренной даты. Но если ваше влияние на рынке не столь велико, нужно будет договариваться с контрагентами и выделить на это время.

Нюансы работы с документами: типизация, маршрутизация, комплектность

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

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

Еще один важный вопрос связан с комплектностью первичных документов, присланных контрагентами. Речь идет о возможности разбирать комплекты, чтобы потом передавать их в определенные ИТ-системы, и собирать их из нескольких систем в единый пакет, подписывать и отправлять вовне.

Третья группа вопросов связана с большим объемом документооборота с контрагентами. Для них может быть реализована техническая подпись. Кроме того, важно прогнозировать рост объема документов в перспективе для того, чтобы заранее определить потребность в ресурсах для их обработки и хранения. Этот параметр также влияет на выбор класса систем ECM и расчет потенциальных затрат.

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

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

оцифровки и хранения внутри ИТ-системы всего архива. Это может быть сделано как в самой компании, так и передано на аутсорсинг.

Несмотря на большое количество нюансов внедрение ЮЗДО в компаниях продолжается. Работа с внешними консультантами позволяет сделать такой переход максимально безболезненным, учесть все тонкости и факторы. Если в организации уже есть ЭДО и/или ЮЗДО, специалисты помогут сделать их использование более эффективным и масштабировать решения.

Поскольку сфера ЮЗДО постоянно трансформируется и меняется, включая правовое поле и пул доступных технических решений, именно опытный консультант может помочь бизнесу построить индивидуальную модель процесса, которая будет учитывать специфику деятельности компании, уже имеющиеся у нее ИТ-решения и сложившиеся взаимоотношения с контрагентами. Сотрудничая с консультантом, можно получить максимум от тех инструментов для ЭДО, которыми бизнес уже располагает, и дополнить их недостающими звеньями.

Ведь в конечном счете задача перехода на ЮЗДО состоит не в том, чтобы усложнить процессы в бизнесе, а упростить их, ускорить прохождение процедур, способствовать росту операционной эффективности и прибыли. И все эти возможности заложены в саму идею ЭДО, но работают только в умелых руках.

Вступление

Привет. Меня зовут Олег и я занимаюсь внедрениями систем управления предприятиями более четверти века.
Я решил написать цикл статей на основе материалов моей книжки ERP для собственников, которая скоро появится в книжных магазинах.
В первой статье я хочу поговорить о главной ошибке большинства внедрений систем управления предприятием. И ошибка эта - непонимание результата внедрения со стороны заказчика.

О чем это?

Начну с частного примера. Представьте себе что ты - собственник компании. Ты считаешь что у тебя есть и ERP и CRM (эта эротическая фантазия может возникнуть, например, из-за наличия у тебя BAS ERP).
И вдруг тебе в голову приходит замечательная управленческая инициатива: персонально связываться с регулярными клиентами, которые перестали у тебя покупать: звонить, выявлять причину отказа и оперативно возобновлять сотрудничество.
Для этого у тебя есть много вариантов реализации. Позволь я назову их не-ERPшными вариантами.

Например, ты можешь попросить своего ИТшника сделать отчет. Очень простенький отчет типа отобрать клиента с признаком РЕГУЛЯРНЙ, у которого за последние 60 дней продажи равны 0.
Но есть проблема. Ты этот отчет запустишь только один раз - когда твой ИТшник будет сдавать работу. Ты его похвалишь, подпишешь акт - и забудешь. Отчет потеряется в дебрях встроенных менюшек. Отчеты - Сервисные - Дополнительные - Для руководства - Клиентские - Не покупающие. Я знаю о чем говорю. Моей команде часто заказывают уникальные отчеты, а практически во всех системах есть журналы использования объектов, которые можно использовать как счетчики. Спустя годы максимальное количество запусков заказанного топ-менеджерами отчета была 16 раз, среднее - 3 раза.

Другой вариант - обязать секретаршу приносить этот отчет ежемесячно. Тут тоже есть проблема. Первого числа следующего месяца ты успеешь позвонить первым пяти клиентам.
Алло, Юрий Петрович? Это Жора Сидоров, собственник Сидоров и партнеры, есть пара минут? Последние два месяца вы у нас ничего не покупаете - вот звоню, может случилось чего? Если есть - я готов решить их тут же, для нашего дальнейшего сотрудничества. Менеджер Костя подвел? Извините, пожалуйста - вы никогда больше не услышите Костю. Давайте следующие 2 месяца я лично буду вашим персональным менеджером, а после - я дам вам на сопровождение нашего лучшего сотрудника и 5% скидки. итд, итд, итд. На пятом клиенте - тебя отвлекут. Отчет потеряется среди кипы текущих бумаг.
Через месяц первого числа ты успеешь обзвонить только двух клиентов. Потом тебя отвлекут.
А на третий месяц твоя секретарша просто не принесет тебе этот отчет.

А что делать?

Но есть другой вариант - позволь мне назвать его ERPшным.

Ровно на 61й день у тебя пиликает телефон (или почта или СМСка или клиент ERP\CRM) и на экране написано:
Сценарий 23. Регулярный клиент не покупает 2 месяца. Клиента зовут Юрий Петрович. Нажми ТУТ чтобы начать звонок.
Ты жмешь кнопку и начинаешь заученное Алло, Юрий Петрович? Это Жора Сидоров, собственник Сидоров и партнеры, есть пара минут?.
А после конца разговора у тебя появляется меню действий: Отправить свежий прайс, Оформить отгрузку клиенту, "Сменить менеджера", Перезвонить через 2 недели. И на каждый пункт меню - автоматизированная цепочка действий.

А разница-то в чем?

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

Время философии.

И тут мы приходим к трехуровневой проблеме. Эта проблема - не техническая, она управленческая. Или, возможно, психологическая. Или - философская.
Слушай.

Первый уровень проблемы

Ты должен четко понимать что вот-этот-вот месседж в телефоне - это не прихоть программиста и не спам телефона. Это твой, собственника, личный приказ с прошлого - себе-будущему: "Позвони, сволочь ленивая, Юрию Петровичу".
Понимаешь? Ты привык отдавать себе приказы с помощью ежедневника? Позвонить, поздравить, заехать. Вот это - точно такой же приказ. Твой приказ себе самому.
Как только ты это поймешь - дела с внедрением ERP сразу пойдут лучше. Но есть и другая сторона. Если у тебя нет ежедневника или ты привык опаздывать на встречи или твои подчиненные часами ждут тебя после окончания рабочего дня (проще говоря - ты не привык отдавать приказы себе-будущему) - даже не пробуй внедрять ERP. Напрасная трата денег. Это не для тебя.

Второй уровень проблемы

На втором уровне - восприятие твоих подчиненных.
Представь что, по твоему приказу, этот-вот обзвон должен делать коммерческий директор. Это значит что когда его, коммерческого директора, телефон пропиликает - он должен воспринять это как твой приказ.
Все твои подчиненные тоже должны понять что любое управляющее воздействие, пришедшее от ERP - это не прихоть консультанта, программиста или компьютера. Это - прямой приказ собственника. И неисполнение того что пропиликало (или игнорирование пиликанья или непрочтение того что пропиликало) - должно восприниматься как неисполнение твоего приказа, с соответствующими оргвыводами: выговор, депремирование, увольнение.
Это твой приказ. Точка. Как только твои подчиненные это осознают - дела с внедрением ERP\CRM в твоей компании пойдут ну очень хорошо.

Уровень третий. Самый сложный.

Вот-этот-вот условный Сценарий 23 - это твой, собственника, приказ. Ты его выстрадал. Ты понимаешь почему ты его создал, понимаешь почему он необходим и понимаешь почему ты или твои подчиненные должны его выполнять.
Но создавать систему на собственном опыте - долго и муторно. Для внедрений существуют типовые решения. На каждой платформе они называются по-разному, поэтому я выбрал максимально нейтральное и мало где встречающееся понятие индустриальная модель. Например - управление поставками для массового производства. Или - управление розничными продажами для аптек.
Индустриальные модели - это концентрация опыта, процессов и управленческих решений других компаний. Компаний, которые продвинулись в автоматизации управления значительно дальше чем ты. Часто это - лидеры отраслей. Твои конкуренты.
Индустриальные модели - это концентрированные опыт, пот, кровь и слезы твоих конкурентов. Процессы и управленческие паттерны твоих конкурентов.
Чтобы внедрить ERP или CRM в приемлемые сроки - ты должен выбрать близкую тебе индустриальную модель. Да, ты можешь потом ее изменять - но старт с ноля вместо старта с близкой индустриальной модели - это как.... как создание своих компьютеров и чипов для офисной работы вместо покупки готового компа в интернет-магазине.

И так, ты выбрал какую-то индустриальную модель. В ней - чье-то видение, чьи-то процессы, чьи-то приказы. А вот исполнять эти приказы - тебе. И именно в этом - самая сложная проблема.
Внедрить ERP - значит принять что ты будешь исполнять чужие приказы. И твои подчиненные будут исполнять чужие приказы.
Чужие приказы можно исполнять через веру - веру в лидера или в начальника, или в гуру или в консультанта или в предшественника. Но это не твой путь. Ты потому и стал собственником - а) чтобы не подчиняться чужим приказам б) чтобы ничего не принимать на веру.

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

Вступление

Привет. Меня зовут Олег и я занимаюсь внедрениями систем управления предприятиями более четверти века.

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

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

ERP для собственников. Часть 1. Философское.

Проектное vs Операционное

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

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

Следствия

А теперь послушай меня внимательно - ибо здесь один из ключей к пониманию роста и устойчивости твоего бизнеса.

• Операционное от процессного отличается только зрелостью команды.

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

• Изменение зрелости команды для превращения проектного в операционное - твоя, собственника, основная задача.

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

Технологичное

Продолжу вводить определения.

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

Объясню.
Айвазовский за 60 лет своего творчества написал более 6000 картин. Без сомнений, его деятельность была операционной - он был способен выдавать оговоренные заказчиком результаты в срок, с оговоренными качеством и стоимостью. Но его деятельность не была технологичной - она критично зависела от самого Айвазовского, он был критичным ресурсом. С исчезновением художника производство картин остановилось.
А вот современный Айвазовскому Фаберже сделал производство получивших его имя яиц технологичным: он него лично (как и ни от одного другого мастера в его холдинге) конечный продукт не зависел вообще. Я не зря привел столетней давности примеры Айвазовского и Фаберже - этим я хотел акцентировать внимание на том что технологичной основная цепочка создания ценности может быть вообще без компьютеров и программ.

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

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

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

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

И тут я подвожу тебя к моменту истины.

Внедрение ERP - это реализация желания собственника сделать деятельность по управлению компанией технологичной.
Внедрение ERP - это реализация желания собственника сделать менеджмент ниже C-level легко заменяемым или вообще не нужным.

Отсюда три вывода.

Вывод 1

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

При внедренной ERP менеджеру платят не за то чтобы он отдавал приказы. Ему платят а) за то чтобы он обеспечивал выполнение приказов, сгенерированных системой б) за то чтобы несколько ключевых параметров его деятельности не вышли за диапазон допустимых значений. Именно это ты должен принять за основу мотивации своих менеджеров.
Дисклаймер. Отдельной коллективной задачей менеджеров стоит регулярный анализ и пересмотр модели принятия решений системой - но об этом я расскажу позже.

Вывод 2

Чуть выше я написал что внедрение ERP делает управленцев легкозаменяемыми.
Но для сапиенсов критично важна стабильность. Поэтому первостепенной задачей топов должно стать обеспечение чувства стабильности.

Если хоть у кого-то из топов хоть раз проскользнет выражение не нравится - свободен, другого найду - то получатель такого сообщения (или получатели, если это было сказано при свидетелях) тут же начнет делами доказывать свою незаменимость. То есть - начнет воевать с EPR. То есть - будут хоронить первичную идею.

Ты думаешь - корпоративные кодексы и вежливость зря придумали? А вот нифига, они придуманы потому что проще демонстративно заменить менеджера (например) третьего уровня чем ставить под угрозу технологичность процессов управления на четвертом уровне.
Если ты думаешь что я сказки рассказываю - нифига. Я внедрил ERP для голландских, австрийских, швейцарских, словенских компаний и продолжаю с ними работать - и здесь это осознанная истина.

Вывод 3

Кнутово-пряничный. Превращение управления в технологичную деятельность делает компанию на горизонте 3-5 лет практически независимой ни от собственника ни от топ-менеджера.

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

Кнут. О такой независимости мечтает любой рейдер. Если кто-то реализует сценарий враждебного поглощения - бизнес вполне нормально продолжит работать, как будто ничего не случилось. И если рейдеру хватит ума ничего не трогать в настройках - бизнес даже не заметит твоего исчезновения.

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

Читатель, если у тебя нет своего бизнеса - кинь этот линк своему работодателю. Он оценит.

В последнее время все чаще слышно про RPA или Robotic Process Automation. С одной стороны, говорят о его эффективности для банковского сектора и крупных корпораций, с другой про применимость и в среднем, и даже в малом бизнесе. На днях на Хабре вышла обзорная статья про интеллектуальную обработку документов с помощью RPA и мы подумали, что хабравчанам также будет интересен рассказ про наш опыт реализации такого проекта в деталях.

Он был выполнен для одного из крупнейших ритейлеров в РФ и Европе. Его магазины можно найти везде: в одной только Москве и области их десятки, а по всей России больше сотни. Это фантастическое количество товаров, поставщиков, поставок и связанного с ними документооборота, которого с каждым месяцем становится больше и больше.

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

Идеальный сценарий для RPA! А для нас отличная возможность показать, как он грамотно и продуктивно реализуется.

С чем предстояло работать

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

Описанные выше проблемы возникали на этапе обработки документов. На стороне заказчика каждый день на эту задачу тратилось 72 часа. Это 9 полноценных бухгалтерских рабочих дней! Роботизации этого проекта от нас и ждали.

Как видите, большая часть этого процесса механическая рутина. Идеальная цель для автоматизации! Однако классический путь доработки ERP-системы с интеграцией ее с СХД был заказчику закрыт: бэклог команд, занимающихся сопровождением и развитием этих систем, был расписан на месяцы вперед, а доработка системы сложна и дорога. В общем, классический кейс а давайте лучше робота: с ним не нужно будет дорабатывать информационные системы.

В качестве платформы роботизации был выбран UiPath: абсолютный лидер на рынке РФ и один из лидеров глобального рынка RPA, кроме того, уже обкатанный в головном офисе нашего партнера в Европе.

Чего мы хотели от робота?

У этой роботизации было несколько основных и вспомогательных целей. Основные цели были достаточно стандартные: процесс нужно было автоматизировать не менее чем на 90% (звучит впечатляюще, но для мира RPA это норма), сократив затраты на него по сравнению с ручным трудом. Второстепенные цели были любопытнее:

выявить аномальные расхождения, которые человек может пропустить;

снизить риск ошибки специалистов по товарному предложению;

предотвратить расширение штата бухгалтеров при увеличении объемов поставок;

ускорить проведение оплат поставщикам.

На основе всего этого мы поставили перед собой такие задачи:

разработать роботов, которые будут выполнять работу бухгалтеров;

разработать сервис их взаимодействия с бухгалтерами и СТП; не допускающий использования вил и факелов

реализовать процесс извлечения данных из сканов бумажных документов;

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

Ну и как же без дополнительных требований от заказчика:

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

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

отсутствие у роботов дублирования функций;

приоритизация срочных задач (например, отчетов);

минимизация поддержки решения после ввода в эксплуатацию;

автоматический онлайн-расчет окупаемости (дэшборд в Confluence);

и еще, чтоб участников процесса письмами/уведомлениями не спамило.

Подход к проблеме и проект

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

Итак, сформулировав процесс AS-IS, мы декомпозировали его на подпроцессы для роботизации. Получилось вот так:

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

Однотипные задачи мы сразу стали собирать в совместную обработку, помня о требовании об эффективном расходовании runtime-лицензии. На практике это значило, что если нужно выгрузить из ЭХД 10 доков, то открывать его мы будем 1 раз, выгружать нужное и 1 раз закрывать, а не открывать и закрывать для каждого документа.

Архитектуру системы полностью определило решение формировать списки задач для каждого роботизируемого процесса в СУБД (MS SQL). Тем более что, как мы выяснили, отчёт из учетной системы (на базе СУБД ORACLE) можно выгружать запросом. Поэтому мы решили сделать Link к БД учетной системы и настроить Job в БД для регулярной выгрузки новых приемок, готовых к сопоставлению. Этот Job будет также анализировать полученные данные и переводить приемки на нужный этап обработки: Требует согласования с СТП, Требует выгрузки в систему распознавания, Передать в оплату и т.д.

Роботу оставалась только грязная работа по выполнению механических операций в соответствии с установленным статусом.

Что еще нужно было определить перед тем, как приступить к работе?

Архитектура распознания документов

Наш робоподопечный должен был уметь распознавать документы такое зрение ему мы сделали на известной платформе ABBYY FlexiCapture. У нее есть, во-первых, готовые шаблоны распознавания для первичных документов (мы лишь немного докрутили их под примеры заказчика). Во-вторых, она предоставляет удобный интерфейс для верификации результатов распознавания, а это экономит время тому, кто верифицирует.

В этом процессе было несколько критически важных точек: качественное извлечение табличной части документа; проверка артикулов в БД (да, номенклатура также выгружалась из БД ERP-системы); сверка суммы документов; проверка совпадения штрихкода на документе и в ERP.

Формирование интерфейса

Для взаимодействия с пользователями изначально планировали использовать Jira, но затем мы приняли решение упростить интерфейс. Мы разработали собственный сервис по взаимодействию с пользователями. Если требуется согласовать расхождение, робот присылает сотруднику по товарному предложению ссылку в письме. При переходе по ней формируется web-страница, при этом проверяется, не был ли этот заказ уже согласован, а также имеет ли данный человек все необходимые права. На этой странице сотрудник выполняет согласование и вводит комментарий. После этого приемка в БД получает соответствующий статус для дальнейшей обработки роботом.

Что важно отслеживать в такой ситуации? Согласованные приемки, сотрудника, который их согласовал, а также его возможный комментарий. Но главное обязательно нужно выполнить дополнительную проверку согласования бухгалтером (в компании уже был случай, когда СТП по ошибке согласовал очень крупное расхождение в цене).

Формирование отчетности

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

Всего отчетов было реализовано четыре:

отчет по задачам бухгалтеров (требуются ли действия от бухгалтера?);

отчет главного бухгалтера (по задачам всех бухгалтеров);

общий отчет по выявленным расхождениям;

детальный отчет по расхождениям (с суммами по приёмкам и по поставщикам).

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

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

Формирование графиков в Confluence

Помимо отчетов, робот также должен был строить real-time графики окупаемости самого себя. Для этого был разработан набор представлений в БД, в которых рассчитываются ключевые метрики робота. Методология расчета метрик включает в себя все затраты на роботизацию процесса, в том числе стоимость лицензий, серверов, стоимость наших услуг, а также зарплату бухгалтеров, ведь полностью мы их не исключили из процесса. Для отображения графика на странице в Confluence используется плагин Database Query.

С какими трудностями мы столкнулись

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

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

После реализации персонализированных отчетов мы столкнулись с проблемой приоритизации задач.

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

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

Таким образом, при наличии в очереди задач на формирование отчета, робот практически сразу брался за их выполнение.

Как заставить робота самого себя поднимать

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

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

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

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

Переиспользование частоиспользуемых процессов (инвоуков)

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

Кастомные активности

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

работа с БД (получение данных по приемкам, по отчетам, сохранение статусов и т.д.);

работа с почтой (получение запросов от бухгалтеров, отправка уведомлений);

работа с Excel (форматирование, группировка, сортировка и т.д.);

работа с учетными системами (авторизация, проверка ошибок).

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

Курьезный случай исчезновение штрихкодов

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

Этот случай очень показателен: многие думают, будто роботы могут сами принимать решения, совершать что-то незапрограммированное или даже сливать кому-нибудь на сторону конфиденциальную или коммерческую информацию. Конечно же, роботам это не интересно, и наши не исключение. Они работают по четким алгоритмам (скриптам), и любое отклонение просто невозможно, если только это не разработчик ошибся.

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

Пришлось-таки подключить команду сопровождения этой учетной системы. Мы совместно настроили расширенную трассировку процесса и уже на первом же тестовом прогоне обнаружили место сбоя. Виновником был java-скрипт на стороне учетной системы. Коллеги выпустили патч и проблема исчезла.

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

Результаты

Как мы говорили в самом начале, от нас требовалась оптимизация рабочего процесса на 90%. Как вычислить этот показатель? Для этого нужно сравнить время, которое будет потрачено на нужный процесс с роботом и без него. Мы определили, сколько занимали все составляющие роботизированной работы выгрузка актов, работа в ABBYY, составление отчетов и даже написание писем; задали резерв на обслуживание робота.

И выяснили, что с задачами, на которые штат бухгалтеров ежедневно тратил время девяти полностью занятых профессионалов, робот справляется примерно за половину одного рабочего дня (0,47 рабочего дня, если быть точным). Точный показатель 94% оптимизации. Это была победа!

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

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

Спасибо всем дочитавшим до этого момента. Если у вас возникли вопросы, мы будем рады на них ответить!

Разбираем аргументы за и против. В конце также можно ознакомиться с моим мнением на этот счет.

С чего все начиналось?

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

Немного обо мне: я Python разработчик, архитектор, тимлид. В программировании с 2009 года. Ранее опубликовал эту статью на vc.ru.

В реализации проекта мне помогал аналитик от заказчика, и в общем-то всё.

Итак, к кейсу

В коллектив организации входит большое количество выездных сотрудников. Часто возникают ситуации, когда у работника нет возможности CRM-системой на компьютере (в нашем случае ноутбуке) для выполнения рабочих задач.

Если коротко описать задачу: человек в полевых условиях должен иметь возможность войти в систему и отправить необходимые документы. Иначе из-за временных задержек компания теряет приличные суммы денег.

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

Как решить проблему потери времени? У сотрудника должна быть возможность коннектиться с CRM-системой с планшета или телефона.

Как осуществить задуманное?

Выход нашёлся быстро: создать чат-бот в Telegram.

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

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

Если рассуждать со стороны управленцев, соединение CRM-системы с чат-ботом Telegram значительно снижает энергозатраты и финансовые расходы компании. И вот, почему:

• Не нужно обучать большой штат новым программам-интеграторам CRM с телефоном.

• Тем более, стоимость таких программ значительно выше, чем стоимость написания и поддержания работоспособности чат-бота для Telegram.

• Это удобно. Сейчас у каждого есть возможность скачать Telegram, который не занимает много места в памяти телефона.

• Работает Telegram-бот действительно быстрее, чем сложная программа. Кроме того, чат-бот помогает сотруднику сориентироваться во внутреннем документообороте фирмы.

Но со стороны безопасности и сохранности данных такое внедрение в электронный документооборот крупной компании нужно считать неприемлемым. Здесь на арену выходят возможные доводы IT-отдела.

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

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

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

• Ещё один весомый аргумент: данные будут храниться в разных системах. Telegram-бот может быть напрямую привязан к CRM или ERP-системе, но в большинстве случаев он имеет свое хранилище, в котором агрегирует данные и обрабатывает их.

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

А что я думаю по этому поводу?

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

Тем более, если говорить об удобстве главных героев этой эпопеи - полевых работниках, то загрузить документ и отправить его на дальнейшее согласование, получить нужное уведомление гораздо проще через бот в Telegram, чем через специализированную программу, типа 1C, Диадок и т.д.

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

Даже удивительно, почему другие компании не используют подобные методы. А может и использует, кто их знает?

Главное учесть, что чат-бот подойдёт для решения не всех задач, но, когда нужно разобраться с простыми вопросами быстро и вовремя, Telegram-бот это то, что нужно.

О технической стороне вопроса

Идея была реализована на основе Telegram API на вебхуках. Для разработки был использован любимый python, данные хранятся на базе postgresql. Для ускорения работы и асинхронности задач применили связку redis + celery, в качестве серверной операционной системы использована Ubuntu 18 Server.

К слову сказать, мой клиент остался доволен. Нововведение принесло компании прибыль, которая терялась на простоях из-за пауз в цепочках бизнес-процессов.

А вы на стороне программистов или управленцев? Делитесь своим мнением, задавайте вопросы!