Что такое RPA? Маленькому ребенку можно сказать: «робот помоет за тебя посуду и уберется в комнате, а ты свое время можешь тратить на игры и книжки», а начальнику большой организации — «это мощный, но легкий инструмент для того, чтобы бизнес-процессы выполнялись быстрее, с меньшим количеством ошибок, используя меньшее количество ресурсов».
У роботизации огромный потенциал. Уже сейчас RPA решет целый спектр задач: мигрирует данные, создает отчеты, убирает рутину из бизнес-процессов, обучает новых сотрудников, интегрирует между собой разные системы, обеспечивает много- и омни- канальность контактных центров, автоматизирует работу с первичными учетными документами, заменяет инструментарий автоматического тестирования и список можно продолжать еще долго.
Технология RPA не новая, в том или ином виде ей уже почти 20 лет, но бум развития приходится на последние два-три года, c появлением новых, сильных игроков и больших, успешных проектов, сэкономившие компаниям миллиарды долларов и миллионы человеко-часов.
Почти всякое внедрение новой технологии начинается с пилотного проекта. Пилот RPA, обычно, проходит достаточно легко и показывает ощутимые преимущества подхода. Но, как и с многими другими технологиями, требующими серьезного изменения подхода к организации производственных процессов, следующие шаги за пилотом часто вызывают психологические трудности.
Нередко пилотный RPA-проект заканчивается МХАТовской паузой, периодом напряженного ожидания, когда уже понятно, что дело нужное, но никто не знает, как перейти от первой попытки к серьезному внедрению. Проблемы, в первую очередь организационные, создают на пути почти непреодолимую пропасть, и часто нет понятного пути ее преодоления.
В этой статье я перечислю условные топ-10 проблем, возникающие при внедрении RPA и постараюсь дать несколько практических рекомендаций на тему того, как RPA-команда может «отрастить себе крылья» и через эту пропасть перемахнуть.
Итак, как же можно максимально себе затруднить внедрение новой технологии?
Ошибка, заключающаяся в том, что решая с помощью RPA текущие задачи, мы не думаем о стратегической цели нашей работы.
На поверхности, RPA это палочка-выручалочка для тех, у кого в работе много скуки: перенести данные из одной системы в другую, составить отчет по материалам из нескольких баз данных, автоматизировать рутинные задачи бухгалтера или администратора и т.д.
Возникает соблазн остановиться на том, чтобы просто держать инструментарий наготове и при обнаружении такой ситуации начинать ее ad-hoc роботизировать, или, как говорят, «написать скриптик». Но, проблема здесь в том, что для того, чтобы получить в глазах руководства компании вес и значение, любая инициатива должна иметь четко сформулированную глобальную цель и ясный план по ее достижению.
Без такого плана практически невозможно добиться масштабности инициативы, а без масштабности никто в большой компании и не заметит, что что-то такое было, RPA останется игрушкой в руках админов, которым когда-то прилетела задачка «посмотреть, что это за роботы такие». А не заметят — не помогут создать команду, не дадут команде денег, спишут все направление как бесперспективное.
Чтобы избежать этой проблемы, к моменту, когда запускается пилотный проект, уже нужно четко понимать, какую цель компания хочет достигнуть с помощью RPA, иметь высокоуровневый стратегический план с контрольными точками, метриками и т.д. Почему не к моменту окончания? Потому что выбор пилотного процесса, и оценка его результатов — все это закономерно вытекает из выбора стратегической цели и методов ее достижения.
Ошибка заключается в том, что RPA воспринимают как инструмент для команды ИТ, и полностью передают всю инициативу туда, не подключая бизнес и не создавая кросс-функциональную команду
Мы часто видим, что инерция мышления заставляет людей рассуждать так: «Это программный продукт, а значит к бизнесу он отношения не имеет. Пусть с ним разбираются специалисты.»
RPA, в первую очередь, решает задачи и проблемы бизнеса, оптимизируя и автоматизируя существующие в компании бизнес-процессы. О том, что, где и как нужно делать, знает только бизнес, а значит, команда, занимающаяся роботизацией обязательно должна включать представителей тех, для кого она работает, знать о том, где больше всего рутины и неэффективных решений, на которые стоит обратить внимание в первую очередь.
Бизнес, помня о том, что «айтишники» все время требует ответов на разные сложные вопросы и вообще мешают прогрессу, решает, что для RPA можно обойтись и своими силами и силами внешних подрядчиков. При этом, конечно, расчет на то, что не будет многомесячных согласований, не надо будет писать документацию, запрашивать учетные записи и все то, что так мешает быстрой и эффективной работе.
Конечно, почти в любом крупном российском предприятии количество административных процедур, требующееся для того, чтобы создать новый продукт или сервис, поражает воображение. Но надо понимать, что это, чаще всего, не прихоть и бюрократия, а реальная, жизненная необходимость.
Внедряя даже такое «легкое» и «простое» решение, как RPA вы все равно должны думать об обеспечении безопасности, об инфраструктуре, о мониторинге роботов и о миллионе других вещей, с которыми бизнес не справится без ИТ. Неплохо, когда бизнес пробует посмотреть на роботов, не ожидая, пока к нему придут с этой инициативой, неплохо, когда бизнес-пользователи сами пишут для себя процессы, но, конечно, в рамках компании, не привлечь ДИТ к инициативе с момента ее старта — это катастрофа.
Без ИТ можно забыть про масштабирование решения, про его нормальную поддержку, не говоря уже о том, что часто роботов нужно оптимизировать, используя API, скрипты Powershell, интеграцию со скриптами на Python и прочими, малопонятными бизнесу вещами.
А еще придется преодолевать синдром "Not invented here", а у «айтишников» он силен, как ни у кого другого.
Частая ошибка, происходящая от того, что после первого, успешного шага, команде кажется, что ей все по плечу. Выбираются сложные для автоматизации процессы, а еще бывает и еще хуже, когда их случайным образом назначают по политическим или иным причинам, не задумываясь над тем, зачем этот процесс попадает к команде RPA.
При выборе процессов для роботизации нужно останавливаться на тех, которые могут принести наибольшую пользу при наименьших затратах. Но говоря о пользе, стоит задуматься, что это может быть один из многих факторов, приоритет каждого из которых зависит от конкретного момента:
С другой стороны, есть несколько причин, почему от роботизации процесса стоит отказаться, или, как минимум, как следует над ней задуматься:
При этом самым главным критерием выбора всегда должно оставаться одно: комплиментарность процесса стратегической цели инициативы по роботизации.
В роботизации как никогда верно правило Парето. Чаще всего, можно быстро роботизировать тот или иной процесс почти целиком, а потом еще месяц-два биться над каким-нибудь «маленьким» его кусочком, который оказался сложно формализуем, или требует сложных технических решений, чтобы безотказно работать.
В таком случае имеет смысл себя спросить о том, хотим ли мы иметь 100% автоматизации процесса или то, что мы уже сделали, вполне достаточно для того, чтобы принести компании пользу, а команду RPA переключить на другую задачу? Почти всегда можно перестроить процесс так, чтобы робот сделал всю «грязную», подготовительную работу, передал ее результаты человеку для принятия решения, а потом робот выполнил рутинные действия для завершения процесса. Можно сказать, что 80% автоматизации — более чем достаточно для большинства задач.
В начале пути роботизации, когда еще команда не набрала достаточного опыта, имеет смысл выбирать легко достижимые цели, которые позволят приобрести уверенность в собственных силах, набрать вес в глазах компании, и не стоит боятся компромиссных решений.
Ошибка, возникающая, когда не делают разницы между проектами на, например, SAP и RPA.
Максимальный эффект роботизация дает там, где мы тратим на нее значительно меньше времени и усилий, чем на «полноценную» автоматизацию. А это значит, что нужно всеми силами стремится к тому, чтобы роботизация была максимально быстрой, а трудозатраты на нее — существенно и доказуемо меньшими, чем другие варианты решения той же задачи.
Чаще всего, в больших предприятиях, эта проблема выражается в том, что принято любое ИТ-решение прогонять через целый ряд проверок и согласований, а весь проект вести, используя «тяжелую» методологию разработки, такую как RUP.
Этот подход, хорошо себя зарекомендовавший при создании и поддержке больших решений, дает сбои на проектах, где весь цикл должен длиться 2-3 месяца. Если процесс можно автоматизировать в два-три раза быстрее, чем провести все необходимые согласования — нужно менять подход, обеспечивать для роботов возможность быстрее проходить проверки, сопровождать их меньшим количеством документации, и т.д.
Там, где уже используется Agile подход, хотя бы для некоторых продуктов, имеет смысл узнать, нельзя ли и разработку роботов отнести к этой категории.
Там, где еще все «серьезно» нужно много времени уделить обучению и разъяснениям того, что такое роботы, с чем их едят и почему к ним нужно особенное отношение.
Следствие того, что легко давшийся пилот создает «головокружение от успехов», и кажется, что дальше можно идти от победы к победе, не прикладывая к этом серьезных усилий.
Для создания пилота обычно скачать из интернета бесплатную версию платформы (например UiPath Community Edition или RPA Express) и начать творить. Силами команды из двух-трех человек вполне реалистично сделать и запустить первый процесс за пару месяцев. Но для большой компании этого недостаточно, нужны десятки процессов, роботизирующих бизнес-процессы в разных областях, выполняющихся на множестве разнообразных компьютеров, серверов, виртуальных машин.
Начало полноценного внедрения невозможно без того, чтобы собрать костяк команды, обучить специалистов, получить необходимые ресурсы, и т.д. и т.п. А значит, все это надо продумать, подготовить и согласовать заранее, нужно найти тех, кому задача будет реально интересна.
Часто сложность этой задачи недооценивается на начальных этапах проекта, что, в дальнейшем, приводит к неприятным разочарованиям.
Ошибка возникает тогда, когда эффект от внедрения PRA рассчитывают, исходя только из очевидной метрики — «экономия FTE». Проблема здесь в том, что в наших реалиях, где зарплата в регионах сопоставима со стоимостью лицензии робота, эта метрика дает сбой, оставляя большинство процессов за чертой, когда положительный ROI можно получить за 9-12 месяцев (в США или Западной Европе это обычно около 6 месяцев).
Здесь нужно понимать, что эффективность RPA измеряется более сложным образом, нежели просто экономия человеко-часов. Надо учитывать и то, что процессы начинают работать много быстрее, разгружая многонедельные «листы ожидания», и то, что снижается процент ошибок, которые раньше привносились «человеческим фактором» и невозможностью добавить в долгий и сложный процесс дополнительные проверки.
Есть и еще более сложно измеримые показатели, такие как рост удовлетворенности сотрудников своей работой (а это значит меньше увольнений, а это значит — меньше нагрузки на HR), улучшение отношений с клиентами (их запросы обрабатываются быстрее и без ошибок), лучшая управляемость процессов и еще множество других факторов.
В краткосрочной перспективе сложно создать модель расчета эффективности RPA, которая полностью учтет все эти факторы, но это не значит, что к этому не нужно стремится и что такая модель, хоть и неполная или предварительная, не должна существовать с первых дней существования программы роботизации.
К слову, когда при расчете себестоимости учитывается, что робот работает 24x7, не болеет, не занимает место в офисе, за него не надо платить налоги и отчисления в пенсионный фонд и т.д. — выясняется, что стоимость робота вполне сопоставима со стоимостью сотрудника. А это значит, что живые люди должны приносить реальную пользу, делая интересную работу, а не перекладывая документы из одной папки в другую.
Если лица, принимающие решения, не понимают, что такое RPA, зачем он нужен и почему компания им занимается, далеко по пути роботизации пройти не получится.
Очень часто недооценивается необходимость согласованной стратегии внедрения RPA, вовлекающей в себя все уровни компании, от топ-менеджмента, до основных исполнителей.
Особенно это важно на начальном этапе, когда программа еще себя не зарекомендовала, и нужно заниматься ее популяризацией.
Заручиться поддержкой нужно и сверху: чтобы компания публично поддерживала внедрение роботов, об этом говорилось на общих собраниях, подразделениям ставились цели по автоматизации и т.д. Но поддержка нужна и снизу: сотрудники должны понимать, что роботы не отнимают у них работу, а забирают скучные рутинные задачи, не вмешиваются в решение проблем, а упрощают их решение. Команда ИТ должна понимать, что их участие не просто нужно, но и необходимо, бизнес должен понимать, что за ними остается решающее слово в том, как будет проводится роботизация их процессов, СБ должна быть уверена, что роботы не создают в безопасности зияющую дыру и так далее.
В целом объяснить важным людям компании, зачем именно им нужен RPA и как он именно им поможет — возможно, самое сложное, но и самое важное дело, которое придется сделать команде.
Двигаясь вперед, не совсем понимая, зачем, куда и как мы собираемся это делать — частая, но, к сожалению, от того не менее важная проблема.
Стратегическое развитие предполагает четко определенную цель, которую должна разделять вся команда RPA и которая должна быть согласована с лицами, принимающими решения.
У такого развития должны быть ориентиры, жестко привязанные ко времени «к 2020 году сделать 10 процессов», «до конца Q2'19 роботизировать процессы HR на 50%», «создать библиотеку из не менее чем 50 переиспользуемых компонентов в этом месяце», «перевести 20% автоматизированных тестов в разработке на платформу RPA».
Должны быть метрики: NPS, экономия FTE, утилизация роботов и так далее.
Должны быть определены (или запланированы к определению)роли в команде, критерии отбора процессов, критерии измерения успешности и многое другое.
Все это, в совокупности, поможет не только понимать, хорошо или плохо движется внедрение RPA в компании, но и убедительно объяснять это заинтересованному начальству или руководству смежных подразделений. Людям будет намного проще участвовать в инициативе, если им могут понятно и четко объяснить, что она делает и как.
Так что, при желании, второй цитатой для этого пункта может смело ставить незабвенное
RPA может стать мощнейшим инструментом для помощи в цифровой трансформации компании, а значит стратегия использования роботизации должна быть частью общей стратегии цифровизации.
Но для того, чтобы роботы помогли компании двигаться по пути в цифровое будущее, недостаточно сказать волшебные слова «RPA», «ML», «OCR», необходимо еще и немного потрудиться над тем, чтобы за этими словами стояла дружная, мотивированная и целеустремленная команда, имеющая четкий план действий и поддержку на всех уровнях организации, от руководства до простых сотрудников.
Разумеется, это не просто, разумеется, в реальной жизни пропасть на пути иногда, кажется непреодолимой.
Но, завершая статью еще одной цитатой из Карла Клаузевица:
При подготовке статьи использовались материалы
У роботизации огромный потенциал. Уже сейчас RPA решет целый спектр задач: мигрирует данные, создает отчеты, убирает рутину из бизнес-процессов, обучает новых сотрудников, интегрирует между собой разные системы, обеспечивает много- и омни- канальность контактных центров, автоматизирует работу с первичными учетными документами, заменяет инструментарий автоматического тестирования и список можно продолжать еще долго.
Технология RPA не новая, в том или ином виде ей уже почти 20 лет, но бум развития приходится на последние два-три года, c появлением новых, сильных игроков и больших, успешных проектов, сэкономившие компаниям миллиарды долларов и миллионы человеко-часов.
Почти всякое внедрение новой технологии начинается с пилотного проекта. Пилот RPA, обычно, проходит достаточно легко и показывает ощутимые преимущества подхода. Но, как и с многими другими технологиями, требующими серьезного изменения подхода к организации производственных процессов, следующие шаги за пилотом часто вызывают психологические трудности.
Нередко пилотный RPA-проект заканчивается МХАТовской паузой, периодом напряженного ожидания, когда уже понятно, что дело нужное, но никто не знает, как перейти от первой попытки к серьезному внедрению. Проблемы, в первую очередь организационные, создают на пути почти непреодолимую пропасть, и часто нет понятного пути ее преодоления.
В этой статье я перечислю условные топ-10 проблем, возникающие при внедрении RPA и постараюсь дать несколько практических рекомендаций на тему того, как RPA-команда может «отрастить себе крылья» и через эту пропасть перемахнуть.
Итак, как же можно максимально себе затруднить внедрение новой технологии?
Использовать тактический подход к RPA
Тактика без стратегии — суета перед поражением.
Сунь-Цзы, «Искусство войны»
Ошибка, заключающаяся в том, что решая с помощью RPA текущие задачи, мы не думаем о стратегической цели нашей работы.
На поверхности, RPA это палочка-выручалочка для тех, у кого в работе много скуки: перенести данные из одной системы в другую, составить отчет по материалам из нескольких баз данных, автоматизировать рутинные задачи бухгалтера или администратора и т.д.
Возникает соблазн остановиться на том, чтобы просто держать инструментарий наготове и при обнаружении такой ситуации начинать ее ad-hoc роботизировать, или, как говорят, «написать скриптик». Но, проблема здесь в том, что для того, чтобы получить в глазах руководства компании вес и значение, любая инициатива должна иметь четко сформулированную глобальную цель и ясный план по ее достижению.
Без такого плана практически невозможно добиться масштабности инициативы, а без масштабности никто в большой компании и не заметит, что что-то такое было, RPA останется игрушкой в руках админов, которым когда-то прилетела задачка «посмотреть, что это за роботы такие». А не заметят — не помогут создать команду, не дадут команде денег, спишут все направление как бесперспективное.
Чтобы избежать этой проблемы, к моменту, когда запускается пилотный проект, уже нужно четко понимать, какую цель компания хочет достигнуть с помощью RPA, иметь высокоуровневый стратегический план с контрольными точками, метриками и т.д. Почему не к моменту окончания? Потому что выбор пилотного процесса, и оценка его результатов — все это закономерно вытекает из выбора стратегической цели и методов ее достижения.
Внедрять RPA как чисто ИТ-решение
Война — это продолжение политики.
Карл фон Клаузевиц, «О войне»
Ошибка заключается в том, что RPA воспринимают как инструмент для команды ИТ, и полностью передают всю инициативу туда, не подключая бизнес и не создавая кросс-функциональную команду
Мы часто видим, что инерция мышления заставляет людей рассуждать так: «Это программный продукт, а значит к бизнесу он отношения не имеет. Пусть с ним разбираются специалисты.»
RPA, в первую очередь, решает задачи и проблемы бизнеса, оптимизируя и автоматизируя существующие в компании бизнес-процессы. О том, что, где и как нужно делать, знает только бизнес, а значит, команда, занимающаяся роботизацией обязательно должна включать представителей тех, для кого она работает, знать о том, где больше всего рутины и неэффективных решений, на которые стоит обратить внимание в первую очередь.
Или наоборот, забыть об ИТ
Жители царств У и Юе не любят друг друга. Но если они будут переправляться через реку в одной лодке и будут застигнуты бурей, они станут спасать друг друга, как правая рука левую.
Сунь-Цзы, «Искусство войны»
Бизнес, помня о том, что «айтишники» все время требует ответов на разные сложные вопросы и вообще мешают прогрессу, решает, что для RPA можно обойтись и своими силами и силами внешних подрядчиков. При этом, конечно, расчет на то, что не будет многомесячных согласований, не надо будет писать документацию, запрашивать учетные записи и все то, что так мешает быстрой и эффективной работе.
Конечно, почти в любом крупном российском предприятии количество административных процедур, требующееся для того, чтобы создать новый продукт или сервис, поражает воображение. Но надо понимать, что это, чаще всего, не прихоть и бюрократия, а реальная, жизненная необходимость.
Внедряя даже такое «легкое» и «простое» решение, как RPA вы все равно должны думать об обеспечении безопасности, об инфраструктуре, о мониторинге роботов и о миллионе других вещей, с которыми бизнес не справится без ИТ. Неплохо, когда бизнес пробует посмотреть на роботов, не ожидая, пока к нему придут с этой инициативой, неплохо, когда бизнес-пользователи сами пишут для себя процессы, но, конечно, в рамках компании, не привлечь ДИТ к инициативе с момента ее старта — это катастрофа.
Без ИТ можно забыть про масштабирование решения, про его нормальную поддержку, не говоря уже о том, что часто роботов нужно оптимизировать, используя API, скрипты Powershell, интеграцию со скриптами на Python и прочими, малопонятными бизнесу вещами.
А еще придется преодолевать синдром "Not invented here", а у «айтишников» он силен, как ни у кого другого.
Автоматизации «не тех» процессов
Если хотите одержать победу, бейте в самое сердце противника.
Карл фон Клаузевиц, «О войне»
Частая ошибка, происходящая от того, что после первого, успешного шага, команде кажется, что ей все по плечу. Выбираются сложные для автоматизации процессы, а еще бывает и еще хуже, когда их случайным образом назначают по политическим или иным причинам, не задумываясь над тем, зачем этот процесс попадает к команде RPA.
При выборе процессов для роботизации нужно останавливаться на тех, которые могут принести наибольшую пользу при наименьших затратах. Но говоря о пользе, стоит задуматься, что это может быть один из многих факторов, приоритет каждого из которых зависит от конкретного момента:
- Экономия трудозатрат и других ресурсов компании
- Мотивация сотрудников
- Улучшение качества обслуживания клиентов
- Привлечение команд, которые раньше об RPA и слышать не хотели
- Повышение значимости RPA в глазах людей, принимающих решения
С другой стороны, есть несколько причин, почему от роботизации процесса стоит отказаться, или, как минимум, как следует над ней задуматься:
- Недоказуемая экономия ресурсов
- Неформализуемый бизнес-процесс
- Незаметность процесса для лиц, принимающих решения
- Жесткое неприятие роботизации со стороны тех, кому она призвана помочь
- Технические факторы: сложность роботизации, система, которую собираются скоро отключать, проблемы с информационной безопасностью и т.д.
При этом самым главным критерием выбора всегда должно оставаться одно: комплиментарность процесса стратегической цели инициативы по роботизации.
Пытаться добиться «тотальной» роботизации
Война любит победу и не любит продолжительности.
Карл фон Клаузевиц, «О войне»
В роботизации как никогда верно правило Парето. Чаще всего, можно быстро роботизировать тот или иной процесс почти целиком, а потом еще месяц-два биться над каким-нибудь «маленьким» его кусочком, который оказался сложно формализуем, или требует сложных технических решений, чтобы безотказно работать.
В таком случае имеет смысл себя спросить о том, хотим ли мы иметь 100% автоматизации процесса или то, что мы уже сделали, вполне достаточно для того, чтобы принести компании пользу, а команду RPA переключить на другую задачу? Почти всегда можно перестроить процесс так, чтобы робот сделал всю «грязную», подготовительную работу, передал ее результаты человеку для принятия решения, а потом робот выполнил рутинные действия для завершения процесса. Можно сказать, что 80% автоматизации — более чем достаточно для большинства задач.
В начале пути роботизации, когда еще команда не набрала достаточного опыта, имеет смысл выбирать легко достижимые цели, которые позволят приобрести уверенность в собственных силах, набрать вес в глазах компании, и не стоит боятся компромиссных решений.
Использовать неподходящую методологию внедрения
Война — область случайности: только в ней этой незнакомке отводится такой широкий простор, потому что нигде человеческая деятельность не соприкасается так с ней всеми своими сторонами, как на войне.
Карл фон Клаузевиц, «О войне»
Ошибка, возникающая, когда не делают разницы между проектами на, например, SAP и RPA.
Максимальный эффект роботизация дает там, где мы тратим на нее значительно меньше времени и усилий, чем на «полноценную» автоматизацию. А это значит, что нужно всеми силами стремится к тому, чтобы роботизация была максимально быстрой, а трудозатраты на нее — существенно и доказуемо меньшими, чем другие варианты решения той же задачи.
Чаще всего, в больших предприятиях, эта проблема выражается в том, что принято любое ИТ-решение прогонять через целый ряд проверок и согласований, а весь проект вести, используя «тяжелую» методологию разработки, такую как RUP.
Этот подход, хорошо себя зарекомендовавший при создании и поддержке больших решений, дает сбои на проектах, где весь цикл должен длиться 2-3 месяца. Если процесс можно автоматизировать в два-три раза быстрее, чем провести все необходимые согласования — нужно менять подход, обеспечивать для роботов возможность быстрее проходить проверки, сопровождать их меньшим количеством документации, и т.д.
Там, где уже используется Agile подход, хотя бы для некоторых продуктов, имеет смысл узнать, нельзя ли и разработку роботов отнести к этой категории.
Там, где еще все «серьезно» нужно много времени уделить обучению и разъяснениям того, что такое роботы, с чем их едят и почему к ним нужно особенное отношение.
Недооценить необходимые для полноценного внедрения компетенции и ресурсы
Если у армии нет обоза, она гибнет; если нет провианта, она гибнет; если нет запасов, она гибнет.
Сунь-Цзы, «Искусство войны»
Следствие того, что легко давшийся пилот создает «головокружение от успехов», и кажется, что дальше можно идти от победы к победе, не прикладывая к этом серьезных усилий.
Для создания пилота обычно скачать из интернета бесплатную версию платформы (например UiPath Community Edition или RPA Express) и начать творить. Силами команды из двух-трех человек вполне реалистично сделать и запустить первый процесс за пару месяцев. Но для большой компании этого недостаточно, нужны десятки процессов, роботизирующих бизнес-процессы в разных областях, выполняющихся на множестве разнообразных компьютеров, серверов, виртуальных машин.
Начало полноценного внедрения невозможно без того, чтобы собрать костяк команды, обучить специалистов, получить необходимые ресурсы, и т.д. и т.п. А значит, все это надо продумать, подготовить и согласовать заранее, нужно найти тех, кому задача будет реально интересна.
Часто сложность этой задачи недооценивается на начальных этапах проекта, что, в дальнейшем, приводит к неприятным разочарованиям.
Неправильно рассчитывать эффект от внедрения
Испокон века лишь великие победы вели к великим результатам.
Карл фон Клаузевиц, «О войне»
Ошибка возникает тогда, когда эффект от внедрения PRA рассчитывают, исходя только из очевидной метрики — «экономия FTE». Проблема здесь в том, что в наших реалиях, где зарплата в регионах сопоставима со стоимостью лицензии робота, эта метрика дает сбой, оставляя большинство процессов за чертой, когда положительный ROI можно получить за 9-12 месяцев (в США или Западной Европе это обычно около 6 месяцев).
Здесь нужно понимать, что эффективность RPA измеряется более сложным образом, нежели просто экономия человеко-часов. Надо учитывать и то, что процессы начинают работать много быстрее, разгружая многонедельные «листы ожидания», и то, что снижается процент ошибок, которые раньше привносились «человеческим фактором» и невозможностью добавить в долгий и сложный процесс дополнительные проверки.
Есть и еще более сложно измеримые показатели, такие как рост удовлетворенности сотрудников своей работой (а это значит меньше увольнений, а это значит — меньше нагрузки на HR), улучшение отношений с клиентами (их запросы обрабатываются быстрее и без ошибок), лучшая управляемость процессов и еще множество других факторов.
В краткосрочной перспективе сложно создать модель расчета эффективности RPA, которая полностью учтет все эти факторы, но это не значит, что к этому не нужно стремится и что такая модель, хоть и неполная или предварительная, не должна существовать с первых дней существования программы роботизации.
К слову, когда при расчете себестоимости учитывается, что робот работает 24x7, не болеет, не занимает место в офисе, за него не надо платить налоги и отчисления в пенсионный фонд и т.д. — выясняется, что стоимость робота вполне сопоставима со стоимостью сотрудника. А это значит, что живые люди должны приносить реальную пользу, делая интересную работу, а не перекладывая документы из одной папки в другую.
Не позаботиться о вовлечения ключевых сотрудников компании
Военные должны подчиняться политикам.
Карл фон Клаузевиц, «О войне»
Если лица, принимающие решения, не понимают, что такое RPA, зачем он нужен и почему компания им занимается, далеко по пути роботизации пройти не получится.
Очень часто недооценивается необходимость согласованной стратегии внедрения RPA, вовлекающей в себя все уровни компании, от топ-менеджмента, до основных исполнителей.
Особенно это важно на начальном этапе, когда программа еще себя не зарекомендовала, и нужно заниматься ее популяризацией.
Заручиться поддержкой нужно и сверху: чтобы компания публично поддерживала внедрение роботов, об этом говорилось на общих собраниях, подразделениям ставились цели по автоматизации и т.д. Но поддержка нужна и снизу: сотрудники должны понимать, что роботы не отнимают у них работу, а забирают скучные рутинные задачи, не вмешиваются в решение проблем, а упрощают их решение. Команда ИТ должна понимать, что их участие не просто нужно, но и необходимо, бизнес должен понимать, что за ними остается решающее слово в том, как будет проводится роботизация их процессов, СБ должна быть уверена, что роботы не создают в безопасности зияющую дыру и так далее.
В целом объяснить важным людям компании, зачем именно им нужен RPA и как он именно им поможет — возможно, самое сложное, но и самое важное дело, которое придется сделать команде.
Забыть составить четко сформулированный план
Самое трудное — возможно лучше подготовить победу; это — незаметная заслуга стратегии, за которую она редко получает похвалу.
Карл фон Клаузевиц, «О войне»
Двигаясь вперед, не совсем понимая, зачем, куда и как мы собираемся это делать — частая, но, к сожалению, от того не менее важная проблема.
Стратегическое развитие предполагает четко определенную цель, которую должна разделять вся команда RPA и которая должна быть согласована с лицами, принимающими решения.
У такого развития должны быть ориентиры, жестко привязанные ко времени «к 2020 году сделать 10 процессов», «до конца Q2'19 роботизировать процессы HR на 50%», «создать библиотеку из не менее чем 50 переиспользуемых компонентов в этом месяце», «перевести 20% автоматизированных тестов в разработке на платформу RPA».
Должны быть метрики: NPS, экономия FTE, утилизация роботов и так далее.
Должны быть определены (или запланированы к определению)роли в команде, критерии отбора процессов, критерии измерения успешности и многое другое.
Все это, в совокупности, поможет не только понимать, хорошо или плохо движется внедрение RPA в компании, но и убедительно объяснять это заинтересованному начальству или руководству смежных подразделений. Людям будет намного проще участвовать в инициативе, если им могут понятно и четко объяснить, что она делает и как.
Так что, при желании, второй цитатой для этого пункта может смело ставить незабвенное
Лучше день потерять, зато потом за пять минут долететь.
Г. Гриф, «Крылья, ноги и хвосты»
В заключение
RPA может стать мощнейшим инструментом для помощи в цифровой трансформации компании, а значит стратегия использования роботизации должна быть частью общей стратегии цифровизации.
Но для того, чтобы роботы помогли компании двигаться по пути в цифровое будущее, недостаточно сказать волшебные слова «RPA», «ML», «OCR», необходимо еще и немного потрудиться над тем, чтобы за этими словами стояла дружная, мотивированная и целеустремленная команда, имеющая четкий план действий и поддержку на всех уровнях организации, от руководства до простых сотрудников.
Разумеется, это не просто, разумеется, в реальной жизни пропасть на пути иногда, кажется непреодолимой.
Но, завершая статью еще одной цитатой из Карла Клаузевица:
Без смелости выдающийся полководец немыслим… Ее мы считаем первым условием полководческой карьеры.
Ссылки на исходники
При подготовке статьи использовались материалы
- CSO (директор по стратегии) UiPath Vargha Moayed «From pilot to full scale RPA deployment»
- Карл Филипп Готтлиб фон Клаузевиц, О войне
- Сун Цзы, Искусство войны
- Картинки роботов из Mobile Fighter G Gundam
