Анализ ресурсного окружения процессов

Анализ  ресурсного окружения процессов

Основу процесса составляют выполняемые функции. Для  выполнения каждой из функций требуются  ресурсы:

♦ людские – участники процесса (кто выполняет);

♦ производственные – станки, оборудование, компьютеры, транспорт (при помощи чего выполняет);

♦ материальные – материалы, комплектующие, энергетические ресурсы (с использованием чего выполняет);

♦ информационные – данные, документы, информация (на основании чего выполняет);

♦ интеллектуальные – знания и полномочия участников и владельца процесса.

Все эти ресурсы  должны быть определены и описаны  для каждой функции, выполняемой  в процессе.

Например, операционное окружение таможенных процессов  включает:

♦ организационное наполнение (перечень исполнителей на уровне должностных лиц и подразделений, участвующих в процессе);

♦ системное наполнение (перечень информационных и технических систем, используемых в процессе);

♦ функциональное наполнение (перечень функций, выполняемых исполнителями на уровне должностных лиц и подразделений в процессе);

♦ информационное наполнение (перечень документов и данных разного типа, используемых в процессе).

Прежде, чем начать работу по описанию процесса, необходимо обозначить участок, чтобы работа не стала бесконечной. Для этого определяются границы  процесса, т.е. те рамки, за которые при описании заходить не будут, и зона ответственности.

Как правило, на старте любой работы должно произойти  событие, дающее начальный толчок. Например, для начала обработки заказа менеджером по продажам необходим звонок клиента. Для выбранного процесса нужно определить, что будет являться запускающим событием, с которого начинается работа. Таких событий может быть несколько. В том же примере клиент может не только позвонить по телефону, но и отправить заказ по почте или факсимильной связи.

Если событий  несколько, необходимо определить: происходят они одновременно и обязательно  для каждого процесса, или достаточно какого-то одного для начала работ?

Если событие  одно или несколько, но для начала процесса необходимо одно из них, логический оператор изменяется с «и» на «исключающее или».

После определения  начальных событий необходимо определить: «Где закончится процесс?». Конечное событие  также может быть не единственным. Например, успешным завершением процесса Приемки заказа может быть событие «заказ принят», но если клиента не устраивают предлагаемые нами товары / услуги, может произойти событие «клиент не заинтересован», и процесс для данного клиента на этом закончится.

После определения  границ необходимо выделить все входящие и выходящие потоки (внешние интерфейсы). Сначала выделяются входящие потоки: информация, ресурсы. Затем определяются продукты/услуги, получаемые в результате процесса, и все виды информации. Особое внимание следует уделять документам, телефонным звонкам, продуктам/услугам используемому программному обеспечению.

После определения  выходов процесса следует установить: «Кто использует полученные продукты/услуги или информацию (выходы процесса)?». Это будут клиенты процесса. Желательно провести опрос клиентов и выявить требования, предъявляемые к результатам процесса. Еще лучше, если это возможно, включить представителя клиентов в рабочую группу.

2.5.1.Пример «Сертификация». Определение границ процесса

Границей входа  процесса будет получение отделом  сертификации образцов товара и сопроводительной документации. При более внимательном рассмотрении процесса можно выделить еще одну входную границу процесса - это поступление недостающих документов от поставщика. В этом случае весь процесс сертификации начинается с самого начала.

Границей выхода будет оповещение отдела продаж о  начале продаж товара. При неудачном  завершении сертификации конечной границей процесса будет оповещение  отдела закупок о некачественном товаре. Еще один случай возникает, если выявлена некомплектность документов, отправленных поставщиком. Тогда недостающие документы запрашиваются, и процесс сертификации продолжается. 

 

После определения  границ можно приступать к интерфейсам. Входным интерфейсом являются получаемые отделом сертификации сопроводительные документы и образцы, либо недостающие документы, досланные поставщиком.

Выходным интерфейсом  будут оповещения либо отдела продаж о выпуске в продажу либо отдела закупок о некачественном товаре.

Клиенты

Основными клиентами  процесса являются: потребители, руководство, отделы закупок и продаж. Требования клиентов к интерфейсам различны. 

 

Внешние интерфейсы и требования клиентов. 

 

Внешние интерфейсы процесса Сопроводительные  документы и образцы, передаваемые в отдел сертификации; Недостающие документы, отправленные поставщиком; Оповещение отдела закупок о некачественном товаре для дальнейшего возврата/уничтожения; Оповещение отдела продаж об открытии товара в продажу. Клиенты    процесса «С ертиф икация» Потребители; Руководство; Отдел закупок; Отдел продаж Требования клиентов процесса Потребители: Соответствие качества продукции установленным  государственным стандартам, гарантирующее  безопасность для здоровья и подтверждаемое наличием сертификата. Руководство: Минимизация  сроков проведения сертификации для ускорения оборачиваемости товаров. Отдел закупок: Получение полного комплекта документов необходимых для Сертификации от поставщика. Отдел продаж: своевременное извещение по телефону о получении сертификата, свидетельствующего о возможности открытия товара в продажу.

 

 

 

 Для чего нужны метрики

Невозможно  управлять тем, что нельзя измерить. Эта фраза встречается во многих руководствах по управлению ИТ, да и  по любому менеджменту. Невозможно управлять  производством без измерительных  приборов, позволяющих вовремя принимать правильные решения и реагировать на изменяющуюся ситуацию. Подразделение ИТ – то же производство, сравнимое по сложности со средним заводом, и для управления им нужны соответствующие инструменты. Метрики процессов - инструменты управления. От того, как будет выстроена система метрик, зависит, насколько эффективно руководитель сможет управлять организацией.

Разница между  метриками и показателями

Прежде, чем  двигаться дальше, договоримся о  терминах. Метрика - измеримый параметр.

Показатель – измеримый  параметр достижения определенной цели. Для показателя должно быть определено целевое значение и желательная  тенденция.

Классификация метрик

Деятельность  любой ИТ организации можно разделить  на три сегмента

• Сервисы
• Процессы
• Инфраструктура

Каждым из этих сегментов следует управлять  и, следовательно, измерять.

Сервисные метрики

Показывают, как предоставляются  наши сервисы. Эти метрики соответствуют  параметрам сервисов согласованным  в SLA. Именно изменение этих метрик в  первую очередь чувствует на себе заказчик. Они формулируются в терминах, понятных заказчику, и должны коррелировать с субъективным восприятием заказчика.

Примеры таких метрик: время  формирования отчета, количество клиентов, обслуженных в единицу времени  и т.д.

Именно за значения сервисных метрик ИТ организация отвечает перед заказчиком.

Очевидно, что  значение сервисных метрик зависит  как от работы процессов, так и инфраструктуры. Большое время простоя (сервисная метрика) может быть вызвано как избыточной загрузкой канала связи (технологическая метрика) так и недостаточной скоростью устранения инцидентов (процессная метрика).

Технологические метрики

Технологические метрики отражают здоровье инфраструктуры. К ним относятся текущая загрузка каналов связи, свободное дисковое пространство, количество сбоев в дисковом массиве и т.д. Контроль этих метрик чаще всего возлагается на системы мониторинга и управления событиями.

Процессные метрики и их классификация

Процессные  метрики показывают эффективность  работы внутренних процессов ИТ организации.

У любого процесса есть вход и выход, кроме того, процесс  использует ресурсы и подвергается управляющим воздействиям.

Выстраивая систему метрик необходимо помнить об этих четырех составляющих и измерять каждую из них.

Метрики входа  – измеряют нагрузку на процесс. Например, для процесса управления инцидентами  количество инцидентов – метрика  входа. Важно, что для менеджера  процесса метрики входа – показатель исключительно информационный, на них нельзя влиять, а можно только реагировать.

Метрики выхода, или метрики результативности –  показывают, насколько процесс достигает  своей цели.

Метрики ресурсов показывают загрузку и достаточность ресурсов, используемых процессом.

Метрики управления показывают, насколько процесс управляем, эффективны управляющие воздействия.

В CobiT предложена своя классификация метрик: показатели результативности, показатели управляемости. Кроме того, для каждого процесса предложена модель зрелости.

Разложение  метрик по четырем составляющим сопоставимо  с классификацией метрик, предложенной в CobiT. Показатели результативности –  метрики выхода, показатели рациональности – метрики ресурсов, зрелость процесса – метрика управляемости.

Очевидно, что, планируя целевые значения для различных  метрик, следует балансировать их между собой. Потому что процесс  может быть очень результативен  и совсем нерационален и наоборот. Например, мы можем устранять все  инциденты за полчаса, силами тысячи человек, или же справляться десятком человек, но устранять инциденты за месяц.

Отчетность  корректирующие меры

Показатели  не интересны сами по себе, они нужны  для осуществления управленческих воздействий на процесс. Следовательно, ответственность за достижение целевых показателей должна быть возложена на руководство процесса и на сотрудников, назначенных на роли в процесс.

Должна быть выстроена система отчетности по показателям. Важно, чтобы на каждом уровне управления были представлены соответствующие показатели. Вряд ли директору по ИТ будет интересно анализировать статистику сбоев одного из дисковых массивов. Система отчетности должна быть выстроена таким образом, чтобы на каждом уровне, каждый менеджер контролировал и отвечал за 3-9 показателей. Большее количество трудно удерживать под постоянным контролем.

Вопросы мотивации

Зачастую показатели эффективности процесса используют для постановки личных целей и  мотивации сотрудников. На первый взгляд, это логичное и правильное решение. Однако у человека, зарплата которого зависит от выполнения целевых значений, будет слишком велико искушение "подправить" показатели в свою пользу. Такая "правка" приводит к нарушению главного принципа использования показателей – объективности и достоверности, как если бы врач ставил диагноз и назначал лечение на основании неправильной информации о температуре пациента.

Как этого избежать? Можно создать развитую службу внутреннего  аудита, которая гарантировала бы актуальность показателей. Но, зачастую, затраты на содержание такой службы неоправданны. Однозначного рецепта тут нет. Приходится искать разумный баланс между доверием и контролем.

Выстраивание  системы показателей ИТ

Процессы работают не в вакууме. Каждый процесс направлен  на достижение определенной цели, связан с другими процессами и вносит свой вклад в предоставление сервисов. Цель каждому процессу должна ставиться исходя из того, какой аспект сервиса им поддерживается.

Таким образом, первичны цели сервисов, параметры, зафиксированные  в SLA. Цели процессов и показатели, их измеряющие, должны определяться путем декомпозиции этих параметров. Например, в SLA может быть зафиксирована целевая доступность сервиса. Очевидно, что на доступность сервиса влияют такие показатели как время устранения инцидентов, количество инцидентов, успешность проведения изменений и пр. Целевые значения этих показателей должны определяться из целевого значения доступности сервиса. Также понятно, что значимость каждого из этих показателей неодинакова и может меняться в зависимости от условий.

Исходя из значимости каждого показателя ему должен быть присвоен соответствующий вес.

Проведя декомпозицию на несколько ступеней, можно выстроить  систему целей и показателей  организации. Такая система предоставляет  руководству организации инструмент оперативного контроля и быстрой диагностики, основу для принятия решений как на операционном, так и на тактическом и, даже, стратегическом уровне.

На основании чего строить систему показателей?

Чем же руководствоваться  при построении системы измерений  для ИТ процессов?

В первую очередь, конечно, CobiT. В этой методологии  предлагается процессная модель, состоящая  из тридцати четырех процессов. Считается, что любая деятельности внутри организации  ИТ может быть отнесена к одному из этих процессов. Для каждого процесса приведен набор показателей результативности и рациональности. Проблема в поверхностном и общем описании метрик. При использовании рекомендаций CobiT способы измерения целевые значения и алгоритмы расчета показателей придется продумывать самостоятельно.

Что касается ITIL®, то он более конкретен. В нем можно  найти достаточно подробный перечень показателей для каждого процесса со способами их измерения и желательными тенденциями. Однако, в ITIL®, как известно, описаны не все возможные процессы ИТ. Например, за показателями процесса Разработки ПО придется обращаться к другим источникам.

В теме про измерения  процессов невозможно не затронуть  Карту Сбалансированных Показателей (BSC). Этот инструмент, изначально разработанный  для управления предприятием, с успехом может быть применен для системы управления ИТ. Основной постулат BSC в том, что, выстраивая систему целей организации, опасно допустить перекос в ту или другую сторону. Например, уделять все внимание финансовой эффективности, не обращая внимания на лояльность клиентов или организацию внутренних процессов.