Как передать только что внедренную систему на поддержку?

для сложных, нетиповых систем 1С

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

• Не сразу понятно, как распределяется ответственность, и кто за что отвечает.
• Пользователи не доверяют новым специалистам поддержки, считают (и резонно) проектную команду умнее. 
• Как следствие, сохраняется замкнутый круг — проектная команда продолжает решать заявки, поддержка тем временем не накапливает компетенции.

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

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

Как можно этого избежать? 

Мы в ФТО исповедуем 5 практик, которые минимизируют риски и помогают сгладить процесс передачи системы на поддержку. При чем совершенно неважно — кто занимался внедрением (наши же специалисты, внутренняя команда заказчика или сторонняя организация).

1. Поэтапная передача участков

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

Как понять, что участок стабилизирован?

В первую очередь смотрите на объем ошибок в системе или настройках, справочниках. Как только у вас будет состояние “все ошибки закрыты к концу дня”, это первый флаг. Второй флаг — уверенность пользователей. Как только все пользователи отработали каждую операцию по нескольку раз и первичный вал вопросов сократился в два-три раза, можно отдавать систему на регулярную поддержку.

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

2. Общая система Service Desk

Используйте единую систему Service Desk для проектных консультантов, запускающих систему, и команды будущей поддержки. У нас в ФТО система управления проектным циклом и система для поддержки разные, но перед стартом мы переключаем проектную команду в Service Desk поддержки.

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

3. Привлечение специалистов поддержки в проект 

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

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

Привлекать десант из поддержки на проект желательно как можно раньше:

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

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

4. Создание базы знаний

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

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

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

5. Управление ожиданиями

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

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

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

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

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

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

И самое главное — не забывайте о коммуникации. От нее зависит успех любого проекта.

О том, как организована поддержка в ФТО читайте здесь