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

Тиск на доставку ERP та бізнес-критичного програмного забезпечення швидше часто створює приховані витрати, які організації в кінцевому підсумку повинні буде вирішити, стверджує Карл Ендрюс, генеральний директор Original Software.

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

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

Де починається борг

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

Настройка залишається на місці, оскільки її заміна здається занадто порушувальною.

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

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

Чому організації недооцінюють проблему

Частина виклику полягає в тому, що технічний борг рідко з’являється як очевидна вартість. На відміну від проваленого проєкту або пропущеного терміну, борг накопичується поступово. Він з’являється як оновлення, які займають більше часу, ніж очікувалося. Зміни, які вимагають більше зусиль, ніж вони повинні. Команди проводять тижні, розслідуючи питання, які раніше були б простими для вирішення.

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

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

Вплив на інновації, продуктивність та стійкість

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

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

Як знайти баланс

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

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

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

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