Контроль известной ошибки (known error) в ситуации, когда после диагностики не обнаружено реалистичных решений, имеет свои особенности. В этом случае процесс фокусируется не на устранении проблемы, а на управлении ее последствиями и минимизации влияния на бизнес. В рамках error control (EC) устанавливается срок контроля известной ошибки, который позволяет отслеживать проявления проблемы и оценивать, как она влияет на работу бизнес-процессов в режиме ожидания. Такой подход необходим, когда решение проблемы технически невозможно или экономически нецелесообразно в данный момент, но требуется поддерживать сервис на приемлемом уровне.

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

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

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

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

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

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

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

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

Диагноз «сбой услуги» фокусируется на том, что пользователь перестал получать необходимую услугу, и определяет, какое именно повреждённое звено вызвало проблемы для конечного пользователя. Диагноз «сбой компонента» же касается поиска конкретного физического или программного компонента, который вышел из строя. Первый необходим для оперативного восстановления работы сервиса, второй — для устранения технической причины инцидента. Таким образом, на уровне процессов это различие помогает разделить управление инцидентами и управление проблемами.