В редакцию портала поступил вопрос:
Добрый день!
Какие существуют рекомендации или лучшие практики по принятию нового сервиса на поддержку службой Service Desk?Положим, в рамках внутреннего проекта происходит внедрение транспортно-логистической системы. Поддержка системы после сдачи в эксплуатацию предполагается имеющимся штатом службы Service Desk. Какие действия должны быть предприняты со стороны ServiceDesk для того чтобы на входе получить минимум проблем?
Для принятия на поддержку хорошо бы еще иметь результаты test case-ов и bug report с комментарием. это нужно для того чтобы понимать какие проблемы с системой возникали и как их решали. опять же возможно не всё могло быть исправлено и тогда сразу станет понятно как обработать обращения пользователя. если админы внутри техподдержки, то хорошо бы еще план отката иметь.
Этот момент называется ELS (Early life support). Читайте в книге ITILv3 Service Transition, Figure 4.26 (стр 144) .
Из личного опыта могу посоветовать привлечь менеджера/специалиста Сервисдеск в процесс разработки новой услуги , к примеру на этапе тестирования продукта. Тендер закончен, выбрали поставщика и продукт. Попросили поставщика провести инсталяцию. Вот в этот момент зовём Сервисдеск. Они сами скажут что им надо на выходе в эксплуатацию.
Скажу из весьма богатого личного опыта.
В зависимости от типа реализуемого проекта(цифрового или классического), очень важно на ранних этапах привлекать в обязательную роль – архитектора сервиса. Он в курсе стека технологий, наличие компетенций внутри и снаружи организации, стоимости сервиса.
Также очень важно иметь выстроенный единый подход по приемке проектов на сервис с понятными сроками/метриками эффективными практиками управления финансами.
Ситуации разные бывают, но общие черты конечно есть и было бы здорово иметь на этапе завершения проекта:
1. обученных специалистов поддержки (пускай без опыта – система новая, но они должны её пощупать и посмотреть как и что решать)
2. инструкции для админов и поддержки системы
3. перечень пользователей новой системы
4. согласованный с бизнесом SLA по поддержке
5. предполагаемое кол-во обращений
6. описание регламентных работ
7. (на основании п 4-6) расчёт необходимого кол-ва специалистов для соблюдения SLA
8. документацию на систему и план (процесс) её актуализации в случае изменений
9. если планируется привлечение внешней (высокоуровневой поддержки производителя или разработчика) – соответствующие договоренности с ними (Договор).
10. если лицензируемое ПО используется (соответственно расчёт и закупка лицензий и их техподдержки)