Портал №1 по управлению цифровыми
и информационными технологиями

Бесплатная экспертная база знаний по управлению ИТ

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

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

Authors
25

авторов

Sources
440+

источников

Original
100%

оригинальный контент

Команда может делегировать ответственность за эксплуатацию продукта, внедрив практики инфраструктуры как код (IaC), управления конфигурацией через системы контроля версий и использования принципа неизменности узлов. Это позволяет команде сохранять контроль над конфигурациями и параметрами настройки middleware, которые должны управляться через CMS и автоматизированные процессы, а не через ручные вмешательства в работающие системы. Базовая инфраструктура, такая как IaaS, может быть полностью делегирована внешним поставщикам, что значительно снижает нагрузку на внутреннюю команду. При этом необходимо иметь четкие SLA и мониторинг за работой системы, чтобы быстро реагировать на возможные инциденты. Это позволяет держать критически важную эксплуатационную экспертизу внутри команды и при этом эффективно использовать сторонние ресурсы для базовых задач.
SLA аутсорсинг, интеграция услуг командная работа мониторинг общие вопросы менеджмента управление инцидентами управление конфигурациями, CMDB управление продуктами, продуктовый подход управление уровнем услуг, SLM
Андрей Труфанов (источник). Рейтинг вопроса: 230
Проблема наличия нескольких заказчиков у одной ИТ-услуги заключается в том, что разные подразделения компании могут предъявлять различные (иногда противоречивые) требования к одной и той же ИТ-услуге, при этом плательщиком может выступать третья сторона. Например, одно подразделение отвечает за продажи продукта и выступает как основной заказчик, а другое подразделение отвечает за бэк-офисные операции и является потребителем той же ИТ-услуги. Это создает сложности в определении ответственности, аллокации затрат и заключении SLA. ИТ-подразделению приходится выбирать между несколькими вариантами: заключать отдельные SLA со всеми заказчиками (что усложняет переговоры и размывает ответственность), рассматривать одно подразделение как заказчика, а другое как потребителя (что требует договоренностей между бизнес-подразделениями), или выделять разные ИТ-услуги для разных заказчиков (что увеличивает сложность каталога услуг).
SLA аллокация затрат, расчёт себестоимости услуг бизнес, ценность, бизнес-заказчик общие вопросы менеджмента управление каталогом ИТ-услуг управление продуктами, продуктовый подход управление уровнем услуг, SLM экономика и финансы
Дмитрий Исайченко (источник). Рейтинг вопроса: 230
Конфликт возникает из-за разного понимания требований бизнеса и возможностей продуктовых команд. Бизнес стремится закрепить сроки для планирования бюджета и стратегии, тогда как команда сталкивается с непредсказуемостью разработки. При этом команды могут формально следовать гибким методологиям, но на практике работать в рамках дедлайнов, что противоречит принципам организации равномерного потока и снижает эффективность.
бизнес, ценность, бизнес-заказчик бюджетирование, планирование затрат Канбан, WIP-лимиты командная работа общие вопросы менеджмента стратегия эффективность, оптимизация
Игорь Гутник (источник). Рейтинг вопроса: 230
ITIL 4 предлагает решать проблему разобщенности через принцип 'Используйте целостный подход' (Think and work holistically) и через рассмотрение четырех аспектов управления ИТ-услугами. Этот принцип подразумевает необходимость понимания того, как все части организации работают вместе интегрированным образом. Вместо того чтобы фокусироваться на отдельных элементах (процессах без учета инструментов и компетенций, или наоборот), ITIL 4 предлагает рассматривать четыре взаимосвязанных аспекта: организации и люди, информация и технологии, партнеры и поставщики, потоки создания ценности и процессы. Для устранения разобщенности также необходимо формировать организационные структуры, ориентированные на сотрудничество, развивать культуру доверия и прозрачности, обеспечивать достаточные компетенции сотрудников и правильно определять взаимодействие с партнерами. Важно рассматривать процессы не изолированно, а как часть потоков создания ценности, что обеспечивает целостное преобразование входов в результаты, воспринимаемые клиентом.
ITIL аутсорсинг, интеграция услуг бизнес, ценность, бизнес-заказчик Канбан, WIP-лимиты поток создания ценности (Value Stream) управление отношениями, взаимодействие, BRM
Игорь Фадеев (источник). Рейтинг вопроса: 230
Не рекомендуется брать инциденты в работу заранее для улучшения показателя реакции, потому что такая практика маскирует реальные задержки в обработке инцидентов. Когда инцидент формально берется в работу, но фактически остается в очереди до появления возможности к нему приступить, это искажает измерения и не позволяет выявить истинные узкие места в процессе. Кроме того, такое поведение может привести к увеличению общего времени решения инцидентов, так как ресурсы распределяются неоптимально, а внимание распыляется на формальное обслуживание задач вместо их реального решения. В конечном счете это ухудшает эффективность всей системы управления инцидентами.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды постоянное улучшение, совершенствование, CSI, PDCA управление инцидентами управление процессами, ИТ-процессы эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 230
Частыми ошибками являются недостаточный анализ текущих проблем, игнорирование оптимизации процессов и чрезмерное увлечение новой технологией без понимания реальных потребностей. Также часто не учитываются требования к новой системе, и миграция воспринимается как панацея от всех проблем в ИТ вместо решения конкретных задач. Это приводит к неоправданным затратам и низкой отдаче от вложенных ресурсов.
автоматизация ИТ-процессов, ПО для ITSM и ESM аллокация затрат, расчёт себестоимости услуг общие вопросы менеджмента экономика и финансы эффективность, оптимизация
Евгений Шилов (источник). Рейтинг вопроса: 230
Пользователи не оставляют оценку после получения услуги, даже если изначально планировали это сделать, из-за возникающих барьеров и неопределенностей в процессе. Например, в случае с государственными услугами, когда заявленное бесплатное SMS на самом деле оказалось платным, это вызывает недоверие и снижает мотивацию. В случае с коммерческим банком требование регистрации на стороннем сайте для размещения отзыва создает дополнительный этап, который многим кажется излишним. Пользователь готов оценить услугу, но только если процесс простой, понятный и не вызывает сомнений в его прозрачности.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды мотивация персонала, стимулирование поддержка пользователей, Service Desk, Help Desk
Артём Мукосеев (источник). Рейтинг вопроса: 230
Шестой принцип DevOps по DASA 'Автоматизируйте всё, что можете' охватывает два основных аспекта автоматизации: во-первых, автоматизацию процессов разработки программного обеспечения, включая непрерывную поставку (continuous delivery), которая сама подразумевает непрерывную интеграцию (continuous integration) и непрерывное развёртывание (continuous deployment). Во-вторых, автоматизацию всего инфраструктурного ландшафта, что в современных практиках реализуется через подход 'инфраструктура как код' (Infrastructure as Code). Такой широкий взгляд на автоматизацию позволяет снизить человеческий фактор, ускорить процессы разработки и доставки, повысить надёжность и воспроизводимость систем, а также обеспечить возможность быстрого масштабирования и восстановления систем при необходимости.
DevOps, CI/CD управление конфигурациями, CMDB управление релизами
Игорь Гутник (источник). Рейтинг вопроса: 230
Матрица взаимодействия функций и процессов строится следующим образом: по вертикали размещаются функции (отделы, группы), а по горизонтали — процессы. Каждая ячейка матрицы на пересечении функции и процесса означает участие данной функции в реализации данного процесса. Это участие подразумевает, что функциональный руководитель отвечает за предоставление необходимых ресурсов для выполнения процесса, даже если он формально не несет функциональных обязанностей в этом процессе (например, не является ответственным в матрице RACI). С помощью этой матрицы можно определить, за какие метрики процессов будет отвечать каждый функциональный руководитель. Например, если отдел участвует в процессе управления инцидентами, то руководитель этого отдела будет оцениваться по метрикам, связанным с эффективностью работы его сотрудников в этом процессе, таким как доля инцидентов, принятых в работу своевременно или решенных с первой попытки.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды общие вопросы менеджмента управление инцидентами управление отношениями, взаимодействие, BRM управление процессами, ИТ-процессы эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 230
В исследовании Project Oxygen использовались два основных KPI для оценки эффективности менеджеров. Первый KPI – оценка эффективности деятельности менеджера, которая оценивает, насколько успешно руководитель справляется с поставленными задачами и целями. Второй KPI – оценка менеджера сотрудниками, которая отражает мнение подчинённых о качестве работы своего руководителя. Эти показатели дополнялись данными, полученными в ходе интервью, анализа по методу 360 градусов за несколько лет и специальных опросов уходящих из компании сотрудников. Такой комплексный подход позволил выявить факторы, которые действительно влияют на результативность руководителя и его команды.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды командная работа общие вопросы менеджмента эффективность, оптимизация
Олег Скрынник (источник). Рейтинг вопроса: 230
« 1 ... 111 112 113 ... 617 »