Skip to content

Billing Problems: What can Go Wrong with self-written software

Technological tangle

Proprietary software solutions are often monolithic — this means that in addition to the actual billing, they may also have CRM functionality, a help desk, a system for activating new subscribers, and even a tool for planning installation work.

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

Crutches are eternal

Often the choice in favor of self-written software is made by companies with “non-standard” business processes. The problem is that exoticism eventually leads to the creation of crutches that remain in the system for years and complicate the work of users.

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

What to do if the move is overdue

Own developers are expensive, and their presence does not guarantee success (as illustrated by the problems described above). 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 recommendations:

First of all, there is no need to delay the transition. The further this decision is postponed, the more intractable problems will accumulate.

When choosing a serial solution, you need to look not only at its current functionality, but also find out from the creators development plans (the right developers will never hide them).

It is better to migrate gradually — it is more difficult and more expensive, but it will avoid failures and negativity, and the reputation of the company is more important than money.

It is impossible to save on testing — attention should be paid to recreating the “combat” conditions on test benches. For example, we ask large customers to switch the load from the real network to a test billing installation for a short time at night.

It is incredibly difficult to move yourself. Migration to a new billing is a time—consuming project, for which few companies have free human resources. Employees are busy with current tasks, so it is better to attract contractors who have already carried out many similar implementations.

That’s it for today, thank you for your attention. In the next topic, we will talk about how we were engaged in work to improve the fault tolerance of our system.

A small business takes a demo and puts it to watch. Medium-sized businesses go to their neighbors and consult, look, and then implement it at home. Big business can’t do this, because ERP-level software can’t just be taken and tried (it can take 2 months for one test organization), you can only spy on general principles from neighbors, and you can’t get a distribution kit and a license so easily.

Since it is very difficult to understand how to do something at this level (after all, you need to have a couple of years of extremely rare experience), and there are usually more than one options, problems begin. As a result, you may get a blurry technical task, which is put up for tender. And the tender is won “for two kopecks” by someone who will do everything as it was in the task – but at the same time absolutely not what the business wanted. I think there is no need to explain how this happens.

Therefore, special decision centers are needed — a kind of testing grounds. There you can look at one working day of an abstract company from the perspective of users from different departments, an administrator, and so on, using already filled test bases and simulated infrastructure.

Why do we need such a solution center?

It’s very simple: you can say a lot of words and promise anything. Or you can just show it. So that everyone understands in detail what is possible, what is not, how tasks are solved and where what surprises can be. In the case of software, the implementation of which can take from 4 to 12 months, this is very important. No one wants to implement it first, and then understand that there is still a lot of work to do, or even migrate to another solution.

Why is it impossible to deploy a pilot project with the customer?

In my practice, there was a case when a customer chose a resource and project management system for 4 months out of three options. Accordingly, specialists from the same company came to them, looked, picked, deployed. IT specialists poked, studied, mastered and generally ran an almost complete “beta” — then the cycle repeats for the other two solutions. If you have so much free time and money — yes, this is a good option for a responsible choice.

How is it usually done?

Usually the customer knows exactly what he wants to solve. And it is enough for him to make sure that the system can do this in principle, there will be no rakes in the process, plus all this is not done through one place, and maybe it will be “sharpened” for his specific business processes. Accordingly, at first there is just an inspection of the software solution, then a more detailed poking at the described tasks. After a day or two of picking and commenting on our consultants, there is an understanding of how it all works and what it can do.

What does the decision center look like?

I work with HP Solution Center, so I will continue to talk about its example. Our center looks like a small room with plasma, laptops and other things for presentation. All this is connected to a data center in the same building.

Full list of solutions in HP SC