Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
ИТ-ландшафт организации формируется как уникальный набор интегрированных между собой ИТ-систем, автоматизирующих куски бизнес-процесса. Эти системы, работая в комплексе, обеспечивают работу всего бизнес-процесса или его определённой части. Состав и структура ИТ-ландшафта зависят от специфики бизнеса и организационных потребностей.
Роль, отвечающая за учет расходных материалов, должна выполнять функции: ведение актуального учета наличия материалов, планирование закупок на основе статистики использования, настройка совместимости материалов с оборудованием, расчет затрат по методу FIFO, отчетность по использованию материалов и затратам, а также взаимодействие с поставщиками для своевременного пополнения запасов.
Принципы построения эффективного бизнес-процесса включают: ориентацию на конечный результат и удовлетворение потребностей клиентов; минимизацию избыточных действий и потерь времени; четкое распределение ответственности на каждом этапе; возможность измерения и контроля результатов; регулярную обратную связь и возможность улучшения; вовлеченность сотрудников в процесс оптимизации; устойчивость к небольшим изменениям внешней среды. Без этих принципов процесс становится неэффективным и неустойчивым.
Для организации взаимодействия между внутренними ИТ-подразделениями без использования OLA рекомендуется сосредоточиться на построении четких SLA и UC (Underpinning Contracts). Это позволит регулировать внутренние процессы с теми же принципами, что и внешние отношения с заказчиками. Важно определить ответственные области, уровни обязательств и механизмы контроля, но без введения дополнительного слоя терминов и документов (таких как OLA). Такой подход снижает риски излишней бюрократизации и избежит путаницы. Также необходимо пересмотреть организационную структуру для обеспечения эффективной коммуникации и контролю за выполнением обязательств, возможно, через создание централизованного арбитра, но без усложнения терминологии.
Целевые состояния предпочтительнее конкретных задач в дорожной карте потому что они предоставляют более высокий уровень абстракции, который сохраняет гибкость в условиях неизбежных изменений. В отличие от конкретных задач, которые быстро устаревают и требуют постоянной корректировки, целевые состояния фокусируются на том, каким должен стать продукт через определенное время, не привязываясь жестко к конкретному набору функциональных требований. Это позволяет команде сохранять ориентацию на главные цели бизнеса, даже если отдельные задачи меняются. Работа с целевыми состояниями помогает избежать вырожденного варианта дорожной карты, который просто повторяет содержимое бэклога, разбитое на кучки по месяцам. Такой подход позволяет сосредоточиться на ценности, которую приносит продукт, а не на количестве отработанных задач, лучше учитывает необходимые согласования и дополнительные работы, и дает более реалистичные прогнозы сроков, основанные на достижении определенного состояния продукта, а не на выполнении отдельных задач.
Для обеспечения актуальности данных о взаимосвязях между инфраструктурой и ИТ-услугами необходимо регулярно обновлять информацию о конфигурационных элементах и их связях. Если используется CMDB, следует настроить процесс автоматического сбора данных и установки связей. При использовании альтернативных методов нужно назначить ответственных за ручное обновление информации, установить регламент проверки данных и периодически проводить аудит. Без системного подхода к актуализации данных возможны ошибки и некорректная информация.
Анализ дерева отказов (FTA) – это дедуктивный метод, направленный на анализ нежелательных событий в системе посредством построения логической схемы, основанной на булевой логике (с использованием элементов «и», «или», «исключающее или», «не»). В ИТ-управлении его применяют для выявления путей возникновения отказов системы, нарушений функциональности или снижения доступности услуг. С его помощью можно разбить ИТ-услугу на базовые функциональные компоненты, для каждой из которых строится дерево отказов, показывающее все возможные причины сбоя. Это помогает при подготовке к возможным проблемам (управление непрерывностью), определении точек уязвимости (управление рисками), проектировании систем и выявлении корневых причин после инцидентов. Метод позволяет оценить вероятность критичных событий на основе статистики по базовым событиям, что полезно для прогнозирования уровня доступности и вычисления целевых показателей восстановления.
Качество записей об инцидентах критически важно для работы ITSM, так как от этого напрямую зависят сроки решения, корректное назначение ответственных, правильное определение приоритетов и эффективность анализа инцидентов. Низкое качество записей приводит к ошибкам в обработке инцидентов, увеличивает время восстановления услуг и снижает общую эффективность работы сервисной службы. Корректно оформленные записи позволяют быстро идентифицировать корневые причины проблем и предотвращать их повторное возникновение.
В SLA между отделом маркетинга и отделом продаж учитываются как количественные, так и качественные показатели. К основным показателям относятся: количество переданных потенциальных клиентов, их качество и платежеспособность, разбивка по профилям клиентов (как это принято в маркетинге). Отдел маркетинга обязуется предоставить определённое количество квалифицированных потенциальных клиентов, а отдел продаж - добиться определённого уровня конверсии этих клиентов в покупателей. При этом большое значение имеет не только общее количество клиентов, но и их соответствие целевой аудитории компании.
Процесс управления релизами необходим для организации безопасного и контролируемого внедрения изменений в информационные системы. Он обеспечивает координацию разработки, тестирования и развертывания релизов, а также объединяет несколько изменений в единый цикл внедрения. В зависимости от организационной структуры, управление релизами может быть либо отдельным процессом (в подразделении разработки), либо частью общего процесса управления изменениями (в подразделении эксплуатации).