Объемы ИТ услуг и каталог сервисов, вопрос

[DieKrupps]

Добрый день , господа !

В Базе СМДБ определяются услуги , системы и зависимые конфигурационные единицы.

Вариант #1

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

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

Таким образом любой сервис моделируется с помощью конфигурационных единиц, как обеспечивающих ( support) так и зависимых ( dependent) Из этой картины видно как , на что повлияет сбой в инфраструктуре.

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


Для чего я это написал. А вот для чего. У нас возникли разногласия при построении самой сервисно-ресурсной модели.


Некий коллектив предлагает другую так сказать идеологию построения СРМ.

-------------------------------------------

вариант #2

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


В этой идеологии нет зависимых конфигурационных единиц (напр. активов пользователей в виде компьютеров), они просто не определены и выкинуты из контекста.

Каждый информационный ресурс ассоциируется с услугами. А пользователь ассоциируется с информационным ресурсом ( например с конкретной железкой в виде сервера где крутится 1С)


И вот отсюда возникает множество разногласий.

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

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

Все бы ничего, но когда встает вопрос подсчета объемов услуг то начинается свистопляска.


Одни говорят "А если компьютером пользуются несколько пользователей, что тогда? Как разнести объемы?"

Другие говорят "А что если пользователь сел за чужой компьютер и хочет там зайти под своим логином и паролем?"

Мнение разделились именно на том, что считать объектом , пользователя или конкретную конфигурационную единицу которая считается зависимой от сервиса.

Инструментальное ПО которое было куплено ( Altiris) , поддерживает в CMDB и надо сказать в workflow первый вариант. Можно конечно повозюкаться с кастомизацией , но все таки ...

Второй вариант реализован в кустарной системе написанной собственными силами и сторонники второго варианта ратуют за перенос идеологии из кустарной системы в систему Altiris где есть настоящая полноценная CMDB построенная по рекомендациям ITIL и где по дефолту так сказать можно достаточно легко построить первый вариант.

Так уже служилось исторически , что пользователю акцептуется доступ не к услуге , а к информационному ресурсу ( например серверу)

Просветите , господа, очень интересны Ваши комментарии !

[atoo]

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

[DieKrupps]

[atoo]

Тогда вопрос какие процессы описаны?
Лучше убогий каталог чем совсем никакого.
Я про изменения спросил, дабы узнать что пользователю делать, чтобы заменить картридж.

[PaSol]

А цели то какие? Что хотите на выходе получить? Оценивать себестоимость услуг как таковых? Оценивать объём потреблённых услуг каждым отдельно взятым пользователем? Повысить качество планирования изменений? Или что-то другое возможно?

[ValentinBelov]

Всем сдрасвуйте, соклько будет стоить создать сайт аналогичный этому - http://xn-----8kcod2ajcvj9dey3d5c[dot]com[dot]ua/ http://xn-----8kcod2ajcvj9dey3d5[dot][dot][dot]ehli-na-iphone-6 тоже интернет магазин продающий силиконовый чехол для iphone 6 . И по времени соклько займет?
_________________
Это полезный сайт, хочу зарегистрироваться