Reusing documented business rules for business benefit

Summary

Billers who document their billing business rules, maintain them to mirror the current reality, and (importantly) place them where staff can find and use them, are better placed to perform accurate processing and recover faster when problems occur.

Billers who don't maintain their business rule documentation, or lock it up within application / network silos where it cannot be found, will incur additional costs when incorrect processing is performed (in ignorance), errors take longer to fix, and project costs are higher due to internal inter-silo 'friction' in areas such as revenue assurance testing.

Billers replacing their existing billing systems benefit from knowing what their new systems must do to support their current product offerings (minimum spec), what their revenue assurance plans must address, and what their future testing plans must accommodate (including regression testing). Documented business rules form a base to which future requirements can be added.

Examples of what can be captured in business rules

Business rules describe in plain language what happens during the billing process - they document 'what' should happen rather than the 'how' mechanism through which it is delivered. Business rules may reflect industry regulation (pricing, credit management), be specific to the biller (doctors' surgeries will not be disconnected), or outline specifics of the biller's product offerings (all call charges levied for 'gold-class' conference calls will be directed to the convening party).

The methods used to describe business rules must cater for the 'tension' between accurate descriptions that can be understood and verified by the biller's staff (or auditors), and the terse formats the biller's systems will use to implement those same business rules.

Whilst business rules included in industry regulations may be described in 'plain language', repeatable and ongoing processing such as revenue assurance may prefer accurate, 'machine readable' tables of valid field values and record selection criteria. A trade-off may need to be made in how the business rules are represented to the biller's staff (and customers) versus the level of reentry required for those rules to be translated (reflected) in billing functions.

Business rules can involve areas such as:

Selection: These rules identify which customers, records or products are passed to billing, and how (and whether) they are billable when they get there (e.g. toll-free phone calls). Not all records that flow from a biller's network must be passed to their billing platform. For example mediation processing for a phone network may omit a network's information-only records, consolidate partial call records from a mobile phone conversation into one call record, redirect toll-free and reverse charge calls for specialised billing, or guide (wholesale) interconnect call records to a separate billing platform.
Eligibility: Differentiated processing can be performed based on criteria such as product family or customer segment. For example, a discount plan may be applied automatically to reduce 'residential' customers' prices, whilst leaving ineligible corporate accounts unchanged. Conversely, only corporate customers may be allowed to negotiate their own pricing plans.
Aggregation / Manipulation / Transformation: These rules outline how transactions are manipulated and record / transaction interfaces between applications are populated. For example, long-held phone calls (i.e. lasting hours or days) may be aggregated 'up to' a specific duration before a 'new' call record is 'deemed' to have begun. Interface field values may be differentiated by (say) product or customer segment, possibly affecting downstream processing.
Error processing: The majority of transactions flow through the end-to-end billing process successfully, but a small number will error due to incorrect field values or mismatches between separate databases (e.g. a network service not found in billing). Business rules can describe which errors are 'serious' and require immediate manual attention (e.g. invalid product code), and which are 'temporary' and possibly resolved automatically with recycling (e.g. for database entries not found due to known issues of update timing, make three additional attempts before failing with a 'serious' error).
Discard processing: Otherwise valid transactions can be discarded if they fall within classifications regarded as unbillable. For example, some industry billing codes prevent charges older than 90 or 180 days being billed to customers. Other examples of discarded transactions include phone calls where a 'busy signal' is encountered, unanswered calls, and calls to emergency services.

Four areas where documented business rules can provide business benefit

Documented business rules are a mechanism by which corporate knowledge is carried across time from one 'generation' of business users (product managers, business analysts, programmers) to the next. Four areas where documented business rules can provide business benefit to a biller's business are:

Education / Training / Context
Processing simplification
System replacement
Revenue Assurance

Education / Training / Context

Like all businesses, billers must continuously transfer the system and business knowledge from their existing staff to their newly hired and internally transferring staff. Without documentation, billers must take their existing staff away from day-to-day duties in order to pass on the business knowledge using time consuming manual explanations.

Billers who have not documented their systems are at risk when the correct operation of their business resides in the heads of a small pool of subject-matter experts (SME), or remains (obscurely) embedded within their applications' software code. Billers must take the opportunity to capture their business rules where others can find and use them before key staff retire, have an unfortunate accident, win lotto or resign (career change, poached by a competitor).

Once captured, documented business rules can be referenced repeatedly with minimal day-to-day disruption to the SMEs. With documentation, the SMEs can dedicate their time to addressing harder business problems or delivering advanced training rather than repeatedly answering the same questions. By documenting their business knowledge, SMEs may save their own time by avoiding the need to (re)work out the correct answers, or hold required details accurately in their head for immediate reference.

Business rules whose only documentation exists in 'programming code' (software) are not easy to discover, explain, validate for correctness, replace or reuse. Staff who try to use business rules located only in software must understand the specific programming language(s) in which they are encoded, hunt through all the relevant software code to build an overall picture, and have some mechanism for detecting when changes take place to validate modified business rules.

Alongside the basic details of the business rules, documentation can outline a processing context, helping users understand 'why' processing is performed. For example, business rules that outline record selection using explicit field values can explain what the fields values mean (e.g. international phone calls, three-phase electricity, international interconnect charges). If field values have structure (e.g. ABC123-X), an explanation of what each segment means or how it is constructed (i.e. ABC, 123, X) can be included. These contextual details can help staff identify errors (e.g. 'domestic' phone calls performed overseas), and assist in future analysis when these fields are extended, retired or replaced (e.g. during a system replacement).

Documented business rules are especially important for processing that fails rarely or is changed infrequently. Even experts can forget what should be performed or why certain actions are taken. Staff will have a strong working knowledge of application areas that change regularly for reasons of pricing or new product introduction. Working knowledge about areas operating for years without change (such as payment processing or financial postings) can be completely forgotten necessitating a '(re)discovery' process that will be longer without documentation.

Processing simplification

Each product (or product version) offered by a biller will eventually be retired. Products replaced by versions of the same underlying technology, network and/or pricing rules may cause little change in the underlying billing environment. However, when a technology / network is retired for good, and its related processing is no longer in use, the biller is presented with an opportunity to simplify their systems, reducing their operational environment's complexity.

For example, the retirement of (say) 'telegrams' as a product allows the removal of the dedicated interfaces through which telegrams were sent and received, the application (say) that stored the telegrams' contents, and the application that (say) scheduled and tracked delivery to their intended recipients. Where processing was performed in an application shared with other products, any telegram-specific processing can be removed, or flagged as 'no longer required'.

Staff updating applications and end-to-end processing flows can be secure in the knowledge that the 'telegram' processing is not required, its processing can be removed / changed / reused without impact, and that 'special processing' associated with field values of 'TE' (say, for telegrams) is not required in related areas such as revenue assurance and mediation.

The documentation of what processing 'was' involved with telegrams can still be retained, but deprecated, so that when telegram-related processing is unexpectedly encountered in shared systems that 'used to' process telegrams, the appropriate understanding (products no longer offered / sold) can be applied to software, training, and business impacts (no longer supported / required - remove).

System replacement

Billers will replace their billing systems on a regular, if long-term, basis. Documentation of the existing systems can form the starting point for the minimum requirements a replacement system must support. These initial business rule details can be supplemented by the requirements identified to support the biller's view of their future billing needs.

The RFx documentation billers send to their software and system integration vendors as part of a billing system replacement will be more complete and allow the corresponding responses to be both better informed and more accurate. The vendors will have less opportunity (or risk) of encountering 'surprises' during the replacement project.

Alternatively, the operating environment may have changed so that not all of the business rules now apply. Billers can select the subset representing what is still needed going forward. For example, the rules may have outlined inter-system processing between a biller's fixed-line and mobile phone billing applications, but if the biller has sold their mobile phone business (and network) these rules are probably no longer applicable.

Revenue Assurance

Revenue assurance testing relies on documented business rules to describe what 'should' take place as a comparison point against what 'actually' takes place in the biller's systems. Documented business rules describe how customers and their transactions are selected for processing, how different product groups can be identified, the applicable field transformations / mappings, the pricing mechanisms and the discard/error rules.

Explanations of how different products are defined allows product-specific testing to be performed (e.g. testing fixed-line phone calls but not mobile phone calls), allowing the segmentation of consolidated transaction streams. Business rules describe how the biller's revenue flows through their systems, how different points in the end-to-end processing flow should reconcile, and which files / databases should reconcile along with the means for comparing entries in an 'apples' to 'apples' manner.

Tags: Billing, Business Rules, Revenue Assurance, System Replacement