Proposal for Management Integration
and
Book-to-Bank System
1 Overview
2 Basic Data Architecture
3 Inventory Database
4 Network Provisioning
5 Customer Provisioning
6 Trouble Management
7 Marketing Support
8 Billing and Accounting Systems
9 Sales Force Automation
10 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” employees[1]
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
· 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