Слайд 1Управление ИТ-сервисами и контентом
Раздел 4. ITIL(продолжение)
Лекция 8 – 2.12.16
Слайд 2Ключевой термин - организация
Заказчики IT-услуг и поставщики IT-услуг рассматриваются в
форме организации(О).
О - это определенная форма сотрудничества людей. Перед любой
О стоит вопрос: в чем цель объединения в организацию?
Миссия - это короткое и четкое описание задач, стоящих перед О, и идеалов, в которые она верит.
Стратегические задачи (objectives) - это более подробное описание того, что хочет достичь О в долгосрочной перспективе. Хорошо сформулированные стратегические задачи должны обладать пятью основными свойствами (соответствовать принципу SMART): быть конкретными (Specific), поддаваться измерению (Measurable), быть уместными и соответствующими ситуации (Relevant), быть реалистичными (Achievable ) и иметь четкие временные границы (Time-bound).
Политика О (policy) - это совокупность всех решений и мер, принятых О для постановки стратегических задач и их достижения.
ПОВТОР
Слайд 3Важно контролировать выполнение поставленных задач в ходе исполнения запланированных работ.
Т.е., необходимо измерять, в какой степени организация или процессы близки
к достижению своих стратегических целей.
Методы оценки –
Карта Сбалансированных Оценок (Balanced Score Card - BSC).
Критические факторы успеха КФУ
(Critical Success Factor - CSF).
- факторы, которые обязательно должны реализовываться для успешности проекта, процесса, плана или услуги.
Ключевые показатели производительности
(Key Performance Indicator - KPI)
- метрики, которые используются для управления процессом, услугой или деятельностью
Слайд 4Эффективность процессов ITIL оценивается на основе системы метрик и показателей
http://itilium.ru/itilium/detail.php?ID=350
Слайд 54.3.2.Карта Сбалансированных Оценок (Balanced Score Card - BSC)
Cуществуют различные варианты
перевода на русский язык термина BSC:
- сбалансированная карта балльных
оценок,
- сбалансированный план достижения стратегических результатов,
- карта сбалансированных оценок,
- сбалансированная система оценочных индикаторов и т. д.
Авторы – американские экономисты::
директор исследовательского центра Norlan Norton Institute Дэвид Нортон и
профессором Harvard Business School Роберт Каплан (1992 году)
Слайд 6Назначение BSC
“Для того чтобы любые проблемы в компании можно было
предупредить или устранить сразу после их появления, необходима система своевременных
и достоверных показателей, которая позволит наиболее полно оценить эффективность работы компании в целом. Такой системой и является сбалансированная система показателей эффективности (Balanced Scorecard — BSC). Она позволяет существенно улучшить качество управления предприятием, особенно если у компании многопродуктовый бизнес или несколько направлений деятельности. В статье опыт внедрения BSС рассмотрен на примере компании IBS.’’
Cтатья: Управление предприятием с помощью системы Balanced Scorecard http://www.cfin.ru/management/controlling/bsc/bsc_management.shtml
Слайд 7BSC должна охватывать все важные направления деятельности предприятия. Классический вариант
– 4 направления:
финансовое направление рассматривает эффективность компании с точки зрения
отдачи на вложенный капитал
удовлетворение потребительских запросов оценивает полезность товаров и услуг компаний с точки зрения конечных потребителей
внутренняя операционная эффективность
оценивает эффективность внутренней организации бизнес-процессов
инновации и обучение
способность организации к восприятию новых идей, ее гибкость, ориентация на постоянные улучшения.
В зависимости от компании и изменяющихся условий внешней среды формулировка и количество направлений, рассматриваемых в BSC, могут меняться.
Слайд 8Этапы
Стратегическое планирование
Сформировать функциональные цели см ниже
Для каждой функциональной
цели определить критические факторы успеха (CSF)
Исходя из CSF необходимо определить
KPI
Формирование BSС
По статье: Управление предприятием с помощью системы Balanced Scorecard http://www.cfin.ru/management/controlling/bsc/bsc_management.shtml
Для того чтобы BSC «заработал», необходимо поэтапное построение системы.
I
II
III
IV
V
Слайд 9Функциональные цели должны удовлетворять следующим требованиям:
Необходимость и достаточность – должны
быть для всех направлений деятельности компании.
Привязка ко времени: должны
быть установлены сроки достижения цели (н-р, снижение управленческих расходов на 5% в течение года).
Согласованность по времени: должна быть установлена четкая очередность достижения целей
Согласованность по иерархии управления: целевые показатели подчиненных подразделений не должны противоречить целевым показателям руководящих подразделений и компании в целом.
Измеримость: все функциональные цели должны иметь количественное выражение (н-р, увеличение рентабельности продаж на 20%, увеличение доли постоянных клиентов на 10% и т. д.).
Слайд 10Пример формирования функциональных целей и определения для каждой функциональной цели
КФУ(CSF)
Слайд 11Пример определения KPI на основе КФУ
Слайд 13Автоматизация BSC и этапы её внедрения
BSC можно реализовать как
в специальных программных продуктах (например, Oros Scorecard, Hyperion Performance Scorecard,
Oracle Scorecard и др.), так и в MS Excel.
BSС — это продукт, индивидуальный для каждой компании, поэтому и его реализация будет абсолютно индивидуальной.
Слайд 14Выходная информация BSC
карта стратегических задач, логически связанных со стратегической целью;
карты
сбалансированных показателей, которые количественно измеряют эффективность бизнес-процессов и достижения цели
в заданные сроки;
приборные панели руководителей разных уровней для контроля и оценки деятельности;
целевые проекты, обеспечивающие внедрение необходимых изменений.
Слайд 15Реализация BSC на основе
SAP Business Information Warehouse (SAP BW)
Слайд 16Факторы успешного внедрения BSC
система сбора информации о деятельности всех подразделений
должна быть хорошо налажена.
руководство компании должно быть готово к
конструктивной работе по созданию стратегии, обсуждению целей и разработке подробного плана работы.
желательно, чтобы в компании хотя бы один сотрудник имел опыт построения подобных систем управления или хорошо в них разбирался.
При введении BSС нужно быть готовым к трудностям, возникающим при любой перестройке бизнес-процессов, главной из которых является сопротивление персонала.
Михаил Белов:
“..одна из основных сложностей построения системы BSС — это человеческий фактор. Менеджер никогда не будет сторонником введения новых показателей, особенно если на его участке работы и так все хорошо. Поэтому важно создать не только систему показателей, но и систему бизнес-процедур, которые, с одной стороны, позволят применять эту аналитическую систему, а с другой — заставят менеджеров ее использовать.”
Слайд 17Выводы по BSC
“….сбалансированная система показателей позволяет проводить всесторонний анализ взаимосвязей
внутри компании, своевременно отслеживать как позитивные, так и негативные изменения
в различных сферах управления и влиять на них.”
Cтатья: Управление предприятием с помощью системы Balanced Scorecard http://www.cfin.ru/management/controlling/bsc/bsc_management.shtml
Слайд 20Автоматизация BSC с помощью QPR Suite 2012. Cтратегическая карта компании
Слайд 21Пример отчета: Стратегическая карта
Слайд 224.4.Базовые процессы ITIL
Подробнее только о 2-ух процессах:
4.4.1.Процесс управления инцидентами
4.4.2.Процесс управления
проблемами
Значения терминов ITIL см.
Словарь терминов и определений ITIL http://www.itsmforum.ru/ZAM-test/Russian_2011_Glossary_v2.0.pdf
Слайд 23В ITILv3 определены и широко используются понятия:
Функция
- части организации, специализированные
для того, чтобы выполнять определенные виды работ и отвечать за
формирование соответствующих результатов.
Функции обладают всеми необходимыми для выполнения работы возможностями и ресурсами. Возможности включают в себя собственные методы работы и накопленный опыт. Функции обеспечивают структурированность и стабильность организации
Процесс
- структурированный набор видов деятельности, спроектированный для достижения определенной цели.
Процесс может включать в себя роли, ответственность, инструментарий и методы контроля, необходимые для формирования результатов.
Процесс может определять политики, стандарты, руководства, виды деятельности и рабочие инструкции, когда это необходимо
Слайд 24Схема базового процесса
Процесс состоит из активностей.
Активность или деятельность -
набор действий, спроектированный с целью получения определенного результата.
Слайд 25Характеристики процесса
Процессы измеряемы, то есть можно измерить процесс каким-либо подходящим
методом. Менеджеры стремятся измерить в первую очередь стоимость и качество,
а практикующие пользователи - продолжительность и продуктивность процесса.
Процессы служат для достижения конкретных результатов. Причина существования процесса - предоставление конкретного результата, который можно идентифицировать и посчитать.
Процессы имеют потребителей - каждый процесс предоставляет свои результаты потребителям или инвесторам. Они могут быть внутри или вне организации, но процессы в любом случае должны удовлетворять их ожиданиям.
Процессы отвечают за определенный результат.
Процессы должны реагировать на определенные события. Пока идет процесс, он должен быть связан со специальным инициализирующим триггером.
Книги ядра ITIL v.3 описывают совокупность процессов. Процессы имеют конкретные результаты - получение результата является причиной существования процесса.
Слайд 26Базовые процессы, обеспечивающие поддержку и предоставление ИТ сервисов, описанных в
ITSM:
Процесс управления инцидентами
Процесс управления проблемами
Процесс управления конфигурациями
Процесс управления изменениями
Процесс управления
релизами
Процесс управления уровнем услуг
Процесс управления мощностями (ёмкостью)
Процесс управления доступностью
Процесс управления непрерывностью
Процесс управления финансами
Процесс управления безопасностью
Блок процессов
поддержки
ИТ-сервисов
Блок
предоставления
ИТ-сервисов
Базовые процессы приведены по ITIL v2 (по двум первым книгам)
В ITIL V3 полный список процессов некоторые скептики насчитывают до 43
Слайд 27Цели базовых процессов ITIL
Процесс управление инцидентами
(Incident management)
Цель процесса –
скорейшее устранение инцидентов, под которыми понимаются любые события, требующие ответной
реакции: сбои, запросы на консультации и т.п.
В тесной связи с данным процессом рассматриваются вопросы создания и управления подразделением Service Desk, которое является единой точкой контакта с пользователями и координирует устранение инцидентов.
Процесс управления проблемами
(Problem management)
Цель процесса – сделать так, чтобы инцидентов стало меньше. Это достигается за счет выявления и устранения причин инцидентов.
Service Desk
Слайд 28Цели базовых процессов ITIL
Процесс управление конфигурациями
(Configuration management)
Цель процесса –
создать и поддерживать в актуальном состоянии логическую модель инфраструктуры.
Процесс управление
изменениями
(Change management)
Обычно изменения делаются с благими намерениями, но каждое изменение потенциально опасно для инфраструктуры.
Цель процесса – допускать только разумные изменения, а также координировать их проведение.
Слайд 29Цели базовых процессов ITIL
Процесс управление релизами
(Release management)
Если считать управление
изменениями "головой", то этот процесс – "руки", которые производят изменения
в инфраструктуре.
Цель процесса – сохранить работоспособность производственной среды при проведении изменений.
Процесс управление уровнем услуг(сервиса)
(Service Level Management)
Зачастую поставщик и потребитель ИТ-сервисов по-разному представляют себе, в чем заключаются эти сервисы, какие операции и насколько быстро должны проводиться.
Цель процесса – выявить необходимый состав и уровень сервиса, следить за его достижением, а при необходимости – инициировать действия по устранению некачественного сервиса.
релиз
Слайд 30Цели базовых процессов ITIL
Процесс управления финансами
(Financial management for IT
services)
Цель процесса – обеспечить надежную финансовую базу для всех прочих
процессов.
Процесс управление мощностью
(Capacity management)
Недостаточная мощность инфраструктуры приводит к появлению жалоб на скорость работы, или к невозможности продолжать работу. С другой стороны, излишняя, неиспользуемая мощность – это впустую потраченные деньги.
Цель процесса – найти разумный компромисс между затратами и потребностями.
Слайд 31Цели базовых процессов ITIL
Процесс управления непрерывностью
(IT service continuity management)
Цель
процесса – обеспечить гарантированное восстановление инфраструктуры, необходимой для продолжения бизнес-операций
в случае чрезвычайной ситуации: пожара, наводнения, отключения электроэнергии. В последнее время к этим классическим угрозам добавился терроризм.
Процесс управления доступностью
(Availability management)
Доступность – очень часто используемый показатель уровня сервиса. Однако не только обеспечение заданного уровня доступности, но даже определение и измерение доступности настолько сложны, что для всех связанных с доступностью задач организуется отдельный процесс.
Слайд 324.4.1.Процесс управления инцидентами
http://www.itsm.in.ua
http://www.itexpert.ru
Слайд 33Процесс управления инцидентами(И)
Цель процесса - предназначен для обеспечения быстрого восстановления
ИТ-сервиса.
Инцидент - любое событие не являющееся частью нормального функционирования ИТ-сервиса.
И не запланированное, трудно предсказуемое событие. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является И.
Примеры И: невозможность загрузить операционную систему, сбой электропитания, сбой жесткого диска на ПК пользователя, появление компьютерного вируса в ЛВС офиса, отсутствие тонера или бумаги для печатающего устройства и т.д.
Слайд 35Процесс управления инцидентами(И)
Входы и выходы процесса
КФУ (CSF)
КПП (KPI)
Выполняемые функции(действия)
Влияние при
отказе от процесса
Риски процесса
Далее подробно об этих компонентах:
Слайд 36Информация по инциденту
Вся значимая информация об инциденте должна быть зафиксирована
и доступна группам поддержки.
Пример информации по инциденту:
Слайд 37Процесс управления инцидентами(И)
Входы
Инциденты
Сведения об инфраструктуре (CMDB)
Сведения о проблемах и известных
ошибках
Сведения о способах решения И
Ответы на поданные RFC
Выходы
Запросы на изменения
Сообщения
о некорректности данных в CMDB
Решенные и закрытые И
Записи об И
Оповещения
Отчеты
CMDB - Configuration Management Database
RFC - Request for Change
Слайд 38Процесс управления инцидентами(И)
КФУ(CSF):
Пристальное внимание к управлению процессом
Реалистичные цели и контроль
их достижения
Актуальная CMDB
База знаний по известным ошибкам и проблемам
Автоматизация настроена
в соответствии с требованиями процесса
Четкие целевые показатели поддержки, согласованные с пользователями в рамках процесса SLM
Наличие эффективных инструментов диагностики
Наличие резервов для быстрого применения обходных решений
SLM - Service Level Management
Слайд 39КПП(KPI) для процесса управления И
Количество зарегистрированных обращений (инцидентов)
Количество/процент открытых обращений
Количество/процент вовремя разрешенных обращений
Количество/процент обращений, закрытых на 1-й линии
поддержки (Операторами Service Desk)
Средние трудозатраты на решение обращения
Количество/процент обращений, закрытых с превышением сроков, установленных в SLA
Среднее время между сбоями
Среднее время ремонта
Сумма расходов на выполнение обращение (по нарядам)
Оценка качества выполнения обращения
Количество/процент обращений, по которым превышено время реакции
Количество/процент обращений, открытых повторно
Количество/процент обращений, выполнение которых не подтверждено пользователем
Количество/процент завершенных обращений
SLA -Service Level Agreement
Слайд 40Процесс управления инцидентами(И)
При реализации процесса должны выполняться следующие функции:
прием запросов
пользователей;
регистрация инцидентов;
категоризация инцидентов;
приоритизация* инцидентов(см. ниже);
изоляция* инцидентов;
эскалация* инцидентов;
отслеживание развития инцидента;
разрешение инцидентов;
уведомление
клиентов;
закрытие инцидентов.
Слайд 41Приоритет инцидента
На основании приоритета определяется очередность устранения инцидентов.
Приоритет устанавливается
с учетом следующих факторов:
Срочность
Влияние на бизнес
Риск для жизни или здоровья
(risk to life or limb)
Число затронутых услуг
Финансовые потери
Влияние на репутацию бизнеса
Влияние на соответствие законам и другим нормами др.
Слайд 42Диаграмма
активности
(деятельности)
процесса
управления
инцидентами
(с применением
UML)
Слайд 43Процесс управления инцидентами(И)
При отказе от процесса управления И:
Некому управлять и
производить эскалацию INC, INC могут стать более трудными для разрешения
Специалисты
SD постоянно отрываются на выполнение других задач
Бизнес-персонал отрывается от основных функций, так как коллеги обращаются др. к др. за советами
Частое расследование INC с самого начала из-за отсутствия готовых решений
Нехватка согласованной управленческой информации
Потерянные, неправильно или плохо управляемые INC
Для управления качеством процесса необходимо
определить систему управления инцидентами,
разработать управленческие отчеты
обеспечивать непрерывное улучшение процесса.
Слайд 44Процесс управления инцидентами(И)
Риски:
Отсутствие поддержки у руководства, нехватка ресурсов
Отсутствие четких требований
к поддержке со стороны бизнеса
Отсутствие деятельности по улучшению процесса и
обновлению процессной документации
Нечеткое распределение обязанностей
Нехватка знаний и навыков у специалистов по поддержке
Неадекватная система автоматизации
Сопротивление изменениям
Эффективное управление инцидентами требует от сотрудников понимания и реальной приверженности процессному подходу, а не просто участия.
Слайд 454.4.2.Процесс управления проблемами
http://www.itsm.in.ua
http://www.itexpert.ru
Слайд 46Процесс управления проблемами
Цель процесса – минимизация воздействия инцидентов и проблем
на жизнедеятельность бизнеса и предотвращение потенциальных инцидентов, связанных с системными
ошибками в IT инфраструктуре.
Проблема – причина одного или нескольких инцидентов. Обычно при создании записи о проблеме причина неизвестна, и за дальнейшее её расследование отвечает процесс управления проблемами.
Слайд 47Задачи процесса управления проблемами
Слайд 48Процесс управления проблемами
Входы и выходы процесса
КФУ (CSF)
КПП (KPI)
Выполняемые функции(действия)
Влияние
при отказе от процесса
Риски процесса
Далее подробно об этих компонентах:
Слайд 49Информация по проблеме
все значимые данные о проблеме должны быть зафиксированы
в записи о проблеме (problem record):
Информация о пользователе(-ях)
Информация об услуге(-ах)
Информация
об оборудовании
Время регистрации
Приоритет, категория
Описание связанных инцидентов
Предпринятые для диагностики и решения действия
Запись о проблеме – запись, содержащая детальное описание проблемы. Каждая запись о проблеме документирует жизненный цикл одной проблемы.
Слайд 50Процесс управления проблемами
Входы
Описания инцидентов
Сведения об инфраструктуре (CMDB)
Сведения об обходных решениях
инцидента (work-around) найденных Процессом управления инцидентами
Выходы
Записи о проблемах и
известных ошибках
Обходные решения
RFC
Решенные проблемы
Отчеты
Слайд 51Процесс управления проблемами
КФУ (CSF):
Пристальное внимание к управлению процессом
Реалистичные цели и
контроль их достижения
Актуальная CMDB
База знаний по известным ошибкам и проблемам
Автоматизация
настроена в соответствии с требованиями процесса
Эффективный процесс управления инцидентами, особенно в части классификации и привязки
Эффективное взаимодействие c процессом управления инцидентами
Грамотное использование аналитических способностей персонала, выделение ресурсов
Слайд 52КПП(KPI) для процесса управления проблемами
Количество зарегистрированных проблем
Количество запросов на
изменение, сформированных процессом управления проблемами
Количество/процент закрытых проблем со статусом
«Решена»
Количество/процент закрытых проблем со статусом «Известная ошибка»
Количество/процент повторно открытых проблем
Количество записей в базе знаний
Процент проблем с некорректно заполненными данными
Слайд 53При реализации процесса управления проблемами
процесса должны выполняться следующие функции:
анализ тенденций
инцидентов;
регистрация проблем;
идентификация корневых причин инцидентов;
отслеживание изменений проблем;
выявление известных ошибок;
управление известными
ошибками;
решение проблем;
закрытие проблем.
Слайд 54Диаграмма
активности
(деятельности)
процесса
управления
проблемами
(с применением
UML)
Для управления качеством
процесса необходима организация
системы управления проблемами/известными ошибками,
превентивных процедур поддержки,
способов верификации известных ошибок,
интерфейса поддержки поставщиком,
разработка отчетов для управления, постоянное усовершенствование процесса
Слайд 55Возможными признаками проблем могут быть:
Инциденты, повторяющиеся в:
Один и тот же
временной промежуток
В одной предметной области (категории)
В одном и том же
КЕ или группе однотипных КЕ
В одних и тех же локации, заказе, подразделении
Объем однотипных инцидентов превышает некий уровень
Для решения инцидента применено обходное решение
Превышение предельного срока обработки инцидента(ов)
Слайд 56Процесс управления проблемами
При отказе от процесса управления проблемами:
SD работает только
по принципу реагирования и устраняет проблемы когда предоставление услуги Заказчику —
прервано
Пользователи ИТ сталкиваются с повторяющимися инцидентами и теряют доверие к качеству SD
SD становиться не эффективной, так как требуется разрешение повторяющихся инцидентов и структурные решения не внедряются
SD - Service Desk
Слайд 57Процесс управления проблемами
Риски:
Отсутствие поддержки у руководства, нехватка ресурсов
Отсутствие хорошо налаженного
процесса управления инцидентом — отсутствие подробных исторических данных по инциденту
Отсутствие деятельности
по улучшению процесса и обновлению процессной документации
Неспособность связать записи об инциденте с записями проблем/ ошибок — снижает точность определения влияние инцидентов и проблем на бизнес
Нечеткое распределение обязанностей
Неадекватная система автоматизации
Сопротивление изменениям
Слайд 584.3.Модель зрелости
(Модели качества процессов конструирования ПО)
По литературе:
1. С. Орлов. Технологии
разработки программного обеспечения. Учебное пособие. — СПб.: Изд - во
«Питер», 2003.
2. Марк Паулк, Билл Куртис, Мэри Бет Хриссис, Чарльз В. Вебер, Сьюзен М. Гарсия, Мерилин Буш. CMMI Product Team. Модель зрелости процессов разработки программного обеспечения
(см.http://modernlib.ru/books/paulk_mark/model_zrelosti_processov_razrabotki_programmnogo_obespecheniya/read_1/ )
3. Статья: Модели зрелости процесса тестирования ПО. Вячеслав Панкратов http://www.osp.ru/os/2007/02/4108132/
Слайд 59Основные тезисы:
Типичная разработка ПО в России была долгое время ориентирована
на программистов-одиночек
Интереса к индустриальному производству не было из-за высокой стоимости
и низкого платежеспособного спроса на сложные программные комплексы(информационные системы)
Разработка ПО велась спонтанно – не уделялось должного внимания организации самого процесса: планированию, тестированию, межгрупповому взаимодействию, управлению конфигурацией.
Качество ПО напрямую зависит от качества процесса его производства. Управляя процессом производства и контролируя показатели эффективности всех его технологических этапов, можно влиять на качество производимого продукта
Важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам.
Слайд 60Основные тезисы:
Подобные международные стандарты дают представление (описывают) свою модель обеспечения
качества
Примеры: ISO9001:2000, ISO/IEC15504 и модель зрелости процесса конструирования ПО (Capability
Maturity Model — СММ) Института программной инженерии при американском унив-те Карнеги-Меллон.
Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности.
Стандарт ISO/IEC 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Объем этого > 500 страниц. Значительная часть идей ISO/IEC 15504 взята из модели СММ.
Базовое понятие модели СММ зрелость компании.
Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков высока вероятность превышения бюджета или срыва сроков окончания проекта.
Слайд 61Основные тезисы:
В зрелой компании работают ясные процедуры управления проектами и
построения программных продуктов. По мере необходимости эти процедуры уточняются и
развиваются. Оценки длительности и затрат разработки точны, основываются на накопленном опыте.
Также в компании имеются и действуют корпоративные стандарты на процессы взаимодействия с заказчиком, процессы анализа, проектирования, программирования, тестирования и внедрения ПП. Все это создает среду, обеспечивающую качественную разработку ПО.
СММ фиксирует критерии для оценки зрелости компании и предлагает рецепты для улучшения существующих в ней процессов.
В СММ не только сформулированы условия, необходимые для достижения минимальной организованности процесса, но и даются рекомендации по дальнейшему совершенствованию процессов.
В СММ есть 5 уровней зрелости и предусмотрен плавный, поэтапный подход к совершенствованию процессов — можно поэтапно получать подтверждения об их улучшении после каждого уровня зрелости.
Слайд 62CMM разрабатывалась для программной индустрии, которая остается ее основным пользователем,
но, в силу своей универсальности, модель находит сегодня применение и
для оценки зрелости бизнес-процессов во многих других областях.
Пять уровней зрелости модели СММ
Зрелость технологического процесса - это степень ясности определения, управления, измерения, контроля и выполнения конкретного технологического процесса.
Зрелость свидетельствует, с одной стороны, о мощности (richness) процесса программирования в организации, и, с др. стороны, о степени его применимости (адаптируемости) к проектам организации.
Слайд 63Описание уровней(лит-ра 1)
Начальный — процесс разработки не формализован, носит хаотический
характер, не может строго планироваться и отслеживаться. Определены лишь немногие
из процессов, и успех проектов зависит от конкретных исполнителей.
Повторяемый — для перехода на этот уровень необходимо внедрить формальные процедуры для выполнения основных элементов процесса конструирования; установлены основные процессы управления проектами: отслеживание затрат, сроков и функциональности. Упорядочены некоторые процессы, необходимые для того, чтобы повторить предыдущие достижения на аналогичных проектах. Основное отличие от уровня 1 состоит в том, что выполнение процесса планируется и контролируется.
Слайд 64Описание уровней(лит-ра 1)
Определенный — процессы разработки ПО и управления проектами
описаны и внедрены в единую систему процессов компании. Во всех
проектах используется стандартный для организации процесс разработки и поддержки программного обеспечения, адаптированный под конкретный проект. Основное отличие от уровня 2 заключается в том, что элементы процесса уровня 3 планируются и управляются на основе единого стандарта компании.
Управляемый — собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса.
Оптимизируемый — постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий. Основное отличие от уровня 4 заключается в том, что технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется.
Слайд 65Область ключевых процессов (ОКП)
Каждый уровень СММ характеризуется областью ключевых процессов
(ОКП), причем считается, что каждый последующий уровень включает в себя
все характеристики предыдущих уровней. Н-р для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Н-р, ОКП 5-го уровня образуют процессы:
предотвращения дефектов;
управления изменениями технологии;
управления изменениями процесса.
Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ.
Слайд 66Связи заказчик-поставщик и Уровни Зрелости
Введение в ИТ СЕРВИС-МЕНЕДЖМЕНТ
При оценке зрелости
организации нельзя ограничиться только поставщиком услуг. Важен также Уровень Зрелости
Заказчика. Если разница в степени зрелости компаний заказчика и поставщика велика, то ее следует учитывать, если нет желания столкнуться с несоответствием подходов и стилей работы в этих компаниях. Целесообразно, чтобы компании заказчика и поставщика выходили на одинаковый Уровень Организационной Зрелости, и взаимодействие происходило бы на этом Уровне или было скорректировано с учетом более низкого уровня одного из партнеров.
http://e-libra.ru/read/169111-it-servismenedzhment.
-vvodnyj-kurs-na-osnove-itil.html
Слайд 67Приложение 1. Стадии ЖЦ услуги в соответствии с ITIL версии
3
Фрагмент учебного пособия:
Целью каждой стадии жизненного
цикла является создание
коммерческой ценности ИТ-сервиса.
Слайд 68Стадии ЖЦ услуги в соответствии с ITIL в. 3
Слайд 69Стадии ЖЦ услуги в соответствии с ITIL в. 3
Слайд 70Стадии ЖЦ услуги в соответствии с ITIL в. 3
Слайд 71Приложение 2. Задание на семинар. Часть 2
работа с текстами
стандартов
Жизненный цикл ИТ-сервиса – это совокупность стадий и этапов, которые
проходит в своем развитии ИТ-сервис от момента принятия решения о создании ИТ-сервиса до момента прекращения ее предоставления.
Стадии жизненного цикла ИТ-сервисов достаточно полно регламентируются стандартами(н-р ITIL), существуют и российские стандарты –
ГОСТ Р ИСО/МЭК 20000 “Информационная технология. Менеджмент услуг”. (несколько разделов).
Необходимо к семинару найти тексты российских стандартов (20000), например, на сайте http://docs.cntd.ru и информацию о каждом: наименование, когда принят, какому международному стандарту соответствует, область применения. + найти ответы на вопросы – см. следующий слайд
Слайд 72Вопросы?
По ГОСТ Р ИСО/МЭК 20000-1-2010
Кем может использоваться 1 часть
ИСО/МЭК 20000?
Процессы управления услугами
(ГОСТ Р ИСО/МЭК 20000-1-2010 см. рис.2)
сколько?
Какие? В какие группы они объединяются?
Найдите в тексте стандарта определения следующим понятиям:
Инцидент
Проблема
Процедура
Процесс
Релиз
Риски
Конфигурационная единица
SLA
CMBD
Доступность
