Лайфхаки проектов автоматизации клиентского сервиса

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

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

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

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


Критерии выделения вех проекта:

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

2. По территории
Есть у нас есть обособленные подразделения, заводы, склады, которые находятся на разных площадках и работают каждое в своей базе, их логично запускать отдельно.


Преимущества такого подхода – в нем меньше рисков при запуске нового функционала, меньше нагрузки на проектную команду и меньше стресса для предприятия целиком.

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

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

Порядок запуска:

1. Заменить то, что работает сейчас
2. Добавлять новые функции

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

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

Способы обеспечения:

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

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

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

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

Выписка документов происходит и рано утром, и в выходные, и в праздники – всегда. А содержать линию поддержки 24х7 ради возможных инцидентов не целесообразно. Поэтому при запуске лучше выделять людей из пользователей, на которых мы будем «приземлять» этот функционал.

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

Компетенции опорных специалистов:
1. Понимание бизнес-процесса своей области
2. Понимание логики системы
3. Мотивированность/вовлеченность в проект
4. Способности к обучению других

Порядок подготовки:

1. Своевременное выделение специалистов
2. Обучение
3. Вовлечение в проект на этапе подготовки и запуска первого этапа

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

Наиболее эффективно это происходит еще на этапе подготовки к запуску. Например, привлечение через написание пользовательских инструкций или через обучение пользователей.

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

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

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

Зачем:

1. Производительность
2. Надежность
3. Поддержка
4. Развитие

В финансовом контуре есть высоконагруженные операции, такие как расчет себестоимости, которые тормозят базу. Процессы оперативного учета (прием заказов, отгрузка) требуют стабильной быстрой работы системы. Так же финансовый контур требует регулярные обновления, связанные с изменениями законодательства, что накладывает риски на стабильность работы базы. Чтобы не усложнять себе жизнь, разделяйте базы регламентированного и оперативного учета.

Обычно заказчиками системы являются руководители отделов продаж (директор по продажам/коммерческий директор).

Наиболее важной задачей для них является работа с клиентами и обеспечение объемов продаж, а наведение порядка в клиентском сервисе – это задача второго порядка. Как следствие, задача оказывается брошенной – вроде и делается, но без участия бизнес заказчика нет ориентиров и многое делается не то или не так.

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

Способы вовлечения:

1. Участие в совещаниях управляющего комитета проекта
2. Еженедельные статус встречи на активных этапах
3. Участие в демонстрациях функционала

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

Желаю, чтобы ваши проекты проходили гладко и успешно.