Автор: Дмитрий Толоконников, бизнес-аналитик департамента ИТ-аутсорсинга ALP Group.
Техническая поддержка ИТ-продуктов — это важная для заказчика и необходимая для разработчика программного обеспечения деятельность, которая, если не допустить ошибок, может дать разработчику и его продуктам значительные конкурентные преимущества, особенно в эпоху импортозамещения, когда организации должны перейти на совершенно новое для большинства из них ПО. Конечно, только если такая техподдержка существует не на бумаге, а в реальности, и на самом деле позволяет заказчику, если случится ИТ-инцидент, получить быструю первую реакцию, а потом и гарантированное решение проблемы — как простой, так и самой сложной. Причем и то, и другое — в соответствии с SLA, в любой точке на карте страны.
Разумеется, такая техподдержка имеет свою специфику, глубоко отличную от разработки ПО, что делает ее непрофильной для компании-разработчика. Фактически это разные модели бизнеса — сервисная и продуктовая, и совместить их очень трудно, особенно если учесть, что компетенции, персонал, весь жизненный опыт компании-разработчика всегда значительно смещен в сторону процессов создания ПО, и попытка освоить новую область чревата многочисленными ошибками и набиванием шишек. Да и ресурсоемкость качественной техподдержки нельзя не учитывать. Именно поэтому сегодня ее выгодно отдать на аутсорсинг. Для нескольких передовых компаний-разработчиков отечественного ПО эта мысль уже стала привычной. Сегодня этот опыт исключительно важен для всего рынка отечественного ПО.
Традиционная схема
Часто разработанное нашими компаниями программное обеспечение для предприятий распространяется через партнеров-интеграторов, которые не только занимаются его внедрением у клиента, но и берут на себя первую и вторую линии поддержки. Такая схема неплохо зарекомендовала себя в прошлом — при неспешных темпах внедрений и возможности списывать сложные вопросы на западных вендоров, крупные международные ИТ-компании, которые, приняв заявку на устранение ошибки в своем ПО, могли держать ее в очереди годами. При этом участники рынка понимали: риски, действительно, лучше диверсифицировать, не складывая все яйца в одну корзину. А обязательные затраты на централизованное управление партнерами были практически нечувствительны для разработчиков.
Но времена изменились — на ИТ-рынке все чаще стали появляться проекты по внедрению российского ПО в государственных органах. В 2016 году — небольшие "пилоты" на несколько сотен рабочих мест, в 2017 году — проекты уже на 3-10 тыс. рабочих мест. И это только начало! То есть масштаб привлечения партнеров-интеграторов уже стал резко повышаться. При этом резко выросло число запросов на все линии техподдержки, а сложные запросы стало нельзя "отложить навсегда" — крупные заказчики не позволяют этого российским разработчикам. Последние уже не могут справляться с растущим и ожидаемым потоком внедрений силами двух-трех партнеров. Соответственно, для них становится нереально постоянно наращивать свою долю рынка: они просто этого не успевают.
Очевидное решение в таких случаях — расширение партнерской сети, однако сегодня оно приводит к столь же очевидным проблемам масштабирования привычной схемы "разработчик + партнеры-интеграторы". В результате вместо экономии времени и денег на поддержке разработчику приходится решать вопросы, связанные с управлением партнерами. Например, что-то делать с их незаинтересованностью в накоплении нужных компетенций по продуктам, с отсутствием единого уровня качества ИТ-обслуживания и т.д.
Есть ли иное решение, позволяющее нивелировать или обойти все эти и некоторые другие сложности?
Сложность первая: незаинтересованность в компетенциях
Российский разработчик, достигший статуса вендора, существенно уменьшает свои риски за счет того, что у него несколько партнеров-интеграторов на каждом направлении. Или в каждом городе. Но он же усложняет себе жизнь: ведь ему надо постоянно убеждаться в том, что компетенции каждого партнера соответствуют его требованиям. И что партнер действительно их наращивает.
Однако в подавляющем большинстве случаев этот статус российским разработчиком еще не достигнут. И когда сотрудники партнера-интегратора не знают продукт досконально, максимум, как они могут поступить в любой мало-мальски сложной ситуации — это попробовать сделать что-то простое в рамках своей компетенции или тех инструкций, которые у них есть, тут же завести заявку и перекинуть ее дальше, на 3-ю линию. То есть на самого разработчика. Таким образом терпит крах сама идея экономии за счет передачи поддержки на аутсорсинг такому партнеру, ведь вместо 5-10% всех запросов (при отлаженном разделении работ по линиям) разработчику приходиться решать собственными силами 50% и более заявок. А это означает неизбежную катастрофу, т.к. разработчик с этим потоком справиться никак не может.
Поэтому важно, чтобы интеграторы действительно считали сотрудничество ценным и постоянно растили свои кадры и их компетенции — причем не только по проприетарным продуктам (система сертификации у разработчика, обучение, карьерный рост).
Не каждый разработчик российского ПО может справиться с этими проблемами самостоятельно. Не каждый сможет выстроить единое понимание уровня качества у партнеров и управлять им, а также настроить процесс получения нормальной обратной связи или правильно спланировать обучение персонала. А когда становится понятно, что всю эту систему разработчику еще нужно распространить на отношения еще с десятком компаний-интеграторов, то надежда на успех и вовсе становится призрачной.
Сложность вторая: такое разное качество ИТ
Всех партнеров нужно приводить к единому представлению о качестве ИТ-обслуживания, то есть подписывать с каждым SLA (скажем, время решения — 8 часов и ни минутой больше). Это не всегда возможно. К тому же мало просто подписать с партнерами SLA, нужно иметь инструменты, чтобы постоянно контролировать фактические отклонения от параметров SLA — например, доступы ко всем Service Desk-системам, в которых работают партнеры… А теперь представьте объем требуемой при этом ручной работы и попрощайтесь с желанием сэкономить!
Более правильным решением будет хорошо организованная работа партнеров в собственной системе компании, являющейся "хозяйкой" партнерской сети. Но для разработчика ПО такая система — непрофильная: разработка и поддержка — разные процессы, ITSM-решение и issue-tracker — разные системы. И необходимость серьезно тратиться на ITSM-решение противоречит самой идее экономии за счет аутсорсинга техподдержки. Разработчикам этот путь невыгоден, ведь их главная задача — успеть захватить новую, перспективную нишу, а не выстраивать незнакомую систему, в которой обычно работают развитые сервисные компании.
Сложность третья: отсутствие обратной связи по продукту
Если нет централизованной системы и каждый партнер работает с программным продуктом самостоятельно — как правило, нет и нормальной обратной связи по продукту. Есть создатель продукта, есть партнеры-интеграторы, которые его поддерживают, и есть конечные пользователи, которые сначала контактируют с партнерами, высказывая недовольство продуктом или предложения по его улучшению им. И только потом эта информация, часто в искаженном виде, доходит до разработчиков ПО. Возможно, там не будет хватать главного: статистики по инцидентам и проблемам, указывающей, как именно стоит доработать ПО — какие функции убрать, какие добавить, по мнению большинства корпоративных пользователей.
Выходом, опять же, является работа в собственной продуманной системе, в которой есть место для всех трех сторон — вендора, интегратора/сервисной компании и представителя клиента. Тогда информация не искажается и, в конечном итоге, разработчик точно понимает, как пользователь воспринимает его продукт, что важнее доработать в первую очередь, а что — во вторую. Но для разработчика создание такой системы — очередные непрофильные расходы. Или снова трата драгоценных ресурсов, изъятие их из программ развития продуктовой линейки.
Как избавиться от сложностей
Одно из самых очевидных решений — выбор сервисной компании, которая сможет профессионально забрать на себя все непрофильные функции и при этом не подвести разработчиков, даже если поток запросов в один прекрасный момент вырастет сразу в десятки раз. Но по каким критериям выбирать такую компанию? Что она должна уметь?
Управлять качеством ИТ-обслуживания. Сервисная компания должна иметь выстроенные не только базовые (управление запросами, обращениями), но и высокоуровневые ИТ-процессы (управление проблемами, сервисом, ИТ-активами и пр.). Эти процессы должны работать и у компаний, входящих в региональную партнерскую сеть провайдера ИТ-услуг — базовые у всех, а высокоуровневые — хотя бы у 30-40%. Структура линий техподдержки тоже должна быть выстроена правильно: на 1-й линии должны работать только недорогие специалисты, быстро и четко отвечающие на вопросы: "Почему ПО не работает так, как гарантировал вендор?". Или: "Есть ли у программного обеспечения такая-то функция и где ее искать?" На 2-й линии более дорогие и компетентные специалисты работают с более сложными вопросами: "Почему ПО не работает после того, как мы сделали все, что нам рекомендовали?". И только на 3-й линии должны быть задействованы сотрудники разработчика, способные решить 5-10% вопросов, действительно требующих глубинного знания продукта и возможности внести в него изменения.
Приводить большинство партнеров к единому представлению о качестве оказываемого ИТ-обслуживания. Подписать с каждым партнером внутренние соглашения (OLA) и выровнять их с клиентскими соглашениями на конкретных проектах (SLA).
Использовать современные сервисные инструменты, чтобы контролировать SLA и давать обратную связь по продуктам. У разработчиков таких ITSM-инструментов, скорее всего, может и не быть, а зрелая сервисная компания должна пользоваться ими ежедневно в интересах клиентов, чтобы понимать, например, каков процент "выпадения" из SLA ("просрочек") у каждого заказчика, что из полученных ИТ-инцидентов действительно относится к неработающему ПО (bug-reports), что — к неправильному использованию программ, сколько времени ушло на устранение каждого инцидента, какие "поломки" менее, а какие более критичны (по мнению пользователей программного обеспечения). Вся эта статистика достаточно точно отражает впечатление людей от продукта и показывает, что им в ПО понятно и удобно, а что нет, какие функции для них важны в повседневной работе, а какие — не очень. В конечном итоге именно эти, полученные и правильно проанализированные данные, помогают разработчикам оптимально спланировать развитие своего продукта.
Выстроить взаимодействие с разработчиками системообразующего ПО. Речь о модели, не встречавшейся на нашем ИТ-рынке в прошлом, но набирающей обороты сегодня — когда одна сервисная компания поддерживает сразу нескольких компаний-разработчиков, продукты которых формируют стек системообразующего ПО, и создает у себя пул соответствующих компетенций, например, в области импортозамещающего ПО. Пример такого стека: первая российская операционная система уровня предприятия (ОС АЛЬТ компании "Базальт СПО"), ведущая СУБД для использования в высоконагруженных ИТ-системах и в критически важных приложениях (Postgres Pro компании Postgres Professional), ряд отечественных СЭД. При этом весь стек продуктов обслуживается как одно целое: работает принцип одного окна, время реакции и решения проблем фиксируется в SLA и может описываться единым сервисным контрактом. Передача заявок между треми линиями техподдержки продуктов разных разработчиков происходит автоматически (под контролем сервисной компании).
Преимущества нового подхода
Такое попадание в общий "периметр техподдержки" дает разработчикам два принципиально важных конкурентных преимущества, которые нельзя получить иным путем:
Во-первых, доступ к компетенциям техподдержки не только по своему продукту, но и по продуктам, от которых зависит успешная работа приложения, например, ОС и СУБД. Это позволяет гарантировать, что разработчику будут отправляться запросы, только связанные с работой именно его приложения.
Во-вторых, постоянный арбитраж, который поможет точно отследить, на стороне какого вендора находится каждая конкретная проблема, и не даст "свалиться в футбол" (перебрасывание пользователя от одного разработчика к другому), что крайне мучительно для пользователя и, в конечном итоге, негативно влияет на лояльность заказчиков и на репутацию продукта.
Подведем итоги
Техническая поддержка ПО — хотя и непрофильная, но важнейшая функция, по мнению большинства российских разработчиков. При этом мало кто из них, в силу объективных причин, серьезно задумывается о ее качестве (которое складывается из качества работы каждого партнера и умения централизованно управлять ими) и влиянии на имидж продукта, и уже умеет или знает, как быстро создать целостную систему такой поддержки, насытить ее компетенциями и обеспечить быструю масштабируемость в условиях острого дефицита компетенций и кадрового голода.
Между тем в новой, масштабной нише импортозамещения допускать "просаживание" качества ИТ-поддержки (и, соответственно, снижения репутации продукта) на больших масштабах внедрений нельзя — это почти гарантированно лишает компанию-разработчика притока новых клиентов. А именно так бывает, когда качеством поддержки никто не управляет. Если же управление ведется разработчиком самостоятельно, то оно требует неизменно больших затрат времени, средств и ресурсов, а на построение всей системы уходит несколько лет интенсивной работы. Это по силам далеко не каждому разработчику российского ПО. Вариант же, когда контроль над качеством ИТ-поддержки (и сама ИТ-поддержка) передается на аутсорсинг, требует намного меньших вложений, и связан с гораздо меньшими рисками.