Продуктовый подход к построению сложных решений в нефтегазовой отрасли

Проблематика отрасли

Цифровизация. Нет четкого определения данному понятию как в целом по рынку, так и в рынке нефтегазовой отрасли. Можно дать следующее: цифровизация — процесс внедрения организацией информационных технологий, сопровождаемый оптимизацией системы управления основными технологическими и бизнес-процессами. Цифровизация призвана ускорить рост ключевых показателей бизнеса за счет автоматизации рутинных процессов, измерения ключевых метрик с целью более эффективного управления и планирования относительно текущих показателей.

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

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

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

• Создание отраслевых информационных центров компетенций (ИЦК) согласно поручению правительства от 13 сентября 2022 года. (http://government.ru/orders/selection/401/46589/)
• Продолжением создания ИЦК в нефтегазовой отрасли стало появление нефтегазового консорциума 15 июня 2023. Среди участников объединения заявлены девять нефтяных и газовых компаний: ПАО «Газпром», ПАО «Газпром нефть», АО «Зарубежнефть», ПАО «ЛУКОЙЛ», ПАО «НОВАТЭК», АО «Росгеология», ПАО «СИБУР Холдинг», ПАО «Татнефть» и ПАО «Транснефть». (https://www.comnews.ru/content/226816/2023-06-16/2023-w24/neftegazovyy-ick-dal-pobeg-forme-konsorciuma)
• Российский фонд прямых инвестиций и российские нефтегазовые компании договорились о создании отраслевого инвестиционного фонда «Технологии для нефтегазовой промышленности». Его задача — инвестиции в компании, развивающие критически важные технологии для нефтегазовой отрасли, сообщил РФПИ. (https://www.interfax.ru/business/983818)

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

Роль интеграторов

Долгие годы роль интеграторов цифровых решений заключалась в использовании решений западных и цифровых вендоров, которые необходимо было дорабатывать большим количеством кастомного кода, который на другом проекте достаточно сложно переиспользовать. В 2022 году ситуация резко изменилась. Западные вендоры, которые могли поставлять до 90% софта, стали уходить из России, оставив достаточно высокой планку зрелости цифровых решений.  А замены на их место даже в ключевых проектах попросту не существовало. Интеграторы, в свою очередь, за годы работы с крупнейшими игроками рынка собирали воедино «конструктор» из решений вендора, инфраструктуры заказчика и собственных разработок — и стали обладать весомой экспертизой.  В дополнение: проектная модель разработки сложного программного обеспечения постепенно себя изживает на рынке нефтегаза. Участники форума TNF 2024 — отраслевой площадки, объединяющей государство, ВИНК, поставщиков оборудования и технологий, упоминали о:

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

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

Продуктовый подход

Здесь необходимо уточнить терминологию проектного и продуктового подходов.

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

Основным атрибутом проектного подхода является ограничение во времени с установленными ресурсами и бюджетом. Также можно выделить:

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

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

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

Продуктовый подход в разработке призван учесть все эти атрибуты и создать дополнительные преимущества.

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

Отсюда следуют основные атрибуты такого подхода:

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

Этапы продуктового подхода. Этап 1: исследования

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

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

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

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

Рискованное предложение — это позитивное мнение об изменении, из которого мы исходим, думая, что в будущем закроет потребность, принесет реальный результат, улучшит процесс и так далее. Фактически все пожелания, заказчика в том числе, являются рискованными предположениями, которые совсем не обязательно несут пользу. Статистически 90% рискованных предположений являются провальными даже среди сотрудников с высокой экспертизой. Часто экспертность и привычки могут негативно сказываться в процессах, где высок процент изменений.  Рискованные предложения нельзя изначально считать сформированными требованиями, поскольку они требуют проверки методами оценки и приоритизации. Например, через использование метода Riskiest Assumption Test (RAT). Алгоритм здесь следующий:

1. Составляем список рискованных предположений, собирая его со всех участников процессов изменений и доработок. Фактически это расширенный сбор требований, с использованием методологий интервьюирования проблемного с элементами решенческого JTBD-интервью.
2. Оцениваем по формуле Risk Score = вероятность * последствия / [стоимость проверки].
3. Проводим приоритизацию по Risk Score.
4. Визуализируем наиболее приоритетные рискованные предположения на специальной схеме (см. рисунок 1), выбирая наименее дорогие по последствиям издержек предложения по проверке с наибольшей вероятностью на успешность выполнения. Данная область графика называется Local Optimа.

Рисунок 1. Пример Riskiest Assumption Test c областью Local Optimа

Далее рискованные предположения из области Local Optimа. Необходимо превратить в гипотезы.

Гипотеза — это артефакт доказательного знания, включающий в себя:

• определение,
• процесс экспериментальной проверки на основе выработанных критериев,
• обработку результатов и обратной связи.

Гипотеза содержит в себе:

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

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

Качественные исследования продукта позволяют выявить потребности, мнения и мотивы сегмента и пользователя:

1. JTBD-интервью.
2. Опросы.
3. Фокус-группы.
4. CJM.
5. UX-исследования.

Количественные отвечают на вопрос «Сколько?». Часто выражаются в продуктовые метрики, но необязательно.

Примеры:

1. A/B-тестирование. Позволяет проверить гипотезу о том, поменяется ли выбранная продуктовая метрика, если изменить что-то в продукте.
2. Кластеризация качественных обращений.
3. Веб-аналитика через метрики взаимодействия с UI-продуктом.

Этапы продуктового подхода. Этап 2: формулировка работы

Сформированные и проверенные гипотезы служат, по сути, одной цели — формулировке и формированию целевых работ.

Работа (Job) — в продуктовом подходе, то для чего на самом деле нанимают наш продукт. Например, в рамках цифровизации ПХГ целевая работа директора холдинга состоит в снижении себестоимости конечной продукции, что влияет на KPI, что склоняет его к выбору наиболее эффективного и качественного решения от того или иного вендора.

Описание работы строится так:

Кто [должность, роль взаимодействия с продуктом и проектом]

Когда [контекст+особенности компании+прошлый опыт компании/сотрудника+триггер]

Хочу [понятный результат]

Чтобы [выполнить цель/KPI/OKR] ИЛИ работа выше уровнем + чувствовать себя по-другому в контексте выполнения работы выше уровнем

Решение: [доминирующее решение, которое этот пользователь нанимает на работу]

Проблемы с решением:

Проблема 1

Проблема 2

Проблема N

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

Дополнительно должен срабатывать ряд соответствий:

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

Этапы продуктового подхода. Этап 3: процесс производства продукта

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

Рисунок 2 Процесс продуктовой разработки

Любопытно, что до этапа «Проверка решения MVP» не должно быть написано ни строчки требований или кода. То есть проверка осуществляется минимальными ресурсами исследований, без привлечения команды разработки. Чаще всего это владелец продукта (Product Owner), руководитель проекта и аналитики.

Выводы использования продуктового подхода

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

В компании IBS в продуктах нефтегазовой отрасли продуктовый подход уже предлагает свои разработки в виде конструктора из продуктовых сервисов на базе продуктов КАМА, InSim, iFDP и лучших наработанных за годы практик внедрения в отрасли.