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

Жизненный цикл процесса в COBIT 5, включающий этапы планирования, приобретения, построения/приобретения/создания/внедрения, использования/эксплуатации, оценки/мониторинга и обновления/утилизации, может быть упрощен до цикла Деминга (PDCA). В этом случае этапы планирования, создания плана и постановки целей соответствуют фазе Planning (Планирование), этапы создания и внедрения - фазе Doing (Делание), этапы мониторинга и отчетности - фазе Checking (Проверка), а планирование совершенствования процесса - фазе Acting (Действие). Это упрощение сохраняет смысл и позволяет оценивать зрелость процесса по полноте реализации цикла PDCA, что является основой для подходов оценки зрелости, таких как CMMI-SVC и COBIT PAM.

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

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

Принцип разделения полномочий в контексте RBAC заключается в том, что критически важные операции должны выполняться разными людьми, чтобы предотвратить мошенничество или ошибки. Например, в банковской системе один сотрудник (роль "Операционист") может инициировать платеж, но его проведение должно быть одобрено другим сотрудником (роль "Контролёр"). Эти полномочия не могут быть объединены в одной роли и не могут быть назначены одному сотруднику. Это обеспечивает взаимный контроль и повышает безопасность операций, минимизируя риски, связанные с злоупотреблением полномочиями.

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

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

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

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

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