Часть 1. Малая Автоматизация вошла в чат

Зачем написана эта статья и для кого

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

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

Что такое ОЦО и СКР?

Хочется кратко рассказать про то, чем мы вообще занимаемся, для понимания всей картины. Сначала ответим на вопрос, да кто вообще они такие — эти ваши ОЦО? Объясняю, ОЦО — это общие центры обслуживания, которые создаются крупными компаниями для того, чтобы «запихнуть» в них одну или несколько внутренних сервисных функций, например, бухгалтерию, HR, закупки и т.п. Спросите, зачем? Затем Для концентрации бизнеса на получении прибыли и оптимизации, а также для поднятия эффективности сервисов.

ОЦО Tele2 в статье — это про финансы. Мы отвечаем за учет, взаиморасчеты, платежи, финконтроль и отчетность в группе компаний «Т2 Мобайл». Основная цель ОЦО может прозвучать непонятно, но на деле довольно проста — построение эффективной модели внутрикорпоративного клиентоцентричного финансового сервиса. Другими словами, упрощение операций учета денег для всех внутри компании.

Следующий набор букв, который стоит расшифровать, — СКР. Это служба контроля, развития и операционной эффективности, небольшое подразделение ОЦО, отвечающее за два направления работы:

• работа с системой SLA/CSI ОЦО, для оценки уровня оказываемых услуг;

• формирование и развитие локального центра компетенций (ЛЦК) по автоматизации и роботизации процессов ОЦО.

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

• средний срок разработки — от 2 недель до 2 месяцев (все зависит от масштаба проектов);

• поддерживаем свыше 100 созданных решений в собственной локальной «экосистеме»;

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

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

Закономерный вопрос: на чем у нас все работает? Знакомьтесь, ERP-система — SAP Hana, а в качестве ECM и системы ЭДО юзаем FileNet. Интеграция есть только по ограниченной части функционала, полной нет.

Что именно мы делаем в компании?

Расскажу по порядку. В конце 2018-го мы начали активно исследовать бизнес-процессы внутри компании, чтобы повышать их эффективность. На тот момент все традиционные и очевидные подходы для повышения эффективности и качества работы с транзакциями уже были внедрены. Начиная от управленческих решений — группировки документов в одном из подразделений, группировки распределения заданий и их частота, специализации сотрудников на отдельных операциях — и заканчивая несложными макросами или шаблонами с формулами в Excel. Они хоть и приносили эффект, но он измерялся единицами процентов. Нам не удавалось сильно влиять на показатели ОЦО. Как пример, старыми методами нельзя было снизить срок обработки поступающих документов, который составлял от 2 до 4 рабочих дней.

Вся автоматизация, сделанная нами в то время, была на уровне простейших макросов, построенных на формулах Excel. А если требовалась серьезная доработка, то в игру вступал полный цикл разработки за пределами ОЦО, занимающий от 9 месяцев и более. За это время может измениться даже сам процесс, ради которого автоматизация и затевалась. Итого у нас было: отсутствие своей разработки в ОЦО, отсутствие ресурсов и задачи по повышению эффективности, которые нужно решить сейчас, а не через 2 года. В связи с этим было принято решение организовать внутри ОЦО направление по автоматизации, ядром которого и стала наша команда.

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

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

После изучения информации по этой теме сформировалось понимание, что мы заметно отстали в направлении автоматизации. В то время как участники конференций делились своим успешным опытом роботизации и участвовали в дискуссии, что лучше — API или использование возможностей RPA, мы писали формулы в Excel.

Мы не могли пойти в использование коммерческих RPA-платформ, так как компания только начала процесс выбора одной из них. Поскольку разработка Z-транзакций и программирование на ABAP — это не наши компетенции, нам приходилось работать с теми инструментами, которые нам дает SAP сверху. Так мы и пришли к тому, что наши задачи решает SAP Scripting.

На этой почве встал вопрос о стеке, который будет использоваться для автоматизации. И он был разрешен с помощью: SAP Scripting, MS Access, AutoIT, VB (VBA), MS SQL (в архитектуре появилась не сразу, но мы пришли опытным путем). Почему сделали свой выбор в пользу данных технологий:

• VB (VBA). Достаточно прост в изучении. Для желающих освоить VB организовали обучение. Глубокая интеграция с MS Office. VB внедрен в виде VBA во все офисные приложения, используемые в ОЦО. Возможность отладки «здесь и сейчас», так как программа на VBA не требует создания .exe файла, при возникновении ошибок у пользователя можно в режиме онлайн отладить программу. Это значительно экономит время на восстановление работоспособности.

• MS Access. Мы изначально понимали необходимость работы с достаточно большими объемами информации. «Достаточно большие» объемы — такие, где Excel начинает испытывать затруднения с их обработкой (десятки и сотни тысяч строк). При этом тот же MS Access справлялся с данными задачами «на ура», у него есть инструменты импорта и экспорта данных, доступ к другим к БД (некоторый опыт использования MS Access у нас уже был). Обработка данных на языке SQL гораздо изящнее и производительней, чем язык формул/макросов MS Excel.

• SAP Scripting. Дает аналог записи макросов Excel и записывается на VBScript. Поэтому его можно легко переносить в код VBA с минимальными исправлениями.

• AutoIT. Подкупил простым скриптовым языком, независимостью от MS Office, хорошей документацией, большим количеством информации в интернете, отзывчивым комьюнити. К тому же это opensource ПО, которое можно использовать для автоматизации рутинной работы на ПК, включая возможности управления запущенными приложениями через GUI.

• MS SQL. Есть бесплатная Express-версия, множество документации и информации в сети, что и как делать. Что было крайне важным для нас — доступ к данным MS SQL не требует настройки или установки ПО на стороне клиента, так как соответствующие драйверы уже входят в состав ОС Windows/MS Office. Использовать MS SQL мы начали во второй половине 2019 года. Почему — об этом ниже.

Не забываем, что мы ОЦО, практически любая работа бухгалтера тесно связана с Excel, выбор технологий очевиден, потому что…

Сопоставив все факторы, выбор VBA на тот момент был безальтернативным. Он давал нам возможность заметно сократить сроки до релиза, а в нашем случае скорость крайне важна.

Исследование процессов ОЦО

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

В начале со стороны бухгалтеров мы почувствовали сопротивление изменениям: «Зачем что-то менять? Вы сейчас что-нибудь поломаете, а нам разгребать». В условиях больших объемов регулярной работы бухгалтеров ОЦО, ее высокого темпа это нормальная реакция. Сомнения коллег были ожидаемы, так как ранее они пытались закрывать вопросы с помощью доработок за рамками ОЦО, и это не давало большого выхлопа. А тут еще и какую-то непонятную автоматизацию своими силами предлагают...

Скепсис был обоснован.

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

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

Поиск ресурсов в других подразделениях для разработки решений

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

В апреле 2019 была запущена одновременная реализация сразу четырех проектов с участием привлеченных сотрудников, на которые было заложено 2-3 рабочих недели. Разработка решений проходила очно на территории нашего подразделения, подход к решению и способ реализации определялся тоже нами.

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

История первого крупного проекта. Что происходит в ОЦО ночью, пока бухгалтер спит

В июне 2019, уже опираясь на практику проведения исследований, стало понятно, что для повышения доверия к команде СКР нужен реально сильный и успешный кейс, причем немедленно. И мы побежали искать идеи для таких кейсов.

И вот что у нас родилось. Через ОЦО Tele2 ежедневно проходит до 10 000 документов. Обрабатывают эти документы руками, из-за чего в цикл обработки документов включается достаточно большой пул контрольных процедур. Сотрудники их выполняют, чтобы убедиться, что все операции отражены правильно. Типичный сценарий такой процедуры — сотрудник делает выгрузку из SAP или нескольких систем, проводит предобработку в Excel, дополняет ее необходимой информацией, проводит анализ и выявляет ошибки. Из-за человеческого фактора достаточно высока вероятность допустить ошибку как при подготовке исходных данных, так и при проведении их контроля. Предложенное нами решение исключало этот самый человеческий фактор на определенных этапах исполнения сценария контроля.

Мы предложили организовать исполнения сценария иначе: «А что если мы будем формировать все необходимые выгрузки в нерабочее время, например, ночью? А также будем выполнять предобработку данных, дообогащение, проверку логики; отмечать сразу корректные позиции и т. д.». Коллеги крайне заинтересовались, в их сердцах промелькнул лучик надежды на светлое будущее. Потому что мало того, что этот процесс занимал много времени, так еще и зачастую бухгалтерам приходилось проводить контроль во внерабочее время, особенно при закрытии периода.

Коротко пробегусь по реализации проекта. В MS Access лежит расписание, список задач, выполняющих выгрузки из различных транзакций, и предобработки данных. Сами задачи реализованы на VBA в Access и Excel.

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

• По итогу отработки задания выгрузка копировалась на общий сетевой ресурс.

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

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

Это был успех

Результат составил свыше 500 часов в месяц, но получилось это не сразу. Пришлось попотеть при настройке задания в планировщике Windows, над частыми сбоями, перезапусками ночных заданий… но все было не зря. Плюс у нас сформировалось понимание, что автоматизация любых транзакций абсолютно реальна, если правильно к ней подойти, и решения на Access работают стабильнее, чем в Excel. Это привело к тому, что базой для всех новых разработок стал Access, а решения, реализованные на Excel, не переписывались до момента возникновения существенных сбоев в их эксплуатации.

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

Мы сформулировали несколько характеристик процессов, которые подпадали под пристальный интерес:

• Регулярность

• Формализованность

• Нетребовательность к глубокой экспертизе

• Рутинность

• Трудозатратность

К середине 2019 г. по промежуточным итогам анализа бизнес-процессов был сформирован и приоритизирован пул проектов. Их получилось более 150.

Как определялся приоритет задач? Проводилась консультация с руководителем, aka держателем процесса, на предмет озвученных выше характеристик. Дополнительно учитывалась сложность изменения процесса, возможные альтернативы, в том числе автоматизация, оценивался потенциальный эффект. Задачи с наибольшим эффектом получали более высокий приоритет для старта поиска решений.

Пилот по обработке первичных документов

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

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

1. мы можем использовать существующие и доступные нам механизмы для перевода документа из формата PDF в формат Word;

2. разрабатываем/настраиваем шаблонные алгоритмы извлечения формализованной информации из преобразованных сканов;

3. бухгалтер со своей стороны подстраховывает от случаев отклонений, проверяя скан документа на наличие подписей/печатей;

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

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

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

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

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

Сам процесс обработки документа имел следующие шаги:

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

2. Робот анализировал каждый документ (сравнивал вложение с данными из ЭДО-системы) и фиксировал результат в таблице.

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

4. После того как сотрудник проанализировал оставшиеся позиции, он отмечал документы, по которым согласована обработка в SAP, и запускал процесс автоматической обработки.

5. После этапа обработки SAP также формировался отчет о результате.

Автоматизация шагов на стороне SAP нас не пугала, так как к этому моменту уже были уверенные знания и практика, что и как делать. Как уже говорили ранее, VB интегрирован с продуктами MS Office, поэтому сложностей с открытием/парсингом/анализом документа word через VB не возникло. Нужную информацию из документа получали с помощью регулярок. Сам робот был реализован на MS Access. Использование SQL избавляет от большого количества кода, который бы пришлось реализовать в Excel.

Итоги пилота в цифрах:

• 140 часов экономии в месяц;

• Время обработки одного документа снижено в 20 раз;

• Срок обработки сокращался с 2 рабочих дней до одного.

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

Миграция на MS SQL

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

Для решения этой задачи мы и использовали БД MS Access, содержащую: реестр решений, загруженный исходный код модулей с привязкой к решению (связь «многие ко многим»), а также ряд дополнительных таблиц. Наличие единого хранилища было удачным решением, так как оно решало целый комплекс задач для нас:

• Обеспечивало логирование (старт, окончание, статистические показатели работы).

• Обеспечивало централизованную актуализацию версий модулей.

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

• Реализация общих принципов в наших решениях: при запуске решения оно обращалось к БД, определяло по идентификатору решения список модулей, их актуальные версии. При выявлении устаревших версий из базы скачивался актуальный модуль и заменял текущий. Таким образом обеспечивалось автоматическое централизованное обновление решений, что было практически незаметно пользователям и существенно экономило время на разбор ситуаций, связанных с работой устаревшего кода.

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

Стало ясно, что с MS Access надо уходить на более надежную БД. Это и стало причиной миграции на MS SQL. Как уже говорилось выше — наличие у клиентов всех необходимых драйверов «по умолчанию» стало одной из основных причин перехода именно на эту СУБД, да и свободные IT ресурсы в виде оборудования у ОЦО на тот момент были.

Общие достигнутые результаты за 2019 год

• Сформулировано перспективное видение для службы по повышению эффективности процессов ОЦО.

• Установлены признаки процессов, подходящих под автоматизацию. Наработана экспертиза для проведения бизнес-анализа.

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

• Проведено обучение части сотрудников ОЦО языку программирования.

• Сформированы дорожные карты крупных проектов.

• Научились уверенно пользоваться SAP Scripting (разработаны готовые программные модули для внутреннего использования).

• Освоены инструменты VB, SQL, AutoIT.

• Перешли на MS SQL как централизованную БД по решениям автоматизации.

• Реализован крупный проект «Ночные выгрузки», который масштабируется по сей день.

• Реализован пилот по обработке транзакционных документов.

• Расширение службы: один сотрудник после обучения макросам перешел в наше подразделение как разработчик, еще один — в качестве аналитика (тот самый из бухгалтерии).

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

• К концу года в базе данных было зарегистрировано 57 решений.

• Экономия по итогам года составляет более 1000 часов в месяц (~ 7 FTE).

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