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.

 

Leave a Reply

Your email address will not be published. Required fields are marked *