Стратегия поддержки и развития внедренных ERP-систем (часть 1)

Подробности

Опубликовано: 31.05.2025 10:25

Автор: Степанов Дмитрий Юрьевич

Просмотров: 146

Аннотация: в статье рассматриваются активности, выполняемые для поддержки и развития внедренной информационной системы. Анализируются такие параметры сопровождения программной системы, как: виды обращений и инцидентов, уровни поддержки, сервисное окно, время реагирования на инциденты и их устранения, показатель качества сервиса, задающие соглашение об уровне сервиса или SLA. Формулируется вывод, чем строже предъявляются требования к SLA и больше инцидентов в разрезе ИТ-систем, тем более затратными будут услуги поддержки.
Ключевые слова: поддержка программного обеспечения это, техническая поддержка программного обеспечения, поддержка кис, организация поддержки программного обеспечения, технологии поддержки программного обеспечения, 1с erp поддержка, процессы поддержки программного обеспечения, виды инцидентов, показатели качества сервиса, SLA, соглашение об уровне сервиса, соглашение об уровне сервиса SLA, время реакции поддержки, инцидент программное обеспечение, ITSM системы.
Скачать: PDF (статья), PDF (выпуск №30).

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

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

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

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

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

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

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

Рис. 1. Типовые этапы жизненного цикла программной системы

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

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

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

• поддержка программной системы:
  • виды обращений/инцидентов;
  • уровни поддержки;
  • сервисное окно;
  • время реагирования на инциденты и их устранения;
  • показатель качества сервиса;
  • соглашение об уровне сервиса (SLA, Service Level Agreement);
• развитие внедренного решения:
  • корпоративная архитектура и конфигурационное управление;
  • запрос на изменение;
  • архитектурный комитет и комитет по управлению изменениями.

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

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

Рис. 2. Пример организации уровней поддержки программного решения

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

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

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

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

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

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

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

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

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

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

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

QoS = max (50%; 100% – P1 – P2 – P3 ),      (1)

где P1 – штраф за просроченные обращения высокого приоритета, P2 – штраф за несвоевременное разрешение инцидента среднего приоритета и P3 – штраф за опоздание в решении обращения низкого приоритета, вычисляемые как:

P1 = (Число просроченных обращений высокого приоритета / Общее число обращений высокого приоритета) × 80%,
P2 = (Число просроченных обращений среднего приоритета / Общее число обращений среднего приоритета) × 15%,
P3 = (Число просроченных обращений низкого приоритета / Общее число обращений низкого приоритета) × 5%.

Тогда стоимость услуг поддержки, оказываемых внешним подрядчиком, может корректироваться в зависимости от показателя качества сервиса (табл. 4).

Табл. 4. Качество сервиса и штрафы

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

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

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

Литература

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. Agutter C. ITIL. 4 Essentials. ITIL. IT Governance Publishing, 2024. – 226 p.
3. Washizaki H. Guide to the software engineering body of knowledge. Waseda University, IEEE Computer Society, 2024. – 413 p.
4. Сорокин М.М. TOGAF для построения корпоративной архитектуры в ИТ-проектах по разработке и настройке программного обеспечения // Корпоративные информационные системы. – 2024. – №2 (26) – с. 1-9. – URL: https://corpinfosys.ru/archive/2024/issue-26/275-2024-26-togaf.
5. Кон М. Agile: оценка и планирование проектов. М.: Альпина Паблишер, 2019. 418 с.
6. Сазерленд Д. Scrum. Революционный метод управления проектами. М.: Манн, Иванов и Фербер, 2019. 272 с.

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

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

Об авторе

Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный адрес автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

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

1. Современные формы безналичных расчетов в РФ и техника их проведения;
2. Стратегия поддержки и развития внедренных ERP-систем (часть 1).