Прошу вас уточнить по курсу ITIL. IT Service Management по стандартам V.3.1 вопрос о количестве версий ITIL. |
Эксплуатация услуг как этап жизненного цикла услуг
В табл. 11.2 приведены примеры крайностей двух позиций.
Чрезмерная концентрация на стабильности | Чрезмерная концентрация на реагировании | |
---|---|---|
Позиция |
|
|
Типичные проблемы | IT может демонстрировать соответствие с SOP и OLA, даже если есть явные расхождения с требованиями бизнеса | Персонал IT не может выполнять стандартные процедуры и рутинные работы, так как сконцентрирован на проектной деятельности |
Стратегия развития |
|
|
Технология предоставления услуг | Использование существующей или стандартной технологии предоставления услуг; услуги корректируются для работы в рамках существующих параметров | Избыточное обеспечение. Нет попыток приспособить новую услугу для работы в существующей инфраструктуре. |
Управление мощностями |
|
|
Достижение баланса между стабильностью и быстрым реагированием на изменения требует выполнения следующего:
- финансирование гибких технологий, таких как виртуальные среды;
- построение сильного процесса Управления уровнем услуг(SLM), который будет функционировать на всем жизненном цикле услуг;
- интеграция SLM с другими процессами проектирования для обеспечения корректного отображения требований бизнеса на этап Эксплуатации и компоненты IT-инфраструктуры;
- инициирование изменений на ранних стадиях жизненного цикла услуг с целью совместного управления требованиями бизнеса и IT;
- обеспечить участие IT в изменениях бизнеса на ранних стадиях их осуществления, чтобы IT услуги максимально соответствовали этим изменениям;
- команды Операционного управления должны предоставлять информацию на вход проектирования и улучшения архитектур и услуг.
Эксплуатация услуг также должна находить баланс между качеством услуг и их стоимостью. На рис. 11.3 изображена зависимость инвестиций в услуги и их качества.
Из рисунка видно, что в большинстве случаев увеличение качества услуги приводит к ее удорожанию. Тем не менее, эта связь не всегда прямо пропорциональна. Например, на ранних стадиях жизненного цикла можно значительно увеличить качество услуг путем минимальных вложений. Чем позже делаются изменения в рамках жизненного цикла, тем они дороже. На более поздних этапах жизненного цикла услуг даже малейшее увеличение качества услуги может стоить больших денег. Достижение баланса между затратами и качеством является ключевой задачей сервис-менеджмента (рис. 11.4). Универсальных решений нет, так как каждая услуга имеет разный потенциал оптимизации, зависящий от природы самой услуги и бизнес-цели, которую она поддерживает. Например, бизнес может быть готов тратить много денег на увеличение доступности критичных услуг, но его устраивает низкий уровень доступности для административных средств. К сожалению, существует множество примеров, когда организации вкладывают большие финансовые средства в увеличение качества услуг, но не получают никаких доказательств того, что оно в конечном итоге увеличивается.
В последние годы IT-организации стремятся сократить свои расходы чаще всего под давлением извне. Это приводит не только к уменьшению стоимости услуг, но и их качества. При этом нет простого способа расчета баланса качества и затрат. SLR (Требования уровня услуг) вместе с четким пониманием бизнес-цели и потенциальных рисков помогут определить, что услуги предоставляются с оптимальными затратами. Они также могут помочь определить услуги с "большим размером", которые возникают из-за доступности средств, и услуги "с маленьким размером", которые возникают из-за того, что бизнес не понимает необходимости финансирования тех или иных аспектов.
В табл. 11.3 примеры крайностей в двух позициях.
Чрезмерный фокус на качестве | Чрезмерный фокус на стоимости | |
---|---|---|
Позиция | Предоставление качества, которое необходимо бизнесу, чего бы это ни стоило | Максимальное сокращение затрат и предотвращение выхода за рамки выделенного бюджета |
Типичные проблемы |
|
|
Управление финансами | IT не имеет метода для связи качества услуг и их стоимости. Для оценки используется чаще всего "затраты на одного пользователя" | Нет метода для связи деятельностей в рамках IT и непосредственного предоставления услуг. Финансирование обычно выполняется в рамках расходов, заранее предусмотренных в бюджете. |
Достижение баланса качества услуг и их стоимости требует следующего:
- процессы и инструменты Управления финансами могут рассчитать стоимость предоставления услуг и выбрать оптимальную по стоимости модель предоставления среди имеющихся альтернатив. Например, сравнить стоимость предоставления услуги с 98% доступностью и 99,5 %, или стоимость предоставления услуг с дополнительным функционалом и без него;
- обеспечение того, что решения относительно баланса качества и затрат, будут принимать люди с соответствующей квалификацией на этапах Построения стратегии и Проектирования. Менеджеры Операционного управления должны принимать решения относительно выделения финансовых средств на увеличение операционной эффективности.
Следующей проблемой является баланс проактивности и реактивности. К реактивным организациям относятся те, которые не предпринимают никаких действий, пока не будет толчка в виде какого-нибудь внешнего драйвера - нового требования бизнеса, разработанного приложения или увеличения жалоб пользователей и заказчиков. К сожалению, многие организации придерживаются реактивных методов управления, наивно полагая, что это единственный путь для достижения стабильности в предоставлении услуг. Они сознательно ограничивают любые проявления проактивных действий со стороны персонала Операционного управления. Ирония состоит в том, что отсутствие одобрения проактивных действий сервис-менеджмента может привести к тому, что в итоге увеличится стоимость реактивных действий и соответствующие риски. Например, проактивным действием является формирование резервных копий серверов на случай сбоев. Это стоит не так дорого, как реактивные действия по восстановлению, если сбой все-таки случится.
Проактивная организация всегда ищет пути для улучшения текущей ситуации. Проактивный подход всегда работает на перспективу и увеличивает конкурентное преимущество организации. Тем не менее, излишний уклон "в проактивность" может стоить слишком дорого. Поэтому важно соблюдать баланс двух подходов (рис. 11.5).
В табл. 11.3 представлены крайности этих подходов.
Чрезмерная реактивность | Чрезмерная проактивность | |
---|---|---|
Позиция | Ответ на потребности бизнеса и инциденты только после того, как о них сообщили/они случились | Предугадывание потребностей бизнеса, прежде чем о них сообщат, и проблем, прежде чем они появятся |
Типичные проблемы |
|
|
Планирование мощностей | Ждать пока не возникнут проблемы с мощностями. При их возникновении предоставлять дополнительные мощности до появления следующей проблемы. | Предугадывать проблемы с мощностями и тратить деньги на то, чтобы они не появились - даже если это скорее всего не случится |
Планирование непрерывности услуг |
|
Чрезмерное планирование(и траты) на опции восстановления IT. Предоставление незамедлительного восстановления большинства услуг, вне зависимости от их влияния на бизнес |
Управление изменениями |
|
изменения запрашиваются и осуществляются даже при отсутствии необходимости в них - много работы проделывается на корректировку работы элементов, которые нормально функционируют. |
Проактивное управление в общем случае имеет преимущества, но иногда требуется и реактивные действия. Для соблюдения баланса необходимо следующее:
- строгие процессы Управления проблемами и инцидентами;
- готовность категорировать технические сбои также хорошо, как спрос на услуги со стороны бизнеса.
- доступность данных от Управления конфигурациями и Управления активами для экономии времени на реализацию проектов и принятия адекватных решений;
- непрерывное вовлечение SLM в эксплуатацию услуг.
Очень важно иметь обратную связь Эксплуатации с другими этапами жизненного цикла услуг. Персонал операционного управления должен принимать участие в Проектировании и Внедрении услуг, а также в Построении стратегии там, где это допустимо. Меру участия персонала необходимо определить в должностных инструкциях, ролях и т.п. Это обеспечит то, что услуги, спроектированные на этапе Проектирования, смогут быть использованы в конечном итоге.
Интересным является то, что в ITIL мониторинг и контроль эксплуатации услуг сравнивается с мониторингом и контролем здоровья. IT-инфраструктура выступает в роли организма. Каждая инфраструктура имеет жизненно важные показатели, которые необходимо отслеживать, чтобы понять, работает ли инфраструктура нормально, то есть "здорова" ли она. Это значит, что для контроля не обязательно отслеживать абсолютно все компоненты, а только "жизненно важные". Это может быть использование пропускной способности сети или использование памяти на критичных серверах. Если значения этих показателей в пределах нормы, значит, система здорова. Выделение таких показателей позволит сократить расходы на мониторинг и контроль.
Но, как и с другими организмами, иногда необходимо проводить комплексные проверки, которые выявят проблемы, не влияющие сразу на "жизненно важные" показатели.
Какие показатели и когда необходимо контролировать в "здоровье" инфраструктуры должно быть определено на этапе Проектирования, протестировано на этапе Внедрения и оптимизировано в рамках Непрерывного улучшения услуг.