Самый очевидный способ повысить эффективность ручного труда, уменьшить влияние человеческого фактора или ускорить тот или иной процесс – это попытаться его автоматизировать. Тема с частичной или полной автоматизацией процессов стала популярной ещё во времена Генри Форда и его конвейера. В интернете и книгах можно найти огромное количество статей, примеров и пресс-релизов об успешных внедрениях. Но всегда ли все проходит гладко? О спорных или неудачных примерах говорить не принято, поэтому информация о них практически отсутствует. Сегодня мы поговорим именно о таких случаях, когда автоматизация вместо положительного эффекта приносила отрицательный и разберем несколько примеров. В конце статьи вы найдете удобный чек-лист, который поможет вам правильно оценить перспективы автоматизации ДО начала работ и поможет избежать базовых ошибок.
Дисклеймер
Понятие “неудачная автоматизация” может показаться размытым, если не определены критерии “удачной автоматизации” и методы их оценки. Предлагаю договориться, что в данной статье под этим понятием будем понимать автоматизацию, которая не принесла ожидаемый положительный эффект сразу после внедрения. В приведенных примерах я опущу названия банков, детали и подробности, суммы расходов и отрицательного эффекта, но постараюсь кратко донести суть. Также мы пропустим подробный анализ корневых причин проблемных кейсов, так как такие разборы должны быть комплексными, и по каждому из них можно написать отдельную статью.
Первое правило любой технологии заключается в том, что автоматизация эффективной операции повышает эффективность. Второе правило: автоматизация неэффективной операции увеличит неэффективность.
(Билл Гейтс, Microsoft Corporation)

Примеры неудачной автоматизации
Пример №1. Самым ярким и запоминающимся примером из моего опыта стал случай, когда один очень крупный банк, находясь под гнётом грандиозного плана по сокращению расходов за счёт автоматизации и роботизации, сократил внушительное количество сотрудников юридического департамента. Как всё произошло. Коллеги занимались исковой работой. Процесс был простой и стандартизированный, хотя и имел ряд незначительных особенностей. Банк разработал и утвердил подробный план действий: централизуем функцию, автоматизируем процесс и сокращаем высвободившиеся ресурсы. Как это часто бывает в крупных проектах, не все пошло по плану. Ближе к завершению проекта сроки начали сдвигаться и чтобы уложиться в утверждённый график, вместо полноценного пилота договорились провести упрощённый и экспресс-апробацию реализованного решения на небольшом объёме тестовых задач и только в одном регионе присутствия. Пилот завершился успешно, все были рады, типовые исковые заявления готовились и направлялись в суды автоматически. Было принято решение о переходе к промышленной эксплуатации во всей сети. Спустя буквально несколько дней работы в новом процессе выяснилось, что ПО, RPA и скрипты, которые выполняли работу за сотрудников, требуют очень тонкой настройки, а сбой в смежном ПО мгновенно парализует работу централизованного юридического конвейера. Также выяснилось, что используемые в автоматизированном процессе шаблоны документов могут отличаться в зависимости от региона применения (шаблон, используемый в пилоте в одном регионе РФ, не подходил для использования в другом регионе). Также шаблоны должны были быть тщательно перепроверены и не содержать ошибок при ручном обновлении, т.к. в этом случае конвейер начинал генерировать десятки тысяч некорректных документов, которые впоследствии требовалось отозвать (процесс отзыва не был автоматизирован), исправить и отправить заново. Также отзыв и повторная отправка документов дополнительно приводила к повышенной нагрузке на ряд внешних систем, которые вообще не имели отношения к банку. В итоге, руководство приняло решение приостановить масштабирование, дали очень жесткие поручения доработать реализованную автоматизацию, а также распорядились и о срочном обратном найме специалистов юридического департамента, которые буквально месяц назад покинули компанию с выходным пособием на руках.
Пример №2. Другая история – попытка полностью автоматизировать управление денежным обращением в одном крупном банке. Идея заключалась в том, чтобы научить системы автоматически выдавать прогноз потребности наличных в отделениях и банкоматах сети. Согласно плана это должно было сократить объем обращения денежной массы, снизить трудозатратах на формирование заказов, построение маршрутов, резервирование, упаковку, транспортировку, хранении наличных и т.п. Выделили бюджет, команда создала решение и систему, которая действительно выдавала прогноз всех нужных параметров. Но оказалось (особенно на первом этапе после внедрения), что без учета специфики объектов добиться от системы точного прогноза и корректного предложения по оптимальному количеству банкнот для подкрепления невозможно. Сотрудники были вынуждены корректировать все прогнозы руками и индивидуально по каждому объекту. Команда проекта признала недоработку и запросила дополнительный очень серьезный бюджет на разработку новых прогнозных моделей на основе ретроданных с учетом сезонности, моделей на геоданных (количество жителей, офисные площади, абоненты сотовой связи), моделей учитывающих количество рыночных сделок с недвижимостью в том или ином городе и районе, а также на сложные алгоритмы для транспортных задач с изменяющимся в процессе решения параметрами. В итоге, спустя внушительный период времени и внушительный бюджет, прогноз корректно так и не заработал для всех городов. Руководством было принято решение остановиться на достигнутом и утвердить гибридный прогноз без полной автоматизации: рекомендация от доработанной системы + ручной акцепт или корректировка сотрудником.
Избежать полного провала в этих двух историях получилось благодаря быстрому признанию руководством отрицательного эффекта, правильным выводам и готовности принимать решения о дальнейших действиях.
Пример №3. Tesla. Аналогичный хороший пример признания отрицательного эффекта от автоматизации мы видим, когда Илон Маск открыто рассказывает о случае, произошедшем на заводе Tesla. Вот как это описано в его биографии:
В какой-то момент я заметил, что конвейер сборки замедляется на станции, где дорогой, но медленный робот приклеивал на аккумуляторы полоски из стеклопластика. Вакуумные захваты робота то и дело роняли полоски, и он выдавливал слишком много клея. Выяснилось, что данный процесс практически не влияет на качество итоговой продукции, и мы просто отказались от него. Я понял, что наша первая ошибка состояла в попытке автоматизировать этот процесс и виноват я сам, поскольку настаивал на максимальной автоматизации производства.
(Илон Маск, автобиография)

Причины неудачной автоматизации
В самом начале мы договорились отложить подробный анализ факторов неудачной автоматизации для отдельной статьи. Поэтому, я просто приведу список наиболее общих и распространенных причин:
Неверно определили объект и целесообразность автоматизации.
Неверно определили цели и целевые параметры автоматизированного процесса.
Использовали неподходящие инструменты и фрэймоворки для автоматизации.
Неверно определили границы, участников, периметр систем, который будет затронут в процессе автоматизации.
Автоматизированный процесс не был принят конечными пользователями.
Чек-лист перед началом работ
Чем я хотел поделиться с вами в этой статье. За годы работы и использования разных методологий (Waterfall, Agile), концепций и философий (TQM, Lean, 6 sigma, Kaizen) и фреймворков (DMAIC, PDCA), я пришел к выводу, что одним из ключевых факторов успеха автоматизации является наличие в процессе этой автоматизации очень важного этапа - предварительного этапа. Именно на этом этапе ДО начала работ вы проводите экспресс-анализ и определяете готовность процесса к автоматизации. Другими словами - устанавливаете своеобразный DoR. Для этих целей я сформировал удобный чек-лист. Несколько простых вопросов, которые помогут принять решение об автоматизации без глубокого погружения в методологию управления бизнес-процессами:
Действительно ли данный процесс важен и он не является избыточным? Следует определить кто или что требует наличия данного процесса? Возможно, процесс можно упростить или вовсе отказаться от него без критичных негативных последствий.
Регламентирован ли процесс, есть ли его описание? Если процесс не описан, нет единого понимания у всех участников и руководства, как именно он работает, то нет и предмета для автоматизации.
Готов ли процесс к автоматизации? Если процесс нестабилен, вариативен, содержит множество исключений или требует постоянного вмешательства человека, его автоматизация усугубит ситуацию.
Можно ли оптимизировать процесс до автоматизации? Если процесс может быть оптимизирован без автоматизации, это необходимо сделать в первую очередь. Далее рассматривать вопрос автоматизации уже оптимизированного процесса.
Зачем мы автоматизируем данный процесс? Автоматизация ради автоматизации — это пустая трата ресурсов. Четкое понимание целей (снижение затрат, ускорение производства, рост продаж и доходов, повышение точности) и того, как мы будем измерять результат в будущем, помогает выбрать правильный подход и проверить достигнуты ли цели по итогам автоматизации.
Как долго данный процесс будет существовать? Автоматизация может потребовать значительных затрат времени и ресурсов. Инвестиции могут просто не окупиться при коротком сроке существования автоматизируемого процесса.
Окупятся ли вложения в автоматизацию? Мы должно четко понимать, как быстро расходы на автоматизацию процесса окупятся и какой экономический эффект будет получен.
Предусмотрен ли пилотный проект? Автоматизация на первом этапе может быть неудачной, нужна апробация решения перед полномасштабным внедрением, а также возможность доработки или даже отказа от внедрения по итогам пилота.
Учтен ли фактор сопротивления изменениям? Как будут переиспользованы высвободившиеся ресурсы? Любые изменения в процессе всегда встречают сопротивление от его участников, а внедрение новых систем требует обучения сотрудников, изменения их привычек, сокращения персонала и, возможно, даже пересмотра организационной структуры.
Вывод
Автоматизация – это инструмент, а не самоцель. Автоматизируем только то, что в действительности должно быть автоматизировано.
p.s. Предлагаю в комментариях поделиться, что еще можно проверить перед началом работ, а также поделиться примерами удачной и неудачной автоматизации. Начну первый.


