|
purebill.com Stephen Jones writing on billing and application migration |
![]() |
| . | Home | . | About | . | Archive | . | Links | . | Billing | . | Reference | . | Subscribe | . | Search | . | . |
Column - 16 April 2006 Using location to drive operational and migration processingSummaryBilling and other business functions often differentiate their processing by market segment, but processing can also be driven by where a customer or transaction is performed - its geography. Geographically driven processing can be performed over the long-term (tax rate, default currency), or the short-to-medium term during system and data migrations (e.g. to select (or omit) customer and / or transactions). Geography can be described using obvious and well developed reference values such as postal codes and commercial GIS identifiers, or derived by applying external knowledge against existing (arbitrary) code values (e.g. mapping the arbitrary values of a business' organisational units to their corresponding geographical coverage). By applying geographic criteria when making decisions, operational and migration processing can be customised and targeted to great effect. Processing decisions driven by geographyFive examples of geographically-driven processing are listed below, and whilst most are demonstrated by migration examples, the same principles can be applied equally well in day-to-day operational processing. Selection / Qualification - The earliest part of a phased migration event is to identify which subset of the old system's data will be migrated in this event, separate from the data that has gone before, or that will migrate subsequently. Geographically based criteria can be applied to select the specific customer, accounts, services, or products eligible for migration. Omission / Exclusion / Disqualification - Once records have been selected for (migration) processing, an additional step may be performed that excludes records (customers, accounts, etc.) that would otherwise have qualified. The criteria applied may be specific to customers (e.g. don't migrate a new customer), or specific to a location (e.g. incomplete training at a business unit, equipment failure, earthquake / cyclone / typhoon / hurricane in a specific region). The exclusion process acts to reduce the planned scope of processing without changing the core processing itself, and is likely to be both short-term (dynamic) and localised in scope (targeting specific areas within an otherwise qualifying selection). (Re-)Direction - During a program of migration, network transactions and customer maintenance sent to the systems under migration will require guidance to ensure they reach the appropriate system. Customers and interfaces should not need to understand which system is now appropriate (old system / new system) and so the guiding process must direct inbound transactions and interfaces to the appropriate system reflecting the migration status and the business rules for new connections. Effective dated changes - Geographic-based status can vary by date driving changes in defined processing. Examples include pre-migration cutoff dates that limit what, where and how new network connections are processed (ahead of a region's migration), or changes to tax rates that change on the first day of a new tax year (operational). An example of date effective migration is when Australia renumbered its telephone numbers (i.e. Austel Numbering Plan), extending the telephone number length and reducing the number of area codes to four (from fifty-six). During this extended, years-long migration, the telephone network was prepared exchange-by-exchange to process (receive and initiate) phone calls performed using different phone numbering structures. Most phone numbers (and their exchanges) underwent only one transition, but some specific number groups had to undergo two transitions over the migration period. Decisions about when numbers were classified as seven or eight digits long, when they could be contacted using the new number, and no longer contacted using the old number were driven by effective dated reference tables. Migration granularity - Each migration segment's size (granularity) often depends on how large a group can be migrated at one time. The limiting factor in a migration can differ by market segment, and vary as the migration process is 'tuned'. Factors that can influence migration granularity include limits on the 'physical' volume of data that can be moved / migrated / converted within a specified timeframe, the rate at which staff can be trained, and the time available to perform timely error corrections post-migration. Groups that are initially too large can be segmented by additional criteria (business division, status, market segment, product portfolio) until the granularity of each sub-group matches the migration volumes that can be comfortably addressed within a single migration event. Examples of geography driving operational processingGEOCODE - Geocodes outline locations from levels representing entire countries, down through regional levels representing states and counties (e.g. in the US), and on through to identifying city districts. Location specific processing such as taxation can be linked to 'geocode' values, which are possibly derived from more conventional address details such as billing addresses, postal codes, service or transaction locations. Telephone number related fields - Telephone numbers can be linked to a wide range of actual and derived fields that can then drive geographical processing. A phone number's leading digits can indicate a destination country code (international call rates), intra-country area code (separating local versus interstate calls), or the location of a telephone exchange (e.g. timezone, system equipment). As well, transaction fields can indicate the specific (say) mobile phone towers from which a transaction originates or terminates, with these details used to drive the derivation (lookup) of other reference values (such as geocodes) used in subsequent processing. Examples of geography driving system / data migrationBilling, like other core business processing, is often deployed (replaced) using phased releases rather than in one 'big bang' event. Phased releases deliver gradual increases in processing volumes assisting in user training schedules, IT performance tuning, and hardware releases to address capacity growth. Geography is often the basis by which existing (legacy) processing is divided up into deployment phases, using group indicators such as:
Do Not Call (DNC) Processing - A (US-based) register of telephone numbers established to indicate those households and businesses who do not wish to receive telemarketing calls. The register was deployed in phases to spread and accommodate the expected high processing workload associate with new registrations. Eligibility for each phase was based on where people lived, with the customer's (telephone's) location driving when they could sign-up, along with the cutoff dates for telemarketing-related processing. Tags: Migration, Selection, Criteria, Location, Geography [ Share with others ] Post this page to a social bookmarking site:
Other 'purebill' columnsPrevious column: Archiving billing data for the long-term Next column: Four steps that defend a biller's revenue stream All previous purebill columns can be found in the archive section. Recent Updates
Sign up to receive a brief text email when a new purebill column is published. JUMP TO TOP
|
. |
| Comments welcome: stephenjones(at)purebill.com | Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap | . |