As a network operator you strive towards a business that is well-functioning, profitable and with high customer satisfaction in all processes. It is then more important than you might think with architecture and the design of the system landscape to keep in mind the integrations between those systems.
Automation and digitisation are effective ways to reach the goals. Automation requires that data is available and integrated. Data storage is of importance. To store data in the wrong type of system drives cost and creates systems that are hard to maintain.
Integration between systems is important but is a source of high costs, both short and long term. Integrations can also be complex and are often uniquely created for every solution. Complex integrations can be a source of problems and makes you dependent on expensive and scarce resources.
Few systems can manage everything. But by understanding different systems, it is possible to make good decisions that minimize integrations but still reach the goals of automation.
So, what integrations should be done?
First and foremost, you should automate the processes that often recur and have the most impact for your rollout. Typical examples are “from interest to order”, “order to cash” and “problem to resolve”. A common denominator for all these processes is that self-service by the customer makes them even more efficient.
Let us investigate a typical system landscape that is common among Netadmin customers operating a fiber network (as below). In the middle, you have an integrated OSS/BSS, like Netadmin, capable of keeping track of an address and its relations to customers, subscriptions, devices, and different statuses. To the right, you have payment and invoicing together with Business Intelligence (BI) and reporting tools. To the left, you have the Sales & Marketing department and their needs in CRM and marketing automation for B2B and more manual sales processes like knocking on doors.
If you are going to work with a wholesale business model, you would need to integrate and automate the processes between you and the Service Providers, either via GUI or API. After the network planning and design is done, the addresses need to be transferred to the operational business support system so that they become aware of the ready-for-sale addresses. On the top, we have the interaction with the subscriber and at the bottom, we have the communication with the network.
Here is a description of each of the integration points.
- The integration to the network is done directly to the network elements or via a vendor specific Element Management System (EMS). Sometimes there is a RADIUS server for authentication that needs to be configured as well. The RADIUS backend database is modified via CRUD operations. Typical operations are to configure the bandwidth profile and a static IP address associated with the subscriber ID.
- The integration towards an invoicing system is done differently if the network operator invoice according to anniversary or period billing. Regardless the invoice rows for one-time and period fees are sent over to the invoicing system together with customer information. It is common that there is an integration between the customer portal to the invoicing system to present a PDF copy of the invoice for the customer. In the customer on-boarding portal there might be an integration to a payment provider, so that it is possible to retrieve a Direct Debit mandate that then is used at invoicing.
- The integration between GIS/planning/network design tools to the OSS/BSS is usually done via exchanging a spreadsheet in the start-up phase. An integration between APIs might be needed at very high build-out rates.
- If you are going to or already working with a wholesale business model there is often a need for the external Retail Service Providers (RSPs) to perform availability checks, place an order and troubleshoot existing customers via some portal. If you have larger RSPs they might want to integrate towards an API. Depending on the market there might be specific APIs that needs to be implemented, e.g., S/PRI in Germany, ON-API in Sweden, and the ALEX platform in Switzerland. Billing is often a manual process when running a wholesale business.
Apart from these four integrations, there might be a need of creating integrations to lightweight CRM systems used by Sales & Marketing for B2B sales and door-knocking sales activities. An integration towards external ticketing systems might be needed as well.
There are some potential pitfalls. One is to introduce an Enterprise Service Bus (ESB) and place your business logic in such system. Those systems are made for message exchange and not for business logic, orchestration, and administration. Another pitfall is to start with a CRM and build everything around that system. CRM systems are great but only for certain use cases. The customization and integration costs can be huge when a CRM system grows. CRM systems are not built to manage fixed fibre infrastructure, wholesale and all the processes around such a business and the address object.
When you design your system landscape you should investigate the different systems’ strengths and weaknesses. It’s best to avoid too many integrations to start with and develop them according to business cases. Good luck 😊