После уяснения задачи, перед ее выполнением, всегда идет этап проектирования и планирования. Прежде чем копать яму желательно уточнить размеры, разметить территорию, выяснить, нет ли там трубы или кабеля. Определить сколько человек, лопат, экскаваторов необходимо, чтобы уложиться в заданный срок. Иначе никак. Внедрение службы поддержки не исключение.
Типичная проблема на старте
Тупиковое развитие событий, когда заказчик Service Desk ставит задачу поставить новое решение, но, чтобы все было по-старому. По принципу, сделайте также как было, только угадайте, что должно быть лучше. Почему так происходит:
1. Часто заказчик явно не признается самому себе, что существующая система не соответствует новым реалиям: изменениям рынка, возросшим потребностям компании и т.д. Решение о замене приходит подсознательно или в силу физической невозможности продолжать пользоваться устаревшим ПО.
2. К старой системе все привыкли. Есть ясное понимание, чтобы что-то изменить, нужно дополнительно напрягаться, а не хочется. Люди готовы закрыть глаза на текущие неудобства, лишь бы не оказаться в грядущей буре перемен.
Тут важно поставщику услуг по внедрению привести клиента в меридиан реального положения дел. Для этого нужно грамотно использовать характерные особенности ПО систем обработки заявок.
Специфика Service Desk
Хорошо продуманная и настроенная система используется достаточно длительное время. Пользователь действует по принципу: работает – не трогай. Часто эксплуатация без какого-либо апгрейда настолько продолжительна, что поддержка старой версии прекращается. Нередки случаи, когда из-за недоступности активации лицензий, отсутствовала возможность восстановиться после сбоя.
До такого состояния лучше не доводить. Обновить устаревшую, снятую с поддержки версию стоит очень дорого. Стоимость сопоставима с установкой с нуля последней версии или с заменой на продукт другого производителя.
Отдельного внимания требует сохранение и перенос архива старых заявок. В идеале он должен быть мигрирован весь, его лучше не терять. В крайнем случае глубина архивных данных должна быть не менее года или сопоставима времени эксплуатации обслуживаемого продукта. История сервисных обращений покажет специфику процесса, динамику изменений и поможет правильно настроить новую систему. Перенос – отдельная дорогая работа. Если не удается это сделать, есть смысл оставить на время старую систему в качестве хранилища архива.
Как выбрать то, что нужно
Пару десятков лет назад было всего пару штук популярных Help Desk. Муки выбора отсутствовали, ставили, что есть. Сейчас рынок предлагает несколько десятков вариантов ПО для организации службы поддержки. Разобраться в этом зоопарке сложно, нужно исходить из условий применения и ориентироваться в деталях реализации. Чтобы не завалить внедрение, необходимо учесть ряд моментов:
- Область применения. Для внутренних нужд или для предоставления сервисных услуг клиентам во вне. Внешняя система более сложная и характеризуется наличием разветвленной системы справочников и классификаторов базы данных, предназначенной для хранения заявок.
- Организация внедрения. Своими силами или привлечение внешних консультантов. Вопрос важный, потому что нет ничего более действенного, чтобы провалить проект, как сделать все самому, начать с внедрения ПО, а потом подстраивать под бизнес-процессы. Сразу заплатить за лицензии на весь персонал и управление процессом взять на себя руководителю, не ниже генерального директора.
- Стоимость. Нужно понимать структуру ценообразования. Кому платить: вендору, его партнеру или еще кому-то. Что входят в стоимость: просто лицензии, услуги внедрения и все или с последующим сопровождением и т.д.
Не нужна служба техподдержки организациям, которые передали свою ИТ-структуру на аутсорсинг. Service Desk в этом случае целесообразно включить в состав комплекса заказанных услуг.
Тонкости внедрения
Важно не ошибиться с выбором ответственного за процесс. Топ-менеджмент не подойдет. По статистике, личное участие высшего руководства заканчивается через неделю, а вспоминать об этом гендиректор перестает месяца через два. Если у организации развитая структура и планируется полноценный Service Desk, то нужен отдельный менеджер, который будет руководить внедрением, а впоследствии эксплуатацией сервиса. С установкой небольшого Help Desk или тикетной системы справится сотрудник, занимающийся обработкой заявок. Однако, ему необходимо выделить не менее 50% рабочего времени на управление и администрирование.
При проектировании нужно заложить возможность увеличения поступающих заявок не за счет расширения штатов, а путем оптимизации процессов обработки. Как ни странно, реально упорядочить работу удается с помощью выявления отнюдь не сложных, а наоборот, быстро решаемых задач. Увлечение первоочередным закрытием простых тикетов раньше срока снижает эффективность работы системы в целом. Ну и классическое устранение узких мест, когда количество определенного класса задач не соответствует числу специалистов нужной квалификации. Исключительно оптимизацией удается увеличить объемы обработки в среднем на 30-40%. Когда технические возможности будут исчерпаны, статистика Service Desk будет лучшим аргументом для руководства о необходимости увеличения штата.
В ходе внедрения возникнет масса нюансов, которые невозможно учесть на старте. Не стоит пытаться развернуть сразу в полном объеме разветвленный Service Desk, даже когда процессы понятны. Показателен случай, когда заказчик настаивал на комплексном тестировании всех функций до ввода в пром. Более десятка ролей, заявка порождает несколько сотен событий, сложная система оповещения – все это предписывалось исполнителю запустить одним махом. Когда сроки внедрения в три раза превысили планируемые, пришло понимание тупикового развития ситуации. Выбраться удалось только развертыванием системы по очередям.
Крайне редко встречается идеальная картина, когда сначала досконально анализируются бизнес-процессы, а потом выполняются действия по установке и настройке. Практика показывает, что никто не хочет на старте платить за описание процессов. Настаивать при продаже не стоит, заказчик сам поймет необходимость такой процедуры, когда столкнется с первыми проблемами. Чтобы инцидент не перерос в конфликт, нужно пока все на берегу, во время предпродажной работы квалифицировано информировать заказчика о возможных вариантах развития событий.
Правильная продажа
В ходе внедрения Service Desk заказчика ненавязчиво, но настойчиво надо подводить к мысли о нецелесообразности использовать длительное время установленную версию без апгрейта. Вместе с продуктом желательно приобретать услугу обновления в течение 2-3 лет. Если этого не сделать в будущем гарантирован неизбежный негатив.
Здесь важно соблюсти баланс между желаниями продавца и покупателя. Не лучшая идея со стороны продавца в ходе предпродажных переговоров прямолинейно заявлять, что нужно сейчас заплатить, иначе будут проблемы. На этой стадии нужно грамотно управлять ожиданиями покупателя. Объяснять, что система может, а что нет, исходя из объективных событий, которые могут вывести продукт из строя. А вопрос приобретения страховки лучше перенести на время выполнения работ и, на примерах из уже апробированной практики внедрения и начала эксплуатации, тактично убедить заказчика предусмотреть возможность периодического обновления.
Заказчик тоже живет в реальном мире и пусть подсознательно, но понимает, что ничего вечного и идеально работающего не бывает. Совершенствуются технологии, раз в год выпускаются новые версии, в том числе и для того, чтобы устранить баги. Глупо купить автомобиль, а потом предъявлять претензии автосалону, что ремонт поломки стоит денег, а вмятина не выправляется сама собой. Правильно будет оформить КАСКО.
При беде заказчик все-равно придет к исполнителю за помощью. И для снижения градуса напряженности позиция исполнителя: помнишь я предлагал, намного выигрышней заявления: сам виноват, плати теперь вдвое. При первом варианте клиент не уйдет и естественная покупка продукта под названием «отсутствие проблем» в виде регулярного обновления и поддержки Service Desk будет выгодна обеим сторонам.
