Proposal for Management
Integration
and
Book-to-Bank System
1
2
3
4
5
6
7
8
9
10
Overview
Basic Data Architecture
Inventory Database
Network Provisioning
Customer Provisioning
Trouble Management
Marketing Support
Billing and Accounting Systems
Sales Force Automation
Summary
1 Overview
Company “A” requires an integrated data architecture allowing us to conduct our business, and
maintain revenue assurance. These systems range from the core architecture required to
provision and manage the COMPANY “A” exchange sites, to customer support, to the
software and hardware platforms needed for our book-to-bank process. Key to the success of
this infrastructure is the need to enforce an open data architecture, with published data schema
and structure. This will promote easy integration of data elements from potentially several
different databases, and potentially multiple software solutions vendors.
This document will explain the requirement for management, inventory, provisioning,
customer support, sales support, and book-to-bank systems. Where possible
recommendations are given to understand and plan for interconnection, correlation, and
data warehousing requirements. Emphasis is given to ensuring all databases will have a
capability to provide input to decision support systems needed by both senior
management, as well as operational levels of the business.
2 Basic Data Architecture
All data architecture is designed to support both the functional requirement given by a
particular division, such as network management or billing, as well as consideration for
data correlation and potential warehousing.
Figure 1. Data Inter-Relationships
In addition, provision should be made for those cases where one system update should
be able to update one or more external databases such as a customer information
database update should also have the effect of updating the billing database. This
should in turn give updated information to the trouble ticketing system (ex, Figure 1).
As the data architecture should be designed with open and known data formats, a
correlation or data warehousing capability must also be added to ensure data is
available to decision support systems for statistical reporting, as well as input to key
performance indicators. Some examples of data required for adhoc and recurring
reporting from the overall data architecture include:







Inventory consumption trends
Installation trends
MTTR/MTBF trends
Sales force automation support (being able to automatically generate customer
and network profile information for use by mobile sales staff)
Vendor performance
Network resource and utilization statistics
Product performance info by category
Producing decision support and adhoc reporting information based on either single or
multiple databases will require staff skilled in database report generation using tools
such as Cold Fusion or Brio. These tools allow us to generate DSS/reporting to web
browsers or additional formats, without the need to create additional adhoc local
databases. This will have the added benefit of reducing the instance of “Z” files by
COMPANY “A” employees1
COMPANY “A” will strive to keep all data used in DSS systems real time, with the
only exceptions resulting from data produced from a correlation or data warehouse
(CDW) infrastructure. In those cases the data maintained in the correlation or CDW
will have specific rules attached regarding data life cycle and currency.
The Manager, Global Data Architecture under IT will publish and maintain a database
architecture and schema directory. This directory will give guidelines for data record
structure (i.e., creation of key fields, record formats, database formats and software
standards, etc). Only databases considered extremely proprietary and sensitive will be
excluded from employee access to this directory and schema (this is to prevent
unauthorized attempts at writing scripts against the database). All new databases and
architectures created must be registered and the basic architecture approved by the
Global Data Architecture group. This is not meant to be a limiting factor for users
requiring creation of a database, rather it is to enforce an open structure within our data
architecture to support correlation, CDW, and production of DSS, SPC, and KPI
reporting.
3 Inventory Database
The inventory database is considered one of the most important systems within the
revenue assurance data family. This database will maintain physical revenue producing
resource records, as well as facility infrastructure which will be consumed as part of the
customer provisioning process.
The inventory is generated when one of the following conditions occur:


A new facility is constructed
New routers/ports are installed
A “Z” file occurs when local databases are creating using input from a master database. The data is further used
and may be put into additional database formats for other reporting, and subsequently passed to other users, who
may input the data to additional databases or spreadsheets, with the ultimate result of out of date or corrupted data.
1




New cabinets are installed
Electrical capacity is installed
Cross connect capacity is installed
Trunking/circuit capacity is installed
Customer provisioning must be able to identify “consumable” network resources prior
to planning installation and activation for a revenue producing customer. Network
inventory must reflect a condition of “available for provisioning” in the inventory
database for customer provisioning to assign and design against those resources.
Inventory is consumed when one of the following conditions occurs:




Router or concentration ports are assigned either to internal or customer usage
Cross connects are assigned to network or customer usage
Cabinets are assigned either to customer or internal usage
Electrical power distribution points are assigned to either network or customer
usage
The workflow surrounding the inventory database is shown in Figure 2.
Figure 2. Inventory Database Workflow
The inventory database entry system must have data rules assigned which will prevent
most potential format errors from happening during order entry. This intelligence is
required to ensure database integrity. As both provisioning functions are driven by
inventory, and decision support (DSS) information is produced from the inventory
database, integrity is paramount.
Within the operations provisioning group there is a dedicated inventory manger
dedicated to maintaining the inventory database. There are also dedicated inventory
technicians planned for each operational site who will maintain the integrity of data
associated with their site.
4 Network Provisioning
Network provisioning is the assign and design function driving creation of network
resources and applying network upgrades and enhancements to the inventory resource
database. Network provisioning will also generate work orders and tasking for field
operations to install cabinets, routing hardware, and inter-machine trunking (IMTs). In
addition, Network Provisioning will also task the software integration engineers
assigned to network management and operations to update network management and
monitoring equipment such as HP OpenView.
Figure 3 shows the basic workflow driving the network provisioning process.
Figure 3. Network Provisioning Workflow
5 Customer Provisioning
Customer Provisioning is the order fulfilment function. Customer provisioning will
receive an order through the sales order entry system, and then fulfil the order based on
availability of network and facility inventory.
As the inventory database is updated with order information, and current stock is
consumed to fulfil the order, several activities will occur:




Work Packet creation. Work packets are created for distribution to field
operations for physical installation, as well as to the network management
center for management system update. Local operations center management
and monitoring equipment is updated based on the field operations work packet.
Work packet decomposition is essential to ensure all order fulfilment tasks are
completed prior to the order being returned to customer provisioning for billing.
Field Operations. Completes work order physical installation and LOCC
update.
Network Management Center. Completes work packet and updates
management information systems and network surveillance system.
Inventory Database. Updates are used in maintaining information used by DSS
systems such as network engineering (to show network port utilization on



engineered platforms), operations (to give management indicators on amount of
workload being sent to field locations – used for staffing and planning, as well
as installation interval KPIs), and management DSS systems for use in
measuring the following
o Installation trends
o Product trends
o Installation intervals
o Location information
o Facility space planning
o Capital cost forecasting
o Etc
Customer information database. Updated to add the customer and customer
profiles to the customer information database. This database is used for a
variety of requirements such as:
o Management system reference
o Trouble ticketing reference
o Billing system reference
o Extranet security and directory information
Billing System. In most cases a customer cannot be billed until order fulfilment
is complete. When work force management returns a completed work order for
both network management integration, as well as field installation, then the
customer records are updated and billing can begin.
Decision Support Systems. As COMPANY “A” grows, additional reporting
requirements based on management “dashboard” performance reporting, 2nd and
3rd tier KPI and SPC reporting, as well as adhoc corporate performance
reporting will rely on good customer provisioning information to create those
essential decision support system components.
Customer provisioning workflow is presented in Figure 4.
Figure 4. Customer Provisioning Workflow
6 Trouble Management
The trouble management system will use data from several different sources, as well as
create new data. The source of data for customer and network profiles will come
primarily from the customer information database, with additional input from the
inventory database. Information created during the course of producing trouble tickets
is located in a database external to customer information and inventory, however all
data elements are required for successful processing of trouble tickets.
Trouble tickets require several features, including:









Ability to “pass” the ticket to a variety of fix or hold agencies such as
o Network management center
o Field operations
o Technical support
o Engineering
Timed alerts or warnings to prompt action from “fix” agencies
Ability to easily link network configuration, topology, and customer
information to the trouble ticket
Complete customer contact information
Prioritization of trouble tickets
Ability to administratively hold trouble ticket processing
Ability to track time to restore, close, or hold tickets based on fix agency
responsible for managing the ticket
Support updates and extended comments field for input to the system.
Provide automatic alerting via pager, mobile phone, and email for customer
flagged as “hotlist” or special care
As trouble ticket information has considerable for management data from the tickets
will have significant input to decision support systems. DSS will use data from trouble
tickets to produce statistics and management data related to:






Network performance (cause codes)
Product performance (cause codes/product codes)
Personnel training and performance
MTTR data
MTBF data for vendor equipment and systems
Customer/chronic failure data
The trouble ticket system must also be able to discriminate between internal
COMPANY “A” generated trouble tickets for IT related systems, as well as network or
customer tickets. He basic workflow for trouble ticket systems is in Figure 5.
Figure 5. Trouble Management System Workflow
7 Marketing Support
Marketing support systems will come in two different varieties, a public website and
secured customer information and support site. Both will look out towards the Internet,
and have both public perception and security considerations.
For the public web site, COMPANY “A” will need to either staff web site development
with internal MARCOM staff, or outsource the actual marketing material to an external
agency. In either case, COMPANY “A” will need to manage and maintain the physical
hosting equipment, as well as the web/HTTP server application. In addition, depending
on the nature and extent of marketing’s implementation of our public web site, we will
need support for the following applications:





HTTP for standard web server applications
Web based email support for customer enquiries
Streaming video server application for online multimedia presentations
Extensive Java/Javascript code support for enhanced marketing applications
Macromedia Flash/shockwave support for multimedia applications
In most cases, if MARCOM is outsourced, those applications are provided by the
outsource company under COMPANY “A” license.
Customer Information and Support Site
This site is more complicated than the public web site, but is considered an essential
feature for COMPANY “A” to provide the market. This site will give customers access
to a variety of their COMPANY “A” interconnection information such as:




Network performance data
Port utilization
Billing information
Customer information and update information


Overall network health data, including peering and other network
interconnection health data (as determined by COMPANY “A” policy and
customer concurrence)
Other information as developed by COMPANY “A” MARCOM
The information flow for the customer information and support system is shown in
figure 6.
The Customer Information and Support Site does present a significant risk to the
COMPANY “A” OSS Intranet. As live data must be presented through the Internet
firewall, security is a grave concern. The actual presentation of data, whether live
through direct API access to the source database, or through a correlation/CDW
architecture is not yet fully defined.
This type of access to customer data is considered an essential application by the
Internet Service Provider market.
Figure 6. Customer Information and Support Site Data Flow and Architecture
8 Billing and Accounting Systems
Billing and Accounting systems are essential to the COMPANY “A” business, however
they are not included in this document. The CFO for COMPANY “A” will need to
provide guidance to IT regarding which systems CFO determines appropriate for
implementation within COMPANY “A”.
There are some items within the CFO systems requiring either open data or open APIs.
Those systems are used to either integrate or support:


Customer access to online billing information
Updates to customer profile information
Planning for those open “hooks” into the CFO data systems will ensure our ability to
provide that “world class” application to our customers.
9 Sales Force Automation
Sales force automation components are envisioned at a mid-term implementation of our
overall data architecture. Major components of the sales force automation plan include:




Contact Management
Opportunity Profiling
Order Entry Interfaces
Online inventory and batch inventory management
While the sales force automation process is expected to evolve considerably based on
new product development and process requirements, the above items will at least give
our sales force the basic tools they need to prepare for, and execute customer orders
either locally or from the field.
Contact management systems are probably the most basic requirements or the sales
force. If properly designed, this system can also be used to populate the initial
customer information database. Customer contacts can be assigned customer reference
numbers which are available as key fields for all further customer processing.
The customer information database must be available online via the COMPANY “A”
Intranet, and information available for batch download into laptop or desktop computer
“briefcases.” Contact management software should also include an Intra/Internet
search facility for further customer research by sales staff when needed.
Opportunity profiling. This facility allows sales staff to enhance their ability to
complete background research on potential customer opportunities. The opportunity
profiling system will include a series of scripts that allow the sales account manager to
place a single argument, such as stock symbol, company name, or other identifying
feature, and apply that to a pre-scripted routine that builds a customer profile. This
profile is then used by the sales account manager as pre-meeting research for
supporting a sales or account call.
The order entry interface will allow the sales account manager to execute the first step
in the book-to-bank process. The order entry form will need to interface with a number
of potentially separate databases, such as:




Inventory
Customer Information
Customer provisioning
Work Force Management (scheduling)
The order entry system should ensure orders placed online have sufficient network
inventory to fulfil the order, or if sufficient inventory does not exist should give some
level of data on when additional network provisioning will produce work orders to
complete additional network augmentation. Once the order is accepted, the order must
trigger action by customer provisioning to fulfil the order.
As able, the customer provisioning order should also be able to give an indication of
when field and network management may be able to schedule installation into both the
management system, as well as physical/logical implementation by field operations.
Some data inter-relationships for order entry are shown in figure 7.
Figure 7. Order Entry System
In the short-term sales account managers should be able to download batch or online
inventory data to support negotiations with potential customers. Our experience shows
that most difficulties observed in fulfilling customer orders happen when the sales
account manager is not able to correctly represent inventory levels, and order fulfilment
cannot occur within service level agreement timeframes.
10 Summary
This document includes descriptions and requirements for most revenue assurance
support systems, with the exception of direct CFO support systems. The book-to-bank
process includes all systems from inventory through customer provisioning. Once the
CFO systems are defined, we can continue our final planning and engineering of
customer management, provisioning, and support workflow and integration.