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

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

Для построения дерева отказов для функции «Обработка обращений» следует выполнить следующие шаги: определить топ-событие (отказ функции обработки обращений); выявить прямые причины этого отказа на первом уровне (например: недоступность базы данных, ошибки в логике обработки, проблемы с сетью между компонентами); для каждой из этих причин определить более низкоуровневые события, пока не достигнуты базовые события, которые уже не требуют дальнейшей декомпозиции (сбои оборудования, программные ошибки, действия персонала). При этом следует использовать правильные логические операторы между событиями («И», «ИЛИ» и др.). Например, если для отказа обработки обращений необходимо одновременное отсутствие сетевой связности между сервером и БД, а также сбой в прикладном слое – используется оператор «И». Если же достаточно одного из этих условий – оператор «ИЛИ». Базовые события размещаются на листьях дерева и могут быть оценены количественно для последующего расчета вероятности топ-события.

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

При анализе рисков учитываются три уровня вероятности: 1) Вероятность появления источника риска или угрозы, которая определяется внешними факторами и средой, в которой функционирует организация. 2) Вероятность того, что появление угрозы приведет к наступлению нежелательного события, что зависит от уровня уязвимости системы. 3) Вероятность того, что произошедшее событие вызовет конкретные негативные последствия для организации, что может варьироваться в зависимости от эффективности системы реагирования и других внутренних факторов. Каждый уровень требует отдельной оценки для формирования комплексной картины риска.

CSI (Continual Service Improvement) - это процесс постоянного совершенствования услуг, который является универсальным и применим в любой отрасли. CSI помогает выявлять области для улучшения, планировать и внедрять изменения в процессы, измерять результаты и поддерживать постоянное развитие. Для не-ИТ организаций CSI особенно ценен при использовании вместе с ITIL Practitioner Guidance, который подробно описывает применение модели совершенствования. Это позволяет сервисным организациям любой направленности постоянно повышать качество предоставляемых услуг.

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

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

Время реакции группы на назначение инцидента (время с момента назначения до переназначения в другую группу или окончания работы) включено в параметр ti, который представляет собой общее время обработки i-го инцидента силами данной группы. Чем дольше группа реагирует на назначенный инцидент, тем больше значение ti, а следовательно, тем больше доля группы во времени обработки и тем ниже её KPI в случае просрочки. Поэтому метрика стимулирует группы оперативно приступать к работе над назначенными инцидентами, даже если инцидент был передан уже близко к окончанию срока.

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