Эксплуатация ИТ-услуг и скорость

Среднее время поставки (Lead time) является одной из ключевых метрик команд разработки ключевых информационных систем /продуктов компаний. 

Если ваша компания уже не стартап, а «безжалостный и беспощадный» энтерпрайз, то ваши основные бизнес-процессы и поддерживающие их системы / продукты обросли вспомогательными услугами и приложениями, сервисами, on-site инфраструктурой. 

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

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

 "One ring to rule them all ..."

Задачей продуктовых команд является создание устойчивых (resilient) приложений, изменения в которых не нарушают их эксплуатационных характеристик. В этом им помогают: принципы SRE; повышающие надежность методы разработки, такие как test driven development; сквозное автоматизированное тестирование на всех этапах разработки, интеграции и доставки; своевременный контроль и устранение технического долга.

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

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

Вы правильно думаете. Ничего хорошего из этого не выйдет. Эксплуатация/потребление услуг непрерывно связаны друг с другом, нет никаких «стен», через которые некто иногда пытается что-то перебрасывать.

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

Если вышеперечисленные задачи будут выполняться медленно, с неприемлемыми задержками, то страдать от этого будут поголовно все. Клиенты будут недовольны продуктом, т.к. их ощущения от customer journey будут испорчены во всех/почти всех точках контакта с компанией. Сотрудники не смогут своевременно получать информацию и обратную связь для формирования предложений, бизнес-экспериментов (бизнес гораздо более agile чем некоторые думают). Отчеты будет отправлены с опозданием, сделки не заключаться в нужные сроки, волокита и ожидание в очередях поглотит время, которое должно было быть направлено на создание ценности.

Из этого следует очевидный тезис (да, сегодня я снова Капитан): «Эксплуатация должна работать быстро».

Что значит быстро

  • Если запрос пользователя можно обработать автоматически — он будет обработан автоматически: информация предоставлена, приложение установлено, 
  • Вся информация, необходимая для обработки запроса, которую можно собрать автоматически будет собрана автоматически. Список обязательной информации к запросу, которую нельзя собрать роботами, прозрачен и очевиден. 
  • Пользователь понимает, что он запрашивает;  эксплуатация понимает, что запрашивает пользователь. Между этими восприятиями нет разногласий: они всегда трактуются в терминах бизнес-задачи или потребности клиента.
  • Хорошие команды разработки ориентируются на lead time, измеряемых в единицах дней, эталонные — часов. Задача эксплуатационного подразделения не «поспешать, догоняя», а быть быстрее команды разработки. Все типовые запросы выполняются в пределах одного бизнес-дня, а если запрос не является типовым, то с пользователем обеспечивается оперативный контакт и согласуется срок исполнения.

Это возможно?

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

  1. Фокус на ценности, удовлетворении конечной потребности, решении бизнес-задачи, общих целях и миссии организации. 
  2. Организационная и процессная прозрачность за ответственность за исполнения операционных (инциденты, проблемы, запросы) и иных ИТ-процессов (каталог услуг, непрерывность и доступность, активы и конфигурации, знания). Личная ответственность и заинтересованность руководителей, владельцев услуг.
  3. Отсутствие выраженной экономии на экспертизе. Если мы хотим решать множество задач И быстро И качественно, то нам понадобятся думающие головы и работающие руки. (Олег Скрынник не зря написал свою статью «Требования к системе управления с точки зрения персонала») 
  4. Интенсивная, даже превентивная, автоматизация. Удаление людей из процесса настолько, насколько это возможно. Применение нейронных сетей там, где необходимо принятие решения на основании оценки ряда факторов с неалгоритмизируемыми / нечеткими критериями, условиями. 
  5. Умение реагировать на быстро изменяющиеся вызовы: масштабирование на кратное изменение числа входящих запросов; навыки дистанционных коммуникаций, работа с массовыми запросами, публичными коммуникациями. 
  6. Достаточное ресурсное обеспечение, обеспечение творческой свободы и эксперимента, поддержка инициатив и проектов «цифровизации».

Где карта, Билли? 

Вопрос: Где взять деньги на все это счастье?

Ответ: Возьмите их из текущих затрат потерь компании.

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

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

DevOps Основы DevOps

Популярный трёхдневный учебный курс
 

Проект Феникс — DevOps на практике

Полезная деловая игра для вашей команды
 

Узнайте больше!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
24
Учебный курс:
ITIL® 4 Foundation 
АВГ
31
Учебный курс:
Operational Support and Analysis (ITIL OSA)