Привет! Меня зовут Роман Остапчук, я директор по техническому развитию РТК-Сервис. Одной из важных моих задач является взаимодействие с нашими заказчиками – телеком-операторами разного профиля и из разных сегментов рынка.
В этой статье я постарался собрать воедино основные принципы хорошего ТЗ от оператора связи партнеру по сервисному обслуживанию телеком-инфраструктуры. Причем не просто хорошее ТЗ, а которое сэкономит заказчику до 20% стоимости контракта и гарантирует качественное исполнение услуг.
Операторы связи обслуживают свою телеком-инфраструктуру, в основном привлекая для этого сервисных партнеров. В настоящее время это ИКТ-компании, которые в свое время обучили специалистов, а в последние годы активно разобрали к себе инженеров, ранее работавших у покинувших РФ западных вендоров. К слову, эти же спецы сейчас отлично разбираются уже в новых решениях от российских производителей. А еще в наличии у партнеров – собственные лаборатории для тестирования оборудования, склады запчастей и другие (недокументированные) возможности. И все равно по моему опыту, именно люди – главный ресурс. В 90% случаев от их рук и светлых (и, конечно, мотивированных) голов зависит результат.
До 2022 года крупные операторы связи и корпоративные заказчики иногда заключали прямые контракты на техническую поддержку с производителями. Но подавляющее число компаний в России имели договорные отношения с российскими интеграторами, которые уже в свою очередь заключали договора с производителями на критичные услуги и услуги, которые могли предоставить только вендоры.
После ухода иностранных производителей оборудования из России вся система пошла на слом. Перед нашими заказчиками встала задача переоценки правил и методов работы с внешними поставщиками услуг технической поддержки. Потребность же в этом не только не сократилась, но стала еще сильнее и сложнее в реализации. Во многих компаниях есть несколько центров компетенций, которые имеют свои очерченные зоны ответственности и показатели эффективности. Вопросы юридической чистоты, финансовой эффективности и технической компетенции как правило имеют различных владельцев, и мы видим, как сложно дается нашим заказчикам выработка итогового компромисса. Зачастую ключевым критерием для победы в тендере является самая низкая стоимость контракта, и у технического блока заказчика не всегда хватает аргументации в спорах с закупками или финансистами, чтобы оценивать будущего сервисного партнера по более глубоким компетенциям. Но если смотреть только на цену, это в 99 случаев из 100 грозит непредвиденными ситуациями в процессе взаимодействия.
Поэтому, надеюсь, моя статья будет полезна с точки зрения раздельного анализа всех компонентов услуг технической поддержки в текущих условиях. Подробнее читайте под катом.
Для того, чтобы посчитать стоимость услуг по контракту, нужно оценить масштаб требуемых ресурсов и рисков, которые будут сопровождать проект. Чем качественнее и оперативнее происходит общение с заказчиком на этом этапе, тем эффективнее с экономической и технической точки зрения складывается дальнейшее сотрудничество.
Мы стараемся прозрачно и предсказуемо для партнеров выстроить весь процесс общения. Чтобы помочь заказчикам быстрее погрузиться в наш подход, мы предлагаем заполнить несложный специальный опросник, который прояснит все нюансы и позволит прозрачно забюджетировать услуги по техподдержке. По этому опроснику мы работаем со всеми телеком-операторами и испытали его в действии десятки раз – на проектах постгарантийного обслуживания. Спойлер – в львиной доле случаев мы сами заполняем все опросники, пишем и выверяем все ТЗ, но опросник формулирует ключевую информацию, и ее нужно уточнить и верифицировать с заказчиком.
Бывает, что заказчик уже приходит с детально проработанным ТЗ, но, как ни странно, в текущей ситуации в таком подходе есть много подводных камней. Иногда ТЗ делается на основе предыдущего контрактного опыта, без учета реалий последних двух лет. Иногда — на основе опыта общения с единственным интегратором и по формализованным процедурам. Но анкеты и опросники, которые нужно заполнить, очень разные от интегратора к интегратору по своей глубине и степени проработки, не факт, что в больших лонгридах корректно расставлены приоритеты, существует описание возможных вариантов поведения, когда у заказчика большая инфраструктура с пробелами в инвентаризации и документировании. А ведь этот фактор влияет на результат. Недостаток данных может привести к недоразумениям и непониманию запроса, а избыточные требования — к удорожанию контракта.
Итак, содержание ТЗ. Поехали по пунктам.
1. Подробная спецификация оборудования
В техническом задании должна быть отражена спецификация оборудования, которое установлено у заказчика, и это первый пункт опросника, который мы заполняем подробно. Если спецификация содержит перечень и описание оборудования в точном и полном виде, то дальнейший расчет ведется с использованием этих данных.
Если мы получаем на руки только перечень моделей устройств, то уточненную спецификацию со всей информацией по оборудованию составляем мы совместно с заказчиком.
Спецификация оборудования - один из основных источников оптимизации себестоимости и ценообразования потенциального контракта в целом, так как мы можем предложить различные варианты исполнения непосредственно сервисных работ и оптимизированные способы использования подменных фондов оборудования с учетом возможных ограничений и рисков.
Очень многие наши заказчики, решая задачи развития и повышения качества сервиса, чуть меньше времени и ресурсов уделяют поддержанию актуальной информации о своих активах. Но важно отметить, что любая совместная работа по уточнению информации дает хороший результат и положительно сказывается на точности проработки затрат на реализацию. Например, обоснованная экспертная оценка служб эксплуатации о типовом составе карт в шасси или примерном распределении таких типовых вариантов на сети.
2. Адресный план установки оборудования
Львиная доля проектов в нашем портфеле требует проведения тех или иных работ с привязкой к адресу установки оборудования. Например, это касается отправки отремонтированного или восстановленного оборудования, забора вышедшего из строя оборудования с адреса установки. Москва или Хабаровск – согласитесь, есть разница. Поэтому для точного расчета себестоимости услуги необходимо точно знать, где стоит оборудование.
Этот пункт долго расписывать не будем, обычно его заполняют максимально точно, нужно только учитывать, что адресный план может меняться, если в период действия контракта заказчик ставит дополнительное оборудование на сетях. Нас это, конечно, не слишком беспокоит - мы работаем с территориально распределенными заказчиками по всей стране.
3. Статистика обращений в техподдержку
На этом пункте предлагаю остановиться подробнее. Как говорил ранее, очень важно для подготовки лучшего конкурентного предложения максимально точно сформулировать и разложить по полочкам все неизвестные вводные и специфицировать риски. Мы пытаемся погрузиться в то, что происходит в заказчике, в его традиции эксплуатации и развития своей сети. Например, в распределение задач между собственным персоналом и подрядчиками, в политики информационной безопасности, специфику расширения сети и т.п. Как показывает практика, двух одинаковых операторов с этой точки зрения не бывает.
На что мы смотрим и какие исторические данные запрашиваем у заказчика:
1. Количество обращений за информационной поддержкой в части специфики эксплуатации оборудования, предоставления актуальной документации и т.п.
2. Количество обращений за технической поддержкой при проведении аварийно-восстановительных работ (АВР): количество кейсов 1-го и 2-го приоритета (с полным, критическим или существенным ущербом для сервисов), количество минорных консультаций и диагностик.
3. Количество аппаратных неисправностей в год. Идеально выделить статистику выходов из строя от блоков питания и вентиляторов до основных модулей оборудования.
Обращения мы детализируем по вендорам, линейкам оборудования и категориям инцидентов. Инциденты, в свою очередь, разбиваем на четыре группы по следующим параметрам:
· АВР оборудования с существенной деградацией сервисов (25% и более). Да-да, мы помним, что у вас есть SLA с приоритетами, но на данном этапе распределение АВР по типам не играет значительной роли.
· АВР оборудования без существенной деградации сервисов.
· АВР, повлекшие замену аппаратных компонентов.
· Запросы на информационную поддержку и предоставление документации.
Исходя из предоставленных данных, проводим расчет:
· спецификации оборудования для ЗИП (запчасти и материалы), которое потребуется на период срока действия договора;
· спецификации оборудования из лаборатории, которое будет задействовано;
· объёма ремонтов, которые потенциально должны случиться;
· объема замен там, где ремонт не будет успешным.
Прогнозирование параметров для расчёта зависит от конкретных условий по эксплуатации оборудования, технических политик эксплуатации оборудования персоналом, политик ИБ и других факторов, которые специфичны от заказчика к заказчику. Поэтому максимально точно рассчитать параметры для конкретного оператора связи можно и нужно с использованием актуальной статистики, которая уже отражает динамику происходящего на сети заказчика. Плюс статистика всегда хорошо раскрывает экспертную оценку этих же вопросов специалистами заказчика.
Для договоров технической поддержки и постгарантийного ремонта оборудования вендоров, с которыми у заказчика сохраняются отношения, важно избежать повторного бюджетирования работ в части 3-ей линии технической поддержки, замен или ремонтов. Поэтому обязательно укажите, если на 2-ю линию сдаётся комплексная сеть, в том числе оборудование с текущими контрактами на замену оборудования, на предоставление доступа к программному обеспечению. Партнёр по технической поддержке заложит использование существующих договоров и исключит свои затраты на данное направление работ.
4. Техподдержка неаварийных работ на сети
Тут мы просим указать, какого плана поддержка неаварийных работ нужна и как часто. Например, заказчик хочет раз в год планово обновлять программное обеспечение, и требуется присутствие эксперта с нашей стороны для консультации или иной помощи. Или необходима помощь в процессе модернизации оборудования, обычно тоже есть какой-то график или его видение на текущий год или календарный год вперед.
Бывают запросы на расширенную техническую поддержку, граничащую с эксплуатацией. Например, вводится в строй узел связи, на котором требуется установить определенное оборудование, или нужно подключить большее количество новых пользователей, добавить линейных карт и т.п. Внедрение каких-то дополнительных фич может влиять на работу оборудования другого вендора оборудования, и в этом случае тоже может потребоваться дополнительная консультационная поддержка или даже стейджинг.
Или, наоборот, требуется конкретный эксперт, который будет погружен в специфику дизайна и развития конкретной сети конкретного заказчика. Он должен оказывать техническую поддержку в случае сложных, системных кейсов, которые требуют изменения дизайна сети. Проводить выделенные воркшопы с эксплуатацией заказчика по данным проблемам. Руководить или лично проводить аудит сети, в том числе с оценкой производительности и мер отказоустойчивости. Регулярно выдавать рекомендации по улучшению эксплуатационных характеристик отдельных узлов и сетей связи целиком.
5. Обновление ПО на сетях заказчика
Специфика обновлений софта от производителей, прекративших поддержку оборудования на территории РФ, изменилась, и для уточнения стоимости постгарантийной поддержки требуется расширенная информация об используемом ПО.
Все помнят, как было раньше: после покупки оборудования производитель предоставлял доступ к порталу, где были выложены маркетинговые материалы, а также техническая документация и доступ к обновлениям ПО. Политика выдачи доступов разнилась от вендора к вендору – некоторые давали информацию только по приобретенному оборудованию. Другие давали доступ к базе данных по всей линейке оборудования без каких-либо ограничений, в особенности, если покупатель имел статус золотого партнера.
В реальности цепочка была куда сложнее: оборудование покупал не только конечный пользователь, но и дистрибьютор, реселлер, а иногда пользователи перепродавали свое железо. Так что контроль за доступами и раньше был не так прост, а сейчас все сильно усложнилось. По официальным каналам документацию не достать. Если такой канал удается получить, то он стоит конкретных денег, я бы даже сказал, что теперь это очень заметная статья расходного бюджета.
Для достижения лучшей цены проекта, заказчику нужно в первую очередь сформулировать, сколько раз в год ему нужно обновлять ПО и с какой целью. Возможно, есть сегменты, где это вообще не требуется. Такая информация позволит поставщику техподдержки серьезно оптимизировать бюджет в части затрат на поддержку софта. В качестве источников вдохновения для этой работы предлагаем использовать следующие факторы:
1. Специфические требования к ИБ при обновлении ПО.
Даже если ПО приобретено по легальным каналам, никто не может гарантировать отсутствие рисков в части ИБ в связи с местом производства софта (Индия, страны НАТО и пр.), ведь оно может быть подконтрольно недружественным странам.
2. Политика обновления ПО на сети: требования к регулярному обновлению ПО и сопровождению данных работ.
Раньше у всех операторов связи были определенные политики, которые регламентировали объем обновлений, например, в привязке к официальным релизам.
Сегодня слепое следование таким политикам – это дополнительные расходы. Например, мы часто видим на сетях заказчиков End-of-Support оборудование, с ПО версии на 1-3 ниже итогового GA релиза модели. Рекомендуем принять итоговое решение, обновится разово до финального или остаться на существующей версии, но не вносить в ТЗ общие туманные требования «поставки ПО по запросу», под которые исполнитель всегда закладывает худший для себя вариант развития событий.
Что касается сопровождения работ с ПО – также надо подумать, нужна ли только консультация или же непосредственный доступ к ПО и его установка, нужна ли работа с инцидентами по результатам установки нового ПО. Из этого пункта вытекает следующий.
3. SLA для работ c ПО оборудования.
Доступ к новому программному обеспечению теперь не просто ограничен, не только стал дороже, но еще и дольше. Даже при наличии бюджета сейчас это история, растянутая во времени – на получение нужного обновления может потребоваться до 1 месяца.
Это связано с необходимостью документального оформления, с представлением обоснований для доступа к ПО. Дополнительные данные может запросить вендор, у которого есть свой compliance.
Продолжение следует….
Автор: rostRTK
