Введение в ИТ сервис-менеджмент

? перечень инцидентов, связанных с безопасностью и ответных мер, возможно, в сравнении с предыдущим отчетным периодом;

? определение тенденций возникновения инцидентов;

? состояние программы оповещения.

Подпроцесс оценки:

? отчеты об эффективности подпроцессов;

? результаты аудиторских проверок, анализа и внутренних оценок;

? предупреждения, определение новых угроз.

Специальные отчеты:

Для сообщений об определенных в соглашении SLA инцидентах, связанных с безопасностью, поставщик услуг должен иметь прямой канал связи с представителем заказчика (возможно, инспектором информационной безопасности предприятия) через Руководителей Процессов Управления Уровнем Услуг, Управления Инцидентами или Управления Информационной Безопасностью. Должна быть также определена процедура для связи в особых случаях. За исключением особых обстоятельств, отчеты передаются через Процесс Управления Уровнем Услуг.

15.5 Контроль процесса

15.5.1 Критические факторы успеха и ключевые показатели эффективности

Критическими факторами успеха являются:

? полное понимание необходимости процесса со стороны руководства и его привлечение к процессу;

? привлечение пользователей к разработке процесса;

? точное определение и разделение ответственностей.

Показатели эффективности Процесса Управления Информационной Безопасностью соответствуют таким же показателям Процесса Управления Уровнем Сервиса в той степени, в которой последние связаны с затрагиваемыми в SLA вопросами безопасности.

15.5.2 Функции и роли

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

15.6 Проблемы и затраты

15.6.1 Проблемы

Следующие аспекты имеют существенное значение для успешной реализации Процесса Управления Информационной Безопасностью:

? Понимание необходимости процесса (понимание со стороны участников): меры безопасности редко встречают быстрое положительное понимание со стороны персонала; чаще встречается сопротивление, а не одобрение. Пользователи возмущаются потерей определенных привилегий из-за введения мер безопасности, даже если эти возможности не являются существенными для их работы. Это объясняется тем, что привилегии дают им определенный статус. Поэтому необходима специальная работа по мотивации пользователей и получению согласия руководства на введение мер безопасности. Особенно в области Управления Информационной Безопасностью руководство должно показать пример ("разъяснять курс" и "вести за собой"). При отсутствии инцидентов по безопасности у руководства может возникнуть искушение сократить расходы на Управление Безопасностью.

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

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

? Верификация: должна существовать возможность проверки и верификации безопасности. Это относится как ко вводимым мерам, так и к причинам их введения. Необходима возможность убедиться, что в соответствующих обстоятельствах приняты правильные решения. Например, должна быть возможность проверки полномочий тех, кто принимал решения.

? Управление Изменениями: часто при проведении изменений ослабевает качество оценки соответствия базовому Уровню Безопасности.

? Амбиции: при желании организации делать все сразу часто возникают ошибки. В случае введения Процесса Управления Информационной Безопасностью реализация технических мер гораздо менее важна по сравнению с организационными мерами. Изменение организации требует поэтапного подхода и занимает длительное время.

? Отсутствие систем обнаружения: новые системы, такие, как Интернет, не были рассчитаны на безопасность и необходимость обнаружения взлома. Причина заключается в том, что разработка защищенной системы требует больше времени, чем незащищенной, и находится в конфликте с требованиями бизнеса по невысокой стоимости разработки и скорейшей поставке на рынок.

? Чрезмерные надежды на технологию "неприступной крепости": угрозы безопасности систем все чаще возникают в непредсказуемых местах. Сравните первые атаки вирусов ILOVEYOU и Nimda с первым примером атак Denial of Service (DoS). В то время как защита информации с использованием традиционного подхода "неприступной крепости" сохраняет свое значение, также приобретает важность подхода "встречных атак" при возникновении нарушений безопасности. Организация должна иметь возможность быстро направить ресурсы в место возникновения дефекта до того, как он сможет выйти из-под контроля.

15.6.2 Затраты

Защита ИТ-инфраструктуры требует привлечения персонала, а следовательно, и денег для принятия, поддержки и проверки мер безопасности. Однако неспособность защитить ИТ-инфраструктуру также стоит денег (стоимость непроизведенной продукции; стоимость замены; ущерб для данных, программного или аппаратного обеспечения; потеря репутации; штрафы или компенсации в связи с невозможностью выполнения договорных обязательств). Как всегда, необходимо соблюдение баланса.

Приложение А. Фирма "Quick Couriers" ("Быстрые курьеры")

В данном примере рассматривается развитие молодой фирмы, столкнувшейся со всеми актуальными проблемами сервис-менеджмента. В конце каждого раздела ставятся вопросы, которые могут дать читателям пишу для размышлений.

Транспорт в Амстердаме в настоящее время так перегружен, что предоставление курьерских услуг с помощью автофургонов стало затруднительным. Поэтому после окончания учебы трое друзей Джейн, Джон и Питер решили заняться курьерскими услугами на велосипедах и открыли фирму Quick Couriers (QC). Фирма QC доставляет посылки в центр города, используя для этого велосипеды.

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

Джейн является ответственной за бухгалтерию, выписывание счетов, обработку заказов и поддержку деловых связей. Фирма Quick Couriers закупила программные приложения для бухгалтерии и Процесса Управления Взаимоотношениями.

Джон отвечает на телефонные звонки, рассматривает запросы заказчиков, занимается планированием и материально-техническим снабжением курьерской службы, а также передает сообщения курьеров Джейн и Питеру.

Питер отвечает за обслуживание велосипедов, заказывает детали и инструменты, планирует материально-техническое обеспечение и инструктирует курьеров.

Недавно три друга произвели анализ положения своей фирмы и определили свою концепцию и внутренние правила работы (policy). Концепция заключается в следующем: "Фирма Quick Couriers должна стать синонимом быстрой доставки в центре Амстердама и окружающих районах". Для реализации этого фирма начала рекламную компанию и увеличила наем курьеров. Было запланировано оснащение курьеров пейджерами или мобильными телефонами. Был также сделан запрос о цене Интернет-системы, которой могли бы пользоваться заказчики для подачи заявок на курьеров и отслеживания доставки своих посылок. Другим рассматриваемым вариантом было расширение бизнес-операций путем открытия еще одного офиса в Гааге или Роттердаме. Кроме того, друзья решили, что для будущего компании критическое значение имеет постановка их бизнеса на более профессиональную основу. Поэтому они определили области, требующие особого внимания.

А.1. Управление Конфигурациями

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

В настоящее время фирма имеет двадцать средств доставки (велосипедов и трейлеров), шестнадцать из которых постоянно используются. Остальные четыре или проходят техобслуживание, или могут использоваться как резерв. Фирма Quick Couriers использует технику двух моделей от разных поставщиков.

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

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

Велосипедный гараж находится рядом с мастерской. Многие курьеры заходят, чтобы узнать новый график или починить свои велосипеды.

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

Сейчас Питер инсталлировал базу данных для ведения учета инвентаря, которую он назвал ConFig. Он держит в мастерской распечатку с описью деталей. Он также купил мощный гравер для маркировки внесенных в перечень деталей.

Вопросы

1. Что послужило причиной для разработки этого процесса?

2. Кто вовлечен в процесс, кроме самого Питера?

3. Сделайте набросок сферы действия (scope) и степени детализации (level of detail) базы данных. Какие атрибуты конфигурационных единиц (CI) имеют значение для Питера?

4. Что используется для мониторинга состояния? Для чего нужно хранить историю состояний (status history)?

5. Приведите примеры некоторых вопросов, например, о тенденциях, на которые Питер может ответить сейчас с помощью базы данных, но не мог бы сделать раньше.

6. Как будет Питер заполнять базу данных?

7. Как может Питер обеспечить актуальное состояние базы данных?

8. Какие отчеты Питер будет предоставлять Джейн?

А.2. Управление Инцидентами и Служба Service Desk

При шестнадцати курьерах, постоянно находящихся в пути, нагрузка Джона по ответам на телефонные звонки все более возрастает. Он непрерывно получает заявки от заказчиков, жалобы о поздней доставке и сообщения от курьеров, чьи велосипеды сломались, или которые не могут доставить посылку из-за того, что адрес неправильный.

Джону все труднее уследить за всем, и он забывает делать важные звонки. Джейн также замечает, что про некоторые заказы забывают. Бумажки с записями теряются, и не понятно, кто над чем работает. Хотя делается все возможное для хорошего обслуживания заказчиков, невозможно определить, насколько быстро решаются проблемы. Заказчики начали жаловаться на недостатки обслуживания, и у всех на фирме создалось впечатление, что число заказов уменьшается.

В то же время Питер столкнулся с тем, что все большее маршрутов и посылок следует включать в план. Он создал базу данных - RoutePlan - для посылок и маршрутов, рассортировав их по почтовым индексам. Каждая поездка курьера охватывает несколько индексов при их оптимальной последовательности. Несколько курьеров могут обслуживать один и тот же маршрут.

Джона попросили отвечать на некоторые телефонные звонки самостоятельно. Например, он информирует заказчиков о диапазоне услуг, предоставляемых фирмой Quick Couriers, и регистрирует жалобы. Он также разбирается с тем, что случилось с посылками, и обязательно делает ответные звонки заказчикам. Теперь он имеет доступ к базе данных RoutePlan на компьютере Питера благодаря недавно установленному сетевому каналу между их компьютерами.

Для отслеживания всех сообщений и телефонных звонков Джон создал новую базу данных, TelLog. Джон использует TelLog для регистрации всех телефонных звонков и для назначения им категорий и кодов приоритета.

Вопросы

1. Что вызвало развитие Службы Service Desk?

2. Какой тип Службы Service Desk первоначально использовался для данного процесса?

3. Какая информация об инциденте существенна при обработке обращения (звонка)?

4. Приведите примеры категорий и приоритетов.

5. Кому может позвонить Джон, если он не в состоянии решить проблему?

6. Эффективная связь с ремонтной мастерской имеет существенное значение. Какой термин используется для этого в библиотеке ITIL?

7. Как может фирма Quick Couriers убедиться в том, что обращения по инцидентам не пропущены, и кто отвечает за это?

8. Оказывается ли в данном случае поддержка бизнес-операциям (Business Operations support)? Если да, объясните как.

9. Какие информационные каналы к другим системам хотели бы вы создать, и с какой целью?

10. Какой отчет должен Джон представлять Питеру и Джейн?

A.3. Управление Проблемами

Благодаря базам RoutePlan для разработки маршрутов, TelLog для регистрации звонков и ConFig для регистрации инвентаря улучшился сервис и уменьшилась рабочая нагрузка. Фирма Quick Couriers теперь имеет тридцать курьеров на маршрутах, а Джон и Джейн поженились, и свадебной "машиной", конечно же, был велосипед-тандем.

Джон теперь использует базу RoutePlan для планирования маршрутов. Привлекаемый к работе студент отвечает на телефонные звонки и может решить большую часть инцидентов с помощью предоставляемой Джоном документации. При возникновении новой проблемы, студент обращается за помощью к Питеру, Джону или Джейн, и затем документирует решение так, чтобы его можно было легко отыскать в следующий раз. Если курьер задерживается в пути из-за проблемы с велосипедом, студент из службы Service Desk отправляет запасную деталь на этот маршрут со следующим курьером. Если курьер не может справиться с проблемой, Питер доставляет ему другой велосипед на трейлере.

Однако Питера все еще беспокоит количество ремонтов дорожных велосипедов. Гоночные велосипеды легко ломаются, и они находятся в постоянном использовании. Все в значительной степени зависит от того, как курьеры преодолевают бордюры и выбоины. У фирмы Quick Couriers возникает впечатление, что велосипеды марки А меньше подвержены износу, чем велосипеды марки В, но в этом нет уверенности. Некоторые узлы выходят из строя более часто, чем другие, но непонятно, виновато ли в этом использование, сборка или модель.

Причиной беспокойства Джейн является количество потерянных посылок. Хотя они в конце концов обнаруживаются, она думает сделать работу курьеров более надежной. Курьеры получают премии за производительность, существует также приз за максимальное среднее число доставок в час. Но Джейн все же хочет получать больше информации об эффективности их работы и обслуживании заказчиков, чтобы при необходимости проводить инструктаж.

Джона попросили более глубоко проанализировать данные в базах TelLog, RoutePlan и ConFig для определения скрытых причин недостатков. Он предполагает, что ему придется объединить большое число архивных данных и провести анализ тенденций изменения.

Вопросы

1. Что вызвало разработку этого процесса?

2. Кто вовлечен в процесс и в какой роли?

3. Какие действия предпринимает Джон и с каким результатом?

4. Какую информацию хочет получить Джон от других систем?

5. Приведите примеры проблем и известных ошибок.

6. Каковы действия Джона в отношении известных ошибок?

7. Какие выводы Питер предоставляет Джейн и Джону?

А.4. Управление Изменениями

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

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

Питера попросили испытать новый тип тормозов. После этого он собирается составить график обслуживания, на основе которого будет проводиться поэтапная замена тормозов. Работа по замене тормозов будет идти одновременно с плановым обслуживанием для того, чтобы велосипеды не выводились из эксплуатации слишком надолго или слишком часто.

Будут опробованы предложения по структурированному подходу к сортировке и распределению посылок, а также проведены собрания с курьерами, чьи велосипеды слишком часто ломаются.

Вопросы

1. Что вызвало разработку этого процесса?

2. Кто вовлечен в процесс и в какой роли?

3. Какие действия предпринимаются после того, как Джон представил свои предложения?

4. Опишите, как бы вы тестировали различные предложения, в том числе требуется ли план возврата к начальному состоянию. Что могло бы быть включено в план тестирования?

5. Что учитывается в планирование модификаций? Определите слабые места, риски, необходимые ресурсы и ожидаемое воздействие.

6. Что необходимо для закрытия незавершенных мероприятий? Какой другой процесс может быть использован?

А.5. Управление Релизами

Когда курьеры доставляют посылки заказчикам, они оставляют велосипеды на улице. Джон купил несколько надежных замков для предотвращения краж велосипедов. Велосипеды оснащены также отдельными замками на колесах и замками для трейлеров.

Запасные ключи Питер держит в коробке в ящике стола. Курьеры иногда теряют свои ключи, и приходится тратить много сил на поиски подходящего запасного ключа. По прошествии некоторого времени становится трудно определить, для каких замков потеряны также и запасные ключи. Фирме Quick Couriers приходится регулярно покупать новые замки, и сейчас, когда парк велосипедов расширяется, это обходится весьма дорого. Поэтому Питер решил улучшить введение ключами и их копиями.

Комплекты ключей определены для каждого велосипеда. Замки пронумерованы, и номера занесены в базу данных ConFig. Питер покупает шкаф для хранения ключей и их дубликатов.

Вопросы

1. Что вызвало разработку этого процесса?

2. Кто вовлечен в процесс и в какой роли?

3. Какие действия необходимо предпринять перед тем, как использовать новый комплект ключей?

4. Какие действия предпринимаются перед тем, как курьер может получить новый комплект копий ключей?

5. Заменили бы вы весь комплект при выходе из строя одного замка? Как бы вы это назвали?

6. Какие действия вы бы предприняли при замене только одного замка? Как бы вы это назвали?

А.6. Управление Доступностью

Работы у фирмы Quick Couriers становится все больше. При выходе велосипеда из строя на его ремонт уходит слишком много времени, окончания которого курьер с доставляемой посылкой должен ждать на обочине дороги. Кроме того, если курьер заболел, нарушается весь график доставки. Заказчики начинают жаловаться на слишком долгую доставку.

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

Вопросы

1. Что вызвало разработку этого процесса?

2. Кто вовлечен в процесс и в какой роли?

3. Перечислите некоторые положительные моменты, угрозы и уязвимые места.

4. Используйте эту информацию для определения рисков.

5. Какие превентивные меры вы можете предложить?

6. Перечислите, что должно быть включено в план в части обслуживания, поставщиков и персонала.

А.7. Управление Мощностями

Рынок быстро меняется, фирма Quick Couriers получает новых заказчиков в других районах, рассматривается возможность распространения услуг на Гаагу и Роттердам, являющиеся густо населенными городами страны. Питер также обдумывает открытие нового офиса в международном аэропорту Шипхол.

У Джейн есть информация о необходимом уровне кадрового обеспечения для каждого маршрута, полученная из практического опыта. Она использовала систему RoutePlan для создания отчета, показывающего по каждому маршруту сколько посылок доставляются в каждый день недели, в какое время дня маршруты наиболее загружены, и сколько посылок входят в трейлер. Она использовала средние значения в качестве базового уровня и определила процентное отношение выше и ниже базового уровня для каждого месяца и времени дня. Она хочет использовать эту информацию для планирования оборудования и персонала.

Джейн использует эту информацию для подготовки отчета об ожидаемом расширении и необходимых затратах и капиталовложениях.

Вопросы

1. Что вызвало разработку этого процесса?

2. Кто вовлечен в процесс и в какой роли?

3. Приведите примеры деятельности по моделированию.

4. Как можно справиться с пиковыми нагрузками без развертывания дополнительных мощностей?

5. Какие действия помогают в расчете ресурсов при открытии нового маршрута?

6. Что должно включаться в план возможностей?

А.8. Управление Непрерывностью ИТ-сервиса

На прошлой неделе сгорело здание по соседству с фирмой Quick Couriers. Это по-настоящему испугало Джейн, Джона и Питера. Их нынешнее помещение очень удобно, а поиск нового офиса в Амстердаме весьма труден. Они осознали, что если бы сгорело их здание, месяцы ушли бы на то, чтобы снова вернуться в бизнес.

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

? размещение;

? средства доступа;

? персонал;

? электронные файлы и компьютерные системы;

? оборудование;

? посылки заказчиков.

Вопросы

1. Что вызвало разработку этого процесса?

2. Кто вовлечен в процесс и в какой роли?

3. Какие причины заставляют компанию составлять план на случай чрезвычайных обстоятельств?

4. Каковы угрозы, активы компании и точки уязвимости?

5. Используйте эту информацию для определения рисков.

6. Какие превентивные меры могут быть приняты и при каких рисках необходимы удаленные помещения для восстановления на случай чрезвычайных обстоятельств?

7. Каким термином библиотеки ITIL обозначается план на случай чрезвычайных обстоятельств, предлагающий использование ИТ-средств другой организации?

8. Определите позиции, которые должны быть включены в план перемещения на другое местоположение, и опишите способы тестирования такого плана.

9. Какова зависимость плана обеспечения непрерывности ИТ-сервиса от плана возможностей и плана повышения доступности (например, новый офис)?

10. Каково влияние процесса Управления Изменениями (Консультативного комитета по изменениям - CAB)? Приведите пример для данного случая.

А.9. Управление Финансами

Диапазон услуг, предоставляемых фирмой Quick Couriers, расширяется. Фирма использует сниженные тарифы для доставки в непиковые периоды времени, наценки за срочную доставку и скидки за большие объемы. Заказчики могут использовать Интернет для подачи заявок и для отслеживания местонахождения своих посылок. Однако некоторые из работников Quick Couriers уволились и основали собственное дело, что повлияло на качество и стоимость услуг.

Возросли также затраты, связанные с поддержкой услуг. Фирма становится все более зависимой от эффективных ИТ-средств. Джейн заключила договор с поставщиком услуг сети Интернет на предоставление выделенной линии, и фирма Quick Couriers приняла на работу сетевого администратора, чтобы обеспечить поддержку работы системы. Есть ремонтная бригада, постоянно находящаяся в разъездах. Административные расходы увеличились из-за роста численности персонала. Вложены средства в помещения, так что теперь амортизационные отчисления стали существенным фактором в бухгалтерии. Экспресс-услуги по работе курьеров должны быть доступны в любое время, а это означает, что иногда курьеры простаивают.

Становится все труднее установить цены, которые бы покрывали затраты. Джейн хочет поддерживать некоторые услуги (которые их конкуренты также оказывают) путем назначения низких цен, но должна соблюдать осторожность, чтобы новые цены не привели к убыткам от основной деятельности.

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

Вопросы

1. Что вызвало разработку этого процесса?

2. Кто вовлечен в процесс и в какой роли?

3. Приведите примеры постоянных и переменных затрат, а также прямых и косвенных затрат.

4. Приведите пример каталога услуг и средств производства, необходимых для различных услуг.

5. Составьте суммарный план цен.

А.10. Управление Уровнем Услуг

Джейн хочет привязать к своей фирме постоянных клиентов. Поэтому она стремится поддерживать с ними более тесные контакты и заключать долгосрочные договоры на обслуживание. Вместо того, чтобы платить за каждую посылку или услугу, постоянные заказчики могли бы платить фиксированную ежемесячную плату. Это обеспечит фирму постоянным доходом, что, в свою очередь, облегчит планирование услуг.

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

Фирма Quick Couriers приняла на работу нового сотрудника на должность представителя по работе с крупными клиентами (account manager). Его задачей является преобразование потребностей заказчиков в планы разработки новых или модифицированных услуг. После заключения внешних договоров он может начать подготовку нового каталога.

Вопросы

1. Что вызвало разработку этого процесса?

2. Кто вовлечен в процесс и в какой роли?

3. Опишите функции представителя по работе с крупными клиентами.

4. Приведите пример рамочного соглашения с постоянным заказчиком.

5. Как гарантируются услуги, согласованные с заказчиком?

6. Что может включаться в План обеспечения качества сервиса (SQP) компании?

7. Если бы вы были заведующим представителем по работе с крупными клиентами, с кем бы вы заключили OLA?

8. Кому бы вы докладывали о достижениях в предоставлении услуг?

Приложение В

В1. Акронимы

ACU	Accommodation Cost Unit	Статья учета затрат на размещение
AMDB	Availability Management Database	База данных управления доступностью
ВСМ	Business Continuity Management	Управление непрерывностью бизнеса
BSC	Balanced Score Cards	Карты сбалансированных балльных оценок
СА	Cost Accounting	Учет затрат
CAB	Change Advisory Board	Консультативный комитет по изменениям
CAB/EC	Change Advisory Board / Emergency Committee	Консультативный комитет по изменениям / Комитет по срочным изменениям
CCTA	Central Computer and Telecommunications Agency	Центральное агентство по вычислительной технике и телекоммуникациям (Великобритания)
CDB	Capacity Database	База данных мощностей
CFIA	Component Failure Impact Analysis	Анализ степени воздействия сбоя компонентов
CI	Configuration Item	Конфигурационная единица
CMDB	Configuration Management Database	Конфигурационная база данных
СММ	Capability Maturity Model	Модель зрелости (СММ)
CRAMM	CCTA Risk Analysis and Management Method	Метод анализа и управления рисками CCTA
CRM	Customer Relationship Management	Управление взаимоотношениями с заказчиками
CSF	Critical Success Factor	Критический фактор успеха
CTI	Computer Telephony Integration	Компьютерно-телефонная интеграция
DHS	Definitive Hardware Store	Склад эталонного аппаратного обеспечения
DoS	Denial of Service	Отказ в обслуживании
DSL	Definitive Software Library	Библиотека эталонного программного обеспечения (Фонд алгоритмов и программ)
ECU	Equipment Cost Unit	Затраты на оборудование
EFQM	European Foundation for Quality Management	Европейский фонд управления качеством
EXIN	EXamination INstitute	Экзаменационный институт EXIN
FSC	Forward Schedule of Change	Согласованный план изменений
FTA	Fault Tree Analysis	Анализ дерева неисправностей
HRM	Human Resource Management	Управление персоналом
ICT	Information and Communication Technology	Информационные и телекоммуникационные технологии
ISEB	Information Systems Examination Board	Экзаменационный институт ISEB
ISO	International Standards Organization	Международная организация по стандартизации
IT	Information Technology	Информационные технологии
ITIL	Information Technology Infrastructure Library	Библиотека передового опыта организации ИТ
ITSCM	IT Service Continuity Management	Управление непрерывностью ИТ-сервисов (услуг)
ISM	IT Service Management	ИТ Сервис-менеджмент
ITSMF	IT Service Management Forum	Форум по ИТ Сервис-менеджменту
IVR	Interactive Voice Response	Интерактивное речевое меню
KPI	Key Performance Indicator	Ключевой показатель эффективности
LAN	Local Area Network	Локальная вычислительная сеть LAN
MTBF	Mean Time Between Failures	Среднее время между сбоями
MTBSI	Mean Time Between System Incidents	Среднее время между системными инцидентами
MTTR	Mean Time To Repair	Среднее время ремонта
OCU	Organization Cost Unit	Организационные затраты
OGC	Office of Government Commerce	Государственная торговая палата ( Великобритании)
OLA	Operational Level Agreement	Соглашение об оперативном уровне услуг
PC	Personal Computer	Персональный компьютер
PI	Performance Indicator	Показатель качества
PIR	Post-Implementation Review	Анализ результатов внедрения
RFC	Request For Change	Запрос на изменение
SCU	Software Cost Unit	Затраты на программное обеспечение
SIP	Service Improvement Program	Программа улучшения сервиса (услуг)
SLA	Service Level Agreement	Соглашение об уровне услуг
SLM	Service Level Management	Управление уровнем услуг
SLR	Service Level Requirements	Требования по уровню услуг
SMART	Specific, Measurable, Appropriate, Realistic and Time-bound (Measurable)	Конкретный (Specific), измеряемый, уместный и соответствующий ситуации (Appropriate), реалистичный (Realistic) и определенный по времени (Time-bound)
SOA	System Outage Analysis	Анализ сбоев системы
SPOF	Single Point Of Failure	Критическая точка сбоя
SQP	Service Quality Plan	План обеспечения качества услуг (сервиса)
TCU	Transfer Cost Unit	Трансферные затраты
ТОР	Technical Observation Post	Пункт технического наблюдения
UC	Underpinning Contract	Внешний договор
UPS	Uninterruptible Power Supply	Источник бесперебойного питания
VOIP	Voice Over Internet Protocol	Речевая связь через Интернет по протоколу VoIP
WAN	Wide Area Network	Глобальная сеть WAN

В2. Дополнительный материал

ПРЕДМЕТ	НАЗВАНИЕ	ИЗДАТЕЛЬ	ISBN
Service Support	Service Support	OGC/HMSO	0 11 33
Service Delivery	Service Delivery	OGC/HMSO	0 11 330017 4
Service Management	Security Management	OGC/HMSO	0 11 330014 X
Applications	Application Management	OGC/HMSO	0 11 330866 3
Infrastructure	ICT Infrastructure Management	OGC/HMSO	0 11 330865 5
Implementation	Planning to Implement Service Management	OGC/HMSO	0 11 330905 8
General ITSM	The Guide to IT Service Management	Addison Wesley	0 20 173792 2
Humor	Not the IT Infrastructure Library	Giggle Production	0 95 334690 0

В.3. Веб-сайты

OGC	http://www.ogc.gov.uk
ITIL	http://www.itil.co.uk
EXIN	http://www.exin.nl
ISEB	http://www.bcs.org.uk/iseb
itSMF-AU	http://www.itsmf.org.au
itSMF-BE	http://www.itsmf.be
itSMF-CA	http://www.itsmf.ca
itSMF-DE	http://www.itsmf.de
itSMF-NL	http://www.itsmf.nl
itSMF-SA	http://www.itsmf.org.za
itSMF-UK	http://www.itsmf.com
itSMF-USA	http://www.itsmf.net
ITSM PORTAL	http://en.itsmportal.net
ITIL/ITSM World	http://www.itil-itsm-world.com
The ITIL Tooling Page	http://tools.itsmportal.net
ITIL world	http://www.itilworld.com
Loyalist College	http://www.itilexams.com

Примечания

1. ITIL является зарегистрированной торговой маркой агентства CCTA/OGC

2. Термин "ИТ Сервис-менеджмент", с одной стороны, используется как синоним термина "Управление ИТ-услугами, но, с другой стороны, усиливает его, имея в виду централизованный подход к менеджменту всей ИТ-организацией как современным сервисным подразделением, направленным на предоставление услуг бизнес-подразделения и являющихся неотъемлемым звеном в производственном процессе.

3. Framework (здесь и далее - англ.).

4. Policy (англ.). В данном случае - линии поведения, правила работы компании. Иногда переводится термином "внутренние политики компании".

5. Transformation

6. Ad hoc.

7. Под "цепочкой" понимается цепь создания прибавочной стоимости. - Прим. ред.

8. Total quality.

9. Ad hoc.

10. Policies

11. Stakeholders.

12. Actions.

13. Tasks.

14. Perspectives.

15. Период времени, который требует планирования. - Прим. ред.

16. Applications.

17. Human Resource Management - HRM.

18. Empowerment - данный английский термин имеет очень широкое значение и подразумевает "усиление" коллектива за счет оказания ему доверия, предоставления дополнительных полномочий, организации доступа к накопленным знаниям и т. д.

19. Accountability.

20. Competence management.

21. Mentors and coachers.

22. IT Customer Relationship Management - IT CRM.

23. Service Level Management - CLM.

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

25. Request for Change - RFC.

26. В данной книге в качестве перевода "activities" используются понятия "виды деятельности (работа)"

27. Суть терминов "effective" и "efficient" можно также проиллюстрировать выражения "делать правильные вещи" и "делать вещи правильно".

28. Вопрос владения и руководства процессом является сложным и в разных организациях решается по-разному. Далее в рамках этой книги будет использоваться термин "Руководитель Процесса" как перевод понятия "Process manager", объединяющий роли владельца и менеджера процесса. Это может иметь смысл для организаций, хотя это объединение не является единственным решением. - Прим. ред.

29. Performance indicators.

30. Capacity.

31. Framework.

32. Точным переводом названия "IT Infrastructure Library" является "Библиотека инфраструктуры информационных технологий", но, по мнению коллектива русской редакции, название "Библиотека передового опыта организации ИТ" более точно отражает ключевые принципы управления, используемые в мире при организации работы ИТ-подразделений, и отраженные в настоящее время в библиотеке ITIL.

33. Effective and efficient.

34. Framework

35. Efficient.

36. Effective.

37. Commitment of personnel at all levels in organization.

38. "OGC aims to modernize procurement in government, and deliver substantial value for money improvements".

39. "Best practices".

40. "Codes of practice".

41. Effective and Efficient.

42. User group.

43. Task forces.

44. Frameworks.

45. Generic Framework.

46. Service Support.

47. Service Delivery.

48. Business Perspective Set.

49. Customer Focus.

50. Demand Pull.

51. Supply Push.

52. Underpinning Contracts.

53. Costing.

54. Application Sizing.

55. Contingency Planning.

56. Request for Change.

57. Configuration Item (CI).

58. В литературе по ITIL понятие "функция" ассоциировано с вертикальным (линейным) подразделением организации, выполняющим соответствующие функциональные обязанности и фактически является его синонимом. - Прим. ред.

59. Incident.

60. Service Request.

61. Request for Change (RFC).

62. Configuration Item (CI).

63. Impact.

64. Urgency.

65. Priority.

66. Quick Fixes.

67. "Down".

68. Key Performance Indicators - KPI.

69. Knowledge Base.

70. Performance Indicators.

71. Effectiveness and Efficiency.

72. Т.е. программного обеспечения. - Прим. ред.

73. Commitment.

74. Request for Change - RFC.

75. Quick Fixes - быстрые исправления, быстрые решения или "заплатки", т.е решения, позволяющие быстро устранить инцидент, но не устраняющие ошибку.

76. Long-term Errors.

77. Historical Data.

78. Quick Fix.

79. Post Implementation Review - PIR.

80. Т.е. во время сопоставления новых инцидентов с известными ошибками. - Прим. ред.

81. Post Implementation Review - PIR.

82. Effectiveness.

83. Effectiveness and Efficiency.

84. Configuration Items - CI.

85. Configuration Management Database - CMDB.

86. Economic Value.

87. Scope.

88. Stakeholder.

89. Scope.

90. Service Request.

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

92. Naming Convention.

93. Definitive Software Library - DSL.

94. Т. е. меню со списком выбора вариантов. -Прим. ред.

95. Starting point.

96. В то же время Управление Конфигурациями сохраняет наивысшую ответственность за актуальность Конфигурационной Базы Данных, то есть возможно делегирование полномочий (но не ответственности) по регистрации результатов изменений из процесса Управления Конфигурациями в процесс Управления Изменениями. - Прим. ред.

97. Quick Wins.

98. Long-term errors.

99. Request for Change - RFC.

100. Steering Committee.

101. Executive Committee.

102. Change Advisory Board - CAB.

103. Emergency Committee - EC.

104.Scope.

105.Pre-authorized.

106.Account.

107.Forward Schedule of Change - FSC.

108.Projected Service Availability - RCA.

109.Upgrades.

110.Quick Fix.

111.IT Steering Committee.

112.Emergency Committee.

113.Forward Schedule of Change - FSC.

114.Back-out.

115.Building.

116.Performance Indicators.

117.Operational Acceptance.

118.Implementing.

119.Post Implementation Review - PIR.

120.Previous Trusted State.

121.Performance Indicators.

122.Effective.

123.Efficient.

124.Production Environment.

125.Definitive Software Library - DSL.

126.Definitive Hardware Store - DHS.

127.Work-arounds.

128.Quick Fixes.

129.Upgrades.

130.Previous Trusted State.

131.Standard Installation Scripts.

132.Definitive Software Library - DSL.

133.Installation Scripts.

134.Back-up.

135.Definitive Hardware Store - DHS.

136.Efficient.

137.Creating Images.

138.Build Management.

139.Previous Trusted State.

140.Disaster Recovery Plans.

141.Installation Scripts.

142.Rollout Scripts.

143.Т.е. как был определен релиз.

144.Operating Instructions.

145.Кроме того, для осуществления эффективной поддержки пользователей необходимо обеспечить информирование службы Service Desk о планируемом тиражировании (распространении) новых версий. - Прим. ред.

146.Accessibility.

147.Scripts.

148.Business Operations Support Desk.

149.Operations Bridge.

150.Под отделом эксплуатации (операционным отделом) понимается группа обеспечения операционной деятельности - Operations Department. - Прим. ред.

151.Production, Operations.

152.Service Requests.

153.Accounts.

154.Operations.

155.Effectiveness.

156.Service Level Agreements - SLA.

157.Operational Level Agreements - OLA.

158.Underpinning Contracts - UC.

159.Service Quality Plan - SQP.

160.Promotion.

161.Scope.

162.Quantifying.

163.Compose Service.

164.Service Specifications (Spec Sheets).

165.Charging.

166.Capacity.

167.Effectiveness and Efficiency.

168.Management Reports.

169.Operations.

170.Charges.

171.Direct Costs.

172.Indirect Costs.

173.Fixed Costs.

174.Variable Costs.

175.Capital Costs.

176.Operational Costs.

177.Budgeting.

178.Accounting.

179.Costing.

180.Charging.

181.По мнению редакторов, в настоящее время для ИТ этот период составляет 6-12 месяцев, при периоде долгосрочного планирования около 3-х лет.

182.Business Unit.

183.Rates.

184.KPI.

185.Cost-benefit analysis (CBA).

186.Capacity Management - более точным переводом является Управление "емкостью", т.е. управление мощностью вычислительных и телекоммуникационных средств и их потенциальными возможностями. - Прим. ред.

187.Advantages.

188.Efficiency.

189.Efficiently.

190.В данном случае это перевод словосочетания ad hoc.

191.Effectively.

192.Operational Processes.

193.Scripts.

194.Change Advisory Board - CAB.

195.Capacity Plan.

196.Request for Change - RFC.

197.Capacity Database - CDB.

198.Cost/benefit analysis.

199.Capacity Plan.

200.Simulation.

201.Baseline Assessment (Benchmark).

202.Host.

203.Application Sizing.

204.Application Sizing.

205.Operations.

206.Profiles.

207.Designers.

208.Benchmarks.

209.PABX.

210.Denial of Service - DoS.

211.Benefits.

212.Scope.

213.Business Impact Analysis.

214.Scope.

215.Stronghold/Fortress approach.

216.Skirmish Capability.

217.Recovery Options.

218.Cold Stand-by.

219.Fixed Facility.

220.Mobile Facility.

221.Warm Stand-by.

222.Upgrade.

223.Hot Start, Hot Stand-by.

224.Contingency Plan.

225.Host Computers.

226.Crisis Manager.

227.Fault-tolerant Systems.

228.Midrange Platform.

229.Effective.

230.Assurance.

231.Reliability.

232.Resilience - устойчивость: способность сервиса сохранять доступность при себе одного или нескольких ИТ-компонент. - Прим. ред.

233.Maintainability.

234.Recoverability.

235.Serviceability.

236.Availability Plan.

237.Recoverability.

238.Single Points of Failures - SPOF.

239.Component Failure Impact Analysis - CFIA.

240.CCTA Risk Analysis and Management - CRAMM.

241.Component Failure Impact Analysis - CFIA.

242.Recoverability.

243.Serviceability.

244.Availability Plan.

245.Component Failure Impact Analysis - CFIA.

246.Fault Tree Analysis - FTA.

247.CCTA Risk Analysis and Management Method - CRAMM.

248.System Outage Analysis - SOA.

249.Technical Observation Post - TOP.

250.Policy.

251.Management Framework.

252.Information Security Steering Committee.

Размещено на Allbest.ru

...