В прошлой статье я остановился на вопросе: текст уже появился - что полезного сделать с ним дальше? Я прогнал эту ветку отдельным исследованием. Результат оказался неожиданным: самые сильные сигналы нашлись не там, где нужно улучшить транскрипт, а там, где голос сразу закрывает конкретную рабочую операцию.
В прошлой статье я дошёл до вопроса, который для меня оказался важнее самой транскрибации.
Текст уже появился.
Что полезного должно произойти дальше?
Я вынес эту ветку в отдельное исследование. Хотел понять, есть ли самостоятельная ценность в слое после распознавания речи:
- выделить задачу,
- определить исполнителя и срок,
- заполнить карточку клиента или сделки в CRM-системе (системе управления отношениями с клиентами),
- создать событие,
- подготовить письмо,
- извлечь факты
- или перенести данные в рабочую систему.
По ходу исследования направление немного сместилось. Для меня это хороший результат.
Самые сильные примеры нашлись не там, где нужно просто лучше обработать уже готовый текст.
Они нашлись там, где человек голосом сразу создаёт результат конкретной рабочей операции.
Не:
сказал -> получил красивый текст.
А:
увидел ситуацию -> сказал -> система поняла структуру -> человек проверил -> готовый результат появился в рабочей системе.
Для меня это заметно меняет саму постановку задачи. Под голосовым вводом данных в бизнесе я здесь понимаю не обычную диктовку текста, а сценарий, в котором речь помогает сразу создать структурированный результат в рабочей системе.
Сначала я проверял очевидный слой после транскрибации
Исходная схема была очень простой:
голос -> текст -> следующее действие.
После текста действительно можно делать много полезного.
Например:
- создать задачу;
- определить ответственного;
- поставить срок;
- создать событие календаря;
- заполнить поля CRM;
- подготовить письмо;
- выделить сумму, дату, имя или договорённость;
- сохранить структурированную заметку;
- перенести данные в 1С или другую учётную систему.
По результатам исследования большинство этих сценариев технически выглядят реализуемыми.
Но исследование ещё раз напомнило мне простую вещь: техническая реализуемость не равна самостоятельной продуктовой ценности.
Нужно смотреть, кто уже находится в точке выполнения этой работы и может встроить функцию прямо в существующий продукт.
При этом платформы уже закрывают часть этих сценариев встроенными функциями.
Голос -> задача уже становится функцией самой рабочей системы
Это видно на примере постановки задач.
У моего продукта «Говори дело» один из сценариев как раз выглядит так:
наговорил поручение -> система поняла содержание -> определила исполнителя и срок -> создала задачу в Битрикс24.
Несколько лет назад такой сценарий сам по себе выглядел значительно интереснее. Но сейчас Битрикс24 уже умеет автоматически создавать задачи из аудио- и видеосообщений. Система определяет содержание поручения, исполнителя, крайний срок, может сформировать чек-лист и отметить важность.
У функции есть ограничения: по текущей документации она доступна только в мобильном приложении Битрикс24 и требует подписки BitrixGPT + Маркетплейс. То есть часть цепочки, которую раньше нужно было строить отдельным сервисом, сама становится встроенной функцией платформы.
Похожая история происходит и в 1С. В 1С:CRM голосовой ввод уже доступен в письмах, задачах, поручениях, заметках, базе знаний и других формах.
Это не означает, что отдельные голосовые продукты больше никому не нужны или что рынок исчез.
Для меня это фильтр к самостоятельной продуктовой ценности.
Если продукт делает только:
голос -> текст -> стандартная задача в системе,
то нужно очень хорошо объяснить, почему пользователь должен покупать ещё один слой поверх платформы, которая постепенно делает то же самое сама.
Сильные примеры появились там, где человек физически занят другой работой
Я начал смотреть не только на офисные поручения и CRM, а на ситуации, где человек выполняет профессиональную работу и ему неудобно одновременно что-то печатать.
И здесь голос перестаёт быть просто альтернативной клавиатурой.
Он становится интерфейсом выполнения самой работы.
Конкретный пример - осмотр вагонов.
Группа ЦРТ описывает внедрение мобильного голосового обходчика в «ФосАгро».
До внедрения осмотрщик шёл вдоль состава, выявлял замечания, фиксировал их вручную, а затем должен был перенести данные в электронную систему.
Осмотрщик использует гарнитуру и голос.
Система распознаёт замечание.
Заполняет отчёт.
Данные появляются в электронной системе.
Для проверки система может озвучить распознанные параметры обратно сотруднику.
Вендор заявляет, что время передачи информации о техосмотрах сократилось более чем в 5 раз.
Я отношусь к таким цифрам как к заявлению стороны проекта, а не как к универсальной норме для любого предприятия.
Для меня сам факт внедрения здесь важнее красивой метрики: видна конкретная работа.
Осмотреть вагон и зафиксировать результат осмотра в системе.
Раньше внутри этой работы был лишний ручной переход:
увидел -> запомнил или записал -> дошёл до другого рабочего места -> повторно ввёл.
Голос позволяет попробовать убрать именно этот переход.
В медицине паттерн похожий
Второй сильный пример - медицинские протоколы.
Voice2Med предназначен не просто для расшифровки речи врача. В продукте есть специализированные медицинские словари, шаблоны протоколов, голосовая навигация по полям, заполнение протоколов и подтверждение результата распознавания.
Есть и конкретные внедрения. Например, ЦРТ описывает проект в Пермской краевой клинической больнице, где врач диктует информацию во время осмотра или исследования, а система переносит её в открытый протокол медицинской информационной системы.
Здесь конечная работа тоже сформулирована намного точнее, чем «превратить голос в текст».
Например:
врач проводит обследование -> диктует наблюдения -> система раскладывает информацию по структуре медицинского документа -> врач проверяет -> протокол сохраняется.
В этом сценарии текст является промежуточным представлением данных.
Пользовательская ценность находится в другом месте.
Готов медицинский документ, с которым можно продолжать работу.
В этом сценарии есть то, чего нет у обычной транскрибации:
- отраслевой словарь;
- понятная структура результата;
- конкретная целевая система;
- проверка критичных данных человеком;
- известный момент начала и окончания работы.
Чем больше я смотрел на такие примеры, тем меньше мне нравилась формулировка «сервис после транскрибации».
Она слишком технологическая: описывает место компонента в цепочке, но почти ничего не говорит о работе пользователя.
Исследование сместилось - и я не хочу это исправлять
Формально я начинал с другой задачи.
У меня уже есть текст после распознавания речи.
Что ценного можно сделать с ним дальше?
Но по мере проверки появился соседний вопрос:
а что, если сильная ценность вообще возникает раньше - когда человек в момент выполнения работы голосом сразу создаёт структурированный результат?
Я не считаю такой сдвиг ошибкой исследования. Наоборот.
Если заранее запретить исследованию уходить от первоначальной формулировки, оно очень легко превращается в механизм подтверждения собственной идеи.
Мне нужен другой результат.
Если исходная гипотеза слабая, а рядом обнаруживается более конкретная работа с реальными внедрениями, алгоритм должен это показать.
Два реальных внедрения не доказывают, что найден большой рынок.
Они не доказывают готовность платить в выбранном мной сегменте.
Они не доказывают, что я смогу сделать продукт с подходящей экономикой.
Они подтверждают более узкую вещь.
Такой класс работы существует не только в моей голове. Голос уже используется как способ фиксировать результат конкретной профессиональной операции.
Этого достаточно, чтобы направление заслуживало следующей проверки.
Но недостаточно, чтобы начинать коммерческую разработку.
Где голосовой ввод данных реально полезен бизнесу
После исследования я бы описал перспективный голосовой сценарий так:
конкретная рабочая ситуация -> короткое голосовое описание -> извлечение структурированных данных -> быстрая проверка человеком -> запись результата в целевую систему.
Для меня здесь важны 5 признаков.
1 - человек уже выполняет основную работу и ввод данных мешает ей.
2 - результат имеет понятную структуру.
Не просто свободный текст, а карточка, акт, протокол, дефект, задача или набор реквизитов.
3 - результат можно проверить.
Особенно если ошибка дорогая.
Система не должна незаметно записывать критичные данные только потому, что модель «уверена».
4 - после подтверждения результат сразу попадает туда, где нужен бизнесу.
Если сотруднику всё равно потом приходится перепечатывать информацию, автоматизация не закончена.
5 - ручной шаг действительно повторяется достаточно часто, чтобы его устранение имело смысл.
Последний пункт пока нельзя считать доказанным для всех найденных ниш.
Его нужно измерять уже на конкретных ролях и компаниях.
Поэтому «голосовой ввод» сам по себе тоже не продукт
Здесь легко совершить ту же ошибку второй раз.
Сначала сказать:
транскрибация - продукт.
Потом увидеть, что этого мало, и заменить формулировку на:
тогда продукт - голосовой ввод.
Но это опять описание технологии.
Для бизнеса вопрос формулируется иначе.
Не «есть ли голосовой ввод у инспектора».
А:
сможет ли инспектор закончить осмотр без повторного заполнения тех же данных позже?
Не «умеет ли врач диктовать».
А:
сможет ли врач получить готовый проверяемый протокол в своей медицинской системе?
Не «можно ли отправить голосовое руководителя в ИИ».
А:
появится ли после сообщения правильная задача у правильного человека с правильным сроком без дополнительной ручной работы?
Именно на таком уровне мне сейчас интереснее искать цифровых сотрудников.
Не от технологии к применению.
А от законченной работы к тому, какую её часть можно безопасно передать системе.
Это продолжение принципа, который я уже описывал в статье о переходе от разработки к исследованию.
Что это значит для «Говори дело»
Для моего старого продукта вывод получается не очень удобный, но полезный.
Сценарий «сказал поручение -> получил задачу в Битрикс24» уже нельзя рассматривать как автоматически сильную самостоятельную ценность только потому, что он работает.
Битрикс24 уже закрывает часть этого сценария встроенной функцией.
В 1С:CRM голосовой ввод уже встроен в письма, задачи, поручения, заметки и другие рабочие формы.
Поэтому вопрос для меня теперь намного жёстче:
какую законченную работу «Говори дело» умеет закрыть заметно лучше или там, где её не закрывает сама целевая система?
Ответ может оказаться в работе между несколькими системами, в обработке уже существующего аудио и видео или в специализированном профессиональном сценарии. А может выясниться, что текущая конструкция вообще не должна становиться отдельным большим продуктом.
Я пока не знаю ответа и не хочу придумывать его вместо исследования.
Что исследование пока не доказало
У меня есть сильнее сформулированное направление, но ещё нет продуктового решения.
Пока неизвестно:
- сколько компании готовы платить именно за такой слой автоматизации;
- в каких профессиях повторный ввод данных действительно занимает заметное время;
- насколько часто выполняется выбранная операция;
- какая точность распознавания получится в реальном шуме и с отраслевой терминологией;
- сколько ручной проверки понадобится после распознавания;
- насколько сложно будет подключаться к конкретным 1С, ERP-системам (системам управления ресурсами предприятия), CRM или медицинским системам;
- какие ограничения появятся со стороны информационной безопасности;
- какая ниша даст нормальную экономику после внедрения и поддержки.
Именно поэтому следующий шаг для меня не «собрать универсального голосового сотрудника».
Следующий шаг - взять одну конкретную работу и проверить её на реальных людях.
Например:
осмотр -> голос -> структурированная запись -> подтверждение -> учётная система.
И уже там измерять исходный процесс.
Сколько таких операций происходит.
Сколько времени уходит сейчас.
Где возникает повторный ввод.
Какова цена ошибки.
Что можно убрать полностью.
И готов ли бизнес за это платить.
Главный вывод для меня изменился
После первой статьи мой вопрос звучал так:
если текст уже получен, что ценного можно сделать с ним дальше?
После отдельного исследования я сформулировал его иначе:
какую законченную рабочую операцию можно выполнить голосом так, чтобы после речи сразу появился проверяемый бизнес-результат?
Это более узкая и одновременно более полезная постановка.
Я начинал с транскрибации.
Потом смотрел на задачи, CRM и обработку текста.
А в итоге пришёл к тому, что настоящий объект исследования - не текст и даже не голос.
Объект исследования - ручная работа между событием и готовой записью в системе.
Если её можно убрать, не ухудшив качество и контроль, там действительно может появиться ценность.
Голос в таком случае - просто удобный интерфейс для конкретной ситуации.
Источники, которые я перепроверил перед публикацией
- Битрикс24: Аудио и Видео Задачи AI
- 1С:CRM: голосовой помощник ввода
- ЦРТ: Voice2Med
- ЦРТ: внедрение Voice2Med в Пермской краевой клинической больнице
- ЦРТ: мобильный голосовой обходчик для «ФосАгро»
FAQ
Где появляется ценность после расшифровки речи?
Самый сильный сценарий, который я увидел в исследовании, возникает тогда, когда речь превращается не просто в текст, а в готовый рабочий результат: задачу, заполненный протокол, запись о дефекте или другой структурированный объект в целевой системе.
Чем голосовой ввод в бизнес-процесс отличается от обычной транскрибации?
Транскрибация заканчивается текстом. Голосовой ввод в рабочий процесс продолжается до результата: система понимает структуру, заполняет нужные поля, даёт человеку проверить критичные данные и сохраняет результат там, где с ним продолжают работать.
Можно ли ставить задачи голосом в Битрикс24?
Да. По текущей документации Битрикс24 умеет создавать задачи из аудио- и видеосообщений: определяет содержание поручения, исполнителя и срок. Функция доступна в мобильном приложении и требует подписки BitrixGPT + Маркетплейс.
Где голосовой ввод данных реально полезен бизнесу?
Он особенно полезен там, где человеку неудобно печатать во время основной работы, результат имеет понятную структуру, критичные данные можно быстро проверить, запись сразу попадает в рабочую систему, а операция повторяется достаточно часто.