Среднее время поставки (Lead time) является одной из ключевых метрик команд разработки ключевых информационных систем /продуктов компаний.
Если ваша компания уже не стартап, а “безжалостный и беспощадный” энтерпрайз, то ваши основные бизнес-процессы и поддерживающие их системы / продукты обросли вспомогательными услугами и приложениями, сервисами, on-site инфраструктурой.
Все эти артефакты ваших внутренних и внешних услуг важны в некоторой области, но их ценность не превышает того порога, когда вы задумываетесь о необходимости создания и финансирования отдельной постоянной команды по их развитию в продуктовом ключе, не готовы инвестировать в их развитие.
Тогда вы создаете подразделение по эксплуатации этих разнородных приложений и сервисов и наделяете его ответственностью по обеспечению их бесперебойной работы, поддержке пользователей. Термин “двухскоростного” ИТ появился не зря. В компаниях, которые не рождались сразу цифровыми, такое подразделение первично, и это из него выделяются и уходят в самостоятельное плавание, как оперившиеся птенцы, ключевые бизнес и внутренние продукты.
“One ring to rule them all …”
Задачей продуктовых команд является создание устойчивых (resilient) приложений, изменения в которых не нарушают их эксплуатационных характеристик. В этом им помогают: принципы SRE; повышающие надежность методы разработки, такие как test driven development; сквозное автоматизированное тестирование на всех этапах разработки, интеграции и доставки; своевременный контроль и устранение технического долга.
Эксплуатационные подразделения, исторически, используют другой набор ИТ-процессов для обеспечения операционной стабильности, см. ITIL, COBIT, ISO старых версий. Следуя им, они соблюдают некоторый баланс между уровнем надежности и способностью выполнять изменения в контролируемых средах.
Как вы думаете, что будет происходить, если скорость работы команд разработки ключевых продуктов будет сильно отличаться от скорости работы эксплуатационного подразделения, сделавшего ставку на стабильность поддерживающего окружения и инфраструктуры?
Вы правильно думаете. Ничего хорошего из этого не выйдет. Эксплуатация/потребление услуг непрерывно связаны друг с другом, нет никаких “стен”, через которые некто иногда пытается что-то перебрасывать.
Продуктом, каждый со своей стороны, пользуются клиенты компании, сотрудники компании. Поддержка пользователей: выполнение их запросов на обслуживание, реагирование на локальные пользовательские инциденты, широковещательная коммуникация и сбор ценнейшей обратной связи – ответственность команды/группы эксплуатации, даже если мы говорим о ключевом продукте. Использовать для этих задач разработчиков нерационально: это и дорого и смертельно скучно для последних.
Если вышеперечисленные задачи будут выполняться медленно, с неприемлемыми задержками, то страдать от этого будут поголовно все. Клиенты будут недовольны продуктом, т.к. их ощущения от customer journey будут испорчены во всех/почти всех точках контакта с компанией. Сотрудники не смогут своевременно получать информацию и обратную связь для формирования предложений, бизнес-экспериментов (бизнес гораздо более agile чем некоторые думают). Отчеты будет отправлены с опозданием, сделки не заключаться в нужные сроки, волокита и ожидание в очередях поглотит время, которое должно было быть направлено на создание ценности.
Из этого следует очевидный тезис (да, сегодня я снова Капитан): “Эксплуатация должна работать быстро”.
Что значит быстро
- Если запрос пользователя можно обработать автоматически – он будет обработан автоматически: информация предоставлена, приложение установлено,
- Вся информация, необходимая для обработки запроса, которую можно собрать автоматически будет собрана автоматически. Список обязательной информации к запросу, которую нельзя собрать роботами, прозрачен и очевиден.
- Пользователь понимает, что он запрашивает; эксплуатация понимает, что запрашивает пользователь. Между этими восприятиями нет разногласий: они всегда трактуются в терминах бизнес-задачи или потребности клиента.
- Хорошие команды разработки ориентируются на lead time, измеряемых в единицах дней, эталонные – часов. Задача эксплуатационного подразделения не “поспешать, догоняя”, а быть быстрее команды разработки. Все типовые запросы выполняются в пределах одного бизнес-дня, а если запрос не является типовым, то с пользователем обеспечивается оперативный контакт и согласуется срок исполнения.
Это возможно?
Да, это возможно. Достичь целевого состояния можно при сочетании нескольких факторов успеха (в порядке убывания по степени влияния, с точки зрения автора):
- Фокус на ценности, удовлетворении конечной потребности, решении бизнес-задачи, общих целях и миссии организации.
- Организационная и процессная прозрачность за ответственность за исполнения операционных (инциденты, проблемы, запросы) и иных ИТ-процессов (каталог услуг, непрерывность и доступность, активы и конфигурации, знания). Личная ответственность и заинтересованность руководителей, владельцев услуг.
- Отсутствие выраженной экономии на экспертизе. Если мы хотим решать множество задач И быстро И качественно, то нам понадобятся думающие головы и работающие руки. (Олег Скрынник не зря написал свою статью “Требования к системе управления с точки зрения персонала“)
- Интенсивная, даже превентивная, автоматизация. Удаление людей из процесса настолько, насколько это возможно. Применение нейронных сетей там, где необходимо принятие решения на основании оценки ряда факторов с неалгоритмизируемыми / нечеткими критериями, условиями.
- Умение реагировать на быстро изменяющиеся вызовы: масштабирование на кратное изменение числа входящих запросов; навыки дистанционных коммуникаций, работа с массовыми запросами, публичными коммуникациями.
- Достаточное ресурсное обеспечение, обеспечение творческой свободы и эксперимента, поддержка инициатив и проектов “цифровизации”.
Где карта, Билли?
Вопрос: Где взять деньги на все это счастье?
Ответ: Возьмите их из текущих затрат потерь компании.
Посчитайте все задержки в исполнении бизнес-процессах компании, когда сотрудникам/клиентам приходится ждать решения их ИТ-запросов (не говорю уже про потери от сбоев и затрат связанных с утерей / восстановлением данных). Посчитайте, какая численность клиентов или сотрудников компании прямо сейчас ждет в унынии и растерянности, пока их запросы обработают. Умножьте получившуюся долю на общий ФОТ / выручку и получите грубую оценку потерь компании от не заключенных вовремя сделок, ушедших клиентов, снижения конверсии.
Метод описан автором намеренно грубо и неточно, но даже сама мысль взглянуть на эту цифру (или рассчитать ее более точным способом) может стать отрезвляющим откровением для значительного числа ИТ-руководителей среднего и высшего звена, за исключением, вероятно, CIO.
