Компания «Росинтер Ресторантс» решила создать единый центр обработки заявок и обращений для всех своих сервисных подразделений, а не для одной только ИТ-службы. В качестве методологии была выбрана ITIL.

Компания «Росинтер Ресторантс» решила создать единый центр обработки заявок и обращений для всех своих сервисных подразделений, а не для одной только ИТ-службы. В качестве методологии была выбрана ITIL.

Отечественный ресторанный рынок относительно пуст. В любой европейской столице на каждые 100 метров может быть по пять-шесть точек питания, причем практически не отличающихся друг от друга. В то же время потребность Москвы в предприятиях общественного питания удовлетворяется приблизительно на 20%. Конечно, надо учесть, что в нашей стране (особенно за последние годы) пропала привычка регулярно посещать рестораны. Да и большинство россиян никогда не придерживались «американского» подхода, когда человек практически ничего не готовит дома и, чтобы подкрепиться, отправляется в специализированные заведения. Судя по всему, на данный момент российскому рынку не нужно столько ресторанов и кафе, сколько могло бы быть развернуто согласно «мировым стандартам», но простор для его роста, безусловно, еще есть.

Более того, перспективы развития просто огромны, особенно вне развитых промышленных центров — там, где из предприятий общепита есть лишь дорогие рестораны да забегаловки с отвратительным сервисом.

Полнофункциональный велосипед

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

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

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

Идея создания центра обработки заявок, связанных с ИТ, родилась три года назад. С его помощью в «Росинтере» рассчитывали уточнить объемы решаемых ИТ-отделом задач и выявить узкие места — проблемы, с которыми приходится сталкиваться наиболее часто. Имея на руках статистику о проведенных работах, о проблемах и путях их решения, можно сделать выводы о том, какие направления работы ИТ-отдела надо совершенствовать.

Алексей Ильинский, ИТ-директор компании «Росинтер Ресторантс»

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

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

Серьезным импульсом к дальнейшему развитию проекта создания центра послужила информация о процессе внедрения функции Service Desk в торговом доме «Перекресток». Так же, как и у «Росинтер Ресторантс», у «Перекрестка» имеется развитая сеть территориально распределенных площадок, на которых развернуты типовые ИТ-решения.

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

Деятельность в цифрах

Компании не всегда интересно, что происходит внутри подразделений, гораздо важнее, что она получает от них на выходе. Главное ее требование — все проблемы в бизнес-единицах должны решаться. В «Росинтере» рассчитывали получить технический сервис — надежный, качественный, гарантированный.

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

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

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

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

Инструментарий

В качестве инструментария для построения системы обработки заявок в «Росинтер Ресторантс» выбрали модуль HP OpenView ServiceDesk. По мнению Ильинского, подобных систем не так много, к тому же большинство из них имеет массу ограничений по функционалу. Поскольку основным критерием выбора являлось отражение принципов ITIL в программном обеспечении, предпочтение было отдано OpenView. «Решение НР является практически единственным, ?заточенным? под процессы ITIL», — уверен Ильинский.

«У системы есть ограничения, про которые консультанты предпочитают молчать», — сетует Ильинский. Например, говоря про способность системы настраивать логику, все забывают, что настройка не очень гибкая: имеется ограниченный набор полей, которые могут использоваться в работе, но если их не хватает, приходится менять бизнес-логику.

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

Еще один недостаток: архивация данных в системе реализована весьма странно, для просмотра «исторических» данных приходится использовать внешние средства.

В качестве продавца системы и консультанта по развертыванию бизнес-процессов ITIL была выбрана компания «Инфосистемы Джет». Система была запущена в эксплуатацию в сентябре 2004 года. К настоящему времени в ней зарегистрировано более 6 тыс. заявок. Служба принимает около 50 различных заявок в день — от простейших до комплексных, связанных с открытием новых ресторанов.

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

Ориентируясь на пользователя

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

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

Создавать систему приоритетов заявок было сложнее, в этой области и сейчас ситуация не идеальна. Основная проблема в том, что одни и те же заявки в разное время и на различных объектах «стоят» по-разному.

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

Базовые регламенты взаимодействия с пользователями (способы обращения, контроля, уведомления) также стандартизованы. Например, обратиться можно по телефону, по почте или лично. Это касается проверки статуса и отчетов о выполнении заявок.

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

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

Стандарты общения

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

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

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

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

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

«Росинтер»

Компания «Росинтер Ресторантс» входит в состав холдинга «Ростик Ресторантс», владеющего сетью ресторанов разных форматов, концепций и ценовых категорий. Основное направление деятельности холдинга — развитие сетей концептуальных ресторанов различных марок, ориентированных на разные ниши рынка («Ростик?c», «IL Патио», «Планета Суши», T.G.I. Friday?s, «Мока Лока», «Сибирская Корона» и др.). На начало 2005 года «Ростик Ресторантс» обслуживала 174 ресторана, из них 119 в Москве и Московской области. Согласно планам холдинга, к концу 2005 года число ресторанов превысит 200.

Еще раз о «человеческом факторе»

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

Кроме того, сотрудники должны понимать, ради чего осуществляется проект. Если они не прониклись его идеей, внедрять систему бесполезно. Это ключевой момент внедрения. Все остальное преодолевается относительно легко. «Можно переустановить систему, переосмыслить свой подход, но если персонал не заинтересован и не обладает достаточным уровнем квалификации, все усилия пойдут насмарку», — уверен Ильинский.

Ну и еще одна, не менее важная проблема — приучить компанию пользоваться созданным сервисным центром.

Ильинский считает, что большая часть перечисленных проблем может быть решена простым убеждением: «Можно многого добиться, объясняя персоналу, почему вводимые новшества принесут пользу не только компании, но и им самим. В самом деле, чем лучше работает система, чем тщательнее она отлажена, тем легче самим сотрудникам, тем меньше нагрузка, которая на них падает. Да, система создана с учетом максимального удобства клиентов, но она предназначена для улучшения работы сотрудников службы поддержки».

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

Еще один веский аргумент заключается в том, что методология ITIL стала стандартом де-факто и знакомство с ним повысит ценность ИТ-сотрудника как профессионала.

С целью поддержания «боевого духа» специалистов возникла идея отойти от практики использования «профессиональных» диспетчеров. Действительно, сидеть по восемь-девять часов за телефоном — тяжелое испытание для здорового и активного человека. В связи с этим планируется обеспечить ротацию персонала внутри отдела, сейчас эта практика начинает применяться.

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