13.02.2008 Intelligent Enterprise

Об опыте внедрения проекта журналу Intelligent Enterprise рассказывает Антон Губарьков, директор по ИТ компании ООО «Фольксваген Груп Рус» 2007 года.

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

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

Перед тем, как перейти непосредственно к проекту, давайте остановимся на том, почему на Volkswagen Group Rus не оказали влияния корпоративные стандарты головной структуры, не включающие в себя HP OpenView Service Desk. Стандартным средством для автоматизации сервисных процессов в ИТ в Volkswagen AG является Peregrine Service Center. Однако, уровень зрелости эксплуатации данного решения в VW AG ещё недостаточен для тиражирования в дочерние компании по всему миру. Кроме того, в момент старта проекта линейка продуктов Peregrine была куплена компанией HP с неясными перспективами развития.

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

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

Выбор решения

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

Определившись с методологией, мы начали выбор программной платформы. Рассматривались три продукта: Remedy, Peregrine Service Center и HP OpenView Service Desk. Стандартом в головном Volkswagen AG является Peregrine Service Center, хотя его и не навязывали ООО ФГР, как уже было сказано. В тот момент, когда нужно было принимать решение, судьба Peregrine, только что купленной HP, была непонятной, а ее перспективы туманны. Головная компания не смогла нас поддержать финансово и методологически. У Volkswagen AG не было глобального соглашения с Peregrine, по которому можно было бы покупать и внедрять этот продукт с существенными скидками. Мы обратились с этой дилеммой к новому владельцу Peregrine компании HP и получили рекомендацию покупать Service Desk. Среди дополнительных факторов было принято во внимание количество партнеров, работающих с HP OpenView ServiceDesk. Мы понимали, что в последующем тендере у нас будет большая гибкость и тоже это сыграло в пользу Service Desk.

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

Этапы проекта

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

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

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

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

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

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

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

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

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

Был построен процесс регистрации ошибок в идентификационных данных заявителей и процесс коррекции таких ошибок. Оба процесса имели свои показатели эффективности.

Результаты и выводы

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

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

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

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

О централизации стандартов

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

Новости
  • 26.09.2017
    «ИНЛАЙН ГРУП» и Fortinet защитили web-сервисы ТМК Подробнее
  • 14.09.2017
    «ИНЛАЙН ГРУП» на III Федеральном ИТ-форуме нефтегазовой отрасли России Подробнее
Проекты
  • Альфа-Банк
    Консолидация ИТ-ресурсов на основе индустриальных стандартов