С 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 — Service Level Agreement, оно же Соглашение об уровне оказания услуг. Чем SLA отличается от просто договора, где фиксируются положенные клиенту часы поддержки? В нем прописаны конкретные требования к сервисному обслуживанию: скорость приема заявки, время решения проблемы — и система штрафов, которые накладываются на поставщика, если требования не соблюдены.
Как показывает практика, чтобы SLA стал эффективным инструментом регулирования отношений между заказчиком и поставщиком, заказчику придется провести некоторую аналитическую работу. Нужно понять, как инциденты будут критическими для конкретного бизнеса, а какие не стоят того, чтоб паниковать. Большинство наших клиентов так или иначе используют наши базовые SLA многократно проверенные и на наш взгляд являющимися оптимальными.
Часть сталкиваемся с тем, что небольшие компании, которые приобретают готовые “коробочные” решения для биллинга в случае возникновения проблем оказываются 376-ми в очереди на техподдержку. Часто для таких компаний более оперативной оказывается помощь сообщества пользователей этого продукта на интернет-форуме.
Случаются, правда, и другие крайности. Один потенциальный заказчик, небольшой виртуальный мобильный оператор, пришел к нам как раз после того, как сильно “обжегся” с поддержкой биллинговой системы. В результате этот клиент предложил нам “сумасшедший” SLA, умножив наши стандартные требования по срокам реагирования и штрафам чуть ли ни в сто раз. Нам к сожалению не удалось его переубедить и он продолжает обслуживать своих абонентов на свой страх и риск.
Биллинг — не просто калькулятор
Биллинговые системы давно не просто ведут баланс клиента и выставляют счета. Они глубоко интегрированы в бизнес: обеспечивают контроль трафика, управляют процедурой предоставления доступа к услугам, предоставляют клиенту отчет о расходах в разных разрезах — за месяц, за год, с момента последнего платежа. Плюс биллинговая система, как правило, должна поддерживать множество балансов пользователя: монетарный и несколько вещественных (бонусы, минуты разговора, гигабайты трафика и т.д.). Не говоря уже о партнерских программах и прочих вариантах кросс-продаж. То, что называется современный конвергентный биллинг. Реализуется он за счет интеграции тарификатора с другими модулями и подсистемами: 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, умножив наши стандартные требования по срокам реагирования и штрафам чуть ли ни в сто раз. Нам к сожалению не удалось его переубедить и он продолжает обслуживать своих абонентов на свой страх и риск.
