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

В большинстве организаций процесс управления проблемами часто возникает раньше практики постоянного совершенствования по нескольким причинам: 1) Непосредственная потребность - проблемы и инциденты оказывают непосредственное влияние на бизнес и требуют немедленного решения. Это создает острое ощущение необходимости иметь процесс, который может устранивать корневые причины повторяющихся инцидентов. 2) Более простая фокусировка - управление проблемами сосредоточено на конкретных технических или операционных проблемах, что легче реализовать, чем более абстрактную концепцию постоянного совершенствования. 3) Тесная связь с управлением инцидентами - процесс управления проблемами часто развивается естественным образом из процесса управления инцидентами как его логическое продолжение. 4) Ощутимые результаты - эффект от внедрения управления проблемами можно увидеть достаточно быстро в виде снижения количества повторных инцидентов. 5) Менее высокие требования к культуре организации - управление проблемами требует меньше изменений в организационной культуре, чем практика постоянного совершенствования, которая предполагает постоянный поиск возможностей для улучшения. 6) Более четкая ответственность - в управлении проблемами роль и ответственность обычно четко определены, тогда как в постоянном совершенствовании ответственность часто распределена более широко. 7) Поддержка руководства - руководство чаще поддерживает внедрение процессов, направленных на решение конкретных проблем, чем абстрактные инициативы по совершенствованию, результаты которых могут быть не такими очевидными на начальных этапах.

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

FTA и анализ дерева событий (ETA) часто используются совместно как дополняющие друг друга методы. FTA – это дедуктивный метод (сверху вниз), направленный на анализ причин конкретного нежелательного события. ETA – индуктивный метод (снизу вверх), начиная с базового события, анализирующий все возможные последствия. Комбинация этих методов позволяет: использовать базовые события из FTA как отправные точки для построения ETA, что позволяет увидеть не только причины, но и все потенциальные последствия сбоя; проверить, не упущены ли какие-либо сценарии в FTA, через обратный анализ ETA; получить более полную картину рисковой ситуации – как от события к причинам, так и от причины к событиям. Например, базовое событие из FTA (например, отказ сервера) может стать начальной точкой для ETA, который покажет все возможные негативные сценарии, возникающие из-за этого отказа.

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

BMC Remedy ITSM Suite оказалась единственным лидером в магическом квадрате Гартнера за 2010 год благодаря оценке ее как надежного и стратегически стабильного партнера, способного поддерживать долгосрочные отношения с корпоративными клиентами. Гартнер оценивает не только технические характеристики продукта, но и способность компании внедрять продукт на предприятиях, поддерживать его развитие и обеспечивать уверенность клиентов в долгосрочной перспективе. В то время как другие компании, такие как HP, IBM и CA, потеряли позиции из-за оценки их маркетинговой и продажной активности, а также стратегического видения развития продукта.

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

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

ITIL рекомендует, чтобы служба service desk закрывала инциденты после того, как будет удостоверена полная ликвидация инцидента, удовлетворенность пользователей и их согласие на закрытие. Согласно документу Service Operation 4.2.5.9, service desk должен выполнить несколько процедур перед закрытием: указать код закрытия, провести опрос удовлетворенности пользователя, документировать закрытие инцидента, определить наличие связи с проблемой для предотвращения повторения, и формально закрыть инцидент (изменить статус на «закрыто»).

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