От корпоративного ПО к цифровой организации

Кратко: что узнает руководитель

Речь не о том, чтобы заменить все программы одним чат-ботом или отказаться от IT-специалистов. Речь о новом способе управлять развитием цифровой среды: бизнес формулирует задачу обычным языком; ИИ помогает подготовить изменение; система проверяет совместимость, данные, полномочия и безопасность; ответственный человек разрешает выпуск. При этом работающие учётные и производственные процессы не должны зависеть от доступности чата. Уже действующие CRM, ERP, 1С, складские, кадровые и другие решения можно сохранять и связывать между собой, если позволяют их интерфейсы и права доступа.

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

Что является фактом, а что прогнозом. Генеративный ИИ уже используется для помощи в разработке, подготовке кода, интерфейсов и автоматизаций. Распространение полностью управляемого изменения сложных корпоративных систем через диалог — сценарий развития, а не гарантированная функция любой CRM или ERP. AINUM Office, CRM, ERP и другие разработки авторов рассматриваются как практический опыт создания работающих решений; конкретная промышленная готовность каждой функции, интеграции и нагрузки требует отдельного подтверждения испытаниями.

1. Главная проблема руководителя — не недостаток программ, а разрыв между решением и изменением

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

Сама по себе такая последовательность не ошибочна: критические изменения должны проходить проверки. Проблема возникает, когда даже небольшая управленческая корректировка превращается в долгий и дорогой IT-проект. Бизнес меняется быстрее, чем обновляются его цифровые инструменты. Предприятие вынуждено подстраивать работу под ограничения программ, хотя программа должна помогать выполнять бизнес-задачи.

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

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

2. Три разных смысла фразы «создать программу с ИИ»

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

Модель А — ИИ как помощник разработчика. Программист использует модель для генерации кода, тестов, документации и поиска ошибок. За архитектуру и выпуск отвечает профессиональная команда. Эта модель уже применяется в отрасли.

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

Модель В — ИИ как участник непрерывного развития корпоративной системы. Руководитель формулирует управленческую цель. Система оценивает, можно ли использовать существующие функции, какие данные и интеграции нужны, какие риски появятся; затем готовит формальную спецификацию, проверяет её и выпускает управляемое изменение. Новая функция становится частью общей архитектуры, а не отдельным изолированным приложением.

Модель В — наиболее значимое направление для НУМ. Но она не отменяет инженеров. Она меняет распределение труда: бизнес отвечает за цели и правила, ИИ ускоряет проектирование, техническая среда обеспечивает ограничения, специалисты отвечают за сложные и критические участки, уполномоченные лица утверждают изменения.

3. Не «построить ERP за вечер», а развивать систему без переписывания всего предприятия

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

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

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

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

4. Добавление функций обычным языком: как должен выглядеть управляемый процесс

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

После уточнений формируется BusinessBrief — описание бизнес-цели. Из него появляется SolutionBlueprint — проект решения: формы, данные, процессы, роли, интеграции. Затем ExecutableSpec — проверяемое описание изменений. Автоматические проверки выявляют конфликт имён полей, нарушение доступа, несовместимость со старыми отчётами, ошибки миграции. Человек утверждает выпуск; создаётся ReleaseManifest, фиксирующий версию и состав изменений.

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

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

5. Интеграция действующих систем: новая система не обязана уничтожать старую

На предприятии редко существует единственная информационная система. Бухгалтерия может работать в 1С, продажи — в CRM, документооборот — в отдельном сервисе, производство — в отраслевом ПО, склад — в WMS, а часть задач — в Excel. Смена одной программы не должна автоматически означать замену всех остальных.

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

Сценарий 1: подключение существующей 1С. Руководитель хочет видеть оплату заказов в CRM. Система уточняет доступные механизмы обмена, согласует ключи соответствия контрагентов и документов, проверяет режим чтения или записи, предлагает расписание синхронизации и обработку ошибок. Если API или другой законный механизм обмена недоступен, обещать автоматическую интеграцию нельзя.

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

Сценарий 3: подключение системы без готового API. Иногда возможны согласованный файловый обмен, выгрузки CSV/XLSX, очереди сообщений или специально разработанный коннектор. Но автоматизация через экран и обход защит могут быть ненадёжными и недопустимыми. Выбор способа зависит от технических и договорных условий.

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

6. Локальные и облачные LLM без ручного вмешательства в код

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

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

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

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

7. AINUM Office, CRM, ERP и специализированные решения: практическая основа подхода

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

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

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

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

AINUM Office: реальные интерфейсы и управленческие задачи

Ниже представлены изображения действующего интерфейса AINUM Office. Они показывают не абстрактную концепцию, а конкретные рабочие экраны: кабинет руководителя, систему показателей, управленческий контур и контроль проблем. Вместе они иллюстрируют принцип НУМ: руководитель видит задачи, людей, данные и решения в связанном рабочем пространстве.

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

8. Будущее поставщиков ПО: от продажи функций к продаже способности безопасно изменяться

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

Поставщики могут двигаться по разным траекториям. Одни сохранят закрытые продукты и ограничат ИИ-персонализацию. Другие предоставят управляемые конструкторы. Третьи предложат гибрид: готовое ядро и расширения, создаваемые заказчиком. В критических отраслях сохранятся строгие процедуры сертификации, тестирования и профессионального сопровождения.

У заказчика появятся новые критерии выбора платформы: можно ли экспортировать данные и конфигурацию; как фиксируются изменения; можно ли сменить модель ИИ; доступны ли API; кто владеет созданными расширениями; насколько безопасно восстановление; есть ли документированный выход от поставщика. Самая дешёвая лицензия не обязательно обеспечивает самую низкую зависимость.

9. Управленческая скорость: более важный показатель, чем скорость генерации кода

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

В условном примере традиционный путь занимает 90 дней, а ИИ-поддерживаемый — 25. Это не статистика и не обещание шестикратного ускорения: реальные сроки зависят от сложности, регуляторных требований и готовности данных. Важно другое: если предприятие сокращает время изменения без роста ошибок, оно может быстрее реагировать на спрос, цены, поставки и сбои.

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

10. Экономика: купить, доработать, создать или объединить

Решение о цифровой стратегии должно опираться на полную стоимость владения (TCO), а не на стоимость первой разработки. Учитываются лицензии, внедрение, инфраструктура, интеграции, безопасность, поддержка, обучение, миграции, обновления, простои, стоимость ошибок и зависимость от поставщика.

Иллюстративный расчёт на три года, млн рублей (не фактический кейс): готовая платформа — лицензии 3, внедрение 4, интеграции 2, сопровождение 3, всего 12; гибридный подход — базовые лицензии 1,5, настройка и модули 3, интеграции 2, сопровождение и инфраструктура 3,5, всего 10. Разница 2 млн существует только при указанных допущениях. При дополнительном персонале, ошибках или более дорогой инфраструктуре гибрид может оказаться дороже. При повторном использовании модулей — выгоднее. Ни одну из сумм нельзя переносить на конкретное предприятие без обследования.

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

Как считать экономику: пример с прозрачными допущениями

Для собственника важна не стоимость генерации кода, а совокупные затраты за весь период использования системы — TCO (Total Cost of Ownership). В расчёт входят лицензии, настройка, интеграции, сопровождение, инфраструктура, безопасность, обучение, обновления и возможные простои.

Ниже приведён условный расчёт для предприятия со 100 пользователями на три года. Это не тарифы поставщиков, не предложение «Яркиной школы» и не доказанный результат внедрения AINUM. Цифры специально приведены для демонстрации метода сравнения.

В этой модели гибридный вариант дешевле готового на 1 млн ₽ за три года, или на 10%. Однако изменение стоимости лицензий, интеграций или поддержки способно изменить результат. Поэтому нельзя объявлять собственную платформу выгоднее без расчёта на данных конкретной организации.

Экономия рабочего времени: как избежать завышения эффекта

Предположим, 20 сотрудников экономят по 15 минут в рабочий день, 220 дней в году. Это 1 100 часов высвобождённого времени за год. При расчётной полной стоимости часа 800 ₽ теоретический эквивалент составит 880 000 ₽. Но это ещё не денежная экономия: она возникает лишь тогда, когда высвобождённое время действительно сокращает затраты, увеличивает выпуск, продажи или предотвращает измеримые потери. Потребуются исходный замер, контрольный период и учёт затрат на внедрение.

11. Переход от цифрового следа к корпоративной памяти решений

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

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

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

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

12. Карточка управленческого решения: минимальная единица памяти

Предлагаем ввести формальную Decision Record — карточку решения. Её поля: идентификатор; дата и версия; владелец; бизнес-проблема; исходные показатели; источники; ограничения; рассмотренные варианты; ожидаемые последствия; утверждающий; принятое действие; критерии успеха; дата повторной оценки; фактические показатели; объяснение отклонений; ссылки на подтверждения; статус достоверности; права доступа и срок хранения.

Пример (вымышленный): «Решение DR-2026-014. Увеличить страховой запас компонента А с 12 до 20 дней. Причина: повторяющиеся задержки поставок. Альтернатива: второй поставщик; отклонена из-за отсутствия подтверждённой квалификации. Ожидание: уменьшить риск остановки линии. Через 90 дней: простоев из-за компонента не было, но оборотный капитал вырос. Вывод: пересмотреть запас после квалификации альтернативного поставщика».

Через два года новый сотрудник увидит не только число «20 дней», но и причины. Однако ему следует проверить, сохранились ли те же сроки поставки и ограничения. Память — не приказ повторять прошлое, а доказательная основа для нового решения.

Особая ценность — записи об отказе от решения. Почему не внедрили определённую CRM? Почему отклонили автоматизацию? Какие ошибки выявили в испытаниях? Такие сведения предупреждают повторное расходование ресурсов.

13. Передача должности: как сделать преемственность управляемым процессом

Обычная передача дел часто сводится к списку документов, паролей и незавершённых задач. Но новому руководителю необходимо понимать зависимости и причины существующих правил. Корпоративная память позволяет создать пакет вступления в должность: карта процессов, текущие обязательства, критические решения, открытые риски, история инцидентов, действующие ограничения, перечень источников данных, контактные роли и вопросы, требующие внимания в первые 30–90 дней.

Новый коммерческий директор спрашивает: «Почему мы не работаем с сетью X?». Система отвечает только на основании доступных ему подтверждённых записей: «В 2024 году переговоры приостановлены из-за условий отсрочки; финансовое заключение — документ такой-то; условия рынка могли измениться». Если сведений недостаточно, система предлагает обратиться к ответственному подразделению.

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

14. Память успешных решений, ошибок и несостоявшихся инициатив

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

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

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

15. Как корпоративный ИИ использует память и не подменяет доказательства выдумками

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

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

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

16. Безопасность и этика: память предприятия не должна стать тотальной слежкой

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

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

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

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

17. От памяти к обучающейся организации: что действительно можно измерять

Накопление записей само по себе не означает обучения. Для этого необходим замкнутый цикл: решение → ожидаемый результат → наблюдение → сравнение → объяснение отклонений → изменение правил. Система может помогать находить повторяющиеся проблемы, но не должна объявлять корреляцию доказанной причиной.

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

Потенциально предприятие сможет задавать вопросы: «Какие решения снижали простои?», «Где согласования создают задержки?», «Какие гипотезы проверяли дважды?», «Что изменилось после подключения нового поставщика?». Ответы должны содержать контекст и альтернативные объяснения.

18. НУМ как архитектура: свобода цифрового развития плюс единое управление

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

НУМ — Новая управленческая модель — объединяет человеческий контур, цифровых исполнителей, данные, регламенты, цифровой след, корпоративную память и контроль. Человек определяет цели и утверждает решения; ИИ помогает проектировать и анализировать; формальная архитектура удерживает согласованность; журнал действий обеспечивает проверяемость; результаты возвращаются в организационную память.

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

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

Центральная архитектура цифровой организации

НУМ объединяет не отдельные программные продукты, а роли, решения, процессы и правила. Следующая схема показывает целевую архитектуру: часть функций уже представлена в интерфейсах AINUM Office, другие элементы отражают направление развития и не должны восприниматься как подтверждение полной реализации.

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

19. Как меняются роли собственника, директора, IT-службы и сотрудников

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

Руководитель подразделения должен уметь формулировать требования и объяснять, какой результат ему нужен. Сотрудник получает инструменты для улучшения процессов, но не безграничные полномочия. HR и корпоративное обучение обеспечивают развитие компетенций и преемственность, не превращая цифровую память в систему скрытого наблюдения. Служба безопасности и юристы участвуют в проектировании правил, а не только проверяют готовый продукт в конце.

Это не означает массовой отмены профессий. Скорее меняется распределение задач: рутинная подготовка может ускоряться, а значимость архитектуры, проверки, предметной экспертизы и ответственности возрастает.

20. Три сценария будущего до 2030 года

Консервативный: ИИ остаётся преимущественно инструментом IT-команд. Бизнес-пользователи получают более удобные отчёты и автоматизации, но серьёзные изменения требуют разработчиков. Базовый: платформы разрешают самостоятельно создавать типовые модули и интеграции через управляемые конструкторы; критические функции проходят отдельные проверки. Трансформационный: предприятия получают адаптивную цифровую среду, где функции, подключения, модели ИИ и корпоративная память управляются через единые правила, а изменение процессов становится непрерывным управленческим циклом.

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

Не следует утверждать, что к определённому году «все IT-компании» предоставят такие возможности. Стратегически важнее уже сегодня выбирать решения, которые не блокируют дальнейшее развитие и переносимость данных.

21. Индекс управляемой самостоятельности: как оценить платформу

Для управленческой диагностики предлагаем авторскую модель ИУС — индекса управляемой самостоятельности. Это не отраслевой стандарт и не сертификация, а предварительная рамка оценки. Критерии:

1. Самостоятельное создание типовых функций
2. Управляемые интеграции
3. Возможность выбора локальных и облачных LLM
4. Безопасность и разграничение прав
5. Версионирование, испытания и откат
6. Переносимость данных и конфигураций
7. Прозрачность совокупной стоимости
8. Сохранение и проверяемость истории решений

Каждый критерий можно предварительно оценить от 0 до 5, но равные веса не подходят для всех отраслей. Для производственного предприятия безопасность и непрерывность могут иметь больший вес, чем удобство конструктора; для небольшой сервисной компании — наоборот. Итоговый балл нельзя использовать как доказательство надёжности без независимых испытаний.

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

22. Дорожная карта первых 90 дней

Дни 1–15. Управленческая диагностика. Определить три наиболее дорогих разрыва между процессом и цифровой системой. Описать исходные показатели, ответственных и ограничения. Инвентаризировать существующие CRM, ERP, 1С, склад, документы и источники данных. Не начинать с покупки новой платформы.

Дни 16–30. Архитектурная проверка. Выяснить, какие функции уже доступны, какие API и выгрузки разрешены, где хранятся первичные данные, кто владеет справочниками, какие сведения нельзя передавать облачным LLM. Установить правила допуска изменений и роли согласующих.

Дни 31–60. Один ограниченный пилот. Выбрать измеримую задачу: отчёт о дебиторской задолженности, согласование заявок, контроль складских отклонений или поиск оснований прошлых решений. Подготовить требования, реализовать изменение в тестовом контуре, проверить качество данных, права и восстановление.

Дни 61–75. Измерение эффекта. Сравнить показатели до и после: трудозатраты, время цикла, количество ошибок, качество данных, затраты на сопровождение. Зафиксировать отрицательные эффекты и ограничения. Не приписывать весь результат ИИ, если одновременно менялись процессы и персонал.

Дни 76–90. Масштабирование и память. Решить, расширять ли решение. Создать первые карточки значимых управленческих решений, установить владельцев данных и сроки повторной оценки. Утвердить план следующего этапа и бюджет на сопровождение.

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

Три отраслевых сценария применения

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

23. Вопросы, которые собственник должен задать до инвестиций

1. Какую бизнес-проблему решаем и как измерим результат?
2. Можно ли использовать уже действующую систему?
3. Какие данные являются первичными?
4. Кто имеет право инициировать, утверждать и публиковать изменения?
5. Можно ли заменить LLM без потери функций и данных?
6. Что произойдёт при недоступности ИИ?
7. Как система восстановится после неудачного изменения?
8. Кому принадлежат созданные функции и конфигурации?
9. Можно ли экспортировать историю решений с источниками?
10. Как защищены персональные и коммерческие данные?
11. Кто сопровождает систему через три года?
12. Как мы отличим реальную экономию от красивой демонстрации?

Если на эти вопросы нет ответов, проект пока не готов к масштабированию — независимо от того, насколько впечатляет генерация интерфейса.

24. От исследования к оценке результата: ИИ-эффект

Главный практический вывод — не начинать с технологии. Сначала нужно понять, где предприятие теряет деньги, время, знания или управляемость. Затем определить, какие изменения принесут измеримый результат, и только после этого выбирать инструменты.

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

Краткий словарь для руководителя

Источники и основания исследования

Авторские выводы о НУМ и корпоративной памяти представлены как концепция и направление развития. Для сопоставления с существующими практиками и принципами контроля использованы следующие первичные материалы:

1. Microsoft Learn — создание бизнес-приложений Power Apps и применение Copilot. Пример развития инструментов разработки приложений через естественный язык.
2. Microsoft Learn — возможности и ограничения Copilot в Power Apps. Важны предварительные условия и различие между экспериментальными и промышленными функциями.
3. NIST — AI Risk Management Framework. Подход к управлению рисками, надёжности, ответственности и прозрачности ИИ.
4. NIST — Govern, Map, Measure, Manage. Принципы непрерывного контроля рисков в жизненном цикле ИИ.
5. NIST AI 600-1 — Generative AI Profile. Специфические риски генеративных моделей.
6. Федеральный закон № 152-ФЗ «О персональных данных». Нормативная основа для проектирования работы с персональными данными; применимость конкретных требований определяется контекстом обработки.

Экономические таблицы и отраслевые ситуации в статье специально обозначены как расчётные примеры. Они не являются результатами независимого исследования рынка или отчётами о внедрении AINUM.

Заключение. Главное изменение — не в программах, а в способности организации развиваться и помнить

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

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

Чем доступнее создание цифровых возможностей, тем выше значение единой управленческой архитектуры. Конкурентное преимущество получит не тот, кто быстрее генерирует код, а тот, кто умеет безопасно превращать знания, данные и решения в устойчивые результаты. В этом состоит практический смысл НУМ — Новой управленческой модели: ЧЕЛОВЕК · ТЕХНОЛОГИИ · РЕЗУЛЬТАТ.

Об авторах

Государственная регистрация программы для ЭВМ

Свидетельство Роспатента подтверждает государственную регистрацию программы «Система автоматизации коллективной работы в распределённой среде». В документе Алексей Несмеянов указан автором и правообладателем. Регистрация программы не является сертификатом безопасности или подтверждением эксплуатационных характеристик других продуктов.

Алексей Несмеянов — автор и разработчик зарегистрированной программы для ЭВМ «Система автоматизации коллективной работы в распределённой среде», автор и разработчик цифровых решений AINUM, соавтор Новой управленческой модели (НУМ). На личной странице Алексея Несмеянова представлены направления исследований, изображения разработанных программ и материалы о практических решениях; раздел будет пополняться новыми кейсами.

Калина Яркина — руководитель «Яркиной школы — Центра комплексных бизнес-решений», соавтор Новой управленческой модели и настоящего исследования. Занимается управленческой практикой, внедрением искусственного интеллекта, цифровой безопасностью и обучением руководителей. Профессиональная страница Калины Яркиной.