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

Рекомендуется опираться на данные, а не на экспертные оценки, потому что: 1. Данные предоставляют объективную картину происходящего, в то время как экспертные оценки часто субъективны и могут быть искажены 2. Люди, предоставляющие экспертные оценки, могут иметь мотив скрывать информацию или представить ситуацию в выгодном для себя свете 3. Данные позволяют точно измерить текущее состояние, выявить тенденции и количественно оценить эффект от принятых мер 4. Анализ по данным позволяет конкретно определить источники проблем, вместо обобщений и догадок 5. Работа с данными обеспечивает прозрачность ситуации для всех заинтересованных сторон, что облегчает принятие решений и выделение ресурсов 6. Данные позволяют избежать предвзятости и эмоциональной окраски при анализе проблем, что особенно важно в стрессовых ситуациях Подход Trust no one (доверяй, но проверяй) помогает выявить истинные проблемы и принять по-настоящему эффективные меры.

Заказчики не любят платить за 'гарантию' услуг, потому что это невидимая часть сервиса, которая сама по себе не создает прямой полезности для бизнеса. Люди склонны ценить и готовы платить только за то, что они видят и непосредственно используют - например, за работоспособное приложение или доступ в интернет. Гарантия, обеспечивающая надежность, безопасность, соответствие SLA и другие параметры, проявляет себя только тогда, когда чего-то не происходит (сбоев, нарушений безопасности), и поэтому ее ценность сложно оценить. Кроме того, для оценки гарантии нужны знания и опыт, которые обычно отсутствуют у заказчиков, что делает эту часть услуги менее понятной и менее ценной в их глазах, даже несмотря на то, что без нее полезность не может быть стабильно предоставлена.

В ITIL 4 для выявления требований потребителя используются методы, такие как анализ путешествия заказчика (customer journey), регулярные опросы удовлетворенности (CSAT, NPS), оценка поведения пользователей (например, объем усилий, количество ошибок) и обратная связь в рамках сервис-ревью. Цель этих методов — идентифицировать ключевые характеристики услуги, важные для потребителя, и согласовать их измерение для достижения оптимального уровня удовлетворенности.

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

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

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

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

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

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