Как там биллинг делается: когда заказчик и разработчик говорят на разных языках
С 2006 года мы занимаемся биллинговыми системами. В общей сложности — более 12 лет. Начинали работать с телевизионного рынка, сейчас среди наших клиентов есть и банки, и сотовые операторы, и провайдеры интернет-телевидения. Сама биллинговая система эволюционировала от более или менее простого решения для телевидения до полноценного конвергентного биллинга с возможностью применения препейдной схемы. А мы за это время успели набить множество шишек как по части внедрения, так и поддержки биллинга. Часто ошибки происходят оттого, что заказчик не знает “матчасть”, а разработчики биллинга не понимают опасений и потребностей клиента.
Биллинг — не просто калькулятор
Биллинговые системы давно не просто ведут баланс клиента и выставляют счета. Они глубоко интегрированы в бизнес: обеспечивают контроль трафика, управляют процедурой предоставления доступа к услугам, предоставляют клиенту отчет о расходах в разных разрезах — за месяц, за год, с момента последнего платежа. Плюс биллинговая система, как правило, должна поддерживать множество балансов пользователя: монетарный и несколько вещественных (бонусы, минуты разговора, гигабайты трафика и т.д.). Не говоря уже о партнерских программах и прочих вариантах кросс-продаж. То, что называется современный конвергентный биллинг. Реализуется он за счет интеграции тарификатора с другими модулями и подсистемами: CRM, PRM, BPM и т.д. Для разработчиков это не “сокровенное” знание. Как говорится, разделяй функции и властвуй. Но для пользователей биллинга, даже технически грамотных, мысль, что с “калькулятором” сложновато общаться напрямую, порой оказывается новой.
Пример из нашей практики. Клиент — небольшая, но перспективная компания. У них не хватало бюджета на биллинговый комплекс целиком, они попросили убрать модуль BPM (business process management). Нужно отдать должное, там работали достаточно продвинутые в техническом смысле ребята. Сказали, возьмут open source решение, настроят, интегрируют с системой. Мы согласились. А через четыре месяца “утонули” в их обращениях в техподдержку по поводу некорректных данных.
BPM — система, которая, помимо прочего, при подключении абонента занимается валидацией данных, и не пропускает тебя на следующий шаг, пока ты не заполнишь все необходимые параметры — технические и персональные. А они от BPM отказались, и нарисовали просто интерфейс для ввода данных. Люди, которые принимают заявки на подключение — не высокооплачиваемые специалисты, там большая текучка, малое время обучения персонала. Естественно они постоянно делали ошибки при внесении данных. Итог — в конце месяца компания выставляет счета, а тарификатору не хватает параметров. Он “ругается”, выдает сообщения об ошибках. Клиент звонит в поддержку. В конце концов, мы приняли решение подарить им BPM в дефолтных настройках. У них все стало сходиться, а у нашей техподдержки стало меньше головной боли. Теперь мы вообще не продаем биллинг без BPM, кроме случаев если он уже внедрен и есть варианты интеграции с ним. Если у клиента не хватает денег на минимально необходимый комплект, предлагаем аренду или аренду с возможностью выкупа через пять лет. Или, если это какой-то стартап, но видно, что люди серьезно относятся к делу и у них есть перспективы, предлагаем схему ревенью. В любом случае это бережет нервные клетки и нам, и руководству компании-клиента.
Гибкость — понятие растяжимое
Непродуманная архитектура биллинговой системы оборачивается не только техническими сбоями. По нашему опыту, в 70% случаев необходимость замены биллинга возникает из-за недостаточной ее маркетинговой гибкости. Телеком-рынок сейчас перенасыщен, и заполучить себе новых клиентов компании могут, только отбив их у конкурентов. Даже крупные провайдеры, осваивая новые ниши и расширяя территорию присутствия, начинают демпинговать, а уж новым игрокам на рынке “сам бог велел” привлекать к себе внимание уникальными предложениями. Разворачивается настоящая война тарифов. И тут уже маркетологи хватаются за голову: “Мы сможем вывести в продажи ваш новый инновационный тариф “Супер-Новогодний” только к июлю”, — приходит сообщение от IT-отдела.
В чем проблема. В очень небольшом числе биллинговых систем есть, например, отдельный модуль продакт-каталог, который позволяет легко комбинировать услуги в пакеты и настраивать акции. Параметры которыми он оперирует могут быть как услуги так и отдельные параметры такие как минуты разговора, пакеты трафика или услуги предлагаемые партнерами(так называемые услуги третьих лиц), например билеты в кино или поездки на такси. Есть мнение, что продакт-каталог — это вообще элемент CRM-системы, а не биллинга. Но да будь оно даже так, не во всех компаниях есть отдельная CRM. Многие обслуживание абонентов ведут прямо в биллинговой системе. А это значит, любая новая услуга, новый тариф, новая акция — и “айтишникам” нужно не собрать ее в конструкторе, а добавлять поля и писать строчки кода. Вот уже и июль не за горами.
Правда, маркетологи обычно не понимают, что имеет в виду вендор, говоря, что его система “достаточно гибкая”. Достаточно для чего? “Комерсантов” в первую очередь интересует time-to-market, время, необходимое, чтобы выпустить услугу на рынок. Однажды представители клиента — регионального оператора, в чей регион пришла федеральные игроки — прямо на презентационную встречу принесли нам описания 3 кейсов конкурентов которые они не смогли реализовать у себя. Поставили вопрос ребром: за какой срок сможете настроить в вашей системе? Не грех похвалиться — один кейс в тестовой среде мы настроили прямо при них, пока шла презентация. Вообще, при продуманной архитектуре биллинга любой и использовании продукт -каталога любой пакет или акцию можно настроить и вывести на рынок за 2-3 дня, не считая времени маркетингового и функционального тестирования. Проверять, может ли это конкретный биллинг, лучше еще на этапе знакомства. Потому что нередки случаи, когда настройка нового тарифа в “достаточно гибкой” системе на самом деле занимает несколько месяцев.
Между централизацией и автономией
С подобными проблемами в плане маркетинга и продаж сталкиваются и крупные компании, разросшиеся за счет поглощения региональных операторов. Разные биллинговые системы в филиалах не позволяют, например, запускать масштабные акции сразу по всей стране. Страдает отчетность и аналитика: собрать данные по подключениям и пользованию услугами со всех этих разрозненных систем просто невозможно. Частичное решение проблемы — зонтичная CRM, в которой есть продакт-каталог. Некоторые компании так и поступают — торгуют из CRM, а тарифицируют в биллинге. Для этого в компании должен быть действительно продвинутый IT-отдел. Интегрировать написанные на разных языках и по разным принципам биллинговые системы с единой CRM — непростая задача.
Но есть одно извечная проблема, которую распределенные системы решить не в силах — это банальный фрод на местах. У нас было несколько таких примеров. В частности на Украине, где мы внедряли централизованный биллинг, перенося данные из недавно приобретенных региональных филиалов. Когда мы мигрируем данные, мы делаем ряд проверок и сравнений, все несоответствия попадают в соответствующие отчеты, и после этого обычно начинает шевелиться служба безопасности компании-заказчика. Чего там только не находится. Абоненты, подключенные мимо учетных систем, “нулевые” тарифные планы и т.д… Было и откровенное мошенничество: компанию продали, а квитанции абонентам еще какое-то время выставляли на левые реквизиты.
Организация единого расчетного центра делает все такие ситуации прозрачными, в регионах остается только функция абонентского информационного обслуживания поэтому возможности для фрода практически не остается. Плюс большая клиентская база, сведенная в единую систему, позволяет на совершенно ином уровне анализировать и прогнозировать поведение клиентов. Мы постепенно начинаем применять к таким большим данным наши системы аналитики построенные на машинном обучении. Например, можем выделить в клиентской базе “группы риска” — тех, кто в ближайшее время может отказаться от услуг компании. Это выявляется по тому, как люди платят, как они пользуются сервисами, личным кабинетом, как общаются с колл-центром, сколько и по каким причинам у них блокировой.
Правда, централизация биллинга приносит с собой другие проблемы. Нужно, чтобы региональные филиалы сохраняли долю технической независимости. Иначе, если вдруг центральный расчетный центр окажется “вне зоны доступа”, обслуживание абонентов в регионе может пострадать. Мы ее решаем за счет “выносов” на периферию: серверов авторизации, элементов сбора и обработки трафика, элементов сервис-провижининга. В частности для мобильных операторов наша препейдная платформа(Forward Fusion) может тарифицировать услуги автономно и ждать, когда восстановится связь, чтобы синхронизировать данные с биллинговым центром. Региональные абоненты при этом могут заметить, что стал недоступен личный кабинет, но деградации предоставляемого сервиса при этом не происходит.
Сервер, который поставил Джек: где хранятся данные?
Есть много вариантов, как и где разместить биллинговую систему. Часто компании переживают за сохранность данных клиентов, сами покупают сервера и ставят в своем дата-центре. Но не все могут потянуть их качественное обслуживание. Иногда у клиента что-то сломалось, а он даже не понимает, что это на его стороне. Звонит нам в техподдержку, и уже наши админы ему рассказывают, где поломка, какой сервер не отвечает. У нас система настроена так, что она постоянно “мониторит” по многим параметрам обслуживаемые системы, и поднимает тревогу, если что-то не так. Так что мы заранее можем сообщить, что кончается память или скорость какого либо важного процесса снизилась ниже нормы. Но это к сожалению не отменяет форс-мажоров.
Другой вариант — когда клиент размещаться хочет у себя, а мы поставляем программно-аппаратный комплекс, это делается когда клиент хочет чтобы мы програрантировали ему определенную производительность по критическим для него сервисам. В таком случае в стоимость “железа” сразу закладывается стоимость его трехлетней поддержки от производителя. Тогда оно держат запасные комплектующие и если что-то ломается, то их специалисты выезжают на место с запчастями в течение суток и ликвидируют поломку.
Бываю ситуации когда наоборот, привозят свои сервера и ставят в наш сертифицированный по Tier III дата-центр.
Еще один распространенный вариант — у нас арендуют вообще все. Тогда мы полностью отвечаем и за “железо” — и за обслуживание, и за то, чтобы вовремя увеличивать необходимые мощности. По этой причине в определенный момент мы стали использовать частные облака. Если у нас выросла нагрузка, мы меняем настройки, и нам выделяются дополнительные вычислительные мощности. Не нужно бесконечно заниматься непрофильным для нас “апгрейдом” оборудования. Российские компании, которые сегодня предлагают услуги публичного облака, к большому нашему сожалению пока не могут предоставить тот уровень гарантированной производительности, которого требует биллинговая система. У них можно хостить сайты, можно разворачивать интернет-магазины или поставить 1С. Поэтому нам пока приходится активно участвовать оптимизации и тестировании решения для различных частных облаков, например недавно начали использовать OpenStack.
Базы данных: важно не только где, но и как
Важность выбора базы данных для биллинга сложно переоценить. Высокой производительности тут можно добиться, только оптимизировав биллинговую систему под конкретный продукт. Forward Billing оптимизирован под работу с двумя СУБД: Oracle Database и PostgreSQL). В прошлом году Forward Billing был включен в реестр российского ПО, разрешенного для использования в государственных компаниях. И вот недавно пришла новость, что через полгода из реестра начнут исключать разработки на базе иностранных СУБД. С точки зрения государства, это понятно. В условиях, когда чуть не каждый день под санкции попадают все новые российские компании, им хочется обеспечить полную независимость российского ПО. Но для вендоров это грозит приличными дополнительными затратами. Думаю в этом вопросе мы как и весь остальной рынок ждем от законодателей более четких разъяснений на этот счет и после этого будем корректировать свою стратегию.
SLA: определитесь с приоритетами
Где-то в идеальном мире уровень техподдержки от поставщика определяет четко прописанное SLA — Service Level Agreement, оно же Соглашение об уровне оказания услуг. Чем SLA отличается от просто договора, где фиксируются положенные клиенту часы поддержки? В нем прописаны конкретные требования к сервисному обслуживанию: скорость приема заявки, время решения проблемы — и система штрафов, которые накладываются на поставщика, если требования не соблюдены.
Как показывает практика, чтобы SLA стал эффективным инструментом регулирования отношений между заказчиком и поставщиком, заказчику придется провести некоторую аналитическую работу. Нужно понять, как инциденты будут критическими для конкретного бизнеса, а какие не стоят того, чтоб паниковать. Большинство наших клиентов так или иначе используют наши базовые SLA многократно проверенные и на наш взгляд являющимися оптимальными.
Часть сталкиваемся с тем, что небольшие компании, которые приобретают готовые “коробочные” решения для биллинга в случае возникновения проблем оказываются 376-ми в очереди на техподдержку. Часто для таких компаний более оперативной оказывается помощь сообщества пользователей этого продукта на интернет-форуме.
Случаются, правда, и другие крайности. Один потенциальный заказчик, небольшой виртуальный мобильный оператор, пришел к нам как раз после того, как сильно “обжегся” с поддержкой биллинговой системы. В результате этот клиент предложил нам “сумасшедший” SLA, умножив наши стандартные требования по срокам реагирования и штрафам чуть ли ни в сто раз. Нам к сожалению не удалось его переубедить и он продолжает обслуживать своих абонентов на свой страх и риск.