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

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

25
авторов

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

100%
оригинальный контент
Вместо этапа 'Отложено' в потоке создания ценности можно использовать несколько альтернатив: 1) Вернуть задачу на вход потока, если она не может быть продолжена, освободив слот для другой задачи; 2) Внедрить механизм быстрого разрешения блокеров, чтобы устранять причины задержек в течение короткого времени; 3) Установить строгие лимиты времени на разрешение внешних зависимостей; 4) Изменить дизайн потока таким образом, чтобы он мог обходить блокирующие факторы, например, через параллельные ветки работы; 5) Создать отдельный быстрый поток для разрешения блокеров, который будет обслуживать основной поток. Главное, чтобы задача либо двигалась вперед, добавляя ценность, либо покидала поток, высвобождая ресурсы.
Понятие «средняя температура по больнице» отражает недостаток усредненных метрик: они скрывают разнообразие отдельных случаев. Например, среднее время решения может быть приемлемым, но при этом половина инцидентов устраняется мгновенно, а другая половина — только в последний момент. Это не позволяет оценить реальное влияние на бизнес, так как кратковременные простои не критичны, а длительные — могут причинять серьезный ущерб даже при соблюдении среднего показателя.
Ограничение охвата процесса при тестировании на бумаге помогает снизить нагрузку на сотрудников и уменьшить объём ручной работы, связанной с неавтоматизированными операциями. Это позволяет сфокусироваться на ключевых участках процесса, проверить их на практике и получить достоверные данные для будущей автоматизации, не отвлекаясь на второстепенные детали. Кроме того, ограниченный тестовый режим уменьшает риск потери мотивации у участников и способствует более точному выявлению слабых мест в работе регламента.
Переименование операнда C в R (например, от 'Resolved') делает формулу более понятной и логичной, так как явно указывает, что в числителе учитываются только решенные проблемы, принесшие реальную пользу. Это упрощает интерпретацию метрики для сотрудников и менеджеров, снижает вероятность ошибок в расчетах и подчеркивает фокус на результатах с ценностью.
Вендоры активно продвигают готовые решения, чтобы увеличить объемы продаж и привлечь больше клиентов. Для достижения этих целей они используют свой авторитет и бренд, создавая иллюзию универсальности и эффективности своих решений. Это позволяет им расширять партнерскую сеть и увеличивать количество проектов, что в свою очередь способствует росту продаж. Однако такие решения часто не учитывают специфику конкретных компаний, что приводит к проблемам в долгосрочной перспективе.
Да, количество аспектов управления проектами может отличаться от шести, рекомендованных в PRINCE2®. Хотя методология определяет конкретный набор из шести аспектов (Сроки, Затраты, Охват, Качество, Выгоды, Риск), это не означает, что других аспектов быть не может. Если для конкретной организации важна дополнительная характеристика проекта и есть (или необходим) соответствующий механизм управления этой характеристикой, то можно выделить дополнительный аспект. Главное, чтобы каждый аспект представлял собой независимый параметр, имеющий свою методику измерения и контроля, и вносил значимый вклад в общее управление проектом.
CMDB (Configuration Management Database) необходима для хранения точной и надёжной информации о конфигурационных элементах, которые требуются для предоставления ИТ-услуг. Её основное назначение — обеспечить контроль над активами, задействованными в сервисах, и предоставлять актуальные данные о них в нужное время и в нужном месте. Это позволяет поддерживать согласованность инфраструктуры, минимизировать ошибки при проведении изменений и ускорять процессы восстановления работоспособности систем.
Операционный бюджет ИТ формируется через последовательность шагов: получение бизнес-планов через взаимодействие с владельцами бизнеса (BRM/SLM), согласование планов потребления услуг с заказчиками (SLM и управление емкостью сервисов), разработка планов ресурсного обеспечения включая кадры (управление емкостью ресурсов), расчет стоимости ресурсов и услуг с учетом косвенных затрат (Финансовый менеджмент в ИТ), и финальный расчет стоимости услуг по потребителям с обоснованным формированием бюджета. Этот процесс требует тесной увязки бизнес-потребностей, технических возможностей и финансового планирования.
ITSM-проект становится проблемой из-за его восприятия новым руководством как ненужного элемента - "чемодана без ручки", который неудобно нести, но и выбросить жалко. Поскольку проект уже завершен и оплачен, его эффективность не сразу очевидна, особенно когда основной фокус нового руководства сосредоточен на срочных финансовых показателях. Новые руководители, не имеющие опыта работы с ITSM, могут не понимать его ценность и пытаться свернуть или проигнорировать внедренные процессы, хотя эти процессы потенциально могли бы улучшить управление ИТ-сервисами и снизить операционные затраты в долгосрочной перспективе.
Проактивная составляющая процесса «Управление проблемами» представляет собой усилия по выявлению потенциальных проблем до того, как они вызовут инциденты. Это включает анализ данных, тенденций и паттернов для обнаружения уязвимостей в инфраструктуре, оценку рисков, проведение регулярных аудитов и технические обзоры с целью обнаружения скрытых проблем. Проактивная работа направленна на предотвращение инцидентов вместо реактивного реагирования на уже произошедшие события и является важной частью минимизации общего влияния проблем на бизнес.