Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Оценку зрелости рабочего процесса гибких команд можно проводить через самодиагностику команд или при помощи агентов изменений - специалистов, сопровождающих переход к новой организации труда. Можно привлекать и внешних экспертов с развитыми инструментами диагностики. Для оценки необходимо создать систему показателей, позволяющих измерить соответствие рабочего процесса команды требованиям организации. Эти требования зависят от темпов и направления развития бизнеса и ожиданий, накладываемых на команды разработки. Важно развивать методологическую базу, включающую не только распространенные гибкие практики (Scrum, пользовательские истории), но и практики для развития архитектурных решений, сервис-ориентированную разработку, систему непрерывного совершенствования качества и улучшение процессов.
Основные ошибки при внедрении сервисного подхода включают: фокус на технические метрики вместо бизнес-ценностей, отсутствие вовлечения бизнес-заказчиков, неадекватное определение уровня обслуживания (SLA), избыточная формализация процессов в ущерб гибкости, и игнорирование обратной связи от конечных пользователей. Также распространенная ошибка — формальное переименование ИТ-активов как услуг без изменения образа мышления сотрудников и структуры взаимодействия с клиентами.
Жизненный цикл ИТ-услуг в рамках парадигмы ITSM включает пять основных этапов: стратегию услуг (определение бизнес-потребностей и стратегического планирования), дизайн услуг (проектирование и разработку сервисов), переход к эксплуатации (внедрение новых или изменённых услуг), эксплуатацию услуг (повседневное предоставление и поддержку сервисов) и постоянное улучшение услуг (анализ и оптимизацию процессов). Каждый этап имеет свои ключевые процессы, цели и результаты, что создаёт непрерывный цикл управления услугами от концепции до прекращения предоставления.
Управление активами программного обеспечения (SAM) представляет собой практику, направленную на интеграцию людей, процессов и технологий для систематического отслеживания, оценки и управления лицензиями ПО, а также их использованием в организации. Оно включает учет активов, контроль соответствия требованиям регуляторов, оптимизацию расходов на ПО, снижение рисков и внедрение процессов, позволяющих улучшить финансовые показатели организации. Цель SAM — сократить ИТ-расходы, оптимизировать использование человеческих ресурсов и минимизировать риски, связанные с владением и управлением программным обеспечением.
Процесс управления изменениями остается важным, потому что современная ИТ-инфраструктура представляет собой многосвязную систему взаимодействующих компонентов. Наибольший риск возникает при изменениях, которые влияют на совокупность приложений и сервисов комплексно. Даже при итеративном развитии приложений необходима коммуникация знаний об изменении, его влиянии и совместной подготовке к преобразованию, чтобы снизить риски возникновения инцидентов.
В случае внутреннего ИТ-подразделения заказчиками являются подразделения или лица, которые так или иначе влияют на формирование задач для ИТ и влияют на формирование бюджета ИТ. Это могут быть различные бизнес-подразделения, руководители которых определяют потребности и заинтересованы в повышении эффективности работы через ИТ. При этом не все подразделения, выступающие в роли заказчиков, непосредственно связаны с основным бизнесом компании - например, бухгалтерия может быть заказчиком для ИТ, хотя сама является поддерживающей функцией.
Важно объяснить всем участникам процесса, что метрики служат не для наказания, а для выявления проблем в системе. Например, если целевое значение метрики не достигается, это сигнал к поиску причин: возможно, не хватает ресурсов, нужно обучение или изменения в самом процессе. Такой подход помогает перевести фокус с личной ответственности сотрудника на общее улучшение процесса.
В контексте KPI для руководителей поддержки термин "tension-партнер" относится к дополнительной метрике, которая балансирует основную метрику и предотвращает фокус на одном аспекте работы в ущерб другим. Например, если основной KPI - своевременность решения инцидентов, то tension-партнером может быть своевременность выполнения плановых работ, которая не позволяет руководителю полностью сосредоточиться только на экстренных задачах. Это создает "напряжение" между разными аспектами работы и стимулирует руководителя поддерживать баланс между оперативным реагированием и стратегическим развитием системы, предотвращая выгорание команды и накопление технического долга.
Компромисс в ITSM, при котором управление разработкой отделяется от эксплуатации, влияет на взаимодействие между ИТ и бизнесом, создавая барьеры для коммуникации. Бизнес остается недовольным отсутствием гарантий по срокам и качеству новых разработок, а ИТ-подразделение не может полноценно взять на себя ответственность за результат. Без сквозной системы ответственности, охватывающей все этапы жизненного цикла услуги, сложно построить партнерские отношения между ИТ и бизнесом, основанные на сервисных принципах. Это приводит к тому, что ИТ воспринимается как вспомогательная функция, а не как источник ценности для бизнеса.
В новой модели ИТ-подразделение перестает быть «фейковым» субъектом взаимодействия и становится объектом — надежным ресурсом и качественным профессиональным инструментом. ИТ предоставляет свои знания, умения и навыки бизнесу, который полностью отвечает за владение данными, информационными системами, управление рисками, коммуникации и финансовые решения. ИТ обслуживает бизнес, предоставляя технологические возможности для реализации его целей, но не принимает стратегических решений, которые теперь полностью лежат на бизнесе.