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

Существует множество различных сводов знаний, применимых к комплексным программным системам: PMBoK для управления проектами, BABoK для бизнес-анализа, BPM CBOK для управления бизнес-процессам, EABoK для управления кооперативной архитектурой, а также SWEBoK по программной инженерии. Практически во всех сводах знаний делается акцент именно на внедрение и смежные активности, забывая про то, что имплементация программного продукта завершается его передачей в поддержку. Одним из немногих литературных источников по данной тематике является ITIL [2], описывающий четыре домена знаний, позволяющих осуществлять сопровождение решения после его реализации.

В контексте BABoK и расчета бизнес-кейса, выполняемого при предпроектном обследовании, довольно часто рассчитывается показатель TCO (Total Cost of Ownership, совокупная стоимость владения), демонстрирующий постоянные и переменные затраты, которые понесет компания при внедрении программного обеспечения. Одной из постоянных статей затрат является сумма поддержки и развития информационной системы. Таким образом, знание особенностей выполнения этапа поддержки и развития программной системы позволяет рационально планировать затраты и разумно ограничивать содержание проекта имплементации.

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

• обзор активностей поддержки и развития ПО;

• задание ключевых параметров, характеризующих данные активности;

• детальное рассмотрение выявленных параметров;

• связь этапов поддержки и развития с пред-проектом внедрения ERP-системы.

Основные термины и определения

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

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

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

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

• поддержка программной системы:

  • виды обращений/инцидентов;

  • уровни поддержки;

  • сервисное окно;

  • время реагирования на инциденты и их устранения;

  • показатель качества сервиса;

  • соглашение об уровне сервиса (SLA, Service Level Agreement);

• развитие внедренного решения:

  • корпоративная архитектура и конфигурационное управление;

  • запрос на изменение;

  • архитектурный комитет и комитет по управлению изменениями.

Поддержка внедренного программного решения

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

Переход на следующий этап, фазу поддержки и развития, знаменует важные изменения в жизни всего предприятия и его сотрудников:

• внедренное решение стало неотъемлемой частью выполнения бизнес-процессов предприятия. Без нее реализация процессов затруднительна или невозможна;

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

• дальнейшее развитие системы является совместной ответственностью бизнес-пользователей и ИТ-команды, обеспечивающей необходимые программно-технические изменения.

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

• получения консультации по работе программной системы;

• обработки/исправления данных;

• выполнения стандартной настройки;

• устранения программной ошибки;

• обновления платформы/системы,

где первые четыре типа инцидентов могут создавать ключевые/конечные пользователи в ITSM-системе, в то время как последний тип – только технические специалисты. Каждый инцидент имеет приоритет, определяющий время реакции и сроки его выполнения (табл. 1-2). Обратите внимание, что в таблицах ниже для высокого приоритета указано в том числе нерабочее время, то есть предполагается режим работы 24X7, для остальных приоритетов – только рабочее время.

Табл. 1. Время реагирования на инцидент

Табл. 2. Время устранения инцидента

Получив инцидент, 1-я линия поддержки осуществляет проверку приоритета, а также маршрутизацию на дальнейшего ответственного исполнителя в случае, если специалист сопровождения не может самостоятельно его разрешить. Классификация обращения уточняется по мере прохождения различных уровней поддержки и выявления первопричин проблемы. Таблица ниже описывает параметры обработки различных видов обращений (табл. 3).

Табл. 3. Параметры оказания услуг поддержки

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

Литературный источник

Степанов Д.Ю. Стратегия поддержки и развития внедренных ERP-систем (часть 1) // Корпоративные информационные системы. – 2025. – №2 (30) – c. 7-11. – URL: https://corpinfosys.ru/archive/2025/issue-30/298-2025-30-supportdevelopmentstrategies.