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

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

25
авторов

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

100%
оригинальный контент
Владелец процесса отвечает за соответствие процесса его назначению, занимается постановкой процесса, разработкой политик и стандартов, определением целевых показателей для процесса и обеспечивает стратегическое направление. Менеджер процесса отвечает за операционное управление процессом - планирование, координацию активностей, управление исполнителями, мониторинг и отчётность. Владелец процесса больше занимается стратегическими аспектами, определяя 'куда идём', тогда как менеджер процесса обеспечивает ежедневное функционирование процесса. Роль менеджера процесса может быть совмещена с ролью владельца процесса.
Основная тема книги - построение каталога ИТ-услуг и организация Service Level Management (SLM) в ситуациях, когда ИТ-подразделение находится в составе компании или группы компаний. Книга подробно рассматривает методы формирования каталога ИТ-услуг, разделения его на каталог для заказчиков (Service Catalog) и каталог для пользователей (Service Request Catalog), а также рекомендации по внедрению ITSM. Авторы предлагают рассматривать бизнес-процессы предприятия как основной источник информации для формирования бизнес-ориентированного каталога ИТ-услуг.
Из многомесячной практики учета рабочего времени можно сделать два основных вывода: во-первых, реальные сложности и временные затраты на ведение учета значительно меньше, чем их представляют ('нет так страшен черт, как его малюют'); во-вторых, невозможно точно оценить эффективность какой-либо методики, не попробовав её на практике ('пока сам не попробуешь — не узнаешь').
Value Streams в IT4IT и процессы ITIL v3 имеют прямое соответствие, хотя и структурированы по-разному. В IT4IT определены четыре основных Value Stream'a: Strategy to Portfolio (S2P), Requirement to Deployment (R2D), Request to Fulfill (R2F) и Detect to Correct (D2C). Каждый Value Stream состоит из нескольких функциональных компонентов. Например, Value Stream 'Request to Fulfill' включает в себя функциональные компоненты, которые непосредственно соответствуют множеству процессов из ITIL v3, таких как управление запросами, управление инцидентами, управление проблемами и управление уровнями услуг. Аналогично, Value Stream 'Detect to Correct' соотносится с процессами управления непрерывностью и доступностью. Таким образом, хотя IT4IT объединяет процессы в более крупные потоки создания ценности, практические функции и действия, описанные в этих потоках, совпадают с процессами ITIL v3.
Менеджеры процесса должны отслеживать метрики, отражающие эффективность всего процесса: время прохождения процесса (cycle time), количество ошибок или повторных работ (defect rate), удовлетворенность заказчика результатом процесса, затраты на выполнение процесса, соблюдение сроков этапов, коэффициент использования ресурсов. Важно, чтобы KPI были сквозными и оценивали не отдельные подразделения, а результат всего процесса, так как это позволяет менеджеру процесса сосредоточиться на улучшении целостной работы, а не на локальной оптимизации отдельных частей.
Для выхода из сложившейся ситуации необходимы структурные меры, направленные на разрушение коммуникационных барьеров между командами и улучшение синхронизации планов развития. Следовало бы создать межфункциональные группы для решения кросс-функциональных проблем и регулярного обмена информацией. Необходимо пересмотреть баланс между развитием новых функций и поддержкой текущих систем, возможно, выделив отдельные ресурсы на укрепление стабильности и надежности основных сервисов. Важно внедрить системы мониторинга и отчетности, которые помогут бизнесу видеть операционные проблемы на ранних стадиях. Также следует провести анализ технического долга и разработать план его постепенного погашения, чтобы предотвратить будущие кризисы. Наконец, необходимо сосредоточиться на удержании кадров, улучшив условия труда и создав возможности для профессионального развития сотрудников, занимающихся поддержкой систем.
Да, количество одновременно проводимых диагностик обязательно нужно ограничивать. Это важно потому, что ключевой ценностью является не сам факт проведения диагностики и затраченные ресурсы, а качество полученных результатов и их практическая применимость. Управленческий и методический ресурсы обычно ограничены, поэтому контроль над количеством одновременных диагностик (WIP limit) обеспечивает лучшее качество каждой диагностики, своевременную обработку результатов и возможность действенной поддержки команд. Это позволяет создать устойчивый поток диагностических мероприятий без перегрузки как диагностируемых команд, так и проводящих диагностику специалистов.
Согласно ITIL 4, при формировании сервисного предложения (service offering) используются три типа сущностей: 1. Товары (goods) – то, что передаётся потребителю, после чего сам потребитель отвечает за их использование (например, wifi-маршрутизатор в подарок при подключении домашнего интернета). 2. Доступ к ресурсам – ресурсы, к которым получает доступ потребитель (например, сеть, к которой подключается абонент, или почтовый/прокси/p2p сервер). 3. Сервисные операции (service actions) – деятельность, выполняемая представителями поставщика, потребителя или ими совместно (например, взаимодействие со службой поддержки). Эти три типа сущностей позволяют комплексно описать то, что поставщик услуги предлагает потребителю.
Основная цель управления инцидентами в ITIL — максимально быстро восстановить нормальное функционирование ИТ-услуги после возникновения инцидента. Это помогает минимизировать негативное влияние на пользователей и бизнес-процессы. Например, когда пользователь не может распечатать документы, задача службы поддержки — оперативно устранить текущую проблему, используя даже временные решения, чтобы вернуть услугу в рабочее состояние.
Эпики в процессе разработки продукта находятся между инициативами и пользовательскими историями и служат в первую очередь для наглядной иллюстрации и объяснения покрытия общей формулировки инициативы очень частными определениями историй. Эпики не являются объектами обработки для команды, так как они слишком велики, не имеют строгого самостоятельного Definition of Done, который не является просто компиляцией дочерних требований. Они выполняют роль промежуточного уровня детализации между стратегическими инициативами и конкретными историями.