В прошлом году в дочерней структуре Volkswagen AG — оптовом импортере автомобилей Volkswagen Group Rus — был завершен проект внедрения HP OpenView Service Desk. Начали его после того, как обнаружили, что текущее состояние ИТ-службы перестало соответствовать изменившимся условиям бизнеса. В октябре 2006-го головной концерн Volkswagen AG провел аудит информационных систем и процессов. По результатам проверки было рекомендовано внедрять сервисный подход в ИТ-службе. В ходе проекта кроме подразделения информационных технологий, процессов и оптимизации (ИТПиО) к нему подключились еще пять бизнес-подразделений (Group Service, выполняющее среди прочего поставки запасных частей и аксессуаров, и четыре отдела рекламаций и запросов клиентов), которые также сочли удобным использовать Service Desk в своей работе. Эта статья посвящена специфике проекта и сделанным по его результатам выводам.

Предпосылки проекта

Реализация данного проекта началась с анкетирования ключевых пользователей ИТ-услуг в компании Volkswagen Group Rus. Опрос касался основных претензий к ИТ-службе и качеству оказываемых услуг. В результате были сформированы две основные группы требований к будущей службе ИТ — во-первых, рекомендации ИТ-аудита, а во-вторых, отраженное в анкетах недовольство качеством работы ИТПиО в некоторых её аспектах. Прежде всего жалобы пользователей касались нарушения сроков выполнения стандартных и сложных изменений, а также сроков разрешения инцидентов. Кроме того, анкетируемые оказались недовольны доступностью информационных систем в критические для бизнеса периоды. Регламентные работы, приводящие к перерыву в обслуживании, могли назначаться на рабочее время, что недопустимо. Установленных сроков не выдерживал и подрядчик, не выполнявший вовремя изменения при развитии основной информационной системы. Поясню, как в компании классифицируются изменения. Если на момент регистрации реализация изменения определена вплоть до продолжительности работ и списка требуемых ресурсов, то это стандартное изменение. От операционной работы его отличает появление в ИТ-инфраструктуре новой конфигурационной единицы (КЕ) или существенное изменение атрибутов уже существующей КЕ. Сложные изменения представляют собой мини-проекты, в которых нужно опросить заказчика, составить бизнес-требования и преобразовать их в работы, составить техническое задание и описать методы проверки результата. Список выполняемых работ не является постоянным, он меняется от изменения к изменению. Например, в класс сложных изменений попадают модификации информационных систем в связи с изменением бизнес-процесса или организация переезда. По результатам аудита и анкетирования было решено начинать проект реструктуризации ИТ-службы с внедрением сервисного подхода. Штат подразделения ИТПиО на момент старта проекта составлял шесть человек плюс семь внешних консультантов. Подразделение обслуживало 160 пользователей в нескольких московских офисах.

Выбор рамок проекта, системы и подрядчика

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

Затем мы начали выбирать программную платформу. Рассматривались три продукта: Remedy, Peregrine Service Center и HP OpenView Service Desk. Надо сказать, что на выбор Volkswagen Group Rus не оказали влияния корпоративные стандарты головной структуры. Стандартным средством автоматизации сервисных процессов в Volkswagen AG является Peregrine Service Center, хотя его и не навязывали дочерней структуре. Однако эксплуатация данной системы в головной компании ещё не достигла того уровня зрелости, когда её можно было бы тиражировать в дочерних структурах по всему миру. А в тот момент, когда нужно было принимать решение, судьба Peregrine, только что купленной HP, была непонятной и перспективы её туманны. Кроме того, головная компания не смогла нас поддержать финансово: у Volkswagen AG не было глобального соглашения с Peregrine, по которому можно было бы покупать и внедрять этот продукт с существенными скидками. Мы обратились с этим к новому владельцу Peregrine — компании HP и получили рекомендацию покупать HP Service Desk. Среди других факторов было принято во внимание количество партнеров, работающих с HP OpenView ServiceDesk. Мы понимали, что в последующем тендере у нас будет бо’льшая гибкость, и это тоже сыграло в пользу HP Service Desk.

К началу марта 2007 года у нас были готовы первые документы — приглашения к тендеру. Проанализировав ситуацию с компаниями-интеграторами на рынке ИТ-услуг, мы сузили круг приглашенных к тендеру компаний до трех: IBS, IDS Scheer и «ИНЛАЙН ГРУП». В целом критерии выбора подрядчика до начала тендера не формулировались в явном виде, они появились уже после того, как мы услышали первые презентации. Когда одна компания предлагает выполнить проект за четыре месяца, а другая при сопоставимых ценах — за девять, то разумно одним из критериев сделать срок выполнения проекта.

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

Главная сложность данного тендера заключались в том, что критерии, значимые для ИТ-службы, как то: репутация подрядчика на рынке, реалистичность планирования и т. п. — не являлись решающими для финансового директора, коллегиально с которым принималось решение. Правда, большого расхождения в стоимости заявок не было, поэтому удалось убедить его в разумности нефинансовых критериев выбора подрядчика. Тендер был завершен к концу марта. Его победителем стала компания «ИНЛАЙН ГРУП».

Планирование и создание каталога услуг

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

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

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

Этап формирования каталога услуг был закончен к середине июня, и началось проектирование самих процессов поддержки ИТ-сервисов. Эксперты из «ИНЛАЙН ГРУП» убедили нас, что эти два этапа должны следовать именно в таком порядке, так как практически в любых процессах основным классификатором является услуга. Именно она отвечает на самый главный вопрос: зачем мы это делаем?

Подключение других бизнес-подразделений

Как раз в это время к проекту в результате его широкого представления сообществу менеджеров Volkswagen Group Rus проявили интерес другие подразделения. Таким образом, бизнес-подразделения примкнули к проекту на более поздней стадии. При проектировании процессов мы уже знали, что к системе подключается не только ИТ-служба. Управление запросами дилеров по запасным частям и аксессуарам планировало обрабатывать в системе большое количество запросов от своих клиентов по поводу логистических процессов поставки. Логистику запасных частей обслуживает система SAP R/3. Но она не предлагает возможностей по регистрации и обработке исключительных случаев.

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

Проектирование процессов

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

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

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

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

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

Таким образом, основным результатом семинаров стали карта процессов, список ролей и ключевые показатели эффективности (key performance indicators — KPI). Карта в обязательном порядке включала в себя привязку к каталогу услуг, это один из основных классификаторов, который присваивался при обработке обращений. Несколько дополнительных классификаторов заявок разнились в зависимости от области применения, хотя обработка всех трех групп процессов проходила на одном и том же приложении — HP Service Desk. Словари данных и классификаторы соответствовали принятой в каждой области бизнес-терминологии. KPI для ИТ-службы формулировали мы сами, а для случаев логистики и обращений клиентов — соответственно специалисты по логистике и менеджеры по послепродажному обслуживанию.

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

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

Началась фаза опытной эксплуатации. Надо отметить, что проблемы, возникавшие в этот период, оперативно решались специалистами «ИНЛАЙН ГРУП». Связаны они в основном были с тем, что при проектировании процессов что-то не учли; иногда всплывали такие ошибки, как несоответствие документа процесса и его реализации в системе. А бывали случаи, когда процесс, реализованный в системе в полном соответствии с документом, приходилось переделывать, потому что жизнь уже внесла соответствующие коррективы. Появлялись дополнительные классификаторы и т. п. Подобные изменения вносились как раз на этапе опытной эксплуатации.

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

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

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

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

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

Небольшое количество заявок (менее 5%) приходило по телефону. Специалистами «ИНЛАЙН ГРУП» была реализована интеграция с телефонной станцией. Если телефонный номер входящего звонка, выданный автоматическим определителем, находился в базе данных, то инициатор определялся системой автоматически. Многие пользователи звонили с мобильных телефонов, что, конечно, упрощало идентификацию. Был построен процесс регистрации ошибок в идентификационных данных заявителей и процесс их коррекции. Оба процесса имели свои показатели эффективности.

Выводы

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

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

Управление изменениями и управление проектами

Выяснилась и еще одна важная вещь. Поскольку в компании не налажено управление проектами, то и управление изменениями наталкивается на серьезное непонимание со стороны бизнеса. Руководство и заказчик не видят плановости выполнения, работа идёт по факту поступления заявки, управление изменениями является реактивным и не отвечает на вопросы: сколько денег нужно заложить? что делать, когда деньги кончатся? какие еще ресурсы потребуются на выполнение помимо денежных? почему сдвигаются сроки и как это повлияет на бизнес? Управление изменениями — это всего лишь техническая процедура, а для ответа на поставленные вопросы необходимо проектное управление, долгосрочное стратегическое планирование. Именно проектное управление может ответить, когда изменение будет выполнено и сколько оно будет стоить. К сожалению, в Volkswagen Group Rus процессов управления проектами не существует, в результате проектами управляют подрядчики — каждый по своему усмотрению. Однако эффективно управлять изменениями невозможно до тех пор, пока управление проектами не будет введено как процесс, стандартный и обязательный для всех подрядчиков и сотрудников. Полную отдачу оно даёт совместно с управлением проектами.

О важности коммуникации

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

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

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

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

С Антоном Губарьковым можно связаться по e-mail: anton.gubarkov@gmail.com