Почему погоня за скоростью создает проблемы программного обеспечения завтрашнего дня

Давление на быструю доставку ERP и бизнес-критического программного обеспечения часто создает скрытые затраты, которые организации в конечном итоге должны устранить, утверждает Карл Эндрюс, генеральный директор Original Software.

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

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

Где начинается долг

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

Настройка оставляется на месте, потому что ее замена кажется слишком разрушительной.

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

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

Почему организации недооценивают проблему

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

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

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

Влияние на инновации, производительность и устойчивость

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

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

Найти баланс

Ответ не в том, чтобы замедлить. Мало организаций могут позволить себе это. Цель – построить процессы доставки, которые поддерживают скорость без компрометации долгосрочного качества. Это начинается с признания того, что такие деятельности, как тестирование, документация и управление, не являются препятствиями для доставки. Они являются тем, что делает устойчивую доставку возможной. Для систем ERP, в частности, прочное регрессионное тестирование является необходимым.

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

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

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