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

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

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

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

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

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

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

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

Цикл Деминга, известный как PDCA, фактически является модификацией цикла Шухарта. Уильям Шухарт, статистик и инженер, первым предложил концепцию циклического подхода к управлению качеством, который затем был популяризирован Эдвардом Демингом в Японии. Деминг адаптировал и внедрил эту методологию в японской промышленности, поэтому впоследствии она стала ассоциироваться с его именем. В действительности, Деминг сам называл этот цикл циклом Шухарта, признавая приоритет первоначальной идеи.

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