Точка А: Автоматизация

Мы IT-компания, которая помогает малому бизнесу как бэк-офис на аутсорсе. Ведём бухгалтерию, сдаём отчётность, готовим кадровые документы и считаем зарплату.

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

Какую-то малую часть задач на все сто закрывают роботы. Другая малая часть закрывается вручную, силами людей. Но для решения 95% всех задач задействованы и те, и другие. 

Другими словами, до недавнего времени мы жили в парадигме:

• Распишем весь бизнес-процесс 

• Посмотрим какая часть дамажит людей больше всего и отнимает кучу времени

• За-автоматизируем этот участок

• Оставим на людях только то, что не поддаётся понятной и быстрой автоматизации или занимает минимум времени у человека. Например, проверить за роботом и нажать 3 кнопки для получения результата.

Такой подход отлично подходит, когда ты стартап или только запускаешь новый продукт. То есть, когда важна скорость и быстрый запуск. 

Ты не пытаешься сразу объять 100% исключений и отклонений от мейнстрим сценария. Если попытаешься написать сразу идеального робота, который умеет у себя всё подтирать, не деградирует и поддерживает 100% сценариев — то ты просто опоздаешь, рынок займёт кто-то другой, да и деньги на разработку быстро кончатся.

Но в любом IT-проекте, как и у нас, наступает момент, когда важно перестать считать себя стартапом и начать жить по правилам «стабильного производства».

Точка О: Осознание

Как мы поняли, что “пора” перестраивать кухню?

К сожалению, никак. Недавно мы поняли, что уже опоздали ????

За последние годы нам удалось заавтоматизировать кучу процессов по модели, описанной выше. И нам стало казаться, что с таким уровнем автоматизации мы можем освободить часть работников от их ежедневной рутины без потери качества и увеличения сроков обработки. Причём кадровые перемещения ожидались не в одном отделе, а сразу по всей компании.

Когда стали разговаривать с руководителями отделов (у нас это технологи), выяснили, что снимать с процесса никого нельзя — нагрузка не позволит.

Как так? Столько всего вам упростили и ускорили… половина работы на роботах. Почему не можем взять и половину людей отпустить?

Ну как-то не спасают роботы. Уж точно не половину работы на себя берут.

Начали разбираться и углубляться в роботов. Оказалось, что они успели сильно деградировать, причём с разной, иногда ошеломляющей скоростью.

Один алгоритм обещал закрывать 90% ситуаций без участия человека. Спустя год он отправляет в лучшем случае 20% отчётов, остальные бухгалтеры фигачат вручную. 

А всё потому, что он заранее был спрограмирован так: успех случится, если совпадут условия А, B, C и D. Если хотя бы одно условие не работает, робот поднимает лапки и задача уходит на ручник (бухгалтеру).

Уже на этом этапе к нам пришло осознание, что к чему. Люди просто сидели и месяцами подтирали жопу деградирующим роботам. 

Мы даже не стали уточнять почему бухгалтеры не сообщали о деградации робот. Ответ очевиден: они за этим не следят, и даже не всегда знают, какие сценарии робот покрывает сам, а какие уходят им на ручник. 

В сухом остатке:

• Наша ошибка в том, что мы слишком долго жили в режиме “стартапа” и не пересматривали процессы. Нам всегда было важно автоматизировать 90% работы как можно быстрее, а где там что-то не сработает — придёт исполнитель (бухгалтер, платёжник, юрист, не важно) и поправит руками.

• Сейчас нам предстоит как-то разгрести то, что у нас сотни роботов и десятки тысяч строк кода написаны в режиме стартапа. Они каждый день деградируют и никто об этом не сигнализирует.

• Мы слишком долго не снимали людей с процессов. По хорошему, надо было делать это сразу после внедрения робота.

• Никто в компании по факту не следил за уровнем деградации роботов.

Из этих ошибок и родилась новая концепция с дерзким названием.

Точка П: Перестать подтирать жопу роботам

Мы решили кардинально изменить подход к автоматизации в трёх ключевых точках. 

Теперь мы автоматизируем не то, что получится быстрее. И даже не то, что больше всего дамажит людей. Теперь ключевой параметр для выбора объекта автоматизации — это 100% исключение человека из процесса. То есть, автоматизируем только те части процесса, из которых можно будет полностью убрать исполнителя (бухгалтера, юриста).

Да, с таким подходом процент автоматизации станет ниже, ведь много где существуют какие-то ручники и нюансы, не поддающиеся алгоритмизации. Но в перспективе это спасёт нас от деградации роботов и даст прозрачность в том: работает механизм или нет.

Второй момент: мы не позволим роботу притворяться, что он закрывает задачу для всех клиентов или покрывает все сценарии. Теперь мы будем чётко понимать ещё до запуска робота, по каким клиентам и для каких сценариев он 100% сработает, а по каким 100% — нет. Это позволит более прозрачно планировать нагрузку на исполнителей (бухгалтеров, платёжников и т.д.).

Другими словами, сейчас мы стараемся прийти к ситуации, когда сможем доверять роботам на 100% и держать под контролем область их покрытия (20-40-70% задач). 

Третье важное отличие — если робот сломался, задача “прийти и доделать за ним руками” поднимается не на исполнителя, а на разработчика.

Да-да, если робот по каким-то причинам не отправил отчёт в налоговую, а завтра последний день — разбираться с этим будет разраб, без возможности перекинуть задачу бухгалтеру ????

Во-первых, это даст мотивацию писать код так, чтобы он как можно дольше не ломался. Во-вторых, только разработчики смогут понять почему робот деградирует и быстро починить это. Другими словами, мы оставляем роботу возможность падать только в “неизвестных случаях”, которые не были запрограмированы должным образом. А значит, и разбираться с падением должен разработчик.

Команды разработки становятся ответственными за контроль деградации. И все в компании это знают и согласны с этим.

Точка Ж: Жизнь

Как только определились с новой парадигмой, а случилось это пару месяцев назад, сразу начали менять процессы внутри себя. У нас три отдельные команды разработки с разными задачами и целями. И ни у кого из команд не возникло сопротивления: все приняли идею на ура. Хотя нам и потребовалось 2-3 встречи, чтобы прийти к общему пониманию концепта и проговорить все опасения.

Зато теперь есть понятный план на дальнейшую жизнь:

• всех новых роботов без исключения пишем сразу по-новому (уже закончили с двумя) 

• осознаём и проектируем новые процессы сразу по-новому

• старых роботов стараемся апгрейдить по мере возможности и по степени важности

Сами разработчики отмечают:

Новый подход должен в перспективе экономить время разработки. Потому что сейчас дофига времени разработчика, особенно дежурного, уходит на расследование ситуаций, которые были созданы из-за старой парадигмы (робот должен был, но не сделал).

У разработчиков есть ожидание, что это улучшит самочувствие системы в целом.

А как у вас устроено проектирование процессов?