Преамбула

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

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

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

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

• 1. Разработать типовой договор на оказание услуг по техподдержке(думаю на просторах интернета можно найти «рыбу» или что-то вроде «Договор о техподдержке для чайников»). Разумеется, с приложениями. Обязательно с lead-time и разбивкой по приоритетам, например critical/major/minor/tech cons.
• 2. Создать презентацию и послать сейла с пресейлом в гости к потенциальному заказчику рассказывать о преимуществах. Лейтмотив – ваши проблемы ложатся на наши суровые мозолистые плечи целиком и полностью. Показать сколько теряет бизнес на простоях и за какую сумму вы готовы решать проблему.
• 3. В зависимости от согласованного в договоре времени реакции и устранения аварий (например, 24 на 7, плюс не более 4 часов на полное восстановление сервиса) необходимо будет организовать отдел поддержки. Внимание! Все попытки обойти этот пункт всегда заканчивались неуспешно. Очень важно понимать, что подписавшись под 24*7*4, вам потребуется минимум два человека, главным образом занимающихся поддержкой.
• 4. Продумать состав и расположение ЗИП. С точки зрения бизнеса ЗИП это замораживание денег, поэтому если суммы внушительные, то придется искать компромисс.
• 5. Продумать и оформить процедуру взаимодействия с заказчиком, включая веб-сервисдеск или хотя бы отдельный email. Определить форму приема кейсов по авариям. Определить номер аварийной поддержки (который будут носить поочередно два инженера поддержки). Определить сроки и формат отчетности. Определить вариант фидбэка от заказчика. Определить процедуры взаимодействия экспертов с инженерами поддержки. «Оформить вторую линию поддержки». После самых критичных кейсов опередить процедуру «Disturbance reporting».
• 6. При сложной архитектуре заказчика в перспективе можно предложить решение мониторинга и автоматического формирования кейсов в поддержку при аномальных значениях счетчиков/показателей.
• 7. При увеличении количества заказчиков, необходимо расширять штат поддержки, причем очень рекомендую выделить отдельного человека менеджера-руководителя поддержки, который будет взаимодействовать с заказчиком, получать фидбэк и оперативно решать вопросы взаимодействия.

Это крупным помолом. Добавьте, если что-то важное упустил.

Аутсорсинг

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

Вывод

Оба варианта реальны. Если бы я консультировал заказчика-предприятие, я бы рекомендовал использовать услуги поддержки. Первые несколько лет. Когда исполнитель будет знать сеть заказчика как свои пять пальцев (как, например, семейный доктор болячки всего семейства за последние дцать лет ), только после этого можно отпускать в аутсорсинг. С максимальным количеством точек контроля, прописанных в договоре. И конечно, все это справедливо при действительно сложной критичной архитектуре.

Автор: igor2706

Источник