Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.

6170+
вопросов и ответов

25
авторов

440+
источников

100%
оригинальный контент
Чтобы определить, является ли ИТ-система продуктом в контексте продуктового подхода, нужно проверить выполнение трех критериев: 1) наличия динамически появляющихся и меняющихся возможностей в области применения системы; 2) необходимости активного и постоянного развития системы; 3) высокой неопределенности в начальный момент. Также следует учитывать, есть ли целевая аудитория, готовая платить за использование системы, необходимость в монетизации, изменении позиционирования и адаптации бизнес-модели. Если система направлена на внешних клиентов с их меняющимися потребностями, она, скорее всего, является продуктом. Если же система внутренняя, стабильная в требованиях и без необходимости в постоянном развитии для удовлетворения внешнего рынка, она не является продуктом в контексте продуктового подхода.
Поле «Срочность» с градацией (низкая, средняя, высокая) часто используется бизнесом для завышения приоритета запросов, так как максимальная отметка «высокая» кажется единственно правильным выбором при любом запросе. Это приводит к перекосу в управлении изменениями: важные emergency-изменения теряются среди множества ненужно приоритизированных изменений, а процесс принятия решений замедляется из-за необходимости перепроверки каждого случая. Кроме того, сама градация не учитывает контекст — например, «высокая срочность» может означать как реальную угрозу для бизнеса, так и личную заинтересованность сотрудника.
Традиционные KPI фокусируются только на соблюдении Tmax, игнорируя тот факт, что даже кратковременные простои вблизи лимита могут нанести бизнесу значительный ущерб. Например, при Tmax = 4 часа инцидент, устраненный за 3,9 часа, формально считается успешным, хотя за это время бизнес мог потерять клиентов или прибыль. Новый подход учитывает реальное влияние на операции через Tmin, что позволяет выстроить более справедливую систему оценки, ориентированную на реальные результаты, а не формальное соблюдение сроков.
Финансовая система координат помогает в синхронизации бизнеса и ИТ, так как финансы представляют собой общий язык и метрику, понятную обеим сторонам. В игре Grab@Pizza это проявляется в том, что обсуждение вопросов через призму финансовых показателей позволяет бизнес-и ИТ-специалистам находить общие точки соприкосновения и принимать совместные решения. Для эффективного использования этой системы координат необходима общая воля сторон к сотрудничеству и готовность выстраивать процессы с учетом финансовых последствий всех решений и изменений.
В тексте приведены два примера имитации активности: массовое закрытие проблем с кодом 'Решение нецелесообразно', при котором KPI остается близким к единице, несмотря на отсутствие реальной пользы, и регистрация дублей проблем, которые сразу закрываются как дубликаты. Эти действия создают видимость высокой активности, но не добавляют ценности процессу управления проблемами.
Важно отделить ответственность за принятие решений о приоритетах от ИТ-руководителя, потому что ИТ-департамент по сути является исполнителем, а не владельцем бизнес-требований. Бизнес-цели и стратегические приоритеты должны определяться самим бизнесом, а не техническими специалистами. Когда ИТ-руководитель вынужден принимать решения о том, какие задачи важнее, он попадает в невыгодное положение: бизнес-подразделения будут винить его в том, что их задачи не выполнены, хотя он просто следовал указаниям, которые никогда официально не были зафиксированы. Перенос ответственности на бизнес-руководителей обеспечивает прозрачность и подотчетность в процессе принятия решений.
Вероятностный характер поступления инцидентов, описанный как стохастические отклонения, существенно влияет на среднее время их решения. Инциденты обычно распределяются неравномерно в течение дня с пиками нагрузки (распределение в форме 'верблюда'), что создает эффект очереди. Даже при постоянной производительности персонала, если инциденты приходят неравномерно, среднее время их решения может быть значительно выше, чем при равномерном распределении. Например, 24 инцидента, решаемые с производительностью 20 минут каждый, теоретически должны обрабатываться за 20 минут на инцидент при равномерном поступлении, но при массовом поступлении утром среднее время возрастает до 4 часов 10 минут. Это связано с тем, что последующие инциденты вынуждены ждать, пока предыдущие будут обработаны, что приводит к экспоненциальному росту среднего времени при увеличении количества одновременно поступающих инцидентов.
Алгоритмы выравнивания и профилирования нагрузки могут привести к неравномерной нагрузке по причине того, что они узаконивают принцип «дурака работа любит» – наиболее продуктивные сотрудники получают больше задач только потому, что быстрее их обрабатывают. Вместо того чтобы учитывать реальную сложность задач и текущую эффективность работы, эти алгоритмы создают ситуацию, когда трудолюбивые сотрудники перегружаются, а менее эффективные, наоборот, остаются с меньшим объемом работы. Это не способствует оптимальному распределению нагрузки в команде и может снизить общую производительность.
С помощью CLD можно косвенно оценить факторы, которые сложно измерить напрямую, анализируя их причинно-следственные связи с другими элементами системы. Например, прямое измерение Cost per change / release может быть сложным, так как требует точного учета всех ресурсов. Однако CLD показывает, что эффективность использования ресурсов связана с уровнем стандартизации и автоматизации изменений, а также с успешностью первоначальной реализации (First-Time Implementation Rate). Измеряя эти косвенные показатели, можно оценить эффективность использования ресурсов, даже не измеряя напрямую стоимость изменений.
Итоговый показатель удовлетворенности заказчика ИТ-услугами при использовании прямого подхода вычисляется на основе ответов на ключевые вопросы, оцениваемые по шкале от 0 до 1 (где 0 – полное несоответствие, 1 – полное соответствие). Для определения интегрального показателя применяется взвешенное арифметическое усреднение отдельных оценок, где веса могут учитывать важность тех или иных аспектов услуги для заказчика. Такой метод позволяет получить общий показатель, отражающий комплексную оценку удовлетворенности.