Функциональная эскалация инцидентов — это процесс передачи заявки от одного уровня поддержки к следующему по иерархии (например, с L1 на L2 или с L2 на L3) при необходимости более глубокой диагностики или решения сложной проблемы. Она отличается от временной эскалации, которая связана с нарушением сроков SLA и требует вмешательства менеджмента, и от персональной эскалации, когда заявка передается конкретному специалисту или руководителю по содержательным вопросам. Функциональная эскалация определяется сложностью проблемы и необходимостью привлечения специалистов с более высоким уровнем компетенции, тогда как другие виды эскалации могут быть связаны с организационными или временными аспектами обработки заявок.

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

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

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

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

Для сбалансированной оценки деятельности групп поддержки необходима пара метрик: 1) Метрика своевременности – оценивает скорость обработки инцидентов с учётом доли ответственности за соблюдение сроков; 2) Метрика результативности – оценивает, насколько группа реально способствует решению инцидента при его обработке (предотвращает «футбол»). Только комбинация этих метрик позволяет объективно оценить как скорость работы группы, так и её реальный вклад в решение инцидентов, а не просто перемещение их между группами.

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

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

ISO 27031 (Guidelines for ICT Readiness for Business Continuity) описывает вопросы управления ИТ-системами для гарантии обеспечения непрерывности бизнеса в соответствии с подходом, установленным в стандарте ISO 22301. Стандарт был ранее известен как BS 25777 и практически не изменился при переходе в семейство стандартов по информационной безопасности.

Вместо показателя SPI из EVM предлагается применять показатель, рассчитываемый как средневзвешенный рейтинг своевременности выполнения проектных задач. В этом методе рейтинг Ri можно рассчитывать как отношение плановой длительности выполнения задачи к фактической длительности, чтобы выровнять целевую динамику с Cost Performance Index (CPI). В качестве веса Wi может использоваться, например, трудоёмкость задачи. Альтернативно, можно оценивать сроки по отклонению от даты прохождения последней контрольной точки проекта, что даёт более точное представление о реальном соблюдении временных рамок.