Обычно, когда речь заходит об ITSM (Information Technologies Service Management), человек, плохо знакомый с информационными технологиями, отмахивается: «Что вы, это не для меня, в этом пусть “айтишники” разбираются». Однако Марина Аншина, директор департамента ИТ ОАО «СИБУР — Русские шины», считает, что такая модель построения сервисной службы как раз и может наконец осветить для руководителя предприятия «темное царство» — работу его собственного отдела ИТ.
Intelligent Enterprise: Не секрет, что для топ-менеджмента информационные технологии обычно представляются совершенно закрытой областью. Хотя необходимость их использования понимает, наверное, каждый руководитель, но часто на интуитивном уровне. ITSM же, как правило, воспринимается им как нечто бесконечно далекое, сложное и нужное лишь самому ИТ-отделу.
Марина Аншина: Напротив, ITSM — это одна из моделей, которая позволяет помочь руководителю предприятия понять, что именно ему могут предоставить ИТ, сколько это будет стоить, как это реализуется и куда обращаться с вопросами. И в этом смысле для него сервисная модель построения ИТ наиболее проста. Я даже думаю, что аббревиатуру ITSM можно трактовать несколько по‑иному — IT Simple Model, то есть «простая модель ИТ». Конечно, это не означает, что она примитивна. Суть в том, что использование сервисного подхода сильно упрощает взаимодействие ИТ и бизнеса.
Ведь если говорить с руководством о серверах, локальной сети и программном обеспечении, вряд ли стоит ожидать интереса и понимания. Поэтому я люблю использовать модели и сравнения. Попробую объяснить концепцию ITSM и ITIL на примере варки каши.
Допустим, я, мать семейства, предоставляю своей семье сервис — варю утром кашу. В этой ситуации, если каша пригорела, возникает инцидент. Ведь есть ее теперь нельзя, семья остается голодной, волнуется, ругается. У меня появляется повод задуматься, почему это произошло, — вроде варила как всегда, не отлучалась. На основании одного или нескольких таких инцидентов выявляется проблема — неисправность терморегулятора. Возникает необходимость в изменениях, то есть нужно поменять терморегулятор. Теперь мне нужно идти в магазин за новым терморегулятором. Но если у нас с соседями одинаковые плиты, мы можем, чтобы каждый раз не выяснять модель терморегулятора и не бегать за ним в магазин, просто держать какое‑то количество этих деталей в общем шкафу. Вот так, если говорить упрощенно, в ITIL возникают процессы управления инцидентами, проблемами, изменениями и конфигурациями.
Но тут возникает вопрос: «А почему вы решили, что каша не может пригореть?» Я рано встаю, ухожу на работу, не высыпаюсь — имею право не уследить. Но если каша будет пригорать постоянно, семье это, конечно, не понравится. Нужно договориться, что, к примеру, каша будет пригорать не чаще трех раз в месяц. Тогда четвертый — это уже нарушение договора. Так появляется управление уровнем обслуживания (Service Level Management — SLM).
Однако может оказаться, что я все сделала правильно, плита работает исправно, но каша вдруг получилась кислой. Выясняется, что молочник продал мне кислое молоко. То есть сервис варки каши предоставляю я, но мне, с другой стороны, сервис поставки молока предоставляет молочник. И мне с ним тоже нужно заключить соглашение об уровне обслуживания (Service Level Agreement — SLA). При этом понятно, что уровень обслуживания, предоставляемый мне поставщиком (молочником), должен быть не ниже того, который я обещаю своим пользователям (семье).
Так же, на примере варки каши (как, впрочем, и на многих других примерах сервисного обслуживания), можно объяснить и другие процессы ITSM. Как видите, все довольно просто и обыденно. Но как всегда, чтобы сделать что‑то проще, кто‑то должен сильно постараться, и в данном случае речь идет об отделе ИТ.
Существует мнение, что в кризисное время не до процессного управления ИТ — вполне достаточно должностных инструкций и обычного здравого смысла…
Я категорически не согласна. Кризис или нет, у пользователей и руководства существует вполне обычное желание — получать от ИТ качественный сервис. Причем их удовлетворенность на самом деле зависит вовсе не от широты спектра предложений ИТ и даже не от их уровня, а прежде всего от того, насколько предложенное соотносится с их ожиданиями. Именно так обычно оцениваются услуги и даже товары, которые мы приобретаем. Ведь само по себе их качество не всегда имеет большое значение. Не секрет, что многие функции текстовых редакторов, например, обычным пользователям вовсе не нужны.
И ITSM как раз помогает выстроить работу ИТ таким образом, чтобы она максимально соответствовала потребностям пользователей. Во-первых, пользователь хочет знать, что он получает. Очень часто пользователь бывает недоволен ИТ, потому что просто не знает, что хочет и может получить. Поэтому ИТ-отдел должен составить для пользователя спецификацию — договор об уровне предоставления сервиса.
В дальнейшем уровень услуг должен соответствовать этой спецификации. Разумеется, их стоимость должна соответствовать качеству, которое хочет получить бизнес. То есть необходимо управление уровнем предоставления сервиса. При этом хорошо известно, что качество во многом определяется постоянством. Если сегодня уровень услуг высок, а завтра сотрудники ушли в отпуск, и какой‑то сервис стал на порядок хуже, то вряд ли пользователи будут довольны. Поэтому нужно наладить управление конфигурациями и изменениями. Ну и наконец, пользователь должен знать, что делать в случае возникновения проблем. В этом ему всегда сможет помочь служба технической поддержки (Help Desk).
Да, тяжелое экономическое положение заставило урезать бюджеты, и не только на ИТ. И в этой ситуации, когда проектная деятельность, по не зависящим от нас причинам, очень сократилась, самое время обратиться к процессам. Раньше на это оставалось гораздо меньше времени, и деятельность организации могла уподобиться лодке, в которой с одной стороны сидят сильные гребцы, а с другой — слабые. Процессы просто не поспевали за проектами. В итоге, как можно догадаться, далеко в такой лодке не уплывешь.
Тема эффективности работы ИТ сейчас очень актуальна. ИТ-бюджеты повсеместно урезаются, при этом требования к качеству сервиса со стороны бизнеса, как правило, ниже не становятся. Как в этом случае соответствовать ожиданиям пользователей?
Да, вопрос соответствия качества цене довольно сложен, особенно в настоящих условиях. Существует общеизвестный «треугольник качества», где качеству соответствует одна вершина, а в двух других углах находятся стоимость и время. Понятно, что если бизнес требует сократить затраты, то соответственно либо что‑то будет выполняться дольше, либо ухудшится качество. Возвращаясь к SLA на примере каши, можно предположить следующие варианты: ухудшится качество предоставления сервисов — каша будет пригорать не один раз в месяц, а, допустим, пять, несколько снизятся требования к самой каше — можно крупу или молоко похуже купить, и т. д. Достаточно часто руководство на это идет. Многие проекты, финансирование которых было сокращено, мы вынуждены были делать дольше, но соответственно с меньшими затратами, и это сразу оговаривалось с руководством компании.
Но на самом деле, так как процессы редко бывают отлажены идеально, «треугольник качества» можно преобразовать в ромб, добавив в четвертом углу эффективность. Во многих компаниях, к сожалению, эффективность ИТ пока не оптимальная — четко видно, где еще можно «подкрутить» — при неизменных стоимости и времени предоставлять сервисы лучшего качества. Этим и пытаемся заниматься. Поэтому, особенно в нынешних условиях, не стоит забывать про четвертый угол.
Многое, конечно, зависит и от наших поставщиков, потому что уровень предоставляемых нами услуг и их стоимость основывается на договорах с ними. При этом важна и обратная связь. Мы постоянно работаем с поставщиками — программного обеспечения, услуг, оборудования, — пытаясь, с одной стороны, повысить качество, а с другой — сократить расходы. Как это можно сделать так, чтобы не потопить поставщика? Попытаться заставить его использовать «четвертый угол».
Хорошо, предположим, компания решила использовать процессный подход к управлению ИТ. Какие шаги ей предстоит пройти?
Прежде всего нужно определить процессы. Потому что ни для руководства, ни для пользователей, ни даже для рядовых ИТ‑специалистов они обычно не являются очевидными. Дальше нужно их спроектировать, сформировать, выстроить и контролировать с помощью сбалансированной системы показателей (баланс: качество, цена, время). Желательно, естественно, чтобы эти показатели в большинстве своем были числовыми. Но иногда приходится довольствоваться лишь качественными. Кроме того, процессы нужно постоянно оптимизировать и время от времени кардинально пересматривать. В противном случае они начинают «осыпаться», и происходит это на удивление быстро.
При этом очень важный момент — единая точка ответственности за процесс от начала до конца. Для этого необходимо назначить владельца процесса. По своему опыту могу сказать, что если руководители проектов в России уже встречаются практически повсеместно, то владельца обычно найти очень нелегко. И на самом деле, при жестком делении организации на отдельные подразделения бывает сложно понять, откуда его взять. Ведь каждое подразделение отвечает только за свой кусочек процесса. Мне кажется, что можно использовать простой принцип: «кто подвесил — тот и перережет». Например, кто отвечает за процесс управления изменениями? Если запрос пользователя переводит в изменение менеджер Help Desk, то он же и должен его закрывать. Потому что видит процесс от начала до конца. И не столь важно даже, кого именно назначить ответственным за процесс, важнее, чтобы он просто существовал, имел соответствующие права и обязанности, а также желание и возможности управлять этим процессом.
Часто первым внедряют процесс управления инцидентами. Возможно, по той причине, что в этот процесс не столь активно требуется вовлекать руководство и пользователей. Но возникает вопрос, о котором я уже говорила на примере каши: «Как можно говорить про инцидент, если нет договора об уровне обслуживания?» Может быть, не работающая день корпоративная почта — это нормально для компании, а сбой какого‑то сервера никто и не заметит (впрочем, это повод задуматься о разумности инфраструктуры). Поэтому для начала стоит определить, что же именно является инцидентом и какие сервисы мы предоставляем пользователям. Кстати, а знают ли они, какие?
Ведь распространенная ошибка при разработке процессов ИТ — вести проект исключительно внутри службы ИТ. Но, говоря о сервисах ИТ, мы ведь имеем в виду тех, для кого строим, поддерживаем и развиваем ИТ-процессы. Хотя, конечно, можно пошутить, что если бы не было пользователей, все ИТ работали бы замечательно.
До сих пор мы все‑таки больше говорили об ИТ-процессах. А оказывает ли внедрение сервисного подхода какое‑то влияние непосредственно на бизнес?
Современный бизнес очень сильно зависит от ИТ. Поэтому любой инцидент способен привести к серьезным проблемам: остановить производство или отгрузки, ухудшить качество продукции, оттолкнуть клиентов, поставить компанию перед необходимостью платить штрафы. С другой стороны, грамотное и умелое использование ИТ может дать компании огромные преимущества и привести ее к расцвету.
Сервисный подход позволяет сократить количество инцидентов, высвободить время ИТ‑специалистов для выполнения проектов и инициатив, подготовки предложений и развитию компьютерной грамотности пользователей. Я считаю, что сервисный подход — это основа ИТ на предприятии, тот фундамент, на котором можно построить развитие компании. А без этого тыла самые амбициозные проекты обречены на провал. Я часто слышала, что при использовании сервисного подхода ИТ-отдел воспринимают как обслугу. Однако при использовании модели ITSM никоим образом не подразумевается такое отношение к ИТ. Понятно, что мы предоставляем определенные сервисы, но при этом на нас лежит задача их развития, предоставления в большем объеме и лучшего качества, потому что вряд ли кто‑то это сделает за нас.
Мы видим «изнанку ковра» нашей компании, что в непростых экономических условиях имеет большую ценность. Следуя той же терминологии, очень важно вовремя подвязать ниточки или какие‑то из них заново протянуть. Потому что проблем очень много, и чем быстрее бизнес получает информацию об этих проблемах, тем скорее последует его успешный выход из кризиса.
Кроме того, ИТ-отдел — это подразделение, которое работает практически со всеми сотрудниками компании. Поэтому от нашей работы во многом зависит психологическая обстановка в коллективе. В данной непростой ситуации эту роль у нас никто не отнимал, и потому очень важно то, о чем я говорила: соответствовать ожиданиям; определять, что мы предоставляем; объяснять, почему, например, ухудшилось качество или изменилось время выполнения тех или иных запросов. То есть быть открытыми и поддерживать своих пользователей — не только с точки зрения ИТ, но и морально. Особенно это касается подразделения поддержки, которое теснее всего взаимодействует с пользователями.
Кроме того, многие процессы ITSM, например управление изменениями, могут быть использованы другими подразделениями. Когда я представляла этот процесс нашему руководству, первая реакция была: «Почему только в ИТ? Разве у нас в других отделах нет изменений? Процесс, о котором вы рассказали, вполне применим и там».
Поэтому хоть ITSM и «simple», но в нем есть масса скрытых возможностей, которые еще ждут своего часа.
ИТ-инструмент жизненно необходим
Алексей Николаев,
начальник отдела систем управления компании «Инфосистемы Джет»ИТ, как объект управления, включает в себя три основных составляющих — технологии, процессы, людей. При внедрении процессов ITSM, помимо выстраивания собственно процессов и обучения людей новым методам работы, важно уделить внимание и выбору соответствующих средств автоматизации. Сегодня в большой организации успех внедрения ITSM без поддержки автоматизированными средствами представляется сомнительным — это похоже, если попытаться продолжить метафору автора статьи, на ежедневное использование костра для приготовления пищи и собственной руки в качестве терморегулятора. Малоэффективно и неприятно.
Реализация подхода ITSM — это всегда изменения. Любые изменения болезненны как для людей (руководителей и исполнителей), так и для организации в целом. Правильно выбранные средства автоматизации помогут руководителям ИТ, владельцам и менеджерам процессов — в первую очередь оповестят о проблемах в реализации или функционировании процессов. Кроме того, их использование позволит упростить переход исполнителей к новым практикам работы, а значит, уменьшить вероятность возникновения ошибок. Внедрение сопутствующих средств автоматизации задач инвентаризации или мониторинга (ведь система мониторинга могла бы предупредить нас о неработающем терморегуляторе еще до нарушения уровня сервиса) позволит ИТ‑службе стать более эффективной и повысить уровень зрелости процессов ITSM. А в результате — получить максимальный эффект от перехода к сервисно, а на самом деле бизнесориентированному подходу. Это значительно упростит переход к ITSM.
