Стремительное развитие информационных систем и технологий породило некогда считавшуюся немыслимой ситуацию: завершение использования программного обеспечения стало обыденностью и возможностью для компании повысить свои конкурентные преимущества. Как бы парадоксально это не звучало, но сейчас дела обстоят именно так. Изначально жизненный цикл программного обеспечения предполагал прохождение ряда состояний, включающих пред-проект внедрения, проект имплементации и пост-проект, на которых доказывалась целесообразность продукта, велась разработка, а далее – поддержка и развитие. До недавнего времени все шло именно так, а сопровождение и развитие решения могли выполняться годами.

Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап.

Финальными этапами жизненного цикла любой программной системы служат активности пост-проект внедрения (рис. 1) [1]. Проект пост-имплементации решает такие задачи как: регулярная поддержка и развитие внедренной информационной системы, а также завершение ее использования [2]. Сейчас утилизация программного обеспечения фактически сводится к разумной концепции его замещения, за исключением случаев банкротства предприятия. Ситуация замены ПО усложняется тем, что любая корпоративная информационная система представляет собой набор приложений, что требует искусного выстраивания интеграционных потоков между существующими и заменяемой программными системами. Замещение информационной системы проходит небыстро, ее можно представить совокупностью таких активностей, как:

- идентификация/выбор программного продукта к замене; - проведение предпроектного обследования для внедрения нового ПО; - исполнение проекта имплементации информационной системы; - отключение «старой» системы по результатам запуска нового программного решения.

Любой программный продукт, перед тем как попасть на фазу поддержки/развития к заказчику, проходит все стадии проекта внедрения: анализ, проектирование, разработка, тестирование, переход и интенсивная поддержка [1]. Внедренный программный продукт позволяет автоматизировать основные, поддерживающие и бизнес-процессы управления, обеспечивая достижение стратегических целей компании. Процессный подход к управлению предприятием предполагает выделение роли владельца бизнес-процесса (Business Process Owner, BPO), контролирующего, чтобы заданный процесс достигал своих ключевых показателей эффективности (Key Performance Indicators, KPI) [3]. С другой стороны, следуя своду знаний по корпоративной архитектуре EABoK, представленной методологией TOGAF, сотруднику ИТ назначается роль владельца системы/архитектора по системе, отвечающего за развитие гибкой, масштабируемой и отвечающей потребностям бизнеса архитектуры продукта [4]. Две указанные роли являются основными стейкхолдерами, заинтересованными в корректной работе бизнес-процессов в программной системе, непрерывном их улучшении и обновлении ПО.

Взаимосвязь процессов и ИТ-систем демонстрирует процессно-функциональная архитектуры предприятия в модели As-Is (рис. 2), получаемая по итогам проекта имплементации программного приложения. Как можно заметить из рисунка, взаимосвязь процесс-система имеет вид «М:М» ...

Карасева Н.С. Стратегия завершения использования программного обеспечения // Корпоративные информационные системы. – 2025. – №3 (31) – c. 13-18. – URL: https://corpinfosys.ru/archive/2025/issue-31/300-2025-31-terminationofusestrategy.