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

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

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

Использование статических весов не решает проблему игнорирования отдельных областей ответственности, потому что даже при больших весах отклонений от статического веса, если у сотрудника много KPI, частичное невыполнение по одной метрике снизит общую оценку пропорционально её весу, но не достаточно критично. Например, при 10 равнозначных KPI (вес 10% для каждого) полный провал одного показателя снижает средний результат всего на 10%. Поэтому работник может решить: "Черт с ними с 10%, я не буду делать эту работу и сосредоточусь на остальных". Статические веса не усиливают значимость провала по какому-то конкретному показателю в зависимости от ситуации.

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

Люди склонны действовать вместо анализа из-за глубоко укоренившегося убеждения, которое называется Action Bias. Это убеждение работает на подсознательном уровне: мы автоматически считаем, что действие всегда лучше бездействия, даже если нет полной информации о ситуации. Когда мы сталкиваемся с таким выбором, подсознательно уже знаем «правильный» ответ (что нужно действовать), и уже потом придумываем обоснование для своих действий. Это создает иллюзию рациональности, тогда как решение принимается на основе убеждения, а не анализа фактов.

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

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

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

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