В предыдущей публикации я поделилась опытом проведения обследования процессной практики на предприятии.
В этой статье сфокусируюсь на конкретном процессе, чтобы наглядно продемонстрировать, как производится его оценка. За основу возьму процессы управления инцидентами и запросами. Почему говорю об одном процессе, а оцениваю два?
Дело в том, что в Cobit свое видение процессной модели. Процессы методологии ITIL RFF Request Fulfilment и INC Incident management в CobiT консолидируются в DSS02 Manage Service Request and Incidents, а процесс ITIL SACM Service Asset & Configuration Management разделен на два: BAI09 Manage Assets и BAI10 Manage Configuration. В сетях можно найти таблицу маппинга процессов из смежных методологий, чтобы консультантам облегчить труд по сопоставлению.
Расскажу о своем видении: как эта методология помогает в достижении высоких, а главное обоснованных и понятных результатов.
ITIL, в отличие от CobiT, сам по себе систематически принудительно «прокачивает» практикующих консультантов, являясь стандартом де-факто в ИТ-внедрениях. В связи с этим ступени по сертификации недостижимы без постоянного изучения методологии с различных ракурсов. А вот до CobiT обычно руки не доходят. Но вдруг, по стечению обстоятельств, «руки дошли», и взгляду начали открываться бескрайние оценочные возможности.
CobiT 5 – это серия книг, которая содержит обширную методологическую информацию в части процессов управления информационными технологиями.
Для оценки воспользуемся Process Assessment Model (PAM): Using COBIT® 5.
Немного теории
CobiT выделяет шесть уровней возможностей процессов, включая уровень «неполного процесса», когда процесс не соответствует своему назначению:
- Уровень 0 – Неполный процесс – процесс еще не внедрен или не способен соответствовать своему назначению. На этом уровне отсутствуют свидетельства систематического достижения процессом своих целей или таких свидетельств мало.
- Уровень 1 – Осуществленный процесс – процесс внедрен и соответствует своему назначению. Определены требуемые результаты выполнения процесса, прорабатываются виды деятельности для достижения целей и результатов процесса.
- Уровень 2 – Управляемый процесс – осуществленный процесс предыдущего уровня управляем (планируется, отслеживается и корректируется). Создаются, контролируются и поддерживаются рабочие продукты процесса. Разработан полный комплект проектной документации. Используется единая система автоматизации.
- Уровень 3 – Установленный процесс – управляемый процесс предыдущего уровня способен получать ожидаемые результаты. Все процессные процедуры унифицированы. Разработана процедура масштабирования процесса, а также выделения ресурсов и обучения персонала.
- Уровень 4 – Предсказуемый процесс – установленный процесс предыдущего уровня получает результаты в условиях заданных ограничений – процесс измерим. Разработаны процедуры проверки и корректировки процессной деятельности, их периодичность.
- Уровень 5 – Оптимизируемый процесс – предсказуемый процесс предыдущего уровня постоянно совершенствуется, чтобы обеспечивать достижение текущих и будущих целей предприятия.
Каждый из уровней делится на атрибуты возможностей, наличие которых свидетельствует о достижении процессом соответствующего уровня.
В свою очередь, атрибуты возможностей достигаются путем проверки у процесса набора фиксированных индикаторов в соответствии с ISO/IEC 15504-2:2003. (ГОСТ Р ИСО/МЭК 15504-2-2009)
В таблицу сведены все атрибуты и индикаторы из обозначенных стандартов, немного субъективно «причесано» по результатам практики в части формулировок и с учетом особенностей перевода (оригинал – в 4.0 Process Capability Indicators). Они адаптированы под восприятие как аудитором, так и участниками обследования.
Схема измерения возможностей процессов управления ИТ
Полнота атрибута оценивается по шкале:
- N (не достигается) – в оцениваемом процессе не существует или существует мало свидетельств того, что определенный атрибут в оцениваемом процессе достигается (от 0 до 15% достижения);
- P (частично достигается) – в оцениваемом процессе существуют свидетельства того, что существует подход к достижению и происходит частичное достижение заданных целей. Некоторые аспекты того, как достигается цель (атрибут), непредсказуемы (от 15% до 50% достижения);
- L (в основном достигается) – в оцениваемом процессе существуют свидетельства системного подхода и системного достижения заданных целей. Существуют некоторые недостатки достигаемых результатов (от 50% до 85% достижения);
- F (достигается полностью) – в оцениваемом процессе существуют свидетельства полного системного подхода и фактического достижения заданных целей. Значительных недостатков, связанных с полученным результатом, не выявлено (от 85% до 100% достижения).
Оценка возможностей процессов начинается с нулевого уровня. Оценка каждого последующего уровня имеет смысл только в том случае, если обеспечено 100% достижение предыдущего.
При оценке:
- сначала проверяется наличие индикаторов атрибутов в обследуемом процессе,
- затем по полноте индикаторов принимается решение о доле наличия атрибута,
- далее по наличию атрибутов определяется мера достижения уровня. Уровень считается достигнутым, если у него в полной мере присутствуют нужные атрибуты.
Как выполняется оценка
Первоначально производится сбор информации при помощи анкетирования и интервьюирования ключевых сотрудников.
Затем вся полученная информация сводится в единый отчет и производится ее оценка. Для проведения оценки можно воспользоваться табличками-шаблонами Self-assessment Template (Appendix B of the Self-assessment Guide), в котором необходимо проставить чекбокс на пересечении индикатора и его рейтинга.
Проверка достижения первого уровня
Для каждого процесса предусмотрена таблица, содержащая справочную информацию. Данная таблица удобна не только при оценке, но и при проектировании процесса, как шпаргалка по ключевым процессным особенностям. Для оценки достижения процессом DSS02 первого уровня нам поможет соответствующая таблица. А именно ее разделы: Цель процесса (ProcessPurposeStatement), Результаты (Outcomes), Артефакты (Outputs).
Атрибут, свидетельствующий о достижении процессом первого уровня, – Производительность процесса. Процесс существует, достигается его цель:
- Повышение производительности и минимизация сбоев благодаря быстрому разрешению пользовательских запросов и инцидентов.
Если у нас по результату обследования нет в отчете статистических данных о динамике повышения производительности и стабильном снижении сбоев, то рекомендуется оценить результаты и привести любые возможные примеры в поддержку заключения:
- DSS02-О1 ИТ-услуги доступны – 80% L;
- DSS02-O2 Инциденты разрешаются в соответствии с согласованными уровнями обслуживания – 90% F;
- DSS02-O3 – Запросы на обслуживание DSS02-O3 обрабатываются в соответствии с согласованным уровнем обслуживания и удовлетворенностью пользователей – 90% F.
Если с первого подхода разобраться не получилось, то самый верный способ просто «прочекать» артефакты на предмет «есть/нет». Это даст общую картину о фактической производительности процесса.
Таблица базовых практик и артефактов
На более высоких уровнях следует смотреть не на конкретные результаты процесса, а в целом на общие цели, которые отображаются для каждого из уровней от 2 до 5.
Чтобы считать определенный уровень достигнутым, все атрибуты этого уровня должны быть оценены на L или F, чтобы перейти на следующий уровень все атрибуты должны быть F. Например, если Атрибут 2.1 = L и Атрибут 2.2 = F, вы подтверждаете, что достигли уровня 2, но чтобы преодолеть уровень 2, рейтинг должен быть = F у обоих атрибутов.
CobiT в этой части предлагает оценивать достижение процессом целей того или иного уровня по наличию определенных результатов и качества их проработки. На рисунке указаны, какие результаты помогут определить достижение уровня. Подробнее о результатах можно узнать в приложении Appendix B generic And level 1 outPut work Products.
Мною выделены определенные чекпоинты, наличие которых в собранной информации по результатам обследования я принимаю за успешное достижение уровня. Ниже предложен их перечень со сквозной нумерацией, но условным разделением по уровням методологии.
Проверка достижения второго уровня
Для определения степени прохождения процессом второго уровня рекомендую собрать все возможные процессные регламенты, инструкции, стандарты, задокументированные процедуры.
Считаем уровень пройденным, если нашли:
- Процедуры – описание видов деятельности;
- Документация – формальное описание процесса и его процедуры контроля и корректировки;
- Описание Ролей – состав участников и перечень их полномочий;
- Описание Ресурсов – сотрудники, знания, инструменты;
- Описание интерфейсов взаимодействия участников, контроль ответственности;
- Описание Входов и выходов процесса;
- Описание процессных параметров и ограничений.
Проверка достижения третьего уровня
Для определения степени прохождения процессом третьего уровня рекомендую искать в собранной документации описание методик масштабирования. Если на втором уровне мы просто искали описание процедур или ролей, то на третьем уровне данные процедуры должны быть обезличенными и должны свободно исполняться в любом филиале, подразделении, организации без привязки к конкретной оргструктуре, ресурсам, особенностям технологических процессов и т.п.
Если роль второй линии исполняет инженер отдела технической поддержки пользователей и на него ссылается процедура второго уровня, то процедура третьего уровня должна исполняться обезличенным ответственным исполнителем, роль которого в свою очередь играет все тот же инженер ОТП либо начальник службы поддержки пользователей и т.п. (в зависимости от филиала/территориального распределения). При этом обязательно должна быть таблица распределения типовых ролей на конкретных сотрудников/отделы/группы, т.е. ответственность должна быть явно зафиксирована.
Считаем уровень пройденным, если нашли:
- Описание типовых процедур;
- Универсальные интерфейсы между типовыми процессами;
- Описание типовых ролей;
- Описание процедур развертывания процесса, выделения ресурсов, распределения ролей;
- Универсальные методы мониторинга процесса;
- Процедуры обучения персонала;
- Получение гарантии доступности управляемости и сопровождаемости рабочей среды;
- Получение анализа эффективности процесса.
Проверка достижения четвертого уровня
Для определения степени прохождения процессом четвертого уровня рекомендую искать в собранной документации описание методик контроля, анализа, корректировки процесса по результатам проверки и анализа.
Считаем уровень пройденным, если нашли:
- Процедуры измерения: метрики, цели, периодичность контроля продуктов процесса;
- Оценка соответствия процессной деятельности и бизнес-целей организации;
- Оценка достижения целей на основании затраченных ресурсов;
- Процедура анализа полученных результатов измерений;
- Процедура использования полученных результатов;
- Фиксация целевых параметров процессов и ограничений для его работоспособности;
- Процедуры корректировки процесса, направленные на устранение отклонений от целевых показателей работоспособности.
Проверка достижения пятого уровня
Для определения степени прохождения процессом пятого уровня потребуется не только подготовка методологической базы, но и свидетельства жизни в процессе на протяжении времени, и, как результат, накопленные статистические данные и отчеты по исследованию результатов применения корректировок в процессе.
Считаем уровень пройденным, если нашли:
- Стратегия улучшения на основании статистики;
- Корреляция улучшений с лучшими практиками;
- Улучшение процесса с учетом новых технологий;
- Статистика по изменениям процесса;
- Регламент изменения и авторизации изменений процесса;
- Оценка эффективности изменений процесса.
В итоге
Методология очень насыщенная и обширная. С моей точки зрения, она ассоциируется с понятием «мозговой штурм», когда огромная группа людей усердно думает в одном направлении и все возникающие мысли где-то фиксирует. Так и в Cobit – упорядоченная фиксация всех возможных полезных сведений, востребованных в процессах. Для меня эта методология – кладезь идей, почва для вдохновения, средство для выхода из логического тупика.
Минусы методологии – избыточность. Целенаправленно придерживаться ее не получается. Есть ощущение дублирования понятий либо из-за особенностей перевода, либо из-за непрозрачности восприятия всех идей, предложенных авторами. Поэтому:
- ИДЕАЛЬНО взять за основу как точку опоры;
- НЕВОЗМОЖНО слепо придерживаться методологии для разработки процесса «под ключ».
