Внедренный программный продукт подлежит дальнейшему развитию, причин для которого достаточно: изменение законодательства, технологические тренды и новинки, цифровизация не автоматизированных областей и др. Часто подобные активности над ИТ-системами связывают с запросами на изменение (ЗНИ), относящимися к процессу управления изменениями. Это действительно так, однако работа с ЗНИ требует выстраивания регулярных бизнес-процессов, вовлекающих как бизнес-пользователей, так и технических специалистов, обеспечивающих надзор над корпоративной архитектурой предприятия и соблюдение целостности существующих ИТ-сервисов. Для чего согласно 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.
