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

Подробности
Опубликовано: 02.10.2025 01:28
Автор: Степанов Дмитрий Юрьевич
Просмотров: 858
Корпоративные информационные системы и учетная политика организации при применении автоматизированной формы ведения учета

Аннотация: в статье рассматриваются задачи, выполняемые для поддержки и развития внедренной информационной системы. Анализируются такие активности развития программной системы, как: организация отдела корпоративной архитектуры, работа архитектурного комитета, функционирование комитета по изменениям продукта и бизнес-процесс обработки запросов на изменение или ЗНИ. Выдвигается утверждение, чем чаще реализуются ЗНИ, тем больше объем инцидентов будет порождаться в ИТ-системе, увеличивая тем самым затраты на сопровождение ПО.
Ключевые слова: развитие информационной системы, развитие программного обеспечения, архитектура корпоративных систем, архитектурный комитет, архком, конфигурационное управление это, корпоративный архитектор, функциональный архитектор 1с, комитет по изменениям, change advisory board, CAB change advisory board, ЗНИ, инцидент, руководство по управлению инцидентами, управление инцидентами, система управления инцидентами, время реакции, услуга ITSM, TCO стоимость владения.
Скачать: PDF (статья), PDF (выпуск №32).

3. Развитие имплементированного ПО

Ссылка на 1-ю часть статьи. Внедренный программный продукт подлежит дальнейшему развитию, причин для которого достаточно: изменение законодательства, технологические тренды и новинки, цифровизация не автоматизированных областей и др. Часто подобные активности над ИТ-системами связывают с запросами на изменение (ЗНИ), относящимися к процессу управления изменениями. Это действительно так, однако работа с ЗНИ требует выстраивания регулярных бизнес-процессов, вовлекающих как бизнес-пользователей, так и технических специалистов, обеспечивающих надзор над корпоративной архитектурой предприятия и соблюдение целостности существующих ИТ-сервисов. Для чего согласно EABoK [4] организуются следующие организационные сущности:

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

а также поддерживающие их работу процессы. Рассмотрим их более подробно в следующих подразделах. 

3.1. Отдел корпоративной архитектуры и архитектурный комитет

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

  • архитектор по бизнес-процессам;
  • архитектор по данным;
  • архитектор по инфраструктуре;
  • архитекторы по приложениям (например, архитектор по 1С: ERP, 1C: ДО, SAP ERP и др.). В части литературных источников [5-6] данную роль называют владелец продукта (Product Owner),

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

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

Работа архитектора тесно связана с взаимодействием с бизнес-пользователями. Для обеспечения единой точки контакта с которыми необходимо выделение отдельной роли, владельца процесса (Business Process Owner, BPO), кто озвучивает и представляет потребности всех пользователей в заданной предметной области.

Обеспечение целостности ИТ-архитектуры предприятия требует групповую работу всей команды по архитектуре, для чего организуется коллективный орган под названием архитектурный комитет. Цель архитектурного комитета состоит в комплексном взгляде на вносимые в ИТ-архитектуру изменения. Порядок коммуникации в этом случае выглядит так:

  • BPO, обсуждая потребности пользователей, генерирует запрос на изменение системы или выступает с инициативой по старту ИТ-проекта (рис. 3);
  • ЗНИ отправляется ответственному за его реализацию техническому специалисту, который описывает верхнеуровневое решение задачи, плановые трудозатраты, срок и, возможно, стоимость. Специалист может быть как штатным сотрудником ИТ-службы, так и находится на аутсорсинге;
  • ЗНИ или инициатива по ИТ-проекту выносится на архитектурный комитет. Чаще всего задаются правила, определяющие, действительно ли их необходимо обсудить на архкомитете или нет;
  • ЗНИ/ИТ-инициатива рассматривается архитекторами комитета: архитекторы по процессам и данным оценивают степень влияния и сложности изменения, относящиеся корпоративным бизнес-процессам и процессу ведения/хранения данных, архитекторы по ИТ-системам и инфраструктуре озвучивают опасения по техническим вопросам по компетенции. Как результат, дается коллективное решение архкомитета: обоснованный отказ с возможностью внесения изменений в инициативу для повторного вынесения на комитет или согласие на реализацию инициативы.

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

Пример структуры запроса на изменение

Рис. 3. Пример структуры запроса на изменение

3.2. Комитет по изменению продукта

Решение по старту работ над запросом на изменение принимается комитетом по изменению продукта (Change Advisory Board, CAB), в то время как инициатива по ИТ-проекту в дальнейшем прорабатывается в ходе бизнес-кейса [1]. Стоит отметить, что ЗНИ может формироваться как со стороны BPO, так и ИТ-команды, в частности для запросов на обновление программной системы. Выделяют две стратегии обновления информационной системы, следуя правилам конфигурационного управления:

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

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

  • подтверждение возможности и начала реализации ЗНИ. Например, ЗНИ может быть не согласован в виду ожидаемой программы цифровой трансформации, наличием других ЗНИ, противоречащих текущему и др.;
  • приостановка и отмена активностей по ЗНИ. Приостановка работ может быть обусловлена высокой сезонной загруженностью, закрытием периода/квартала/года по бухгалтерскому/управленческому учетам и прочими бизнес-мероприятиями, для которых критически важна 100% функционирование и доступность информационных систем;
  • согласование даты переноса реализованного ЗНИ в продуктивную среду. Следуя ИТ-регламентам, могут быть установлены определенные сервисные окна, в рамках которых разрешен перенос некритичных программных разработок в продуктивную среду, например, каждый вечер четверга. Критичные модификации обычно переносятся по мере потребности.

Запрос на изменение выносится на комитет по изменениям продукта, BPO отстаивает необходимость ЗНИ, архитектор по приложению и ответственный за реализацию запроса технический специалист дают комментарии при возникновении техвопросов. Получив подтверждение от CAB, ЗНИ передается в работу. Разработка запроса на изменение осуществляется согласно методологии внедрения заказчика. Последующее обращение в комитет ведется по мере технической готовности решения с целью подтверждения даты его переноса в продуктивную среду.

4. Связь предпроектного обследования и пост-проекта внедрения ПО

Активности пост-проекта внедрения программного обеспечения обусловлены SLA и объемом ЗНИ: чем строже предъявляются требования к уровню сервиса и больше число требуемых модификаций имплементированного решения, тем трудозатратнее становится его поддержка и развитие. В начальном разделе текущей статьи были детально описаны ключевые параметры, задающие SLA для поддержки ПО, одним из которых служит число инцидентов в день/месяц. Отметим взаимосвязь активностей поддержки и развития программного решения, используя его:

  • статистика показывает, что объем инцидентов максимален в интервал от момента продуктивного запуска решения до завершения стабилизации работы системы, то есть первые 1-4 месяца после старта. Далее количество инцидентов становится относительно постоянным с возможными колебаниями при закрытии периода/квартала/года для целей бухгалтерского и управленческого учетов;
  • регулярные усовершенствования программного решения, проводимые в рамках развития и реализации ЗНИ, являются одним из триггеров увеличения объема инцидентов по отношению к их устоявшемуся количеству (рис. 4). Более того, чем больше запросов на изменение вносится в ИТ-систему, тем более кастомизированнее/отличнее от типового функционала она становится. Все это приводит к росту стоимости поддержки ПО: во-первых, повышаются трудозатраты на обработку увеличивающегося объема инцидентов, во-вторых, для разрешения инцидентов нетипового функционала требуется привлекать более квалифицированных, то есть дорогих, специалистов.

Тогда совокупная стоимость владения программной системы, вычисляемая на этапе бизнес-кейса в рамках предпроекта внедрения по условной формуле:

TCO = F(стоимость внедрения, стоимость поддержки в год, стоимость обработки ЗНИ в год),

имеет более комплексный расчет:

TCO = F1(стоимость внедрения, F2(стоимость поддержки в год, стоимость обработки ЗНИ в год), стоимость обработки ЗНИ в год).

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

Статистика роста числа инцидентов

Рис. 4. Статистика роста числа инцидентов

Заключение

Стратегия поддержки и развития внедренного программного решения определяется такими характеристиками как: SLA для сопровождения, а также работа комитетов по архитектуре/изменениям продукта и объем ЗНИ – для развития системы.  Чрезмерно строгие требования, предъявляемые к соглашению об уровне сервиса, и большое число запросов на изменение, включая вовлеченные в их обработку стороны, увеличивают TCO программной системы. Уровень зрелости не всех компаний подразумевает организацию архитектурной команды, контролирующей развитие ИТ-архитектуры. Активности развития приложений и их поддержки тесно переплетены между собой: большое количество вносимых модификаций в программную систему увеличивает число инцидентов, обрабатываемых в ходе ее сопровождения. Последнее может привести к завершению использования текущей системы и параллельным активностям по ее перевнедрению.

Литература

  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-систем (часть 2) // Корпоративные информационные системы. – 2025. – №4 (32) – c. 7-11. – URL: https://corpinfosys.ru/archive/2025/issue-32/299-2025-32-supportdevelopmentstrategies.

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

Об авторе

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

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

  1. Новации ФСБУ 9/2025 «Доходы»;
  2. Стратегия поддержки и развития внедренных ERP-систем (часть 2).