PCF был разработан в 1992 году Американским центром эффективности и качества (APQC), который продолжает поддерживать и развивать этот стандарт. Текущая версия PCF - 6.1.0, выпущенная в марте 2014 года. APQC является автором и поддерживающей организацией данного стандарта, обеспечивающей его постоянное развитие и адаптацию к меняющимся требованиям бизнеса.

Для получения качественных ответов рекомендуется ограничиться 2-3 вопросами. Большое количество вопросов повышает риск отсутствия ответов или получения случайных, невнимательно заполненных ответов, так как пользователи часто не хотят тратить много времени на такие опросы.

Для создания ценностного предложения с использованием эмпатии следует применить несколько ключевых методов. Во-первых, важно сосредоточиться на ценности для клиента, а не на бизнес-процессах компании, что соответствует руководящему принципу ITIL4 «Фокусируйтесь на ценности». Это значит, что процессы должны быть гибкими и адаптированы под потребности клиентов, следуя философии Agile — «Люди и взаимодействие – важнее процессов и инструментов». Во-вторых, необходимо создавать карты путешествий клиента, чтобы лучше понимать его путь взаимодействия с продуктом или услугой. Это позволяет выявлять ключевые точки контакта и улучшать их. Также полезно активно взаимодействовать с клиентами и проводить наблюдения за их поведением, чтобы понять, что на самом деле важно для них. Использование информации из первых рук поможет улучшить продукт, сделать его более удобным и удовлетворяющим скрытые потребности клиентов, формируя тем самым ценность для них.

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

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

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

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

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

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

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