Введение

Исследование бизнес-деятельности 495 ИТ-субъектов Томской области (ОКВЭД код 62), проведенное в рамках научно-исследовательского гранта РФФИ №16-36-00031 «мол_а», позволило установить, что во время создания ИТ-продуктов в рамках выполнения ИТ-проектов могут материализоваться порядка 105 универсальных рисков[29]. Под универсальными рисками понимаются вероятные события, актуальные для ИТ-проектов (спринты, фазы жизненного цикла, контракты и др.), независимо от их масштабов, сложности, длительностей (краткосрочные, среднесрочные, долгосрочные), типов (ПО, мобильное приложение, ИС и др.), концепций создания ИТ-продуктов (Waterfall, Agile) и численности участников. Анализ идентифицированных универсальных рисков показал, что одним из механизмов их элиминирования является высокая степень освоения ИТ-субъектами положений о процессах создания ИТ-продуктов и управления ИТ-проектами, которые закреплены в основополагающих национальных стандартах. К данным стандартам относятся ГОСТ Р ИСО/МЭК 12207[1], серия стандартов ИСО/МЭК 15504[2][3], ГОСТ Р ИСО 21500[4] и семейство стандартов «Проектный менеджмент»[5],[6],[7],[8],[9],[10].

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

1. Анализ национальных стандартов, закрепляющих положения о процессах создания ИТ-продуктов и управления ИТ-проектами

Национальный стандарт ГОСТ Р ИСО/МЭК 12207 описывает специальные процессы, которые должны быть реализованы на стороне ИТ-субъекта, если он намерен создавать, поставлять и успешно эксплуатировать ИТ-продукты. Для раскрытия особенностей применения данного стандарта раскроем суть и содержание понятия «процесс» подробнее.

Согласно ГОСТ ISO 9000[11], ГОСТ Р ИСО/МЭК 21827[12], ГОСТ Р ИСО/МЭК 33001[13], ГОСТ Р 54869[14] и ГОСТ Р ИСО/МЭК 15504-1 под процессом необходимо понимать совокупность действий, которые направлены на достижение определенной цели, где вход процесса – это объекты, необходимые для нормальной работы процесса (информация, ресурсы, регламенты и др.), а выход процесса – это результаты достижения цели процесса.

В научной литературе также можно встретить и другие толкования понятия «процесс». Например, О. Вишняков[28] в своих трудах определяет процесс как повторяющуюся упорядоченную цепочку действий, которая создает значимый результат для заказчика, пользователя, клиента, потребителя и др. Более развернутое определение можно встретить в работах Ю. Т. Шестопал, Н. Ю. Дорофеева, Н. Ю. Шестопал и Э. А. Андреевой. Под процессом ученые понимают устойчивую, целенаправленную совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы и выходы, где вход – это ресурс, который необходим процессу, а выход – это результат (продукт) выполнения процесса[30].

Рассмотренные выше определения и требования по документированию процессов, закрепленные в стандарте ГОСТ Р 57098[15], позволяют заключить, что процесс включает в себя такие элементы, как цель, реализуемые действия, функции и их последовательность, потребляемые ресурсы (вход процесса), результат (выход процесса), риски и др. Пример графического изображения процесса согласно ГОСТ Р 57098 представлен на рис. 1.

Рис. 1. Пример графического представления процесса
Рис. 1. Пример графического представления процесса

Анализ положений, закрепленных в ГОСТ Р ИСО/МЭК 12207, показал, что стандарт описывает цели, желаемые результаты, входы и выходы 43 процессов жизненного цикла ИТ-продукта, которые объединены в 7 групп.

Несмотря на исчерпывающую совокупность процессов, необходимых для создания ИТ-продуктов, применение ГОСТ Р ИСО/МЭК 12207 имеет ряд ограничений, о которых необходимо упомянуть.

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

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

  • В-третьих, стандарт не устанавливает применение конкретной модели жизненного цикла (далее – ЖЦ) ИТ-продукта. Ответственность за возможные последствия, связанные с выбором той либо иной модели ЖЦ, согласно положениям стандарта, возлагаются на заинтересованные стороны. Данное обстоятельство также является существенным недостатком, т. к. проведенное исследование показало, что для создания ИТ-продуктов необходимо применять модель ЖЦ ИТ-проекта, включающую в себя квантификацию ЖЦ на 6 фаз: начало ИТ-проекта, определение требований к ИТ-продукту, планирование ИТ-проекта, создание ИТ-продукта, тестирование ИТ-продукта и окончание ИТ-проекта.

Серия стандартов ИСО/МЭК 15504 предлагает использовать процессную модель, состоящую из 60 процессов – 10 процессов соглашения, 13 процессов организационного обеспечения, 7 процессов проекта, 13 технических процессов, 6 процессов реализации ПС, 8 процессов поддержки ПС и 3 процессов повторного применения ПС. Согласно ГОСТ Р ИСО/МЭК 15504-5[16] под процессной моделью понимается модель, состоящая из логической последовательности процессов, выполнение которых гарантирует получение желаемого результата. Несмотря на исчерпывающее описание процессов, описанных в серии стандартов ИСО/МЭК 15504, проведенный анализ показал, что предлагаемая процессная модель не описывает последовательность выполнения действий, оставляя решение о выборе процессов и определение их последовательности выполнения за пользователями. Стандарты не содержат информации о возможных проблемах, которые могут материализоваться в ходе выполнения процессов, о мерах, элиминирующих эти проблемы, а также о метриках, которые бы показывали результативность и эффективность выполнения процессов. Кроме того, предлагаемая модель не содержит процессов анализа проблем, выявления лучших практик, стандартизации и распространения полученного опыта среди заинтересованных сторон и работников ИТ-субъекта. Отсутствие подобных процессов на стороне ИТ-субъекта создает угрозу утраты выученных уроков, что в будущих проектах может привести к повторному появлению ранее решенных проблем.

ГОСТ Р ИСО 21500 распределяет 39 процессов проектного менеджмента на управленческие (инициация, планирование, исполнение, контроль и завершение) и предметные группы (интеграция, заинтересованные стороны, содержание, ресурсы, сроки, стоимость, риски, качество, закупки и коммуникации). Согласно условиям, закрепленным в разделе 4, требования ГОСТ Р ИСО 21500 носят рекомендательный характер, т. к. количество процессов и их последовательность зависит от области, в которой выполняются проектные работы. Например, если используются заемные средства (кредиты), то в проект должны быть добавлены процессы, связанные с финансами. Если проектные работы могут оказать негативное влияние на жизнь и здоровье человека, то в проект необходимо включить процессы по технике безопасности и охране здоровья. Если оказывается негативное влияние на окружающую среду, то процессы, связанные с экологической безопасностью и др.

Кроме того, в ГОСТ Р ИСО 21500 отмечается, что количество процессов и их последовательность также зависит от зрелости субъекта и его накопленного опыта. В качестве примера следует привести PMBOK® Guide, где:

  • в первом издании (1996 г.) было зафиксировано 9 предметных групп и 37 процессов;

  • во втором (2000 г.) – 9 предметных групп и 39 процессов;

  • в третьем (2004 г.) – 9 предметных групп и 44 процесса;

  • в четвертом (2008 г.)[17] – 9 предметных групп и 47 процессов;

  • в пятом (2013 г.)[18] – 10 предметных групп и 47 процессов;

  • в шестом (2017 г.)[19] – 10 предметных групп и 49 процессов.

Среди ключевых недостатков ГОСТ Р ИСО 21500 необходимо отметить, что представленные процессы дают только общее представление о возможном количестве и последовательности выполнения работ.

Несмотря на расширенный перечень процессов проектного менеджмента (61 наименование) аналоги��ные недостатки были также выявлены при анализе семейства стандартов «Проектный менеджмент». Однако данное семейство стандартов закрепляет важное положение, которое заключается в декомпозиции процесса выполнения проекта на совокупность подпроцессов с последующим объединением их в самостоятельные группы. Например, согласно требованиям ГОСТ Р 54869 и Р 50.1.028[20], процесс выполнения проекта включает в себя 5 процессов более низкого уровня – процесс инициации проекта, процесс планирования проекта, процесс организации и исполнения проекта, процесс контроллинга проекта и процесс завершения проекта. Говоря же о наличии подпроцессов следует обратиться к разделу 5 ГОСТ Р 54869, где отмечается, что наличие, количество, повторяемость и последовательность процессов, подпроцессов и функций в первую очередь зависит от масштаба, сложности и длительности работ проекта. Например, если ИТ-продукт создается согласно концепции Agile, то процесс организации и исполнения проекта в части формирования бюджета может выполняться частично либо вовсе отсутствовать.

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

Процессы, реализуемые во время фаз жизненного цикла ИТ-проекта. Результаты проведенного исследования показали, что для каждой фазы модели ЖЦ ИТ-проекта характерно выполнение определенного процесса с получением конкретного результата. Например, по итогу завершения процесса начала ИТ-проекта между заказчиком и ИТ-субъектом должен быть заключен контракт на создание ИТ-продукта. Анализ судебной практики показал, что некачественное, частичное выполнение либо полное невыполнение данного процесса влечет тяжкие последствия.

В качестве примера наступления нежелательного исхода для заинтересованных сторон, которые спонтанно инициировали запуск ИТ-проекта, можно привести дело № А67-4580/2016[21], в котором между сторонами отсутствовали документальные соглашения, подтверждающие заключение контракта. Однако в ходе разбирательства было установлено, что требующие исполнения гражданско-правовые обязательства все же возникли.

Похожая ситуация произошла в деле № А67-3471/2010[22], где подписание актов сдачи-приемки оказанных услуг по техническому обслуживанию и обновлению баз данных ИСС «Кодекс» послужило доказательством того, что между сторонами возникли определенные обязательства.

Другим примером тяжких комплаенс-последствий для заинтересованных сторон является дело № А45-15497/2020[23]. Согласно материалам, при эксплуатации мобильного приложения «Boom Boom» заказчик выявил большое количество программных недостатков и потребовал от ИТ-субъекта переделать работу. ИТ-субъект не согласился с предъявленной претензией и отказал в удовлетворении данного требования. Для определения характера недостатков суд был вынужден провести экспертизу, которая установила, что результат выполненных работ частично соответствует условиям контракта, является некачественным и требует устранения выявленных дефектов. Размер причиненного ущерба составил 340,8 тыс. руб.

Нередки случаи, когда заинтересованные стороны после завершения ИТ-проектов запрещают своим бывшим контрагентам и работникам использовать ИТ-продукты. В качестве примера следует привести дело № А53-23110/22[24], где истец попросил суд запретить ответчику использовать ИТ-продукт «LabWagon». Другим примером является дело № А40-90889/21-134-529[25], где истец требовал запретить использование его ИТ-продукта, изъять все материальные носители с копиями ИТ-продукта и взыскать компенсацию за нарушение исключительных прав в размере 5 млн. руб.

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

Рис. 2. Процессная модель создания ИТ-продуктов в рамках выполнения ИТ-проектов
Рис. 2. Процессная модель создания ИТ-продуктов в рамках выполнения ИТ-проектов

Цели, действия и результаты процессов процессной модели создания ИТ-продуктов в рамках выполнения ИТ-проектов представлены в табл. 1.

Табл. 1. Цели, действия и результаты процессов процессной модели создания ИТ-продуктов в рамках выполнения ИТ-проектов

№

Название процесса

Комментарий

1

Процесс начала ИТ-проекта

Процесс направлен на достижение договоренности между заказчиком и ИТ-субъектом, где ИТ-субъект по заданию заказчика обязуется создать ИТ-продукт, а заказчик обязуется принять его и произвести оплату.

Материальным воплощением договоренности является заключенный контракт.

2

Процесс определения требований к ИТ-продукту

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

Результатом выполнения процесса является ТЗ.

3

Процесс планирования ИТ-проекта

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

По завершению процесса разрабатывается базовый план проекта.

4

Процесс создания ИТ-продукта

Процесс направлен на создание ИТ-продукта согласно заявленным функциональным, пользовательским и бизнес-требованиями, которые предъявляют заинтересованные стороны к разрабатываемому ИТ-продукту.

По завершению процесса создается желаемый ИТ-продукт.

5

Процесс тестирования ИТ-продукта

Процесс направлен на установление соответствия между функциональными, пользовательскими и бизнес-требованиями, которые предъявляют заинтересованные стороны к созданному ИТ-продукту.

Результатом выполнения процесса является верифицированный ИТ-продукт.

6

Процесс окончания ИТ-проекта

Процесс направлен на организацию передачи и перехода прав собственности созданного ИТ-продукта от ИТ-субъекта к заказчику.

Результатом выполнения процесса является валидированный ИТ-продукт.

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

Процессы ИТ-проекта, распределенные по предметным группам. Процессы, относящиеся к функциональным областям управления проектами согласно ГОСТ Р ИСО 21500 должны быть дифференцированы на предметные группы. Предметная группа – это выделенная область проекта, определяемая ее требованиями к знаниям[31]. В частности, управление рисками в проекте является отдельным знаниевым доменом, который регулируется собственным семейством стандартов ГОСТ Р ИСО 31000[26], управление качеством – ГОСТ ISO 9000, управление закупками и интеграцией – нормами действующего гражданского законодательства[27] и др. В литературе также можно встретить синонимы понятия «предметная группа». Например, А. А. Дульзон в своих трудах предметные группы управления проектами называет функциями управления[32]. В своде лучших практик управления проектами PMBOK® Guide используется понятие области знаний, которыми руководитель проекта должен обладать для успешного завершения проекта. В ряде национальных стандартов, например, ГОСТ Р 54869, предметные группы управления проектами именуют как области управления.

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

 Табл. 2. Процессы ИТ-проекта, распределенные по предметным группам

№

Название предметной группы

Комментарий

1

Интеграция

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

2

Заинтересованные стороны

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

3

Содержание

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

4

Ресурсы

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

5

Сроки

Процессы, направленные на создание календарного план-графика проекта, отслеживание его выполнения и обеспечение своевременного завершения. Для данных процессов характерно определение последовательности работ, оценки длительности работ и разработка календарного план-графика проекта.

6

Стоимость

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

7

Риски

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

8

Качество

Процессы, направленные на планирование и обеспечение качества. Для данных процессов характерно определение критериев качества, обеспечение качества и верифицирование ИТ-продукта.

9

Закупки

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

10

Коммуникации

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

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

Цели контроллинга совпадают с целями ИТ-проекта – создать ИТ-продукт в назначенный срок и в границах утвержденного бюджета[33]. Для достижения запланированных целей ИТ-проекта во время контроллинга осуществляется взаимодействие с заинтересованными сторонами, управление их ожиданиями, сбор и протоколирование запросов на изменения, а также внесение изменений в контракты, дополнительные соглашения к ним, технические задания, базовые планы проектов либо ИТ-продуктов. Внесение изменений является ключевым процессом контроллинга, который приводит к изменению существенных условий, в связи с чем рекомендуется в тексте контракта заблаговременно описывать механизм внесения изменений. В табл. 3.5 дается подробное описание процессов контроллинга.

 Табл. 3. Процессы контроллинга ИТ-проекта

№

Название процесса

Комментарий

1

Управление содержанием проекта

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

2

Управление ресурсом проекта

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

3

Управление сроками проекта

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

4

Управление стоимостью проекта

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

5

Управление рисками проекта

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

6

Управление качеством проекта

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

7

Управление закупками проекта

Процесс получения регулярных отчетов от субподрядчиков о ходе исполнения обязательств.

8

Управление коммуникациями проекта

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

9

Управление изменениями проекта

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

10

Управление ожиданиями заинтересованных сторон

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

11

Внесение изменений

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

2. Модель 62 подпроцессов создания ИТ-продуктов в рамках выполнения ИТ-проектов

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

Рис. 3. А.0 – Подпроцессы фазы жизненного цикла «Начало ИТ-проекта»
Рис. 3. А.0 – Подпроцессы фазы жизненного цикла «Начало ИТ-проекта»
Рис. 3. В.0 – Подпроцессы фазы жизненного цикла «Определение требований к ИТ-продукту»
Рис. 3. В.0 – Подпроцессы фазы жизненного цикла «Определение требований к ИТ-продукту»
Рис. 3. С.0 – Подпроцессы фазы жизненного цикла «Планирование ИТ-проекта»
Рис. 3. С.0 – Подпроцессы фазы жизненного цикла «Планирование ИТ-проекта»
Рис. 3. D.0 – Подпроцессы фазы жизненного цикла «Создание ИТ-продукта»
Рис. 3. D.0 – Подпроцессы фазы жизненного цикла «Создание ИТ-продукта»
Рис. 3. E.0 – Подпроцессы фазы жизненного цикла «Тестирование ИТ-продукта»
Рис. 3. E.0 – Подпроцессы фазы жизненного цикла «Тестирование ИТ-продукта»
Рис. 3. F.0 – Подпроцессы фазы жизненного цикла «Окончание ИТ-проекта»
Рис. 3. F.0 – Подпроцессы фазы жизненного цикла «Окончание ИТ-проекта»
Рис. 3. G.0 – Подпроцессы контроллинга ИТ-проекта
Рис. 3. G.0 – Подпроцессы контроллинга ИТ-проекта

Разработанная модель представляет собой замкнутую последовательность подпроцессов, распределенных по фазам жизненного цикла и предметны�� группам, где каждый подпроцесс направлен на получение конкретного измеримого результата(-ов). Замкнутость последовательности подпроцессов указывает на их непрерывность, взаимосвязь и взаимозависимость. Данное обстоятельство подчеркивает важность и значимость каждого подпроцесса. Например, если будут отсутствовать такие процессы, как «B.5 Валидирование ТЗ», «С.13 Валидирование базового плана проекта» и (или) «F.1 Валидирование ИТ-продукта», то может возникнуть проблема, связанная с тем, что заказчик выявит недостатки ИТ-продукта во время его эксплуатации. Кроме того, анализ разработанной модели показал, что самым трудоемким является процесс планирования ИТ-проекта, где нарушение последовательности выполнения подпроцессов создает угрозу получения недостоверных значений в базовом плане проекта и искажение существенных условий контракта.

Заключение

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

Процессная модель универсальна, поэтому подходит для Waterfall и Agile. Универсальность возможна за счет выделения процесса создания ИТ-продукта в отдельную фазу жизненного цикла ИТ-проекта «Создание ИТ-продукта», где решение о способе создания ИТ-продукта ИТ-субъект определяет самостоятельно.

Модель соответствует требованиям, закрепленным в основополагающих национальных стандартах (ГОСТ Р ИСО/МЭК 12207, серия стандартов ИСО/МЭК 15504, ГОСТ Р ИСО 21500 и семейство стандартов «Проектный менеджмент»), дополняя их в части распределения процессов создания ИТ-продуктов в рамках выполнения ИТ-проектов на следующие группы: процессы, реализуемые во время фаз жизненного цикла ИТ-проекта; процессы, распределенные по предметным группам и процессы контроллинга ИТ-проекта.

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

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

Благодаря выявлению 62 подпроцессов удалось не только идентифицировать их результаты, потребляемые трудовые, материальные и финансовые ресурсы, метрики, риски, превентивные меры воздействия, но и определить обязательные разделы для ключевых проектных документов. Например, было установлено, что базовый план проекта должен включать в себя следующие разделы: иерархическая структура работ (ИСР), календарный план-график, диаграмма сети проекта, бюджет проекта, перечень ресурсов, организационная структура проекта, реестр рисков, меры воздействия на риски и реестр заинтересованных сторон. Некачественное, частичное выполнение либо невыполнение данного условия создаст угрозу получения недостоверных значений в базовом плане проекта и искажает существенные условия контракта.

[1] ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. – М.: Стандратинформ, 2010. – 105 с.

[2] ГОСТ Р ИСО/МЭК 15504-1-2009. Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь. – М.: Стандартинформ, 2017. – 20 с.

[3] ГОСТ Р ИСОМЭК 15504-2-2009. Информационные технологии. Оценка процессов. Часть 2. Проведение оценки. – М.: Стандартинформ, 2017. – 16 с.

[4] ГОСТ Р ИСО 21500-2014. Руководство по проектному менеджменту. – М.: Стандартинформ, 2015. – 46 с.

[5] ГОСТ Р 56716-2015. Проектный менеджмент. Техника сетевого планирования. Общие положения и терминология. – М. : Стандартинформ, 2020. – 20 с.

[6] ГОСТ Р 56715.1-2015. Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения. – М.: Стандратинформ, 2017. – 11 с.

[7] ГОСТ Р 56715.2-2015. Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель. – М.: Стандратинформ, 2016. – 42 с.

[8] ГОСТ Р 56715.3-2015. Проектный менеджмент. Системы проектного менеджмента. Часть 3. Методы. – М.: Стандратинформ, 2016. – 11 с.

[9] ГОСТ Р 56715.5-2015. Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения. – М. : Стандартинформ, 2020. – 12 с.

[10] ГОСТ Р МЭК 61160-2015. Проектный менеджмент. Документальный анализ проекта. – М. : Стандартинформ, 2016. – 28 с.

[11] ГОСТ ISO 9000-2011. Системы менеджмента качества. Основные положения и словарь. – М.: Стандартинформ, 2020. – 28 с.

[12] ГОСТ Р ИСО/МЭК 21827-2010. Информационная технология. Методы и средства обеспечения безопасности. Проектирование систем безопасности. Модель зрелости процесса. – М.: Стандартинформ, 2015. – 188 с.

[13] ГОСТ Р ИСО/МЭК 33001-2017. Информационные технологии. Оценка процесса. Понятия и терминология. – М.: Стандартинформ, 2017. – 16 с.

[14] ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом. – М.: Стандартинформ, 2019. – 8 с.

[15] ГОСТ Р 57098-2016/ISO/IEC TR 24774: 2010. Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса. – М.: Стандартинформ, 2018. – 14 с.

[16] ГОСТ Р ИСОМЭК 15504-5-2009. Информационные технологии. Оценка процессов. Часть 5. Образец модели оценки процессов жизненного цикла программного обеспечения. – М.: Стандартинформ, 2016. – 158 с.

[17] Project management body of knowledge. Guide 4th edition (PMBOK-4). – Project Management Institute (PMI), 2008. – 506 p.

[18] Project management body of knowledge. Guide 5th edition (PMBOK-5). – Project Management Institute (PMI), 2013. – 616 p.

[19] Project management body of knowledge. Guide 6th edition (PMBOK-6). – Project Management Institute (PMI), 2017. – 756 p.

[20] Р 50.1.028-2001. Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования. – М.: ГОССТАНДАРТ РОССИИ, 2003. – 50 с.

[21] Решение Арбитражного суда Томской области по делу № А67-4580/2016 от 10.10.2016 г. [Электронный ресурс]. – URL: https://clck.ru/m5nMz (Дата обращения: 31.01.2024 г.).

[22] Решение Арбитражного суда Томской области по делу № А67-3471/2010 от 28.06.2010 г. [Электронный ресурс]. – URL: https://clck.ru/m4kbL (Дата обращения: 31.01.2024 г.).

[23] Решение Арбитражного суда Новосибирской области по делу № А45-15497/2020 от 24.03.2022 г. [Электронный ресурс]. – URL: https://clck.ru/36d7VV (Дата обращения: 31.01.2024 г.).

[24] Решение Арбитражного суда Ростовской области по делу № А53-23110/22 от 07.06.2023 г. [Электронный ресурс]. – URL: https://clck.ru/36cr8y (Дата обращения: 31.01.2024 г.).

[25] Решение Арбитражного суда города Москвы по делу № А40-90889/21-134-529 от 05.10.2023 г. [Электронный ресурс]. – URL: https://clck.ru/36cmjw (Дата обращения: 31.01.2024 г.).

[26] ISO 31000:2009. «Risk Management – Principles and Guidelines». – 2013. – 34 p.

[27] Гражданский кодекс Российской Федерации (ГК РФ). Комментарий к последним изменениям. – М.: АБАК, 2019. – 752 с.

[28] Вишняков О. Преимущество повторяемости. Практическое руководство по бизнес-процессам. Процессы и их описание. СПб.: Питер. 2022. 304 с.

[29] Nikolaenko V., Sidorov A.. Analysis of 105 IT Project Risks. Journal of Risk and Financial Management. 2023. vol. 16(1). no. 33. pp. 1-20. DOI: https://doi.org/10.3390/jrfm16010033

[30] Шестопал Ю. Т., Дорофеев Н. Ю., Шестопал Н. Ю., Андреева Э. А. Управление качеством. М.: ИНФРА-М. 2019. 331 с.

[31] Alasmari E., Martinez-Vazquez P., Baniotopoulos C. A Systematic Literature Review of the Adoption of Building Information Modelling (BIM) on Life Cycle Cost (LCC). Buildings. 2022. vol. 12(11). no. 1829. pp. 1-25. DOI: https://doi.org/10.3390/buildings12111829

[32] Дульзон А. А. Управление проектами. Томск: Изд-во Томского политехнического университета. 2013. 335 с.

[33] Barahmand Z., Eikeland M. S. Life Cycle Assessment under Uncertainty: A Scoping Review. World. 2022. vol. 3(3). pp. 692-717. DOI: https://doi.org/10.3390/world3030039

[34] Николаенко В.С. Анализ процессов создания ИТ-продуктов в рамках выполнения ИТ-проектов // Проблемы анализа риска, 2025. – Т. 22. – № 1. – С. 68-87.