Журнал об электронном контенте, документах и бизнес-процессах
ИТ-директору Делопроизводителю Кадровику Бухгалтеру
Workflow и управление бизнес-процессами

О двух подходах к описанию бизнес-процессов IT-подразделений

  1 комментариев Добавить в закладки

Ольга Бурносова,

консультант

Департамент консалтинга компании «Ай-Теко»

 

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

 

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

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

Для наглядности описания и сравнения предложенных подходов рассмотрим следующий пример: Подразделение — пользователь IТ-услуг обращается в IТ-подразделение за услугой и получает ее (отметим, что с целью наглядности и желания точнее передать нашу идею, в схемах мы предлагаем «облегченный» вариант процесса, не обремененный ветвлениями, которые часто имеют дело на практике).

Формируется следующая цепочка работ (см. рис. 1):

Бизнес-процесс. DIRECTUM-Journal.ru

Рис. 1. На схеме четко просматривается последовательность выполнения функций процесса, от начала до конца

 

                   1. Пользователь IТ-услуг направляет запрос на предоставление услуги;

                   2. IT-подразделение идентифицирует Пользователя (например, на вопрос: какого рода услуги он имеет право получать), и проводит Обработку запроса;

                   3. Если потребовалось уточнение информации, IТ-подразделение отправляет Пользователю запрос на получение дополнительной информации;

                   4. Пользователь предоставляет запрашиваемую информацию;

                   5. В IТ-подразделении заказ регистрируется и направляется на исполнение, пользователю сообщается номер заказа;

                   6. Пользователь в ожидании исполнения своего заказа может затребовать у IТ-подразделения информацию о текущем состоянии исполнения заказа;

                   7. IТ-подразделение предоставляет информацию о текущем состоянии исполнения заказа Пользователя;

                   8. Как только заказ (услуга) Пользователем получен(а), Пользователь информирует IТ-подразделение об этом;

                   9. После этого запрос в IТ-подразделении может быть закрыт как Выполненный.

 

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

Она может быть полной, для нашего примера: работы 1-2-3-4-5-6-7-8-9.

Или неполной, для нашего примера: работы 1-2-5-6-7-8-9, работы 1-2-5-8-9 или работы 1-2-3-4-5-8-9.

Тот же самый процесс опишем с использованием другого подхода (см. рис. 2):

Бизнес-процесс . DIRECTUM-Journal.ru

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

 

Мы — IТ-подразделение, являемся провайдером IТ-услуг для наших Пользователей, исполняем их запросы согласно утвержденному в Соглашении Уровню обслуживания.

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

●     либо это первичный запрос от Пользователя на предоставление конкретной услуги;

●     либо это ответ Пользователя на наш запрос дополнительной информации;

●     либо это запрос Пользователя о состоянии исполнения его заказа;

●     либо это сообщение Пользователя о получении им услуги.

 

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

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

Рассмотрим подробнее оба подхода и покажем их положительные и отрицательные стороны.

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

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

Такой подход применим для описания процессов «как есть» и «как будет». Он не требует слишком большой формализации данных. Его можно в полной мере использовать для повышения эффективности управления IT-подразделением.

В случае второго подхода (см. рис. 2) взгляд на бизнес-процессы IT-подразделения — со стороны самого IT-подразделения, т.е. изнутри. Вы находитесь внутри механизма. На вход поступают потоки данных, для их обработки запускаются соответствующие, конкретные цепочки процедур и функций, на выход подается продукт (информация), соответствующий установленным нормам.

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

Такой подход применим скорее при описании процессов «как будет». А также он может стать хорошей основой для наложения системы автоматизации, если в дальнейшем подразумевается автоматизация процессов IT-подразделения.

Руководителю IT-подразделения полезно, конечно, иметь у себя описания бизнес-процессов, сделанных на основе обоих подходов.

Первый подход позволит рассматривать процессы IT-подразделения на основе принятой в компании и понятной топ-менеджменту организации методологии, позволит Руководителю ИТ увидеть свое подразделение во взаимодействии с другими подразделениями внутри компании и общаться с ними на одном языке.

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

Источник: IT Manager

Похожие записи
Комментарии (1)
Борис Зверев 09 февраля 2007 г. 14:39  
Статья производит весьма неоднозначное впечатление.
С одной стороны, действительно, при описании процессов крайне важно определить "точку зрения", с которой описывается процесс, т.е. в данном случае - с т.з. "внешней", т.е. потребителя услуг, и внутренней - поставщика. Не обязательно эти схемы будут совпадать. Но тем не менее, некие обязательные элементы должны пристутсвовать. Вот в выборе этих обязательных элементов я с автором статьи и не соглашусь.
1. В первом подходе описана действительно простая линейная цепочка процесса. В то же время отсутствует связь и соответствующие элементы процесса - фрагмент цепочки "исполнение заявки -> внутренний контроль исполнения заявки" и фрагмент "доставка заказа потребителю (для продукта или онлайн-услуги; для off-line услуги - уведомление о выполнении) -> подтверждение выполнения заявки клиентом". При этом под удовлетворённостью тут понимается не "уровень удовлетворённости клиента" - параметр, используемый в CRM, а просто признак признания клиентом статуса "заказ выполнен". На схеме этих элементов нет. Говорить об упрощении визуализации модели для данных элементов, я считаю, некорректно, ибо они являются ведущими для "клиенто-ориентированных" процессов (даже если процессы - внутри компании, всё равно у такого процесса есть клиент - потребитель). Более того, отсутствие этих фрагментов сводит на нет возможность анализа эффективности и качества работы, а при биллинге сервисных работ - невозможно формализовать некоторые биллинговые функции сервисной службы.
Вторая схема вызывает ещё большие вопросы. Такое впечатление, что разговор только о диспетчере cal-центра на поддержке 1-го уровня. Вся остальная часть ИТ-службы представляется глубоким бэк-офисом, этаким чёрным ящиком, у которого нет ни входов, ни выходов - на схеме отсутствуют и фрагменты цепочек, да и вообще логически необходимые функциональные, информационные и рабочие связи.
Объясню, в чём опасность такого подхода к описанию процессов. На схемах присутствуют блоки "направление на исполнение". Понятно, что из этого блока есть 2 выхода: первый - это информационный выход к заказчику с информацией о передачи заказа "к исполнению". Второй - непосредственная передача заявки на исполнение в соответствующую структуру. Не обязательно расписывать второй выход на этом уровне декомпозиции - но фрагмент цепочки должен быть, иначе получается, что кроме информации о номере заказа, к клиенту больше ничего не уходит. Что не есть правильно. (Кстати, первая схема в этом плане корректней)
Сейчас обсуждают
Больше комментариев