БИЗНЕС-СЕТЬ KINETICS CRM CALL-ЦЕНТРЫ ERP ITSM PM АБС АБН SEC SAAS

 ПоискПоиск   ПользователиПользователи   РегистрацияРегистрация   ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 

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

 
ITSM Форум -> Обменяемся опытом
Автор Сообщение
DieKrupps



Зарегистрирован: 26.03.2010
Сообщения: 2


СообщениеДобавлено: Пт Мар 26, 2010 6:44 am     Посмотреть профиль Отправить личное сообщение

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

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

Вариант #1

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

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

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

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


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


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

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

вариант #2

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


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

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


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

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

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

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


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

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

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

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

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

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

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



Зарегистрирован: 19.03.2009
Сообщения: 31


СообщениеДобавлено: Пн Мар 29, 2010 12:18 pm     Посмотреть профиль Отправить личное сообщение

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



Зарегистрирован: 26.03.2010
Сообщения: 2


СообщениеДобавлено: Вт Мар 30, 2010 6:34 am     Посмотреть профиль Отправить личное сообщение

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


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


atoo писал(а):

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


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

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

процесс управления изменениями не формализован вообще. процессы вообще не определены как таковые...
atoo



Зарегистрирован: 19.03.2009
Сообщения: 31


СообщениеДобавлено: Вт Мар 30, 2010 8:59 am     Посмотреть профиль Отправить личное сообщение

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



Зарегистрирован: 10.06.2010
Сообщения: 27


СообщениеДобавлено: Чт Июн 10, 2010 7:42 am     Посмотреть профиль Отправить личное сообщение

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



Зарегистрирован: 31.08.2016
Сообщения: 1


СообщениеДобавлено: Ср Авг 31, 2016 9:20 am     Посмотреть профиль Отправить личное сообщение

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

 


Powered by LP © 2001, 2005 phpBB Group