kAIrosДальше в неё приходят реальные данные и сотрудники. Появляются исключения, разные права доступа, связь с другими сервисами, восстановление после ошибок и поддержка. Даже исправную систему ещё нужно встроить в работу компании: назначить ответственного, объяснить новые правила и добиться регулярного использования.
Поэтому я бы разделил три возможных следующих шага:
- самостоятельно изучать AI и проверять идею небольшими прототипами;
- заказать исследование, если проблема понятна, а будущая система и её цена — ещё нет;
- идти в разработку с подрядчиком, если процесс и ожидаемый результат уже можно описать.
У каждого маршрута своя цена. Самостоятельные эксперименты требуют меньше прямых расходов, но забирают время собственника. Подрядчик стоит дороже и берёт ответственность только за то, что заранее зафиксировано в проекте. Исследование помогает не оценивать неизвестную разработку на глаз.
Оглавление
- Сначала нужно понять, что именно вы меняете
- Путь первый: разобраться и сделать самостоятельно
- Путь второй: привлечь внешнюю команду
- Два пути в одной таблице
- Где заканчивается ответственность разработчика
- Как это выглядит в проекте клининговой компании
- Как выбрать следующий шаг
Сначала нужно понять, что именно вы меняете
В работе над системами я постоянно возвращаюсь к одному вопросу: что именно компания хочет изменить? Автоматизировать можно конкретный процесс. У него есть входные данные, последовательность действий, участники, исключения и результат, который можно проверить. Такой взгляд совпадает с процессным подходом IBM к управлению бизнес-процессами: сначала нужно увидеть процесс целиком, а не только отдельную задачу.
На практике многие процессы малого бизнеса устроены иначе. Часть правил записана в таблицах и инструкциях, часть обсуждается в чатах, а важные исключения остаются в голове собственника или опытного сотрудника. Человек каждый раз восстанавливает недостающий контекст. Система этого сделать не сможет, если контекст ей никто не передал.
Поэтому до разработки нужно ответить хотя бы на несколько вопросов:
- что запускает процесс;
- какие данные нужны на входе;
- кто принимает решения и где требуется человек;
- каким должен быть результат;
- как понять, что система ошиблась;
- кто будет отвечать за процесс после запуска.
Если ответы уже понятны, команда может уточнить объём, зафиксировать критерии приёмки и подготовить оценку. Изучение процесса, техническое задание, документы и проектирование в этом случае становятся начальной частью разработки.
Если ответов пока нет, точную цену всей разработки называть рано. Неясно, что именно строить, где заканчивается работа и по каким признакам принимать результат. Можно дать широкий диапазон, но для решения нужен отдельный этап исследования.
Исследование заканчивается не большим отчётом, а решением: делать систему, изменить идею или остановиться. Для этого команда описывает текущую проблему, ожидаемое изменение, доступные данные, способ измерения результата и условие, при котором проект не продолжают. Разработка начинается уже после согласования решения и объёма.
Именно здесь внешняя команда может принести пользу ещё до кода. Она не обязана соглашаться с первым вариантом решения клиента: её задача — проверить исходные предположения, назвать ограничения и предложить более простой путь, если он есть.
Путь первый: разобраться и сделать самостоятельно
По моей оценке, $100–300 в месяц может хватить на AI-модели, среду разработки, базу данных и сервисы автоматизации для личных первых экспериментов. Это ориентир для прототипа, а не бюджет рабочей системы.
Этот путь подходит собственнику, который хочет глубоко разобраться в технологии, готов экспериментировать и пока не уверен, нужна ли компании полноценная система. Решения можно менять без согласований, а понимание процесса и технологии остаётся внутри бизнеса.
Полная цена появляется позже. Собственник постепенно становится аналитиком, проектировщиком, разработчиком и тестировщиком. Ему приходится разбираться в хранении данных, правах доступа, связи с CRM или учётной системой, восстановлении данных после ошибки и поддержке после запуска. Каждый отдельный вопрос обычно можно решить. Сложность появляется из их количества и взаимосвязи.
Особенно легко ошибиться после появления первого убедительного прототипа. Он открывается, принимает данные и выполняет основной сценарий, поэтому кажется, что почти всё готово. Но именно после этого появляются исключения, реальные роли сотрудников, ошибки интеграций, безопасность и эксплуатация.
Прототип показывает, что идея технически возможна. Он ещё не доказывает, что система готова к ежедневной работе.
В сложном проекте самостоятельный путь может занять месяцы внимания собственника. И даже после них решение может не дойти до первоначальной задачи. Если затем передать проект профессионалам, им придётся сначала оценить созданную архитектуру; часть решений иногда проще пересобрать.
Путь второй: привлечь внешнюю команду
Внешняя разработка стоит значительно дороже самостоятельных подписок. В цену могут входить разбор процесса, документы, проектирование, разработка, проверка и поддержка после запуска. Точный состав нужно фиксировать до начала работы.
Работа команды начинается с исходной идеи. Нужно разобраться в процессе, оценить ограничения и понять, решает ли предложенная система реальную задачу. По результатам идею можно упростить, изменить направление или вообще отказаться от разработки.
Если задача подтверждена, стороны фиксируют проверяемый результат. Нужно отдельно договориться, где будут храниться данные, какие сбои и ошибки покрывает система, кто оплачивает внешние сервисы, сколько длится поддержка и что в неё не входит. Управление рисками на всём пути от проектирования до использования — отдельная работа; это же закреплено в NIST AI Risk Management Framework и его практическом Playbook.
Само название «AI-разработчик» ничего не гарантирует. Перед выбором подрядчика стоит спросить, как он изучает процесс, что фиксирует до разработки, как проверяется результат, какой опыт похожих задач может показать и где заканчивается его поддержка.
И даже сильный подрядчик не может пообещать, что разработка принесёт прибыль. Он может помочь оценить идею, снизить технические риски и отвечать за работоспособность системы. Экономический результат зависит ещё и от компании: от выбранного процесса, качества данных, сотрудников и того, будет ли новая система действительно использоваться.
Два пути в одной таблице
| Критерий | Самостоятельно | С внешней командой |
|---|---|---|
| Прямые расходы | По моей оценке, сервисы для первых экспериментов могут стоить $100–300 в месяц | Выше; цена зависит от ясности задачи, объёма и обязательств подрядчика |
| Время собственника | Очень высокое: нужно самому вести анализ, разработку и проверку | Ниже, но участие в постановке задачи и принятии решений обязательно |
| Необходимые навыки | Приходится осваивать самостоятельно | Уже должны быть у выбранной команды |
| Работа с исходной идеей | Собственник проверяет и улучшает её сам | Команда помогает оценить, изменить или остановить слабую идею |
| Скорость первого прототипа | Может быть высокой благодаря AI | Зависит от процесса, документов и согласованного объёма |
| Путь до рабочей системы | Много нюансов может открыться после прототипа | Заранее фиксируются этапы, требования и способ проверки |
| Технический результат | Ответственность собственника | Ответственность команды в зафиксированных границах |
| Риск перепроектирования | Зависит от опыта собственника и сложности системы | Зависит от опыта подрядчика и качества исследования |
| Экономический результат | Не гарантирован | Тоже не гарантирован |
| Использование сотрудниками | Ответственность бизнеса | Всё равно ответственность бизнеса |
В самостоятельном пути собственник принимает техническую работу и риск на себя. Во внешнем проекте ответственность подрядчика ограничена тем результатом, требованиями и поддержкой, которые стороны зафиксировали заранее. Ни один вариант сам по себе не гарантирует прибыль.
Где заканчивается ответственность разработчика
В разговорах об автоматизации часто смешиваются два результата:
- система работает так, как описано в техническом задании;
- сотрудники действительно используют её в ежедневной работе.
За первый результат подрядчик отвечает в согласованных границах проекта. Он должен изучить задачу, описать границы, спроектировать решение, разработать его и проверить. Сюда же входит та подготовка к запуску, о которой стороны договорились: например, перенос данных, инструкции или обучение ответственных сотрудников.
За управленческое внедрение отвечает бизнес. Кто-то внутри компании должен стать владельцем изменений: выдать доступы, объяснить новые правила, контролировать использование и собирать обратную связь. Подрядчик может помочь в согласованном объёме, но ежедневную дисциплину сотрудников и решения руководителя компания не передаёт ему вместе с разработкой.
Этапы удобно видеть отдельно:
идея → прототип → рабочая система → использование в компании → экономический эффект
Граница проходит по договорённостям проекта. Исполнитель отвечает за согласованный функциональный результат и подготовку к запуску. Компания — за регулярное применение системы и решения, которые должны привести к бизнес-результату.
Как это выглядит в проекте клининговой компании
В проекте для клининговой компании мы собрали в одной системе объекты, планы и табели. Менеджеры отмечают фактические часы, а руководители получают сводную картину по объектам, сотрудникам, часам и начислениям.
С технической стороны задача не заканчивалась экраном с формой. Нужно было связать роли менеджеров и руководителей, объекты, планы, табели и сводные данные. Система также предлагает повторяющиеся строки из последнего сохранённого дня как черновик и не перезаписывает уже сохранённые данные.
Сейчас система используется в ежедневной работе. Но её техническая готовность сама по себе не определяла, кто и когда вносит данные, как контролируется выполнение и какие управленческие решения принимаются на основе сводной картины. Это компании всё равно нужно было организовать внутри.
Работоспособность системы и её регулярное использование — два самостоятельных результата. Оба нужны, но сами по себе ещё не гарантируют экономический эффект.
Профессиональная команда может отвечать за технический результат и помогать компании подготовиться к внедрению. Но она не может принять на себя управленческую ответственность клиента.
Как выбрать следующий шаг
Сначала стоит определить, в какой точке находится задача.
Вы пока изучаете возможности AI
Есть потенциально полезный процесс, но пока непонятно, стоит ли превращать его в отдельную систему. При этом собственник готов лично тратить время на эксперименты и разбираться в технологии.
Можно начать самостоятельно: использовать готовые сервисы, собирать небольшие прототипы и проверять отдельные предположения. Главное — не принимать работающую демонстрацию за почти готовый продукт.
Проблема понятна, но решение и объём пока неизвестны
Компания может объяснить, что её не устраивает в текущем процессе, но пока нельзя точно назвать будущие функции, границы, сроки и цену.
Заказывать разработку на глаз рано. Сначала нужно исследование, которое зафиксирует проблему, ожидаемое изменение, метрику, данные и одно из трёх решений: разрабатывать систему, изменить исходную идею или не начинать проект.
Задача и ожидаемый результат уже описаны
Понятно, какие данные поступают на вход, кто участвует в процессе, что должна делать система и как проверить результат. Компания готова предоставить данные, назначить внутреннего владельца и организовать использование после запуска.
Такую задачу можно передавать подрядчику. После проверки исходных данных стороны смогут согласовать границы, цену, критерии приёмки и поддержку до начала основной разработки.
Перед выбором пути полезно ответить на четыре вопроса:
- Можем ли мы чётко описать процесс и нужный результат?
- Готов ли собственник лично потратить месяцы на непрофильное погружение?
- Есть ли внутри компании человек, который будет отвечать за использование системы?
- Что нам нужно сейчас: изучить возможности, исследовать неясную задачу или получить рабочую систему?
Если пока непонятно, нужен ли процессу отдельный продукт, начните с самостоятельной проверки. Если проблема ясна, но функции, метрика и объём неизвестны, закажите исследование. Если входные данные, результат, проверка и внутренний ответственный уже определены, обсуждайте разработку.
Если хотите понять, какой маршрут подходит вашей компании, принесите на разбор один повторяющийся процесс: кто его выполняет, какие данные использует и где сейчас возникают задержки или ошибки. По результату определим следующий шаг и его причину. Это дешевле, чем потратить месяцы на разработку неясной задачи.
Материалы о таких системах собраны в разделе «Практика AI и цифровых систем».