Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Для обеспечения баланса между интересами заказчиков и пользователей ИТ-услуг необходимо создать четкую структуру взаимодействия, в которой техническая поддержка фокусируется на удовлетворении потребностей пользователей (удобство и стабильность), а менеджеры уровня услуг - на демонстрации ценности для заказчиков (бизнес-выгода и соотношение цена-выгода). Важно установить эффективные коммуникационные каналы между этими группами, чтобы недовольство пользователей оперативно доносилось до менеджеров уровня услуг, а бизнес-требования заказчиков правильно трансформировались в технические требования.
Процесс управления конфигурациями отвечает за контроль и актуальность данных об ИТ-активах, тогда как управление изменениями фокусируется на контроле жизненного цикла изменений, чтобы внедрять их с минимальными нарушениями работы сервисов. Эти процессы взаимодополняют друг друга, но не являются взаимозависимыми. Например, при интеграции процессов снижается вероятность проведения несанкционированных изменений, но конфигурационная база может оставаться актуальной и без формального управления изменениями, если реализованы другие механизмы контроля обновлений данных.
Владелец процесса управления уровнем услуг отвечает за то, чтобы процесс соответствовал своему назначению (fit for purpose). Его обязанности включают постановку процесса, разработку политик и стандартов, обеспечение процесса необходимыми ресурсами, определение целевых показателей для процесса (не для SLA), настройку качественного взаимодействия с процессом управления взаимоотношениями с бизнесом, проведение периодических аудитов и улучшение процесса. Владелец процесса обеспечивает направление и контроль работы процесса, определяя общую стратегию.
Совмещение ролей менеджера процесса негативно влияет на качество управления ИТ-сервисами, так как разделяет фокус и ресурсы сотрудника между операционными задачами и процессным управлением. Сотрудник, совмещающий управление процессом с руководством отделом, сосредоточен на краткосрочных операционных вопросах и может упускать из виду стратегические аспекты процесса. Это также создаёт конфликт интересов, поскольку менеджер может принимать решения, выгодные его собственному отделу, но не учитывающие интересы всей организации. В результате страдает качество и прозрачность управления, что снижает общую эффективность ИТ-сервисов.
При совмещении ролей менеджера и координатора изменений могут возникнуть проблемы с независимостью контроля и объективностью принятия решений. Человек, отвечающий за общий контроль изменений и одновременно обрабатывающий отдельные запросы, может быть предвзят в оценке собственной работы или испытывать конфликт интересов при принятии решений. Это может привести к снижению качества процесса управления изменениями, игнорированию потенциальных рисков и необоснованному ускорению процессов в ущерб их тщательности и безопасности
Продуктовый подход в управлении ИТ-разработкой предполагает фокусировку не на выполнении отдельных проектов, а на создании долгосрочной ценности продукта для бизнеса. Компании, которым необходимы частые выпуски изменений программного обеспечения, выбирают этот подход, так как он позволяет более гибко и оперативно реагировать на изменения рынка и потребности пользователей, повышая конкурентоспособность и эффективность разработки. В контексте современного динамичного рынка, где скорость выхода на рынок и частые обновления становятся критически важными, традиционные проектные подходы уже не могут обеспечить необходимую гибкость и скорость реагирования.
Основные проблемы при переходе сервис-провайдера в роль сервис-интегратора связаны с созданием единого контура ответственности. Технологически сложна интеграция систем разных компаний, обеспечения единого качества услуги и корректного отображения опций. Организационно трудно согласовать процессы взаимодействия между участниками, выстроить линию коммуникации с клиентом. Юридически возникают вопросы распределения ответственности между партнерами и регулирования претензий. Интеграторы часто не могут гарантировать, что изменения в одном элементе системы (например, выбор опции страхования) корректно отразятся во всей цепочке сервиса. Это приводит к ситуациям, когда клиент получает услугу, не соответствующую его ожиданиям, а при обращении за помощью сталкивается с перекладыванием ответственности между партнерами.
Применение неумелых действий в процессе внедрения изменений может привести к нескольким критическим рискам: трансформации заинтересованных сотрудников в нейтральных или противников, превращению партнеров в конкурентов или врагов, созданию новых проблем, превосходящих по сложности исходную ситуацию. Например, игнорирование интересов ключевых участников может вызвать сопротивление, а неграмотное распределение ресурсов — потерю доверия к проекту. Основной вывод — выбор стратегии должен быть сознательным и адаптированным под конкретную организацию.
Наличие типовой модели процесса не гарантирует организацию деятельности в компании, потому что модель процесса является всего лишь документом, описывающим как должна происходить работа. Для реальной организации деятельности требуется адаптация этой модели к конкретной компании с учетом её структуры, компетенций сотрудников, системы мотивации и других особенностей. Типовая модель процесса может быть одинаковой для разных компаний, но результаты её внедрения будут различаться в зависимости от того, как она была адаптирована и внедрена. Более того, сама модель не обеспечивает исполнение процесса, не гарантирует компетентность команды внедрения и не решает задачу контроля и оценки эффективности. Только правильная адаптация и последовательное внедрение модели процесса обеспечивают достижение желаемого результата.
Измерение только технических параметров не обеспечивает понимания того, насколько ИТ-сервис действительно соответствует бизнес-целям. Например, в случае электронной почты технически корректной может считаться отправка письма сервером сразу после нажатия кнопки, однако если доставка занимает восемь часов, то конечный пользователь будет недоволен. Для бизнеса важен именно конечный результат — своевременная доставка писем. То же самое касается рекламы в метро: формально система работала, но сбойное окно ухудшало восприятие рекламы, что негативно сказывалось на её эффективности. Конечный результат — это то, что видят пользователи и что влияет на бизнес-процессы.