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

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

В закладки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{ "author_name": "Дмитрий Малыгин", "author_type": "self", "tags": [], "comments": 7, "likes": 5, "favorites": 10, "is_advertisement": false, "subsite_label": "services", "id": 116708, "is_wide": false, "is_ugc": true, "date": "Wed, 01 Apr 2020 07:32:49 +0300", "is_special": false }
Онлайн-марафон «2 шага до уровня pro в маркетинге недвижимости»
26 мая Онлайн Бесплатно
Объявление на vc.ru
0
7 комментариев
Популярные
По порядку
Написать комментарий...
1

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

Ответить
0

Полностью согласен. В дополнение к вашему аргументу - это даст возможность обсудить детали еще на спокойном этапе, когда есть временные ресурсы этим заниматься (а не перед/на старте)

Ответить
0

Для sd и проектов какие программы используете?

Ответить
0

проекты - redmine, поддержка - 1C Itilium

Ответить
0

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

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

Ответить
0

Дмитрий, спасибо за интересный опыт передачи проектов на сопровождение. Подскажите, пожалуйста, какие по вашей технологии сроки передачи всех работ - идеальные и максимальные, ну и фактические? И нет ли проблем, если у команды проекта после окончания работ сразу же начинается следующий проект? Ведь все равно же возникают вопросы со стороны команды сопровождения.
Заранее спасибо за ответ!

Ответить
0

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

Ответить

Прямой эфир