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

Иерархичность в RBAC добавляет связи для организации иерархии ролей, при которой нижестоящие роли наследуют права доступа от вышестоящих. Это позволяет упростить администрирование, вынося общие базовые права в отдельную роль. Например, если есть роль 'Сотрудник' и роль 'Главный инженер', то можно определить, что роль 'Главный инженер' наследует права доступа от роли 'Сотрудник'. В этом случае не нужно будет при описании каждой роли перечислять одинаковые права доступа, достаточно установить наследование между ролями. Иерархия ролей является необязательным компонентом RBAC и может быть внедрена независимо от других компонентов системы.

Документ об архитектурных и технологических стандартах для разработки новых информационных решений включает следующие аспекты: определение допустимых языков программирования и сред разработки, утверждённых платформ и систем управления базами данных (СУБД), стандарты и протоколы взаимодействия компонентов системы, механизмы развёртывания и настройки локаторов прикладных серверов и middleware, требования к интерфейсу пользователя и администратора системы, стандарты по резервному копированию и восстановлению данных, требования к системам мониторинга и журналирования событий, правила форматирования и хранения логов, возможные ограничения на периоды стабильности системы (freeze периоды), требования к безопасности и аудиту. Такой документ обеспечивает техническую согласованность разрабатываемых решений с существующей инфраструктурой и позволяет избежать использования подходов и технологий, которые создают сложности при эксплуатации или сопровождении системы.

Формулировка целей процесса в ITIL должна соответствовать критериям SMART: - Конкретность: чёткое описание того, что нужно достичь (например, "довести долю обращений на первой линии поддержки до 30%"). - Измеримость: наличие метрик прямо в формулировке (проценты, сроки, количественные показатели). - Достижимость: реалистичный уровень амбициозности. - Актуальность: связь с бизнес-ценностью и общими целями организации. - Привязка ко времени: указание срока достижения (месяц, квартал). Кроме того, цели должны формулироваться с использованием глаголов совершенного вида ("обеспечить увеличение", "достичь уровня"). Они пересматриваются регулярно и размещаются не в регламенте процесса, а в планах управления.

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

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

Основные обязанности владельца услуги в ITIL включают обеспечение соответствия предоставления и поддержки услуги заявленным требованиям, интерпретацию требований заказчиков в ИТ-терминах, взаимодействие с менеджерами процессов на всём жизненном цикле услуги, участие в обсуждении SLA и OLA, участие во внутренних и внешних встречах по оценке услуги, выступление единой точкой ответственности за работу услуги, точка эскалации для значительных инцидентов, представительство в совете по изменениям (CAB) и обеспечение точности и актуальности информации об услуге в каталоге услуг.

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

Желания (Запад) в модели Compass Model представляют собой менее конкретные, не всегда осознаваемые потребителем, цели и пожелания. Эти пункты не являются критически необходимыми, но существенно повышают удовлетворённость, когда реализуются. Чтобы выявить желания, следует задавать вопросы: "Что клиент хотел бы дополнительно?", "Какие необязательные элементы улучшили бы его опыт?" Например, для такси в командировке желаниями могут быть: прибытие вовремя, вежливый водитель, комфортная езда, приятная музыка и отсутствие навязчивых разговоров. Желания часто определяют дифференциацию сервиса и возможность превосходства над конкурентами.

При планировании ресурсов на сопровождение CMDB необходимо учитывать несколько ключевых факторов. Прежде всего, нужно разделить конфигурационные единицы на четыре основные группы: ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений и инфраструктура, так как разные группы требуют различного подхода к сопровождению. Также необходимо учитывать перечень задач сопровождения: первичная регистрация, обновление статусов, обновление при изменениях, операционный и периодический аудит, инвентаризация и отчетность. Важно учитывать стоимость рабочего времени для разных категорий специалистов и требования к их компетенциям, так как разные задачи обычно выполняются разными специалистами. Необходимо учитывать ширину охвата учета в CMDB, так как чем она больше, тем сложнее оценка трудозатрат. Идеально вести учет фактических трудозатрат («списание часов»), чтобы на основе этой статистики планировать ресурсы. Если такой учет не ведется, можно использовать консолидированную статистику с портала REALITSM.RU.