Чтиво.
Модератор: Модераторы
Сообщений: 28
• Страница 2 из 3 • 1, 2, 3
А у Яндекса спросить не пробовал????????
SLA - Service Level Agryment - Соглашение об уровне предоставления сервиса.
Это договор между ИТ подразделением и получателем ИТ сервиса определяющий все аспекты предоставления указанного сервиса (время, место, стоимость и т.д.)
SLA - Service Level Agryment - Соглашение об уровне предоставления сервиса.
Это договор между ИТ подразделением и получателем ИТ сервиса определяющий все аспекты предоставления указанного сервиса (время, место, стоимость и т.д.)
Знания, которые нельзя применить - бесполезны
Для начала неплохо было бы почитать "IT сервис менеджмент. Введение." Там рассказаны общие принципы ITSM. Ссылки нет, могу выслать саму книгу. Мыло в профиле. А так нужно определиться, что нужно. Поставить перед собой цель. Если просто систематизировать ПО и железо, то можно просто пройтись по компам, переписать параметры и составить табличку в том же ёкселе и заполнять ее по мере изменений. Ну, само собой перед этим отобрать админские права у юзеров. Самый дешевый вариант. А вот если требуется выстраивать некие процессы, то тут уже надо определяться с тем, какие.
- Remy
- Активный пользователь
- Сообщения: 793
- Зарегистрирован: 17 мар 2004, 19:11
- Откуда: Санкт-Петербург, Россия
она такая тягомотная, советую лучше, так как попытка распечатать выдает такую кипу листов, что ее только в скоросшиватель, а с такой в метро не поездиешь, ну и в кровате не почитаешь , кто на метро не ездит
- Дмитрий Дашкевич
- Новый участник
- Сообщения: 39
- Зарегистрирован: 25 май 2006, 12:05
- Откуда: Люберцы
"Неблагодарное это дело - бить красных"... Цитата из фильиа вспомнилась в связи с обсуждаемой возможностью самостоятельной разработки SLA. Представляю компанию, которая разрабатывает ITSM-решение, использует его у себя и как раз сейчас находится в процессе перехода на версию, поддерживающую каталог сервисов, услуг и SLA. Могу сказать одно. В большинстве случаев теоретическую работу лучше поручить сторонним консалтерам и прошу не рассматривать мой пост в качестве рекламы. Вряд ли в серьёзной компании возможен SLA, единый для всех. Разным подразделениям предоставляются различнные сервисы. И критичность этих сервисов для подразделений разная. Помимо критичности на время решения инцидента может и должно иметь влияние множество параметров: тип инцидента, способ подачи запроса, время подачи и т.п. Боюсь, что учесть всё сразу не удастся. SLA будет слишком общим, чересчур оптимистичным или, наоборот, пессимистичным по срокам. И будет опираться на персональное видение процессов разработчика. Если есть возможность заказать консалтеров - советую сделать это и постараться набраться собственного первичного опыта глядя на их работу и её результаты со стороны заказчика.
Сообщений: 28
• Страница 2 из 3 • 1, 2, 3
Вернуться в Управление Конфигурациями, Изменениями, Релизами
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3