Участие в деловой игре Grab@Pizza развивает множество навыков: способность быстро принимать решения в условиях неопределённости, навыки коммуникации и взаимодействия между различными департаментами (особенно бизнеса и ИТ), понимание процессов ITSM и ITIL, умение приоритезировать задачи и обосновывать бизнес-ценность ИТ-инициатив, навыки управления кризисными ситуациями, лидерские качества и способность работать в команде. Также игра развивает умение анализировать ситуации, находить ошибки в текущих процессах и предлагать решения по их улучшению.

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

В ITIL рекомендуется использовать «marketing mindset» (маркетинговый способ мышления) при сборе и обработке требований заказчика. Сервис-провайдеру нужно отвечать не на вопрос «Что мы должны предоставить?», а на три ключевых вопроса: какие задачи выполняет заказчик и как ИТ может им в этом помочь; каких результатов хочет достичь заказчик; какие ограничения могут помешать заказчику достичь желаемого и как сервис-провайдер может снять эти ограничения. ITIL отмечает, что у сервис-провайдера часто нет руководств по сбору и обработке требований, что приводит к ситуации, когда заказчики предоставляют требования в произвольной форме без учета процессов. BRM играет ключевую роль в правильной интерпретации требований и обеспечении обратной связи между заказчиком и ИТ-специалистами.

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

Команда на уровне «Яркая молодость» представляет собой зрелую самоорганизованную команду (не обязательно работающую по Scrum). Для нее характерны устоявшиеся партнерские отношения с заказчиками и внешним миром, эволюционирующий рабочий процесс, большое количество инициатив и экспериментов, зрелый подход к решению конфликтов. Команда учится правильно следовать первому принципу Agile Manifesto: понимает, что изменение требований приветствуется не как повод переписать все заново, а как возможность для конструктивного диалога и серьезного исследования. Роль лидера на этом этапе - быть «мотором-метрономом», поддерживающим скорость и ритмичность работы. Важно помогать команде развивать продуктовые компетенции, чтобы она могла быть полноправным партнером для заказчика и говорить с ним на одном языке. Лидер-слуга на этом уровне востребован на 100%.

Стандарт ISO/IEC 20000:2011, раздел 8.1, предъявляет следующие требования к управлению значительными инцидентами: поставщик услуг должен документировать и согласовать с заказчиком определение значительного инцидента; значительные инциденты должны классифицироваться и обрабатываться в соответствии с документированной процедурой; информация о значительных инцидентах должна доводиться до топ-менеджмента; топ-менеджмент должен назначить ответственного за управление каждым значительным инцидентом; после восстановления согласованного уровня услуг должен быть проведен анализ инцидента с целью определения возможностей по улучшению. Эти требования направлены на обеспечение четкого и эффективного управления кризисными ситуациями, которые существенно влияют на бизнес-процессы заказчика.

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

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

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

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