Файл: Разработка регламента выполнения процесса «Планирование налоговой стратегии» (Критерии выбора решения для автоматизации).pdf

Исходя из представленной выше таблицы, отражающей основные отличительные особенности (технические и влияющие на бизнес-логику) программ, мы можем сделать вывод о том, какой модуль Abbyy оптимальнее всего подходит для нашего процесса (наиболее важные положения подчеркнуты в таблице). Итак, Flexi Capture поддерживает шаблоны классификации, благодаря которым происходит определение типа документа по заданному алгоритму (например, соответствие основных блоков текста заранее определенным координатам на странице в зависимости от типа документа) и наложение его на стандартный шаблон документа этого типа (соответствие форме по КНД: 1165013 – для Требования и 1165014 – для Поручения). Эта функция необходима для проверки того, действительно ли поступивший документ является основанием для его исполнения, поэтому по данному пункту FineReader уже не подходит. Следующим важным критерием является возможность определения диапазона документа и его распознавание по страницам: так как Требования и Поручения могу содержать в себе разное количество страниц в зависимости от количества запрашиваемых документов в них, заложить алгоритм работы с определенным количеством страниц не представляется возможным.

В связи с этим, мы приходим к выводу о том, что наиболее подходящим решением в нашем случае является программа Abbyy Flexi Capture, с которой в дальнейшем и будет выстраиваться взаимодействие выбранного решения автоматизации. Для того, чтобы в рамках итогового решения (в случае отсутствия встроенной технологии OCR) учитывать затраты на распознавание входящих документов из ИФНС, ниже в таблице 3 рассчитаем трудозатраты и стоимость решения Abbyy Flexi Capture.

Таблица 3 Расчет трудозатрат и стоимости технологии распознавания символов

Так, независимо от решения автоматизации (при условии отсутствия встроенной технологии OCR), стоимость внедрения технологии распознавания входящих документов будет составлять 4 543 000 руб.

Обоснование оптимальности внедрения технологии RPA

Выше мы проанализировали BPMS- и RPA-решения и остановились на одном из примеров для каждой технологии: Pega BPM и UiPath соответственно. Собственная разработка программного обеспечения (ПО) будет рассмотрена в данном пункте как один из возможных, но изначально менее подходящих вариантов.

Итак, у нас есть текущий процесс AS-IS для сравнения (вариант А). При этом возможно 3 основных варианта решения исследуемой проблемы:

• Разработать собственное решение (при помощи так называемой «честной автоматизации») – B;
• Внедрить BPMS-решение (вариант C);
• Внедрить программных роботов (RPA) – вариант D.

Для оценки вариантов сравним их по набору таких критериев, как: стоимость разработки^[1], время разработки (включая этап предпроектного исследования, аналитическую работу, тестирование и опытно-промышленную эксплуатацию), время работы сотрудника/робота/ПО, количество возникающих в процессе работы ошибок^[2], FTE^[3], а также постараемся вычислить возможные риски, которые наиболее часто встречаются в современных реалиях при интеграциях и разработке новых решений. Чтобы провести данный анализ, для начала вычислим каждый пункт в отдельности.

1. Стоимость разработки.
2. Одной из важнейших статей расходов в процессе AS-IS являются штрафные санкции, возможные при некорректном предоставлении/непредоставлении в срок документов, отраженные в таблице 4.

Таблица 4 Штрафные санкции, применимые к банкам ФНС за некорректное предоставление запрашиваемых документов [38]

Исходя из таблицы 4 и личной практики компании, на штрафные санкции в среднем ежегодно тратится порядка 2-4 млн.руб. Фактические затраты, которая компания понесла за период с 01.03.2018 г. по 01.03.2019 г. (такие даты были взяты, исходя из необходимых сроков написания данной выпускной квалификационной работы), составляют, судя по таблице А2 Приложения А, 3 510 000 руб.

Эксплуатационные расходы, по анализу компании-клиента, составляют 2 000 000 руб. Расчет ФОТ (фонда оплаты труда) 4 сотрудников (2 сотрудника Канцелярии и 2 сотрудника Операционного департамента), которые планируется высвободить для более высокоинтеллектуальной работы, приведен в формуле 1.1.

ФОТ = СЗ*СЧ*12, (1.1)

где СЗ – среднемесячная зарплата, СЧ – среднесписочная численность сотрудников.

Так, фактический ФОТ = 60 000*4*12 = 2 880 000 руб. Помимо НДФЛ, входящих в ФОТ, компания платит страховые взносы от каждой зарплаты в размере 30% от оклада gross (в данном случае – от 60 000 руб.): 2% – в Пенсионный фонд, 2,9% в Фонд социального страхования и 5,1% – Фонд медицинского страхования.

Затраты на 4 сотрудников в год для компании обходятся в следующую сумму: 2 880 000 + (60 000*0,3*4*12) = 2 880 000 + 244 800 = 3 124 800 руб.

Итого компания затрачивает на текущий процесс: 3 510 000 + 2 000 000 + 3 124 800 = 8 634 800 руб.

1. Стоимость разработки индивидуального программного обеспечения расписана в таблице 5 с учетом вариантов использования (use cases – UC), разработанных и расписанных нами для данного проекта внедрения.

Таблица 5Расчет стоимости разработки индивидуального ПО

С учетом того, что в компаниях-интеграторах, рассматриваемых Заказчиком (банком) в качестве потенциального исполнителя, в среднем ставка разработчика составляет 3500 руб./ч, аналитика – 3450 руб./ч, тестировщика – 3000 руб./ч, РП – 3500 руб./ч, получаем следующие расчетные данные:

Стоимость разработки ПО с учетом рисков: стоимость работы разработчика (1982,4 ч * 3500 руб./ч) + стоимость работы аналитика (660,8 ч * 3450 руб./ч) + стоимость работы тестировщика (330,4 ч * 3000 руб./ч) + стоимость работы РП (495,6 ч * 3500 руб./ч) = 6 938 400 + 2 279 760 + 991 200 + 1 734 600 = 11 943 960 руб.

3. ПРИМЕНЕНИЕ ТЕХНОЛОГИИ RPA ДЛЯ АВТОМАТИЗАЦИИ

3.1 Предпосылки автоматизации исследуемого процесса

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

Текущий процесс (AS-IS) исполнения документов представляет собой получение Требований отделом Канцелярии, поиск по текущему Требованию соответствующего Поручения (в случае отсутствия Требования Поручение откладывается, в случае отсутствия Поручения Требование регистрируется и по нему запрашивается Поручение у ИФНС, направившей запрос), скрепление данных файлов в формате pdf. Далее скрепленный файл распечатывается, подписывается у руководителя, по нему у Операционного департамента (ОД) запрашивается входящий номер. После выдачи номера (занимает не более 30 минут) он проставляется в виде штампа на первую страницу объединенного документа с датой и присвоенным номером (отличными от дат и номеров требования и поручения). Далее данный документ сканируется, по нему во встроенной системе IBM LotusNotes заводится карточка, регистрирующая данный документ и уведомляющая сотрудников Операционного департамента о его подготовке для исполнения. После получения уведомления сотрудник ОД открывает программу ExcelRep, вводит пароль для входа в систему, вбивает ИНН в нужное поле для поиска конкретного клиента, после чего открывает таблицу счетов и филиалов по данному контрагенту. В случае, если клиент обслуживается только в филиалах, сотрудник ОД отправляет данный входящий документ через форму IBM LotusNotes ответственным за данный филиал сотрудникам; в противном случае он продолжает работу. Начиная с первого истребуемого документа, сотрудник заходит по очереди в каждую базу, в которой должен находиться определенный документ; авторизуется в ней, вбивает ИНН и расчетный счет (последнее – в случае банковских выписок и депозитных документов) и ищет действующий документ за определенный период, указанный в требовании. После нахождения всех документов, сотрудник выгружает их в определенную папку, запрашивает по описанной выше логике номер для исходящего документа, регистрирует его и готовит шаблон ответа для ИФНС в соответствии с текущими контрагентами, счетами и найденными документами.

Таблица 6 Анализ пригодности процесса для роботизации [29]

Исходя из таблицы мы видим, что процесс абсолютно удовлетворяет по 6 критериям из 8, а именно:

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

3.2 Проектирование процесса TO-BE

Ниже описан проектируемый процесс внедрения программного робота на исследуемом предприятии. На рисунке 6 изображена Studio UiPath с работающим процессом регистрации входящего документа при использовании режима проектирования flowchart (блок-схем).

Рисунок 6 Проектирование автоматизированного процесса TO-BE (Регистрация входящего документа)