Первый практический шаг LOG [IN] OFF 3.0: я собрал 240 гипотез повторяемых работ бизнеса и перешел от отраслей и отделов к конкретным работам.
В предыдущей статье я зафиксировал новый для себя порядок действий.
Не выбирать очередную идею продукта и сразу идти в разработку, а сначала самому разобраться в пространстве, в котором я собираюсь строить новую продуктовую модель Лаборатории автоматизации «LOG [IN] OFF» 3.0.
Следующий вопрос был уже практическим:
С чего вообще начать исследование, если я специально не хочу заранее выбирать ни продукт, ни технологию, ни одну конкретную нишу?
Сначала мне казалось логичным идти по отраслям.
Оптовая торговля.
Строительство.
Производство.
Услуги.
Логистика.
За годы интеграторской работы у нас накопился опыт в разных типах компаний, поэтому такой путь выглядел естественно: взять отрасль и посмотреть, что в ней можно автоматизировать.
Но почти сразу я увидел проблему.
В одной оптовой компании есть продажи, закупки, склад, логистика, документы, бухгалтерия, дебиторка, маркетинг, клиентский сервис и управление.
Если поставить вопрос:
Что автоматизировать в оптовой компании?
пространство получается почти таким же большим, как вопрос «что автоматизировать в бизнесе вообще».
Для интегратора это нормальная постановка.
Для поиска повторяемого продукта - слишком широкая.
Поэтому первый ход я изменил.
Я решил пока не выбирать отрасль.
Сначала мне нужна была карта самой работы.
Почему отрасль и отдел оказались слишком крупными единицами
С отделами возникла та же проблема.
«Автоматизация отдела продаж» звучит конкретнее отрасли, но внутри продаж находятся десятки совершенно разных работ.
Например:
- после разговора зафиксировать договоренности в CRM;
- проверить, что у сделки есть следующий шаг;
- найти сделки без движения;
- подготовить коммерческое предложение;
- проконтролировать известные обязательства менеджера;
- собрать руководителю отклонения по воронке.
Все это продажи.
Но для автоматизации это разные работы. У них разные входы, результаты, частота, цена ошибки и потенциальная технология.
То же самое в закупках.
«Автоматизировать закупки» можно разложить, например, на:
- собрать предложения поставщиков;
- извлечь из них цены, сроки и условия;
- сопоставить номенклатуру;
- привести предложения к одной структуре;
- сравнить варианты;
- проконтролировать обещанный срок поставки;
- заметить изменение срока и понять, на что оно влияет.
Поэтому мне понадобилась более мелкая единица исследования.
Не отрасль.
Не отдел.
Не большая схема бизнес-процесса.
Мне нужна была конкретная работа, которую конкретный человек выполняет в конкретной ситуации ради понятного результата.
Что я считаю работой в этом исследовании
Для исследования я использую простую единицу:
работа - это конкретное действие, которое конкретная роль выполняет в конкретной ситуации ради понятного результата.
На таком уровне уже можно обсуждать вход, выход, частоту, риск и возможный способ выполнения.
Чтобы не оставлять работу абстрактным названием, я держал простой рабочий тест:
Что произошло?
Кто после этого должен что-то сделать?
Что именно он делает?
Что должно получиться на выходе?
Например, не «автоматизация CRM», а:
закончился звонок клиенту -> менеджеру нужно зафиксировать результат -> обновить конкретные данные сделки и следующий шаг.
Не «контроль задач», а:
наступил срок поручения -> нужен актуальный статус -> если его нет, получить статус у ответственного и показать отклонение.
На таком уровне уже можно обсуждать не абстрактную автоматизацию, а конкретную работу.
Первый сбор я специально сделал слишком широким
На этом этапе я еще не хотел выбирать победителей.
Наоборот, задача была получить широкий обзор и не потерять интересные работы из-за слишком раннего фильтра.
Я прошел по разным функциям компании: продажи, маркетинг, управление, документы, финансы, закупки, клиентский сервис, HR, обучение, аналитика, корпоративные знания, операционная координация и другим зонам.
Для расширения и структурирования списка я активно использовал ИИ.
Здесь для меня важна граница.
ИИ помогал генерировать и систематизировать гипотезы о работах.
Он не доказывал, что эти работы массовые, болезненные или коммерчески привлекательные.
В одном из первых широких проходов получилось 240 работ в 19 функциональных направлениях.
Это была первая цифра, которая реально повлияла на мой следующий шаг.
Пока у тебя 10 идей, их еще можно обсуждать по одной.
Когда перед тобой уже 240 отдельных работ, становится очевидно: проблема теперь не в недостатке идей.
Проблема в том, как их сужать.
И здесь важно не перепутать карту исследования с доказательством рынка.
240 работ - это не 240 рынков. Это 240 гипотез о повторяемой работе, которые еще нужно проверять реальными сигналами.
На этом этапе карта дала мне не ответ, что строить.
Она дала пространство, которое можно начинать системно сужать.
Я впервые увидел компанию не как набор отделов
В управлении рядом оказались такие работы, как:
- извлечь поручения из итогов встречи;
- собрать актуальные статусы;
- заметить просрочку;
- подготовить краткую управленческую сводку.
В продажах:
- заполнить CRM после коммуникации;
- определить следующий шаг;
- найти зависшую сделку;
- проверить соблюдение известных критериев.
В документах и финансах:
- распознать документ;
- извлечь реквизиты;
- сверить данные;
- сравнить версии;
- найти расхождение.
В закупках:
- разобрать предложения поставщиков;
- нормализовать условия;
- сопоставить позиции;
- сравнить варианты;
- проконтролировать изменение срока.
В HR:
- обработать отклики;
- подготовить карточку кандидата;
- согласовать интервью;
- провести человека по онбордингу;
- проконтролировать контрольные точки.
Сам по себе длинный список мне был нужен не ради количества.
Он изменил способ, которым я начал смотреть на компанию.
Раньше естественная карта бизнеса для меня выглядела так:
продажи -> маркетинг -> закупки -> финансы -> HR -> управление.
После первого прохода я стал видеть под каждым из этих названий десятки отдельных повторяемых работ.
Для поиска будущего продукта это оказалось гораздо полезнее.
Но 240 работ создали новую проблему
Очень быстро стало понятно, что сам переход к работам еще ничего не решает.
Если каждую повторяемую работу считать продуктовой возможностью, я просто заменю один длинный список другим.
Раньше можно было придумать 100 стартапов.
Теперь можно собрать сотни работ для автоматизации.
Но мой исходный вопрос остается тем же:
Какие из них действительно заслуживают следующего шага?
То есть первая карта выполнила свою задачу, но не дала ответа, что строить.
Она дала другое - структуру пространства, которое теперь можно начинать сужать.
Для меня это и был первый полезный результат исследования.
Одинаковая механика стала повторяться в разных отделах
Когда я перестал смотреть только на названия функций, проявился еще один слой.
Совершенно разные работы иногда устроены похоже внутри.
Например:
пришла неструктурированная информация -> ее нужно понять -> извлечь нужное -> записать результат в систему.
Так может выглядеть:
- звонок клиента -> данные в CRM;
- коммерческое предложение -> таблица закупщика;
- счет -> данные для учетной системы;
- резюме -> карточка кандидата;
- договор -> извлеченные условия;
- встреча -> зафиксированные решения и поручения.
Другой повторяющийся механизм:
произошло событие -> нужно проверить состояние -> увидеть отклонение -> определить, требуется ли реакция.
Например:
- сделка слишком долго стоит на одном этапе;
- поставщик изменил срок;
- поручение просрочено;
- платеж не пришел;
- обязательный документ не получен.
Еще один:
есть несколько источников -> нужно собрать их вместе -> сопоставить -> подготовить понятный результат для решения.
Это может быть:
- несколько предложений поставщиков;
- несколько версий документа;
- показатели из разных систем;
- несколько кандидатов;
- данные разных рекламных каналов.
В одном из исследовательских проходов ИИ предложил сгруппировать такие повторения в 6 горизонтальных архетипов: коммуникации, документы, данные, знания, события и контент.
Я не считаю эту классификацию доказанной моделью рынка.
Но она подсветила для меня важную мысль:
одна и та же механика работы может повторяться в совершенно разных функциях бизнеса.
Поэтому карту стало полезно читать одновременно вертикально - через контекст конкретной функции - и горизонтально - через повторяющуюся механику работы.
Искать можно не только так:
отрасль -> функция -> конкретная работа.
Но и так:
какая механика повторяется снова и снова в разных частях бизнеса?
От отраслей и функций я при этом не отказался
Здесь легко сделать следующую ошибку и решить, что контекст больше не важен.
Это не так.
Одинаковая механика не означает одинаковый продукт.
Извлечь данные из счета и разобрать резюме можно формально отнести к обработке неструктурированной информации.
Но цена ошибки, правила, владелец результата и граница допустимого действия у них совершенно разные.
Поэтому я стал смотреть на одну работу сразу в нескольких разрезах.
Бизнес-функция дает контекст.
Продажи, управление, финансы, закупки, HR и так далее.
Конкретная работа дает единицу исследования.
Что произошло, кто что делает и какой результат нужен.
Горизонтальная механика показывает возможную повторяемость решения.
Понять информацию, сверить, перенести, проконтролировать событие, собрать статус, подготовить данные для решения.
А уже потом к этому можно добавлять экономику, существующий софт, техническую реализуемость и ограничения.
Так карта стала заметно полезнее, чем первоначальный вопрос «какой ИИ сделать для такого-то отдела».
Почему 240 работ еще не означают 240 рынков
Это главное ограничение этого этапа.
240 работ в исследовательской таблице не означают, что я нашел 240 рынков.
Они не отвечают на вопросы:
- сколько компаний реально выполняют эту работу;
- насколько часто она возникает;
- сколько человеческого времени и денег потребляет;
- что происходит при ошибке;
- какие решения уже существуют;
- насколько хорошо они закрывают задачу;
- как сами пользователи называют эту работу;
- ищут ли они решение;
- готовы ли платить;
- насколько одно решение переносится между компаниями.
Я специально не хотел ранжировать список только по внутренним оценкам или по тому, насколько интересно выглядит автоматизация технически.
Для меня сильнее внутренней идеи должны быть реальные сигналы:
- существующий наблюдаемый процесс;
- повторяющиеся запросы клиентов;
- проблемные интервью;
- коммерческая проверка;
- оплаченный пилот.
Поисковый спрос тоже полезен, но он показывает интерес к теме, а не автоматически готовность платить.
Поэтому первая карта работ была не рейтингом будущих продуктов.
Она была картой того, что теперь нужно проверять.
По каким критериям теперь нужно сужать карту
После широкого прохода возник следующий слой отбора.
Для каждой работы мне теперь нужно проверять как минимум:
- насколько часто она возникает;
- сколько ручного времени потребляет;
- сколько стоит текущее выполнение;
- насколько четко можно определить результат;
- можно ли объективно проверить качество;
- доступны ли необходимые данные;
- какова цена ошибки;
- где должна остаться граница участия человека;
- насколько работа похожа у разных компаний;
- насколько решение можно переиспользовать.
Это уже гораздо ближе к продуктовому исследованию, чем вопрос «что вообще можно автоматизировать».
Работа может быть технически интересной, но возникать раз в квартал.
Может повторяться каждый день, но занимать тридцать секунд.
Может быть дорогой, но настолько индивидуальной, что каждый новый клиент потребует отдельного проекта разработки.
Может хорошо стандартизироваться, но иметь такую цену ошибки, что полная автономность пока бессмысленна.
Поэтому сам факт:
это можно сделать с помощью ИИ
для меня теперь почти ничего не решает.
Гораздо полезнее вопрос:
эта работа достаточно частая, дорогая, проверяемая и повторяемая, чтобы ее вообще имело смысл рассматривать как будущий продукт?
Что я вынес из первого прохода
После этого этапа я зафиксировал для себя пять выводов.
Первый. Отрасль слишком крупная единица для первого поиска продукта.
Она нужна для контекста, но внутри нее слишком много разных работ.
Второй. Отдел или бизнес-функция тоже слишком крупные.
«Автоматизация продаж» или «автоматизация закупок» скрывает десятки работ с разной экономикой и риском.
Третий. Исследование нужно доводить до конкретной работы.
Не «обработка документов», а конкретная ситуация, действие и результат.
Четвертый. Между разными функциями повторяются похожие рабочие механики.
Значит, смотреть нужно одновременно на вертикальный контекст и горизонтальную повторяемость.
Пятый. Большая карта работ сама по себе не является доказательством спроса.
Это только первый слой исследования.
Именно пятый вывод определил мой следующий шаг.
Следующим шагом я решил проверить язык самого рынка
До этого большая часть карты была сформулирована языком моего исследования.
Например:
контроль отклонений;
извлечение обязательств из коммуникаций;
сверка документов;
сопоставление предложений поставщиков.
Но клиент не обязан искать решение теми же словами, которыми я называю работу в своей таблице.
Поэтому следующим вопросом стало:
Что из этого люди действительно ищут и какими словами они описывают свою работу и проблему?
Я перешел к поисковому спросу.
И там пришлось снова корректировать направление исследования.
Следующим материалом разберу, как я проверял реальные формулировки спроса и почему одних запросов со словами «AI», «ИИ» и «агент» оказалось недостаточно, чтобы увидеть рынок повторяемой работы бизнеса.