Жизненный цикл корпоративных информационных систем: от бизнес-кейса до прекращения промышленной эксплуатации (часть 1)

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

Аннотация: работа содержит результаты рассмотрения жизненного цикла ERP-систем. В отличие от прочих книг и статей, здесь ведется детальный обзор от фазы бизнес-кейса до прекращения промышленной эксплуатации, не ограничиваясь только проектом внедрения. Весь жизненный цикл разделяется на 3-и части: предпроектное обследование, проект имплементации и фазы после внедрения. Делается вывод о том, что жизненный цикл корпоративных информационных систем является спиралевидным, нежели линейным.
Скачать: PDF (статья), PDF (выпуск №24).
Ключевые слова: стадии жизненного цикла, модели жц, стадии жц ис, жизненный цикл разработки продукта, жизненный цикл ис, бизнес кейс проекта, разработка тэо проекта, технико экономическое обоснование тэо проекта, вывод ис из эксплуатации, ис тендеры, техническое задание на разработку ис, промышленная эксплуатация ис, проведение предпроектного обследования, бизнес как есть, BAU, стадии проектирования программного обеспечения, стадии и этапы разработки программного обеспечения, стадии программного обеспечения, модели ЖЦ ИС, ЖЦ проекта, ЖЦ ПО, этапы проекта ИС, фазы проекта ИС.

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

Приведем шаги классического жизненного цикла программного обеспечения [1]:

  • замысел, где формулируется идея в продукте, описываются выгоды от его реализации, преимущества и недостатки;
  • дизайн, в рамках которого ведется анализ и проектирование будущего программного продукта;
  • изготовление, подразумевающего под собой разработку и настройку программного решения;
  • промышленная эксплуатация, включающая этап гиперподдержки, а также последующий режим работы регулярных бизнес-процессов (BAU, Business as usual) и его поддержки;
  • прекращение применения по причине обновления программного решения до более поздней версии путем перевнедрения или замены на иное приложение.

Теперь слегка адаптируем жизненный цикл под корпоративные информационные системы (КИС), имеющие ряд отличительных параметров по сравнению с классическим пониманием программных продуктов и информационных систем:

  • этапы, предшествующие проекту внедрения;
  • фазы проекта имплементации;
  • а также ранее упомянутые этапы после внедрения: промышленная эксплуатация и вывод программного продукта из эксплуатации.

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

Жизненный цикл корпоративных информационных систем

Рис. 1. Жизненный цикл корпоративных информационных систем

1. Предпроект внедрения корпоративной информационной системы

Основное назначение предпроекта имплементации КИС состоит в обосновании целесообразности его внедрения и выбора будущего подрядчика [2]. Предпроект можно условно разделить на следующие три фазы (рис. 1):

  • бизнес-кейс;
  • проведение тендера;
  • заключение договора на внедрение.

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

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

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

  • список бизнес-процессов, подлежащих автоматизации;
  • реестр функциональных и нефункциональных требований;
  • предполагаемую TO-BE архитектуру (приложения, процессно-функциональная, интеграционная и техническая);
  • план-график внедрения.

Следующий этап – проведение тендера. Потенциальным подрядчикам отправляется запрос на предоставление коммерческого предложения (RFP, Request for proposal) c приложенным тендерным заданием. Ответ на запрос требует от подрядчика подготовки документа коммерческого предложения, для чего на основе технического задания выполняются:

  • Fit/Gap-анализ функциональных требований с целью идентификации и оценки объема доработок и настроек системы;
  • проработка нефункциональных требований, формулировка стратегии доставки проекта (освещаются критичные подходы по миграции данных, тестированию решения, обучению пользователей и др.) и создание устава проекта;
  • актуализация TO-BE архитектуры программного решения;
  • уточнение план-графика проекта и формирование ресурсного плана;
  • расчет стоимости внедрения согласно планам проекта и ресурсов.

Результаты проделанной работы агрегируют в документе коммерческого предложения (КП), в содержание которого входят:

  • предпосылки, цели и задачи проекта;
  • понимание объема проекта (географический, организационный, методологический и технический);
  • TO-BE архитектура системы (приложений, процессная, функциональная и интеграционная);
  • ожидаемый объем разработок и настроек программной системы;
  • план-график проекта;
  • структура проектной команды;
  • распределение ответственности за выполнение работ между исполнителем и заказчиком;
  • стоимость и коммерческие условия;
  • стратегия доставки проекта;
  • допущения и ограничения.

Подготовленный документ КП отправляется заказчику в оговоренные строки для участия в тендере. Собрав КП от различных поставщиков, заказчик выбирает победителя.

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

2. Проект имплементации ERP-системы

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

  • матрицу требований с индикацией Fit/Gap;
  • ресурсный план;
  • устав проекта.

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

  • мобилизация проектной команды;
  • определяется и технически готовится информационный ресурс для совместного хранения и обмена всеми проектными документами;
  • заводится адресная книга, содержащая номера телефонов и адреса электронных почт всех участников проекта как со стороны заказчика, так и исполнителя;
  • определяется программное средство коммуникации между проектной командой, например: VK Teams, Zoom, Dion и др., а также создаются учетные записи в них;
  • осуществляется запрос доступа к существующим ИТ-системам заказчика для членов проектной команды исполнителя;
  • готовятся шаблоны ключевых проектных документов (проектные решения, функциональные спецификации на разработку, документы настроек, сценарии тестирования и др.);
  • вместе с заказчиком определяются стейкхолдеры, формируется состав управляющего комитета, планируются регулярные встречи с ними (не реже одного раза в месяц, по
  • результатам закрытия фаз проекта, а также накануне продуктивного запуска);
  • создаются реестр рисков, список проблем и открытых задач;
  • детализируется план-график проекта;
  • определяется целевой технический ландшафт ИТ-системы, стартуют активности по его подготовке, включая наискорейшее развертывание системы «песочницы»;
  • проводится установочная встреча с участниками проекта, где демонстрируется план-график проекта, организационная структура проектной команды со стороны исполнителя и заказчика, ожидаемые результаты разрезе этапов проекта и прочее.

Завершение подготовки знаменует начало фазы анализа требований. На этапе идентификации и детализации требований решаются следующие задачи:

  • подготовка карты бизнес-процессов согласно отраслевой специфике заказчика, проведение сессий по детализации пользовательских требований в разрезе бизнес-процессов из карты;
  • Fit/Gap-анализ требований, а также RICEF классификация разработок и настроек для Gap-области;
  • формирование матрицы отслеживания требований, содержащей все идентифицированные и детализированные потребности, приоритизация требований;
  • актуализация объема требований путем сопоставления числа требований из Gap-области из исходного тендерного задания (т.е. матрицы требований с индикацией Fit/Gap
  • на базе которой формировались КП и договор на внедрение) и матрицы отслеживания требований, созданной по результатам фазы анализа;
  • при выявлении новых требований, критичных для запуска и ранее не упомянутых ни в КП, ни в договоре, их реализация ведется в рамках подпроекта, финансируемого и контрактуемого отдельно.

Уточнив объем требований, начинается фаза проектирования, где:

  • для каждого требования из Gap-области, для которого необходима доработка системы, готовится документ функциональной спецификации на разработку. Реализацию оставшихся требований Gap-области описывают в документах настроек;
  • описание TO-BE процесса ведут в проектных решениях, ссылаясь на необходимые доработки и настройки, данные выше. Проектные решения создаются для следующих пунктов: бизнес-процессы, организационная структура и справочники данных, миграция данных, роли и полномочия;
  • в качестве графических нотаций для моделирования TO-BE процессов в документах проектных решений могут использоваться: BCM, IDEF0 или ARIS VACD для верхнеуровневого проектирования, а также Cross WFD, DFD, IDEF3, BPMN SLD, UML AD или ARIS eEPC – низкоуровневого описания. В большинстве ERP-проектов использование CASE-средств ограничено моделированием процессов только нижнего уровня на базе BPMN SLD;
  • проектные документы подлежат обязательному согласованию заказчиком, поэтому необходимо: заранее определить список согласующих по направлениям/документам, задать заместителей на случай недоступности согласующих, ограничиться не более одной сессией для демонстрации документа заказчику, четко сформулировать порядок ведения и обработки замечаний, выделить не более трех итераций получения и обработки замечаний, а также объявить об автосогласовании документа, если обратная связь не дана по прошествии нескольких рабочих дней.

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

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

Реализованная программная система позволяет приступить к полноценному ее тестированию как силами исполнителя, так и заказчика. На этапе тестирования ведутся следующие активности:

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

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

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

В случае успешного принятия решения о возможности промышленной эксплуатации, стартует фаза гиперподдержки, где решаются задачи:

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

Ссылка на 2-ю часть статьи.

Литература

  1. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
  2. Степанов Д.Ю. Управление жизненным циклом систем управления ресурсами и взаимоотношениями предприятия, М.: РТУ МИРЭА, 2023. – URL: https://stepanovd.com/training/15-lifecycle.
  3. Степанов Д.Ю. Цифровизация и корпоративные информационные системы // Корпоративные информационные системы. – 2021. – №4(16). – С. 54-62. – URL: https://corpinfosys.ru/archive/issue-16/121-2021-16-digitalizationerp.

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

Степанов Д.Ю. Жизненный цикл корпоративных информационных систем: от бизнес-кейса до прекращения промышленной эксплуатации (часть 1) // Корпоративные информационные системы. – 2023. – №4 (24) – С. 16-25. – URL: https://corpinfosys.ru/archive/2023/issue-24/229-2023-24-erplifecycle.

Жизненный цикл корпоративных информационных систем

Об авторе

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

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

  1. Жизненный цикл корпоративных информационных систем (часть 1);
  2. Каскадная методология для разработки мобильных приложений (часть 2);
  3. О системах налогообложения в РФ в 2024 году;
  4. RICEFS-классификация разработок и настроек.