Привет, Хабр! Уже 27 лет моя работа связана с сервисной ИТ-поддержкой крупного бизнеса. За это время накопилось много наблюдений и мыслей о том, как нужно (и как не нужно) выстраивать сервисную модель, чтобы потом не было мучительно больно – ни исполнителю, ни заказчику. И так сложилось, что в последнее время меня об этом спрашивают все чаще – роль сервисного обслуживания в наши непростые дни сильно выросла. Вот я и подумал перенести свои ответы «на бумагу». Если вам тоже интересно как устроен рынок сервисной поддержки, прошу под кат.
На мой взгляд, сервис — это прежде всего идея, скрепленная людьми, нацеленными творить добро. Это прям очень краткое определение, тут отдельную статью можно писать про подбор людей с сервисным мышлением. И важное подмножество этих людей — искренне вовлеченное руководство, осознающее ценность и суть сервисного подхода в бизнесе. В идеале. А в жизни хорошо, если у руководства есть понимание высокой конверсии сделок в сервисном бизнесе и очевидных преимуществ регулярных платежей. Еще лучше, если кто-то понимает, какой может быть профит и конкурентные преимущества от гарантированного развития отношений с заказчиками на базе качественного сервиса.
Как правило, на старте у нас некий небольшой интегратор или вендор, осознавший необходимость построения собственного сервиса. Или в большом интеграторе в отдельно взятом направлении возникла такая потребность. Иными словами предполагаем, что какой-то объем запросов и внутренняя потребность построить сервис уже есть.
Хотя потребность эта, как правило, возникает, когда уже «горит» и времени на разумное планирование нет прям от слова «совсем». Например, некрупный, заточенный на боксмувинг, интегратор продал кому-то железо. На примере железа легче объяснять, а так-то речь может идти и про софт, и про комплексное решение на нескольких вендорах. Оно сломалось, но не так чтоб не включается, а «с частичной потерей функционала». Интегратор: «ну так есть же гарантия». И просит вендора, иногда через дистрибьютора, поменять. А вендор: «присылайте, посмотрим». Ага, присылайте, а что будет делать заказчик на время ремонта? Обычно, если нет подмены, то страдает Заказчик. Это раньше можно было довольно оперативно купить что-то на рынке, придумать обходное решение, и пусть это всегда были дополнительные траты, но монетизация рисков была вполне допустима. А сейчас «увы и ах».
В итоге, наученный на ошибках заказчик, в следующий раз в требованиях по закупке прописывает в гарантии строгий SLA. Время назначения инженера такое-то, срок предоставления авансовой замены или обходного решения такой-то и т.п. Таким образом, заказчик риски слегка с себя снял и, в большинстве случаев, считает, что на бюджет закупки такое требование влияет незначительно. На практике же заказчику нужно наступить на очередные грабли. И не факт, что это случится быстро. Но это отступление от темы. Интегратор: «да не вопрос. Положу в ЗИП какой-то процент железа каждого типа из поставки и буду предоставлять оперативную замену и менять неисправную по гарантии. А по назначению инженера разверну фриварный сервис деск и попрошу своих инженеров откликаться на заявки. Посчитаю себестоимость и добавлю к сумме контракта.»
Если мы не рассматриваем вариант «рискну и забуду учесть», то тут возникают первые диалоги про косты: запчасти (далее ЗИП), инженеры, сервис деск с организацией внесения туда базовой информации и многое другое. Ладно, если проект сразу большой и своей рентабельностью перекрывает эти затраты, тут опять можно целую статью написать о заблуждениях проектно-мыслящих людей по поводу сервисных нюансов, но на старте это крайне редкий случай. В 99% случаев это «А чего так дорого?», «А что сделать, чтобы эти затраты как-то снизить?», «А почему нужно платить из маржи непойми за что?»
И как правило, если вариант «молиться и извиняться» не рассматривается, то в голову приходит шаринг ресурсов между потенциальными проектами. И тут зарождается сервисный отдел…
И зарождается он, к сожалению, сначала не как центр прибыли, а как кост-центр. Потому что «это же затраты». На этой стадии убедить людей, принимающих решение, что грамотно выстроенный сервис — это не только стабильный доход, но и классный маркетинговый инструмент, практически нереально. Поэтому забываем про миссионерство, «берем лопату и копаем».
Если речь про 8х5, то это два человека по каждой технологии на случай отпусков, болезней и т.д. Если замахнулись на 24х7, то это 5 человек, по той же схеме n+1, для организации дежурств. Если потока ночных звонков не ожидается, то тут можно обойтись дежурствами на удаленке. За небольшую доплату, как правило, инженеры соглашаются неделю находиться в постоянной готовности отвечать на звонки в нерабочее время. Как правило, критичные проблемы сопровождаются не только пингом в чате, но и звонками, и такое дублирование имеет смысл прописывать в договоре, иначе, при непостоянной нагрузке, заявки будут «прозёвываться».
Вторая, крайне весомая составляющая сервиса — это ЗИП. Как правило, 2-5% для каждого партномера из спецификации с округлением вверх до целого. Процент каждая компания определяет, исходя из собственной практики и объемов бизнеса, понятно, что чем крупнее поставки, тем меньше этот процент, но, конечно же есть и другие методики планирования.
Плюс стенд для проверки и ремонтная лаборатория, чтобы чинить вышедшее из строя оборудование, а это и помещение, и закупка оборудования на, примерно, миллион рублей на старте.
Нужно не забывать, что и лаборатория, и стенд не только стоят денег, но и требуют наличие квалифицированных инженеров, которые будут тестировать и чинить оборудование. Это тоже косты.
Вообще с инженерами, которые будут решать инциденты и непосредственно общаться с заказчиком тоже история не простая. При наличии квалификации эти люди также должны обладать сервисным мышлением. Именно они будут совместно с заказчиком работать в поиске над решением инцидента и неумение общаться, собственные амбиции или отсутствие искреннего желания помочь заказчику могут помножить на ноль несомненные плюсы от высокой технической компетентности инженера.
Суммарная себестоимость содержания команды – это не только зарплата, но и масса дополнительных денежных вливаний и на адаптацию, и на обучение, и на кучу других «и», о которых хорошо знают HR-ы и бухгалтерия. Поэтому, на первых порах, имеет смысл рассматривать возможность привлечения субподрядчиков. Важно понимать, что если мы делегируем какую-то роль, связанную с соблюдением наших обязательств перед заказчиками, то денег жалеть не надо и договариваться о субподряде лучше с крупными игроками.
В противном случае, например при задействовании внешнего контакт-центра, можно столкнуться с тем, что оператор запросто может не владеть базовыми терминами или не корректно произнести название одного из ваших ключевых заказчиков. Так что, если и искать подрядчиков, то очень тщательно, без попытки сэкономить на качестве.
Худо-бедно заложили резерв на ЗИП, ремонты или пополнение ЗИП и трудозатраты. Добавили порядка 10% от всех заложенных трудозатрат на управление контрактом (тут про сервис менеджеров, администраторов и т.п.). Плюс управленческие косты компании а ля менеджмент, бухгалтерия, HR, маркетинг,… Добавили наценку за риски, плановую маржинальность, налоги и т.п. Получили стоимость услуги. В случае хорошего потока входящих запросов, вас, скорее всего, не ждут неприятные сюрпризы, но если вы находитесь на старте сервисного бизнеса, то себес всегда будет выше ожиданий и заказчика и ваших продавцов. Это инвестиции. Очень болезненные инвестиции. Успокаивать может то, что даже если вы покупаете ЗИП под годичный контракт, то, с высокой долей вероятности, вы выиграете продление, так как ЗИП у вас уже будет сформирован, а рынок не кишит компаниями с реальным ЗИПом на реальном сервисном складе (персонал, выделенное помещение с доступом 24х7, стеллажи с оборудованием и т.д.). Кстати, сейчас заказчики не стесняются прописывать в требованиях возможность своего визита на сервисный склад исполнителя в первую неделю после подписания контракта. Потемкинская деревня, ввиду специфики помещения, легко вскрывается.
Вернемся к сценарию, когда мы поставляем много однотипного оборудования или уже налажен бизнес в отрасли конкретного заказчика. Ценник может оказаться сильно ниже рынка.
И вот тут очень важно не продешевить. Почему? Естественно, кроме нежелания ронять рынок, и объяснять заказчикам, почему на две похожие железки сервис отличается в разы, есть и другие причины. Например, если завтра начнется каскадный падёж оборудования из-за того, что конкретный чип, задействованный в разных устройствах разных вендоров, выработал свой ресурс, и у вас на складе не окажется необходимого количества замен, то и вы и заказчики окажетесь в печальном положении.
Тут нужно предусмотреть некий запасной план. И это не только или не столько про деньги. От того, что вы зарезервировали деньги на срочную закупку, железо быстрее не приедет. Запасной план это про наличие определенного запаса функциональных замен на складе интегратора, лабу и мониторинг новостей от различных производителей. И, как следствие, увеличение себестоимости сервиса.
Казалось бы, все понятно, ничего хитрого. Но оказывается, что если держать прямую замену под каждый партномер, то сервисная модель в реальной жизни не окупается… Практически никогда.
Каждый новый контракт с партномерами очень похожими на те, что лежат на сервисном складе, приносит нам новые познания в принципиальности различий цифр и букв. А за одной буквой может стоять, как просто страна производства, так и тип интерфейсов или лицензии. И тут нужен набор компетентных инженеров, которые определят отличия; поймут кто тут кого ОЕМ-ит (наклейка может быть одного производителя, а, по сути, это другой); подберет замену с сервисного склада (иногда эта замена предполагает серьезную проработку конфигов) и т.д. Казалось бы, возьмем молодое дарование, и он/она по даташитам нам все подберет. И вот тут оказывается, что без опыта ну прям никак. По-хорошему, нужны инженеры уровня Professional+ с хорошим практическим опытом. И так по совершенно различным вендорам и технологиям, в зависимости от того, что мы планируем поддерживать. На круг получается очень даже нехилый кост. Фрилансеры, в этой модели, себя не оправдывают из-за отсутствия должной степени ответственности. Ошибка в анализе может всплыть через год-два.
Понятно, что инженеры нужны не только для расчета ЗИП. Более того, любой инженер, зациклившийся на подборе замен и оторванный от работы в реальных проектах или сервисных контрактах, через полгода-год начнет терять квалификацию. А для загрузки таких инженеров нужны солидные проекты. При этом, если инженер погружен в какой-то проект, то попробуйте его выдернуть на анализ ЗИПа… получается, что нужно либо много проектов и много инженеров, либо держать заведомо неоптимальный сервисный склад, либо избыточную команду, либо излишне рисковать.
Избыточный склад, на практике, никто не даст закупить. Слишком заметно для финансов на старте любого сервисного контракта.Избыточная команда инженеров и себя не окупит и разбежится, если ее не подкармливать интересной работой.
А с рисками ситуация в последние годы поменялась и просто деньгами их не покрыть. Если раньше можно было за 3-5 дней привезти почти любое оборудование на замену, то сейчас сроки увеличились на порядок. Это не считая того, что модель рисков легко вскрывается визитами заказчиков.
Вот и получается, что уже на старте построения сервиса нужно определиться с массой вопросов, связанных со стратегией компании. Как правило, нужно выбрать одно из двух: либо узкоспециализированные ЗИП и инженеры, либо много ЗИПа, и много профилей инженеров. В первом случае инвестиций меньше, но риск того, что выбранная ниша через какое-то время станет невостребованной, естественно, выше.
В принципе, все что я тут написал — это то, что я рассказываю, когда меня спрашивают с чего начать.Но есть еще дополнительные вопросы и они, как правило, задаются после некоторого осмысления.
Как оценить стоимость ЗИП?
Как уценивать ЗИП на несколько проектов и что меняется при подписании новых контрактов на оборудование уже имеющееся на сервисном складе?
Как обойти вендорские ограничения по софту?
Как посчитать рыночную стоимость сервиса?
Какой коэффициент использовать для 24х7 и для фиксированных обязательств?
Не спрашивают, как правильно организовать работу 24х7,
Про скрытые нюансы ведения сервисного склада,
Зачем нужны СМы,
Как сделать так, чтобы инженеры не бежали от рутины,
Какая команда оптимальна для пресейла
Что имеет смысл автоматизировать,
Как качать стажеров и можно ли это делать через сервис,
Как на собеседовании определить сервисность кандидата,
и еще массу частных вопросов, возникающих несколько позже.
Но об этом в следующий раз.
Немного лирики
На мой взгляд, сервис — это прежде всего идея, скрепленная людьми, нацеленными творить добро. Это прям очень краткое определение, тут отдельную статью можно писать про подбор людей с сервисным мышлением. И важное подмножество этих людей — искренне вовлеченное руководство, осознающее ценность и суть сервисного подхода в бизнесе. В идеале. А в жизни хорошо, если у руководства есть понимание высокой конверсии сделок в сервисном бизнесе и очевидных преимуществ регулярных платежей. Еще лучше, если кто-то понимает, какой может быть профит и конкурентные преимущества от гарантированного развития отношений с заказчиками на базе качественного сервиса.
Откуда берется сервис
Как правило, на старте у нас некий небольшой интегратор или вендор, осознавший необходимость построения собственного сервиса. Или в большом интеграторе в отдельно взятом направлении возникла такая потребность. Иными словами предполагаем, что какой-то объем запросов и внутренняя потребность построить сервис уже есть.
Хотя потребность эта, как правило, возникает, когда уже «горит» и времени на разумное планирование нет прям от слова «совсем». Например, некрупный, заточенный на боксмувинг, интегратор продал кому-то железо. На примере железа легче объяснять, а так-то речь может идти и про софт, и про комплексное решение на нескольких вендорах. Оно сломалось, но не так чтоб не включается, а «с частичной потерей функционала». Интегратор: «ну так есть же гарантия». И просит вендора, иногда через дистрибьютора, поменять. А вендор: «присылайте, посмотрим». Ага, присылайте, а что будет делать заказчик на время ремонта? Обычно, если нет подмены, то страдает Заказчик. Это раньше можно было довольно оперативно купить что-то на рынке, придумать обходное решение, и пусть это всегда были дополнительные траты, но монетизация рисков была вполне допустима. А сейчас «увы и ах».
В итоге, наученный на ошибках заказчик, в следующий раз в требованиях по закупке прописывает в гарантии строгий SLA. Время назначения инженера такое-то, срок предоставления авансовой замены или обходного решения такой-то и т.п. Таким образом, заказчик риски слегка с себя снял и, в большинстве случаев, считает, что на бюджет закупки такое требование влияет незначительно. На практике же заказчику нужно наступить на очередные грабли. И не факт, что это случится быстро. Но это отступление от темы. Интегратор: «да не вопрос. Положу в ЗИП какой-то процент железа каждого типа из поставки и буду предоставлять оперативную замену и менять неисправную по гарантии. А по назначению инженера разверну фриварный сервис деск и попрошу своих инженеров откликаться на заявки. Посчитаю себестоимость и добавлю к сумме контракта.»
Если мы не рассматриваем вариант «рискну и забуду учесть», то тут возникают первые диалоги про косты: запчасти (далее ЗИП), инженеры, сервис деск с организацией внесения туда базовой информации и многое другое. Ладно, если проект сразу большой и своей рентабельностью перекрывает эти затраты, тут опять можно целую статью написать о заблуждениях проектно-мыслящих людей по поводу сервисных нюансов, но на старте это крайне редкий случай. В 99% случаев это «А чего так дорого?», «А что сделать, чтобы эти затраты как-то снизить?», «А почему нужно платить из маржи непойми за что?»
И как правило, если вариант «молиться и извиняться» не рассматривается, то в голову приходит шаринг ресурсов между потенциальными проектами. И тут зарождается сервисный отдел…
И зарождается он, к сожалению, сначала не как центр прибыли, а как кост-центр. Потому что «это же затраты». На этой стадии убедить людей, принимающих решение, что грамотно выстроенный сервис — это не только стабильный доход, но и классный маркетинговый инструмент, практически нереально. Поэтому забываем про миссионерство, «берем лопату и копаем».
Что нужно для начала: 1я линия
Если речь про 8х5, то это два человека по каждой технологии на случай отпусков, болезней и т.д. Если замахнулись на 24х7, то это 5 человек, по той же схеме n+1, для организации дежурств. Если потока ночных звонков не ожидается, то тут можно обойтись дежурствами на удаленке. За небольшую доплату, как правило, инженеры соглашаются неделю находиться в постоянной готовности отвечать на звонки в нерабочее время. Как правило, критичные проблемы сопровождаются не только пингом в чате, но и звонками, и такое дублирование имеет смысл прописывать в договоре, иначе, при непостоянной нагрузке, заявки будут «прозёвываться».
Склад запчастей и ремонтная лаборатория
Вторая, крайне весомая составляющая сервиса — это ЗИП. Как правило, 2-5% для каждого партномера из спецификации с округлением вверх до целого. Процент каждая компания определяет, исходя из собственной практики и объемов бизнеса, понятно, что чем крупнее поставки, тем меньше этот процент, но, конечно же есть и другие методики планирования.
Плюс стенд для проверки и ремонтная лаборатория, чтобы чинить вышедшее из строя оборудование, а это и помещение, и закупка оборудования на, примерно, миллион рублей на старте.
Нужно не забывать, что и лаборатория, и стенд не только стоят денег, но и требуют наличие квалифицированных инженеров, которые будут тестировать и чинить оборудование. Это тоже косты.
Команда
Вообще с инженерами, которые будут решать инциденты и непосредственно общаться с заказчиком тоже история не простая. При наличии квалификации эти люди также должны обладать сервисным мышлением. Именно они будут совместно с заказчиком работать в поиске над решением инцидента и неумение общаться, собственные амбиции или отсутствие искреннего желания помочь заказчику могут помножить на ноль несомненные плюсы от высокой технической компетентности инженера.
Суммарная себестоимость содержания команды – это не только зарплата, но и масса дополнительных денежных вливаний и на адаптацию, и на обучение, и на кучу других «и», о которых хорошо знают HR-ы и бухгалтерия. Поэтому, на первых порах, имеет смысл рассматривать возможность привлечения субподрядчиков. Важно понимать, что если мы делегируем какую-то роль, связанную с соблюдением наших обязательств перед заказчиками, то денег жалеть не надо и договариваться о субподряде лучше с крупными игроками.
В противном случае, например при задействовании внешнего контакт-центра, можно столкнуться с тем, что оператор запросто может не владеть базовыми терминами или не корректно произнести название одного из ваших ключевых заказчиков. Так что, если и искать подрядчиков, то очень тщательно, без попытки сэкономить на качестве.
Ценообразование и подводные камни
Худо-бедно заложили резерв на ЗИП, ремонты или пополнение ЗИП и трудозатраты. Добавили порядка 10% от всех заложенных трудозатрат на управление контрактом (тут про сервис менеджеров, администраторов и т.п.). Плюс управленческие косты компании а ля менеджмент, бухгалтерия, HR, маркетинг,… Добавили наценку за риски, плановую маржинальность, налоги и т.п. Получили стоимость услуги. В случае хорошего потока входящих запросов, вас, скорее всего, не ждут неприятные сюрпризы, но если вы находитесь на старте сервисного бизнеса, то себес всегда будет выше ожиданий и заказчика и ваших продавцов. Это инвестиции. Очень болезненные инвестиции. Успокаивать может то, что даже если вы покупаете ЗИП под годичный контракт, то, с высокой долей вероятности, вы выиграете продление, так как ЗИП у вас уже будет сформирован, а рынок не кишит компаниями с реальным ЗИПом на реальном сервисном складе (персонал, выделенное помещение с доступом 24х7, стеллажи с оборудованием и т.д.). Кстати, сейчас заказчики не стесняются прописывать в требованиях возможность своего визита на сервисный склад исполнителя в первую неделю после подписания контракта. Потемкинская деревня, ввиду специфики помещения, легко вскрывается.
Вернемся к сценарию, когда мы поставляем много однотипного оборудования или уже налажен бизнес в отрасли конкретного заказчика. Ценник может оказаться сильно ниже рынка.
И вот тут очень важно не продешевить. Почему? Естественно, кроме нежелания ронять рынок, и объяснять заказчикам, почему на две похожие железки сервис отличается в разы, есть и другие причины. Например, если завтра начнется каскадный падёж оборудования из-за того, что конкретный чип, задействованный в разных устройствах разных вендоров, выработал свой ресурс, и у вас на складе не окажется необходимого количества замен, то и вы и заказчики окажетесь в печальном положении.
Тут нужно предусмотреть некий запасной план. И это не только или не столько про деньги. От того, что вы зарезервировали деньги на срочную закупку, железо быстрее не приедет. Запасной план это про наличие определенного запаса функциональных замен на складе интегратора, лабу и мониторинг новостей от различных производителей. И, как следствие, увеличение себестоимости сервиса.
Поиск золотой середины
Казалось бы, все понятно, ничего хитрого. Но оказывается, что если держать прямую замену под каждый партномер, то сервисная модель в реальной жизни не окупается… Практически никогда.
Каждый новый контракт с партномерами очень похожими на те, что лежат на сервисном складе, приносит нам новые познания в принципиальности различий цифр и букв. А за одной буквой может стоять, как просто страна производства, так и тип интерфейсов или лицензии. И тут нужен набор компетентных инженеров, которые определят отличия; поймут кто тут кого ОЕМ-ит (наклейка может быть одного производителя, а, по сути, это другой); подберет замену с сервисного склада (иногда эта замена предполагает серьезную проработку конфигов) и т.д. Казалось бы, возьмем молодое дарование, и он/она по даташитам нам все подберет. И вот тут оказывается, что без опыта ну прям никак. По-хорошему, нужны инженеры уровня Professional+ с хорошим практическим опытом. И так по совершенно различным вендорам и технологиям, в зависимости от того, что мы планируем поддерживать. На круг получается очень даже нехилый кост. Фрилансеры, в этой модели, себя не оправдывают из-за отсутствия должной степени ответственности. Ошибка в анализе может всплыть через год-два.
Понятно, что инженеры нужны не только для расчета ЗИП. Более того, любой инженер, зациклившийся на подборе замен и оторванный от работы в реальных проектах или сервисных контрактах, через полгода-год начнет терять квалификацию. А для загрузки таких инженеров нужны солидные проекты. При этом, если инженер погружен в какой-то проект, то попробуйте его выдернуть на анализ ЗИПа… получается, что нужно либо много проектов и много инженеров, либо держать заведомо неоптимальный сервисный склад, либо избыточную команду, либо излишне рисковать.
Избыточный склад, на практике, никто не даст закупить. Слишком заметно для финансов на старте любого сервисного контракта.Избыточная команда инженеров и себя не окупит и разбежится, если ее не подкармливать интересной работой.
А с рисками ситуация в последние годы поменялась и просто деньгами их не покрыть. Если раньше можно было за 3-5 дней привезти почти любое оборудование на замену, то сейчас сроки увеличились на порядок. Это не считая того, что модель рисков легко вскрывается визитами заказчиков.
Вот и получается, что уже на старте построения сервиса нужно определиться с массой вопросов, связанных со стратегией компании. Как правило, нужно выбрать одно из двух: либо узкоспециализированные ЗИП и инженеры, либо много ЗИПа, и много профилей инженеров. В первом случае инвестиций меньше, но риск того, что выбранная ниша через какое-то время станет невостребованной, естественно, выше.
P.S.
В принципе, все что я тут написал — это то, что я рассказываю, когда меня спрашивают с чего начать.Но есть еще дополнительные вопросы и они, как правило, задаются после некоторого осмысления.
Как оценить стоимость ЗИП?
Как уценивать ЗИП на несколько проектов и что меняется при подписании новых контрактов на оборудование уже имеющееся на сервисном складе?
Как обойти вендорские ограничения по софту?
Как посчитать рыночную стоимость сервиса?
Какой коэффициент использовать для 24х7 и для фиксированных обязательств?
Не спрашивают, как правильно организовать работу 24х7,
Про скрытые нюансы ведения сервисного склада,
Зачем нужны СМы,
Как сделать так, чтобы инженеры не бежали от рутины,
Какая команда оптимальна для пресейла
Что имеет смысл автоматизировать,
Как качать стажеров и можно ли это делать через сервис,
Как на собеседовании определить сервисность кандидата,
и еще массу частных вопросов, возникающих несколько позже.
Но об этом в следующий раз.
