Модель системного подхода помогает в анализе текущей ситуации в ITSM, обеспечивая полноту анализа за счет использования набора элементов и связей. Она позволяет не упустить важные факторы, структурировать наблюдения, привязывая их к конкретным элементам, и анализировать взаимное влияние, двигаясь по связям от элемента к элементу. Эта модель особенно эффективна при анализе конкретных проблем (например, роста количества инцидентов или низкой удовлетворенности пользователей), так как помогает выявить корневые причины проблем во взаимосвязи всех компонентов системы, а не рассматривать их изолированно.

В рамках IT4IT Reference Architecture концепция цепочки создания ценности (Value Chain), впервые предложенной Майклом Портером в 1985 году, является основой архитектуры. IT4IT представляет ИТ как цепочку создания ценности, где каждый этап добавляет определенную ценность к конечному продукту или услуге. Эта Value Chain в IT4IT состоит из четырех основных потоков: Strategy to Portfolio (S2P), Requirement to Deployment (R2D), Request to Fulfill (R2F) и Detect to Correct (D2C). Каждый из этих потоков представляет собой последовательность действий, которые преобразуют первоначальные потребности бизнеса в предоставляемые ИТ-услуги и поддерживают их эксплуатацию. Таким образом, IT4IT адаптирует классическую концепцию цепочки создания ценности применительно к ИТ, организовывая все ИТ-активности в последовательность, направленную на создание ценности для бизнеса.

Для анализа причин проблем в DevOps применяются методы, такие как постмортем-встречи и ретроспективы. В таких мероприятиях участники команды совместно обсуждают причины возникновения ошибок, выявляют системные проблемы и определяют пути их решения. Может использоваться методика «Пять Почему» для поиска корневых причин и подход 8D из бережливого производства, в рамках которой отдельная команда, собранная лидером, анализирует конкретную проблему. Эти методы помогают не только исправить текущие ошибки, но и улучшить процессы в долгосрочной перспективе.

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

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

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

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

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

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

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