Попробовать
демоверсию
Бесплатная демоверсия позволяет ознакомиться со всеми возможностями нашего биллинга
+7 499 940-95-05

Проблемы биллинга: Что может пойти не так с самописным софтом

Мы в «Латере» занимаемся разработкой биллинга для операторов связи (провайдеры проводного и беспроводного интернета, ТВ и телефонии, магистральные и спутниковые провайдеры) уже 8 тел, и за это время поучаствовали более чем в 80 проектах внедрения.

По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.

Напишем сами, будет лучше (на самом деле нет)

Главный аргумент сторонников самописных решений заключается в возможности полной адаптации к требованиям бизнеса. «Мы лучше знаем, что нужно компании» — типичный ход мыслей.

На коротком временном промежутке такой ход действительно может оправдать себя, однако затем начинаются проблемы. 

Очень сложно вносить изменения

При очередной смене широко применяемых технологий (например, переход с PPP на IPoE, внедрение BRAS) или появлении новых услуг, самописный биллинг, как правило, оказывается не готов к таким изменениям. Решение, которое разрабатывалось для работы в формате «здесь и сейчас», крайне сложно изменить. Все это приводит к снижению качества обслуживания абонентов и отставанию от конкурентов.

Технологичекий клубок

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

Софт устаревает и его так или иначе приходится заменять. Распутать же клубок из переплетенных между собой разных систем сложно. Заменять приходится либо все сразу и во всех основных подразделениях компании, что крайне болезненно, либо выводить из эксплуатации старое решение постепенно. Этот путь сопряжен с огромными затратами времени, сил и средств, да и не всегда возможен в принципе — например, если в заменяемой системе нет модульности или отсутствует API.

Костыли вечны

Часто выбор в пользу самописного софта делают компании, обладающие «нестандартными» бизнес-процессами. Проблема в том, что экзотика в итоге приводит к созданию костылей, которые остаются в системе на годы и затрудняют работу пользователей.

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

Что телать, если переезд назрел

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

Этот процесс можно сделать менее болезненным, если следовать нескольким простым рекомендациям: 

1. Прежде всего, не нужно тянуть с переходом. Чем дальше откладывается это решение, тем больше накопится труднорешаемых проблем.

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

3. Лучше мигрировать постепенно — это сложнее и дороже, однако позволит избежать сбоев и негатива, а репутация компании важнее денег.

4. Нельзя экономить на тестировании — следует уделить внимание воссозданию «боевых» условий на тестовых стендах. Например, крупных клиентов мы просим переключать нагрузку с реальной сети на тестовую инсталляцию биллинга на короткое время ночью.

5. Переехать самим невероятно сложно. Миграция на новый биллинг — трудоемкий проект, на выполнение которого мало у какой компании есть свободные человеческие ресурсы. Сотрудники заняты текущими задачами, поэтому лучше привлечь подрядчиков, которые уже провели много подобных внедрений.

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

Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!

28.08.2015

Другие публикации

По определению консалтинговой компании Deloitte, текущий период в мировой экономике характеризуется неопределенностью. Поэтому бизнес во всем мире стремится к оптимизации и снижению издержек. Сегодня мы рассмотрим несколько способов, с помощью которых компании из разных стран экономят уже сейчас.
В новой версии Гидры мы по традиции продолжили работу над коммерческими возможностями биллинга. Встречайте контрактные тарифы! Другие мелкие улучшения упрощают интеграцию Гидры с внешними системами.
Компании из самых разных отраслей бизнеса сталкиваются с часто повторяющимися бизнес-процессами, связанными с обработкой заявок. В большинстве отраслей выполнение типовых работ и услуг — это сложный и разветвленный бизнес-процесс. Мы много размышляли об этих проблемах и создали инструмент, который каждая компания могла бы легко адаптировать под себя — новый продукт Гидра OMS
В одном из наших постов мы уже описывали ситуацию, в которой бесконтрольный рост таблиц в базе данных одной компании-пользователя нашей системы привел к настоящему DoS. Сегодня речь пойдет о еще одном интересном случае внезапного сбоя, который сделал «день смеха» 1 апреля этого года совсем не смешным для службы поддержки «Латеры».
В Instagram развертывание backend-кода (основная программно-аппаратная часть, с которой работают клиенты) происходит от 30 до 50 раз в день, каждый раз, когда инженеры подтверждают изменение оригинала. И, по большей части, без участия человека — сложно в это поверить, особенно учитывая масштабы соцсети, но факт остается фактом.
В этой заметке речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2.
Интересный материал о работе с JSON, и в частности, о применении ограничений опубликовал в своем блоге разработчик Магнус Хагандер (Magnus Hagander) — в нашем блоге мы решили представить его основные идеи.
Успешно завершили интеграцию биллинга Гидра с порталом NEXT TV.
В этой заметке мы рассказываем о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки и делимся своим опытом.
Разработчики из американской компании Gaslight написали интересный материал о том, почему организация, известная своей любовью к Ruby и Ruby on Rails, решила инвестировать в освоение новых технологий — например, Clojure. Мы тоже работаем с этим языком программирования, поэтому решили выделить главные тезисы команды Gaslight в отдельный материал.
Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.
Немецкий журналист и хакер Ляйф Риге (Leif Ryge) написал для издания Ars Technica интересный материал о том, что современный подход к организации обновлений программного обеспечениях несет в себе серьезные риски информационной безопасности. Мы представляем вашему вниманию главные мысли этой заметки.
Инженер проекта Haleby.se написал материал, в котором рассказал о причинах выбора в качестве инструмента оркестрации Docker-контейнеров технологии Kubernetes. Мы представляем основные мысли этой заметки.
Адаптация заметки бывшего сотрудника Amazon про то, почему плохие продукты пользуются большим успехом, опубликованная в авторской колонке Дмитрия Копловича на Rusbase.
Поучительная история из жизни нашей техподдержки про то почему операторам нужно мониторить размеры таблиц в своих базах.
Инженер компании Akalak & Neo Technology Горка Садаковски (Gorka Sadakowski) написал интересный материал о том, как использование графовых баз данных может в режиме реального времени предотвращать мошенничество в сфере электронной коммерции. Мы представляем вашему вниманию основные мысли этой заметки.
Платежные протоколы уязвимы — об этом рассказали немецкие исследователи информационной безопасности на конференции Chaos Computing Club. Предлагаем вам адаптированный перевод их выступления.
Наша адаптация заметки разработчика и системного архитектора Михаэля Виттига о наиболее распространенных ошибках в использовании Amazon Web Services.
Наш адаптированный перевод заметки главного разработчика Azure Джеффа Уилкокса, о том, как более двух тысяч членов команды проекта переезжали на GitHub.
Представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.
Наш сегодняшний пост посвящен тому как мы писали софт для контроля работы удаленных сотрудников.
Сегодня мы расскажем про устройство системы подпольного банкинга Хавала, которая возникла еще в VIII веке и до сих пор пользуется большой популярности в странах Среднего Востока, Азии и Африки.
Мы уже рассказывали о том какие проблемы могут возникнуть у компании при саомостоятельной разработке сложных систем. Сегодня мы поговорим о том, как мы работали над повышением отказоустойчивости «Гидры».
Адаптированный перевод заметки главного инженера LinkedIn Джоша Клемма о процессе масштабирования инфраструктуры социальной сети.
Адаптированный перевод заметки инженера финансового стартапа Stripe о том, как его команда мигрировала огромное количество записей в базе данных.
Появились маркетинговые инструменты для сегментации абонентской базы, управления скидками и пакетными предложениями.
Подробнее читайте в блоге.
В новой версии мы полностью переработали механизм работы с услугами. Это сразу дало несколько серьезных улучшений, но полностью все заложенные в новой версии возможности будут раскрыты в следующих версиях.
В новой версии была полностью переработана система прав доступа. Новая система уникальна и позволяет реализовать самые смелые замыслы по разграничению доступа сотрудников к биллингу.

Начните знакомство с Гидрой прямо сейчас

Попробовать демоверсию Купить Гидру

Оформление демоверсии

Пожалуйста, укажите реальный email, на него придут данные для доступа в демо.
Все поля являются обязательными для заполнения.
.hydra-billing.com

Для вас будет развернута персональная облачная версия Гидры.
Нажимая кнопку "создать демоверсию" вы соглашаетесь с
Политикой обработки персональных данных.

Мы можем вам перезвонить

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Напишите нам!

Ваша компания

Услуги, которые вы предоставляете:

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Скачать буклет

Ваш адрес:

Хотите узнать больше?

Рассылка делается примерно раз в месяц. Мы обещаем бережно хранить ваш электронный адрес и никому его не выдавать даже под пытками.