Интегрированное управление сервисами 4
Integrated Service Management (ISM):

Ing. H. van den Elskamp,
Drs.W.J.J. Kuiper,
H.Wanders,
KPN Datacenter, Drs. J. van Bon and
W. Hoving MBT, Bureau Hoving & Van Bon, the Netherlands

- 4 -

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Ограничительный фактор 3. Сложные соотношения между соглашением сервиса и предоставлением

При внедрении процессного подхода, ожидалось, что сервисные контракты (SLA's) будут, прежде всего, включать описание сервисов вместе с множеством параметров относительно доступности, времени реакции, времени инсталляции и т.д. Однако, на практике поставщику сервиса легче просто получать оплату за пару легко определяемых затрат, с дополнительной оплатой или без нее. Клиент, с другой стороны, судя по всему все еще ожидает неизменности понятной ему структуры затрат, основанной на вещах типа аппаратных средств ЭВМ (тип компьютера, количество мегабайтов, емкость сети), программного обеспечение и часов поддержки, вместо единиц производительности в терминах эксплуатационных процессов. Результирующий Ограничительный фактор - в том, что обе стороны, все еще следуют соглашению, но это соглашение не описывает фактические потребности клиента, а именно требуемый ИТ сервис и связанную с ним поддержку. Поставщик, с другой стороны, остается с проблемой, что он (или она) может поставлять то, что было согласовано в контракте, но то, что клиента все еще не удовлетворяет. Причина этой проблемы двойственная. Клиент не осведомлен об ИТ достаточно, чтобы должным образом оценить сервис и поэтому, пытается найти успокоение в описании ресурсов, которые будут развернуты (аппаратные средства ЭВМ, программное обеспечение и людское обеспечение (в оригинале humanware)). Поставщику трудно не только определять стоимость сервиса, но и управлять организацией как требуется для предоставления сервиса. Отсутствие SLA's с ясными, управляемыми и измеряемыми параметрами сервиса ведет к усилению классического недовольства покупателя ИТ.

Ограничительный фактор 4. Ограниченная добавленная ценность управления конфигурации

Зачастую, "внедрение" ITIL в ранней стадии начинается, с создания и детализации Базы Данных Управления Конфигурации (Configuration Management Database - CMDB). По мнению разработчиков, эта база должна служить достижению многих целей типа управления конфигурации, управления активами, управления ресурсами, управление затратами, и т.д. и должна фактически поддерживать все процессы. В результате создается база данных, заполненная детальной информацией, которая содержит много взаимосвязей. Поддержание такой базы данных часто отнимает очень много времени, делая почти невозможным проверить данные. Проблема еще больше усугубляется тем фактом, что те, кто отвечает за поддержку изменений, то есть менеджеры систем, операторы и/или штат поддержки изменений, не видят большой выгоды от их усилий в ежедневной работе. Поэтому надлежащая поддержка CMDB требует большого количества усилий и дисциплины. Отдача еще больше уменьшается, поскольку, в случае многих важных действий, CMDB часто не содержит требуемую информацию, вынуждая проводить инвентаризацию вновь. CMDB предоставляет ограниченную поддержку для деятельностей, в то время как ее обслуживание требует непропорционально больших усилий.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17