Стремительное развитие информационных систем и технологий породило некогда считавшуюся немыслимой ситуацию: завершение использования программного обеспечения стало обыденностью и возможностью для компании повысить свои конкурентные преимущества. Как бы парадоксально это не звучало, но сейчас дела обстоят именно так. Изначально жизненный цикл программного обеспечения предполагал прохождение ряда состояний, включающих пред-проект внедрения, проект имплементации и пост-проект, на которых доказывалась целесообразность продукта, велась разработка, а далее – поддержка и развитие. До недавнего времени все шло именно так, а сопровождение и развитие решения могли выполняться годами.
Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап.
Цель данной статьи состоит в рассмотрении заключительного этапа жизненного цикла программного обеспечения, подходов и методов применимых к нему для обеспечения разумного завершения использования софтверного продукта и его замены на прочие решения, что обеспечит непрерывность бизнес-процессов организации. Достижение цели потребует проработки следующих вопросов:
обзор фазы завершения использования программного обеспечения;
анализ активностей по замене программного решения на новый продукт;
рассмотрение задач предпроектного обследования, внедрения информационной системы, а также отказа от исторической системы.
Фаза завершения использования программного продукта
Финальными этапами жизненного цикла любой программной системы служат активности пост-проект внедрения (рис. 1) [1]. Проект пост-имплементации решает такие задачи как: регулярная поддержка и развитие внедренной информационной системы, а также завершение ее использования [2]. Сейчас утилизация программного обеспечения фактически сводится к разумной концепции его замещения, за исключением случаев банкротства предприятия. Ситуация замены ПО усложняется тем, что любая корпоративная информационная система представляет собой набор приложений, что требует искусного выстраивания интеграционных потоков между существующими и заменяемой программными системами. Замещение информационной системы проходит небыстро, ее можно представить совокупностью таких активностей, как:
идентификация/выбор программного продукта к замене;
проведение предпроектного обследования для внедрения нового ПО;
исполнение проекта имплементации информационной системы;
отключение «старой» системы по результатам запуска нового программного решения.
2. Идентификация программного продукта к замене
Любой программный продукт, перед тем как попасть на фазу поддержки/развития к заказчику, проходит все стадии проекта внедрения: анализ, проектирование, разработка, тестирование, переход и интенсивная поддержка [1]. Внедренный программный продукт позволяет автоматизировать основные, поддерживающие и бизнес-процессы управления, обеспечивая достижение стратегических целей компании. Процессный подход к управлению предприятием предполагает выделение роли владельца бизнес-процесса (Business Process Owner, BPO), контролирующего, чтобы заданный процесс достигал своих ключевых показателей эффективности (Key Performance Indicators, KPI) [3]. С другой стороны, следуя своду знаний по корпоративной архитектуре EABoK, представленной методологией TOGAF, сотруднику ИТ назначается роль владельца системы/архитектора по системе, отвечающего за развитие гибкой, масштабируемой и отвечающей потребностям бизнеса архитектуры продукта [4]. Две указанные роли являются основными стейкхолдерами, заинтересованными в корректной работе бизнес-процессов в программной системе, непрерывном их улучшении и обновлении ПО.
Взаимосвязь процессов и ИТ-систем демонстрирует процессно-функциональная архитектуры предприятия в модели As-Is (рис. 2), получаемая по итогам проекта имплементации программного приложения. Как можно заметить из рисунка, взаимосвязь процесс-система имеет вид «М:М», то есть один процесс может быть реализован в множестве систем и, наоборот, одно приложение может автоматизировать набор бизнес-операций. Владелец системы ведет ежегодный план-факт анализ параметров каждого программного продукта:
совокупная стоимость владения (Total Cost of Ownership, TCO), включающая все постоянные и переменные затраты, которые несет компания при работе с ПО (стоимость внедрения, лицензий, поддержки и развития);
срок эксплуатации, позволяющий понять, насколько устарел программный продукт и возможно ли его обновить до новой версии без осуществления проекта перевнедрения;
ожидаемая дата прекращения поддержки программного продукта вендором, после которой развитие ПО придется выполнять самостоятельно в виду отсутствия официальных обновлений от поставщика;
число обращений в службу поддержки в разрезе ПО;
количество критических инцидентов, зарегистрированных для ПО;
объем запросов на изменение (ЗНИ) программного продукта.
TCO является ключевой характеристикой ПО, все прочие параметры расшифровывают и объясняют ее значение. Так, чем выше срок эксплуатации программы, тем больше ЗНИ формируются для ее развития, что порождает увеличение числа обращений и критических инцидентов [2]. Причем эта динамика усиливается, как только вендор прекращает поддержку продукта. В связи с чем, лучшая практика ведения корпоративной архитектуры состоит в заблаговременной замене ПО в случае известной даты завершения его поддержки производителем. Рис. 3 демонстрирует пример увеличения TCO с течением времени.
По результатам анализа динамики характеристик ПО, а также принимая во внимание обратную связь и пожелания BPO, может рекомендоваться инициатива по замене программной системы, основными триггерами для которой являются:
постоянно увеличивающаяся TCO программной системы;
завершение поддержки программного продукта вендором;
высокая степень кастомизации и/или технологическое устаревание продукта, не позволяющие оперативно обеспечивать новые бизнес-потребности предприятия и следовать мировым трендам развития.
Принятию окончательного решения о замещении программного продукта предшествует предпроектное обследование, подтверждающее экономическую целесообразность подобной инициативы ...
Литературный источник
Карасева Н.С. Стратегия завершения использования программного обеспечения // Корпоративные информационные системы. – 2025. – №3 (31) – c. 13-18. – URL: https://corpinfosys.ru/archive/2025/issue-31/300-2025-31-terminationofusestrategy.
