Workflow
Фиксируем роль, действие, данные и решение в процессе.
Как выбирать ИИ, облака, данные, API, RPA, IoT и low-code под бизнес-процесс, KPI, безопасность и стоимость владения.
Карта выбора
Технология дает эффект, когда меняет workflow, KPI и стоимость владения, а не просто появляется в списке инструментов.
Фиксируем роль, действие, данные и решение в процессе.
Смотрим cycle time, error rate, SLA, adoption и TCO.
Подбираем AI, облако, API, BI или RPA только после проверки данных и безопасности.
Первый полезный контур должен попасть в реальное использование быстро.
19.07.2026 Технологии цифровой трансформации не работают как каталог покупок. ИИ, облако, BI, RPA, IoT, API или low-code дают эффект только тогда, когда выбраны под конкретный бизнес-процесс, метрику и ограничения: данные, безопасность, интеграции, стоимость владения и владельца результата. В 2026 году главный вопрос уже не в том, есть ли у компании цифровые инструменты. Они почти всегда есть.
Вопрос другой:
Рынок цифровой трансформации стал жестче к обещаниям. Gartner в CIO Agenda 2026 пишет, что 94% CIO ожидают существенные изменения планов и результатов в ближайшие 24 месяца, но только 48% цифровых инициатив достигают или превышают бизнес-цели. Это хороший фильтр для любой технологии: она должна выдерживать не презентацию, а изменение условий.
McKinsey в исследовании AI 2025 фиксирует уже 88% регулярного использования AI хотя бы в одной бизнес-функции, но масштабирование остается проблемой: примерно треть компаний начала масштабировать AI-программы. Один из сильных факторов результата - фундаментальная переработка workflow, а не сам факт использования модели.
| Сдвиг рынка | Что это значит для бизнеса | Что проверять перед внедрением |
|---|---|---|
| AI стал массовым | Пилот легко запустить, трудно довести до промышленного эффекта | Есть ли владелец процесса, eval, контроль качества ответа и human validation |
| Рост agentic AI | Модель не только отвечает, но и выполняет шаги в системах | Права, журнал действий, rollback, лимиты и контроль инструмента |
| Данные и семантика стали ядром | AI, BI и автоматизация зависят от качества справочников и смысла полей | MDM, владелец данных, lineage, единые определения KPI |
| Облака усложнились | Нагрузка выбирается по экономике, риску, latency и compliance | FinOps, data residency, отказоустойчивость, стоимость выхода |
| Безопасность стала частью продукта | AI и интеграции расширяют поверхность атаки | ISO/IEC 42001 или похожая система управления AI, NIST AI RMF, ИБ-архитектура |
Технологию удобно выбирать в обратном порядке:
Ниже не рейтинг технологий, а карта применимости. В зрелой трансформации контуры часто соединяются: AI-агент берет контекст из базы знаний, действует через API, пишет результат в ERP, а BI показывает метрику процесса.
| Контур | Когда брать | Что проверить | Типовой риск |
|---|---|---|---|
| AI-агенты и RAG | Нужно ускорить работу с документами, обращениями, кодом, аналитикой или знаниями | Источник правды, eval, права на инструменты, журнал действий | Агент отвечает уверенно, но без grounding и контроля качества |
| Data governance, MDM, semantic layer | Разные отделы считают один KPI по-разному или справочники расходятся | Владелец данных, мастер-система, правила качества, lineage | Красивый BI на грязных данных |
| API, ESB, event-driven integration | Системы должны обмениваться статусами, заказами, остатками, документами | Контракты API, события, идемпотентность, retry, мониторинг | Point-to-point связи превращаются в хрупкий монолит |
| Hybrid cloud и platform engineering | Нужна скорость поставки, но есть требования к данным, стоимости или отказоустойчивости | Placement workloads, FinOps, SRE, резервирование | Облако купили, но расходы и ответственность остались неуправляемыми |
| BI и decision intelligence | Руководителю нужна картина процесса, а не выгрузки по запросу | Единые определения метрик, владельцы отчетов, обновление данных | Дашборд живет отдельно от решений в процессе |
| RPA и workflow automation | Процесс стабилен, правила понятны, ручной ввод повторяется | Частота исключений, источник данных, ответственность за бота | Роботизация закрепляет плохой процесс |
| IoT и edge | Нужны фактические события с оборудования, склада, транспорта или точки продаж | Надежность датчиков, сеть, задержка, обработка на краю | Данные собираются, но не ведут к действию |
| Low-code/no-code | Нужны быстрые внутренние workflow и формы при понятных guardrails | Права, интеграции, lifecycle, кто поддерживает приложение | Shadow IT без контроля ИБ и архитектуры |
| Cybersecurity, observability, AI governance | Изменения должны быть безопасны и доказуемы | SLO, аудит, DLP, model risk, incident process | Безопасность добавляют после пилота, и прод останавливается |
| Blockchain / distributed ledger | Участникам нужен общий неизменяемый реестр без одного доверенного владельца | Нужна ли децентрализация на самом деле | Блокчейн используют там, где достаточно обычного журнала и подписи |
SMART полезен как базовая проверка цели, но для цифровой трансформации его мало. Технологию нужно оценивать через процессную матрицу.
| Критерий | Вопрос | Хороший признак |
|---|---|---|
| Процесс | Где именно меняется работа пользователя? | Есть BPMN или короткое описание workflow: кто, что делает, какими данными пользуется |
| KPI | Какая метрика меняется? | Cycle time, error rate, SLA, cost per transaction, adoption, revenue leakage |
| Данные | Какие данные нужны и кто ими владеет? | Названы мастер-системы, владельцы справочников, правила качества |
| Интеграции | С какими системами надо обмениваться? | Есть контракты API/events, мониторинг, повторная доставка и схема отказов |
| Безопасность | Какие данные чувствительные? | Права доступа, аудит, ПДн, журнал действий и требования ИБ описаны до пилота |
| TCO | Что будет стоить поддержка через год? | Считается разработка, эксплуатация, изменения, лицензии, облако, простой и риск vendor lock-in |
| TTU | Когда пользователи реально начнут работать иначе? | Есть короткий первый контур полезного использования, а не только дата сдачи проекта |
Пять SMART-вопросов перед покупкой любой системы (ERP, CRM, WMS и т. д.): какую задачу решит инструмент; как понять, что цель достигнута; насколько реально добиться ожидаемых результатов; почему внедрение нужно именно сейчас; сколько времени уйдёт на интеграцию и когда появится первый эффект. Если на любой из вопросов нет ответа - покупать рано.
| Ошибка | Как выглядит | Что делать вместо этого |
|---|---|---|
| Начали с инструмента | "Нам нужен AI / BI / low-code", но не назван процесс | Начать с workflow и KPI, затем выбрать технологию |
| Автоматизировали хаос | RPA или low-code повторяет ручные исключения | Сначала убрать лишние ветки и закрепить владельца процесса |
| Нет владельца данных | Отчеты спорят между собой, AI получает противоречивый контекст | Назначить master data owner и правила качества |
| Нет интеграционной архитектуры | Каждая новая система соединяется с каждой напрямую | Ввести API/events/ESB там, где это снижает связанность |
| Пилот не измеряет приемку | Команда показывает демо, но не считает success rate и ошибки | Сделать eval-набор, критерии приемки и замер результата |
| Безопасность приходит в конце | ИБ блокирует промышленный запуск | Включить ИБ, ПДн, аудит и model risk до выбора платформы |
| Не считают стоимость владения | Сравнивают цену лицензии или токена | Считать TCO процесса: эксплуатация, изменения, ошибки и стоимость поддержки |
Для KT.Team цифровая трансформация - это не внедрение максимального числа инструментов.
Единица изменения - конкретный workflow.
Мы смотрим, где процесс теряет время, деньги, качество или управляемость, а затем собираем слабосвязанный контур: данные, интеграции, интерфейс, AI или автоматизацию ровно там, где это меняет работу.
Это совпадает с нашим общим подходом: маленькая сильная команда, короткий TTU, слабая связанность, понятная ответственность за бизнес-результат.
Если в процессе достаточно API и нормального справочника, не нужен AI.
Если AI нужен, он должен иметь grounding, права, журнал действий и понятную стоимость результата.
Если нужна 1С, она должна оставаться частью ландшафта, а не превращаться в монолит, который держит все бизнес-изменения. На практике это выглядит так.
Для одного из клиентов мы собрали AI-платформу, где агент выполняет учётные операции по регламентам и работает с системами через API или MCP без доработок в учётном контуре, а каждое действие оставляет проверяемый аудитный след - та самая связка grounding, прав и журнала действий (разбор проекта).
Для дистрибьютора мы автоматизировали заказы на Odoo и сократили время обработки заказа на 85 процентов, запустив рабочую версию за четыре месяца (разбор проекта). Оценить, какие технологии нужны вашему процессу, можно на странице консалтинга по цифровой трансформации.
Читать дальше по теме - цифровая трансформация России, стратегия и рынок про нацпроект, господдержку и первый шаг для бизнеса, а также смежные решения AI для бизнеса и интеграции.
FAQ
Для большинства компаний важнее не отдельная технология, а связка: данные, интеграции, AI или автоматизация внутри конкретного процесса. Если данные плохие и системы не связаны, даже сильная AI-модель будет давать слабый результат.
Когда процесс уже описан, есть данные, понятен критерий качества результата и можно измерить success rate. Если этих условий нет, сначала нужно собрать контур данных и приемки.
RPA актуальна для стабильных правил и повторяющихся операций. AI-агенты полезнее там, где есть вариативность, документы, язык, контекст и необходимость принять решение. Часто они работают вместе: RPA закрывает жесткий шаг, AI готовит данные или классифицирует исключение.
Цена зависит от профиля нагрузки, требований к данным, отказоустойчивости, лицензий, сетей и команды эксплуатации. Для переменной нагрузки облако часто рационально, для стабильной высокой нагрузки и жестких требований к данным может быть выгоднее private/on-prem или гибрид.
Для KT.Team рабочий ориентир - короткий TTU: первый полезный контур должен попасть в реальное использование за недели, а не превратиться в длинную программу без обратной связи.
Дата проверки: 19.07.2026