Известный консультант Боб Льюис публикует руководство по выживанию ИТ-директора. Как ИТ-директор, вы во многом занимаетесь дизайном, и это тогда, когда вы не контролируете других людей, которые разрабатывают материал. Или, когда вы не следите за тем, чтобы все, что вы разрабатываете, подходило друг другу так, как должно. Есть несколько универсальных правил, которые управляют хорошим дизайном независимо от того, что разрабатывается. Самым известным, вероятно, является изречение великого архитектора Луиса Салливана о том, что форма следует за функцией.

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

Из очереди в очередь: скрытое узкое место процесса

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

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

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

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

Каждый шаг процесса управляется как очередь "первый вход - первый выход" (FIFO). Команды работают с запросами только тогда, когда запрос прошел через очередь и был отправлен на обработку. Общее усилие такое же, как и при просмотре от коробки к коробке. Но время цикла включает в себя как рабочее время, так и время в очереди — для этого смоделированного процесса на пять дней больше или меньше. Фактический анализ более сложен, чем этот. Обычно один шаг оказывается узким местом; работа накапливается в своей очереди, в то время как другие очереди иссякают, что уравновешивается тем, что все очереди получают запросы более чем из одного источника. Но это не меняет принципа, только сложность моделирования.

Это реальность, а не просто теория. Не так много лет назад клиент, размеры очереди которого были немного больше, чем показано выше, столкнулся с многомесячными задержками проекта. Это было связано с тем, что команды ждали установки утвержденных серверов, от которых они зависели, хотя обычный сервер требовал не больше усилий для приобретения, настройки и установки, чем то, что изображено выше. Первопричина? Менеджеры, ответственные за закупки, сетевое администрирование, установку программного обеспечения, обеспечение качества и развертывание, организовали работу своих отделов таким образом, чтобы максимально использовать персонал и увеличить пропускную способность.

Они — части — оптимизировали себя за счет каждого проекта в целом.

Устранение внешних факторов

Решение, которое приверженцы DevOps сразу же распознают и примут, заключалось во включении аналитиков ИТ-инфраструктуры в основную проектную команду и, что еще более важно, во включение задач инфраструктуры, таких как настройка серверов, в рабочий план каждого проекта, назначение дат начала и сроков выполнения, исходя из того, когда их рабочие продукты будут необходимы. С этим изменением сборки серверов стали частью графика проекта, а не внешними факторами, над которыми руководитель проекта не имел никакого контроля. В обмен ИТ-директор должен был согласиться с тем, что для того, чтобы проекты давали свои результаты вовремя и в рамках своих бюджетов, остальной ИТ-организации пришлось бы допустить некоторую слабину в управлении своей работой. Целевые показатели использования персонала не будут и не должны даже приближаться к 100%. (Совет профессионала: Потратьте некоторое время на изучение методологии управления проектами критической цепочки Элиягу Голдратта, чтобы более глубоко понять этот момент.)

Крах MBO

Проблема оптимизации / субоптимизации относится не только к проектированию процесса. Возьмем, к примеру, вознаграждение руководства. В свое время управление по целям (MBO - Management by Objectives) было популярной теорией о том, как получить максимальную отдачу от организации, получая максимальную отдачу от каждого менеджера в организации. Его фатальным недостатком была также неспособность признать неизбежные, но непреднамеренные последствия оптимизации частей в ущерб целому. 

То, как это сработало — точнее сказать, не сработало — заключалось в том, что, как следует из названия, руководители компании поставили перед каждым менеджером одну или несколько целей. Менеджеры, получив более четкое представление о том, чего они должны были достичь, приступили к выполнению этого с маниакальным рвением. При этом - не отвлекаясь на то, что было необходимо любому другому менеджеру в организации для достижения их собственных целей. Современные организации, которые страдают от того, что их обитатели называют “изолированным мышлением” с неспособностью сотрудничать, являются пережитками эпохи MBO.

Беспомощно помогая службе поддержки

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

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

К сожалению, такой подход также гарантирует, что аналитики службы поддержки никогда не научатся справляться с подобными проблемами в будущем. И хотя это также снижает затраты службы поддержки, это делается за счет отвлечения более дорогостоящих специалистов от их текущего набора приоритетов, которые, с точки зрения общей ценности, вероятно, более важны. Оптимизация службы поддержки в итоге превращается в упражнение по неограниченному перераспределению затрат и ответственности. Общая стоимость управления инцидентами увеличивается пропорционально тому, насколько снижаются собственные расходы службы поддержки. Чтобы оптимизировать целое, вы должны отказаться от оптимизации части. Это руководство может показаться не вполне конкретным и прагматичным, но не позволяйте его эзотерическому подтексту сбить вас с толку. Если вы хотите добиться наилучших результатов, убедитесь, что все, кто участвует в достижении этих результатов, знают, какими они должны быть. Также то, что никто не будет наказан за сотрудничество в их реализации.