Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
В ИТ-проектах особенно важно следить за балансом между активностью и аналитикой, потому что работа в этой области часто носит совместный характер и состоит из множества взаимосвязанных этапов. Непродуманные действия на одном этапе могут создать серьезные проблемы на последующих этапах, что приведет к дорогостоящим переездам и задержкам. Из-за высокой сложности и изменчивости требований в ИТ важно тратить время на анализ и уточнение задач, чтобы не создавать ненужного продукта. Кроме того, иллюзия загруженности ресурсов, создаваемая Action Bias, может замаскировать реальные проблемы в процессе и помешать их своевременному выявлению и решению.
Портфель услуг крайне важен для внешнего ИТ-провайдера, так как он помогает формировать конкурентные преимущества и стратегию развития. Ответы на ключевые вопросы портфеля услуг (почему клиенты должны покупать услуги, почему именно у данного провайдера, как ценообразование и монетизация, сильные и слабые стороны) позволяют внешнему провайдеру оставаться конкурентоспособным на рынке, адаптироваться к изменениям и правильно распределять ресурсы. Эти ответы должны быть динамичными и актуальными, а не статичными решениями прошлых лет.
Work-in-progress limit (лимит текущей загрузки) в методологии Kanban — это ограничение на максимальное количество задач, которые могут находиться в статусе "в работе" одновременно. Он необходим для предотвращения перегрузки сотрудников, повышения фокуса на текущих задачах и ускорения завершения работ. Такой подход минимизирует переключение между задачами, сокращает время выполнения и повышает качество результатов. Лимиты помогают выявить узкие места в процессе и оптимизировать поток работ.
Для начального этапа внедрения бизнес-ориентированного измерения доступности рекомендуется использовать упрощённую схему, которая включает: выделение функциональных блоков на стороне заказчика; сопоставление этих блоков с ИТ-системами; определение базовых критериев доступности для ИТ-компонентов; реализацию сбора данных о доступности; расчёт доступности ИТ-обеспечения функциональных блоков на основе доступности соответствующих ИТ-компонентов. Эта схема позволяет начать измерения без чрезмерной сложности и ресурсных затрат, предоставляя базовое понимание влияния ИТ-доступности на бизнес. Затем, по мере роста зрелости, можно постепенно совершенствовать систему, добавляя детали и переходя к учёту конкретных критических бизнес-функций (VBF).
Различие между назначением (purpose), целями (goals) и задачами (objectives) в ITIL важно, потому что: - Оно помогает избежать путаницы при проектировании и управлении процессами. - Каждый уровень отвечает своим задачам: назначение определяет базовую функцию, цели задают измеримые результаты на период, задачи описывают технологию реализации. - Ответственность распределяется между разными ролями (дизайнер, владелец, менеджер процесса). - Иерархия обеспечивают согласованность процессов с бизнес-требованиями, так как цели процессов напрямую связаны с проектными целями и бизнес-обоснованием. Без этого разделения сложно контролировать эффективность процессов, так как стратегические, тактические и оперативные аспекты переплетаются.
В потоке ценность должна добавляться на каждом этапе, потому что сама концепция потока создания ценности предполагает непрерывное движение к конечному результату, при котором каждый шаг приближает задачу к завершению и делает ее более ценной для конечного получателя. Если какой-то этап не добавляет ценности, то он является потенциальным источником потерь, замедления и неэффективности. Бережливое производство учит, что незавершенная работа есть потери, поэтому поток должен быть организован таким образом, чтобы избежать простоев и неэффективных промежуточных состояний, фокусируясь на постоянном создании ценности.
Для минимизации искажения метрик важно: выбирать такие показатели, на которые сотрудник не может напрямую влиять; комбинировать количественные и качественные данные; использовать несколько взаимодополняющих метрик, чтобы получить целостную картину; и проводить регулярный аудит и анализ отклонений. Например, если основная метрика — доля закрытых задач, стоит также учитывать отзывы клиентов и количество повторных обращений по той же проблеме.
Ориентация только на формальные метрики при управлении ИТ-процессами приводит к нескольким негативным последствиям. Во-первых, некоторые данные трудно собрать, есть сомнения в их объективности или они не помогают в принятии управленческих решений. Во-вторых, может происходить замена здравого смысла набором измеримых показателей, хотя некоторые процесс не требуют измерений. В-третьих, отдельные KPI различных процессов могут не складываться в целостную систему оценки деятельности ИТ-отдела в целом, что создает фрагментарную "лоскутную" картину вместо единой системы показателей.
CMDB обеспечивает прозрачность ИТ-инфраструктуры и взаимосвязей между компонентами, что критически важно для управления изменениями. Перед внедрением любого изменения специалисты могут использовать данные CMDB для анализа того, какие именно конфигурационные единицы будут затронуты и как это может повлиять на конечные услуги. Это позволяет предсказать потенциальные проблемы, спланировать стратегию внедрения изменений с минимальным риском и подготовить план отката в случае непредвиденных обстоятельств. CMDB также фиксирует историю изменений, что помогает в аудите и анализе причин возникновения проблем.
Согласно ITIL 4, при формировании сервисного предложения (service offering) используются три типа сущностей: 1. Товары (goods) – то, что передаётся потребителю, после чего сам потребитель отвечает за их использование (например, wifi-маршрутизатор в подарок при подключении домашнего интернета). 2. Доступ к ресурсам – ресурсы, к которым получает доступ потребитель (например, сеть, к которой подключается абонент, или почтовый/прокси/p2p сервер). 3. Сервисные операции (service actions) – деятельность, выполняемая представителями поставщика, потребителя или ими совместно (например, взаимодействие со службой поддержки). Эти три типа сущностей позволяют комплексно описать то, что поставщик услуги предлагает потребителю.