Повышение эффективности управления проектами обеспечения продаж и послепродажного обслуживания автомобилей на основе методологии RUP

руководитель группы разработки и внедрения
ООО «Панавто»

Аннотация

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

ИТ в автомобильном бизнесе на примере отдельной компании: особенности, задачи

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

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

В настоящее время многие компании автомобильного бизнеса заняты выстраиванием своих бизнес-процессов. Mercedes-Benz не является исключением из этих правил, и 2010 год является годом появления Workshop Process 2010 (WP2010) – процессной платформы, целью которой является повышение качества сервисного обслуживания, удовлетворенности клиентов и увеличения показателей сервисного обслуживания. Следующим шагом намечено внедрение процессной платформы в области продаж. Что касается другого премиум-бренда, BMW, то они решили разрабатывать отдельное решение Dealer Management System (DMS), которое будет тиражироваться на все дилерские центры на территории России, тем самым, предоставляя им свои стандарты через «готовый инструмент для работы». DMS – это отдельный класс информационных систем, которые удовлетворяют потребности дилеров конкретной марки или мультибрендовых компаний. С точки зрения методологии подход Mersedes-Benz выглядит более зрелым, но на практике подход BMW получит видимый результат несколько раньше.

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

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

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

Подходы к организации ИТ

Рассмотрим состояние ИТ-департамента на момент старта Проекта по адаптации RUP.

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

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

Управление инцидентами. Процесс управления инцидентами является одним из составляющих библиотеки ITIL. Цель процесса управления инцидентами – скорейшее восстановление нормального функционирования сервиса в соответствии с Соглашением об уровне услуг и минимизация воздействия отказа на жизнедеятельность бизнеса. Этот процесс реализован при помощи системы регистрации заявок Open Source Trouble Ticket System (OTRS). Выделяются следующие типы заявок: инцидент, запрос на обслуживание, заявка на изменения.

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

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

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

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

ERP-система. В качестве единой системы для работы Компании используется Microsoft Dynamics Navision (NAV) – это ERP-система, для которой существует отраслевое решение для автомобильного бизнеса и которая легко модифицируется под потребности бизнеса, являясь тем самым инструментом для автоматизации процессов.

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

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

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

1. Инициирование, контроль изменений (заказчик)
   a. Инициирование Проекта
   b. Контроль изменений
2. Регистрация заявки на изменение (исполнитель)
   a. Мониторинг заявок
   b. Классификация и назначение приоритета
   • Инцидент, запрос на обслуживание, заявка на изменение
   • Назначение приоритета
   • Проектная инициатива
3. Выполнение Проекта (исполнитель)
   a. Разработка правил (концепция, экономическое обоснование)
   b. Проектная деятельность
   • Регистрация Проекта
   • Планирование работ, ресурсов
   • Контроль над ходом Проекта, внесение изменений
   • Завершение Проекта
4. Принятие решений (бизнес)
   a. Принятие решения о необходимости Проекта
   b. Мотивация

Эта простая с виду последовательность действий затрагивает все основные аспекты проектной деятельности. Дополнив её элементами методологии RUP:
• ролевой моделью,
• итеративной моделью жизненного цикла проекта,
• технологическими процессами RUP,
• артефактами RUP,

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

Рекомендации по адаптации RUP

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

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

Процесс адаптации RUP – это Проект, и как любой проект имеет своё начало и завершение во времени, и состоит из последовательности шагов.

Шаг №1: Получить представление о задаче, которую требуется решить, и объеме ресурсов, доступных для выполнения Проекта.

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

Шаг №2: Определить объем адаптации, определить, какие области процесса должны быть задействованы в конкретном проекте.

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

Шаг №3: Разработать специализированные компоненты процесса для проекта, создать дополнительное «ноу-хау» в областях, где RUP в недостаточной степени охватывает потребности проекта.

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

Шаг №4: Настроить процесс, привести масштабы процесса в соответствие с потребностями проекта.

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

• Экономическое обоснование проекта (Business Case) – этот артефакт предоставляет необходимую информацию (с точки зрения бизнеса) для определения того, стоит ли инвестировать в данный Проект или нет. Информация для этого артефакта содержится в заявке на изменение, которую заказчик оставляет в системе регистрации заявок, в виде описания требуемой функциональности и эффекта, которое это изменение принесет для бизнеса. «Экономическое обоснование проекта» будет являться частью артефакта «Концепция»
• План итерации (Iteration Plan) – этот артефакт представляет собой последовательный во времени, содержащий зависимости задач, набор деятельностей и задач с присвоенными ресурсами для итерации, подробный план. Нашей Компанией в проектной деятельности достаточно использовать «План работ», не используя детализацию «Плана итераций».
• Оценка итерации (Iteration Assessment) – этот артефакт фиксирует результат итерации, степень соответствия критериям оценки, извлеченные уроки и выполненные изменения. Каждая итерация завершается оценкой итерации, когда исполнитель берет паузу для оценки того, что произошло, что было достигнуто либо не достигнуто и почему, а также полученных уроков. В нашем случае оценка итерации происходит только по окончанию Проекта: заполнение заказчиком мини-анкеты в «Протоколе о завершении Проекта», а также анализ Проекта в рабочей группе «Проектное Управление» на Корпоративном Портале.
• Оценка состояния (Status Assessment) – этот артефакт представляет собой периодическую оценку состояния, предоставляет механизм управления ожиданиями на протяжении жизненного цикла проекта. Используется для обеспечения механизма адресации, сообщений и разрешения вопросов управления, технических вопросов и рисков проекта. Вся работа по оценке состояния Проекта происходит в рабочей группе Проекта на Корпоративном Портале.
• Концепция (Vision) – этот артефакт определяет представление заинтересованных лиц о разрабатываемом продукте, заданное в терминах ключевых потребностей и функциональных возможностей. Он содержит структуру представляемых основных требований, а также ограничений проекта, таким образом, обеспечивая договорную основу для более подробных технических требований, тесно связан с «Экономическим обоснованием проекта».
• Требование программного обеспечения (Software Requiment) – представляет собой спецификацию условий или возможностей, которым должна соответствовать система. Этот артефакт будет использоваться в Компании в виде «Оценки трудозатрат».
• Запросы заинтересованных лиц (Stakeholder Requests) – этот артефакт содержит все типы запросов заинтересованного лица к разрабатываемой системе. Назначение этого артефакта – зафиксировать все запросы к проекту, а также предпринятые по ним действия. Он будет использоваться в виде заявок в системе регистрации заявок, либо в виде сообщений в рабочей группе Проекта

Шаг №5: Создать модель жизненного цикла для проекта.

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

• Фаза Начало – веха целей жизненного цикла,
• Фаза Уточнение – веха архитектуры жизненного цикла,
• Фаза Построение – веха начальной работоспособности,
• Фаза Внедрение – веха выпуска продукта.

Шаг №6: Сделать процесс, адаптированный для конкретного проекта, доступным членам проектной группы.

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

Шаг №7: Поддерживать процесс.

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

Положительные эффекты от использования RUP

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

• Использование проектного управления в своей деятельности;
• Внутренний ресурс, на котором размещена база знаний о проектной работе;
• Повышение культуры проектной работы сотрудников Компании: понимание того, что такое концепция проекта, экономическое обоснование проекта, план работ, принятие того, что не всегда можно спланировать дату окончания проекта, но можно наметить контрольные точки (вехи), по которым отслеживать ход проекта;
• Определение перечня артефактов (в моем случае – документов, используемых в проектной работе);
• Выделение такой деятельности как процесс управления требованиями, расширение функциональности процесса поддержки;
• Ролевой подход к работе;
• Удовлетворенность работой и уверенность в ИТ-департаменте.

Система регистрации заявок OTRS, Корпоративный Портал 1С:Битрикс, артефакты RUP и четкая последовательность действия – это составляющие успеха данного Проекта по адаптации RUP. Уже намечены дальнейшие шаги по внедрению RUP в большем масштабе: запланирован переход на TFS (Team Foundation Server) для управления версионностью в разработке программного обеспечения и переход на Project Server для планирования работ.

Список литературы

1. Справочная информация. Rational Method Composer.
2. Кратчен Ф. Введение в Rational Unified Process. 2-е изд. 2002. – 240 с.
3. Полис Г. и др. Разработка программных проектов на основе Rational Unified Process (RUP). 2009. – 256 c.
4. Бергстрем С. Rational Unified Process – Путь к успеху. Руководство по внедрению RUP. 2004. – 256 с.
5. http://ru.wikipedia.org/
6. http://www.ibm.com/developerworks/ru/library/kroll/index.html
7. http://epf.eclipse.org/wikis/openup/

Copyright © 2010 Котиков А.Э.