Вернуться к Исследованию рынка
Intuiflow — программное обеспечение для планирования производства и дистрибуции, разработанное Demand Driven Technologies и приобретённое Algo в январе 2026 года. Оно дополняет ERP-системы планированием материалов, рекомендациями по пополнению запасов, составлением производственных расписаний, планированием спроса, продаж и операций. В основе лежит Demand Driven Material Requirements Planning, или DDMRP: стратегически размещённые буферы запасов определяют пополнение и операционные приоритеты. (1, 2, 11)
Общая оценка для цепочки поставок: 4,8/10.
| Направление | Оценка |
|---|---|
| Глубина понимания цепочки поставок | 4,2/10 |
| Содержательность решений и оптимизации | 4,4/10 |
| Целостность продукта и архитектуры | 5,6/10 |
| Техническая прозрачность | 5,8/10 |
| Серьёзность поставщика | 4,2/10 |
У Intuiflow есть конкретный операционный механизм и необычно полезная открытая документация по настройке. Система формирует заказы, учитывает спецификации изделий и связывает планирование с исполнением. Её главный недостаток — модель принятия решений: целевые уровни сервиса, коэффициенты буферов и приоритеты потоков заменяют явное экономическое сравнение выполнимых обязательств в условиях неопределённости. Автоматизация этих правил может сократить трудозатраты, но не доказывает, что правила выбирают наиболее ценные решения.
Aptiv сообщает о существенном улучшении запасов, которое сопровождалось значительной работой по внедрению. Старая симуляция поставщика наглядно раскрывает метод буферов, включая корректировки после обнаруженных дефицитов. Нынешний Autopilot обещает избавить от ручной настройки, однако его публичное описание не объясняет, как обученные политики улучшают денежные результаты или учитывают неопределённость поставок. (7, 12, 14)
Intuiflow в сравнении с Lokad
Рассмотрим компонент, отсутствие которого может остановить сборочную линию. Обычный поставщик предлагает низкую цену, но иногда опаздывает; альтернативный поставщик дорог; несколько готовых изделий конкурируют за один компонент. Буфер может защитить производство, но его желательный размер зависит от стоимости готовых изделий, распределения дат поступления, расходов на срочную доставку и других закупок, претендующих на те же денежные средства.
Intuiflow подходит к проблеме через размещение запасов, приоритеты пополнения и настроенную защиту. Подход Lokad к оптимизации запасов оценивает регулярные обязательства по ожидаемым экономическим последствиям, используя вероятностные проекции и постоянно поддерживаемую числовую логику решений. Специалисты по цепочке поставок разрабатывают и пересматривают эту логику по мере изменения операционных условий.
Различие заключается в том, что именно поручают оптимизировать программе. Высокий целевой уровень сервиса не объясняет, куда направить следующий доллар: на этот компонент, другой, срочную доставку или альтернативного поставщика. Подход, изложенный в Introduction to Supply Chain, начинается с конкурирующих способов использования ресурсов. Публичный метод Intuiflow, напротив, требует от организации выразить значительную часть этого выбора через расположение буферов, коэффициенты, приоритеты и исключения.
Что программа действительно рассчитывает
Открытый Client Playbook объясняет решения при внедрении, рабочие процедуры и переход к поддержке. В нём есть прежняя терминология Replenishment+ и иллюстрированный пример клиентской конфигурации со снимками экрана 2023 года. Это полезное свидетельство поддерживаемых механизмов; настройки примера не следует принимать за универсальные значения по умолчанию или спецификацию более нового Autopilot. (18)
Буферы сводят неопределённость к категориям и коэффициентам
Smart Buffer Profiler группирует позиции по истории спроса, диапазонам сроков поставки и коэффициентам вариации. Пользователи выбирают исторические горизонты спроса, пороги применимости, коэффициенты срока поставки, коэффициенты вариабельности и горизонты всплесков. Полученные профили определяют цветные зоны буфера; зелёная зона учитывает минимальные объёмы заказа, циклы заказа и коэффициенты срока поставки. Предложенные профили можно проверить перед принятием. (3)
Это доступная для проверки эвристика. Её слабость — информация, отброшенная до принятия решения. Процессы спроса со сходными средними и коэффициентами вариации могут различаться хвостами распределения, устойчивостью во времени и связью с задержками поставщиков. Отнесение к одной категории не делает экономические риски равнозначными. Процент зоны буфера сам по себе не выражает разницу между потерей низкомаржинальной продажи и остановкой дорогостоящей производственной линии.
Категории сроков поставки также описывают длительность срока, а не опубликованное распределение вероятностей будущих поступлений. Метод характеризует вариабельность, но не публикует совместную проекцию спроса и поставок, возможные исходы которой оцениваются в деньгах при выборе заказов. Увеличение защитного коэффициента может компенсировать повторяющуюся проблему; оно не показывает, какой риск компенсирован и не обошлась бы другая реакция дешевле.
Исполнение и работа со спецификациями изделий действительно присутствуют
Настройки обработки различают позиции с буфером и без него, предусматривают расчёт чистой потребности MRP и автоматическое формирование заказов на снабжение для позиций без буфера. Сокращение срока поставки проверяет, доступны ли уже дочерние компоненты без буфера; наличие этих компонентов на складе позволяет приблизить обещанную дату родительского изделия. Прогнозируемое суточное потребление также может рассчитываться по прогнозам и разворачиваться по спецификации изделия. (4)
Workbench позволяет планировщикам менять количества, даты, источники снабжения и альтернативные спецификации, с функциями загрузки и упаковки. Утверждённые заказы попадают в таблицу ожидающих заказов для передачи в ERP. Это содержательный путь от решения к исполнению. (5, 6)
Такие взаимодействия важны. Продукт работает не только с независимыми целевыми значениями по SKU. Открытым остаётся вопрос выбора альтернатив в масштабе системы. Показать планировщику другого поставщика или альтернативную спецификацию — ещё не значит иметь расчёт, который выбирает между ними с учётом неопределённой доступности, маржи, общей мощности и денежных средств. Значительная часть такого согласования остаётся за пределами опубликованного правила буфера.
Выполнимость расписания зависит от условий
Модуль расписаний описывает конечные мощности, станки, смены, трудовые ресурсы, графики загрузки и ход работ в цехе. На текущей странице рекламируются «расписания, выполнимые на 100%» и утверждается, что учитывается каждое реальное узкое место. (8)
Расписание может быть выполнимым при моделируемых мощностях и всё же сорваться из-за поломки станка, опоздания доставки или брака компонента. Полезный вопрос — какие обязательства остаются экономически разумными при этих возможностях, включая стоимость пересоставления расписания. Ни проверка мощности, ни буфер не делают безусловную гарантию исполнения убедительной.
S&OP добавляет укрупнённое планирование мощностей и сценарии сбоев поставщиков и изменений спроса. В старой брошюре прогнозы прямо используются для симуляции будущего поведения буферов и выявления пробелов модели. Это разумное предвидение, но само изучение сценариев не даёт вероятностей и не выбирает экономически предпочтительную реакцию. (9, 21)
История технологий и целостность дорожной карты
Demand Driven Technologies основана в 2011 году. Её техническая идентичность по-прежнему сосредоточена на планировании, управляемом спросом. В октябре 2022 года Nextworld объявила об интеграции Intuiflow через API, а сопроводительное описание компании уже рекламировало ИИ и машинное обучение в планировании и исполнении. У интеграции был конкретный механизм; широкое заявление об интеллекте не сопровождалось соответствующей проверкой. (2, 13)
Старая симуляция раскрывает стандарт доказательства
Технический документ поставщика с указанием авторского права за 2020 год описывает демонстрацию 2014 года на числах спроса, предоставленных 57 посетителями конференции. Моделируются две позиции с фиксированными сроками поставки 90 и 21 день. В одном прогоне отмена предварительной видимости всплесков заказов дала два дня дефицита товара и сервис 99,5%. Увеличение страхового процента красной зоны со 120% до 150% восстановило сервис до 100%, одновременно снизив годовую оборачиваемость с 16,27 до 14,78. (12)
Это показывает, что дополнительная защита может устранить дефицит в испытанной последовательности. Оптимальную защиту для следующей последовательности это не устанавливает. Корректировка выполняется после наблюдения неудачи, а денежного сравнения дополнительных запасов с предотвращённым дефицитом документ не даёт. Эксперимент с двумя позициями также не может проверить общие мощности, коррелированные сбои поставщиков или распределение ресурсов между позициями. Сообщаемый процент сервиса — результат исполнения заказов, а не точность прогноза.
Сохраняющаяся проблема методологическая: успешная настройка на историческом спросе представляется доказательством устойчивого планирования. Содержательная экономическая оценка зафиксировала бы политику до оценки последующих решений, сравнила выполнимые альтернативы и включила труд на исправление модели. Сложная историческая последовательность всё равно остаётся лишь одной последовательностью.
Autopilot обновляет настройку, приобретение меняет охват
Нынешний Autopilot описывает ежедневную перекалибровку буферов под целевые уровни сервиса, локальные политики, оповещения об исключениях и симуляции до внесения изменений в рабочую среду. Это ответ на реальную нагрузку сопровождения. В публичной информации не хватает цели обучения, процедуры оценки и подхода к неопределённости поставок. Объявлять корректировки безрисковыми — больше, чем может обосновать симуляция. (7)
В объявлении Algo о приобретении от 13 января 2026 года предлагалось объединить её перспективную аналитику спроса с планированием снабжения Intuiflow, основанным на потреблении. Объединённая компания работает под именем Algo; финансовые условия не раскрыты. Объявление не объясняет, как вычислительно объединят два метода принятия решений. (2)
Противоречие не только архитектурное, но и концептуальное. Коммуникация продукта критикует зависимость от прогнозов, хотя прогнозы уже используются в его симуляциях и теперь входят в обоснование приобретения. Пополнение до будущего потребления неизбежно предполагает ожидания об этом потреблении. Если спрятать их в нормы расхода или буферы, риск прогнозирования не исчезнет, а предположения станет сложнее оценить. (1, 21)
Состав программных компонентов и границы системы
Для восстановления архитектуры продукта открытая документация по внедрению полезнее доступных материалов о найме.
| Слой | Документированный компонент или интерфейс | Операционное следствие |
|---|---|---|
| Размещаемое приложение | Облачный сервис с отдельной средой для каждого клиента | Изоляция клиентов заявлена как явный принцип проектирования |
| Идентификация | Единый вход Azure Active Directory | Корпоративная система идентификации может управлять входом |
| Самостоятельная интеграция | R+ Pusher или написанные клиентом вызовы API | Клиент контролирует выгрузки и расписание передачи |
| Управляемая интеграция | Microsoft Integration Runtime; варианты ADX Lite и Full | Ответственность за сопоставление и передачу зависит от варианта |
| Обмен данными | Импорт позиций и справочных данных, экспорт ожидающих заказов | ERP и Intuiflow должны согласовать, какая система управляет каждым полем |
| Аналитика планировщика | Встроенный Power BI, описанный на странице Aptiv | Отчётность — дополнительный поддерживаемый слой |
База данных приложения, среда исполнения языка программирования и стек обучения Autopilot не указаны. Поэтому до внедрения трудно оценить их требования к размещению, зависимости и ответственность за обновления.
Руководство по интерфейсам необычно конкретно описывает ответственность. При самостоятельном подключении извлечение и преобразование выполняет клиент; ADX Lite размещает Microsoft Integration Runtime в периметре клиента и ограничивает доступ к источникам соответствующими таблицами и полями. Другие варианты делят извлечение, сопоставление и расписание передачи между сторонами. Это постоянные обязательства по интеграции, а не разовое обещание бесшовного подключения любого ERP. (15)
Механизмы безопасности и оставшаяся уязвимость
Algo описывает изоляцию сред клиентов, шифрование, раздельные тестовую и рабочую среды и мониторинг угроз. Playbook документирует корпоративный SSO и настраиваемые административные роли. Эти меры разделяют нагрузки клиентов и управляют доступом к конфигурации планирования. (1, 16, 17)
Распределение полномочий по полям — ещё одна практическая мера. Настройки импорта могут запрещать пользователям изменять в Intuiflow поля, управляемые ERP, исключая конфликтующие источники истины; в приведённой конфигурации прямое редактирование позиций разрешено только основному составу проектной команды. (20, 22)
Опубликованное описание менее конкретно в вопросах восстановления после компрометации администратора, независимо защищённых резервных копий, области полномочий учётных данных коннекторов и утверждения изменений рабочих политик. Отдельная среда ограничивает один вид риска, но не делает скомпрометированную интеграцию безвредной. Эти вопросы важны, поскольку импортированные параметры могут изменить тысячи рекомендаций по пополнению без изменения кода приложения.
Производительность, сопровождение конфигурации и полная стоимость
Обещание Autopilot устранить регулярную проверку параметров соответствует современным ожиданиям производительности. Более строгая проверка — работает ли повседневное планирование при снижении совокупной трудоёмкости: с учётом планировщиков клиента, специалистов по внедрению, поддержки поставщика и сопровождающих политики. Работа по исключениям всё ещё может занимать большую команду, если исключений много или они повторяются без устранения первопричины.
Руководства раскрывают работу, которую необходимо устранить или продолжать выполнять. Пример настроек обработки выбирает 52 недели для среднего суточного потребления и 26 недель для вариабельности, с переключателями обработки отрицательного спроса. Сезонные корректировки используют месячные коэффициенты для отдельных площадок и явные предположения о сроках. Позиции можно сопровождать по одной или массовыми файлами. Это бизнес-решения, закодированные в конфигурации. (4, 19, 20)
Более длинное окно усреднения может подавлять шум, одновременно задерживая распознавание реального изменения. Исключение возвратов упрощает интерпретацию статистики спроса, но убирает экономически значимую информацию. Сезонная надбавка может улучшить наличие, но создать излишек, если событие сдвинется. Издержки состоят в определении правильной интерпретации, обнаружении момента, когда она становится неверной, и безопасном исправлении логики решений.
Это проблема, описанная в Holimization: сама модель требует постоянного улучшения. Ускоренный пересчёт внутри неподходящей политики не заменяет её пересмотр. Значимая мера сопровождения — усилия на одно экономически существенное исправление, включая последствия ошибок.
Aptiv: существенные результаты при значительном участии людей
История Aptiv сообщает примерно о 30% улучшения запасов на пилотном заводе и сокращении срочных доставок. В ней описаны двухлетний пилот, около трёх месяцев ежедневного сопровождения, последующее переобучение и помощь специалистов, а также решение развернуть систему более чем на 100 заводах. Описаны и изменения региональной дистрибуции для дробления минимальных партий поставщиков и сокращения запасов заводов. (14)
Это правдоподобные операционные изменения, заслуживающие изучения. Они не отделяют вклад программы от сопровождения и перепроектирования сети и не измеряют постоянный труд или чистую отдачу. В заключении той же страницы говорится, что расширение от пилота до более чем 100 заводов заняло недели. Этот рекламный срок противоречит подробному изложению и смешивает решение о развёртывании, само развёртывание и достигнутый охват.
Рассказ о внедрении также обнаруживает риск в распределении ответственности. Соблюдение метода контролируется, но экономическая проверка должна сохранять возможность отвергнуть сам метод. Иначе успех подтверждает DDMRP, а разочарование превращается в доказательство того, что персонал не следовал методу. Корректирующий процесс должен проверять, не был ли неверным буфер или правило приоритета, наряду с тем, соблюдал ли его сотрудник.
Экономическая ответственность и проверяемость
Открытая документация Intuiflow позволяет покупателю оспорить реальные расчётные решения ещё до демонстрации. Это существенное преимущество перед непрозрачным обещанием ИИ. Операционные результаты также проверяемы: рекомендованные заказы, изменённые количества, экспортированные обязательства и параметры можно сопоставить с последующими событиями. (3, 5, 6)
Не хватает постоянно поддерживаемого денежного учёта этих решений. Сокращение запасов и уровни сервиса не устанавливают, создаёт ли политика ценность после дефицита товара, срочных доставок, наценок поставщиков, устаревших запасов, внедрения и сопровождения. Текущие материалы о планировании спроса упоминают смещение, абсолютную ошибку и финансовое влияние, но не объясняют, как эта финансовая оценка определяет решения о пополнении. (10)
Публичные отчёты о результатах должны различать выгоды от более аккуратного исполнения, лучшего устройства сети и лучшего выбора решений. Все они могут быть ценными. Только последнее устанавливает качество оптимизатора, а без стоимости эксплуатации процесса ничто из перечисленного не доказывает чистую ценность. Документированные средства контроля продукта позволяют провести такую оценку; опубликованные экономические доказательства остаются неполными.
Оценка для цепочки поставок
Общая оценка 4,8/10 — округлённое среднее арифметическое 25 равновесных частных оценок.
Глубина понимания цепочки поставок: 4,2/10
| Критерий | Оценка |
|---|---|
| Экономическая постановка задачи | 4/10 |
| Конечный результат в виде решения | 6/10 |
| Концептуальная чёткость в цепочке поставок | 5/10 |
| Независимость от устаревших центральных доктрин | 2/10 |
| Устойчивость к показухе с KPI | 4/10 |
Среднее: 4,2/10.
Экономическая постановка задачи. Оборотный капитал и непрерывность операций важны, но опубликованное правило не оценивает в деньгах конкурирующие способы использования запасов и мощностей. (1, 3)
Конечный результат в виде решения. Рекомендации превращаются в обязательства в ERP через явный процесс. Выбор всё ещё существенно зависит от настроенной политики и суждения планировщика. (5, 6)
Концептуальная чёткость в цепочке поставок. Работа с компонентами и развязанными сроками поставки демонстрирует предметное знание. Экономические последствия коррелированной неопределённости проработаны слабо. (4)
Независимость от устаревших центральных доктрин. DDMRP остаётся организующей доктриной. Её категории и защитные коэффициенты ограничивают модель решений до сравнения экономических альтернатив. (3, 11)
Устойчивость к показухе с KPI. Операционные результаты важнее декоративной оценки прогноза. Однако идеальный сервис в симуляции и сжатый рассказ о развёртывании преувеличивают то, что доказывают представленные данные. (12, 14)
Содержательность решений и оптимизации: 4,4/10
| Критерий | Оценка |
|---|---|
| Глубина вероятностного моделирования | 2/10 |
| Самобытная содержательность оптимизации или машинного обучения | 4/10 |
| Работа с реальными ограничениями | 6/10 |
| Автоматизация решений и производительность труда | 5/10 |
| Устойчивость при реальной операционной сложности | 5/10 |
Среднее: 4,4/10.
Глубина вероятностного моделирования. Вариабельность влияет на защиту, но в опубликованном механизме нет калиброванных совместных проекций будущего спроса и поставок. (3, 4)
Самобытная содержательность оптимизации или машинного обучения. Расчёты буферов доступны для проверки. Цель обученной политики и её перспективная экономическая оценка остаются неясными. (3, 7)
Работа с реальными ограничениями. Производственные зависимости и практические ограничения заказов представлены. Экономический выбор между возникающими альтернативами в масштабе системы менее явен. (4, 5, 8)
Автоматизация решений и производительность труда. Автоматическое пополнение и настройка могут убрать рутинный труд. Опубликованные преимущества не измеряют полную трудоёмкость сопровождения и обработки исключений. (4, 7)
Устойчивость при реальной операционной сложности. Промышленное использование даёт полезные свидетельства. Опубликованный процесс исправлений делает упор на настройку и соблюдение метода; он не показывает, как дорогостоящая неудача приводит к проверке другой экономической политики, когда само правило буфера неадекватно. (12, 14)
Целостность продукта и архитектуры: 5,6/10
| Критерий | Оценка |
|---|---|
| Архитектурная согласованность | 6/10 |
| Ясность границ системы | 7/10 |
| Серьёзность подхода к безопасности | 4/10 |
| Программная сдержанность и стоимость владения | 5/10 |
| Совместимость с программным управлением и работой с агентами | 6/10 |
Среднее: 5,6/10.
Архитектурная согласованность. Операционные модули используют единый метод. Более широкая интеграция после приобретения технически описана слабее. (2, 21)
Ясность границ системы. Варианты интеграции и полномочия по полям устанавливают конкретные обязанности ERP, клиента и поставщика. (15, 22)
Серьёзность подхода к безопасности. Идентификация, изоляция и ограничения редактирования закрывают практические риски. Независимость восстановления и привилегированный доступ интеграций требуют более полного раскрытия. (1, 16, 17, 22)
Программная сдержанность и стоимость владения. Видимая архитектура имеет согласованный периметр; её эксплуатационные расходы включают значительное сопровождение политик и интеграций. (15, 19, 20)
Совместимость с программным управлением и работой с агентами. API и массовое обслуживание поддерживают автоматизацию за пределами интерфейса пользователя. Один коннектор не улучшает экономическое правило решений. (13, 15, 20)
Техническая прозрачность: 5,8/10
| Критерий | Оценка |
|---|---|
| Открытая техническая документация | 7/10 |
| Проверяемость без посредничества поставщика | 6/10 |
| Переносимость и видимость привязки к поставщику | 5/10 |
| Прозрачность метода внедрения | 7/10 |
| Плотность доказательств технических заявлений | 4/10 |
Среднее: 5,8/10.
Открытая техническая документация. Playbook раскрывает содержательные механизмы настройки и работы. Более новые заявления об обучении и оптимизации документированы хуже. (3, 4, 18)
Проверяемость без посредничества поставщика. Технически подготовленный покупатель может напрямую изучить политику и нагрузку её сопровождения. Для воспроизведения оценки текущего Autopilot всё ещё требуется содействие поставщика. (7, 18)
Переносимость и видимость привязки к поставщику. Интерфейсы передачи и полномочия по полям документированы. Восстановление накопленных политик планирования останется существенной задачей миграции. (6, 19, 22)
Прозрачность метода внедрения. Руководство и рассказ о развёртывании делают видимыми настройку, сопровождение и операционные изменения. Это позволяет реалистичнее оценивать стоимость владения. (14, 18)
Плотность доказательств технических заявлений. Конкретные расчёты подтверждают более узкие функции. Обещания идеального исполнения и безрисковых изменений не имеют сопоставимой проверки. (7, 8, 12)
Серьёзность поставщика: 4,2/10
| Критерий | Оценка |
|---|---|
| Техническая серьёзность публичной коммуникации | 4/10 |
| Целостность технологической дорожной карты | 6/10 |
| Концептуальная чёткость | 4/10 |
| Экономическая ответственность | 3/10 |
| Защищённость позиции в мире агентного ПО | 4/10 |
Среднее: 4,2/10.
Техническая серьёзность публичной коммуникации. Полезные технические подробности соседствуют с абсолютными гарантиями и преувеличенными формулировками о развёртывании. (7, 8, 14)
Целостность технологической дорожной карты. История показывает последовательную разработку вокруг конкретного рабочего метода и реальных интерфейсов. Широкие заявления об ИИ оценены гораздо менее убедительно. (2, 13)
Концептуальная чёткость. Снижение нестабильности приоритетов полезно. Представление пополнения по потреблению как способа уйти от прогнозирования скрывает заложенные в политике предположения о будущем. (1, 21)
Экономическая ответственность. Отчёты о результатах показывают потенциальную ценность, но не разрешают вопросы атрибуции и полной стоимости. Соблюдение метода должно оставаться подчинённым проверке его экономической состоятельности. (14)
Защищённость позиции в мире агентного ПО. Надёжное исполнение и поддерживаемые промышленные знания могут сохранять ценность. Простая арифметика буферов и помощь в рабочих процессах защищают слабее, чем доказанно лучшие решения при очень низких постоянных трудозатратах. (3, 5, 7)
Источники
Страницы без даты просмотрены 4 ноября 2026 года. Открытый playbook — шаблон внедрения с иллюстрированной клиентской конфигурацией и прежней терминологией; его настройки не представлены как универсальные значения продукта по умолчанию.
[1] Текущий охват продукта и безопасности
Algo, Обзор Intuiflow. Модули, облачная архитектура, изоляция и операционные заявления.
[2] Приобретение и направление развития продукта
Algo, Приобретение Demand Driven Technologies, 13 января 2026 года.
[3] Расчёт и настройка буферов
Demand Driven Technologies, Smart Buffer Profiler.
Demand Driven Technologies, Настройки обработки. Чистые потребности, горизонты, прогнозы, сокращение сроков поставки и автоматические заказы.
Demand Driven Technologies, Workbench.
Demand Driven Technologies, Ожидающие заказы.
[7] Автоматическая корректировка политик
Algo, Intuiflow Autopilot.
[8] Производственные расписания
Algo, Составление расписаний и исполнение.
Algo, Адаптивное планирование продаж и операций.
Intuiflow, Планирование спроса.
Demand Driven Technologies, Что такое DDMRP?, PDF.
[12] Исторический эксперимент с буферами
Erik Bush, Demand Driven Technologies, Симуляция буферов DDMRP, авторское право 2020 года, PDF. Описывает эксперимент на конференции 2014 года и последующие изменения параметров.
[13] Интеграция и заявления об ИИ до 2023 года
Nextworld, Запуск интеграции Intuiflow, 18 октября 2022 года.
[14] Рассказ о развёртывании в Aptiv
Algo, Aptiv принимает решение о глобальном развёртывании после двухлетних пилотов.
Demand Driven Technologies, Проектирование интерфейсов.
[16] Корпоративная идентификация
Demand Driven Technologies, Единый вход Azure Active Directory.
[17] Администрирование доступа
Demand Driven Technologies, Учётные записи и доступ.
[18] Охват руководства по внедрению
Demand Driven Technologies, Client Playbook.
Demand Driven Technologies, Плановый корректирующий коэффициент.
[20] Сопровождение справочных данных
Demand Driven Technologies, Изменение свойств позиций.
[21] Преемственность метода продукта
Demand Driven Technologies, Брошюра Intuiflow, PDF. Планирование материалов, расписания, симуляции на основе прогнозов и позиционирование ИИ и машинного обучения.
[22] Полномочия по полям и обмен данными
Demand Driven Technologies, Импорт и экспорт.