 |
|
|
|
Построение каталога сервисов
Построение каталога сервисов Первый вопрос, на который следует дать ответ перед тем, как приступать к построению каталога сервисов, – цель его построения. Как это ни странно, в большинстве случаев четкий ответ на этот вопрос получить довольно сложно, особенно от представителей бизнес-руководства. Туманные фразы про «повышение управляемости» и «гарантию улучшения качества обслуживания основных подразделений», безусловно, говорят о том, что произносящий их знаком или с ITIL, или с принципами сервисного обслуживания, но не дают конкретного ответа. Между тем именно от цели построения каталога сервисов зависят некоторые тонкие моменты, связанные с его построением и использованием. Рассмотрим некоторые цели, которые может преследовать построение каталога услуг:
В любом случае вне зависимости от декларируемой цели каталог сервисов позволяет:
Таким образом, построенный, эксплуатируемый и поддерживаемый каталог сервисов – это шаг к предвосхищению проблем, связанных с ИТ, и, как следствие, к снижению бизнес-рисков. В частности, при построенном каталоге услуг и внедренном процессе управления проблемами (в терминах ITIL) можно связать поступающие инциденты с конкретным сервисом и таким образом выявлять связанные с сервисом проблемы до их массового проявления. Для того чтобы избежать непонимания, определим понятие «сервис» как конкретную услугу, предоставляемую пользователю, имеющую под собой конкретные инфраструктурные составляющие и обладающую определенной полезностью, как минимум, для одного пользователя. Сервисы для ITIL (процесса управления уровнем сервиса) В случае когда каталог сервисов строится для целей внедрения процесса управления уровнем сервиса, необходимо проанализировать те сервисы, которые ИТ предоставляет бизнесу, в первую очередь с точки зрения пользователя. В частности, для построения подобного каталога рассматриваются типовые роли пользователей в организации (с точки зрения ИТ-сервисов – каждая роль должна обладать уникальным набором составляющих сервиса), и выделяются предоставляемые им сервисы. При этом сервис может быть представлен как конкретным программным, аппаратным или программно-аппаратным средством, так и их набором. Рассмотрим пример. Предположим, что в процессе построения каталога сервисов были выделены следующие роли пользователей: директор, бухгалтер, менеджер (следует не путать понятие «роль» и «должность» – в рассмотренном примере роль «директор» может соответствовать директору, его заместителям и помощникам, роль «бухгалтер» – сотрудникам бухгалтерии и экономистам, и т.д). Предположим, что вся почта организации проходит через один почтовый сервер и используется один сетевой принтер. При этом каждая из ролей характеризуется определенным, уникальным в рамках организации, набором ПО и используемых аппаратных средств (этот критерий является основополагающим при проведении ролевого разделения пользователей). Попробуем описать составляющие сервиса для роли «бухгалтер». Бухгалтер использует «1С» и ПО банк-клиент; он отправляет и получает электронную почту без доступа к ней через Интернет; он формирует отчеты для руководства и смежных подразделений, которые выкладывает в сетевую папку; он использует ПК под управлением Windows с пакетом офисных программ Microsoft Office. Кроме того, ему доступны сетевая печать, офисная телефония и факсимильная связь. Для этой роли можно выделить следующие сервисы:
Аналогично выделяются сервисы и для других ролей. После того как описаны все сервисы для всех ролей, их целесообразно свести в таблицу, которая будет давать представление о доступности того или иного сервиса для той или иной роли, а также о параметрах сервиса, то есть о некоторых его параметрах, характеризующих уровень, с которым данный конкретный сервис предоставляется данному конкретному сотруднику. Возвращаясь к рассмотренному примеру, предположим, что основными инструментами работы для роли «бухгалтер» являются «1С», банк-клиент и, разумеется, ПК. В случае нарушения работоспособности этих сервисов в этой роли ее работа будет парализована; следовательно, в качестве параметров этих сервисов для этой роли должно стоять минимально возможное время восстановления, которое может гарантировать ИТ, а сами эти сервисы признаны критичными для данной роли. Кроме того, выделенные нами сервисы не могут функционировать без сервиса «ПК с базовым набором ПО», что в рассмотренных нами условиях также приравнивает этот сервис к выделенным ранее критичным сервисам. Сервисы для процесса управления инцидентами В этом случае, так же как и в рассмотренном ранее случае, каталог сервисов может быть построен «с точки зрения пользователя», с тем отличием, что для каждого конкретного сервиса не определяются его метрики качества с точки зрения поддержки сервиса, и сами сервисы могут быть заменены на обеспечивающее ПО либо конфигурационную единицу, а роли пользователей быть либо не определены, либо совпадать с должностью. При этом под «метриками качества с точки зрения поддержки сервиса» понимаются не параметры, характеризующие качество предоставления сервиса (например, скорость доступа в Интернет, гарантированную пропускную способность локальной сети), а качество поддержания сервиса, т.е. время, в течение которого сервис при наличии внештатных ситуаций будет гарантированно восстановлен. Такой подход противоречит ITIL, но хорошо работает в небольших организациях, когда во главу угла ставится не формализованное исполнение процедур поддержки, а баланс между эффективностью работы ИТ и усилиями, направленными на достижение этой эффективности. Например, при подобном подходе в небольшой организации могут быть выделены следующие «сервисы»:
С точки зрения ITIL подобное смешение недопустимо, но с точки зрения удобства работы конкретного исполнителя подобное разделение (до определенного объема инфраструктуры) выглядит оправданным. Следует отметить, что в ITIL не сказано о том, какими принципами стоит руководствоваться при проектировании каталога сервисов для обеспечения процесса управления инцидентами – достаточно любым доступным способом идентифицировать проблему, возникшую у пользователя, например, описать ее произвольном виде, и все. Рассмотрим пример. Предположим, что в организации работают 15 сотрудников, каждый из которых имеет доступ в Интернет, использует Windows и OpenOffice, два пользователя используют «1С». В организации имеются 2 сервера – шлюз и файловый под управлением Linux. В этом случае «каталог сервисов» может выглядеть либо так, как приведено в рассмотренном выше примере, либо вообще отсутствовать, а при обращении пользователя ИТ-специалист фиксирует проблему «со слов пользователя», после чего сервис не определяется, а просто исправляется повреждение. С точки зрения управления ИТ-инфраструктурой этот случай вялятся наихудшим, поскольку не дает возможности точно указать, какая именно услуга выведена из строя. Например, записанная со слов пользователя авария сервиса «электронная почта thrunderbird» из рассмотренного выше примера может иметь причиной аварию на почтовом сервере под управлением Linux и затрагивать всех пользователей. Каталог услуг для бизнес-руководства Построение каталога услуг для бизнес-руководства – это процесс, напоминающий построение каталога для целей процесса управления инцидентами, с той разницей, что для бизнес-руководства имеет смысл иногда вводить более высокий уровень абстракции, поскольку его, как правило, интересуют обобщенные показатели. На практике при построении каталога сервисов обычно вводят двухуровневую модель сервиса. На первом уровне такой модели находится так называемый пользовательский сервис, на второй – обобщенный. В примере, рассмотренном в подразделе «Сервисы для ITIL», обобщенными сервисами будут являться:
Подобный подход является несколько искусственным в том смысле, что для повседневной работы конкретного ИТ-специалиста он не имеет никакой практической ценности. Зато для целей предоставления бизнес-руководству сводных показателей по обобщенным сервисам он имеет, как минимум, одно весьма прагматической применение: как правило, решения о материальном поощрении сотрудников ИТ принимаются руководством на основании отчета, построенного по обобщенному каталогу. В такого рода сводный отчет обычно включают обобщенные сервисы, количество отказов по ним и среднее время восстановления – плановое и фактическое. Кроме того, подобный отчет может являться обоснованием для введения в бюджет следующих периодов расходов на модернизацию инфраструктуры, поддерживающей сервис. Одновременно с таким отчетом для руководства ИТ, как правило, выпускается отчет, содержащий полный перечень всех сервисов, количество обращений и инцидентов по ним по каждом подразделению, среднее плановое и фактическое время восстановления. Таким образом, получается достаточно логичная схема: руководство каждого уровня получает соответствующий своему уровню интереса отчет, на основании которого принимаются управленческие решения. Параметры сервисов Следующий шаг, который необходимо сделать после построения каталога сервисов, – определение для каждого сервиса его характеристик, или параметров доступности сервиса. При этом, разумеется, рассматривается лишь случай, при котором каталог сервисов строится для целей внедрения процесса управления уровнем сервиса в рамках ITIL и отчасти для случая, когда каталог сервисов строится для бизнес-руководства. Дело в том, что при внедрении каталога сервисов для процесса управления инцидентами параметры сервисов однозначно определить невозможно, поскольку сервисы в этом случае могут представлять собой не только «сервисы», но и абсолютно не относящиеся к ним сущности. Рассмотрим пример, приведенный в разделе «Сервисы для ITIL», с точки зрения параметров сервиса. В примере мы выявили ряд сервисов для одной из ролей, определили, что часть из этих услуг является критичными. Предположим, что отдел ИТ готов гарантировать для каждого конкретного сервиса следующее время его полного восстановления безотносительно к роли:
Таким образом, для роли «бухгалтер» сервисы доступа к «1С» и «банк-клиент» будут иметь время восстановления 4 часа, а, например, для роли «менеджер» сервис доступа к «1С» будет иметь время восстановления 8 часов (а сервис «банк-клиент» может отсутствовать). Аналогично, исходя из технологических возможностей отдела ИТ и требований бизнеса, определяются параметры всех остальных сервисов. Следует отметить следующее: время восстановления сервиса – это не время гарантированного простоя. Это то время, за которое отдел ИТ гарантирует полноценное восстановление сервиса. Таким образом, время восстановления, например, сервиса «1С» в 4 часа для конкретного сотрудника не означает того, что сотрудник, у которого неработоспособен «1С», может рассчитывать на то, что в течение 4 часов сервис не будет предоставляться. В зависимости от текущих задач специалисты ИТ могут восстановить сервис как через полчаса, так и через три. Возникает закономерный вопрос: если для различных ролей время восстановления, определяемое по возможностям ИТ, одинаковое, то почему тогда для разных ролей оно определяется различно? Ответ на этот вопрос лежит в требованиях бизнеса к параметрам конкретных сервисов – время восстановления сервиса будет тем меньше, чем больше необходимость роли в использовании этого сервиса для осуществления своих должностных обязанностей. Типичная ошибка, которую допускают на этапе определения параметров сервисов, – при составлении каталога сервисов время восстановления сервиса определяют без оглядки на возможности ИТ выдержать это время. В результате при первом же серьезном сбое выявляется несостоятельность такого распределения: например, время восстановления в 1 минуту можно гарантировать, имея отказоустойчивый кластер, но не сервер с ежечасным бэкапом баз данных и т.д. Определение, фиксация и выдерживание отделом ИТ заявленных параметров для каждого сервиса позволяет, во-первых, дать бизнес-подразделениям возможность планирования своих рисков, во-вторых, провести четкую взаимосвязь между инвестициями в ИТ и параметрами предоставляемых сервисов, в-третьих, предоставляет возможность оперативного планирования работы сотрудниками в случае нарушения какого-либо сервиса и, наконец, позволяет косвенно решить извечный вопрос об эффективности работы ИТ: параметры предоставляемых бизнес-подразделениям сервисов являются хорошим индикатором того, насколько оперативно способен работать отдел ИТ. Что дальше Предположим, что в конкретной организации каталог сервисов построен и внедрен, т.е. выделены и описаны сервисы, определены роли пользователей и для каждой роли определены параметры всех предоставляемых ей сервисов. Внедрение каталога сервисов может быть выполнено различными способами: от приказа по предприятию до декларации службы ИТ, зафиксированной, например, на внутреннем портале или в файле на общедоступном ресурсе – все зависит от размеров предприятия и ИТ-службы. При этом надо не забывать, что единственный критерий внедрения – то, что каталог используется в повседневной работе ИТ. При этом если используются автоматизированные средства для организации работы ИТ (системы класса helpdesk/servicedesk), то при наличии в них модуля SLA каталог сервисов может вестись и использоваться непосредственно в них, в противном случае для каждого конкретного случая время восстановления сервиса приписывается в каждый зарегистрированный инцидент вручную. После того как каталог сервисов внедрен, дальнейшая работа службы ИТ будет строиться, во-первых, вокруг поддержки актуальной версии этого каталога, а во-вторых, вокруг улучшения самих сервисов. Не исключая при этом, разумеется, текущую работу ИТ-специалистов, ориентированную на выдерживание конкретных параметров конкретного сервиса и решение текущих задач. Поддержка каталога сервисов включает в себя периодические ревизии каталога на предмет выявления уже непредоставляющихся сервисов или введения в него новых, неописанных сервисов. Подобные ревизии позволят поддерживать каталог сервисов в актуальном состоянии. Текущая работа ИТ-специалистов в условиях жестких временных рамок, которые накладывает на решение того или иного инцидента уровень предоставляемого пользователю сервиса, безусловно, будет отличаться от работы в «свободном стиле». Во-первых, специалисты, задействованные на поддержке пользователей, обязаны будут выдерживать контрольные сроки, заявленные в качестве параметра сервиса. При этом скорее всего количество специалистов, обслуживающих тот или иной сервис (или ряд сервисов), не изменится, и они, работая, с одной стороны, над своей текущей работой, с другой – над поддержанием заявленного уровня сервисов, и с третьей – над улучшением сервисов, оказываются перед выбором – либо расширять свой коллектив, либо модернизировать инфраструктуру (одно, кстати, не исключает другое и связано обычно с ростом компании). В свою очередь модернизация инфраструктуры приведет к внедрению более прогрессивных технических решений, нацеленных на предоставление более качественного и отказоустойчивого сервиса пользователю: например, использование отказоустойчивого кластера сервера баз данных вместо RAID-массива дисков на одном сервере, онлайн бэкапирование всей почты и использование механизмов быстрого восстановления почтового сервера (DVD с образом системных разделов почтового сервера) вместо ежечасного копирования накопившейся за это время почты и т.д. Отдельно стоит упомянуть такую вещь, как стимул специалистов ИТ к улучшению сервисов. В нарисованной выше картине улучшение происходило как бы само собой – следуя из логики развития событий. В реальной жизни все несколько иначе. В частности, у конкретных ИТ-специалистов в рамках нарисованной картины нет стимула к улучшению сервиса, поскольку такое улучшение банально не отражается на их заработной плате. Для того чтобы заинтересовать специалистов делать свою работу быстрее и качественнее, можно ввести «стимулирующие премии», т.е. поощрения за выполнение быстрее установленных параметров для тех или иных сервисов. Правда, встречаются случаи, когда основной бизнес вполне устраивает ситуация, при которой заданные параметры сервисов выдерживаются по граничным условиям – и в этом случае обосновать премии «за перевыполнение» перед руководством бывает весьма проблематично. Кроме того, улучшение сервиса – это не только премии, но и определенный бюджет (оборудование, лицензии, работы), который необходимо получить от того же основного бизнеса. И в этом аспекте ситуация не отличается от ситуации с премированием: бизнес может выделить бюджет, а может и не выделить – все зависит от того, насколько его потребности в ИТ перекрыты текущим уровнем предоставляемых сервисов. Очень многое, если не все, зависит от позиции руководства по отношению к информационным технологиям. Тем не менее позицию руководства можно (и нужно) попытаться изменить. ITIL в целом и каталог сервисов в частности позволяют вести учет таких параметров, как время решения инцидентов, соотнесенное с конкретным пользователем, группой пользователей (объединенных по какому-либо признаку: например, это могут быть сотрудники одного отдела или пользователи, играющие одну и ту же роль по отношению к ИТ) и предоставляемым сервисом. Такого рода показатели, предоставляемые руководству на регулярной основе в виде отчетов, позволят на основании фактов обосновать премирование сотрудников ИТ. В любом случае когда проводится работа по улучшению сервисов, достигается двойной эффект: с одной стороны, улучшается сервис, предоставляемый пользователю, а с другой – повышается общая надежность ИТ-инфра-структуры. Кроме того, с улучшением сервиса повышается и общая удовлетворенность пользователей работой ИТ-службы. Вместо послесловия Тема построения и поддержки каталога сервисов практически неисчерпаема, и формат статьи не позволяет рассказать обо всех нюансах и тонких моментах, связанных с этими процессами, например, о планировании оборудования, резерве мощностей, связанных процессах ITIL, направленных на обеспечение поддержки уровня сервиса. Тем не менее приведенной информации вполне достаточно для того, чтобы сделать первые шаги. А там... дорогу осилит идущий. |
Александр БашкировКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
