Риски аутсорсинга 1С

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

Попадание в зависимость от подрядчика и быстрый рост стоимости услуг

Такое бывает в случае недобросовестности подрядчика, а еще чаще такая проблема встречается у наших клиентов при организации собственной команды поддержки и развития персонала внутри компании. Почему так происходит? Своя команда слабо мотивирована на всеобъемлющее документирование и без должного контроля система часто превращается в черный ящик, недоступный для понимания руководству. В первую очередь персонал собственной службы поддержки заинтересован решать проблемы “здесь и сейчас”.

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

Как минимум, в этом наборе должен быть:

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

Второй момент, обязательно поинтересуйтесь “планом выхода” (расставания с подрядчиком). Каким образом подрядчик завершает работу с клиентом? Как передает материалы по системе, передает знания новой команде? У хорошего исполнителя такая процедура должна быть описана. Идеальным вариантом было бы запросить референс с кем-то из клиентов подрядчика, с кем уже прекращены отношения. 

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

Слабая команда подрядчика (“приведут студентов”) и частая ротация специалистов

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

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

И это же позволит отработать опасения ваших пользователей о том, что исполнитель не настолько вовлечен, как своя команда (“в случае проблем и сверхурочной загрузки свои люди останутся работать, аутсорсер уйдет домой”) — подрядчик, замотивированный на сервисные KPI, будет вовлекаться как минимум не хуже своей команды.

Непонимание сотрудниками подрядчика специфики компании, и как следствие, неоптимальные или неверные решения

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

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

Потенциальное неприятие пользователями удаленной работы, и как следствие провалы в коммуникации

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

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

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

Дополнительно

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

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

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