Анализ каталога услуг (ITIL).

Доброго времени суток.

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



Необходим инструмент анализа этого каталога.
Повторюсь (и акцентирую): предмет обсуждения сам по себе каталог услуг. Ещё нет SLA, ещё нет системы автоматизации деятельности ИТ подразделения (и речь не о её выборе).
К эселю привязку не делаем, использовался просто как инструмент для составления структурированного списка, не более.


А именно, хотелось бы иметь возможность выбрать некую услуги и провести сравнение с другой услугой.
На абстрактном примере.
Например, есть улуга по предоставлению канала связи - по сути, это комплексная услуга. Эта услуга предоставляется потребителям.
Но, для удобства ИТ, эта комплексная услуга делится на более мелкие услуги: поддержу основного канала связи и резервного, "телефония" и "интернет"...
Понятно что у этих услуг много общего, но есть и различия - разные ресурсы, разные зависимости...
Хотелось бы в каком-то удобном виде получить сравнение услуг (дерева услуг), что бы были показаны все зависимые и зависящие услуги. В разрезе каждой услуги от которой зависит текущая были видны её ресурсы, потребители и поставщики.


Хотелось бы иметь возможность, видеть все услуги, зависимые от данной.
- с возможностью видеть перекрестные связи между услугами, потребляющими данную;
- возможность видеть услуги (все или начиная с выбранной) просто в виде графа;
- граф по потребителю/поставщику, с возможностью видеть какие услуги порождает данный поставщик, какие ветви графа проходят транзитом через него(согласен, спорное утверждение), а какие ветки заканчиваются на этом потребителе. Абстрактно... мы выставляем счета по электронной почте, занимается этим отдел продаж. Так вот, я хочу видеть при анализе данного подразделения, какие услуги оно потребляет а какие производят, на каких услугах они базируются. В данном контексте интересно было бы проанализировать электронный документооборот, это подразделение будет и потребителем и поставщиком в рамках ЭД, а услуга связи будет нужна как для потребляемых услуг, так и для ЭД.



Интуитивно и формально всё это ясно и понятно, но хотелось бы всё это видеть в каком-либо удобном виде.
При составлении, в силу человеческого фактора, возможно дублирование некоторых услуг. Возможно, какую-то услугу целесообразно укрупнить, а какую-то наоборот детализировать.
Вот для этого и хотелось бы какой-либо инструмент, а речь виду не в контексте какой либо конкретной Service-desk системы.
Возможно, а какой-то системе есть такого анализа - прошу указать.

Dim, приветствую!

Что-то подобное делали http://omniway.ru/ в рамках подготовки к проекту. Если что, могу дать контакты, почта в профиле.

С Уважением,
Георгий

The Dim!,

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

George Nordic, спасибо за ссылку, но... мне бы сам инструмент, а не кого-то, кто может оказать услуги и выдать мне в готовом виде.

vot_takoy

The Dim!, Думается, что любую сервис деск систему придется пилить под свою компанию, все таки во всех компаниях разный подход к оказанием ИТ сервисов...И я бы на Вашем месте начал еще вот с чего, с более крупных зависимостей, а именно разделил бы на: - Инфраструктурные сервисы (связь, сервера, десктопы и т.д.) - Сервисы для фронт офиса - Сервисы для бек офиса (бухгалтерия, кадры и т.д.) и т.д. И уже потом бы

1. А где Вы увидели, что я пишу про сервис дэск систему, я же специально выделил, что есть только каталог услуг. Небольше не меньше.

2. Не могли бы Вы объяснить принцип выделения "зависимостей" в том виде, как их привели Вы?
Зависимости актуальны в рамках конкретной услуги, но не с точки зрения какой-либо группировки услуг по какому-то принципу.
А Вы, как мне показалось, предлагаете сгруппировать все услуги по территориально-организационной принадлежности.
Почему не имеет смысла, да потому что, оказание/поддержка сервиса не возможно без доступа к нему. Так, например, зачем разделять сервисы и каналы связи?

3. Да, и ещё. Я спросил как проанализировать, а Вы дали ответ на вопрос как организовать. Все же, это разные вещи...

The Dim!
Я спросил как проанализировать, а Вы дали ответ на вопрос как организовать. Все же, это разные вещи...

Вы хотите услышать про потенциальные способы анализа без привязки к конкретным системам? Я тоже изначально вопрос не воспринял в подобном ракурсе.

Насколько я понял, вам нужна система KPI. Однако, разработка такой системы - это проект, такие вопросы "с кондачка" не решают. Если вкратце, то вам нужно разделить сервисы, как минимум, по трем уровням - операционному (на котором основная привязка идет к параметрам исполнителей), технологическому (на котором основная привязка идет к аспектам инфраструктуры, оборудования и т.п.) и результирующему. Результирующий уровень в свою очередь разбивается на целевые направления - финансовое (на котором производится оценка экономической эффективности), процессное (на котором производится оценка эффективности бизнес- и технологических процессов), клиентоориентация (на котором приводится привязка к оценкам и ожиданиям клиентов) - это те, которые, я полагаю, остро необходимы. Если есть запал энергии, то можно включить еще и четвертый "обучение и рост" из предложенной Нортоном и Капланом совокупности четырех аспектов в системе Balanced Scorecard (к которой я предлагаю относиться осторожно и со здоровым скепсисом). Я бы порекомендовал в качестве четвертой группы (из менее ценных) взять "Персонал" (оценка качества персонала, его удовлетворенности и т.п.). Это, ПМСМ, то, что определяется навскидку.

Далее для каждого из уровней определяются регистрируемые параметры с тщательным продумыванием способов регистрации, степени достоверности регистрируемой информации. трудоемкости процесса регистрации. Тут есть очень большой нюанс - регистрировать нужно не всё-всё-всё, что только можно придумать (иначе завалите проект), а то, что можно измерить, не погибнув героически, и с достаточной степенью достоверности.
Выстраиваете граф KPI по уровням, используя формулы преобразования совокупностей одних показателей в другие. По системе показателей необходима оценка их достоверности. По базовым показателям она определяется исходя из технологических погрешностей процедуры регистрации и иных аспектов (например, наличия субъективных оценок, если применяются экспертные оценки). По производным показателям работает чистая математика (точнее, математическая статистика с учетом характера распределения отклонений). И вот тут обращайте внимание, что получается с достоверностью производных показателей - не должно формироваться значений наподобие "время исполнения 3 мин +/- 3 часа". Для производных KPI верхнего уровня помимо функции зависимости от KPI промежуточных уровней и от базовых регистрируемых параметров, должны быть сформированы функции чувствительности к отклонениям базовых параметров.

Основные принципы:
- Регистрировать нужно не всё подряд, а в первую очередь те параметры, к отклонению которых наиболее чувствительны оценки результирующего уровня, с учетом ценности этих оценок.
- Нужно постараться не оставить за бортом системы KPI те факторы, которые влияют, но которые по тем или иным причинам трудно регистрировать.

После разработки изначального варианта такой системы обязательно должна идти фаза ее "обкатки". Вы должны набрать некую значимую статистику регистрируемых параметров, чтобы убедиться, что параметры распределения вероятностей отклонений выбраны правильно. Что итоговые параметры в принципе формируются, что нет каких-то неучтенных факторов, которые приводят к отклонениям, имеющим систематический характер, но при этом не включенными в систему KPI. Первое, что вы увидите, когда запустите в работу систему KPI - огромные пробоины, которые нужно задраить, сконцентрировав на них усилия. Второе, когда самые крупные пробоины "задраите", обнаружите, что имеются факторы, имеющие систематический характер (НЕ случайный), не при этом не учтенные в системе KPI. И будете развивать эту систему, добавляя в нее ранее не учитываемые показатели и модифицируя бизнес- и технологические процессы. Третье, когда убедитесь, что все систематические факторы уже учтены, будете бороться с отклонениями, имеющими случайный характер, к которым наиболее чувствительны целевые показатели - это уже на всю жизнь.

Вообще, это очень обширная тема. С нею может быть связан Acivity Based Coasting, и методы процессного управления, и много чего еще. Это помимо ИТ-продуктов, которыми задумки можно воплотить в жизнь. :)
А самый первый ИТ-продукт, на котором можно задуманное сотворить - MS Excel. :)