Практика управления проблемами может быть эффективно применена для улучшения организационных процессов следующим образом: 1) Анализ корневых причин - использование методик анализа корневых причин (например, метод "5 почему") для выявления глубинных организационных проблем, а не только технических 2) Расширение фокуса - расширение скося проблемного менеджмента за пределы технических инцидентов на процессы и процедуры организации 3) Вовлечение заинтересованных сторон - использование процесса управления проблемами как платформы для привлечения различных стейкхолдеров к улучшению организационных процессов 4) Применение проактивного подхода - выявление и предотвращение потенциальных организационных проблем до их проявления в виде кризисов или конфликтов 5) Анализ инцидентов на уровне процесса - не только поиск технических причин, но и оценка, как организационные факторы (например, неэффективные процессы утверждения) способствовали возникновению проблемы 6) Управление рисками на процессном уровне - идентификация и оценка рисков, связанных с органическими процессами, и разработка мер по их минимизации 7) Интеграция с CSI - использование процесса постоянного совершенствования для трансформации выявленных проблем в возможности для улучшения организационных процессов 8) Формирование организационной памяти - создание знаниевых баз проблем и их решений, чтобы предотвращать повторение организационных ошибок Это позволяет выйти за рамки чисто технического управления проблемами и создать систему, которая улучшает не только технологические, но и организационные аспекты предоставления услуг, что в конечном итоге приводит к более стабильной и эффективной деятельности организации.

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

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

Частые ошибки при аудите CMDB: ограничение проверки только техническими атрибутами (например, IP-адреса) без анализа бизнес-важных связей, использование устаревших методик проверки, игнорирование человеческого фактора (например, не учитываются случаи ручного внесения данных вне системы), чрезмерная фокусировка на количестве расхождений вместо анализа их причин, недостаточная координация с владельцами данных для понимания контекста изменений. Также критична ошибка — проведение аудита без последующего контроля исправления выявленных недостатков.

Уровень влияния инцидента напрямую определяет его вес в системе расчета приоритета проблемы. Инциденты с высоким уровнем влияния (например, "Критичный") вносят больший вклад в суммарный вес проблемы, что повышает её приоритет. Точное определение уровня влияния является ключевым фактором для корректной расстановки приоритетов.

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

Средний чек используется для вычисления количества транзакций, необходимых для выполнения плана продаж. Например, при плане на 1440 млн рублей и среднем чеке в 10 тысяч рублей потребуется выполнять 12 000 сделок в месяц. Зная, что каждый продавец обрабатывает в среднем 20 сделок в день, можно определить необходимое количество пользователей и спрогнозировать нагрузку на ИТ-системы. Это помогает планировать потребность в вычислительных ресурсах, сетевой инфраструктуре и поддержке со стороны Service Desk. На основании данных о количестве сделок и пользователей можно построить сервисно-ресурсную модель для оптимального распределения ИТ-ресурсов.

Улучшенный модуль визуализации CMDB в CleverENGINE 3.1 обеспечивает возможность выборочного отображения данных, что упрощает нахождение сбойных конфигурационных единиц (CI), влияющих на услуги, и позволяет точно определять последствия отказа CI при работе с инфраструктурными инцидентами. Дополнительно появилась возможность «раскрывать» связи выделенных CI и услуг, что дает аналитикам возможность шаг за шагом исследовать ИТ-инфраструктуру, фокусируясь на необходимых деталях.

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

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