Billing issues: What can go wrong with self-written software?

We in Latera have been developing billing for telecom operators (providers of wired and wireless Internet, TV and telephony, main and satellite providers) for 8 years already, and during this time have participated in more than 80 implementation projects.

According to our estimates, about half of Russian telecom operators use self-written (or rewritten to unrecognizable simple “purchased”) software. Today we will talk about the possible disadvantages of this approach.
')

We will write it ourselves, it will be better (actually not)

The main argument of supporters of self-written solutions is the ability to fully adapt to the requirements of the business. “We know better what a company needs” - a typical train of thought.

In a short time span, such a move can really justify itself, but then problems begin.

It is very difficult to make changes

With the next change of widely used technologies (for example, transition from PPP to IPoE, introduction of BRAS) or the emergence of new services, samopisny billing, as a rule, is not ready for such changes. The solution that was developed to work in the “here and now” format is extremely difficult to change. All this leads to a decrease in the quality of customer service and lagging behind competitors.

Technology ball

Self-developed software solutions are often monolithic, which means that in addition to the billing itself, they may also include CRM functionality, helpdesk, a system for activating new subscribers, and even a tool for installation planning.

The software becomes outdated and one way or another it is necessary to replace it. Unravel the tangle of intertwined different systems is difficult. It is necessary to replace either all at once and in all main divisions of the company, which is extremely painful, or to decommission the old solution gradually. This way is associated with a huge investment of time, effort and money, and it is not always possible in principle - for example, if there is no modularity in the replaced system or there is no API.

Crutches forever

Often the choice in favor of samopisny software is made by the companies possessing "non-standard" business processes. The problem is that exotic ultimately leads to the creation of crutches, which remain in the system for years and make it difficult for users to work.

The developers of serial products cannot afford any exotic, since many companies use their solutions. This means that they are more predictable and understandable for users.

What to do if the move is ripe

Own developers are expensive, and their presence does not guarantee success (as the problems described above illustrate). Therefore, more and more companies are thinking about switching to serial billing.

This process can be made less painful if you follow a few simple guidelines:

• First of all, do not need to pull the transition. The further this decision is postponed, the more inaccessible problems will accumulate.
• When choosing a serial solution, you need to look not only at its current functionality, but also to find out the development plans of the creators (the right developers will never hide them).
• It is better to migrate gradually - it is more difficult and more expensive, however, it will allow you to avoid failures and negative, and the company's reputation is more important than money.
• You can not save on testing - you should pay attention to recreating the "combat" conditions on the test stands. For example, large customers we ask to switch the load from the real network to the test installation of billing for a short time at night.
• Moving by yourself is incredibly difficult. Migrating to a new billing is a time-consuming project, for the implementation of which few companies have free human resources. Employees are busy with current tasks, so it is better to attract contractors who have already conducted many similar implementations.

That's all, thank you for your attention. In the next topic we will talk about how we were engaged in work to improve the resiliency of our system.

Subscribe to our blog to not miss anything interesting!