Структура IT4IT первого уровня (Level 1) представлена через призму потоков создания ценности (Value Streams), где все элементы модели выстроены вокруг сервисной модели (Service Backbone) как основы. Это создает более явную и структурированную картину того, как различный ИТ-активы взаимодействуют для создания ценности. В ITIL v3 структура основана на жизненном цикле услуги (Service Lifecycle), представленном как последовательность фаз: стратегия, дизайн, переход к эксплуатации, эксплуатация и непрерывное улучшение. В то время как ITIL v3 фокусируется на том, что происходит с услугей на разных этапах ее жизни, IT4IT Level 1 делает акцент на том, как потоки работы проходят через организацию для создания этой услуги. IT4IT Level 1 предоставляет более явные связи между бизнес-потребностями и ИТ-реализацией через Value Streams, тогда как ITIL v3 предоставляет более детализированный взгляд на управление самой услугой на разных этапах ее жизненного цикла.

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

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

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

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

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

На этапе Act цикла Деминга возможны три основных варианта действий: 1) Внедрение успешных улучшений в постоянную практику, если результаты проверки показали положительный эффект; 2) Игнорирование изменений и остановка цикла, если результаты проверки показали, что изменения не привели к улучшению или улучшения незначительны; 3) Запуск нового цикла PDCA с учетом полученного опыта, если результаты посредственные или требуют дальнейших изменений. Этот этап служит точкой принятия решения относительно дальнейшего развития процесса.

В подходе Tipu понятия 'зрелость процессов' и 'непрерывное улучшение' тесно связаны. Подход отвергает идею создания идеальных процессов сразу, предполагая, что необходимо начинать с процессов, которые 'как-то работают'. Уровень зрелости процессов наращивается постепенно через применение интегрированного подхода Continual Service Improvement (CSI), который воздействует как на услуги, так и на сами процессы. Таким образом, непрерывное улучшение становится основным механизмом повышения зрелости системы управления в целом.

Выражение благодарности в деловом письме важно по нескольким причинам: во-первых, люди положительно реагируют на признание их усилий и предпочитают помогать тем, кто ценит их работу; во-вторых, благодарность помогает создать позитивную атмосферу в коммуникации и поддерживать хорошие рабочие отношения; в-третьих, даже если в прошлом не было конкретных позитивных взаимодействий, выражение благодарности за что-либо положительное может заложить основу для будущего сотрудничества. В тексте письма благодарность может выглядеть так: «Благодарю Вас за оказанное содействие в решении задач по проекту N!». Это небольшое усилие может значительно повысить эффективность коммуникации и вероятность получения желаемого ответа.

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