Крупная нефтегазовая компания на протяжении многих лет активно инвестировала в цифровизацию и разработку информационных систем. В какой-то момент курирующие руководители столкнулись с тревожными сигналами: затраты на разработку и доработку информационных систем росли, а отдача от вложений не всегда соответствовала ожиданиям.
Ситуация выглядела парадоксальной. С одной стороны, компания тратила значительные средства на создание новых цифровых решений. С другой – многие из этих решений с трудом находили путь к пользователям, а те, что доходили до эксплуатации, требовали постоянной доработки и переделки.
Особенно остро проблемы проявлялись в сервисной функции – подразделении, которое отвечало за поддержку и сопровождение информационных систем после их передачи в эксплуатацию. Нагрузка на сервис постоянно росла: количество обращений пользователей увеличивалось, сроки их решения удлинялись, а команда сервиса не успевала наращивать компетенции.
Предварительный анализ выявил несколько ключевых предпосылок для запуска проекта: решения с трудом тиражировались между дочерними обществами, часто не соответствовали ожиданиям бизнеса, наблюдалась высокая зависимость от сторонних вендоров, росла стоимость эксплуатации, а подбор квалифицированных кадров для сервиса становился всё более сложной задачей.
Цель проекта
Перед проектной командой была поставлена амбициозная цель: с привлечением экспертов «Лин Вектор» оценить, как процессы, предшествующие этапу эксплуатации (проектирование, разработка, внедрение), влияют на эффективность сервиса, и найти способы повысить эту эффективность.
Ожидаемый бизнес-результат
Формулировался конкретными цифрами: повышение производительности труда при разработке и доработке информационных систем на 15% и снижение совокупной стоимости разработки и владения системами примерно на 500 миллионов рублей в год.
Как проходил проект: три этапа глубокой диагностики
Для диагностики были выбраны две ключевые информационные системы, поддерживающие критически важные бизнес-процессы: система мониторинга бурения и система учёта ремонтов скважин. Периметр проекта охватывал корпоративный центр, дочерние общества и команды разработчиков.
На этом этапе команда проекта провела масштабную работу по сбору информации. Были организованы десятки интервью с ключевыми участниками процессов: пользователями из дочерних обществ, бизнес-аналитиками, корпоративными и ИТ-архитекторами, командами разработки и сервиса.
Команда проекта выезжала на предприятия, проводила очные встречи в нескольких городах. Параллельно анализировались нормативные документы: регламенты управления проектами, стандарты по ремонту скважин, журналы обращений пользователей, бэклоги замечаний по системам.
Собранные данные позволили сформулировать три основные гипотезы о том, что мешает эффективной работе.
Первая гипотеза
Касалась разрыва в понимании ИТ-услуг между бизнесом и ИТ-специалистами. Пользователи и разработчики по-разному понимали, что такое качественная услуга и какие параметры её работы действительно важны. В результате функционал разрабатываемых решений не полностью удовлетворял бизнес-потребности, уровень удовлетворённости пользователей снижался, а количество обращений в техподдержку росло.
Вторая гипотеза
Была связана с тем, что команда сервиса не вовлекалась на ранних стадиях жизненного цикла продуктов. Когда система доходила до этапа передачи в эксплуатацию, сервисная команда не имела полной информации о её архитектуре, планируемых доработках и технических параметрах. Это приводило к сложностям при формировании команды поддержки и понимании проблем при тиражировании.
Третья гипотеза
Указывала на недостаточную проработку требований на стадии проектирования. Ключевые пользователи из разных дочерних обществ не всегда вовлекались в формирование технического задания. В результате после запуска системы возникало большое количество запросов на доработку и модернизацию.
На заключительном этапе команда проекта провела глубокий анализ собранных данных для проверки выдвинутых гипотез. Были изучены журналы обращений в сервисную службу, проанализирована статистика по проектам, оценены временные и финансовые затраты.
Результаты анализа
- Среднее количество инцидентов в месяц по одной только системе учёта ремонтов скважин составляло 356, а запросов на обслуживание – 831.
- На решение одного обращения уходило от 4 до 8 человеко-часов.
- Из 22 ИТ-проектов, запущенных в рамках одного из продуктовых направлений, часть была отменена и так и не дошла до стадии эксплуатации. Причины – недостаточная проработка требований, отсутствие связи с реальными бизнес-процессами.
- Некоторые бизнес-операции выполнялись сотрудниками сервиса вручную, хотя должны были быть автоматизированы в информационной системе. Например, смена видов и кодов работ по ремонту, разделение ремонта, разутверждение работ – только по этим трём операциям сервис получал около 175 обращений в месяц.
Что удалось выявить
В результате диагностики были выделены три основных направления, где скрывался наибольший потенциал для улучшений.
Самая фундаментальная проблема заключалась в том, что компания проектировала функционал, а не способ предоставления ценности – то есть ИТ-услугу.
Выявленные проблемы:
- При формировании технического задания описывалось текущее состояние бизнес-процессов, но без учёта их возможного улучшения. Разрабатывался детальный функционал, учитывающий пожелания большинства пользователей, но без привязки к бизнес-процессам и их ключевым показателям эффективности (КПЭ).
- Расчёт экономической эффективности и возврата инвестиций не был привязан к изменению бизнес-процессов. По сути, компания оценивала, сколько денег сэкономит внедрение конкретной кнопки в интерфейсе, но не понимала, как эта кнопка повлияет на весь процесс, например ремонт скважин, – от планирования до сдачи акта выполненных работ.
- Отсутствовала детализация бизнес-процессов до уровня операций. По бизнес-операциям не было понимания ключевых параметров: важность операции для бизнеса, влияние на КПЭ, требуемая мощность (количество повторений в единицу времени, количество пользователей).
- Расчёт эффектов от автоматизации был затруднён, потому что отсутствовали схемы текущего и целевого состояний процессов, данные о качестве процессов (ошибки, повторяемость, наличие регламентов) и показатели стоимости процессов.
Предложения по исправлению ситуации
Переход от проектирования функционала к проектированию ИТ-услуги, где каждый элемент привязан к бизнес-процессу и его КПЭ. Использование инструментов моделирования бизнес-процессов позволяет сократить издержки на разработку и эксплуатацию на 5–20%, а время разработки – на 5–15%.
Вторая группа проблем касалась того, как управляются ИТ- и цифровые проекты.
Выявленные проблемы:
- Сроки разработки были длительными, функционал успевал устаревать за время создания системы. Постоянно требовались новые изменения – проект как будто никогда не заканчивался.
- Проектирование и разработка велись под конкретный функционал, а не под средства автоматизации бизнес-процесса. ИТ-услуга не формировалась с необходимыми атрибутами (показатели качества, поддерживаемые бизнес-процессы, приоритеты обращений, стандартные обращения).
- Архитектура решения не учитывала требования бизнеса – мощность системы, количество бизнес-транзакций, пиковые нагрузки.
- Особенно остро стояла проблема вовлечения сервисной команды. Специалисты сервиса не привлекались на ранних стадиях жизненного цикла продукта. Они не видели планирующиеся доработки, не понимали, что проверять при передаче системы в эксплуатацию, не могли оценить, какие ресурсы потребуются для поддержки.
- Беклоги задач были разрозненными – у разных членов команд были свои списки задач, что не позволяло объективно оценить сроки выполнения.
- Отсутствовала релизная политика на уровне компании, не было единого подхода к тестированию и выпуску новых версий.
Предложения по исправлению ситуации
Вовлечение сервиса на ранних стадиях жизненного цикла продукта, формирование единого бэклога задач, подготовка релизов и нефункциональных требований. Это позволит обеспечить бесшовную передачу продукта на сервис, повысить качество и удовлетворённость от ИТ-услуг, снизить объём запросов на изменения.
Третья группа проблем относилась непосредственно к этапу эксплуатации информационных систем.
Выявленные проблемы:
- Параметры качества технической поддержки (SLA – Service Level Agreement) были едиными для всех услуг – завышенными для одних и заниженными для других. При этом они были сформулированы на языке ИТ-специалистов и были непонятны бизнесу.
- Каталог услуг находился в начальном состоянии – разрозненный, слабо структурированный, хранящийся в различных форматах и файлах, не в бизнес-ориентированном формате.
- Наблюдался постоянный рост количества обращений в сервис при отсутствии их системного анализа. Компания не понимала, какие именно проблемы возникают у пользователей чаще всего и что нужно менять в системах, чтобы этих обращений стало меньше.
- Ресурсы на сервис постоянно увеличивались, но это не решало проблему – количество обращений росло быстрее, чем штат.
- Сложность тиражирования решений между дочерними обществами была высокой, потому что бизнес-процессы в разных регионах отличались, а системы проектировались без учёта возможности масштабирования.
- Анализ обращений был слабым и не позволял выявлять необходимость изменений в системах. Обратная связь с этапа эксплуатации не в полной мере учитывалась в проектах развития.
Предложения по исправлению ситуации
Формирование каталога ИТ-услуг в бизнес-терминах, стандартизация обращений и маршрутов их решения, работа с критическими инцидентами с учётом специфики бизнес-требований. Анализ обращений позволит сократить затраты на техподдержку на 5–10% и проектировать более востребованные решения.
Дальнейший план изменений
По итогам проекта были разработаны три сценария реализации выявленных потенциалов, различающихся по сложности и получаемому эффекту.
Включал периодический анализ обращений, поступающих в сервис, формирование на его основе задач для бэклога и расчёт экономической эффективности, а также анализ бизнес-функций, выполняемых сотрудниками сервиса вручную, для их последующей цифровизации.
Результат
Экономия более 2 000 человеко-часов в месяц. Затраты на реализацию этого сценария минимальны, требуются в основном организационные мероприятия.
Добавлял переформатирование роли бизнес-аналитика для участия на всех этапах жизненного цикла ИТ-услуги, анализ обеспечивающих ИТ-функций для реинжиниринга, а также формирование типовых обращений и маршрутов их решения.
Результат
Для сервиса экономия 240–480 человеко-часов в месяц в дополнение к эффекту от первого сценария, для бизнеса – сокращение времени протекания процессов.
Предполагал системные изменения: определение стандартных процессов для масштабирования в дочерних обществах, разработку стратегии цифровизации на основе процессного ядра, привязку эффектов в расчётах экономической эффективности к КПЭ бизнес-процессов, формирование целевой структуры каталога ИТ-услуг.
Выбранное решение
В качестве наиболее пригодного для дальнейшего развития был выбран сценарий «Оптимальный эффект».
Дорожная карта реализации
Дорожная карта реализации включала несколько ключевых направлений:
Направление 1
Определение стандартных процессов для их масштабирования в дочерних обществах, формирование схем процессов в ИТ-системе (процессное ядро). Это позволит создать единую основу для автоматизации.
Направление 2
Разработка стратегии цифровизации бизнес-процессов на основе процессного ядра, определение приоритетных процессов для автоматизации на основе параметров качества и КПЭ.
Направление 3
Привязка эффектов в расчётах экономической эффективности проектов к КПЭ бизнес-процессов. Теперь каждый проект будет оцениваться не по тому, сколько функций он добавил, а по тому, как он повлиял на ключевые показатели бизнеса.
Направление 4
Определение целевой структуры описания ИТ-услуг для каталога и описание услуг для пилотных систем.
Направление 5
Периодический анализ обращений, поступающих в сервис, формирование на его основе задач для бэклога и расчёт экономической эффективности. Обратная связь от пользователей перестанет быть «шумом» и станет источником данных для улучшения продуктов.
Направление 6
Анализ бизнес-функций, выполняемых сотрудниками сервиса вручную, для их последующей цифровизации. Те операции, которые сегодня отнимают время сервисных инженеров, будут автоматизированы.
В реализации мероприятий предполагалось участие широкого круга подразделений: сервисной команды, бизнес-аналитиков, блоков бизнес-трансформации дочерних обществ, кадровой службы, архитекторов, управлений эффективности и сравнительного анализа, закупок и многих других.
От диагностики – к системным изменениям
Проект по оценке потенциала ИТ-компании стал важным этапом на пути к более эффективному управлению цифровыми активами. Вместо того чтобы продолжать бесконечно наращивать затраты на разработку и эксплуатацию, компания получила чёткое понимание того, где скрываются резервы для улучшений.
Главный вывод проекта звучал просто, но парадоксально: компания проектировала функционал, а не способ предоставления ценности. Все проблемы – от несоответствия ожиданиям бизнеса до сложности тиражирования и роста нагрузки на сервис – были следствием этого фундаментального разрыва.
Предложенные изменения затрагивали не отдельные процессы, а весь жизненный цикл ИТ-услуги: от формирования требований и проектирования до эксплуатации и обратной связи. Именно комплексный подход должен был дать максимальный эффект.
Полученные в рамках проекта результаты планировалось использовать для тиражирования решений на другие продуктовые направления компании. Опыт, накопленный при диагностике двух пилотных систем, должен был стать основой для масштабирования изменений на всю ИТ-экосистему.
Компания сделала первый шаг от реактивного управления («чиним то, что сломалось») к проактивному («проектируем так, чтобы ничего не ломалось»). Впереди была большая работа по трансформации процессов, но направление было определено, а первые результаты уже давали основания для оптимизма.