Что такое 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
Комментарии (4)
WizardryIB
11.03.2019 08:23Моё отношение к RPA неоднозначно. С одной стороны быстрое получение эффекта для владельца бизнеса, сокращение FTE, освобождение от операций и сотрудников в бизнес процессах, предоставление легкого пути в достижении краткосрочных результатов… С другой — моральное право и ответственность за обеспечение новых рабочих мест, создание новой прослойки жестко связанного проприетарного программного обеспечения, цементирование и потеря гибкости внедрения новых систем…
ilya_kochetov Автор
11.03.2019 10:22моральное право и ответственность за обеспечение новых рабочих мест
.
Если у вас есть реальные кейсы про сокращения — поделитесь плиз, очень интересно!
В тех случаях, с которыми знаком я, внедрение RPA не приводило к сокращению штатных единиц. Один раз, на моей практике, роботы заменили кучу фрилансеров, выполнявших работу аля Yandex.Toloka или Amazon Turk, вот тут да, от их услуг отказались.
В остальных ситуациях, обычно, происходит совсем другое — у компаний есть проблема перегруженности сотрудников, отсутствия возможности развивать то ли иное направление из-за дефицита кадров, то, что умные люди большую часть времени «перекладывают бумажки». Внедрение RPA приводило к тому, что «процессы раскатывались», люди переставали работать сверхурочно и начинали приносить реальную пользу, работая головой.
Наверное особенно «жесткое» руководство в период кризиса будет пытаться сокращать штаты с помощью роботов, но в большинстве случаев это даже наоборот, повышает качество жизни.
создание новой прослойки жестко связанного проприетарного программного обеспечения
Сейчас у большинства компаний продающих роботов модель лицензирования — ежегодная подписка, аля Office 365. И есть у меня кейс, когда люди решили уйти от текущей платформы к нам. Причем за буквально месяц до окончания срока подписки, когда их роботы перестали бы работать. Я был уверен, что это будет ситуация «ужаса без конца», потому что разработчики видели нашу платформу впервые, но по итогам все прошло быстро и четко (мы помогали, но чисто техническими консультациями).
Как показал опыт, 80% трудозатрат на роботизацию — это формализация бизнес-процесса (или его роботизируемых кусков). В самом роботе, код процесса, сам по себе, служит некой «документацией». При переходе на другую платформу, на уже отлаженном и отработанном процессе, это чисто техническая, не очень сложная задача.
Сами роботы или процессы — намного легче и проще, чем «правильная» интеграция, они обычно пишутся очень быстро и сильно меньше по размерам, чем код полноценных систем.
цементирование и потеря гибкости внедрения новых систем
вот здесь не соглашусь категорически. Как раз это — супер-преимущество роботов, если что-то поменялось, робота можно без особых потерь переписать, за то же, или меньшее время, чем потребовалось бы на переобучение сотрудников и уж точно за много меньше время и деньги, чем потребовалось бы на переделку интеграционного слоя (если мы не говорим про хорошо сделанные микросервисы, конечно, но где они есть :)
zxweed
софт, записывающий действия пользователя в макросы — известен уже много десятилетий, с чего вы решили, что это — новая революция?
ilya_kochetov Автор
TL;DR версия: целое всегда есть нечто большее, чем простая сумма его частей, RPA это подрывная инновация
Все так, макросы начали использовать в 80ых. И BPM системы, которым RPA обязано многим, с 90ых годов начинают отсчет. Автоматизированное тестирование, технология, которая с RPA имеет очень много общего, начали серьезно использовать примерно 20 лет назад.
Тут имеет смысл привести аналогию с, например, светодиодами. Они известны с начала XX века, синий светодиод с 90ых годов, но именно революция светодиодная началась не так давно, если помните, был момент, когда все ставили на люминисцентные лампы, как замену лампам накаливания.
Точно так же можно вспомнить время, которое прошло после появления СМС до момента, когда появилась ICQ, до момента, когда мы почти перестали друг другу звонить и стали пользоваться мессенджерами.
В жизненном цикле инновации
RPA сейчас только вошла в третью стадию, стадию зрелости. Для подрывных инноваций это как раз тот момент, когда вокруг больше всего хайпа, но, одновременно, момент, когда жизнь людей начинает активно меняться под влиянием нововведения.
Все компоненты RPA существуют не первый год. Тот же UiPath на рынке с 2005, но только сейчас можно говорить реально о том, что это не просто «еще один» инструмент, а инструмент, который, при правильном использовании может изменить то, как рождаются, живут и умирают бизнес-процессы в огромной компании.
С чисто технической точки зрения, от макросов RPA отличает возможность централизованного внедрения, управления, и мониторинга, умение работать с разными системами на разных платформах и в разных средах, серьезное отношение к безопасности и т.д. и т.п.