Готовність до ШІ починається з достовірних даних про продукцію

Виробники активно інвестують у ШІ, ініціативи зі створення цифрового ланцюжка, автоматизацію та модернізацію підприємств, щоб підвищити продуктивність і покращити ухвалення рішень. Значна частина дискусій зосереджена на моделях ШІ, інфраструктурі та інтеграції. Однак багато організацій не зважають на фундаментальну передумову цих зусиль: довіру до базових даних про продукцію та бізнес-правил, які визначають операційні рішення.

Проблема полягає не просто в поєднанні систем, а в тому, щоб визначення продукції, логіка конфігурування та бізнес-правила, що передаються між ними, залишалися точними. Готовність до ШІ починається з довіри до корпоративних даних про продукцію. Цифрова трансформація — це не лише поєднання систем, а й збереження змісту та точності інформації, що передається між ними.

Коли компанії модернізують корпоративні системи та об’єднують системи PLM (управління життєвим циклом продукції), ERP (планування ресурсів підприємства), платформи для налаштування продукції, визначення ціни й формування комерційних пропозицій (CPQ) та сервісні платформи, невідповідності в логіці конфігурування можуть непомітно підривати точність подальших процесів і ефективність рекомендацій на основі ШІ. Без надійної логіки конфігурування ШІ не покращує рішення, а прискорює поширення помилок.

Чому конфігурація продукції — прихований фундамент

Сучасні виробники дедалі більше покладаються на взаємопов’язану екосистему, що охоплює PLM, ERP, CPQ, виробництво й сервісне обслуговування. Конфігурація продукції — це сполучна ланка, що перетворює інженерний задум на вимоги до виробництва, продажів, ціноутворення та сервісного обслуговування.

Кожна система бачить продукт по-своєму: PLM потрібні технічні дані та інформація про конструкцію, виробництву — знати, що можна виготовити, а CPQ — враховувати правила продажу й вимоги ринку. Саме конфігурування поєднує ці різні погляди. Щойно базова логіка змінюється або стає непослідовною, цифровий ланцюжок розривається — хоч би наскільки добре були інтегровані системи.

Застарілі правила створюють непомітні ризики

Моделі конфігурації продукції часто втілюють знання, накопичені протягом десятиліть і поступово нашаровані одне на одне: нормативні вимоги, виробничі обмеження, винятки для окремих ринків і логіку ціноутворення. Люди, які спочатку створювали ці моделі, часто вже залишили компанію, тож організаціям доводиться працювати з правилами, яких ніхто вже не розуміє повністю.

У проєктах із модернізації корпоративних систем, зокрема під час переходу на SAP S/4HANA, зазвичай зосереджуються на застосунках, інфраструктурі та спеціально розробленому коді, відводячи логіці конфігурування другорядну роль. Унаслідок цього виникає непомічений ризик: системи можуть успішно перейти на нову платформу, тоді як поведінка конфігурації непомітно зміниться, і традиційне тестування цього не виявить.

Перехід на S/4HANA добре ілюструє цю проблему: новий механізм конфігурування може інтерпретувати усталені правила інакше, навіть якщо їхній синтаксис не змінився. Різниця в застосуванні значень за замовчуванням, у черговості перевірки обмежень і в способах розв’язання конфліктів між правилами може змінити перелік комбінацій, які модель приймає, хоча жодного рядка самих правил не переписували.

Це не просто збиває з пантелику: хибна логіка конфігурування стає бізнес-проблемою. Є два типи збоїв, і кожен із них дорого обходиться:

• Конфігурація дає компанії змогу продати те, чого вона насправді не може виготовити, що призводить до переробок, невиконаних зобов’язань і погіршення відносин із клієнтами.
• Конфігурація помилково не дає компанії продати те, що вона могла б виготовити, що призводить до втрати доходу й потенційної втрати конкурентної переваги.

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

Перевірка стає стратегічною спроможністю

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

Я бачив, як виробники створювали команди, єдиним завданням яких було переконатися, що після міграції модель і далі формує ті самі допустимі конфігурації та відхиляє ті самі недопустимі — просто тому, що іншого способу перевірити це вони не мали. Це кропітка, дорога й тривала робота, яка навіть тоді дає змогу перевірити лише частину проблеми.

Варто чітко уявляти масштаб цієї проблеми. Модель із 30 змінними та п’ятьма варіантами для кожної допускає приблизно 10²¹ комбінацій — незрівнянно більше за орієнтовну кількість піщинок на Землі; до того ж реальні промислові моделі значно масштабніші. Скільки б людей не клацали в інтерфейсі, охопити весь цей простір неможливо — це виключає сама математика.

Саме тому важливі формальні методи. Замість того щоб вибірково перевіряти комбінації, модель конфігурації можна перетворити на канонічну логічну форму — компактне математичне представлення всіх допустимих комбінацій, передбачених її правилами. Дві моделі, перетворені таким чином, можна безпосередньо порівняти. Або вони описують той самий набір допустимих продуктів, або порівняння точно показує, у чому вони розходяться, на конкретних прикладах комбінацій, які одна модель приймає, а інша відхиляє. Те саме представлення дає змогу замінити пошук під час роботи системи на вибірку з довідника, завдяки чому конфігуратор показує лише допустимі варіанти й ніколи не заводить користувача в глухий кут. Як виявляється, перевірка й забезпечення коректності під час роботи системи — це та сама можливість, розглянута з двох боків.

Організаціям дедалі частіше потрібне таке формальне порівняння, перш ніж застосовувати ШІ чи автоматизацію до правил конфігурації продуктів. Мета полягає не лише в зниженні ризиків під час переходу, а й у збереженні безперервності операційної діяльності в інженерії, виробництві, продажах і сервісному обслуговуванні, а також у можливості тестувати, налагоджувати й перевіряти моделі конфігурації до випуску, а не після нього.

ШІ має працювати на основі детермінованого рушія, а не замість нього

Для цього не потрібно, щоб ШІ замінював рушій конфігурації. Надійніший підхід — протилежний: ШІ стає посередником між користувачем і точним рушієм конфігурації, забезпечуючи природніший супровід продажів або рекомендаційний сервіс, тоді як базові правила залишаються детермінованими. Мовна модель інтерпретує запит клієнта, а рушій визначає, що насправді можна виготовити. Такий розподіл обов’язків не дозволяє передавати частину процесу, яка має бути гарантовано коректною, системі, що за своєю природою працює ймовірнісно.

Достовірні дані — запорука успішних програм на основі ШІ

ШІ може надавати рекомендації лише настільки надійно, наскільки надійні отримані ним знання про продукти. Неперевірені дані конфігурації змушують ШІ поширювати помилки в масштабах підприємства, підриваючи якість консультацій із продажу, виробничих рішень і зобов’язань перед клієнтами.

Виробникам слід розглядати перевірку даних як обов’язкову передумову впровадження ШІ — так само, як тестування програмного забезпечення стало передумовою розроблення застосунків. У міру продовження цифрової трансформації конкурентна перевага дедалі більше залежатиме не від того, хто першим запровадить ШІ, а від того, хто застосує його на основі достовірних даних про продукти.