Точка А: Автоматизация
Мы IT-компания, которая помогает малому бизнесу как бэк-офис на аутсорсе. Ведём бухгалтерию, сдаём отчётность, готовим кадровые документы и считаем зарплату.
Обслуживаем около 1500 активных ИП и ООО по всей России. И чтобы не утонуть в отчётах и не раздувать штат, с самого старта мы уделяли много внимания автоматизации. Старались автоматизировать всё, что поддавалось и начали заботливо называть алгоритмы "роботами".
Роботы у нас сейчас закрывают какую-то небольшую часть задач на все 100%. Другая часть задач закрывается людьми вручную. Но для решения 95% всех задач задействованы и те, и другие.
Другими словами, до недавнего времени мы жили в парадигме:
Распишем весь бизнес-процесс
Посмотрим какая часть дамажит людей больше всего и отнимает кучу времени
За-автоматизируем этот участок
Оставим на людях только то, что не поддаётся понятной и быстрой автоматизации или занимает минимум времени у человека. Например, проверить за роботом и нажать 3 кнопки для получения результата.
Такой подход отлично подходит, когда ты стартап или только запускаешь новый продукт, когда важна скорость и быстрый старт.
Ты не пытаешься сразу объять 100% исключений и отклонений от мейнстрим сценария. Если попытаешься написать сразу идеального робота, который не деградирует и поддерживает 100% сценариев — то ты просто опоздаешь, рынок займёт кто-то другой, да и деньги на разработку быстро кончатся.
Но в любом IT-проекте, как и у нас, наступает момент, когда важно перестать считать себя стартапом и начать жить по правилам «стабильного производства».
Точка О: Осознание
Как мы поняли, что “пора” перестраивать кухню?
К сожалению, никак. Недавно мы поняли, что уже опоздали ?
За последние годы нам удалось заавтоматизировать кучу процессов по модели, описанной выше. И нам стало казаться, что с таким уровнем автоматизации мы можем освободить часть работников от их ежедневной рутины, не потеряв в скорости и качестве.
Но когда стали разговаривать с руководителями отделов (у нас это технологи), выяснили, что снимать с процесса никого нельзя — нагрузка не позволит.
Как так? Столько всего вам упростили и ускорили… половина работы на роботах. Почему не можем взять и половину людей отпустить?
Ну как-то не спасают роботы. Уж точно не половину работы на себя берут.
Начали разбираться и углубляться. Оказалось, что наши "роботы" успели сильно деградировать.
Например, один алгоритм обещал отправлять 90% отчётов без участия человека. Спустя год он отправляет в лучшем случае 20%, остальное бухгалтеры фигачат вручную.
А всё потому, как он был спрограмирован: успех случится, если совпадут условия А, B, C и D. Если хотя бы одно условие не работает, робот поднимает лапки и задача уходит на ручник (бухгалтеру).
Уже на этом этапе к нам пришло осознание, что к чему. Люди просто сидели и месяцами подтирали жопу деградирующим роботам. А раз ошибка уходила отдельным бухгалтерам, а не разработке, то было невозможно отследить растущую деградацию.
В сухом остатке:
Наша ошибка в том, что мы слишком долго жили в режиме “стартапа” и не пересматривали процессы. Нам всегда было важно автоматизировать 90% работы как можно быстрее, а где там что-то не сработает — придёт исполнитель (бухгалтер, платёжник, юрист, не важно) и поправит руками.
Сейчас нам предстоит как-то разгрести то, что у нас сотни "роботов" и десятки тысяч строк кода написаны в режиме стартапа. Они каждый день деградируют и никто об этом не сигнализирует.
Мы слишком долго не снимали людей с процессов. По хорошему, надо было делать это сразу после внедрения робота.
Никто в компании по факту не следил за уровнем деградации роботов.
Из этих ошибок и родилась новая концепция с дерзким названием.
Точка П: Перестать подтирать жопу роботам
Мы решили кардинально изменить подход к автоматизации в трёх ключевых точках.
Теперь мы автоматизируем не то, что получится быстрее. И даже не то, что больше всего дамажит людей. Теперь ключевой параметр для выбора объекта автоматизации — это 100% исключение человека из процесса. То есть, автоматизируем только те части процесса, из которых можно будет полностью убрать исполнителя (бухгалтера, юриста и т.д.).
Да, с таким подходом процент автоматизации станет ниже, ведь много где существуют какие-то ручники и нестандартные сценарии. Но в перспективе это спасёт нас от деградации роботов и даст прозрачность в том: работает механизм или нет.
Второй момент: мы не позволим "роботу" притворяться, что он закрывает задачу для всех клиентов или покрывает все сценарии. Теперь ещё до запуска алгоритма мы будем чётко понимать, по каким клиентам и для каких сценариев он 100% сработает, а по каким 100% — нет.
Это позволит более прозрачно планировать нагрузку на исполнителей (бухгалтеров, платёжников и т.д.), ведь мы будем знать точное кол-во задач, с которыми не справится робот.
Другими словами, сейчас мы стараемся прийти к ситуации, когда сможем доверять роботам на 100% и держать под контролем область их покрытия (20-40-70% задач).
Третье важное отличие — если робот сломался, задача “прийти и доделать за ним руками” поднимется не на исполнителя, а на разработчика.
Да-да, если робот по каким-то причинам не отправил отчёт в налоговую, а завтра последний день — разбираться с этим будет разраб, без возможности перекинуть задачу бухгалтеру ?
Только разработчики смогут понять почему робот деградирует и быстро это починить. Ведь в новом подходе мы оставляем роботу возможность падать только в “неизвестных случаях”, которые не были запрограмированы должным образом. А значит, и разбираться с падением должен разработчик.
Команды разработки становятся ответственными за контроль деградации.
Точка Ж: Жизнь
Как только определились с новой парадигмой, а случилось это пару месяцев назад, сразу начали менять процессы внутри себя. У нас три отдельные команды разработки с разными задачами и целями. И ни у кого из команд не возникло сопротивления: все приняли идею на ура. Хотя нам и потребовалось 2-3 встречи, чтобы прийти к общему пониманию концепта и проговорить все опасения.
Зато теперь есть понятный план на дальнейшую жизнь:
всех новых "роботов" без исключения пишем сразу по-новому (уже закончили с двумя)
осознаём и проектируем новые процессы сразу по-новому
старых роботов стараемся апгрейдить по мере возможности и по степени важности
Сами разработчики отмечают:
Новый подход должен в перспективе экономить время разработки. Потому что сейчас дофига времени разработчика, особенно дежурного, уходит на расследование ситуаций, которые были созданы из-за старой парадигмы (робот должен был, но не сделал).
У разработчиков есть ожидание, что это улучшит самочувствие системы в целом.
