Оригинал: IT-as-a-business is dead. Long live BusOps
Автор: Боб Льюис (Bob Lewis)
Чтобы быть преуспеть в цифровую эпоху, необходимо перенацелить ИТ-проекты с чисто технологических на бизнес-результаты. Но это еще не все: эксплуатационная составляющая деятельности ИТ-службы должна влиться в бизнес-операции точно так же, как ИТ-приложения должны стать неотъемлемой частью ведения бизнеса.
Во многих организациях ИТ-подразделения функционируют как самостоятельный бизнес – как поставщик услуг для внутренних заказчиков. К сожалению, такой подход плохо сказывается и на разработке приложений, и на эксплуатационной составляющей ИТ.
Отчасти это связано с ненормальной практикой «ИТ как бизнес», когда между ИТ и внутренними заказчиками устанавливаются соглашения об уровне сервиса (SLA).
Если взглянуть на истинный ИТ-аутсорсинг, то там SLA состоит из пары метрик: первая устанавливает минимально допустимый уровень сервиса, вторая – то, насколько часто аутсорсер должен демонстрировать этот уровень.
Первая часть обычно тривиальна; вторая представляет больший интерес. Например, SLA может определять максимально допустимую длительность перебоя в предоставлении сервиса в один час. Вторая часть метрики оговаривает, что этот показатель должен выдерживаться в 99% случаев прерывания сервиса.
Контракт также оговаривает меры на тот случай, если аутсорсер не выдерживает SLA, и это является предметом переговоров. Если предполагается, что ИТ-подразделение должно функционировать как независимый бизнес, то что может быть более логичным, чем установить SLA с внутренними заказчиками?
Оказывается, есть масса более логичных альтернатив.
Инновации как вызов
Внутренние SLA – идея плохая по нескольким причинам. Во-первых, они работают на неверную модель «ИТ как бизнес», в которой ИТ продает услуги внутренним заказчикам.
Во-вторых, что эти «заказчики» будут делать, если ИТ-служба нарушит SLA – подаст на нее в суд? SLA без штрафа за несоблюдение бесполезен, а SLA со штрафом разрушают доверие внутри организации.
В-третьих, как известно, что вы меряете – такой результат и получите. Применительно к ИТ, обычно измеряется уровень сервиса, но для инноваций никаких метрик не предусмотрено.
Хорошо организованная ИТ-служба постоянно балансирует между надежностью и инновациями, ведь инновации подразумевают риск. SLA – это взгляд в прошлое, они показывают негативные следствия инноваций, но не показывают их выгоду.
Рассмотрим в качестве примера переход на SSD. Для первых энтузиастов их краткосрочная и долгосрочная надежность оставалась величиной неизвестной. Однако они прекрасно окупились, продемонстрировав более высокую производительность в аналитических приложениях и в обработке больших данных.
Оставаться на вершине прогресса означает принимать риск и смотреть в будущее, к чему SLA по своей природе не располагает.
Обвинения против SLA
Обычно на ИТ-службу возлагается двоякая ответственность: за оборудование и за поддержку.
SLA, относящиеся к оборудованию, оговаривают такие вещи, как доступность и производительность – что здесь не так? Дело в том, что когда-то в прошлом построение архитектуры высокой надежности было сложной задачей, а теперь – нет.
Должна ли ИТ-служба продолжать отслеживать уровень сервиса, относящийся к оборудованию? Да – в том случае, если дела идут не очень хорошо, но лишь как инструмент, призванный довести уровень сервиса до уровня, на которым постоянный мониторинг становится напрасной тратой времени.
Потому что сегодня, хотя какая-то часть оборудования может отказать, это больше не приводит к неисправности всей системы. Это то, что дает архитектура высокой готовности. Выход всей системы из строя стало событием настолько редким, что ведение статистики по нему – напрасная трата времени.
Не является напрасной тратой времени анализ корневых причин, т.к. каждый случай выхода из строя означает, что в вашей архитектуре высокой надежности есть конструктивный дефект, который необходимо устранить. Не является потерей времени также анализ инцидентов, направленный на раннюю диагностику и предотвращение проблем до того, как они отразятся на бизнесе.
Вторая составляющая – служба поддержки. Это то, что ИТ делает в рамках помощи операционным подразделениям. Здесь SLA связаны с такими показателями, как время ожидания ответа на обращение в хелпдеск и время от обращения до устранения проблемы.
Но в любой произвольно выбранный день, в рамках любого выбранного обращения хелпдеск отвечает либо слишком быстро, либо слишком медленно по сравнению с SLA: слишком быстро, если сотрудников в данный момент больше, чем обращений, и наоборот.
Таким образом, SLA никак не связан с производительностью. Это просто палка чтобы погонять отвечающего за хелпдеск менеджера.
SLA имеет значение только в период составления бюджета, когда уровень сервиса хелпдеска можно использовать как аргумент для найма дополнительного персонала.
Справедливости ради, это немало. Но это аргумент для того, чтобы контролировать уровень сервиса, а не чтобы вести торг об SLA.
Единственная важная операционная метрика ИТ
Для большинства управленцев успех повышает их заметность в организации, за которым могут последовать повышения, почести и премии. Службу эксплуатации ИТ замечают только когда что-то идет не так.
Хорошая метрика должна быть количественным отражением какой-то цели. В случае эксплуатации ИТ целью является невидимость, а ее метрикой – комплексный «индекс невидимости», включающий доступность и производительность приложений, количество обращений в хелпдеск (меньше обращений – больше невидимость) и некоторый показатель того, как часто производительность ИТ является «бутылочным горлышком» для бизнес-процессов и операций.
Типичная ИТ-служба включает два подразделения: одно отвечает за разработку приложений, другое за их эксплуатацию. Традиционно, эти две группы смотрят друг на друга с недоверием. Во-первых, разработка считает доработку приложения своим достижением, а для эксплуатации каждое изменение означает риск, повышающий видимость ИТ-службы. Во-вторых, разработка зависит от эксплуатации в вопросах развертывания и поддержания сред разработки и тестирования. Для разработки это означает, что эксплуатация является бутылочным горлышком, а для эксплуатации – дополнительную и зачастую незапланированную работу.
Теперь взглянем на DevOps. В отличии от большинства разновидностей аджайла, здесь команда разработки включает одного или несколько представителей службы эксплуатации, которые делают свою часть работы согласно графику проекта в командном духе, а не через очередь запросов к службе эксплуатации.
Все это к тому, что там, где между двумя группами, которые должны работать вместе, возникает трение или недоверие, вариантом решения может быть смешивание позаимствованных из двух групп сотрудников и процессов.
Цифровая трансформация и изобретение BusOps
Для менеджмента большинства сегодняшних организаций цифровая трансформация звучит как барабанный бой. Но переживал ли когда-нибудь менеджмент увлечение более неоднозначное и противоречивое, чем цифровая трансформация?
За всеми эти неоднозначностями кроятся конкретные цифровые технологии, открывающие новые возможности. Бизнес может воспользоваться ими, чтобы получить конкурентное преимущество. Или может их проигнорировать, дав возможность получить преимущество конкурентам.
За этой конкретикой стоит новая реальность: информационные технологии больше не являются опцией. Они глубоко встроены в каждый бизнес-процесс, во всю каждодневную деятельность вашей компании. Следствием этого является то, что служба эксплуатация ИТ, по идее, превратилась в одну из составляющих бизнес-операций и таким образом стала входить в сферу ответственности операционного директора в не меньшей степени, чем ИТ-директора.
Прежде чем двигаться дальше, сделаем замечание практического плана: в чье бы подчинении не передавалась служба эксплуатации ИТ, ее следует сохранить. Ее эффективность (и вытекающая из этого невидимость) зависит от продолжающейся слаженной работы множества опытных специалистов в этой зрелой и хорошо проработанной дисциплине.
Управление процессами и деятельностью этих сотрудников требует руководителя, который разбирается в предмете и сопереживает им в их усилиях.
Следует также отдавать себе отчет в том, что реорганизации редко позволяют что-либо починить. Они скорее убирают барьеры, передавая в единое подчинение группы, которые до того плохо друг с другом взаимодействовали. Но это означает, что большинство реорганизаций также создают барьеры – между теми группами, которые раньше находились в общем подчинении, а теперь нет.
Перемещение службы эксплуатации ИТ по организационной диаграмме и передача ее в подчинение операционному директору – шаг не более и не менее логичный, чем оставить ее на прежнем месте. Что касается реструктуризации службы эксплуатации ИТ, то разбить ее на части и объединить получившиеся части с бизнесом – это не решение. Технари, работающие совместно над общими проблемами – это то, что следует ценить.
Что же надо поменять? Путь указывает DevOps. Культуру совместной работы в стиле DevOps необходимо распространить на взаимодействие между службой эксплуатации ИТ и остальными операционными службами, между менеджерами, которые хотят лучше делать свою работу, и ИТ-приложениями.
Поэтому снимите оковы с сотрудников хелпдеска. Без SLA, приковывающих их к стульям, вы сможете сподвигнуть их на то, чтобы встать, встретиться с сотрудником, у которого возникла проблема, разобраться с ней, подсказать ему как лучше использовать имеющиеся технологии.
Кроме того, необходимо скорректировать аджайл применительно к службе эксплуатации ИТ. Сегодня аджайл нацелен на то, чтобы выпустить продукт, а не на совместную работу с целью произвести изменения в бизнесе. Корректировка заключается в добавлении в аджайл практики DevOps – в команду, нацеленную на бизнес-результаты, необходимо включить системных администраторов и специалистов по безопасности. Результаты проектов улучшатся, а служба эксплуатации ИТ станет лучше понимать что имеет значение для бизнеса, и благодаря этому повысит свою эффективность.
Давайте введем новый термин, чтобы узаконить такую практику. По аналогии с DevOps, означающим смешение и совместную работу ИТ-служб, отвечающих за разработку и эксплуатацию, давайте будем называть BusOps смешение и совместную работу службы эксплуатации ИТ и бизнес-операций.
Согласно Сунь Цзы, сражение всегда идет за сердца и умы. Часто оно часто начинается с правильного слова. Добавьте его, и вы удивитесь – в хорошем смысле – тому, что за этим последует.
Обсудить