# С чего начать внедрение ИИ в компании без специалистов

> Руководство для компании без ИИ-специалистов: как за неделю найти процессы-кандидаты, проверить их по чек-листу, выбрать метрику и что спросить у подрядчика.

- Источник: https://lokai.ru/blog/s-chego-nachat-vnedrenie-ii/
- Организация: Local AI — Внедрение ИИ в закрытом контуре
- Обновлено: 2026-08-07
- Раздел: Главная → Блог → С чего начать

---

Начинать нужно не с выбора модели, а с поиска процесса: частого, повторяемого, с понятным критерием правильного результата. На это хватает недели и трёх человек внутри компании — ИИ-специалист не нужен. Ниже план по дням, чек-лист готовности процесса, таблица признаков «годится или нет» и вопросы, которые стоит задать подрядчику до подписания договора.

## Неделя на поиск процессов: план по дням

Задача недели — не выбрать технологию, а выйти с тремя процессами-кандидатами и цифрами по ним. Нужны три человека: тот, кто соберёт список, руководитель подразделения-владельца и ИТ-специалист на пару часов.

1. **День 1. Соберите список кандидатов.** Обойдите руководителей с одним вопросом: какая работа в отделе повторяется каждый день и занимает больше всего времени. Записывайте одной строкой: процесс, подразделение, кто выполняет.
2. **День 2. Проставьте объёмы.** По каждому кандидату — сколько операций в месяц и сколько минут уходит на одну. Оценка на глаз допустима: погрешность в четверть решения не меняет, отсутствие цифры меняет всё.
3. **День 3. Отсеките неподходящее.** Уберите процессы реже 50 операций в месяц, процессы без письменных правил и те, где каждый случай уникален. Обычно после этого шага из пятнадцати кандидатов остаётся пять.
4. **День 4. Проверьте данные.** По каждому оставшемуся: есть ли регламент, в каком он виде, где лежат примеры правильно выполненной работы, кто в компании считается носителем знаний по этому процессу.
5. **День 5. Выберите метрику и посчитайте потолок.** Умножьте объём операций на время и на стоимость часа сотрудника. Это верхняя граница эффекта — реальный будет меньше, но порядок величины уже виден.
6. **День 6. Соберите ограничения.** Персональные данные, коммерческая тайна, требования службы безопасности, доступность API у ваших систем. Это влияет на выбор контура и на сроки согласований сильнее, чем на выбор модели.
7. **День 7. Назначьте владельца.** По каждому финалисту нужен человек с именем и фамилией, готовый тратить несколько часов в неделю. Кандидат без владельца из списка вычёркивается, каким бы выгодным он ни выглядел.

## Признак процесса: годится для первого сценария или нет

Таблица применяется к каждому кандидату по всем строкам. Одно совпадение в правой колонке — ещё не отказ, три и больше — процесс в первую волну не берут.

*Признаки процесса, пригодного и непригодного для первого внедрения ИИ*

| Признак | Годится для первого сценария | Плохой кандидат |
|---|---|---|
| Частота | От 50 операций в месяц, поток стабильный | Несколько раз в квартал, всплесками |
| Повторяемость | Шаги совпадают в 8 случаях из 10 | Каждый случай разбирается индивидуально |
| Правила | Есть регламент или устойчивая практика | Правила знает один человек и объяснить не может |
| Критерий качества | Понятно, что считать верным ответом | Оценка субъективная и меняется от проверяющего |
| Данные | Документы и примеры собраны, версии актуальны | Три хранилища, противоречия, свежесть неизвестна |
| Цена ошибки | Ошибка заметна и обратима | Ошибка стоит денег и всплывает через месяцы |
| Системы | Битрикс24, 1С, почта, телефония — есть API | Самописная система без интеграций и документации |
| Владелец | Есть руководитель, заинтересованный в результате | Процесс ничей, отвечают все понемногу |
| Измеримость | Метрика снимается из системы без ручного счёта | Эффект придётся оценивать опросом сотрудников |

## Как оценить объём и повторяемость без аналитика

Объём берётся из системы, а не из ощущений. В CRM это число сделок или обращений за месяц, в почте — число писем в нужной папке, в 1С — количество документов вида. Любая из этих цифр достаётся за час фильтром и выгрузкой в таблицу.

Время на операцию считается замером, а не опросом: попросите двух сотрудников неделю отмечать в таблице начало и конец десяти операций. Средняя по двадцати замерам точнее, чем любые «ну минут двадцать». Отдельно фиксируйте время ожидания — согласований, ответа коллеги, доступа к системе: часто оно и оказывается основной потерей.

Повторяемость проверяется на выборке. Возьмите 20 последних случаев подряд, не выбирая, и разложите на две стопки: прошло по стандартному сценарию и потребовало отдельного разбора. Если стандартных 16 и больше, процесс годится. Если меньше половины, автоматизировать пока нечего — сначала нужно навести порядок в правилах.

Порядок эффекта считается в одну строку: объём в месяц × время на операцию × стоимость часа. Это верхняя граница. Реалистично планировать долю от неё: обычно машине уходит часть операций целиком, часть — с проверкой человеком, часть остаётся людям. Точный расчёт делается на [диагностике](https://lokai.ru/besplatnyy-audit-ii/), но собственная оценка нужна раньше, чтобы понимать, о каких деньгах вообще идёт речь.

## Как выбрать метрику, по которой судить о результате

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

Хорошая метрика удовлетворяет трём условиям: снимается из системы без ручного подсчёта, меняется в пределах срока пилота и понятна человеку, который платит. Рабочие примеры: среднее время обработки обращения, доля заявок, закрытых без участия оператора, конверсия квалифицированных лидов в сделки, срок подготовки регулярного отчёта.

Плохие метрики выглядят солидно и не проверяются: «повышение качества обслуживания», «удовлетворённость сотрудников», «число обработанных запросов» без сравнения с ручным процессом. Отдельно опасна метрика, которую легко улучшить в ущерб делу, — например, скорость ответа без контроля правильности.

Замер «до» снимается заранее и записывается в документ. Это скучный шаг, который пропускают чаще всего, и потом весь разговор об эффекте превращается в обмен впечатлениями. В наших кейсах цифры считал сам заказчик — до и после, по одной методике: [примеры результатов](https://lokai.ru/keysy/) с методикой расчёта опубликованы.

## Что подготовить перед разговором с подрядчиком

Подготовка занимает пару часов и экономит две-три встречи. Выгружать базы не нужно — нужны описание, цифры и ограничения.

1. **Процесс одним абзацем**: что приходит на вход, какие шаги, кто принимает решения, что считается хорошим результатом, куда уходит результат дальше.
2. **Цифры по объёму и времени**: операций в месяц, минут на операцию, сколько человек занято, стоимость часа с учётом налогов и накладных. Диапазон допустим.
3. **Список систем**: Битрикс24, 1С, почта, телефония, хранилище документов. Версия, облако или коробка, есть ли доступ к API и кто им владеет.
4. **Материалы процесса**: регламенты, инструкции, шаблоны, 10–20 примеров правильно выполненной работы и пара примеров с ошибками. На них потом проверяется качество.
5. **Ограничения по данным**: что нельзя выпускать за периметр, есть ли персональные данные, какие требования выдвигает служба безопасности и сколько времени занимает согласование.
6. **Метрика и замер «до»** — выбранная цифра и её текущее значение, зафиксированное письменно.
7. **Кто принимает решение** по проекту и по бюджету. Разговор без этого человека заканчивается ещё одной встречей.

## Какие вопросы задать подрядчику

Ответы на эти семь вопросов отличают инженерный подход от продажи презентации. Ни один из них не требует технической подготовки со стороны спрашивающего.

1. **Где физически будут храниться наши данные и уходит ли хоть один запрос во внешний сервис.** Ответ должен быть конкретным: сервер, контур, список внешних вызовов.
2. **Какая метрика будет считаться результатом пилота и как снимается замер «до».** Если метрику предлагают определить позже, разговор закончится спором о результате.
3. **Что происходит, если пилот не сработал.** Сколько мы потеряем, что останется у нас, есть ли зачёт стоимости пилота в цену внедрения.
4. **Кому принадлежат код, модели и данные после проекта** и что написано в договоре про условия выхода. Формулировка «всё ваше» на словах ничего не стоит.
5. **Как выходят обновления и что защищает работающий процесс от поломки.** Спросите про версионирование, ручную проверку релиза и время отката.
6. **На чьих моделях всё работает и что будет при отключении доступа.** Открытые веса на своём железе и закрытый зарубежный API — разные истории с точки зрения рисков.
7. **Кто и сколько времени тратит с нашей стороны.** Честный ответ содержит роли и часы в неделю, а не фразу «мы всё сделаем сами».

## Чего не стоит делать на старте внедрения ИИ

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

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

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

Не поручайте выбор процесса только ИТ-департаменту. ИТ видит системы, но не видит, где именно в работе теряются часы. Кандидатов называют руководители подразделений, ИТ проверяет их на реализуемость. Обратный порядок даёт технически удобные сценарии с нулевым эффектом.

И не ждите «правильного момента», когда данные будут в порядке. Данные приводятся в порядок в ходе первого сценария, и это одна из полезных побочных частей работы. Общий порядок шагов после того, как процесс выбран, описан на странице [внедрения ИИ в бизнес](https://lokai.ru/vnedrenie-ii-v-biznes/).

## Частые вопросы про начало внедрения ИИ

**Нужно ли нанимать ИИ-специалиста, прежде чем начинать?**

На старте — нет. Для поиска процессов и оценки объёмов нужны люди, которые знают работу изнутри: руководитель подразделения, исполнитель и один ИТ-специалист для вопросов по системам. Компетенция по моделям приходит со стороны подрядчика и по ходу проекта передаётся администратору на вашей стороне. Собственный ИИ-инженер окупается, когда сценариев становится больше десятка и компания хочет вести разработку сама. Нанимать его до первого измеренного результата рискованно: неясно, какая именно квалификация понадобится, и человек полгода занимается исследованием вместо работы.

**С какого процесса начать, если болит сразу несколько?**

С того, который чаще повторяется и проще измеряется, а не с самого болезненного. Самая заметная боль обычно оказывается сложным процессом: редким, нестандартным, завязанным на согласования и на конкретных людей. Первый сценарий решает задачу доверия — нужен результат за 2–4 недели и цифра, которую можно показать. Типичный удачный первый выбор: разбор входящих обращений, подготовка коммерческих предложений по прайсу, проверка комплектности документов, сборка регулярного отчёта. Тяжёлый процесс от этого никуда не денется, он берётся во вторую волну на уже развёрнутой инфраструктуре.

**У нас маленькая компания. Есть ли смысл вообще начинать?**

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

**Что делать, если данные в компании в беспорядке?**

Это обычное состояние, и ждать его исправления не нужно. Порядок наводится в рамках первого сценария и только по тому куску данных, который нужен ему: регламенты одного процесса, актуальные версии, набор примеров. Это одна-три недели работы, где основную часть решений принимает ваш носитель знаний, а не подрядчик. Полезный побочный эффект — часть найденных противоречий чинится переписанным регламентом и даёт эффект без всякого ИИ. Попытка привести в порядок все данные компании перед стартом растягивается на год и заканчивается тем, что проект не начинается.

**Сколько времени сотрудники потратят на проект?**

На пилоте владелец процесса тратит несколько часов в неделю: разбор процесса, ответы на вопросы, проверка результатов. ИТ-специалист подключается точечно — доступы, выгрузки, интеграции, суммарно несколько дней за пилот. Два-три исполнителя работают через систему на своих обычных задачах и отмечают ошибки, это не отдельная нагрузка, а изменённый способ делать ту же работу. Постоянная роль появляется одна: администратор системы, который к концу внедрения умеет добавлять документы в базу знаний, менять правила и читать дашборды без подрядчика.

**Можно ли попробовать самим на публичных сервисах, прежде чем звать подрядчика?**

Как способ познакомиться с возможностями — да, и это полезно: команда перестаёт бояться инструмента. Как способ проверить сценарий — почти нет. Ручные эксперименты в чате показывают, что модель в принципе умеет формулировать ответ, но ничего не говорят о качестве на вашем потоке, о работе с внутренними документами и об интеграции с 1С или Битрикс24. Отдельно проверьте, что уходит в такие сервисы: договоры, персональные данные и переписку клиентов туда загружать нельзя, и об этом стоит предупредить сотрудников до, а не после.

---

Бесплатный аудит и расчёт окупаемости на ваших данных: https://lokai.ru/besplatnyy-audit-ii/

Почта: hello@lokai.ru · 123112, Москва, ММДЦ «Москва-Сити» · Пн–Пт, 09:00–19:00 МСК