Инновационная образовательная программа гу-вшэ «Формирование системы аналитических компетенций для инноваций в бизнесе и государственном управлении» Кафедра Управления информационными ресурсами предприятия
| Вид материала | Образовательная программа |
- Инновационная образовательная программа гу-вшэ «Формирование системы аналитических, 2826.81kb.
- Программы гу-вшэ «Формирование системы аналитических компетенций для инноваций в бизнесе, 4514.19kb.
- Инновационная образовательная программа гу-вшэ «Формирование системы аналитических, 457.34kb.
- Программа подготовлена в рамках Инновационной образовательной программы гу-вшэ «Формирование, 340.58kb.
- Программа подготовлена в рамках Инновационной образовательной программы гу-вшэ «Формирование, 330.43kb.
- Программа подготовлена в рамках Инновационной образовательной программы гу-вшэ «Формирование, 994.83kb.
- Программа подготовлена в рамках Инновационной образовательной программы гу-вшэ «Формирование, 976.37kb.
- Программа подготовлена в рамках Инновационной образовательной программы гу-вшэ «Формирование, 318.71kb.
- Правительство Российской Федерации Государственный университет Высшая школа экономики, 343.74kb.
- Учебно-методическое пособие подготовлено в рамках Инновационной образовательной программы, 2552.15kb.
Внедрение
Дальнейшее внедрение разработанных планов идет по трем направлениям.
Принятие мер по уменьшению рисков
Собственно, это знакомое нам всем внедрение систем повышения безопасности и отказоустойчивости – от различных смарт-карт, до создания распределенных систем.
Поиск запасных площадок
На этой стадии происходит поиск коммерческих организаций, предоставляющих услуги восстановления ИТ, в кризисных ситуациях, выбор нужных площадок, подготовка и настройка ИТ-систем, возможная закупка нового оборудовании.
Разработка плана и процедур восстановления
На этой стадии руководство ИТ разрабатывает детальные план по управлению непрерывности ИТ-сервисов. Еще раз напомним, что управление непрерывностью ИТ-сервисов – это лишь малая часть большого процесса управления непрерывностью бизнеса. На этой стадии определяются процедуры по восстановлению ключевых ИТ-сервисов в определенном порядке за минимально допустимое время до минимально допустимого уровня. Эти процедуры могут включать, например, разработку инструкций, согласно которым любой ИТ-специалист, незнакомый со спецификой ИТ-сервиса, мог бы шаг за шагом восстановить его в указанный временной период.
Начальное тестирование
Эта стадия предполагает первое эмулирование кризисной ситуации, в ходе которой определяются реальные времена восстановления определенных ИТ-систем. В тестирование привлекается весь ИТ-персонал – от системных администраторов до службы Service Desk. Первое тестирование может происходить и без привлечения бизнес-подразделений, однако для полноценного тестирования рекомендуется их привлечение.
Операционное управление
Тактика «внедрить и забыть» неизбежно приведет к вымиранию готовности организации встретить кризисную ситуацию, поэтому руководство, в не меньшей мере должно заботится о поддержании планов в актуальном состоянии, а персонала в готовности к встрече с кризисом. Это осуществляется через операционное управление и включает в себя.
Обучение и оповещение
Обучение и оповещение должно пронизывать всю организацию. Персонал организации должен знать о существовании процессов управления непрерывностью бизнеса (в частности ИТ-персонал - об управлении непрерывностью ИТ-сервисов), и воспринимать это как часть повседневной жизни.
Пересмотр и аудит
Возможное появление новых внешних угроз, или автоматизация новых бизнес-процессов означает неизбежное изменение требований к существующим ключевым ИТ-сервисам. Регулярное обновление планов и процедур по обеспечению непрерывности ключевых ИТ-услуг позволят ИТ-подразделению гибко приспосабливаться к изменяющемуся бизнесу организации.
Тестирование
Как и в случае первого эмулирования кризисной ситуации, организация должна быть постоянно готова к принятию быстрых мер. «Учебные тревоги» должны стать частью штатной жизнедеятельности крупных организаций.
Управление изменениями
Процесс управления изменениями, если таковой внедрен в организации должен быть привлечен к управлению непрерывностью ИТ-услуг, для четкого понимания того, как изменение внутри ИТ может повлиять на доступность ключевых ИТ-услуг в кризисной ситуации.
Обучение ИТ
ИТ-персонал может быть привлечен к обучению функционирования ключевых бизнес-процессов, для понимания своего вклада в управление непрерывностью бизнеса.
Управление непрерывностью бизнеса дает организации гарантии устойчивости к внешним рискам. В западных компаниях, где управление рисками уже давно стало нормой функционирования любого крупного бизнеса, внедрение подобного процесса уже вошло в повседневную практику.
Однако необходимость внедрения столь недешевого и полномасштабного процесса в российских компаниях наверняка еще долгое время будет темой для обсуждения на конференциях. И дело здесь, скорее не в отсутствии денежных средств, а в готовности сознания бизнес-руководителей принять данный процесс как жизненную необходимость. Однако все более растущий интерес к этой теме со стороны ИТ-руководителей оставляет надежды на рост интереса к данному процессу со стороны и бизнес-руководителей. А это, в свою очередь, означает перспективу развития новой ниши российского ИТ-рынка – рынка поставщиков услуг по восстановлению ИТ в кризисных ситуациях.
Практика внедрения процессов ITSM на российском рынке. С чего начинать?
Алексей Авакян
Почему ITSM?
Уже ни для кого не секрет, что влияние информационных технологий (ИТ) на деятельность любой фирмы становится более чем существенным. В последнее время все чаще ссылаются на предприятия с автоматизированным бизнесом (банки, трейдинговые компании, операторы сотовой связи и т. д.), для которых ИТ являются не просто поддержкой, но и движущей силой. В связи с новой ролью ИТ в жизни компаний острее ставится вопрос об эффективном — со стороны информационных технологий — обслуживании бизнеса. Иными словами, там начинают задумываться о том, как сделать ИТ-департамент центром предоставления определенных ИТ-услуг. В странах Западной Европы, где культура сервиса (то есть политика организации, направленная на предоставление услуг) стала частью повседневной жизни, признанным де-факто стандартом управления ИТ является набор руководств, изложенных в книгах библиотеки ITIL (IT Infrastructure Library) — “IT Service Support” и “IT Service Delivery”. Эти руководства, основанные на передовом опыте, который был накоплен ведущими компаниями мировой ИТ-индустрии, называются “IT Service Management” (ITSM) — управление ИТ-услугами.
Полный переход на сервисную основу позволит ИТ-департаменту любой компании не только превратиться из затратного подразделения в центр получения прибыли, но и предлагать свои ИТ-услуги за пределами собственной организации, перейдя тем самым к статусу департамента с независимым бюджетом.
Рекомендации, изложенные в указанных выше книгах, не являются прямыми инструкциями к действию, оставаясь лишь “высокоуровневым” описанием эффективной модели управления. Каждое предприятие получает возможность адаптировать “лучшие мировые практики” к особенностям своей ИТ-инфраструктуры и текущему состоянию рынка.
В связи с этим нет единого мнения о том, с чего следует начинать при переводе ИТ-подразделения на сервисную основу работы. Оставляя за любой компанией право на выбор собственного, уникального способа построения процессов ITSM, мы тем не менее хотели бы рассказать о той схеме построения, которая эффективно проявила себя на российском ИТ-рынке.
Тактика быстрых побед
На сегодняшний день руководство российских компаний еще не до конца осознало всю значимость ИТ для бизнеса. Бюджетирование ИТ у них выражено крайне слабо, причем не столько из-за общего дефицита денежных средств, сколько из-за отсутствия представления об ИТ как о стратегическом для развития бизнеса инструменте. Зачастую ИТ-директора сталкиваются с ситуацией, когда внутри ИТ-департамента назрела необходимость реорганизации процессов, но этот факт трудно донести до руководителей среднего звена. В подобном случае особенно эффективным будет применение тактики “быстрых побед”. Она заключается в быстром внедрении яркого и эффективного решения, результаты которого могли бы впечатлить руководство компании. Обычно такие решения содействуют тому, что ИТ-департамент получает соответствующий бюджет на будущие проекты.
Именно с этой целью процесс перехода своего департамента на сервисную основу CIO начинают с этапа построения ITSM-процессов, способных принести наиболее заметные результаты.
Что сейчас распространено?
Одним из самых распространенных в России путей перевода ИТ на сервисную основу является построение своеобразной “связки” — службы Service Desk и процесса управления инцидентами.
Служба Service Desk, или служба технической поддержки, является единой точкой контакта при всех обращениях пользователей, связанных с ИТ. Практика показывает, что организация такой точки (единый телефон, e-mail, факс и т. д.), является фактором, повышающим психологическую удовлетворенность сотрудников компании от ИТ. Однако одной лишь службы Service Desk мало для достижения быстрых побед. Можно догадаться, что повышение удовлетворенности окажется недолгим, если заявки пользователей будут, например, теряться или пользователь станет рассматривать ИТ-департамент как некий “черный ящик”, который, успешно приняв заявку, не сообщает о происходящей внутри него работе.
Процесс управления инцидентами (Incident Management) — это взаимодействие ИТ-отделов, направленное на максимально быстрое устранение сбоев в ИТ-инфраструктуре. В рамках этого процесса служба Service Desk является основным координирующим работу ИТ-отдела звеном. Она позволяет создать средства автоматического оповещения пользователей о ходе работ по рассмотрению их заявок, значительно повысив ценность ИТ-департамента в глазах рядовых пользователей и руководящего состава.
Статистика пользовательских обращений, появляющаяся после построения процесса управления инцидентами, дает возможность ИТ-директорам оптимизировать нагрузку ИТ-персонала, а также аргументировано обосновывать необходимость выделения бюджета на ИТ.
Подводные камни
Как показывает практика некоторых компаний, внедрения вышеуказанной связки тем не менее недостаточно для достижения быстрой победы. Пользователи зачастую считают, что их заявки рассматриваются слишком долго. При этом четкая, но не доведенная до них схема определения приоритетов для различных инцидентов эффективно работает лишь внутри ИТ-департамента, поскольку каждый пользователь будет уверен, что любая его заявка получит высший приоритет. А это может привести к негативной реакции, и, как следствие, к ухудшению репутации ИТ-департамента.
Для того, чтобы вызвать у пользователей доверие к службе технической поддержки прежде всего необходимо ознакомить их с тем, на какие сроки по устранению возникших инцидентов они могут рассчитывать. А определение таких сроков — это уже часть процесса управления уровнем услуг (Service Level Management, SLM).
SLM на ранней стадии. Как это возможно?
Обычно управление уровнем услуг рассматривается как процесс, внедряемый уже в зрелой — с точки зрения выстраивания бизнес-процессов — организации. SLM — это процесс, обеспечивающий регламентную базу для предоставления ИТ-сервисов на заранее согласованном уровне качества и включающий в себя разработку, поддержку и постоянную корректировку “соглашений об уровне услуг” (Service Level Agreement, SLA).
SLA представляет собой формальный договор между потребителем ИТ-услуги (бизнесом) и ее поставщиком (департаментом ИТ), содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.
Для того чтобы “измерять” уровень качества ИТ-услуг, они характеризуются набором показателей — так называемых метрик сервиса, таких как часы доступности, уровень доступности (в процентах) (то есть доля времени, в течении которого услуга должна быть физически доступна в сравнении с максимально возможным временем доступности), время реакции на обращение, время устранения инцидентов, связанных с этим сервисом, и т. д. Под уровнем качества услуги подразумевается набор согласованных значений метрик. Заключая SLA с бизнес-структурой, ИТ-департамент гарантирует предоставление услуги с уровнем качества не ниже согласованного.
Введение четко регламентированного времени реакции/устранения инцидента является частью масштабного процесса SLM, однако это возможно только в том случае, если в ИТ-департаменте уже налажены более элементарные процессы. Как же в этом случае построить эффективный процесс управления уровнем сервиса?
(Предлагаемый ниже подход был удачно реализован компанией КРОК в “Ингосстрахе” в рамках построения службы технической поддержки с измеряемым качеством обслуживания пользователей.)
В процессе управления уровнем сервиса достаточно определить один-единственный ИТ-сервис — техническую поддержку — и классифицировать его как профессиональный[1] (то есть представляющий собой дополнительные действия, производимые ИТ-персоналом).
Далее необходимо обозначить ИТ-системы, которые существуют в департаменте (если такая работа не была проделана ранее). Например, ими могут быть MS Exchange, Lotus Domino, LAN, системы хранения данных и т. д. Обычно каждую такую систему поддерживает отдельная ИТ-служба или рабочая группа инженеров. Собственно говоря, определение ИТ-систем и поддерживающих их рабочих групп — это фундамент для формирования будущей схемы эскалации (то есть схемы маршрутизации инцидента внутри ИТ-департамента), которая определяется в процессе управления инцидентами.
После того как в рамках сервиса технической поддержки будут определены поддерживаемые ИТ-системы, необходимо рассчитать время реакции/устранения инцидентов, связанных с каждой из этих систем, в зависимости от приоритета инцидента. В отсутствие статистики по инцидентам это обычно делается на основе широкомасштабного опроса рабочих групп технической поддержки.
Полученные метрики необходимо включить в SLA для единственно определенного сервиса — сервиса технической поддержки. В SLA можно также включить время доступности сервиса (то есть службы Service Desk), долю устраненных операторами Service Desk инцидентов и т. д.
Конечно, выявленные при опросе метрики (время реакции/устранения инцидентов) могут не соответствовать картине, полученной после первой обработки статистических данных, собранных в процессе управления инцидентами. В этом случае включаются механизмы корректировки согласованных в SLA метрик сервиса, которые являются частью процесса управления уровнем услуг. Корректировка согласованных метрик — задача менеджера по управлению уровнем услуг.
Вначале роли менеджера процесса управления инцидентами и менеджера процесса управления уровнем услуг можно эффективно совмещать в одном лице. Однако в перспективе после оптимизации процесса технической поддержки мы рекомендуем эти роли разделить для последующей формализации каталога услуг, согласования метрик и заключения новых SLA.
После определения метрик сервиса технической поддержки и формализации корректирующих процедур операторы службы Service Desk — в случае задержек исполнения — получат контроль над работой прочих ИТ-служб, имеющих отношение к этой деятельности. В то же время у пользователей появится информация об ожидаемых сроках устранения инцидентов. Мы настоятельно рекомендуем сделать SLA по технической поддержке доступной пользователям, а также довести до сведения сотрудников информацию о том, что означает каждый из установленных в ИТ-департаменте приоритетов инцидента. Это можно сделать через информационные бюллетени или поместив соответствующие сведения на внутренний портал.
Еще одно преимущество построения SLM вместе с Service Desk и Incident Management — это более удобная формализация каталога ИТ-услуг при уже установленном времени реакции и устранения инцидентов для каждой ИТ-системы. Например, предположим, что департамент ИТ пришел к выводу ввести в каталог услуг новый сервис — “Предоставление электронной почты”, связав его с соответствующими ИТ-технологиями. Этот сервис имеет смысл классифицировать как бизнес-услугу.
(Обычно под бизнес-услугой подразумевают такую ИТ-услугу, которая либо воспринимается пользователями как отдельный сервис, либо явным образом поддерживает бизнес-процессы. Такого рода услуги декларируются департаментом ИТ, и для каждой из них заключается SLA. В противоположность им технологические услуги “скрыты” от бизнеса.).
Имея на руках метрики из SLA для технической поддержки, не трудно составить метрики для новой услуги. Сервис “Предоставление электронной почты” основан на нескольких технологических составляющих, таких как MS Exchange, локальная сеть и т. д. Если, скажем, время, необходимое для устранения инцидента, связанного с MS Exchange, в зависимости от приоритета составляет от 20 до 60 минут, срок устранения инцидентов, вызванных отказами в электропитании или локальной сети, варьируется в пределах от 10 до 90 минут, а инциденты, возникающие из-за сбоев клиентского ПО, устраняются за временной интервал от 35 до 60 минут, то на устранение инцидентов по сервису “Предоставление электронной почты” уйдет 35—90 минут.
Выделив новую услугу “Предоставление электронной почты” и связав ее явным образом с бизнес-процессами компании, директор ИТ-департамента совместно с финансовым департаментом подсчитал минуту простоя данного сервиса и пришел к выводу, что ранее регламентированный нижний предел в 35 минут, необходимый для устранения инцидентов минимального приоритета, сопряжен с непомерными для компании расходами. Допустим, что в связи с таким выводом было принято решение сократить срок устранения инцидента до 20 минут. Это, в свою очередь, потребовало привлечь новых сотрудников в группу поддержки клиентского ПО электронной почты. А в таком случае неоценимую помощь окажет статистика обращений в службу Service Desk, которая позволит эффективно перераспределить персонал внутри ИТ-департамента.
Финансовые выгоды
Безусловно, достижение быстрой победы не должно ограничиваться простым повышением удовлетворенности сотрудников и руководства компании от использования ИТ. Не менее важна и финансовая сторона вопроса. Руководство компании должно увидеть, какие доходы принесет построение тех или иных процессов ITSM. Здесь мы излагаем метод грубого вычисления прибыли, получаемой в результате построения одного процесса. В приведенных ниже примерах подсчета сделаны следующие предположения:
- каждый сотрудник (включая ИТ-персонал) обходится компании в 20 долл. в час (зарплата и инфраструктурные расходы);
- общее количество инцидентов — 15 000 в год (60 в день);
- общее число сотрудников — 500 человек;
- в году — 250 рабочих дней.
Если затраты на содержание каждого сотрудника представить непрерывным во времени процессом, то минута его простоя будет означать потерю в 20х1/60 = 0,33 долл. К этому надо прибавить убытки компании, связанные с тем, что данный сотрудник не внес своего вклада в основной бизнес компании.
Построение процесса управления инцидентами уменьшает среднесуточное время простоя каждого сотрудника. Если эта величина снизится на 1 минуту в сутки, то общее уменьшение затрат составит: 1х0,33х500х250=41 250 долл.в год.
Экономию средств можно оценить следующим образом. Предположим, что время устранения инцидентов с максимальным приоритетом после построения процесса уменьшилось на 30 минут, инцидентов со средним приоритетом — на 15 минут, а время устранения инцидентов с минимальным приоритетом в среднем на 5 минут увеличилось. Причем количество инцидентов с максимальным приоритетом составляет 20% от общего числа инцидентов, а со средним и минимальным приоритетом — 30 и 50% соответственно. Таким образом, снижение затрат составит: 0,33х15000х(30х0,20+15х0,30–5х0,50)=39 600 долл. в год.
Кроме того, полученная от процесса статистика обращений поможет более эффективно распределить ресурсы внутри ИТ-подразделения. Сокращение штата хотя бы на одного инженера будет означать прибавку в 20х8х250=40 000 долл. в год.
Построение процесса управления уровнем сервиса на начальном этапе позволит уменьшить количество звонков с запросами на информацию о сроках устранения инцидентов. Уменьшение количества звонков длительностью в 1 минуту на 30% будет означать, что компания за год сэкономила на отсутствии лишних простоев в работе сотрудников 1х0,30х15 000=5000 минут, что эквивалентно 0,33*5000=1666 долл. Вместе с тем служба Service Desk сможет обработать на 30% больше обращений, а это даст компании дополнительный доход за счет уменьшения числа операторов службы Service Desk и времени простоя пользователей.
Приведенные здесь методы не стоит воспринимать как инструментарий для точного расчета. Мы приводим самую грубую оценку возможной прибыли. Конечно, нельзя подсчитать потенциальную выгоду, которая может быть получена от изменения статуса ИТ-департамента в компании, от возможного перехода к политике выставления счетов за предоставленные сервисы и т. д. Однако, опираясь на статистику внедрения процессов ITSM в крупных корпорациях, можно сказать, что только экономия ИТ-бюджета может составлять от 10 до 80%, не говоря уже об увеличении прибыли самой компании.
Связка Incident Management—Service Desk—SLM может стать неплохим фундаментом для развития будущих процессов ITSM, открыв ИТ-департаменту возможность перерасти в движущую бизнес силу, превратиться из затратного подразделения в центр получения прибыли, а в более отдаленной перспективе — стать самостоятельным поставщиком услуг на российском ИТ-рынке.