Для создания системы оценки нужно построить матрицу взаимодействия функций и процессов. В этой матрице вертикаль представляет собой функции (отделы или группы), а горизонталь — процессы. Если функция участвует в процессе, руководитель этой функции отвечает за предоставление ресурсов. Для оценки используется система метрик, которые отражают эффективность работы сотрудников под руководством данного руководителя в контексте процесса. Например, для руководителя отдела в сфере управления инцидентами могут использоваться такие показатели как доля заданий, выполненных в срок; доля инцидентов, принятых в работу своевременно; доля инцидентов, решенных в срок и с первой попытки; коэффициент обновления по проблемам. Эти показатели приводятся к сопоставимому виду (шкала от 0 до 1), после чего формируется итоговый рейтинг руководителя с помощью арифметического, геометрического или взвешенного среднего. На более высоких уровнях управления агрегируются рейтинги нижестоящих руководителей.

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

Метрика результативности для ИТ-групп рассчитывается как отношение количества инцидентов, решённых данным участником процесса без повторной обработки, к общему количеству инцидентов с участием этой группы. Точная формула: KPI результативности = 1 — (M / N), где N — общее количество инцидентов, решённых за период с участием даной группы, а M — количество инцидентов, которые потребовали повторной обработки этой группой. Метрика нормирована в диапазоне от 0 до 1, где 1 означает идеальную результативность.

Существуют два основных варианта интеграции внешних источников данных с CMDB: 1) Перенос данных из внешних систем непосредственно в CMDB; 2) Обеспечение доступа к данным внешних источников через интерфейс CMDB без их физического переноса. Первый подход подразумевает копирование информации во внутреннее хранилище конфигурационной базы данных, тогда как второй вариант сохраняет данные во внешней системе, организуя лишь точку доступа к ним из CMDB.

Основное сходство между IT4IT и ITIL v3 заключается в использовании концепции жизненного цикла услуги. В IT4IT сервисная модель (Service Model) построена вокруг четырех основных столпов и представляет собой Service Backbone, что по сути соответствует этапам жизненного цикла услуги в ITIL v3 - от концепции до оказания услуги. Обе модели рассматривают ИТ-услуги в разрезе процессов, и многие функциональные компоненты в IT4IT (такие как управление инцидентами, проблемами, изменениями) напрямую соответствуют стандартным процессам ITIL v3. При переходе к ITIL v4 видно еще больше общего, в частности, использование цепочки создания ценности (Value Chain), впервые предложенной Майклом Портером. Обе модели стремятся описать целостную картину ИТ-управления, а не просто набор разрозненных процессов.

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

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

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

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

Отказ от использования ролевой модели управления доступом может быть неоптимальным решением, потому что это приведет к потере ключевых преимуществ RBAC, таких как прозрачность системы управления доступом, соответствие бизнес-процессам, масштабируемость и легкость администрирования прав доступа. Переход к дискреционной модели управления доступом (DAC) создаст больше сложностей при управлении доступом для большого количества пользователей, увеличит вероятность ошибок и нарушений безопасности. Даже в условиях частых изменений лучше адаптировать существующую ролевую модель, например, выделяя стабильные зоны и используя гибридный подход, чем полностью отказываться от RBAC, что будет означать шаг назад в эффективности управления доступом.