За прошедшие несколько лет несколько раз доводилось участвовать в проектах по управлению активами и конфигурациями. Во всех проектах акценты расставлены по-разному, что каждый раз подогревает градус интереса. А также каждый раз вспоминается несколько предвзятое утверждение, которым иногда пользуются скептически настроенные заказчики: "вы, консультанты, действуете по шаблону, а нам надо нечто специальное!". Вы понимаете, я сейчас перефразировал немного, но суть, думаю, понятна.
Вспоминается оно, это утверждение, по ходу строительства очередного "космического корабля", обладающего почти неслыханной доселе функциональностью. Из раза в раз ситуация одна и та же – почти все пытаются "засунуть" в проект максимум околовсяческих совершенно необходимых организационных и функциональных "фишек". Что, в общем, понятно, поскольку у каждого свой контекст, своя специфика. Но в результате итог почти каждого проекта можно проиллюстрировать картинкой "с конями". В целом, как вы понимаете, это не только про "конфиг", ситуация с разрастанием охвата по ходу проекта знакома, думаю, всем. Мы же добрые, хотим, чтобы заказчику было хорошо. Вот и стараемся сделать максимум. Боремся, конечно, за вывод части идей в перспективные "бантики", но и навстречу стараемся идти, где возможно.
Часто бывает, что пытаются сразу "внедрять слона", пытаются перепрыгнуть одним махом несколько ступенек зрелости. Из лучших побуждений, конечно. Да и нам хочется "сделать полезно и красиво".
Самое интересное, как вы понимаете, начинается потом, когда опытно-промышленная эксплуатация счастливо заканчивается и заказчик отправляется пожинать плоды в рамках промышленной, повседневной. В том смысле, что интересно же, как оно там всё дальше вертится. Хочется ведь, чтобы не зря… И вполне естественный интерес вызывает судьба тех самых "фишек". Действительно ли они были крайне необходимы? И тот же вопрос, на самом деле, легко переадресуется не только в сторону откровенных "фишек", но и концепций, которые считаются основополагающими.
Конкретно я сейчас говорю про сервисно-ресурсную модель. Пота и крови на проектирование общих подходов и построение "пилотных" моделей уходит просто реки. Имеющиеся "шаблоны", они же наработки, превращаются из пони в вороных жеребцов. Иногда рядом из лучших же побуждений пристраивается ещё один пони. А что дальше? Как конкретно эта красота используется в жизни?
Тут я столкнулся со странным парадоксом. Часто приходилось на вопрос "используете ли вы в повседневной работе сервисно-ресурсную модель и как конкретно?" слышать ответ "Используем!". И дальше пауза. Затянувшаяся ))
Сразу скажу, позитивные ответы у меня тоже есть. То есть в отдельно взятых компаниях оно как-то живёт. Но не очень понятна реальная жизнеспособность подхода в более-менее широких масштабах, если честно. А хочется конкретики. Хочется понять, как СРМ на самом деле используется.
Поэтому просим вас, уважаемые коллеги, пройти небольшой опрос по использованию сервисно-ресурсной модели. Он не отнимет у вас много времени.
Заранее спасибо!
Для начала надо бы определиться с тем, что такое "сервисно-ресурсная модель". То, что обычно понимается под этим термином, на самом деле представляет собой графическое отображение сервисной архитектуры – взаимосвязей между сервисом и поддерживающими его элементами. Сервисная архитектура позволяет анализировать взаимное влияние элементов и моделировать доступность сервисов.
Но для сервисно-ресурсной модели здесь не хватает зависимостей между объемом потребления элементов верхнего уровня (сервисов и ресрусов) от элементов нижних уровней (ресурсов). Причем в модели должны быть представлены не только программно-технические, но и трудовые ресурсы. Сервисно-ресурсная модель позволяет планировать ресурсы на основании объема потребления сервисов.
Если же к сервисно-ресурсной модели добавить учет затрат по элементам модели (они выступают в качестве МВЗ) и правила разнесения затрат, получится экономическая модель услуги. Эта модель уже не просто позволяет планировать ресурсы на основании объема потребления сервисов, но и рассчитывать стомость сервисов, а также разносить её по потребителям.