Мы в «Латере» занимаемся разработкой биллинга для операторов связи (провайдеры проводного и беспроводного интернета, ТВ и телефонии, магистральные и спутниковые провайдеры) уже 8 лет, и за это время поучаствовали более чем в 80 проектах внедрения.
По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.
Напишем сами, будет лучше (на самом деле нет)
Главный аргумент сторонников самописных решений заключается в возможности полной адаптации к требованиям бизнеса. «Мы лучше знаем, что нужно компании» — типичный ход мыслей.
На коротком временном промежутке такой ход действительно может оправдать себя, однако затем начинаются проблемы.
Очень сложно вносить изменения
При очередной смене широко применяемых технологий (например, переход с PPP на IPoE, внедрение BRAS) или появлении новых услуг, самописный биллинг, как правило, оказывается не готов к таким изменениям. Решение, которое разрабатывалось для работы в формате «здесь и сейчас», крайне сложно изменить. Все это приводит к снижению качества обслуживания абонентов и отставанию от конкурентов.
Технологический клубок
Программные решения собственной разработки часто бывают монолитными — это значит, что помимо собственно биллинга, в них может присутствовать и функциональность CRM, хелдпеск, система активации новых абонентов и даже инструмент для планирования монтажных работ.
Софт устаревает и его так или иначе приходится заменять. Распутать же клубок из переплетенных между собой разных систем сложно. Заменять приходится либо все сразу и во всех основных подразделениях компании, что крайне болезненно, либо выводить из эксплуатации старое решение постепенно. Этот путь сопряжен с огромными затратами времени, сил и средств, да и не всегда возможен в принципе — например, если в заменяемой системе нет модульности или отсутствует API.
Костыли вечны
Часто выбор в пользу самописного софта делают компании, обладающие «нестандартными» бизнес-процессами. Проблема в том, что экзотика в итоге приводит к созданию костылей, которые остаются в системе на годы и затрудняют работу пользователей.
Разработчики же серийных продуктов не могут себе позволить никакой экзотики, поскольку их решениями пользуются многие компании. Это значит, что они более предсказуемы и понятны для пользователей.
Что делать, если переезд назрел
Собственные разработчики — это дорого, а их наличие не гарантирует успеха (что иллюстрируют описанные выше проблемы). Поэтому все больше компаний задумываются о переходе на серийный биллинг.
Этот процесс можно сделать менее болезненным, если следовать нескольким простым рекомендациям:
- Прежде всего, не нужно тянуть с переходом. Чем дальше откладывается это решение, тем больше накопится труднорешаемых проблем.
- При выборе серийного решения нужно смотреть не только на его текущую функциональность, но и узнать у создателей планы по развитию (правильные разработчики никогда не станут утаивать их).
- Лучше мигрировать постепенно — это сложнее и дороже, однако позволит избежать сбоев и негатива, а репутация компании важнее денег.
- Нельзя экономить на тестировании — следует уделить внимание воссозданию «боевых» условий на тестовых стендах. Например, крупных клиентов мы просим переключать нагрузку с реальной сети на тестовую инсталляцию биллинга на короткое время ночью.
- Переехать самим невероятно сложно. Миграция на новый биллинг — трудоемкий проект, на выполнение которого мало у какой компании есть свободные человеческие ресурсы. Сотрудники заняты текущими задачами, поэтому лучше привлечь подрядчиков, которые уже провели много подобных внедрений.
На сегодня все, спасибо за внимание. В следующем топике мы расскажем о том, как занимались работами по повышению отказоустойчивости нашей системы.
Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!
