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

Кому подходит

Компании, где сотрудники вручную переносят данные между системами, повторяют одни и те же операции с документами и текстами или не могут включить уже сделанный прототип в ежедневную работу.

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

Какая проблема решается

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

Если задача решается обычной автоматизацией или изменением порядка действий, AI не добавляется. Для критичных решений заранее остаётся проверка человеком и понятный способ остановить сценарий.

Формат работы

  1. Аудит. Описываем процесс, участников, данные, задержки и ограничения.
  2. Выбор задачи. Сравниваем кандидатов по ожидаемой пользе, сложности, качеству данных, цене ошибки и проверяемости результата.
  3. Ограниченная версия. Собираем решение для одного сценария на согласованной выборке реальных данных.
  4. Контроль. Добавляем статусы, журналы работы, обработку ошибок и ручной или программный запасной маршрут.
  5. Интеграция. Подключаем решение к существующим системам с ограниченными правами.
  6. Передача. Фиксируем роли, инструкции, эксплуатацию и порядок остановки; сотрудники проходят реальный сценарий самостоятельно.
  7. Проверка. Расширяем решение только после того, как согласованные критерии выполнены на рабочем процессе.

Инженерное решение

Работа может включать изменение самого процесса, веб-сервис, интеграции, обычную автоматизацию и модель для отдельных операций. Границы выбираются по задаче. Система должна показывать своё состояние, сохранять историю действий и передавать нестандартные случаи человеку.

У модели нет собственной ответственности. Владелец процесса определяет допустимый результат, сотрудники проверяют критичные действия, а техническая система ограничивает права и фиксирует ошибки.

Что остаётся у компании

В зависимости от объёма это карта процесса и рисков, критерии качества, ограниченная рабочая версия, интеграции, журналы, инструкции и правила ручной проверки. Для эксплуатации назначается ответственный и определяется порядок реакции на ошибки.

Эффект оценивается по данным выбранного сценария. Заранее обещать процент экономии, замену сотрудников или безошибочную работу модели нельзя.

Практика и примеры систем

TiROBOTS связывает редакционный план, подготовку материала, проверку и публикацию. В «Самурае» роли, данные и документы встроены в рабочий процесс автосервиса. Эти проекты показывают устройство решений, но не прогнозируют эффект для другой компании.

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

Как выбрать соседний формат

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

Обсудить бизнес-процесс