BILLING SYSTEMS

Blling system.

The lingo of any service provider is an important mechanism

for optimizing billing and subscriber management. And every

operator invariably undergoes two exercises-evaluation and selection

of a system, and then the actual implementation. The success

of the system depends on a large extent as to how it gets implemented.

Vijay Tolpadi, senior consultant, Cambridge Technology Partners,

attempts to address the issues involved in the implementation

of billing systems for potential Internet Service Providers

(ISPs). He lays out a track of activities categorized by broad

areas that need to be followed for smooth implementation. He

also suggests a sequence for billing system implementation wherein

certain activities need to be completed before others as any

disruption in this proposed sequence could lead to potentially

flawed and error-prone implementations.

A billing

system implementation inescapably means a set of activities

designed to result in the billing system being available for

use by enterprise representatives. What this set of activities

tries to ensure is that all the business requirements of the

enterprise are finally met by the system in question. Typically,

such requirements would be thrown up during the evaluation exercise

for the billing system itself. If such requirements are not

available, it is imperative that a requirements-gathering exercise

be carried out prior to implementation.

At this

point of time, it is assumed that the ISPs' business requirements

have been clearly defined, the ISP has a billing system on its

premises, and this billing system is ready for implementation.



Implementation Sequence

Network

Integration



A billing system cannot stand on its own, i.e., it depends on
the network "elements" to provide it with critical

billing data. Every other functionality offered by the billing

system is directly or indirectly dependent on this network generated

data. We could possibly implement business rules as a first

step, but we would have no means to test the correct functioning

of these rules without the presence of network data. Therefore,

before we even get down to implementing "business rules",

we need to ensure that the billing system possesses the network

data to operate on.

However,

network generated data cannot be used straightaway and what

we really need is "billing data". To clarify, network

data usually comprises the usage records of the various users

as logged by the network elements, whereas billing data represents

the same usage records converted to a format recognizable by

the billing system. The "network" data generated is

processed by the "billing interface" and then is converted

to "billing" data. The billing modules comprising

the basic billing system itself, operate on this billing data

using a set of "business rules" to provide the various

functionalities required by the enterprise and store this as

"enterprise" data. Therefore, what network integration

means in this context is to develop the "billing interface",

which would enable receipt and processing of network data and

conversion to billing data.

The natural

question to ask next is why one should develop the "billing

interface", as it should logically be part of the billing

system itself. However, most billing system vendors today "do

not" supply the billing interface modules along with the

basic billing package, as these are heavily dependent on the

nature of the network components on the ISP's premises. For

e.g., a specific type of Radius server (which is normally the

dial-up user's authentication server) stores network data in

a specific format, whereas the billing system would accept data

in a pre-defined fixed format only. Thus, the billing interface

modules would need to change depending on the kind of Radius

servers installed on the ISP premises.

To sum up,

network integration is the first logical step in a billing system

implementation exercise, and this step involves developing the

interfaces required to convert network data to a format that

billing systems can understand.

Business

Rules Incorporation



The next step in the implementation sequence is to incorporate
the "business rules" relevant to the enterprise into

the billing system. This activity is logically the next step

because most of these business rules operate on billing data

and not on raw network data. The output of incorporating the

business rules is to produce "enterprise" data, which

really drive the various functionalities offered by the billing

system.

However,

we must first understand what are really meant by business rules

and their "incorporation" into the billing system.

A business rule pertaining to a specific module represents the

ability of the module to "offer" a specific functionality.

By "offer" it is meant that a business rule is not

an absolute formula or a parametric value, rather it is the

ability of the module to allow the enterprise representatives

to define any specific formula or parametric value that they

desire.

For instance,

consider the payment module of the billing system. A typical

business rule would be the ability of the billing system to

provide the functionality of handling late payments by levying

a late payment fee. Now, the provision of this functionality

enables enterprise representatives to define any late payment

fee structure by inputting appropriate values into the payment

module. The user may input a specific fee structure today and

may change this in the future to another fee structure, because

the system provides him with the business rule functionality

to do so.

Thus implementing

the business rule of late payment management from the viewpoint

of the implementors would "not" mean that a specific

late payment fee structure needs to be input into the system.

Rather, the implementor must ensure that the system has the

capacity to implement "any and all" the late payment

fee structures that the enterprise representatives may desire.

These specific values taken on by the business rules are termed

as "manifestations". Thus the ability to provide late-payment

fee functionality is a "business rule" and a specific

late-fee structure is a "manifestation" of this business

rule.

There is

another implication arising from this technique of business

rules implementation, from the implementors' viewpoint. A great

deal of responsibility is now on the part of the enterprise

representatives, as they would be now required to know how to

implement the various manifestations.

It is important

for the implementors to ensure that adequate training is provided

to enterprise representatives, so that they are capable of implementing

a specific manifestation at any time in the future when the

actual implementors may no longer be physically available.

Implementation

of business rules results in the generation of additional data

in the system that we call "manifestation" data. This

form of data is nothing but a data level representation of the

specific manifestation of the relevant business rule.

Another

form of enterprise data is what we call "transformed billing"

data. This represents the result of certain business rules operating

on "billing" data and converting it to forms more

easily presentable to the end user. As an example, we have mentioned

that billing data is usage data produced by the end-user's usage

of Internet (after being processed by the billing interface).

This data is required by the invoicing module to periodically

generate invoices for customers, i.e., the business rule of

"periodic invoice generation". This billing data cannot

be used per se as it is still too "raw" for presentation

by the GUI. Thus the invoicing module is responsible for massaging

this data into a more easily presentable form by possibly abstracting

the relevant details, performing the needed calculations, and

storing it as transformed billing data.

It is important

to realize that these forms of data like the manifestation and

transformed billing finally resident in the billing system have

ultimately come from either of two sources-the enterprise representatives

(manifestation data), and the final end users (transformed billing

data).



Supplementary Systems

Development





Having carried out network integration and essential business
rules incorporation, then comes the phase of incorporation of

additional business rules. These rules are such that they are

very specific to the enterprise where implementation is currently

underway, and such functionalities do not usually come bundled

in with the product. The reason why this activity should be

executed after the previous two activities is that these business

rules need to be tested after the completion of the other two

steps. Testing here is very important as such functionalities

do not come bundled in with a tested product, but need to be

developed by the implementors themselves.

An example

of such additional



business rules is related to the process of registration by
the end-users. The registration process is still very enterprise

specific, and different ISPs have evolved different means of

allowing



their customers to register themselves. One common form of registration
involves the distribution of CDs to customers with a set of

codes representing login and password ids. The format of these

ids is very specific to the enterprise, as different enterprises

could potentially desire their own such formats. Thus billing

systems do not normally come with id-generation functionality

but provide enough openness to integrate with external id generation

applications.

Dummy

Runs



After all the aforementioned activities have been completed,
it is time to operate the system in a pseudo-live environment,

in what we call a "dummy run". This can be achieved

by actually bringing on customers to use the system on a trial

basis, monitoring their feedback as well as monitoring the performance

of the billing system.



This "dummy run" is very important as it usually throws
up hidden flaws in the entire implementation process and the

product itself. No implementation process or product is defect

free nor should it be expected to be as such. The correction

of such detected flaws is a step towards ensuring that the system

performs as expected in the "live" environment and

there is no extensive revenue loss by the time they are detected.

Crash

Time Frames, But in Order



These are some of the facts and findings that are normally overlooked
by most implementors in their attempt to get a billing system

up and running ASAP. In an attempt to "crash" time

frames, important activities such as network integration are

sometimes overlooked or postponed in favour of more traditional

activities such as implementing "business rules",

or are sometimes combined with other activities in parallel.

In other words, a sequential implementation is the quickest

way to error-free implementations.

Note:

This paper is targeted at both ISPs and the actual implementors,

as they have to ultimately work in unison to ensure successful

implementation. It, however, does not attempt to provide guidelines

on how billing systems should be evaluated and finally selected

for actual use. It assumes that such exercises have already

been carried out, and a ready to use enterprise quality billing

application is available for implementa-tions.