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

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

Чтобы определить, является ли предложение услугой в контексте ITIL4, следует задать следующие вопросы: 1) Какие риски и затраты клиент перекладывает на поставщика при использовании этого предложения? 2) Что является конечной ценностью для клиента, и как предложение помогает ее достичь? 3) Какие ресурсы включает в себя предложение, и как они доступны клиенту? 4) Какие сервисные операции выполняет поставщик для поддержания работы предложения? 5) Если бы клиент сам решал эти задачи, какие усилия и риски на него бы легли? Если при ответе на эти вопросы становится ясно, что клиент перекладывает на поставщика значимые риски и затраты, то предложение соответствует определению услуги в ITIL4. Например, простая продажа шоколадки не является услугой, так как клиент не перекладывает никаких рисков, но при регулярной доставке клиент перекладывает на поставщика ответственность за своевременность и качество поставок.

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

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

Методология PRINCE2® определяет шесть основных аспектов управления проектами: Сроки (Timescales), Затраты (Costs), Объем работ (охват), Качество (Quality), Выгоды (Benefits) и Риск (Risk). Эти аспекты представляют собой параметры, которые необходимо контролировать в рамках проектного управления, и образуют взаимосвязанную систему, где изменение одного из параметров может повлиять на другие.

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

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

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

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