Работать на рынке линейного персонала без операционной части бизнеса практически нереально – как минимум потому что мы работаем с живыми людьми, которых невозможно унифицировать и стандартизировать. Человеческий фактор требует человеческого же подхода, который обеспечивается службой поддержки, причем чем больше наши требования к качеству, тем выше ее вовлеченность. Тем не менее отказаться от части ручных процессов за счет автоматизации и качественного IT даже на рынке линейного персонала вполне реально, о чем я сегодня и расскажу.
Как выглядит традиционный бизнес по аутсорсингу линейного персонала? Ручные процессы, ручное взаимодействие, причем как с заказчиками, так и с исполнителями. Я знаю этот рынок хорошо, я на нем работаю уже около 14 лет. Еще недавно из автоматизации там были разве что базы данных исполнителей в Excel. Сейчас все больше аутсорсеров предлагают заказать на объект исполнителей в один клик через приложение – звучит многообещающе, однако на деле чаще всего это всего лишь автоматизация подачи заявки, но обрабатывать и выполнять ее будут в конечном счете вполне традиционным способом – руками и звонками.
Мы же изначально ставили себе целью совершенно другой объем автоматизации. Когда мы рассказывали потенциальным инвесторам и заказчикам, что мы делаем «убер линейного персонала» мы имели ввиду буквально убер – масштабную IT-инфраструктуру для автоматической агрегации и мэтчинга множеств данных. То есть заявки от бизнеса автоматически сопоставляются с множеством выбранных потенциальными исполнителями слотами, исполнителю автоматически приходит предложение принять заявку, он откликается и под бдительным оком опять таки искусственного интеллекта (системы контроля выхода) выходит на подработку. Конечно, без поддержки и других операционных функций совсем не обойтись, но важно, чтобы они сводились именно к support, а все core-процессы были автоматизированы.
Когда мы только начинали в июне 2019 вся наша автоматизация была буквально прототипом на бумаге (я не шучу), а все процессы тестировались и оттачивались вручную. Мы приняли для себя следующую парадигму – чтобы создать по-настоящему product market fit, нужно минимизировать объем случайного функционала. Чтобы наш продукт отвечал потребностям и исполнителей, и бизнеса, нужны его максимальные удобство, простота и эффективность. На рынке еще не было продукта, аналогичного нашему, мы буквально прокладывали перед собой рельсы в процессе путешествия. Ориентироваться было не на кого, поэтому все, что мы делали, мы делали впервые, и мы делали это вручную. В качестве результата этой ручной настройки у нас появились мобильное приложение для исполнителей, личный кабинет для бизнеса и бэкенд в виде внутренней HRM, и мы стали активно развивать их функционал, загоняя в них все больше прежде ручного функционала. Мы приняли для себя, что готовы изначально запустить на релиз «сырой», но постепенно дорабатываемый и быстро адаптируемый продукт. Мы довольно быстро обеспечили в приложении реализацию основного функционала, т.е. исполнитель мог без проблем выбрать удобные для него слоты и принять заявку, но вот дополнительный функционал, обеспечивающий именно комфорт использования – типа отображения различной информации, обмена документами и т.д. – добавлялся постепенно.
Изначально у нас была бОльшая ставка на операционные блоки – на ранних этапах развития продукта их работу проще, быстрее и дешевле запустить, и до определенного момента они легко масштабируются. Основные процессы там – это онбординг, рекрутмент (у нас более 50 операторов на линии), а также реализация, то есть это контроль рутинных процессов, например, вышел ли наш гигант на объект, почему не смог отметиться о выполнении задач, по какой причине опоздал и т.д. Во всех этих операциях много ручного труда, который требует постепенной автоматизации. Конечно, можно поспорить, что ручные операции не масштабируемы в большом объеме и было бы эффективнее изначально создавать именно IT-продукт, но, во-первых, сама по себе разработка продукта с нуля требует объемного и продолжительного research, во-вторых, это значительно дороже, в-третьих – от идеи до релиза боевой версии продукта, которую можно предложить заказчикам, пройдут месяцы, если не годы, что нас совершенно не устраивало.
Мы начали и до сих продолжаем тестировать гипотезы оффлайновым методом, то есть вручную, на операционных блоках, потому что это новый продукт на новом рынке. Мы исходим из того, что перед тем, как отдавать какой-то функционал на программирование и заведение в приложение, его нужно проверить. Потому что ответ на какую-либо гипотезу в нашем случае в 90% случаев будет звучать не как «надо/ не надо” или “работает/ не работает”, а “как именно надо” и “как именно это работает». Таким образом для нас тестирование гипотез с помощью операционного блока включает функции research и custdev, и финальный результат, который в конечном счете отдается на программирование, может сильно отличаться от гипотезы, основанной на теоретической догадке.
К примеру одной из основ нашего сервиса является алгоритм планирования, который автоматически стыкует заявки от магазинов, в которых указаны локация, дата, временной слот, когда нужен исполнитель, и непосредственно специализация исполнителя, со специализацией, локацией и временными слотами самого исполнителя соответственно. Вопрос не только в скорости мэтчинга, но и в его актуальности. Звучит очень просто – подумаешь, просто сопоставить множества и раскидать исполнителей по заявкам. Проблема в том, что речь идет о живых людях, которые могут с системой не согласиться, если им будут предлагать что-то нерелевантное. Что делать, если в локации исполнителя нет доступной подработки? Какое время человек готов потратить на дорогу, то есть какое расстояние до места подработки является критическим, надо учитывать само расстояние или именно время в пути? За какое минимальное и максимальное время человеку можно предлагать подработку, чтобы он не передумал и успел добраться? Нужна ли исполнителю постоянная локация поиска или люди склонны ее менять? Ответы на все эти и множество других вопросов помогли разработать и усовершенствовать алгоритм планирования, хотя на самых ранних этапах планирование делали менеджеры в Google-таблицах.
При этом приоритет по автоматизации мы отдаем функционалу, который начинает копить кост при масштабировании. Когда мы только начинали, 90% заявок закрывались вручную с помощью операторов. При этом объем заявок был несопоставимо меньше, и при плановом масштабировании в определенной точке нам бы потребовалось более тысячи операторов, что с трудом поддается адекватной оценке. Сейчас участие операторов требуется менее чем в 5% заявок. В дальнейших планах полностью вывести участие людей из процесса закрытия заявок.
Мы постепенно заводили все процессы в приложение и на сегодняшний день уже вплотную приблизились к тому, что весь критический функционал реализован в приложении. Сейчас пользователь с минимальным участием оператора может выполнять все функции. К этому мы шли примерно полтора года.
Сегодня мы все меньше нуждаемся в оффлайн-тестировании, количество ручных процессов снизилось многократно, бэклог сформировался, IT-департамент постепенно дорос до 40 человек и движется в направлении 70. Операционный блок, напротив, постепенно сокращается – при автоматизации части задач для некоторых операторов просто не остается работы, функционал других меняется и все больше движется в направлении суппорта. Важно помнить, что автоматизация даже небольшой функции требует быстрого внесения изменений в бизнес процессы, так что необходимо наладить систему быстрого апдейта алгоритмов работы отделов.
Подведу итог: иногда чтобы стать по-настоящему IT-компанией, надо начать в глубоком оффлайне. Я уверен, что то, что мы постепенно переводили ручные операции в алгоритмы, помогло нам намного лучше понять свою аудиторию, ее реальные боли и потребности, чем если бы мы сразу начинали пилить IT-инфраструктуру, сидя в комфортных креслах в высоких башнях. Ручные процессы помогают прочувствовать саму суть бизнеса на кончиках пальцев, но со временем, когда понятны цели, задачи и основные тонкости, от них, конечно, надо отказываться в пользу IT-инструментов и максимальной автоматизации.