Развитие имплементированного ПО
Внедренный программный продукт подлежит дальнейшему развитию, причин для которого достаточно: изменение законодательства, технологические тренды и новинки, цифровизация не автоматизированных областей и др. Часто подобные активности над ИТ-системами связывают с запросами на изменение (ЗНИ), относящимися к процессу управления изменениями. Это действительно так, однако работа с ЗНИ требует выстраивания регулярных бизнес-процессов, вовлекающих как бизнес-пользователей, так и технических специалистов, обеспечивающих надзор над корпоративной архитектурой предприятия и соблюдение целостности существующих ИТ-сервисов. Для чего согласно EABoK [4] организуются следующие организационные сущности:
отдел корпоративной архитектуры;
архитектурный комитет;
комитет по управлению изменениями,
а также поддерживающие их работу процессы. Рассмотрим их более подробно в следующих подразделах.
Отдел корпоративной архитектуры и архитектурный комитет
С другой стороны мир не стоит на месте: меняются технологии, взгляды людей, бизнес-процессы и, пожалуй, самое важное, законодательные требования. Внедренный программный продукт должен уметь оперативно реагировать на все вышесказанное. Поэтому второй ключевой активностью данного этапа будет является развитие внедренной системы, то есть ее постоянная доработка и донастройка. Конечно, можно предположить, что развитие системы не всегда необходимо, однако как минимум появление новых организационных сущностей в компании (юридические лица, подразделения, заводы, склады и др.), не требующие программной доработки, обязуют выполнение дополнительного конфигурирования коробочного решения.
Комитет по изменению продукта
Отдел корпоративной архитектуры формируется для управления ИТ-архитектурой предприятия, включающей следование архитектурным принципам при реализации программных систем, создания предложений по развитию ИТ-систем с учетом потребностей бизнеса, обеспечение контроля вносимых изменений в существующий ИТ-ландшафт с целью не нарушения его работы и генерализации решения, регламентирование ИТ-активностей по закупке ПО, проектированию, разработке и др. Данное направление подразумевает выделение таких ролей, как:
архитектор по бизнес-процессам;
архитектор по данным;
архитектор по инфраструктуре;
архитекторы по приложениям (например, архитектор по 1С: ERP, 1C: ДО, SAP ERP и др.). В части литературных источников [5-6] данную роль называют владелец продукта (Product Owner),
а также корпоративный архитектор, систематизирующий их работу. Выделение отдела по ИТ-архитектуре требуется не всем организациям, а лишь тем, кто достиг необходимого уровня зрелости, обычно зависящего от числа ИТ-систем и наличия масштабных и регулярных ИТ-инициатив. Примерами активностей, выполняемых архитекторами, служат:
создание регламентов разработки, соглашений о наименовании объектов разработки, переноса программ в продуктивную среду, а также контроль их соблюдения. Данные регламенты позволяют задать единые правила ведения разработок, генерации новых технических объектов и их транспорта в среды контроля качества и промышленной эксплуатации;
подготовка регламента по конфигурационному управлению программными системами, его исполнение и контроль соблюдения. Здесь подразумевается не только версионность вносимых программных изменений в систему и актуализация связанной проектной документации, но также работа с объектами конфигурации (их идентификация в разрезе информационных систем, отслеживание новых версий/обновлений вендора, инициация имплементирования обновления и др.);
подготовка дорожной карты развития программного продукта и его возможной замены на новые софтверные решения с учетом потребностей бизнес-пользователей;
согласование запросов на изменение ИТ-системы и их оценка на соответствие текущей ИТ-архитектуре, технической реализуемости и рискованности;
согласование содержания ИТ-проектов, затрагивающих/меняющих текущую ИТ-архитектуру, формулирование требований к ним, а также контроль того, что внедряемый программный продукт обеспечивает стратегические цели компании.
Работа архитектора тесно связана с взаимодействием с бизнес-пользователями. Для обеспечения единой точки контакта с которыми необходимо выделение отдельной роли, владельца процесса (Business Process Owner, BPO), кто озвучивает и представляет потребности всех пользователей в заданной предметной области.
Обеспечение целостности ИТ-архитектуры предприятия требует групповую работу всей команды по архитектуре, для чего организуется коллективный орган под названием архитектурный комитет. Цель архитектурного комитета состоит в комплексном взгляде на вносимые в ИТ-архитектуру изменения. Порядок коммуникации в этом случае выглядит так:
BPO, обсуждая потребности пользователей, генерирует запрос на изменение системы или выступает с инициативой по старту ИТ-проекта (рис. 3);
ЗНИ отправляется ответственному за его реализацию техническому специалисту, который описывает верхнеуровневое решение задачи, плановые трудозатраты, срок и, возможно, стоимость. Специалист может быть как штатным сотрудником ИТ-службы, так и находится на аутсорсинге;
ЗНИ или инициатива по ИТ-проекту выносится на архитектурный комитет. Чаще всего задаются правила, определяющие, действительно ли их необходимо обсудить на архкомитете или нет;
ЗНИ/ИТ-инициатива рассматривается архитекторами комитета: архитекторы по процессам и данным оценивают степень влияния и сложности изменения, относящиеся корпоративным бизнес-процессам и процессу ведения/хранения данных, архитекторы по ИТ-системам и инфраструктуре озвучивают опасения по техническим вопросам по компетенции. Как результат, дается коллективное решение архкомитета: обоснованный отказ с возможностью внесения изменений в инициативу для повторного вынесения на комитет или согласие на реализацию инициативы.
Здесь следует дать уточнение, в отдел ИТ может входить множество технических специалистов (функциональные аналитики, разработчики и др.), в область ответственности которых входит поддержка и развитие той или иной ИТ-системы. Тогда архитектурный комитет, подтверждая изменение, разработка которого требует вовлечение штатных сотрудников ИТ, руководствуется в том числе их доступностью или явно указывает о необходимости найма специалистов. Детальное обсуждение данного вопроса относится к процессу мобилизации команды и проектному менеджменту.
Комитет по изменению продукта
Решение по старту работ над запросом на изменение принимается комитетом по изменениям продукта (Change Advisory Board, CAB), в то время как инициатива по ИТ-проекту в дальнейшем прорабатывается в ходе бизнес-кейса [1]. Стоит отметить, что ЗНИ может формироваться как со стороны BPO, так и ИТ-команды, в частности для запросов на обновление программной системы. Выделяют две стратегии обновления информационной системы, следуя правилам конфигурационного управления:
активная, как только вендор выпускает новую версию продукта, архитектор по приложению стразу инициирует запрос на обновление, не ожидая обращения со стороны BPO;
пассивная, BPO формирует ЗНИ. По результатам проработки верхнеуровневого решения к нему, подтверждается наличие доступного обновления системы, содержащего необходимый функционал. ЗНИ преобразуется в запрос на обновление системы.
Основное назначение комитета по изменениям продукта состоит в контроле вносимых модификаций в программную систему, планируя все работы так, чтобы минимизировать риск нарушения работоспособности продуктивной системы. Аналогично архкомитету комитет по изменениям продукта является коллегиальным органом и представлен руководителями всех бизнес-функций: закупки, сбыт, производство, финансы, ИТ и др., для которых выполнение регулярных бизнес-процессов невозможно без функционирования ИТ-систем. В обязанности комитета входит:
подтверждение возможности и начала реализации ЗНИ. Например, ЗНИ может быть не согласован в виду ожидаемой программы цифровой трансформации, наличием других ЗНИ, противоречащих текущему и др.;
приостановка и отмена активностей по ЗНИ. Приостановка работ может быть обусловлена высокой сезонной загруженностью, закрытием периода/квартала/года по бухгалтерскому/управленческому учетам и прочими бизнес-мероприятиями, для которых критически важна 100% функционирование и доступность информационных систем;
согласование даты переноса реализованного ЗНИ в продуктивную среду. Следуя ИТ-регламентам, могут быть установлены определенные сервисные окна, в рамках которых разрешен перенос некритичных программных разработок в продуктивную среду, например, каждый вечер четверга. Критичные модификации обычно переносятся по мере потребности.
Запрос на изменение выносится на комитет по изменениям продукта, BPO отстаивает необходимость ЗНИ, архитектор по приложению и ответственный за реализацию запроса технический специалист дают комментарии при возникновении техвопросов. Получив подтверждение от CAB, ЗНИ передается в работу. Разработка запроса на изменение осуществляется согласно методологии внедрения заказчика. Последующее обращение в комитет ведется по мере технической готовности решения с целью подтверждения даты его переноса в продуктивную среду.
Связь предпроектного обследования и пост-проекта внедрения ПО
Активности пост-проекта внедрения программного обеспечения обусловлены SLA и объемом ЗНИ: чем строже предъявляются требования к уровню сервиса и больше число требуемых модификаций имплементированного решения, тем трудозатратнее становится его поддержка и развитие. В начальном разделе текущей статьи были детально описаны ключевые параметры, задающие SLA для поддержки ПО, одним из которых служит число инцидентов в день/месяц ...
Литературный источник
Степанов Д.Ю. Стратегия поддержки и развития внедренных ERP-систем (часть 2) // Корпоративные информационные системы. – 2025. – №4 (32) – c. 7-11. – URL: https://corpinfosys.ru/archive/2025/issue-32/299-2025-32-supportdevelopmentstrategies.
