Портал №1 по управлению цифровыми
и информационными технологиями

Зачем вам сервисно-ресурсная модель?

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

project_plan-factВспоминается оно, это утверждение, по ходу строительства очередного "космического корабля", обладающего почти неслыханной доселе функциональностью. Из раза в раз ситуация одна и та же – почти все пытаются "засунуть" в проект максимум околовсяческих совершенно необходимых организационных и функциональных "фишек". Что, в общем, понятно, поскольку у каждого свой контекст, своя специфика. Но в результате итог почти каждого проекта можно проиллюстрировать картинкой "с конями". В целом, как вы понимаете, это не только про "конфиг", ситуация с разрастанием охвата по ходу проекта знакома, думаю, всем. Мы же добрые, хотим, чтобы заказчику было хорошо. Вот и стараемся сделать максимум. Боремся, конечно, за вывод части идей в перспективные "бантики", но и навстречу стараемся идти, где возможно.

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

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

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

Тут я столкнулся со странным парадоксом. Часто приходилось на вопрос "используете ли вы в повседневной работе сервисно-ресурсную модель и как конкретно?" слышать ответ "Используем!". И дальше пауза. Затянувшаяся ))

Сразу скажу, позитивные ответы у меня тоже есть. То есть в отдельно взятых компаниях оно как-то живёт. Но не очень понятна реальная жизнеспособность подхода в более-менее широких масштабах, если честно. А хочется конкретики. Хочется понять, как СРМ на самом деле используется.

Поэтому просим вас, уважаемые коллеги, пройти небольшой опрос по использованию сервисно-ресурсной модели. Он не отнимет у вас много времени.

Заранее спасибо!

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 3

  • Для начала надо бы определиться с тем, что такое "сервисно-ресурсная модель". То, что обычно понимается под этим термином, на самом деле представляет собой графическое отображение сервисной архитектуры – взаимосвязей между сервисом и поддерживающими его элементами. Сервисная архитектура позволяет анализировать взаимное влияние элементов и моделировать доступность сервисов.

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

    Если же к сервисно-ресурсной модели добавить учет затрат по элементам модели (они выступают в качестве МВЗ) и правила разнесения затрат, получится экономическая модель услуги. Эта модель уже не просто позволяет планировать ресурсы на основании объема потребления сервисов, но и рассчитывать стомость сервисов, а также разносить её по потребителям.

  • Артем Мукосеев

    Дмитрий,

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

    • Конечно, и мне тоже интересны результаты. Я не в качестве критики – просто уточняю. Это вообще очень дискуссионная тема, и наличие общих терминов позволяет больше спорить о сути, меньше – об определениях.


Добавить комментарий для Артем МукосеевОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM