Качественно. Гарантированно. Айтишно

Есть на свете такое понятие — качество. Все, кто так или иначе застал СССР, наверняка помнят, что среди простого народа термин «качество» ассоциировался в первую очередь с японским магнитофоном, польской одеждой, чехословацкой люстрой. Потом СССР не стало, и постепенно слово стали прикладывать ко всем более-менее подходящим понятиям: качество изделий, качество сервиса и т.д. Причем, что примечательно, эти термины также активно используются среди «простого люда». Собственно, о качестве как таковом (применительно к ИТ) и пойдет речь.

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

На практике для ИТ в подавляющем большинстве случаев определяют одну–две метрики, что-то типа «времени реагирования на запрос» и «количества сбоев приложений». И все. Точнее, все, что так или иначе лежит вне этих метрик, или не рассматривается вообще, или рассматривается как второстепенный фактор. И, кстати, что-то в этом есть. Но только «что-то», потому что если следовать этой концепции «от и до», то в итоге получится полная бюрократия. «У меня есть свой участок работы, свои KPI я отрабатываю, а все, что вокруг, меня не касается. Если что — пишите заявку». Есть, правда, и оборотная сторона медали: если постоянно идти на поводу у пользователя, то понятие «качество» будет трансформировано в «угодничество» (вспомнишь СССР, и лексика соответствующая сразу всплывает). Как следствие, то качество, за которое боролись, начинает рассыпаться. Превращаясь в противоположность. Потому что на обслуживание одного запроса начинает тратиться непропорционально много времени, излишняя «забота» начинает сказываться на продуктивности, и, как следствие, падает общая эффективность.

В общем, получается, что истина, как обычно где-то посередине: понятие «качество» всегда лежит в узком коридоре между бюрократией и жизнью «по понятиям» (применительно к ИТ, естественно). Тем не менее, хотя задача обеспечения качества решается в каждом конкретном случае индивидуально, некоторые общие аспекты можно выделить. Например, KPI, подход к обеспечению качества и внедрение полученной модели в жизнь.

Про KPI

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

Первая — это то, на что непосредственно расставляются KPI. То есть, в теории задать можно любые (так же, как и их пороговые значения). Но вот будут ли они работать — большой вопрос. Например, KPI «время простоя информационной системы не более двух часов в год» для небольшого предприятия выглядит, мягко говоря, фантастически (особенно, если система развернута на собственных мощностях), поскольку для обеспечения такого KPI необходимо предусмотреть систему резервирования, быстрого восстановления, и все это в «горячем» режиме, что далеко не всегда укладывается в бюджет. Так что KPI надо проектировать с умом, так, чтобы они были реально выполнимы.

Вторая — попытка регламентировать при помощи KPI абсолютно все (включая работу сотрудников) обычно заканчивается или ничем, или, в худшем случае, резким снижением качества. Потому что в этом случае акцент сотрудников будет не на решении поставленной задачи, а на выполнении KPI. Следовательно, они будут или передавать задачу «по цепочке» по формальному признаку, или стремиться выполнить ее как можно быстрее — не важно, с каким качеством: на первое место в таких случаях выходит формальный факт выполнения.

Третья — очень узкие или наоборот, чересчур широкие KPI (хорошая лазейка для того, чтобы их не исполнять).

Здесь можно сделать небольшое лирическое отступление. Человеческая природа стремится к состоянию покоя (помните знаменитое: «Это у тебя счет в деньгах, а у меня в сутках»). Если у сотрудника будет возможность тем или иным образом обойти KPI, он с большой вероятностью так и поступит (это, разумеется, относится далеко не ко всем, но к большинству). Потому что, с одной стороны, есть объективные обстоятельства; с другой — просто лень; с третьей — спортивный интерес: получился или нет побороть систему? Все это приводит к тому, что над людьми, непосредственно отвечающими за исполнение SLA, метрики которого определены в KPI, приходится выстраивать систему мотивации и контроля. Потому что, к сожалению, самостоятельно контролирующие себя сотрудники встречаются слишком редко.

Крайним случаем рассмотренных выше аспектов является до сих пор встречающаяся ситуация, при которой KPI… «переносят» на пользователя. Внешне безобидные запросы от ИТ (грамотно сформулированные) могут сыграть роль этакого «громоотвода» по формальному признаку. Приведу реальный пример. Пользователь через систему Service Desk жалуется, что у него не работает принтер. ИТ, хорошо зная непростой характер пользователя (у них перманентный конфликт, война, которая ведется с переменным успехом), выдает обратный запрос: «Проверьте, пожалуйста, что указанный принтер присутствует в списке принтеров». И все, стопор. Потому что пользователь не понимает, где список принтеров, что там должно быть написано и т.д. Тем не менее, по сугубо формальному признаку инцидент передан пользователю, и «часы KPI» перестали тикать. Кстати, в реальности, взыскание было наложено именно на айтишников: какой бы ни был пользователь, ИТ создается в том числе для того, чтобы и такого рода пользователям было комфортно работать.

Про процессы

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

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

Второй по списку (но первый по значимости) — процесс мониторинга исполнения SLA. В рамках этого процесса необходимо наладить работу по непрерывному отслеживанию того, насколько хорошо выполняются SLA, и организовать работу по расследованию случаев его нарушения, а также предотвращения возможных нарушений. Процесс в простейшем случае организуется довольно просто: достаточно организовать оповещение заинтересованных лиц при приближении пороговых значений. И в обязательном порядке дать им полномочия на принятие и реализацию оперативных решений по исправлению ситуации. Без этого аспекта весь процесс просто рассыплется, потому что толку от того, что кто-то оповещен, как правило, никакого. Кстати, в рамках этого же процесса должна быть прописана схема эскалации — то есть, если полномочий конкретного человека недостаточно для реализации того или иного оперативного вмешательства, он должен передать проблему на следующий уровень. Вообще, основная направленность процесса мониторинга исполнения SLA в случае нештатных ситуаций (а процесс работает только с такими) — не допустить нарушения SLA… Хочется написать «любой ценой», но это не так. Вернее будет сказать «за разумную цену». Потому что вряд ли кому-то потребуется исполнение SLA точно в срок при цене, превышающей, например, годовой бюджет ИТ.

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

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

Еще один важный момент, о котором необходимо упомянуть, — у каждого процесса должен быть владелец, который, с одной стороны, отвечает за то, чтобы все действия по процессу исполнялись, а с другой — осуществляет общий мониторинг работы процесса («смотрящий за смотрящими», если говорить про процессы обеспечения качества). Но такая, на первый взгляд громоздкая, вертикаль позволяет выстроить действительно качественное предоставление ИТ-услуг. Что само по себе дорогого стоит.

Служба менеджмента качества

Еще один важный вопрос, о котором нельзя умолчать, рассуждая о качестве, — где именно в структуре предприятия должны находиться сотрудники, отвечающие за качество ИТ: «внутри» ИТ или «снаружи», например в службе менеджмента качества. Традиционно «внешняя» СМК считается более «злой» по отношению к ИТ, чем внутренние ресурсы. Я бы сказал, что бывает совершенно по-разному, и порой внутренние ресурсы, отвечающее за качество в ИТ, являются более серьезными, чем внешние. Хотя бы потому, что понимают внутренние связи, возможности и потенциал развития применяемых технологий. И, соответственно, могут спросить с большей строгостью.

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

Наше все, или немного про отчетность

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

Вместо заключения

Управление качеством в ИТ — вещь, простая на верхнем уровне, но сложная на уровне технических решений. Моделирование системы управления качеством в каждом конкретном случае индивидуально (впрочем, тут я не открываю Америку), и модель обеспечения качества зависит как от общих тенденций, так и от конкретных требований в каждом конкретном случае. Внедрение же полученной системы в жизнь почти всегда происходит поступательно, то есть определяются набор и последовательность конкретных шагов, которые необходимо сделать. После чего они претворяются в жизнь. Правда, есть одно «но», которое состоит в том, что человек, как я уже говорил, существо по сути своей инертное. Соответственно, сопротивление среди сотрудников (в первую очередь среди ИТ-специалистов) будет достаточно высоко. Но это, как говорится, вопрос решаемый.

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