"We will understand": Why not need to introduce complex products on their own

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.

In one of the previous materials, we talked about why the decision to engage in self-development of a complex system like billing can lead to problems . The trouble is that just buying a finished boxed product from its developers is not enough to guarantee a bright future for yourself. You can't just take and implement a complex system - as a result, each project turns into a real quest with an unpredictable final.
')

What is the problem

The implementation of such complex products as billing is an extremely difficult process. Despite the fact that the system may be called "boxed", in fact all the companies using it are quite different - we are talking mainly about telecom operators. This means that there are no typical solutions for possible problems - each time the process can take a completely new, unique way.

That is why self-introduction of such a system will almost guarantee the company to a situation where the desire to save ultimately results in additional expenses.

Judge for yourself, even with the availability of high-quality documentation, it will take a large amount of time for specialists of the company buying the system to analyze it. They could spend it on their immediate work. That is, the business begins to incur losses at this stage.

It is obvious that if a specialist performs some kind of operation regularly, then the speed of work in this case increases. The introduction of billing does not fall into the category of regular operations, because such systems are selected for years to come. This means that it will take much longer to deploy a purchased solution than if it was done by its specialists, who carried out a large number of implementations of this product. In such competitive areas as telecom, any delay can seriously damage the business - competitors do not sleep and actively develop their services, offering customers new and interesting conditions.

Another important point - the ideology of complex systems that solve the same problem, in reality can be very different. As a result, this further complicates the migration - often the principles of the old are applied to the new tool. Nothing good comes out of this, as a rule.

An example from the sphere of billing - one physical subscriber of a telecom operator may have several contracts, for example, for different apartments or services. In our Hydra billing, when we know that we are dealing with the same Ivan Ivanov, all the data on it are reduced to one “customer” entity, but there are systems where everything is different. In our practice, there have been cases when customers who have switched from such products asked to make several subscribers of one such Ivan Ivanov - one for each contract or service (Internet, television, telephony, etc.)

This breaks all the logic of the system - it is very difficult to keep statistics and build reports on such “forked” or even “rastered” subscribers. As a result, the customer asked for improvements in the system, which could somehow alleviate the problems that arose - but they would not have existed if the system had been initially implemented in accordance with the stipulated scheme.

Finally, no one is immune from mistakes, and when introducing a complex system, they simply cannot be avoided. This means that even after spending a lot of time, nerves and energy, the company only enters the zone of turbulence, where problems can happen at any moment. Some errors do not appear immediately. Therefore, a situation may arise when a complex system is purchased, independently configured and launched in combat mode without any problems. But after a while a sudden catastrophe happens.

Considering the fact that the same billing is one of the key IT systems of a business, without which it is impossible to correctly service clients and write off service fees from them, even a small mistake can lead to significant consequences.

For example, at some point the provision of services to a certain number of users may be blocked due to an error in the design of the tariff plan or subscriptions. In the case of loyalty programs, an error may occur even after a few months - old users will not be happy about the erroneous cancellation of their discounts or subscriptions to additional services. When implemented with the help of a system developer, such typical errors will be found and neutralized.

In addition, it is not always possible in principle to save and transfer the task of implementation to developers, but to external outsourcing specialists. For example, there are simply no such independent professionals on the Russian billing market, and even not all billing system developers offer customers assistance in their deployment. That is why, the fact that developers help customers implement the created system must be taken into account when choosing a system from different options (what else should we pay attention to here).

It seems that the possible problems are understandable, and all that needs to be done is to simply attract the developers so that everything will go smoothly. Unfortunately, this is not enough either.

Work still have to

The “here's the money, make good” policy in the case of the introduction of complex technology products can destroy all the benefits of the project transfer to the contractor. Implementers need help - to advise them on specific issues related to the business, to provide access to the necessary systems to work. And some of the work, such as reconfiguring network equipment or uploading data from outdated samopisny billing, is often (but not always) given to the contractor simply unprofitable.

If this is ignored, experts will not be able to do their work. In addition, all sorts of hitch will lead to a waste of time, and the resulting rush as the project deadlines approach - in the end the number of errors will increase.

That is, many of the advantages of attracting developers to the implementation of the solution created by them will simply disappear. To avoid this, the efforts of one customer are not enough, the developers themselves must organize the implementation process accordingly.

What to do: project approach

The experience of more than 100 implementations of our own billing by Hydra allows us to make another not very pleasant conclusion. Even in the case when the company’s management is configured in the most constructive way and is ready to invest in a new system and its implementation, this does not always motivate the technical specialists of this company.

As a result, the majority of customers cannot manage the implementation project - before it starts, it seems to everyone that it will be necessary to actively control the contractor (that is, us), but in many cases, on the contrary, we have to control the customer. This is not because customers are lazy or bad, but for objective reasons - the telecom operator does not have “extra” employees, they are all loaded with current tasks, and they have to deal with the implementation of new billing almost overtime.

As a result, projects did not always end on time. When the contract for implementation has only been signed and until the system is launched for a few more months, it is tempting to postpone work in this direction for later, and now do something more relevant. This translates, for example, into the fact that we could wait months for the customer’s engineers to prepare a test bench for us to fill in the billing and its settings. At first, we are not given a virtual machine for a week, then we cannot connect to it due to non-open ports, then the system restarts and access to the stand again disappears - it can take up to a month to solve such an “important” task.

As a result, when the deadlines begin to tighten, the managers of the customer company, as a rule, begin to put pressure on the managers. It is often impossible to shift the timeline for switching to a new billing, so after the wasted months in the last couple of weeks you need to catch up with the whole lag.

Having repeatedly faced with such situations, we came to the need to reformat work on the implementation of billing. Now we completely take over the management of such projects for ourselves - for this the company has a dedicated employee who keeps all the information in the project management system Teamwork.

It clearly shows all the necessary stages of the project, the tasks that must be completed, and those areas of work that will be unlocked after that. Also listed are those responsible for solving the tasks on both sides.



Thus, we have the task of tracking all stages of work, correct logging of the work done and planning future tasks that need to be done by ourselves and assigned to the customer’s specialists.

As a result, the efficiency of the work of the engineers of the two sides increases significantly - the employees of the development company better understand what and when they need to do the project, and the client representatives understand what stage the whole process is at. Thus, potential problems can be identified even before they turn into something serious.

Other articles on IT infrastructure:

• Billing issues: What can go wrong with self-written software?
• How to improve resiliency of billing: The experience of "Hydra"
• DoS on your own: What causes the uncontrolled growth of tables in the database
• How to organize a paid support for a complex product: the experience of "Hydra"
• What else affects the infrastructure: How to ensure the quality of equipment installation