Латера Софтвер corporate blog
28 August 2015

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



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

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

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


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

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

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


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

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


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

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

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


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

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

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


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

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

  • Прежде всего, не нужно тянуть с переходом. Чем дальше откладывается это решение, тем больше накопится труднорешаемых проблем.
  • При выборе серийного решения нужно смотреть не только на его текущую функциональность, но и узнать у создателей планы по развитию (правильные разработчики никогда не станут утаивать их).
  • Лучше мигрировать постепенно — это сложнее и дороже, однако позволит избежать сбоев и негатива, а репутация компании важнее денег.
  • Нельзя экономить на тестировании — следует уделить внимание воссозданию «боевых» условий на тестовых стендах. Например, крупных клиентов мы просим переключать нагрузку с реальной сети на тестовую инсталляцию биллинга на короткое время ночью.
  • Переехать самим невероятно сложно. Миграция на новый биллинг — трудоемкий проект, на выполнение которого мало у какой компании есть свободные человеческие ресурсы. Сотрудники заняты текущими задачами, поэтому лучше привлечь подрядчиков, которые уже провели много подобных внедрений.

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

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

+1
14.3k 51
Comments 108