Дипломная работа: Автоматизация процесса исполнения налоговых документов в банковской сфере посредством внедрения технологии RPA

Из таблицы 11 мы можем отметить, что дольше всего происходит процесс исполнения документа, который оптимизировать крайне сложно (в т.ч. и ввиду хаотичности данных в ряде внутренних систем Заказчика, которые ведутся в условиях сжатых сроков и большого количества ручного труда). При этом все 3 предлагаемые решения примерно в равный период времени выполняют весь процесс. Некоторые задержки могут возникать часто по причине долго отклика программы (для Робота) или баз данных программы (для BPMS).

4) Количество ошибок. В текущем процессе количество ошибок достигает 12% в год. При внедрении ПО он должен снизиться до 0,5%. При внедрении BPMS и RPA (исходя из текущей практики компаний) - до 1,3%.

5) FTE. FTE (Full-Time Equivalent) - эквивалент полной занятости (ЭПЗ), мера включенности сотрудника в проект. Так, FTE, равный 1.0, означает, что человек работает при полной занятости, FTE, равный 0.5, говорит о том, что сотрудник работает неполный рабочий день.

Можно предположить, что, если все сотрудники (4) работают полный рабочий день, FTE будет равно 4, однако данные следует подтвердить расчетами. Для расчета необходимо знать количество сотрудников (4), длительность рабочей недели (40 ч), количество недель в году (52), а также количество часов в году (40*52 = 2080 ч).

Итак, для процесса AS-IS сначала определим количество часов в год, которое затрачивается на работу сотрудниками: 4*40*52 = 8 320 полных рабочих часов. Далее делим итоговое количество часов на расчетный период в часах: 8 320/2080 = 4. Это и есть искомый ЭПЗ (FTE).

Для BPMS-решения: (2 сотрудника * 20ч в неделю(полставки) * 52 недели /2полугодия) /2080 = 0,5.

Для RPA-решения: (1 сотрудник * 20ч в неделю(полставки) * 52 недели/ 2полугодия) /2080 = 0,25.

6) Управление рисками. Один из наиболее спорных и сложных моментов расчета, на наш взгляд - это расчет возможных рисков, т.к. он должен включать не только затраты на сами риски (в % или руб.), но и, в идеале, сумму по возможному нивелированию рисков. А так как в текущей ситуации предсказывать риски непросто даже профессионалам (ввиду экономических и политических изменений, не говоря уже о социальных, которые также значительно влияю на процессы), это несколько затрудняет решение. В данном случае приведем данные, исходя из опыта компании, которая на протяжении 3 лет успешно работает на рынке RPA и разработки ПО. Итак, зафиксируем в таблице 12 по каждому пункту %, который потребует существенных доработок системы, что, непременно, скажется на затратах компании.

Таблица 12 Сравнительный анализ вариантов реализации текущего процесса

Так, исходя из таблицы 12, можно прийти к выводу, что наименее ресурсозатратным способом автоматизации является внедрение программных роботов. В разрезе 3 лет (срок принят за основу в связи с тем, что видимый и значительный эффект возникает примерно по прошествии этого времени, к тому же, после 1 года затратами являются только лицензии, а это значительно разнится с затратами на сотрудников, эксплуатационные расходы и штрафы) это сэкономит компании 17 803 611 руб. (25 904 400 - 8 100 789) и 1 219 277 руб. - по сравнению с текущей ситуацией в первый год внедрения. Количество ошибок при этом снизится в 9 раз, а длительность выполнения 1 процесса - в 2,5 раза (27/10,2).

По сравнению с индивидуальной разработкой ПО в первый год RPA сэкономит 4 528 537,04 руб., за 3 года - 6 155 971 руб. (во 2 и последующие годы затраты на ПО рассматриваются с точки зрения технической поддержки, исходя из того, что в год разработчик тратит около 330,4 ч при ставке 3500руб./ч - итого 1 156 400 руб.). Также нужно учитывать, что роботов внедрять в среднем 3 раза быстрее, чем разрабатывать собственное ПО. При этом практически все показатели робота близки к показателям индивидуальной разработки, за исключением, разумеется, рисков. Любое изменение интерфейса или незначительные изменения данных повлекут доработку роботов. Однако, во-первых, вносить корректировки в Студию UiPath при серьезных изменениях (когда нужно будет переписывать ПО), например, при изменении внутренней системы Заказчика, ничего не стоит ни по времени, ни по средствам по сравнению с тем, сколько придется дорабатывать собственную разработку.

По сравнению с BPMS RPA экономит 3 028 729,04 руб. в первый год и 3 664 467 руб. за 3 года (последняя цифра довольно велика, т.к. нужно отметить, что лицензии по RPA и технология распознавания обходятся для клиентов дешевле в данном конкретном случае, когда интегратор является золотым партнером компаний и может себе позволить делать такие скидки для клиентов). Время разработки при этом вдвое меньше, а длительность работы решений практически идентичны - BPMS зачастую может работать даже быстрее Робота, т.к. не привязана к интерфейсам внутренних систем. Риски в BPMS составляют нечто среднее между индивидуальной разработкой и Роботом, т.к., с одной стороны, вносить корректировки не составляет большого труда, с другой - в случае изменения бизнес-процесса в BPMS, возможно, нужно будет продумывать новую логику или даже интеграцию, если речь идет о другой системе или способе получения данных. Таким образом, роботизированная автоматизация процессов планово должна окупить свои недостатки по части зависимости от интерфейсов (Робот с минимальной вероятностью может кликнуть не на ту часть экрана/кнопку/виджет, если система зависла, и выполнить другое действие) за счет относительно низкой себестоимости, сжатых сроков реализации проекта и возможности внесения пользователем корректировок в работу Робота.

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

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

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

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

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

Более детально процесс отражен на схеме, представленной в Приложении А (рис. А1). Данный процесс был изначально проанализирован на стороне компании-Заказчика (банка) - после выбора наиболее приемлемого решения стало необходимо проверить процесс на пригодность для автоматизации при помощи технологии RPA, - после чего прошел базовый отбор на потенциальную возможность для роботизации со стороны исполнителя (включая меня по части аналитики). Критерии, по которым производился отбор процесса, представлены в таблице ниже (см. Таблицу 12).

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

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

это процесс с обработкой большого количества информации;

он происходит ежедневно;

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

процесс стабилен на протяжении 7 лет;

известны все издержки, которые несет предприятие в рамках данного процесса (помимо оплаты труда самих сотрудников);