Аутсорсинг Или Техническая Поддержка?



Преамбула Представьте, что есть некое предприятие.

Разумеется, с бизнес-критичной архитектурой.

Любой простой – это потеря денег.

Сеть для предприятия построил интегратор.

Инженеры предприятия обращаются к специалистам того же интегратора за советом и моральной поддержкой.

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

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

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

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



Услуги технической поддержки

Прежде всего, именно это и напрашивается.

То, что происходит де-юре, формализуется де-факто.

Более того, начиная с одного предприятия, нужно идти продавать услуги другим.

То, что должно быть сделано?

  • 1. Разработать типовой договор на оказание услуг технической поддержки (думаю, в Интернете можно найти «рыбку» или что-то вроде «Договор техподдержки для чайников»).

    Разумеется, с приложениями.

    Обязательно с указанием времени выполнения и разбивки по приоритетам, например, критические/крупные/незначительные/технические недостатки.

  • 2. Создать презентацию и отправить торгового представителя с предпродажей посетить потенциального клиента и рассказать о преимуществах.

    Ключевой момент в том, что ваши проблемы полностью ложатся на наши суровые, мозолистые плечи.

    Покажите, сколько ваш бизнес теряет из-за простоя и сколько вы готовы заплатить за решение проблемы.

  • 3. В зависимости от оговоренного в договоре времени реагирования и устранения неполадок (например, 24/7 плюс не более 4 часов на полное восстановление сервиса), необходимо будет организовать службу поддержки.

    Внимание! Все попытки обойти этот пункт всегда заканчивались неудачно.

    Очень важно понимать, что подписавшись на 24*7*4, вам понадобятся как минимум два человека, в основном занимающиеся поддержкой.

  • 4. Учитывайте состав и расположение запчастей.

    С точки зрения бизнеса ЗИП – это заморозка денег, поэтому если суммы внушительные, то придется искать компромисс.

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

    Определить форму приема дел о несчастных случаях.

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

    Определить сроки и формат отчетности.

    Определить вариант обратной связи с заказчиком.

    Определить процедуры взаимодействия экспертов и инженеров поддержки.

    «Создайте вторую линию поддержки».

    После наиболее критических случаев опережайте процедуру «Сообщение о нарушениях».

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

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

Это грубого помола.

Добавляйте, если пропустили что-то важное.



Аутсорсинг

Отличается от вышеперечисленного другим текстом договора и другими суммами.

В идеале под вашу юрисдикцию попадают те инженеры, которые бегали по предприятию и звали поддержку.

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

Сервисдеск, как вы понимаете, жизненно важен, это статистика и аргумент в спорах.

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

Скорее всего, экономическое обоснование аутсорсинга с одним клиентом может не сработать.

Конечно, надо сесть и посчитать.

Затем наведите хвост на продавца, чтобы он активнее продавал услуги.

Постройте свой собственный центр мониторинга или отдайте его индийцам (о мечты, мечты).

Если ваши долгосрочные планы аутсорсинга рассчитаны на срок более двух лет, то контракт должен включать развитие инфраструктуры.

Да Да.

Вам придется создать стратегию развития ИТ на несколько лет, защитить бюджет на модернизацию и т. д.

Заключение

Оба варианта реальны.

Если бы я консультировал корпоративного клиента, я бы рекомендовал воспользоваться услугами поддержки.

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

С максимальным количеством точек контроля, указанным в договоре.

И, конечно же, все это справедливо для действительно сложной критической архитектуры.

Теги: #ИТ-инфраструктура #Системное администрирование #техническая поддержка #аутсорсинг

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.