99,9% доступности может быть недостаточно для бизнес-процессов по нескольким причинам. Во-первых, этот показатель не учитывает распределение простоя: 0,1% от года составляет около 8,76 часов, что может быть критично, если эти часы приходятся на пиковую нагрузку. Во-вторых, для некоторых бизнес-процессов (например, финтех, здравоохранение) даже короткие простои могут привести к серьезным последствиям. В-третьих, бизнес зачастую зависит от непрерывности процессов: если 8,76 часов простоев приходятся на один раз, это может привести к утрате контрактов и репутационному ущербу, чего не отражает процентный показатель. В-четвертых, заказчик и поставщик услуг могут по-разному интерпретировать этот показатель (в год, месяц, неделю), что создает неопределенность.

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

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

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

Если инцидент решён в срок, увеличение времени обработки конкретной группой не влияет на её KPI, так как для этих инцидентов vi=0 и их вклад в формулу равен 1. Если же инцидент просрочен, увеличение времени обработки группой (ti) приведёт к росту её доли в общем времени (ti/Ti), что уменьшит её KPI, так как формула для просроченных инцидентов выглядит как 1 - (ti/Ti). Таким образом, метрика специально спроектирована так, чтобы время обработки влияло на показатель только в случае, когда инцидент оказался просроченным.

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

'Человек процесса' должен обладать волей, упорством и готовностью работать в условиях организационной инерции. Он должен уметь преодолевать сопротивление, внедрять изменения и поддерживать процессы в актуальном состоянии. Это требует многолетних усилий, так как результаты такой работы проявляются не сразу, но со временем становятся основой стабильности и эффективности организации.

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

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

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