Сквозная автоматизация бизнес-процессов в любом случае непроста. Для компании ATH Business Travel Solutions, работающей на рынке делового туризма, задача осложнялась ещё и тем, что ее бизнес состоял из двух разнородных частей, которые требовалось объединить. О том, чего и как удалось добиться, мы беседуем с директором по информационным технологиям ATH Павлом Савицким.
Intelligent Enterprise: Давайте начнем с краткой истории развития вашей компании. Ведь она была создана путем слияния двух независимых фирм?
Павел Савицкий: Да, АТН образовалась в 2002 году в результате объединения двух очень успешных игроков на российском рынке делового туризма — Travel House и Andrews Consulting. Каждый специализировался на своем сегменте рынка: Travel House — на услугах, связанных с организацией поездок, Andrews Consulting — на консультациях по вопросам оформления виз, легализации и получения разрешений на работу. Мы унаследовали оба вида деятельности. Недавно у нас появился новый продукт — travel policy, т. е. разработка и поддержка корпоративной политики в области поездок. Такая политика определяет условия путешествия в зависимости от его характеристик (например, если продолжительность перелета более шести часов, сотрудник летит в бизнес-классе, если меньше — в экономическом), и чтобы гарантировать ее соблюдение, необходимо решить ряд вопросов взаимодействия с партнерами — авиаперевозчиками и службами бронирования мест в отелях. Компания является аккредитованным агентом Международной ассоциации воздушного транспорта (IATA) и может гарантировать высшее качество услуг.
Поскольку мы собираемся говорить об автоматизации, стоит охарактеризовать масштаб предприятия. У нас пять офисов: головной, который действует фактически круглосуточно, находится в Москве, оставшиеся четыре — в Лондоне, Санкт-Петербурге, Самаре и Нижнем Новгороде. Численность персонала — 214 человек, не считая курьеров, занимающихся только доставкой заказов клиентам, которых около сорока.
С точки зрения клиента услуги по оформлению визы и приобретению билета принципиально не различаются. Но судя по тому, что существовали две разные компании, занимавшиеся тем и другим, для провайдера разница есть. В чем она состоит?
Деятельность по организации поездок — по преимуществу агентская: мы продаем заказчикам услуги коммерческих поставщиков (авиакомпаний, служб бронирования). Наши сотрудники здесь общаются с фирмами, ориентированными на рынок, и в своей работе следуют четким бизнес-правилам бронирования перевозок, которые существуют не один год и заложены в специализированные информационные системы. Услуги, связанные с визами, — наши собственные, как раньше они были собственными для Andrews Consulting. Мы заключаем с заказчиком договор возмездного оказания услуги и взаимодействуем непосредственно с государственными органами — соответственно если клиенту отказывают в выдаче документов или она задерживается, наши возможности повлиять на ход дела ограниченны. Для этого вида деятельности не существует общепринятых формальных бизнес-правил и готовых средств автоматизации — в Andrews Consulting использовалась система собственной разработки. Даже наши сотрудники, специализирующиеся на визовых услугах и на поездках, не похожи друг на друга по своему психологическому складу. И преодоление различий между ними — одна из тех задач, которые мы хотим решить путём внедрения единой CRM-системы.
Решение внедрять CRM-систему, единую для обоих направлений, было принято сразу после объединения?
Не совсем. Так как слияние осуществлялось в сжатые сроки, мы сначала просто попробовали на некоторой общей платформе объединить ИТ-инфраструктуры одной и другой компаний. Однако это решение нас не устроило, и вот почему.
В качестве общей платформы мы взяли бухгалтерскую систему Concorde XAL, использовавшуюся в Andrews Consulting, и перевели на неё свои финансовые процессы. А в области работы с клиентами каждая из двух объединившихся фирм принесла в ATH свою технологию работы и соответствующие средства автоматизации. Технология Travel House была ориентирована на клиента, и оттуда к нам пришла система GDS (Global Distribution System), а также комплекс front office и back office — упрощенный аналог CRM-системы, как его понимали на рубеже тысячелетий. Эти программы позволяли отслеживать политики в области поездок, вести статистику по клиентам, фиксировать их предпочтения, — т. е. все было замечательно. В Andrews Consulting основой для построения бизнес-процессов служил скорее заказ и, как я уже сказал, имелась визовая система собственной разработки. Мы написали интерфейсы интеграции и передачи данных из систем Travel House и Andrews Consulting в Concorde XAL и некоторое время пытались работать в такой конфигурации. Надо сказать, что мы ожидали определенных шероховатостей, но недооценили их масштаб.
Суть проблемы заключалась в том, что учетные записи клиентов в одной и другой базе велись совершенно независимо друг от друга, так что невозможно было понять, какой клиент что у нас приобрел, — механизм генерации консолидированной отчетности по двум направлениям бизнеса отсутствовал. Фактически мы не знали, сколько покупает одна компания и сколько другая; внутренняя себестоимость обработки заказов и выставления счетов подскочила на неимоверную высоту, и стало ясно, что вскоре нам будет сложно конкурировать на рынке.
Хотя сотрудники иногда сидели буквально спина к спине, они не координировали своих действий. Бывали случаи, когда клиент заказывал у нас авиабилет и визу, его соединяли с двумя разными агентами, в выдаче визы посольство ему по какой-то причине отказывало, а оформление билета тем временем шло своим чередом. В какой-то момент агент, отвечавший за билет, звонил клиенту и сообщал, что все готово, — нетрудно догадаться, какую это вызывало реакцию.
В конце концов, поняв, что дальше так работать нельзя, мы приняли решение полностью сменить инфраструктуру и выстроить совершенно новую систему. Это был смелый шаг, но только с его помощью мы могли надеяться выжить.
Какими критериями вы руководствовались при выборе платформы?
Прежде всего надо было определиться с требованиями. Наша бизнес-задача заключалась в том, чтобы с нуля наладить базовые процессы, и прежде всего мы хотели выстроить процессы обработки заказов. Замечу, что это не характерно для проектов внедрения CRM-систем — в основном они помогают повысить качество обслуживания клиентов путем усовершенствования уже существующих процедур.
Нам требовалась, во-первых, единая точка ввода информации, чтобы по каждому клиенту создавалась учетная запись, автоматически отображающаяся во всех остальных системах. Дублирование данных о клиенте в каких бы то ни было других базах исключалось. Во-вторых, нужен был сквозной бизнес-процесс, полностью охватывающий цикл развития взаимоотношений с клиентом, начиная с появления у нас интереса к нему и заканчивая уплатой налога. На всех этапах процесса следовало расставить контрольные точки, позволяющие в любой момент проверить, на какой стадии находится тот или иной заказ. Наконец, в-третьих, вводилась концепция универсального агента, который для каждого клиента только один и работает с ним как по организации поездок, так и по оформлению виз. Мы стремились с помощью системы заставить сотрудников освоить все виды услуг и избавиться от узкой специализации.
Определившись с требованиями, мы стали рассматривать имеющиеся западные системы и обнаружили массу предложений, позволяющих автоматизировать только одно из наших направлений — организацию поездок. Что касается визовой части, то на Западе она по естественным причинам развита слабо, и нам не удалось найти ничего подходящего. Большинство продуктов были к тому же закрытыми, что делало невозможной их доработку. В наибольшей степени нас устраивала система Siebel E-Travel, но с учетом стоимости отпала и она.
Тогда мы пошли к разработчикам, и они обратили наше внимание, с одной стороны, на Microsoft Dynamics CRM, а с другой — на решения на основе Microsoft Dynamics NAV (в то время Microsoft Navision). Современные программные средства не позволяют на базе одной платформы автоматизировать наши сквозные бизнес-процессы, поэтому использование двух систем так или иначе было обязательно. В подобных случаях лучше брать продукты одного семейства.
Какая архитектура информационной системы получилась в результате?
Взаимодействие с клиентами обеспечивает решение на основе Microsoft Dynamics CRM, функции back office — решение на основе Microsoft Dynamics NAV. У каждой системы своя база данных, а между ними находится интеграционный компонент — Microsoft BizTalk Server, главная функция которого состоит в двусторонней передаче (с преобразованием) данных между базами. Он реагирует на событие, происходящее в одной из баз, и если оно удовлетворяет определенным условиям, переносит соответствующую информацию в другую.
Здесь надо отметить, что мы оперируем двумя разными понятиями о клиенте. До заключения контракта компания для нас представляет собой единое целое — так называемый «бренд», т. е. нас не интересует состав входящих в нее юридических лиц. А с момента подписания договора начинает существовать «организация» — в это понятие вкладывается примерно тот же смысл, что и в юридическое лицо. Непосредственные потребители наших услуг, конечно, не бренды и не организации, а конкретные люди, для которых оформляются визы, заказываются билеты и бронируются гостиницы, но эта связь легко прослеживается и не вызывает затруднений.
Из Microsoft Dynamics CRM в Microsoft Dynamics NAV передаются такие объекты,
как организация, сервисный контракт, поставщик, продукт, заказ на услугу, строка
заказа на услугу (где обозначен конкретный продукт с ценой для данного конкретного
клиента), запрос на предоплату (многие наши продукты требуют предоплаты для
поставщика) и, наконец, представительские расходы (сюда входят все траты, которые
невозможно непосредственно привязать к какому-либо заказу, — скажем, посещение
ресторана с представителем заказчика: мы должны их учитывать, так как считаем
внутреннюю себестоимость обслуживания клиентов). Из Microsoft Dynamics NAV в
CRM-систему возвращается дебиторская задолженность по каждому контракту. Таким
образом, специалисту по продажам не надо работать с ERP-системой — он все видит
внутри CRM-системы, причем в нее встроен триггер, реагирующий на превышение
определенной суммы задолженности (допустимый максимум различается в зависимости
от сегмента клиентской базы). Возвращаются также обменный курс (это обусловлено
техническими причинами: Microsoft Dynamics NAV поддерживает работу с курсами,
а Microsoft Dynamics CRM — нет), статус заказа (оплачен, не оплачен, в стадии
ожидания) в целом и по каждой строке в отдельности, статус запроса на предоплату
— принят или не принят (кстати, эта информация генерируется автоматически на
основе авансового отчета).
Первоначально клиент появляется у нас в качестве бренда. Мы готовим тендерную
документацию, участвуем в тендере, выигрываем его и заключаем контракт — уже
с организацией. Контракт имеет стандартную форму, и к нему прилагается прайс-лист,
определяющий стоимость наших продуктов для клиента (данный подход соответствует
принятой практике). На основе этих документов создается заказ. Комплексный заказ
с точки зрения системы представляет собой некое хранилище заказов индивидуальных,
относящихся к определенному юридическому лицу и определенной поездке. (Комплекс
услуг может включать, к примеру, перелет в оба конца, гостиницу и визу, возможны
любые наборы.) А в систему бухгалтерского учета переходит строка заказа, и когда
это происходит, уже не нужен человек, чтобы делать проводку, — все выполняется
автоматически. У бухгалтеров фактически остались только функции наблюдения и
коррекции в случае каких-либо сбоев в процессе.
Добавлю, что CRM-решение интегрировано с GDS (международной системой бронирования авиаперевозок), а Microsoft Dynamics NAV — с банковскими системами банков, наших партнеров.
Расскажите, пожалуйста, о ходе работ по проекту.
Работа началась в январе 2005 года, и первые шесть месяцев мы параллельно занимались
поиском решения и внутренней оценкой бизнес-процессов. Была проведена ревизия
всех отделов, запротоколировано, кто что делает, и каждая система оценивалась
с точки зрения того, как в ней будут реализованы существующие функции. На этой
стадии мы не приглашали внешних консультантов.
В июне мы, подготовив документацию, объявили тендер, который выиграла компания
«АйТи». Следующие два месяца с нами работали ее консультанты. С задачей они
справились на самом высшем уровне, особенно мне понравилось, что они смогли
посмотреть на нас со стороны и заново оценить нашу клиентскую базу, предложить
нам новую систему сегментации. Именно в этот период идея универсального агента
начала воплощаться в конкретных схемах, так что было уже понятно, куда идти,
какие преимущества мы получим, где возможны проблемы и как их преодолевать.
Чтобы ускорить момент первого запуска (на этом настаивало руководство), мы разделили проект на два этапа: на первом должны были внедряться жизненно необходимые модули, на втором — такие, с которыми можно было подождать. Одна из наших главных проблем состояла в том, что первоочередными оказались как раз те функции, которые отсутствовали в системе в готовом виде, и их нужно было разработать.
На первом этапе разрабатывались и внедрялись функции, самые важные для нас. Мы реализовали управление клиентами и брендами (в нашем понимании), а также продуктами (это основа всей системы), прайс-листами, поставщиками, сервисными контрактами, комплексными заказами (одновременно включающими обслуживание поездок и визовую поддержку), отзывами клиентов. Естественно, была внедрена и генерация разнообразной отчетности — управленческой, бухгалтерской и т. д.
Разработка заняла семь месяцев, и к марту мы получили рабочую версию системы, в которую можно было заводить данные. Мы собрали содержимое трех баз в единый файл, почистили его, убрав повторы, и импортировали в CRM-систему, а оттуда информация через Microsoft BizTalk Server была перенесена в Microsoft Dynamics NAV. И здесь нас поджидал неприятный сюрприз. Дело в том, что наши продукты не были формализованы, и аналитические схемы, используемые для оценки прибыльности клиента, никак не соотносились со схемами ценообразования. Пришлось перепроектировать каталог продуктов.
На тестирование системы мы потратили совсем немного времени — наверное, надо бы больше, но слишком сложно было отвлекать сотрудников от повседневной работы. Четвёртого апреля состоялся запуск новой системы, и тогда же мы остановили все предыдущие решения и базы данных — параллельная работа в двух системах не велась ни минуты, так как в нашем бизнесе это нереально.
Сейчас начат второй этап проекта. В его ходе внедряются главным образом те функции, которые пришли к нам вместе с CRM-системой, — управление интересами, сведениями о конкурентах, планирование продаж, расчеты с клиентами, база знаний по продуктам и т. д.
Таким образом, успех налицо?
В свое время представители компании Microsoft рассказали мне, что по их опыту внедрение CRM-системы, как правило, является успешным, если компания через пять месяцев эксплуатации не отказалась от решения и продолжает с ним работать. Мы работаем в своей системе уже седьмой месяц и, следовательно, можем причислить себя к счастливчикам. При этом нам удалось осуществить сквозную автоматизацию работы с заказчиком — от появления интереса до уплаты налога.