3PM
3rd Parties Software Maintenance Support
Альтернативная техническая поддержка

Экономическая целесообразность

Идея альтернативной технической поддержки ПО выросла из концепции Software Asset Management (SAM), которая появилась в конце 1990-х и оформилась в международный стандарт ISO/IEC 19770 Software Asset Management (SAM) в 2006 году. Нет нужды доказывать, что целостное управление приобретенными правами на ПО (лицензиями) имеет большую ценность для крупных и средних компаний, иначе бы данный сегмент корпоративного ПО и услуг по его настройке не развивался столь значительными темпами и в России и в мире. Все большее распространение получает борьба с так называемым shelfware (приобретенное, но неиспользуемое ПО, за которое приходится платить техническую поддержку, дословно "полочное ПО").

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

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

Как правило, поддержка текущей версии ПО, например ERP-системы, сводится к следующим основным пунктам:

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

К 2017 году на западе прошло несколько громких дел, когда антимонопольные службы в рамках или отдельно от исков заказчиков возбуждали расследования о правомерности поставщиков ПО требовать полную оплату за техническое сопровождение приобретенного ПО для случаев, когда заказчику требуется только услуга сопровождения текущей версии. То есть, по сути, речь шла о возможности приобретения услуги технической поддержки и права на обновления версии раздельно, а именно отдельно технической поддержки существующей версии и отдельно права на обновления версии. При этом всплыло много интересных вопросов, к примеру: считать ли вскрывшуюся уязвимость ПО и патч на его устранение обновлением или устранением скрытого дефекта продукта, устранять которые производитель неважно чего обязан бесплатно. Данный вопрос был решен в пользу заказчиков ПО и обязывал поставщиков ПО устранять скрытые дефекты, т.е. обеспечивать заказчиков, которые не находятся на технической поддержке, доступом к заплатам, необходимым для безопасности системы. Также в ряде случаев поставщиков ПО обязывали предусмотреть возможность продажи услуг технической поддержки и прав на обновление версии раздельно. Самое интересное для многих пользователей ПО, в том числе и в России, вопрос состоит в том, что:
Как DevOps-сервис помогает «разгрузить» высоконагруженные системы BPMSoft 2.2 т А) не все про это знают,
Б) не все это используют на практике в тех случаях, когда это имело бы смысл использовать,
В) конечные пользователи ПО соглашаются в рамках подписания типовых контрактов приобретения прав на ПО на условия, прямо противоречащие указанным положениям.

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

Зачастую разработчики/поставщики ПО вписывают в контракты на поставку ПО с конечными заказчиками условие, что конечный заказчик не имеет права отказаться от технической поддержки на часть приобретенного ПО, а только на весь пакет, что вынуждает заказчика продолжать платить за весь пакет приобретенного ПО. Что не совсем справедливо и признано в ряде стран незаконным. В итоге заказчик, который не планировал развивать и обновлять используемую версию ПО, зачастую сталкивается перед выбором: или полностью платить требуемый поставщиком ПО ежегодный платеж или полностью отказываться от технической поддержки и по факту иметь риск остановки или некорректной работы конкретного приложения. Альтернативой данной истории с необходимостью или платить полный платеж или отказываться от официальной технической поддержки вендора является примитивное воровство. Это может быть незаконное скачивание или приобретение необходимых патчей и обновлений конкретными сотрудниками служб эксплуатации/сопровождения ПО, что во многих случаях имеет место и в нашей стране, но особо никем не афишируется: заказчиком понятно по какой причине, а конкретным поставщиком ПО – по имиджевым причинам. Рынку не обязательно знать, что кто-то из заказчиков конкретного вендора отказался от официальной технической поддержки.

Результатом данных процессов стало появление ниши услуг альтернативной технической поддержки, которая была бы приемлемого уровня по цене и качеству для клиента и позволяла заменить официальную техническую поддержку вендора. Данная ниша, а именно рынок 3rd parties software maintenance support (или 3PM) является одним из нескольких самых быстрорастущих сегментов рынка ИТ-услуг и приложений для бизнеса. Согласно Gartner «К 2020 году до 10% предприятий, имеющих стратегию цифровой трансформации, будут использовать специализированных провайдеров технической поддержки 3ей линии ERP-систем и сокращая затраты не менее чем на 50% ежегодно» (данные на 2017 г).

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

Основная причина перехода на альтернативную техническую поддержку ПО – экономическая. Служба CFO не готова ежегодно платить в среднем 20%-25% от стоимости ПО, которое не планируется развивать. Это просто здравый смысл. Что в этом случае делать службе ИТ, чтобы гарантировать корректную работу выводимого с поддержки ПО? Или решать вопрос неофициально со всеми рисками и вытекающими последствиями, или искать альтернативного поставщика услуг 3PM.

Список платформ, поддерживаемых поставщиками альтернативной технической поддержки, достаточно обширен: Microsoft SQL, SAP Business Suite, SAP HANA DB, Oracle DB, Oracle Hyperion, Oracle Siebel, Oracle JDEdwards, PeopleSoft, Oracle Fusion Middleware. В целом список поддерживаемых, в том числе на рынках вне США платформ частично пересекается с бизнес приложениями и базами данных, используемыми заказчиками в России и странах СНГ.

Этапы перехода на 3PM

Конечно вопрос отказа (если компания еще не отказалась) от официальной технической поддержки ПО от вендора - очень серьезный вопрос, который требует четкого согласования на всех уровнях: от финансовой службы, которая в основном и является ее инициатором, до службы эксплуатации ПО. Согласно Gartner, на 2017 год количество компаний отказавшихся от продления услуги технической поддержки составляет от 5 до 10% от совокупной базы инсталляций. Возникает много вопросов:

• какие возможности у 3РМ провайдера, чтобы обеспечить своевременное закрытие тикетов по задачам соответствия изменяющемуся локальному законодательству,
• как осуществляется разработка патчей,
• какие возможности остаются у заказчика после отказа от официальной технической поддержки от поставщика ПО, от чего будет отрезан доступ.

Активность по тестированию качества услуг поставщика 3РМ и отказ от официальной технической поддержки достаточно продолжительный процесс, который можно разбить на несколько крупных этапов:

Определение целесообразности перехода на альтернативную техническую поддержку к независимому провайдеру. Здесь основным триггером является понимание стратегии использования существующего ПО. Очевидно, что для компаний, которые декларируют политику импортозамещения или планируют заместить импортные платформы отечественными решениям имеет смысл проработать стратегию перехода и оптимизировать затраты на сопровождение выводимого из эксплуатации ПО. В том числе с помощью 3PM провайдера, другой причиной является плановая замена или миграция на альтернативное ПО или отсутствие целесообразности развивать и обновлять ПО.

Подписание NDA между заказчиком и 3PM провайдером, передача информации о специфике используемых приложений, стратегии их эксплуатации на среднесрочный период, определение потребностей и режима оказания услуг. Получение ТКП на обслуживание в рамках согласованного SLA . Сравнение стоимости и качества услуги с текущей услугой, которую оказывает конкретный вендор ПО;

Решение тестовых тикетов или подписание договора на пробный период (как правило, квартал), в течение которого тестируется услуга;

Принятие решение об отказе от официальной технической поддержки вендора и переход на услуги альтернативной технической поддержки 3РМ-провайдера

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

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

Один из практических бизнес кейсов, где может быть востребована данная услуга – история с SAP HANA. После выхода данного решения, разработчик ПО, объявил, что вся новая функциональность будет добавляться в основном в версии S4Hana, а существующие решения (SAP ERP) будут только поддерживаться, поэтому заказчикам рекомендуется мигрировать на S4HANA. Однако, многие заказчики, использующие приложения SAP ERP и в России и в мире, не планируют отказываться от существующей системы и мигрировать на SAP HANA. По разным причинам. У кого-то нет бюджета, у кого то идут другие важные проекты, завязанные на текущую функциональность, кто-то просто не готов развивать продукт. Переходить на новую версию платформы просто потому, что так рекомендовал вендор или потому в новом продукте появилась новая улучшенная возможность обработки отчетов (чтобы воспользоваться которой, надо вложить еще почти столько же инвестиций, сколько уже потрачено). Это элементарный здравый смысл. Согласно отчету 2016 года от компании Nucleus Research, «9 из 10 заказчиков SAP не планируют переходить на S4HANA». Получается, если заказчик не планирует обновлять версию, ему достаточно текущей версии и тогда встает вопрос: за что платить требуемую ежегодно сумму, только за патчи и обновления текущей версии? Это дорого и несправедливо. Оптимальнее рассмотреть имеющиеся альтернативы: или вообще отказаться от технической поддержки или перейти на поддержку к специализированному 3РМ-провайдеру. ^[1]

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

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

Примечания