Стратегия завершения использования программного обеспечения

Подробности
Опубликовано: 11.09.2025 10:24
Автор: Карасева Наталья Сергеевна
Просмотров: 19
Корпоративные информационные системы и учетная политика организации при применении автоматизированной формы ведения учета

Аннотация: в статье рассматривается вопрос утилизации программного обеспечения, сводящийся к замене софтверного решения. Стратегия замещения ПО прорабатывается в контексте идентификации программного продукта к замене, проведения предпроектного обследования для внедрения нового решения, выполнения проекта имплементации, а также отключения исторической системы по итогам запуска новой. Подчеркивается роль владельца процесса и архитектора ИТ-системы для выбора устаревшего программного продукта к замене. Вводятся параметры, характеризующие ПО. Формулируется вывод о том, что историческая система продолжает функционировать в ограниченном режиме, несмотря на успешное внедрение нового программного продукта, что обусловлено законодательством РФ.
Ключевые слова: утилизация программного обеспечения, замена программного обеспечения на российское, прекращение поддержки ПО, ключевые показатели эффективности, система ключевых показателей эффективности, совокупная стоимость владения информационной системой, совокупная стоимость владения TCO, срок эксплуатации программного обеспечения, владелец системы это, владелец информационной системы, владелец системы определение, владелец автоматизированной системы, владелец бизнес процесса это, владелец процесса это, владелец процесса отвечает, ответственность владельца процесса, функции владельца процесса.
Скачать: PDF (статья), PDF (выпуск №31).

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

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

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

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

1. Фаза завершения использования программного продукта

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

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

Спиралевидный жизненный цикл информационных систем

Рис. 1. Спиралевидный жизненный цикл информационных систем

2. Идентификация программного продукта к замене

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

Процессно-функциональная архитектура

Рис. 2. Процессно-функциональная архитектура

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

  • совокупная стоимость владения (Total Cost of Ownership, TCO), включающая все постоянные и переменные затраты, которые несет компания при работе с ПО (стоимость внедрения, лицензий, поддержки и развития);
  • срок эксплуатации, позволяющий понять, насколько устарел программный продукт и возможно ли его обновить до новой версии без осуществления проекта перевнедрения;
  • ожидаемая дата прекращения поддержки программного продукта вендором, после которой развитие ПО придется выполнять самостоятельно в виду отсутствия официальных обновлений от поставщика;
  • число обращений в службу поддержки в разрезе ПО;
  • количество критических инцидентов, зарегистрированных для ПО;
  • объем запросов на изменение (ЗНИ) программного продукта.

TCO является ключевой характеристикой ПО, все прочие параметры расшифровывают и объясняют ее значение. Так, чем выше срок эксплуатации программы, тем больше ЗНИ формируются для ее развития, что порождает увеличение числа обращений и критических инцидентов [2]. Причем эта динамика усиливается, как только вендор прекращает поддержку продукта. В связи с чем, лучшая практика ведения корпоративной архитектуры состоит в заблаговременной замене ПО в случае известной даты завершения его поддержки производителем. Рис. 3 демонстрирует пример увеличения TCO с течением времени.

Пример динамики показателей программной системы

Рис. 3. Пример динамики показателей программной системы

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

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

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

3. Предпроектное обследование и бизнес-кейс

Проект пред-внедрения может состоять из нескольких фаз: бизнес-кейс, тендер и заключение договора на внедрение программного продукта, наличие которых зависит от того, будет ли имплементироваться ПО заказчиком или же с привлечением внешнего подрядчика [1]. Этап бизнес-кейса представляется мини проектом внедрения и решает такие технические задачи, как:

  • сбор верхнеуровневых функциональных требований, предъявляемых к будущей информационной системе;
  • идентификация нефункциональных требований к ПО и проекту в целом;
  • определение наиболее подходящего нового программного решения;
  • выявление функциональных разрывов между типовым новым ПО и собранными требованиями к нему. В литературе данную активность часто называют Fit/Gap-анализом;
  • построение To-Be архитектуры будущего решения (функциональная, процессная, интеграционная, миграционная, концептуальная и прочие виды архитектур);

что позволяет проработать организацию проекта имплементации:

  • построить ресурсный план проекта [5];
  • принять решение, как будет реализовываться проект: самостоятельно или подрядчиком;
  • выбрать модель внедрения ПО (каскадная, итерационная или спиралевидная);
  • задать стратегию запуска ПО на организационных сущностях/предприятиях (метод большого взрыва, франчайзинговая стратегия, способ точного броска) [6];
  • определить необходимость понижения риска не запуска ПО в продуктивный режим эксплуатации путем введения фазы опытно-промышленной эксплуатации (ОПЭ), известной как режим двойного ввода данных;
  • сформировать план-график проекта внедрения [5];

а также рассчитать экономические показатели:

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

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

4. Внедрение программного обеспечения и отказ от «старой» системы

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

  • сразу при переходе в режим ПЭ при отсутствии фазы ОПЭ;
  • после перехода от этапа ОПЭ к фазе ПЭ.

Под отключением программной системы подразумевается не столько ее физическое выключение, сколько перевод в режим работы «только чтение». Так как в историческом ПО остаются электронные копии первичных документов, данные по движению товарно-материальных ценностей, сведения по оплатам и многое другое, используемые при сдаче отчетности по предыдущим периодам в регулирующие органы РФ, к «старой» системе должен оставаться доступ избранному числу пользователей. Согласно законодательству РФ надзорные органы могут запросить информацию пятилетней давности, хранящуюся в информационной системе.

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

Заключение

Несмотря на то, что жизненный цикл ПО завершается этапом прекращения использования программного продукта, данная активность не ведется одномоментно. Отказу от информационной системы предшествует инициатива по замене текущего решения на новое. Предварительно идентифицируется ПО к замещению, дальше осуществляется анализ и оценка целесообразности замены приложения, лишь после окончания имплементации нового решения ведется отключение «старого» продукта. При этом под отключением ПО понимается ограничение режима его работы (перевод в состояние «только чтение») и лимитирование пользователей, имеющих доступ к нему, что продиктовано законодательством РФ. Таким образом, отказ от использования ПО представляется обдуманной стратегией, требующей слаженной работы множества стейкхолдеров и соблюдения правил из всевозможных сводов знаний (BPM CBoK, EABoK, BABoK, PMBoK и др.), нацеленной на достижение корпоративных целей и обеспечения непрерывности существующих бизнес-процессов предприятия.

Литература

  1. Stepanov D.Yu. The lifecycle of corporate information systems // Proceedings of 6th International Conference on Control Systems, Mathematical Modeling, Automation and Energy Efficiency. – 2024. – p.593-597. – URL: https://stepanovd.com/science/article/197-2024-4-thelifecyclecis.
  2. Степанов Д.Ю. Стратегия поддержки и развития внедренных ERP-систем (часть 2) // Корпоративные информационные системы. – 2025. – №4 (32) – c. 7-11. – URL: https://corpinfosys.ru/archive/2025/issue-32/299-2025-32-supportdevelopmentstrategies.
  3. Свод знаний по управлению бизнес-процессами: BPM CBoK 4.0 / Бенедикт Т., Кирхмер М., Шарсиг М., Франц П., Саксена Р., Моррис Д., Хилти Д. – М.: Альпина Паблишер, 2024. – 504 с.
  4. Сорокин М.М. TOGAF для построения корпоративной архитектуры в ИТ-проектах по разработке и настройке программного обеспечения // Корпоративные информационные системы. – 2024. – №2 (26) – С. 1-9. – URL: https://corpinfosys.ru/archive/2024/issue-26/275-2024-26-togaf.
  5. Першин Д.С. Формирование ресурсного плана в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2022. – №3 (19) – c. 38-44. – URL: https://corpinfosys.ru/archive/issue-19/203-2022-19-erpresourceplan.
  6. Катасонова Н.С. Метод большого взрыва и франчайзинговая стратегия для внедрения и импортозамещения корпоративных информационных систем // Корпоративные информационные системы. – 2023. – №3 (23) – с. 1-11. – URL: https://corpinfosys.ru/archive/2023/issue-23/227-2023-23-implementationstrategy. 

Выходные данные статьи

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

Стратегия завершения использования программного обеспечения

Об авторе

 Катасонова Наталья Сергеевна Карасева Наталья Сергеевна – функциональный консультант SAP по финансовому и налоговому учетам. Принимала участие в российских и международных проектах внедрения ERP-систем при тиражировании и имплементации программного решения «с нуля». Выпускник кафедры оптических и биотехнических систем и технологий физико-технологического института РТУ МИРЭА. Контактный электронный адрес: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №31

  1. Об использовании и учете векселей на предприятии;
  2. Стратегия завершения использования программного обеспечения;
  3. Универсальный передаточный документ в 2026 году.