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

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

Управление конфигурациями требует учета связей между элементами инфраструктуры (CI) и услугами, а также между самими услугами. Это критически важно для корректного понимания влияния изменений в инфраструктуре на конечные услуги и для обеспечения целостности сервисов при проведении изменений.

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

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

Раздел «Хорошие практики» в описании фактора влияния COBIT 5 включает набор задач и факторов успеха, необходимых для реализации назначения процесса. Эти практики можно взять из общедоступных референтных моделей, таких как COBIT, ITIL или ISO20000, или разработать собственные. Например, для процесса BAI06 Manage Changes COBIT 5 определяет такие практики, как оценка и приоритизация запросов на изменения, управление экстренными изменениями, отслеживание статуса изменений и их документирование. Соответствие этим практикам является метрикой соответствия внешним или внутренним требованиям и помогает оценить, насколько процесс соответствует лучшим практикам отрасли, что важно как для внутреннего совершенствования, так и для аудита и сертификации.

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

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

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

В разделе «о чем просим / что требуем» должно быть четко и конкретно указано действие, которое требуется от получателя. Примеры формулировок: «Прошу Вас содействовать / довести до сведения персонала / назначить ответственных / согласовать расходы на…», «Инициировать проект не позднее …», «Начать работы с …». Если вы что-то требуете, важно ссылаться на соответствующее основание из предыдущего раздела (например, приказ или решения встречи), которое подтверждает ваши полномочия в постановке таких требований. Также желательно указать конкретные сроки выполнения задачи. Четкое формулирование запроса и наличие ссылок на нормативные документы или решения значительно увеличивают вероятность получения нужного ответа в требуемые сроки.