CMDB (Configuration Management Database) — база данных управления конфигурациями, используемая для хранения информации об ИТ-активах и их взаимосвязях. Она необходима для точного отслеживания конфигурации систем, учета изменений, управления инцидентами и обеспечения стабильности работы ИТ-инфраструктуры. Для расходных материалов CMDB помогает контролировать их привязку к оборудованию, собирать статистику использования и управлять затратами без увеличения объема данных.

В условиях строгих ограничений на численность штата ИТ-руководители активно используют аутсорсинг и аутстаффинг для выполнения задач. Также широко практикуется передача функций в регионы с более низким уровнем заработных плат – например, создание центров разработки и поддержки в городах России, отличных от Москвы и Санкт-Петербурга, таких как Волгоград, Нижний Новгород и Новосибирск. Это позволяет частично сократить затраты на персонал, сохранив необходимый объем работы.

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

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

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

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

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

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

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

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