Навігація у золотій лихоманці штучного інтелекту: розкриття прихованих витрат технічного боргу в корпоративних підприємствах

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

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

Що таке технічний борг?

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

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

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

Як організації набувають технічний борг?

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

Як щодо штучного інтелекту, трохи більше ніж 72% лідерів хочуть采用 штучний інтелект для покращення продуктивності працівників, проте головною проблемою щодо впровадження штучного інтелекту є якість та контроль даних. Здається, що це протирічить організації, яка використовує продукт, який підвищує продуктивність, одночасно відволікаючи час від важливої роботи щодо безперервного вирішення будь-яких проблем з якістю, спричинених технічним боргом, які можуть загрожувати продуктивності. Однак обіцянка майбутніх прибутків за підвищення продуктивності переважає ці перешкоди в найближчому майбутньому, які згодом повернуться, щоб переслідувати програмне забезпечення в довгостроковій перспективі.

Дрейф моделі: новий тип технічного боргу

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

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

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

Вплив технічного боргу на дно лінії

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

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

Як вирішити технічний борг

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

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

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

Залиште свій технічний борг позаду в епоху штучного інтелекту

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