Improving Outsourced CIS/Billing for Utilities

Marc Tannenbaum | Apr 07, 2003

Share/Save  
You made the decision to outsource your CIS and billing. You have gone as far as selecting an Application Service Provider (ASP) after a brief selection process. The final and most critical phase is the contract.

Contracting is more than just price. It is about the specifics of service and delivery, performance metrics and reporting, and process and coordination. You will hammer out the detailed requirements to be fulfilled by both sides and the roles and responsibilities that will make the business processes work successfully. Although they are key components of a successful service relationship, roles and responsibilities may be the most difficult to define and receive the least attention.

Undocumented assumptions can be relationship killers
The mistake many organizations make is that they neglect to define the roles and responsibilities required to make the relationship successful. Instead, they assume that the vendor will perform certain tasks based on a lightweight set of responsibilities defined in a boilerplate contract. Later, as the undocumented assumptions are disproved, problems develop, fingers are pointed, and requests for changes are made late in the game.

Gaps in accountability are often identified when a failure has reached a critical state. At that point, you may be months into your contracted agreement and you have few alternatives. It becomes extremely difficult to negotiate with the ASP about accountability that falls into the “gray zone” between the two of you. This is particularly true when the provider perceives the problem as potentially impacting their service levels or negatively impacting the economics of the deal.

The discussion is often accompanied by both parties denying problem ownership, and is typically follow by acrimony and rapid decline in satisfaction with the ASP services. The ASP will often refer back to the contract to prove that what the client expects of them is not in the agreement, and that the problem resulted from a faulty assumption on the client’s part. Dissatisfaction will most likely cascade into your customer base because of failed enrollments, erroneous bills, and a lack of corrective action.

It all comes back to process definition, defined performance metrics, accountability, and the related assumptions about who performs which roles.

Roles and responsibilities in an outsource arrangement need to be addressed as explicitly as possible in the initial contract to avoid reopening negotiations due to scope creep. You will need to clearly and precisely define accountability for the full spectrum of business processes from end-to-end. Based on those definitions, you can clarify the performance metrics that will drive your Service Level Agreement (SLA) with your new service provider.

The roles and responsibilities document should be included as part of the contract. It will clearly identify:

  • Who is accountable for which business and technical activities
  • The metrics used for gauging effectiveness
  • Definitions of acceptable quality and tolerance levels that define success
  • Timeframes allowable to insure fluid business processes in accordance with market rules and your internal business needs
  • Reporting for monitoring performance in each category, business activity, and role (to include timeliness and frequency of reporting)
  • Defined timeframes for “curing” any quality or performance related issues
  • Consequences for non-fulfillment, i.e., not achieving the business definition of “quality” or “success”

Ideally, you should begin mapping your current and expected business processes long before you enter into negotiation with your ASP. The more knowledgeable you are of what is needed, the greater leverage you will have in defining the parameters of the contract.

Two sides to every relationship, and then some
The problem must be looked at from both an internal (your business) and external (the ASP’s business) viewpoints, in other words, those tasks for which your organization will maintain responsibility, those belonging to the ASP, and those that are shared. Within those views, you need to designate both business and technology responsibilities and the type of behavior that is acceptable for a variety of scenarios.

It is a two-way street because you are building a co-dependence. Failure by either party to fulfill its obligations can lead to the other being unable to meet their SLA in critical areas. The ASP essentially becomes an extension of your IT, Billing, Customer Service, and Accounting departments, the depth of which depends upon the levels of service that you acquire.

For instance, trying to roll out your new product without consulting with the ASP about the cost, effort, and schedule may affect their capacity to support your timeframe. It may alter your economic forecast for the product, or otherwise disrupt your competitive marketing program. Likewise, an ASP who does not meet the requirement to inform you of planned outages may impact your customer service capabilities by disrupting call center activities.

You need to think through and plan at a detail level. Decide how each party will perform through each step of each process. Functional areas should develop a set of process scenarios for both normal and abnormal results. Each scenario has a monitoring, reporting, and action responsibility that needs to be judged from the perspective of the service level expectations of your customers, as well as the SLA you are establishing between you and your ASP.

Lets start with the major functional areas that need to be addressed:

  • End-to-end support of daily business functions for market and customer facing activities. You need to be assured that errors are not only captured, but also resolved each day and that you can track trends to identify system and process gaps, or training deficiencies whether they occur internally or within the ASP environment.
  • Accounting coordination and controls for daily, weekly, monthly, quarterly, and annual checkpoints on interfaces between systems for billing, taxation, credit and collections, and financial reporting.
  • Reconciliation of wholesale and retail commodity and revenue to insure that balances are within tolerances; of sales with expected enrollments or disconnects; of meter activity with billing activity; of error rates with correction rates; of tax collections with tax reporting. This focuses on the flow of information through the ASP to your other systems, departments, and trading partners by staying hands-on and maintaining oversight of input/output controls.
  • Reporting needs to be defined at the Executive, Operational, and Functional levels with regard to the monitoring of performance metrics. This is not only for good corporate governance, but for tracking of the SLAs that will be created between you and the ASP. Emphasis should be given to the exceptions.
  • Knowledge Transfer needs to be established. It would be extremely risky to allow a hands-off relationship with the ASP owning all the knowledge assets and controlling the market relationships. Knowledge transfer gives you insight to managing the relationship better and improving coordination without locking your business into a long-term relationship that may not serve your best interests.
  • Technical Architecture and technology decision-making needs to be defined in terms of your forward-looking business needs. It is the means by which you establish technical ownership and coordinate your internal IT functions with those of the ASP. You need to avoid overlap, contradiction, and conflict.
  • Project initiation, prioritization, scheduling, and coordination across departments including the ASP as an extension of your departments. Any new implementation, or maintenance effort needs follow your standard project initiation process.
  • Operational Support insures that both sides have a clearly defined set of procedures for technical and business support. This includes security, controls, as well as notification and correction of any outage, planned or unplanned, whether it is related to computing or telecommunications. Also included is schedule coordination for your business and market needs, or IT initiatives on either end of the equation.
  • Testing extends to all functional areas with a single point of coordination for any changes to the systems, interfaces, or reporting. This is true whether the project is a technology imperative such as a vendor upgrade to applications or hardware, a business requested change, or an initiative caused by the ASP’s internal requirements.
  • Quality Assurance must set the bar as required by the business’ definition of quality and success, whether it is related to a project or day-to-day invoice production. Both sides of the relationship have proprietary and shared responsibilities that require a standard set of QA procedures.
  • Vendor relationships need to be defined in terms of who maintains the control of the relationships, makes commitments, or contracts for services or products. This includes coordination with agents such as your ISO, scheduling entity, bill print service provider, suppliers, or other trading partner relationships. If you hand control for any relationship over to your ASP, you need to be sure that they pass information on to your internal departments. That should include the ASP’s interpretation of the information and their planned actions.
  • Other critical areas of coordination that need definition include Program Management for cross departmental coordination of projects, Problem Escalation for acute and chronic error management, and Process Mapping for continuous improvement and updating of procedures and business flow.

In every case there should be performance goals. Responsibilities should be defined for executive, departmental, and functional roles with party/counter-party definitions on either side (whenever appropriate). The party with the primary responsibility should track and report performance statistics at regular intervals to insure that performance meets the business definition of quality and success. If not met, the responsible party should follow a prescribed procedure for exception identification and corrective action within the timeframe defined in your service contract.

You need to be sure that your ASP makes all of their plans, designs, data, metrics, and reporting available, regardless of who is accountable. They must support all of your processes that rely on the ASP’s input. Likewise, you must be forthcoming with your ASP.

Manage your ASP like any other department
You should view the relationship with your ASP as a means of extending your organization’s capabilities by contracting with a shared resource. Executive and managerial focus should be directed at the performance of the ASP as if it were internal staff. It is not an opportunity for abdicating responsibility, nor is it a chance to make billing someone else’s problem.

Once you have delineated the roles and responsibilities, you and the ASP will have a clearer understanding of services, performance, and pricing. You have eliminated a critical set of assumptions by creating a broader set of facts. A more precise set of performance expectations defines your relationship. Now you can finalize your contract and get started on outsourcing your customer information and billing systems.

Related Topics

Comments

1

1