| 23.05.2018

Одна из типичных задач, так или иначе с завидной периодичностью «падающих» в ИТ, - требование по оптимизации бизнес-процессов. И, как ни странно, зачастую именно это заставляет коллег «изобретать велосипед», хотя вроде бы все велосипеды изобретены до нас... Из данного посыла и родилась статья - краткое практическое пособие по оптимизации бизнес-процессов, предложенное человеком, который реализовал подобные преобразования на процессах, охватывающих деятельность более 1000 сотрудников.

С чего начать?

Как и любое преобразование, оптимизация бизнес-процессов начинается с постановки цели. Чего мы хотим добиться в результате оптимизации? Что должно получиться в итоге и что не должно произойти ни при каких обстоятельствах? Ответы на эти вопросы помогут сформулировать цель оптимизации процессов. Отмечу, что цель может быть общей и для всех процессов, и для каждого. Как правило, можно выделить подцель - с указанием конкретных измеримых параметров того, что должно быть оптимизировано. Например: «Целью проекта оптимизации бизнес-процессов является уменьшение времени выпуска изделия со 100 до 80 часов, при уменьшении процента брака с 7 до 3%». Это конкретная цель. Для каждого процесса можно поставить и свою цель, коррелирующую с общей. Например, одной из подцелей может быть «Снижение срока проектирования нового изделия с 12 до 10 часов путем оптимизации процесса проектирования изделий». Тут, правда, большой отдельный вопрос: за счет чего и как выполнять поставленные цели (скажем, снижение срока проектирования запросто может отразиться на балансе «скорость - качество»).

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

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

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

Как найти точки оптимизации?

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

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

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

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

На этом этапе кроме формирования идей важно выполнять их анализ на реализуемость и на расходы, которые следует предусмотреть на изменения, вкупе с возможной выгодой. Между прочим, проводить идеи по оптимизации сквозь «сито реальности» очень полезно. Во-первых, работа с «ситом» позволит лучше сформировать и понять критерии оптимизации. Во-вторых, прогоняя через «сито», мы выносим на обсуждение экспертов и руководства идеи, которые могут принести определенный эффект.

В ряде случаев я фиксировал идеи «из отбраковки» и предлагал ознакомиться с ними экспертам. С одной стороны, в «отбраковку» могло попасть что-то дельное. С другой - элементы идей могли пригодиться при обсуждении оптимизации процессов. И с третьей - я демонстрировал логику «сита», чтобы снять вопросы типа «почему эта идея не в скопе».

Важно отметить, что для оптимизации процессов необходимо выбирать «правильную» нотацию (способ описания) бизнес-процесса. Ведь процесс, описанный в определенной нотации, может оказаться непригодным для дальнейшей трансформации «де-юре». Например, потому что он в силу выбранной схемы не содержит важной информации или, наоборот, имеет избыточное описание. И если второй случай (избыточное описание) чреват легким раздражением, то первый (недостаточность информации) в худшем варианте способен породить повторный виток описания. Поэтому очень важно, приступая к описанию бизнес-процессов с целью оптимизации, выбирать схему, которая будет необходима и достаточна для дальнейшей работы.

Карта оптимизации и тестирование

После того как найдены точки оптимизации, следующим шагом станет непосредственно построение карты предполагаемой оптимизации. Карта включает, во-первых, описание (схему) оптимизированного процесса, во-вторых, перечисление выгод от оптимизации и, в-третьих, краткий перечень мероприятий по оптимизации.

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

Важной точкой в вопросе оптимизации процессов лично я считаю «прогон» (моделирование) измененного процесса. Делается он так же, как в разделе «Как описать процесс?». Поэтому не буду повторять ранее изложенное, просто скажу, что «прогон» измененного процесса целесообразно делать путем сбора всех ключевых сотрудников процесса и последовательного моделирования движения работ по процессу, с разными возможными входными данными, вариациями и т. д. Эту операцию следует выполнять до момента защиты процесса. Операция очень полезна, потому что позволяет выявить вероятные узкие места, вскрыть не увиденные ранее противоречия и т. д. Кроме того, в результате такого моделирования могут и должны быть внесены корректировки в измененный процесс. А это, кроме того, что решает основную задачу - оптимизацию процесса, создает и задел для решения дополнительной задачи, а именно вовлечения сотрудников в ценность оптимизации и получаемых выгод.

Как внедрять изменение?

Самый интересный вопрос, который мне часто задавали: а что происходит после того, как сформирована и утверждена карта оптимизированного процесса? Я всегда отвечаю, что происходит «магия». На самом деле происходит самый интересный момент - внедрение изменений в процесс. Как я уже говорил, в данную карту, помимо самого процесса, резонно включить перечень мероприятий по внедрению изменений. А их, в свою очередь, целесообразно обсудить с всеми участниками и экспертами. А также утвердить у руководства. Фактически перечень мероприятий представляет собой прообраз плана трансформации бизнес-процесса. Для того чтобы он принял законченный вид, нужно облечь его в формат плана и принять к исполнению.

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

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

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

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

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

Регламент работы сотрудника, он же «ролевая инструкция» . Тут очень подробно написано, кто что делает на каком шаге. И в идеале - что делать в непонятных ситуациях (схема эскалации, заморозки решения и т. д.);

Ответы на часто задаваемые вопросы (это может быть некоторая онлайн пополняемая база знаний).

Предположим, мы подготовились к внедрению: есть смоделированный процесс, есть материалы и согласованная схема мероприятий... Вроде бы - бери и делай. Но и в период внедрения требуется соблюсти определенные правила. Их несколько.

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

Внедрение обязательно должно включать работу с участниками процесса, которых затрагивает и не затрагивает изменение. На встрече происходит презентация схемы участникам процесса («как было», «как будет» и ключевые изменения), обозначаются даты, план мероприятий и ответственные (в идеальном варианте данные работы необходимо включать в приказ, для обеспечения их проведения).

Необходимо заранее подготовить регламенты. Они могут быть частью приказа, на них может быть ссылка в приказе, но они должны существовать. В регламентах должно быть написано, что теперь должен делать применительно к процессу каждый его участник, как будет оцениваться его работа и кто этим займется (на практике часть «кто и как оценивает» обычно вызывает ступор - именно поэтому ее надо проработать максимально подробно).

Внедрение необходимо делать, заручившись поддержкой сотрудников, участвующих в процессе. Можно и «по-жесткому»: без поддержки, но эта схема работает, только если управление в принципе построено на жесткой вертикали.

И про людей

Еще один весьма актуальный вопрос, который следует затронуть: как работать с сопротивлением, возражением, страхом? Не секрет, что любое организационное изменение (а изменение процессов - это именно оно) обычно вызывает стресс и панику среди рядовых сотрудников. И если с ним ничего не сделать, то могут возникнуть последствия, связанные с ухудшением климата в коллективе. И, соответственно, ухудшение производительности в целом, вплоть до саботажа.

Как не допустить этого? Во-первых - до начала проекта открыто его анонсировать. Довести до каждого сотрудника, особенно до тех, кто непосредственно работает в трансформируемых процессах, цели и задачи реорганизации.

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

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

Если в результате трансформации должны быть проведены кадровые перестановки, их следует готовить заранее. Если перестановки связаны с перемещением, то разъяснить тем, кого перемещаем, как это будет происходить, когда и что они выиграют и что, возможно, потеряют. Если перестановки связаны с увольнением, оно также должно готовиться заранее, с точки зрения юридических оснований, компенсаций и т. д. Увольнения важно не замалчивать, и в любой момент времени быть готовым дать ответ на вопрос «почему ушел такой-то сотрудник?».

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

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

Ключевые слова: ,

Горячие темы: Бизнес в цифре

ИТ эксперт. Высшее техническое образование. Публикуется в ИТ-прессе с 2001 года, с IT Manager сотрудничает с 2009 года. Основные интересующие темы: отношения ИТ и бизнеса, облака, технологии ИТ для бизнеса, управление, проекты, консалтинг, СПО.

Не так часто случается, что гостем нашей традиционной рубрики “Кто он, современный ИТ-руководитель?” становится представитель производителя товаров повседневного спроса. В последний раз это было два года назад, когда мы обсуждали основные задачи ИТ-службы такого предприятия. Сегодня мы продолжаем разговор на эту тему с ИТ-директором компании Efes Rus Василием Власюком, который в беседе с научным редактором PC Week/RE Ольгой Павловой поделился своим опытом руководства ИТ-департаментом регионального подразделения крупной международной компании.

PC Week: Свой нынешний пост вы занимаете недавно — с января текущего года. С какими особенностями в сфере ИТ и бизнеса вам уже пришлось здесь столкнуться?

Василий Власюк: До прихода в Efes Rus я тринадцать лет работал в компании MARS — одном из известнейших производителей кондитерских изделий. И хотя обе компании относятся к одному и тому же рынку потребительских товаров, продукт Efes Rus имеет характерное отличие: он тяжелый и при этом относительно дешевый. Цена грузовика с пивом и грузовика с шоколадом различаются в десятки раз, и потому очень большую роль в затратах играют перевозки. Соответственно в связи с необходимостью оптимизации транспортных потоков у нас более значима роль транспортного менеджмента.

Если же сравнивать пивоваренное производство с такими высокотехнологическими сферами, как банковское дело или телекоммуникации, то у нас влияние ИТ не столь велико. Если в банке, скажем, произойдет сбой какой-либо ИТ-системы, то может встать весь бизнес. Мы же в подобной ситуации можем некоторое время продолжать работу без каких-либо значительных последствий.

PC Week: Наверное, это служит поводом для бизнеса считать ИТ-департамент вспомогательным подразделением, не приносящим никакой прибыли?

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

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

PC Week: А где вы находите ИТ-специалистов, разбирающихся в бизнес-процессах?

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

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

PC Week: Какие первые шаги вы предприняли на новом месте?

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

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

PC Week: Какие вопросы входят в вашу компетенцию как ИТ-директора?

В. В.: Я вижу свою задачу отнюдь не в решении технических вопросов. Если бы это было так, мне не нужна была бы сложная ИТ-структура, а требовались бы просто консультанты, выполняющие распоряжения бизнеса. Моя миссия заключается в том, чтобы разбираться с проблемами в бизнес-процессах и предлагать варианты их решения. Конечно, эти решения могут быть непопулярны, поскольку предполагают изменение не ИТ-систем, а бизнес-процессов. На практике подобное случается часто, и приходится настойчиво и последовательно объяснять руководству, почему такие изменения необходимы.

Надо сказать, что сегодня Efes Rus переживает непростой период, связанный со слиянием двух компаний (два года назад был создан стратегический альянс британского концерна SABMiller и турецкой Anadolu Efes, в рамках которого компании объединили усилия на рынках России, Турции, а также в странах СНГ, Центральной Азии и Ближнего Востока. — О. П. ). В этой связи передо мной стоит серьёзная задача по объединению разных ИТ-ландшафтов и ИТ-коллективов, выработке единой ИТ-стратегии.

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

PC Week: Что будет представлять собой разрабатываемая вами ИТ-стратегия?

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

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

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

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

PC Week: Помимо закупки мощностей ЦОДов есть ли у вас планы по переводу каких-либо ИТ-сервисов на аутсорсинг?

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

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

Другая проблема использования аутсорсинга связана с тем, что при покупке сервиса требуется тратить время на то, чтобы управлять им, согласовывать уровни предоставления этого сервиса (SLA), следить за тем, чтобы они выполнялись. А если не выполняются, урегулировать разногласия. К сожалению, не получается просто купить и избавиться от забот.

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

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

PC Week: Как вы относитесь к другим популярным сегодня трендам, таким как облачные вычисления, большие данные и прочие?

В. В.: Я считаю, что облачные вычисления по сути очень похожи на аутсорсинг, поэтому отношение к ним у меня точно такое же. Но мы постоянно изучаем рынок — нужно всё-таки понимать, что там происходит. Например, SAP делает свое облако, посмотрим, что из этого выйдет. Но переходить в облако нужно только исходя из экономической выгоды. При этом первоначально я бы всё-таки попытался переводить в облако не бизнес-системы, а что-нибудь попроще — например, инфраструктурные решения, такие как корпоративная почта.

Что же касается больших данных, то если говорить честно, я никогда не сталкивался с этим на практике. Я знаю, что существует направление, позволяющее готовить гибкие отчеты и обладающее другими интересными возможностями, но я ни разу не видел бизнес, который решал бы сегодня какую-нибудь серьезную задачу с применением технологий Big Data. Мне кажется, это всё-таки дело будущего.

PC Week: Легко ли бизнес даёт деньги на внедрение новых технологий?

В. В.: Свою задачу я вижу в том, чтобы понять, что бизнес собирается делать в предстоящее время и какие проекты для этого следует реализовать. Далее я должен объяснить, что эти проекты будут стоить столько-то денег и добиться, чтобы бизнес с этим согласился. Естественно, руководство будет задаваться вопросом: “Почему так дорого?”. Поэтому мы должны прийти к соглашению и зафиксировать его. Допустим, бизнес хочет систему для мобильных компьютеров, которая будет стоить X млн. долл. Мы договариваемся и заносим данную сумму в бюджет. Однако в какой-то момент выясняется, что аппетиты отдела продаж выросли и их удовлетворение стоит уже не Х, а Х плюс некую дельту. Но в бюджете проекта этих денег нет. И тогда либо отдел продаж сокращает что-то из выполняемых задач, либо на собрании директоров решается, как перераспределить бюджет.

Правда, такая модель взаимодействия с бизнесом вступит в силу с будущего года. Это позволит оптимизировать наши планы.

PC Week: Какой опыт в последнее время был для вас самым полезным?

В. В.: Как ни странно это прозвучит, но именно уход из MARS. Это был непростой шаг, поскольку я уходил впервые в жизни, причем из компании, где я проработал много лет.

Главным обстоятельством, повлиявшим на мое решение, стало то, что в MARS имеется очень сильный глобальный ИТ-департамент, который покрывал часть моей ответственности как ИТ-директора в России. С одной стороны, это облегчает работу, а с другой — несколько ограничивало поле для принятия решений. Нередко случалось, что бизнес выдвигает некое требование, глобальные ИТ-руководители не собираются выделять на это деньги, и что я могу поделать? Слишком много времени уходило на проведение бесконечных сложных переговоров. В Efes Rus я имею большую свободу принятия решений, но при этом, конечно же, и большую ответственность. А в результате у нас в ИТ-департаменте самое большое развитие за этот год.

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

PC Week: Спасибо за беседу.

И, тем не менее, ум человеческий тщетно пытался постигнуть ее в течение более чем 2 000 лет, между тем как, с другой стороны, ему удался, но крайней мере приблизительно, анализ гораздо более содержательных и сложных форм. Почему так? Потому что развитое тело легче изучать, чем клеточку тела. К тому же при анализе экономических форм нельзя пользоваться ни микроскопом, ни химическими реактивами. То и другое должна заменить сила абстракции.

Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.

О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.

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

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

Определение бизнес-процесса

Итак, в чем же разница между бизнес-процессом и функций или даже просто обычным процессом? В чем разница между этими терминами? Я пришел к следующему выводу:

Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес-процесса – анализ и регламентация тех или иных действий в коллективе.

Почему я делаю особый упор на людях и коллективе:

1. Бизнес-процесс всегда происходит с участием человека. Если действия выполняются автоматической системой или программой, это уже не бизнес-, а технологический процесс или спецификация. И тогда в силу вступают несколько иные стандарты, методы описания и особенности реализации.
2. В бизнес-процессе всегда задействованы несколько людей в явной или неявной форме. Даже если человек работает один (например, писатель), все равно у него есть заказчики (издательские агентства) и потребители (читатели). Также продавец работает не в «вакууме» - у него есть поставщики и покупатели продукции, и все эти люди также задействованы тем или иным образом в бизнес-процессе.

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

Описание бизнес процесса

Также важно дать определение описанию бизнес процесса:

Описание бизнес-процесса – это описание последовательности действий сотрудников при выполнении определенных действий в графическом и текстовом виде с целью регламентации действий в коллективе, анализа и оптимизации их последовательности.

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

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

Лично я сравниваю создание нового бизнес-процесса с балансированием на тонкой нити гармоничного сочетания творчества, искусства и строгой математики.

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

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

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

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

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

Конечно, даже в технологическом процессе существует вероятность получения брака, но не один из закономерных вариантов, а последствия нарушения технологического процесса. В то время как в бизнес-процессе результат «на выходе» может отличаться в зависимости от выполнения тех или иных условий в «теле» бизнес-процесса, который выполнялся без нарушений и сбоев.

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

1. Берем заготовку A;
2. Соединяем ее с заготовкой B;
3. Обрабатываем под параметры C;
4. Получаем деталь.

Все однозначно и никаких условных «вилок» не предусматривается.

В бизнес-процессе вполне нормальной считается следующая ситуация:

1. Получаем вводные данные A:
   • Если данные соответствуют условию B, переходим на последовательность действий C;
   • Если данные соответствуют условию D, выполняем действия E.
2. Полученный результат передается на выход.

Т.е. уже в алгоритме процесса предусмотрены возможные условия и разные действия, зависящие от исходных или промежуточных данных.

История появления термина

Я не единожды читал информацию о том, что нотации бизнес-процессов IDEF0 появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.

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

Нотации – понятие современное, причем, нотациями называется нечто устоявшееся, стандартизированное, т.е. набор команд и обозначений, которыми пользуется много людей, а не одна или две организации. Можно придумать свой особый язык для описания бизнес-процессов или, например, программирования. Но пока он не получит «обкатку» в массовом использовании, не будут выявлены и устранены противоречия, неоднозначные трактовки, другие недочеты, пока он не стает устоявшимся и привычным для людей стандартом, называть его нотацией нельзя. Подробнее о нотациях я планирую написать позже. А сейчас вернемся к вопросу появления термина «бизнес-процесс».

На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.

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

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

Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна – уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.

***По теме методологически проработанных нотаций хочу также сказать пару слов. Почему я привел в качестве примера IDEF3: я еще не видел более проработанной методологически системы описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатывается. А если вы почитаете англоязычное описание IDEF3 (перевода на русский я пока не видел), то также сумеете оценить по достоинству глубину его проработки.

Очень быстро методология и нотации завоевали огромную популярность в бизнес-среде.
Нотации позволили получить инструмент описания взаимодействия людей и цифровых информационных систем.

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

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

Именно тогда появились понятия бизнес-процессов и нотаций бизнес-процессов, два неразрывно связанных понятия.

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

Продажи – это самый простой и наглядный пример. Каждый из нас в роли покупателя, а многие, и в роли продавца знакомы с этим процессом. И все мы знаем, что даже один и тот же человек в разных ситуациях (для разных товаров, разных покупателей, в разную погоду и вообще, в зависимости от настроения) будет продавать несколько по-разному. Но если описать и четко регламентировать определенный бизнес-процесс, то независимо от того, «с какой ноги встал утром продавец», процесс продажи будет определенным образом стандартизирован, ограничен определенными рамками, и, в результате, более стабилен.

Зачем моделировать (описывать) бизнес-процессы

Как я уже не единожды писал, я работаю преимущественно с малым и средним бизнесом, где предоставляю широкий комплекс услуг – от выявления проблем и «узких мест» в работе компании до внедрения предложенных мною решений на уровне программных продуктов и систем автоматизации.

Моделирование бизнес-процессов помогает решить сразу две задачи:

• Изучение бизнеса. Графическое изображение в виде схем, т.е. моделирование бизнес-процессов позволяет быстрее понять особенности работы компании и выявить возможные «узкие места».
• Обеспечение наглядности. Как известно, «одна картинка стоит тысячи слов». А потому схематическое изображение работы компании помогает руководителю и владельцу бизнеса намного быстрее понять суть проблемы и оценить предложенные варианты решения. В работе бизнес-консультанта (кстати, как и специалиста по внедрению программных продуктов) очень важно, чтобы клиент понимал все преимущества решения. Не менее важна и обратная связь – руководитель на схеме сможет увидеть какие-то недочеты еще на этапе обсуждения проекта, и внедрение обойдется без дополнительных сложностей и внесения изменений в проект «на ходу».

И сочетание изучения истории появления термина с моим личным опытом дает следующее определение:

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

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

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

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

Как описывать бизнес-процессы

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

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

Причина такого решения проста: в графическом виде информация лучше воспринимается. Если вы предложите человеку «стену текста», ему потребуется много времени и сил, чтобы разобраться, о чем вы вообще говорите. А охватить задачу целиком в этом случае – почти не реально. Другое дело графические схемы – здесь можно изучать бизнес-процессы на разных уровнях детализации, да и быстро «охватить взглядом в общем» графическую схему сможет любой человек.

1. Собираем участников процесса (сотрудников);
2. Собираем входящую информацию, необходимую и достаточную для запуска процесса;
3. Собираем используемые системы. Это может быть учетная система,CRM, электронная почта, таблицы Excel и т.д. Все, что реально используется в работе, необходимо зафиксировать.
4. Определяем ожидаемый результат – что будет в конце процесса.
5. Собираем последовательность действий, которые выполняет человек.
6. Вычленяем условия. В зависимости от разных входящих данных и промежуточных результатов действия могут быть разными.
7. Описываем всю собранную информацию в графическом виде в удобной нотации (IDEF3, BPMN 2.0 и т.д.).

Правила описания бизнес-процесса

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

• Законченность. Бизнес-процесс должен четко отвечать на вопрос, стоящий перед ним. Если мы говорим о процессе продажи определенного товара или услуги, то бизнес-процесс должен полностью описывать действия, необходимые для получения указанного результата, и завершающегося именно таким результатом (с определенными допущениями, о которых я говорил выше).
• Лаконичность. Бизнес-процесс должен сочетать в себе достаточность, т.е. описывать все необходимые этапы и действия, при этом быть максимально лаконичным для простоты восприятия. Лично я вывел для себя «правило 15 минут» - если за этот период времени я могу объяснить руководству компании представленный бизнес-процесс, значит, его можно показывать заказчику. Получается быстрее – прекрасно, требует больше времени и слов – надо подумать, что можно сократить и упростить.
  Я когда-то лично видел графическое описание бизнес-процесса, выполненное на листе 2 метров длиной (и соответствующей шириной). Его даже просто рассмотреть и понять, куда ведет какая стрелка крайне сложно. А как его пояснять заказчику, я лично не представляю.
  Помните, что человек воспринимает зрительно определенный объем информации, ограниченный, в том числе, определенным размером листа или экрана (это связано с особенностями зрения), а также числом элементов (возможности мозга также ограничены). Простой и лаконичный бизнес-процесс заказчик поймет, просто «охватив» схему взглядом. Сложный и перенасыщенный деталями придется изучать не один час просто для того, чтобы понять, что там отображено. Скорей всего, руководитель компании, который не является экспертом в работе отдельных подразделений, а также ограничен по количеству свободного времени, просто не будет изучать столь сложную конструкцию и не поймет сути даже самых выгодных предложений.
• Использование общепризнанных нотаций. Не стоит изобретать собственные обозначения и правила. Используйте нотации, которыми пользуются во всем мире. Я видел в книгах некоторых отечественных авторов попытки создания собственной системы обозначений. И, честно говоря, так и не понял, зачем они усложняют жизнь и себе, и своим читателям. Здесь как с языком – вы можете придумать свой особый язык, но понимать его никто, кроме вас, не будет. А если он окажется похож на существующие, то может еще и путаница появиться. Либо вас сочтут безграмотным, так как вы не по правилам известных языков используете пунктуацию, склоняете слова и т.д. Так и с нотациями – есть уже устоявшиеся, известные людям и, что также немаловажно, интуитивно понятные нотации. Они потому и стали популярны, что в процессе их создания и доработок постоянно тестировались на простоту, однозначность и удобство. Если вы будете использовать готовые нотации, вас будут понимать, воспринимать, как эксперта, да и сами правила нотаций уберегут вас от логических ошибок. Я лично рекомендую IDEF3 и BPMN 2.0.
• Все участники бизнес-процесса должны быть учтены и прямо указаны. И делать это необходимо без использования сносок с нумерациями, комментариях в объектах Swimm line (специальные сноски) и т.д. Этим нередко «грешат» любители создавать собственные конструкции вместо использования готовых нотаций. Где-то у них названия не помещаются, где-то им кажется, что длинное название в теле бизнес-процесса будет неудобным. В результате либо приходится искать в сносках, о ком именно идет речь, либо создатели таких бизнес-процессов просто забывают указать кого-то из участников.
• Понятное потребителю описание. Самое главное – ваш потребитель, тот, кто будет читать эту нотацию, должен быстро и, в идеале, даже без ваших пояснений понимать описание бизнес-процесс.

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

Распространенные мифы и заблуждения

Не «изобретайте велосипед»! Не нужно придумывать свои нотации.

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

Я не рекомендую так поступать. Во-первых, при использовании готовых инструментов вам не потребуется изобретать свои обозначения и стандарты. Все давно придумано до вас. При этом стандартные нотации действительно понятны интуитивно, читаются однозначно, известны многим людям. Во-вторых, в готовых системах (IDEF3, BPMN 2.0 и пр.) имеется проработанная методология и строгие ограничения. Их можно воспринимать как язык программирования и среду для работы с этим языком. Здесь вы просто не сумеете совершить многих ошибок, от этого вас уберегут стандарты синтаксиса и сама среда (ограничения в редакторе, автоматические проверки).

Не путайте описания бизнес-процессы компании и бизнес-процессы IT систем.

Во многих автоматизированных системах, например, 1С или Zoho CRM, существуют собственные сущности с названием «бизнес-процессы». Но к описываемым в этой статье бизнес-процессах эти сущности не имеют никакого отношения. Считайте их «омонимами», т.е. термины вроде звучат одинаково, но в нашем случае это – описание работы компании, а в IT системах – название группы функций и отчетов.

Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль).

О том, что бизнес-процессы должны приносить прибыль, я слышал даже от известных спикеров. Более того, видел даже “разбор ошибок” при создании бизнес-процесса, в котором очень много внимания уделяется тому, что 70% действий не несут никакой ценности.

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

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

Возможно ли создать идеальный бизнес-процесс - когда следует остановиться?

Нет. Бизнес--процесс должен быть простым, понятным, удобным, читабельным. Но идеальным он не будет никогда.

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

На самом деле, исходя из всего выше описанного, моделирование бизнес-процесса - это некоторое допущение, процесс творческий. С другой стороны, я в свое время не знал даже что ответить на просьбы описать еще “это” и “вон то”. Но со временем я понял, что бизнес-моделирование - это не просто творчество, но некий диалектический процесс. И уже само создание бизнес-процесса всегда будет нести в себе собственное отрицание. Здесь действительно стоит подходить к вопросу с философской точки зрения. И создавая бизнес-процесс, нужно помнить, что мы не можем охватить все и сразу, а потому он всегда будет несовершенен. Но при этом мы уже закладываем в него то, что будем совершенствовать в будущем. Стоит к этому подходить просто как к факту.

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

Процесс управления инцидентами

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

Инцидент - незапланированное прерывание или снижение качества ИТ-услуги. Сбой конфигурационной единицы,который еще не повлиял на услугу, также является инцидентом, как, например, сбой одного диска из массива зеркалирования.

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

Каким образом это сделать? В одном случае - максимально быстро «починить», в другом - в кротчайшие сроки восстановить наиболее важные функции, в третьем - применить обходное решение, и т.д.

Обходное решение (workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение.

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

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

В рамках достижения цели задачами процесса управления инцидентами являются:

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

Деятельность в рамках процесса управления инцидентами

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

В большинстве случаев инциденты регистрируются Service Desk, куда поступают сообщения о них. Регистрация всех инцидентов должна производиться немедленно после поступления сообщения по следующим причинам:

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

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

Пример информации по инциденту:

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

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

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

Каждом инциденту присваивается определенный приоритет.

Приоритет основывается на влиянии и срочности и используется для определения требуемого времени обработки.

Срочность (urgency) - мера того, насколько быстро с момента своего появления инцидент, приобретет существенное влияние на бизнес.

Степень влияния (impact) - мера воздействия инцидента на бизнес-процесс.

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

Приоритет устанавливается с учетом следующих факторов:

• Срочность
• Влияние на бизнес
• Риск для жизни или здоровья (risk to life or limb)
• Число затронутых услуг
• Финансовые потери
• Влияние на репутацию бизнеса
• Влияние на соответствие законам и другим нормами др.

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

Непосредственно при обращении пользователя специалистами Service Desk должна быть проведена предварительная диагностика инцидента для получения необходимой информации для установления причины инцидента, если это возможно, а также для корректной категоризации и передачу на следующую линию поддержки. Если решение инцидента находится в компетенции сотрудника Service Desk, то он может быть решен сразу. Служба Service Desk направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следующего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или направляет его группе поддержки очередного уровня.

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

В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.

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

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

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

Политики и базовые принципы процесса управления инцидентами

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

• Хорошая координация между пользователями и специалистами по решению инцидентов
• Решение инцидентов должно происходить в сроки, согласованные с бизнесом
• Удовлетворенность пользователей должна обеспечиваться на всех этапах решения инцидентов
• Деятельность по управлению инцидентами должна быть согласована с уровнем услуг и задачами поддержки на основе реальных потребностей бизнеса
• Все инциденты управляются, а их данные сохраняются в единой системе управления
• Все инциденты должны иметь стандартную схему классификации, которая соответствует бизнес процессам предприятия
• Записи инцидентов должны регулярно проверяться на предмет правильного ввода и их корректной классификации
• Все записи инцидентов по мере возможности должны иметь общие формат и набор информационных полей
• Должен быть общий и согласованный с бизнесом набор критериев для определения приоритетов и эскалации инцидентов

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

Временные рамки (Timescales) - для всех этапов обработки инцидентов должны быть согласованы временные рамки (они будут различаться в зависимости от уровня приоритета инцидента). Все группы поддержки должны быть в полной мере осведомлены об этих временных рамках.

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

Модель инцидента - это предопределенный способ обработки определенного типа инцидентов.

Модель инцидентов может включать следующие аспекты:

• Предопределенная последовательность действий по обработке определенного типа инцидентов
• Предопределенная ответственность
• Меры предосторожности до решения инцидента
• Временные рамки и процедуры эскалации
• Доказательства деятельности (записи, логи)

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

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

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

На положение инцидента в процессе обработки указывает статус. Примерами статусов могут быть:

• новый;
• принят;
• запланирован;
• назначен;
• активный;
• отложен;
• разрешен;
• закрыт.

Показатели процесса управления инцидентами

Для управления и оценки эффективности процесса управления инцидентами, а также для обеспечения обратной связи с другими процессами управления, ITIL предлагает использовать следующие основные показатели (CSF и KPI):

• CSF Быстрое решение инцидентов, минимизации их влияния на бизнес
• KPI Среднее время, затраченное на решение инцидента
• KPI Распределение инцидентов по статусам
• KPI Процент инцидентов, решенных первой линией поддержки
• KPI Процент инцидентов, решенных дистанционно
• KPI Количество решенных инцидентов, не повлиявших на бизнес
• CSF Поддержка качества ИТ-услуг
• KPI Общее количество инцидентов (контрольный показатель)
• KPI Размер очереди нерешенных инцидентов по каждой услуге
• KPI Количество и процент значительных (major) инцидентов по каждой услуге
• CSF Поддержка удовлетворенности пользователей
• KPI Средний балл опроса по пользователям /заказчикам
• KPI Процент удовлетворенности ответивших по сравнению с общим числом участвующих в опросе
• CSF Улучшение прозрачности и коммуникаций при решении инцидентов между бизнесом и персоналом поддержки ИТ
• KPI Среднее количество обращений в службу поддержки или других контактов с пользователями по поводу инцидентов, по которым уже было извещение
• KPI Количество претензий и проблем по поводу содержания и качества коммуникаций при решении инцидентов
• CSF Совмещение приоритетов деятельности по управлению инцидентами с приоритетами бизнеса
• KPI Процент инцидентов, решенных без нарушения целей SLA
• KPI Средняя стоимость одного инцидента
• CSF Обеспечение использования стандартных методов и процедур при решении инцидентов
• KPI Количество и процент неправильно назначенных инцидентов
• KPI Количество и процент неправильно классифицированных инцидентов
• KPI Количество и процент инцидентов, обработанных сотрудниками Service Desk
• KPI Количество и процент инцидентов, связанных с изменениями и релизами

Риски и сложности

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

• Необходимость раннего обнаружения инцидентов - потребуется конфигурацию инструментов управления событиями (мониторинга), а также обучение пользователей информированию об инцидентах
• Необходимость тотальной регистрации инцидентов
• Необходимость внедрения адекватной автоматизированной системы управления и обеспечения интеграции ее с различными системами управления ИТ (например, CMS)
• Необходимость обеспечения высокой доступности единой точки контакта
• Необходимость обеспечения следования процессу и выявление случаев обхода процедур процесса — если пользователи будут устранять возникающие ошибки сами или напрямую связываться со специалистами, не следуя установленным процедурам, ИТ-организация не получит информацию о реально предоставляемом уровне услуг, числе ошибок и многое другое. Отчеты руководству также не будут адекватно отражать ситуацию.
• Нехватка ресурсов при решении инцидентов, перегруженность инцидентами и откладывание «на потом» — при неожиданном росте количества инцидентов для правильной регистрации может не оказаться достаточно времени, т. к. до окончания ввода информации об инциденте от одного пользователя возникает необходимость обслуживать следующего. В этом случае ввод описания инцидентов может производиться недостаточно точно и процедуры по распределению инцидентов по трупам поддержки не будут выполняться должным образом. В результате решения получаются некачественными и рабочая нагрузка увеличивается еще больше. В случаях, если число открытых инцидентов начинает интенсивно расти процедура экстренного выделения дополнительных ресурсов внутри организации может предотвратить перегрузку персонала.
• Отсутствие каталога услуг и соглашений об уровне сервисов (SLA) — если поддерживаемы услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в управление инцидентами, бывает трудно обоснованно отказать пользователям в помощи.
• Недостаточная приверженность процессному подходу со стороны руководства и персонала - решение инцидентов с помощью процессного подхода обычно требует изменения культуры и более высокого уровня ответственности за свою работу со стороны персонала. Это может вызвать серьезное сопротивление внутри организации. Эффективное управление инцидентами требует от сотрудников понимания и реальной приверженности процессному подходу, а не просто участия.

Ценность для бизнеса

Внедрив процесс управления инцидентами в соответствии с рекомендациями ITIL и решив все сложности, которые могут возникнуть при внедрении, может быть получена следующая ценность для бизнеса в целом:

• Возможность снизить незапланированные работы и затраты для бизнеса и ИТ, вызванные инцидентами
• Возможность обнаруживать и устранять инциденты, сокращая время простоя и повышая доступность бизнес услуг
• Возможность выделять ресурсы ИТ в соответствии с их приоритетом для бизнеса
• Возможность инициировать улучшение услуг на основании знания природы инцидентов
• Возможность идентифицировать потребности в дополнительном обучении персонала

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

Со временем может возникнуть потребность изменения ИТ инфраструктуры. Это может быть вызвано рядом причин - необходимостью устранения проблемы, желанием повысить качество ИТ сервисов, старением инфраструктуры или изменением законодательства.

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

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

За обеспечение контроля над изменениями в ITIL отвечает ряд процессов преобразования услуг (Service Transition): Управление изменениями, Управление сервисными активами и конфигурациями и управления релизами и развертыванием.

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

В рамках достижения цели задачами процесса управления изменениями являются:

• Реагировать на изменяющиеся бизнес-требования заказчика, максимизируя ценность для бизнеса и уменьшая количество инцидентов, сбоев и повторных работ
• Реагировать на запросы на изменение со стороны бизнеса и ИТ для обеспечения гарантии соответствия услуг нуждам бизнеса
• Гарантировать, что все изменения зарегистрированы, оценены, авторизованы, приоритизированы, запланированы, протестированы, внедрены, документированы, а также проведен их обзор контролируемым образом
• Гарантировать, что все изменения конфигурационных единиц регистрируются в системе управления конфигурациями (CMS)
• Оптимизировать бизнес-риски

В охват процесса управления изменениями попадают изменения в ИТ-инфраструктуре, процессах, инструментах, метриках и документации, а также изменениях в ИТ-услугах и других конфигурационных единицах.

Деятельность в рамках процесса управления изменениями

На рисунке приведена общая схема процесса управления изменениями. Для обеспечения контроля изменений все изменения должны быть зарегистрированы. При необходимости внесения изменения, входящего в охват процесса, должен быть подан запрос на изменение (request for change, RFC).

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

В рамках процесса управления изменения в ITIL выделяется три типа изменений:

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

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

Нормальное изменение - изменение, не являющееся срочным или стандартным. Нормальные изменения обрабатываются по определённым шагам процесса управления изменениями.

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

Ниже приведен пример информации, которая может включаться в запросы на изменение (RFC):

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

Запрос на изменение создается инициатором, в качестве которого может выступать отдельный человек или группа людей. Если требуется значительное изменение, может потребоваться предложение об изменении (change proposal).

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

Все полученные запросы на изменения должны быть зарегистрирован и для каждого изменения должна быть создана запись об изменении (change record).

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

После регистрации запроса на изменение (RFC) Управление изменениями делает первичную проверку, нет ли среди них неясных, нелогичных, непрактичных или ненужных запросов. Такие запросы отклоняются с объяснением причин. Сотруднику, направившему запрос, всегда должна быть предоставлена возможность для защиты своего запроса.

Для того чтобы оценить изменение ITIL предлагает ответить на 7 вопросов (7 ‘R’s):

• Кто инициатор? (RAISED) (Who RAISED the change?)
• Какова причина? (REASON) (What is the REASON for the change?)
• Какой требуется результат? (RETURN) (What is the RETURN required from the change?)
• Какие риски связаны с изменением? (RISKS) (What are the RISKS involved in the change?)
• Какие ресурсы требуются для проведения изменения? (RESOURCES) (What RESOURCES are required to deliver the change?)
• Кто отвечает за построение, тестирование и внедрение изменения? (RESPONSIBLE) (Who is RESPONSIBLE for the build, test and implementation of the change?)
• Какие взаимоотношения между этим и другими изменениями? (RELATIONSHIP) (What is the RELATIONSHIP between this change and other changes?)

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

Позднее к записи может добавляться следующая информация:

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

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

Пример системы кодирования приоритетов:

• Низкий приоритет — изменение желательно, но его внедрение может быть отложено до более удобного времени (например, до следующего релиза или планового обслуживания).
• Обычный приоритет — нет особой срочности и высокой степени воздействия, но изменение не следует откладывать.
• Высокий приоритет — изменение касается серьезной ошибки, затрагивающей ряд пользователей, или новой нетипичной ошибки, затрагивающей большую группу пользователей, или связано с другими срочными вопросами.
• Наивысший приоритет — запрос на изменение (RFC) касается проблемы, серьезно влияющей на важнейший для заказчиков сервис. Изменения с таким приоритетом классифицируются как «экстренные».

• Низкая степень воздействия — изменение, требующее выполнения небольшого объема работ.
• Существенная степень воздействия — изменение, требующее значительных усилий и оказывающее существенное воздействие на ИТ-услуги. Эти изменения обсуждаются на совете по изменениям (CAB) для определения необходимых усилий (ресурсов и др.) и потенциального воздействия.
• Наивысшая степень воздействия — изменение, требующее значительных усилий. руководителю процесса необходимо предварительно получить авторизацию на выполнение изменения руководства ИТ или руководящего комитета ИТ, после чего изменение представляется на рассмотрение совета по изменениям (CAB).

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

Эти коды могут быть представлены в цифрах, например: низкая степень=1/ высшая степень = 3

Большинство изменений относятся к двум первым категориям. На основании оценки влияния изменения должен быть определён уровень авторизации изменения (полномочные лица, change authority), например, как это показано на рисунке.

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

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

В рамках процесса управления изменениями осуществляется ведение графика изменений.

График изменений - документ с перечнем всех утвержденных изменений и плановых дат их реализации, а также с примерными сроками реализации более поздних изменений.

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

Повестка дня совещания совета по изменениям должна включать ряд постоянных пунктов, в том числе:

• Неуспешные или неавторизованные изменения
• Запросы на изменения (RFC), предложенные на рассмотрение членам совета по изменениям в порядке приоритетов
• Запросы на изменения (RFC), рассмотренные советом по изменениям
• Планирование изменения и обновление графика изменений
• Оценки проведенных изменений
• Процесс управления изменениями, дополнения и изменения процесса
• Достижения процесса и выгоды для бизнеса, полученные с помощью процесса управления изменениями
• Незавершенные изменения и изменения в процессе обработки
• Планирование запросов на изменение к рассмотрению на следующем совете по изменениям
• Проверка неавторизованных изменений, обнаруженных процессом управления сервисными активами и конфигурациями

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

Необходимо давать оценку произведенным изменениям, за возможным исключением стандартных изменений. При необходимости совет по изменениям (CAB) принимает решение о проведении последующих дополнительных мероприятий. Должны быть рассмотрены следующие вопросы:

• Изменение достигло поставленных целей?
• Пользователи и заказчики удовлетворены?
• Не возникло побочных эффектов?
• Объем ресурсов, использованных для внедрения изменения, соответствовал запланированному?
• Изменение было внедрено своевременно и без превышения затрат?
• План внедрения функционировал корректно?
• План восстановления функционировал корректно, если это было необходимо?
• И т.д.

Если изменение осуществлено успешно, запрос на изменение (RFC) может быть закрыт. Это происходит на этапе оценки результатов внедрения (PIR). Если же изменение закончилось неудачно, процесс возобновляется с того места, где он вызвал сбой, с использованием нового подхода. Иногда бывает лучше сделать возврат назад и создать новый или модифицированный запрос на изменение (RFC). Продолжение работы с неудачным изменением часто приводит к ухудшению ситуации.

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

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

Проведение экстренных изменений

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

Совет по экстренным изменениям (еСAB) - группа людей в составе совета по изменениям, которые принимают решения по экстренным изменениям. Решение о составе участников совета по экстренным изменениям может быть принято непосредственно при организации совещания. Необходимость участия определяется исходя из сути срочного изменения.

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

Политики и базовые принципы процесса управления изменениями

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

• Абсолютная недопустимость неавторизованных изменений, создание культуры изменений
• Соответствие управления изменениями процессам управления изменениями и проектами заказчиков
• Категоризация изменений, например инновационные, исследовательские, превентивные, корректирующие изменения
• Определение ответственности за изменения на всех стадиях жизненного цикла услуги
• Разделение ответственности за управление
• Создание единой точки ответственности за изменения для уменьшения вероятности конфликтующих изменений и риска сбоев в продуктивной среде

Показатели процесса управления изменениями

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

• Процент изменений, удовлетворивших требованиям заказчика
• Польза от изменения, выраженная как «ценность сделанных улучшений» + «предотвращенное негативное воздействие» по сравнению с затратами на проведение изменения
• Уменьшение количества нарушений услуг, дефектов и переделок, вызванных неточными спецификациями или недостаточной оценкой влияния
• Уменьшение количества неавторизованных изменений
• Уменьшение очереди запросов на изменения, процента незапланированных изменений и срочных исправлений
• Уменьшение количества изменений, потребовавших восстановления
• Уменьшение количества неуспешных изменений
• Среднее время исполнения по срочности/приоритету/типу
• Количество инцидентов, связанных с изменением
• Точность оценки изменений

Ценность для бизнеса

Внедрив процесс управления изменениями в соответствии с рекомендациями ITIL и решив все сложности, которые могут возникнуть при внедрении, может быть полученна следующая ценность для бизнеса в целом:

• Выставление приоритетов запросам на изменение от бизнеса и заказчиков и реакция на них
• Внедрение изменений, соответствующих согласованным требованиям к услугам оптимально по затратам
• Уменьшение количества неуспешных изменений, приводящих к прерыванию услуги, дефектам и переделкам
• Проведение изменений в соответствии с временными рамками, определенными бизнесом
• Отслеживание изменений в рамках жизненного цикла услуги и активов своих заказчиков
• Лучшая оценка качества, времени и стоимости изменений
• Оценка рисков, связанных с изменениями услуг (вводом или выводом из эксплуатации)
• Увеличение производительности персонала за счет минимизации количества незапланированных или «срочных» изменений, и, как следствие, увеличение доступности услуг
• Сокращение среднего времени восстановления за счет более быстрого и успешного внедрения корректирующих изменений
• Поддержка связи с процессом изменений бизнеса для выявления возможностей совершенствования бизнеса

Хотели бы Вы, чтобы предоставляемые вам услуги была качественными? Думаю, да. Одной из основных задач ITSM, и ITIL в том числе, является предоставление качественных ИТ-услуг.

Управление ИТ- услугами (IT service management, ITSM) - внедрение и управление качественными ИТ-услугами, которые соответствуют потребностям бизнеса.

Не всегда мнение провайдеров ИТ-услуг и заказчиков в отношении качества услуг сходится.

Качество - способность продукта, услуги, или процесса предоставлять ожидаемую потребителем ценность. Например, качество компонента может считаться высоким, если его работа оправдывает ожидания и обеспечивает требуемую надежность.

Выше приведено определение качества в соответствии с ITIL. Т.е. если мы хотим предоставлять качественные услуги, необходимо чтобы они соответствовали ожиданиям заказчика.

Как гласит известно утверждение: «Нельзя управлять тем, что нельзя измерить». Таким образом, чтобы обеспечить предоставление качественных услуг, необходимо сначала ожидания заказчика в отношении ИТ-услуг выяснить, согласовать, возможно в чем-то ограничить, например, если требование заказчика нереализуемо, и представить в измеримом виде. Дальше остается обеспечивать соответствие фактических параметров услуги ожиданиям заказчика и подтверждать это предоставлением соответствующей отчетности.

В соответствии с ITIL за согласование и документирование целевых показателей уровня услуги и ответственностей в соглашении об уровне услуги (SLA) и требованиях к уровню услуг (SLR) для каждой услуги и связанной с ней ИТ-деятельностью отвечает процесс управления уровнем услуг, который является жизненно важным процессом для каждой организации-поставщика ИТ-услуг.

Управление уровнем услуг (service level management) - процесс, отвечающий за обсуждение и заключение выполнимых соглашений об уровне услуг, и обеспечивающий их выполнение. Управление уровнем услуг отвечает за соответствие процессов управления ИТ-услугами, соглашений операционного уровня и внешних договоров согласованным целевым показателям уровня услуги. Управление уровнем услуг отслеживает и предоставляет отчётность по уровням услуг, проводит регулярную оценку услуг совместно с заказчиками и определяет необходимые улучшения.

Соглашении об уровне услуги (service level agreement, SLA) - cоглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон - поставщика ИТ- услуг и заказчика. Одно соглашение об уровне услуг может распространяться на множество ИТ-услуг или множество заказчиков.

Требование к уровню услуг (service level requirement, SLR) - требование заказчика к ИТ-услуге. Требования к уровню услуг основаны на бизнес-целях и используются для переговоров и согласования целевых показателей уровня услуги.

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

Целевой показатель уровня услуги (service level target) - обязательства, зафиксированные в соглашении об уровне услуг. Целевые показатели уровня услуги основываются на требованиях к уровню услуг и нужны для обеспечения того, чтобы ИТ-услуга соответствовала бизнес-целям. Целевые показатели уровня услуги должны соответствовать критерию SMART, и обычно основаны на ключевых показателях эффективности.

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

Управление уровнем услуг — это процесс, который связывает поставщика ИТ-услуг и заказчика. Этот процесс имеет следующие задачи:

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

Управление уровнем услуги должен обеспечивать постоянную связь и коммуникацию менеджеров организаций заказчиков и бизнеса. Это должно давать представление бизнесу о поставщике услуг и поставщику ИТ-услуг о бизнесе.

В охват процесса управления уровнем услуг должно быть включено:

• Организация отношений с бизнесом
• Обсуждение и согласование текущих требований и целей, документирование и сопровождение SLA для предоставляемых услуг
• Обсуждение и согласование требований и целей, документирование и сопровождение SLR для планируемых новых и изменяемых услуг.
• Формирование и сопровождение соглашений операционного уровня (OLA) для поддержки целей SLA.
• Оценка и согласование с целями SLA всех внешних договоров (UC) - совместно с управлением поставщиками.
• Предупреждение сбоев, снижение рисков и внедрение улучшений услуг совместно тс другими процессами.
• Предоставление отчетности и оценку в отношении всех услуг и анализ всех отклонений от целей SLA.
• Инициация и координация плана совершенствования услуг (SIP).

Соглашение операционного уровня (operational level agreement, OLA) - соглашение между поставщиком ИТ-услуг и другой частью той же организации.

Внешний договор (underpinning contract, UC) - договор между поставщиком ИТ-услуг и третьей стороной. Третья сторона предоставляет товары или услуги, поддерживающие предоставление ИТ-услуг для заказчика. Внешний договор определяет предмет и зоны ответственности, необходимые для достижения согласованных целевых показателей уровня услуги в одном или нескольких соглашениях об уровнях услуги.

План совершенствования услуг (service improvement plan, SIP) - формальный план для внедрения улучшений в процессе или ИТ-услуге.

Деятельность в рамках процесса управления уровнем услуг

На рисунке приведена общая схема процесса управления уровнем услуг.

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

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

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

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

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

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

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

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

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

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

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

• соглашения об уровне услуги, основанные на одной услуге;
• соглашения об уровне услуги, базирующиеся на заказчиках;
• многоуровневые соглашения об уровне услуг.

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

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

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

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

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

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

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

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

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

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

Разработка стандартов и образцов обеспечивает последовательную разработку всех соглашений, что в свою очередь облегчает их последующие использование, управление и эксплуатацию.

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

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

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

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

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

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

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

Для начала стоит попробовать управлять ожиданиями заказчиков. Это значит сформировать верные ожидания и цели, а затем систематически проактивно их корректировать, помня, что «удовлетворенность = восприятие - ожидания» (при значении большем или равном нулю заказчик удовлетворен). Соглашение об уровне услуг - это просто документы, и сами по себе не заменяют качество предоставляемой услуги (хотя и могут влиять не поведение и могут способствовать развитию должной культуры услуги, что даст и кратко- , и долгосрочный положительный эффект). Определенная степень терпения должна быть проявлена и быть частью ожиданий.

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

• периодическое анкетирование и опросы заказчиков;
• обратная связь на встречах по оценке услуг;
• обратная связь при проведении оценки проведенных изменений;
• телефонные опросы, проводимые службой Service Desk;
• анкеты удовлетворенности, раздаваемые при выполнении обслуживания и др. контактах;
• общение с группами пользователей (на форумах и т.п.);
• анализ жалоб и благодарностей.

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

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

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

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

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

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

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

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

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

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

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

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

На этих встречах должны планироваться меры по исправлению слабых мест в предоставлении и потреблении услуг. Решения должны протоколироваться, а их исполнение - отслеживаться и проверяться на следующих встречах.

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

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

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

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

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

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

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

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

Показатели процесса управления уровнем услуг

• CSF Важно обеспечить управление качеством сервисов в целом, включая охват и уровень предоставления:
• KPI Доля снижения несоответствий целям SLA
• KPI Доля снижения угроз несоответствий
• KPI Доля улучшений в восприятии и удовлетворенности заказчиков достижениями SLA на основании встреч по оценке сервисов и опросов удовлетворенности
• KPI Доля снижения несоответствий, связанных с зависимостью от третьих сторон (UC)
• KPI Доля снижения несоответствий, связанных с зависимостью от внутренних подрядчиков (OLA)
• CSF Предоставление сервисов в соответствии с договоренностями за приемлемые деньги:
• KPI Число и доля повышения числа полностью документированных SLA
• KPI Доля улучшений в SLA, направленных на совершенствование уже предоставляемых сервисов
• KPI Доля снижения стоимости предоставления сервисов
• KPI Доля снижения стоимости мониторинга и отчетности по SLA
• KPI Доля повышения скорости разработки и согласования SLA
• KPI Частота встреч по оценке сервисов
• CSF Управление интерфейсом между бизнесом и пользователями:
• KPI Повышение числа сервисов, покрытых SLA
• KPI Документирование и согласование процесса и процедур SLM
• KPI Снижение времени ответа и исполнения для запросов на SLA
• KPI Повышение доли SLA, пересматриваемых вовремя
• KPI Снижение доли невыполненных SLA, подлежащих пересмотру
• KPI Снижение доли SLA, требующих корректировки
• KPI Повышение охвата OLA и UC при снижении числа соглашений за счет их консолидации и централизации
• KPI Наличие документальных свидетельств улучшений по выявленным отклонениям от SLA
• KPI Снижение числа и тяжести несоответствий целям SLA
• KPI Эффективная оценка и обработка всех отклонений и несоответствий от SLA, OLA, UC

ITIL выделяет субъективные и объективные показатели эффективности управления уровнем услуг. Объективные:

• Число или доля достигнутых целей услуги
• Число и степень (тяжесть) отклонений и нарушений
• Число актуальных SLA (up-to-date)
• Число услуг, по которым своевременное предоставляется отчетность и проводится оценка

Субъективные:

• Улучшения удовлетворенности заказчиков

Риски и сложности

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

• Недостаток точных входных данных, вовлеченности и заинтересованности со стороны бизнеса и заказчиков
• Потребность в ресурсах и инструментарии для согласования, документирования, мониторинга, отчетности и оценки соглашений и уровней услуг
• Процесс может стать излишне бюрократичным, ориентированным на административные процедуры, а не на фактическое проактивное улучшение услуг
• Доступ и поддержка корректных и актуальных CMS и SKMS
• Неисполнение процедур SLM
• Бизнес ориентированные метрики слишком сложно мерить и улучшать, поэтому они не собираются
• Несоответствующий задачам уровень контакта и согласования
• Высокие ожидания и низкая удовлетворенность заказчиков
• Неэффективные коммуникации с бизнесом

Процесс управления проблемами

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

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

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

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

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

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

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

Деятельность в рамках процесса управления проблемами

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

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

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

• Управление инцидентами не может привязать (match) инцидент к существующим проблемам или известным ошибкам
• Анализ тенденций инцидентов показывает, что может существовать проблема
• Необходим анализ причины значительного (major) инцидента
• Другие ИТ-функции определили, что возможна проблема
• Персонал Service Desk не смог определить причину инцидента и есть подозрение, что этот инцидент может повториться
• Анализ инцидента группой поддержки показал, что есть (или может существовать) проблема
• Уведомление от поставщика о существовании проблемы, которую нужно решить

Возможными признаками проблем могут быть:

• Инциденты, повторяющиеся в:
• Один и тот же временной промежуток
• В одной предметной области (категории)
• В одном и том же CI или группе однотипных CI
• В одних и тех же локации, заказе, подразделении
• Объем однотипных инцидентов превышает некий уровень
• Для решения инцидента применено обходное решение
• Превышение предельного срока обработки инцидента(ов)

Анализ тенденций позволяет обнаружить области, которым требуется особое внимание. Независимо от метода обнаружения проблемы, все значимые данные о проблеме должны быть зафиксированы в записи о проблеме (problem record):

• Информация о пользователе(-ях)
• Информация об услуге(-ах)
• Информация об оборудовании
• Время регистрации
• Приоритет, категория
• Описание связанных инцидентов
• Предпринятые для диагностики и решения действия

Запись о проблеме - запись, содержащая детальное описание проблемы. Каждая запись о проблеме документирует жизненный цикл одной проблемы.

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

Классификация проблемы включает в себя следующее:

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

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

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

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

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

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

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

После окончания этапа выбора существует достаточно информации для подачи запроса на изменение. Далее исправление проблемы (известной ошибки) будет произведено под контролем процесса управления изменениями.

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

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

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

Политики и показатели процесса управления проблемами

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

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

Для управления и оценки эффективности процесса управления уровнем услуг, а также для обеспечения обратной связи с другими процессами управления, ITIL предлагает использовать следующие основные показатели (CSF и KPI):

• CSF Минимизация влияния на бизнес инцидентов, которые не могут быть предотвращены
• KPI Количество известных ошибок добавляется KEDB
• KPI Процент актуальности KEDB (по аудиту базы данных)
• KPI Процент инцидентов, закрытых службой поддержки («первой точкой контакта»)
• KPI Среднее время решения инцидентов, по которым открыта проблема
• CSF Поддержка качества ИТ-услуг путем устранения повторяющихся инцидентов
• KPI Общее количество проблем (как контрольный параметр)
• KPI Размер очереди по проблемам для каждой ИТ-услуги
• KPI Количество повторно случившихся инцидентов для каждой ИТ-услуги
• CSF Обеспечение качества и профессионализма в решении проблем для поддержания уверенности бизнеса в возможностях ИТ
• KPI Количество значительных проблем (открытых, закрытых и очередь)
• KPI Процент успешно выполненных обзоров значительных проблем
• KPI Процент обзоров значительных проблем, завершенных успешно и в срок
• KPI Количество и процент проблем, назначенных неправильно
• KPI Количество и процент проблем с неверной категоризацией
• KPI Очередь накопившихся нерешенных проблем и её тенденция
• KPI Количество и процент проблем, превысивших сроки решения
• KPI Процент проблем, решенных в рамках целей SLA целей
• KPI Средняя стоимость решения одной проблемы

Ценность для бизнеса

Внедрив процесс управления инцидентами в соответствии с рекомендациями ITIL и решив все сложности, которые могут возникнуть при внедрении, может быть полученная следующая ценность для бизнеса в целом:

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

Процесс управления сервисными активами и конфигурациями

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

• сложность актуализации: при внесении каждого изменения схему необходимо перерисовать и печатать заново, в противном случае на нее нельзя полагаться в случае необходимости
• ограниченный охват: компоненты инфраструктуры могут быть очень тесно переплетены между собой и не всегда все элементы могут быть отражены на схеме
• ограниченность информации: как правило, для каждого элемента указывается только самая важная информация, например, доменное имя или IP-адрес
• сложность анализа: при большом охвате схемы и при наличии различных сложных взаимосвязей между компонентами, анализ таких схем затруднителен

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

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

Управления сервисными активами и конфигурациями включает в себя два подпроцесса:

• Управление активами (Asset Management) - деятельность или процесс, отвечающий за отслеживание и предоставление отчётности о ценности и владении активами на всём протяжении их жизненного цикла
• Управление конфигурациями (Configuration Management) - деятельность или процесс, отвечающий за управление информацией о конфигурационных единицах, необходимой для предоставления ИТ-услуг, включая их взаимоотношения.

Задачи процесса управления сервисными активами и конфигурациями:

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

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

Система управления конфигурациями (configuration management system, CMS) - набор инструментов, данных и информации, которые используются для поддержки процесса управления сервисными активами и конфигурациями. CMS - часть общей системы управления знаниями по услугам, включает в себя инструменты для сбора, хранения, управления, обновления, анализа и представления информации обо всех конфигурационных единицах и их взаимоотношениях. CMS может также включать в себя информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах. CMS поддерживается процессом управления сервисными активами и конфигурациями и используется всеми процессами управления ИТ-услугами.

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

Конфигурационными единицами могут быть технические средства, все виды программного обеспечения, активные и пассивные сетевые элементы, серверы, системные блоки, документация, процедуры, услуги и все другие ИТ-компоненты, контролируемые ИТ-организацией, и т.д. В CMS хранятся следующие типы объектов:

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

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

Атрибут - часть информации о конфигурационной единице. Например, наименование, местоположение, номер версии и стоимость. Атрибуты КЕ записываются в базу данных управления конфигурациями (CMDB) и поддерживаются как часть системы управления конфигурациями (CMS).

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

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

Совокупность КЕ и их взаимоотношений фактически представляют собой конфигурационную модель. На рисунке представлен пример конфигурационной модели.
CMS позволяет эффективным образом учитывать необходимую конфигурационную информацию, анализировать и представлять в различном виде, включая графический. CMS предоставляет информацию другим процессам управления услугами:

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

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

• Финансовая информация и политика компании в отношении продуктов
• Какие ИТ-компоненты используются в настоящее время по каждой модели (версии) и на протяжении какого времени?
• Какие тенденции существуют в разных группах продуктов?
• Какова текущая и остаточная стоимость ИТ-компонентов?
• Какие ИТ-компоненты нужно выводить из операционной среды и какие требуют модернизации?
• Сколько будет стоить замена определенных компонентов?
• Какие имеются лицензии и достаточно ли их?
• Какие контракты на сопровождение следует пересмотреть?
• Какова степень стандартизации инфраструктуры?
• Выявление неисправностей и оценка результатов
• Какие ИТ-компоненты необходимы для поддержки процесса восстановления в случае чрезвычайной ситуации?
• Будет ли работать план восстановления на случай чрезвычайных обстоятельств, если была изменена конфигурация инфраструктуры?
• Какие ИТ-компоненты будут затронуты при развертывании новых сервисов?
• Как оборудование подключено к сети?
• Какие программные модули входят в каждый из комплектов программного обеспечения?
• Какие ИТ-компоненты затрагиваются изменениями?
• Какие запросы на изменение (RFC) конкретных ИТ-компонентов находятся на рассмотрении и какие инциденты и проблемы произошли в прошлом и сейчас продолжают оставаться актуальными?
• Какие ИТ-компоненты вызывают известные ошибки?
• Какие ИТ-компоненты были закуплены у конкретного поставщика в течение определённого периода?
• Предоставление услуг и выставление счетов
• Какие конфигурации ИТ-компонентов являются существенными для определенных услуг?
• Какие ИТ-компоненты используются в том или ином месте и кем?
• Какие стандартные ИТ-компоненты может заказать пользователь и какие из них поддерживаются (каталог продуктов)?

Деятельность в рамках процесса управления сервисными активами и конфигурациями

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

В материалах ITIL «планирование» означает деятельность по организации самого процесса управления конфигурациями. Управление и планирование как вид деятельности, применяется как на этапе создания, так и на этапе совершенствования процесса. Основным результатом планирования является «План управления конфигурациями».

План управления конфигурациями содержит.

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

План является «живым» документом и подлежит регулярному пересмотру. За актуализацию плана отвечает менеджер процесса управления конфигурациями.

Деятельность по идентификации конфигураций включает:

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

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

Деятельность по управлению КЕ включает следующие аспекты:

• Поддержание данных CMDB в актуальном состоянии
• Обеспечение целостности данных CMDB (понятны происхождение и история изменений каждой КЕ)
  • Ограничение доступа на изменение данных CMDB
  • Обеспечение антивирусной защиты средств управления CMDB
  • Обеспечение резервного копирования и возможности восстановления данных
• Правила контроля должны быть разработаны на этапе планирования процесса
• Правила передачи контроля от проектов или поставщиков
• Процедуры контроля должны соответствовать типам КЕ

В деятельность по учету статуса конфигураций и отчетности входит:

• Поддержка конфигурационных записей в ходе жизненного цикла услуги и архивация их в соответствии с соглашениями, внешними требованиями, передовым опытом и стандартами (например ISO 9001)
• Управление документированием, получением и консолидацией текущего статуса конфигурации и статусов всех предшествующих конфигураций для обеспечения корректности, своевременности, целостности и безопасности информации
• Обеспечение доступности информации о статусе в течение жизненного цикла услуги
• Документирование изменений CI от приемки до вывода из эксплуатации
• Обеспечение правильного документирования базовых конфигураций

Верификация и аудит:

• Верификация - проверка КЕ на соответствие стандартам или функциональным требованиям:
• При первичной регистрации в CMDB
• При получении оборудования или ПО от поставщика
• При вводе в эксплуатацию
• Аудит - проверка соответствия между актуальным состоянием КЕ (как есть) и описанием КЕ в CMDB (как должно быть)
• Стандартный аудит
• Упрощенный аудит
• Текущий (операционный) аудит

• Спустя небольшой промежуток времени после внедрения новой системы / процесса управления конфигурациями
• Перед и после крупных изменений в ИТ инфраструктуре
• Перед развертыванием нового ПО для проверки готовности продуктивной среды
• После восстановления от крупного сбоя (чрезвычайной ситуации)
• По факту обнаружения большого количества расхождений (например, в рамках операционного аудита)
• Регулярно (с заранее определенной периодичностью)
• Время от времени («внезапные» проверки)

Показатели процесса управления сервисными активами и конфигурациями

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

• Процент улучшения поддержки жизненного цикла актива по принципу: не слишком много, не слишком поздно
• Степень соответствия поддержки потребностям бизнеса
• Активы, идентифицированные как причина сбоев в предоставлении услуг
• Увеличение скорости решения инцидентов и восстановления услуг через более быстрое определение сбойных КЕ
• Выявление связей между специфическими типами КЕ, инцидентами и проблемами
• Более эффективное использование сервисных активов
• Более эффективное использование закупленных лицензий, средняя стоимость лицензии на одного пользователя
• Более точные бюджет и оплата за использование активов
• Более эффективные аудиты активов
• Улучшение качества и точности информации об активах
• Меньше ошибок, вызванных работой с устаревшими данными
• Уменьшение количества и объемов аудита
• Уменьшение использования неавторизованного оборудования и ПО, что ведет к уменьшению стоимости и рисков в поддержке услуг
• Уменьшение времени и снижение стоимости при диагностике и решении инцидентов и проблем
• Уменьшение времени идентификации активов, проблемных по производительности
• Уменьшение количества неуспешных изменений, причиной чего явилась неверная оценки влияния, некорректные данные в CMS или плохой контроль версий
• Снижение рисков благодаря раннему обнаружению несанкционированных изменений

Сложности

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

• Убеждение персонала технической поддержки соблюдать политики учета, что часто воспринимается как препятствие в быстрой поддержке услуг.
• Привлечение и обоснование выделения фондов для процесса, так как, обычно, процесс не виден подразделениям заказчика, обладающим полномочиями по выделению фондов. Обычно финансируется как «невидимый» элемент управления изменениями и других более «заметных» процессов
• Подход: «собираем все данные, которые возможно», что ведет к перегрузке процесса, а также к невозможности его поддерживать
• Недостаток приверженности и поддержки руководства, не понимающего ключевую роль процесса

11 марта 2009 г. 09:20

Вероника Климентионок, консультант по управлению, консультационная компания «Украинский Имидж» (г.Киев)

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

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

Идея и необходимость описания бизнес-процессов

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

Из личного опыта автора по работе в отделе автоматизации крупного холдинга: именно ИТ-директор организовал для топ-менеджеров мини-семинар по рассмотрению деятельности компании через бизнес-процессы (и было это три года назад). Он же обучал сотрудников своего отдела методикам моделирования бизнес-процессов, инициировал проекты по описанию бизнес-процессов не только для целей автоматизации, но и для реорганизации отдельных компаний и подразделений холдинга. На это ИТ-директора вдохновило обучение на MBA. Фактически он выполнял функции руководителя ИТ-подразделения и CIO холдинга.

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

Подготовка компании к проекту по описанию бизнес-процессов

Итак, ИТ-директор или руководитель ИТ-подразделения со своими подчиненными участвует в проекте по описанию бизнес-процессов, который инициировал один из топ-менеджеров компании (или сам ИТ-директор). С чего начать и как подготовить компанию к такому проекту? Есть четыре составляющие, без которых проект начинать нельзя: цель, обучение, команда, план.

Цель

Возможные цели проекта по описанию бизнес-процессов - это структуризация и регламентация компании, тиражирование бизнеса, оптимизация бизнес-процессов, внедрение СМК ИСО, функционально-стоимостной анализ деятельности компании, проектирование и внедрение ИС и т. д. Однако это очень общие формулировки, чтобы в конце проекта оценить, насколько вы достигли своей цели.

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

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

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

Еще одним хорошим вариантом конкретизации цели проекта является присутствие в формулировке цели названия бизнес-процесса или бизнес-процессов для описания. Например, разработка модели и регламента бизнес-процесса закупки и поставки сырья на склад.

Обучение

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

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

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

Команда

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

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

Возглавляет рабочую группу Руководитель проекта - он организует и координирует проект, работает с Заказчиком и отвечает за результаты проекта. Руководителем проекта должен быть один из топ-менеджеров компании. Если руководитель ИТ-подразделения имеет статус ИТ-директора и входит в топ-менеджмент компании, то Руководителем проекта может быть он.

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

Когда в проекте работает несколько Аналитиков, они могут параллельно описывать различные процессы и работать на разных уровнях декомпозиции описания. Для того чтобы модели Аналитиков не пересекались и имели одинаковую подробность, в рабочей группе проекта должен присутствовать Интегратор . Он удерживает целостность бизнес-модели компании и координирует работу Аналитиков. Чаще всего функции Интегратора выполняет один из Аналитиков или сам Руководитель проекта, если он имеет соответствующие компетенции.

Секретарь рабочей группы - не очень большая, но ответственная роль. Он организует заседания рабочей группы, фиксирует принимаемые решения и контролирует их исполнение. Фактически он является помощником Руководителя проекта, его левой рукой и «контрольным» органом.

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

Несколько слов о тех ролях, которые ИТ-специалисты выполнять никак не могут (конечно, если мы не описываем бизнес-процессы ИТ-компании).

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

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

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

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

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

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

План

Последний шаг в подготовке проекта по описанию бизнес-процессов - это планирование.

Сначала определяется структура работ, исполнители и необходимые трудозатраты. Затем делается календарная привязка и определяется длительность работ: в плане учитываются праздники, дни рождения босса, корпоративные выезды и командировки.

К примеру, на согласование модели бизнес-процесса надо всего-то 3 часа. С этой целью вы запланировали две встречи с Владельцем и Экспертами этого бизнес-процесса с перерывом в два дня. Длительность работ по согласованию модели бизнес-процесса составит 4 дня, но если в этот период Владелец бизнес-процесса уедет в командировку или возьмет несколько отгулов на празднование своего дня рождения, то длительность работ может существенно увеличиться. Конечно, помимо запланированных бывают и «внезапные» командировки, а для этого между работами проекта оставляется временной лаг. Это означает, что если длительность работ по согласованию модели бизнес-процесса составляет 4 дня, то перед началом следующей работы по формированию структуры процессного регламента надо оставить 1 резервный день. Когда такие лаги выставлены по всему проекту, то даже незапланированное отсутствие кого-то из участников проекта не повлияет на суммарную длительность проекта.

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

Бизнес-результаты проекта по описанию процессов компании

«Если раньше ИТ оценивались исключительно по тому, насколько успешно они осуществляли технологические проекты, то в последующие пять лет они будут оцениваться по тому, насколько сами эти проекты помогают бизнесу в его деятельности». Это было написано в журнале CIO Magazine еще в начале 2000-х. Время оценивать работу ИТ-подразделений по бизнес-результатам пришло. Проект по описанию бизнес-процессов, несомненно, поможет бизнесу в его деятельности и будет способствовать:

● повышению прозрачности деятельности компании;

● закреплению зон ответственности сотрудников компании;

● улучшению взаимодействия подразделений;

● решению проблемы «незаменимых сотрудников».

И если проект по описанию бизнес-процессов компании инициирует ИТ-подразделение, то достичь перечисленных результатов оно может только в тесном сотрудничестве и взаимопонимании с бизнесом. По этому поводу хорошее выражение прозвучало в выступлении Эдуарда Савушкина (корпорация «Инком») на съезде ИТ-директоров 2007 г. в Киеве: «Не бывает ИТ-проектов - бывают бизнес-проекты с вовлечением ИТ» .