Utility Industry is undergoing a rapid change due to regulations and change to ownership structures. In today's scenario the top 3 concern for the industry would be:

1. Reliability requirement

2. Regulation Uncertainty &

3. Long term investment

Over 40% of the Utility Companies will have IT systems that are at or end of planned useful life! Legacy systems have been 'Built to Last' and not 'Built to change'; but the changes in regulation and ownership structure require major changes to these systems.

Hence investments for robust future proof landscape are the norms of the day. Based on the personal experience of the author, an attempt has been made to highlight key focus areas that require specific attention during an ERP implementation program by a Utility company as part of their business transformation exercise.

ERP Implementation -- Project Phase & Key Focus area

• 1. Preparation
  • 1.1 Align to the ERP Product Roadmap; go with latest available version
    • There is a general tendency to adopt 'current release minus 1', with the belief that such versions are more stable. We believe in adopting the latest enhancement packs. By adopting a robust testing strategy, we will be able to identify and rectify any product deficiency during the project life cycle.

    • The latest releases from ERP package vendors are filling more white spaces than before. Instead of building custom functionality in 'current release minus 1' it is advisable to use standard functionality in 'current release'

  • 1.2 Don't postpone Data Archiving; plan from day one
    • Utility industry being data intensive (AMI or otherwise), it will not take much time to realize the need for Archiving. The massive amount of daily meter read data, billing and invoicing data, payments and financial data and customer service data is enough to impact system performance within months of going live

  • 1.3 Identify reporting requirement; Plan to achieve in Business Blueprint
    • Performance Prediction for every 'ask of customer' is critical in designing a business process. 'Defining' the Business Process should go hand in hand with 'Measuring' the 'Critical to Quality' parameters to ensure 'Analysis' to help us take corrective actions.

  • 1.4 Communication Plan; start from day-one
    • Goal of Communication Strategy is to raise awareness within the organization on project's mission, strategy & goals; right information to the right people at right time can be your recipe for acceptance and success of the project

  • 1.5 Sponsorship
    • Ensure you have sponsorship from the highest levels and don't forget to make it visible throughout the lifecycle.

• 2. Design
  • 2.1 Align to the chosen ERP Product's Roadmap; verify support & development road map for individual module before adoption
    • As an example, many ERP vendors are bringing in utility industry specific enhancements, reports and user interfaces in the latest versions whereas some of the vanilla features are becoming obsolete.

    • Support for AMI functionality is being continuously evolved by ERP Vendors with each new release. Utilities can synchronize the roll-out of AMI functionality with their ERP's development roadmap on AMI.

  • 2.2 Consideration for system performance; right-sizing hardware sizing
    • System Performance in critical for acceptance by end users. Get your design principle right: Low Risk -- Leading edge but not "bleeding-edge"; Availability; Recoverability; Scalability and Contingency; Manageability; Supportability

    • Provide specific focus on systems exposed to end customer (Customer Self Service Portal, and Customer Mobility Solutions). Customer experience over such systems can reduce call to your call centers.

    • Envisage upcoming regulatory and competition driven changes to the system and allow space to scale for such changes. Such changes often result in increased system load.

  • 2.3 Data Quality Check; it is never too early!
    • Typical Utility companies have operational data records, especially asset data, which are 30 or even 50 years old. Standard Data Validations built in the software can make the upload impossible if not corrected. Correcting them, especially asset data, require physical verifications of assets which are geographically spread over 100s of KM. Many a times, it may be prohibitively costly and we have to migrate data in AS-IS condition. Knowledge of data quality can influence the system and process design

    • As part of data profiling, focus on relationship with data. E.g.: A Manufacturer may make only specific Meter Models; Serial number pattern may have definite correlation with model and type, etc

    • Invest in additional data quality software like Human Inference which can validate data at the first entry point into the system (e.g. correct postal code while creating a new customer's address). Good data quality goes a long way in keeping maintenance costs low.

  • 2.4 Adopt Change Management and leverage Best Practices offered within chosen ERP
    • Limit number of customized development to the minimum; adopt standard business processes provided by the ERP as long as company's 'Critical to Quality' parameters are met.

    • Customized development can bring additional need of development and testing time during implementation. The effort needed to maintain such development is 25 times the development effort during its life time!

    • Adopt partner products which are certified by your ERP vendor to fill functionality gaps instead of complex customized self-development. Examples include certified bill print products.

  • 2.5 Get your Design Principles documented; before starting TO-BE design
    • Ensure you cover all aspects of the program while developing Design Principles. Following is a partial list:
      • Architecture (and Architecture Governance) Principles

      • Business Principles

      • Data and Information Principles

      • Security Principle

      • Operations and Systems Governance Principles

      • Technical Principles -- IS and Application Architecture

      • Technical Principles -- Integration

      • Technical Principles -- Infrastructure

    • For every design principle, in addition to the 'statement' of Principle document 'Motivation', 'implication' and corresponding 'Assurance'. Following is an illustration of one Design Principle: Auditability of business and security-related transactions
      • Statement: - It must be possible to audit all business transactions and security activities on the implemented ERP system

      • Motivation: Regulatory compliance demands auditability of financial information and corporate results

      • Implication: The Solution must be able to provide an audit trail of financial (and other) transactions, tied back to an individual

      • Assurance: User Acceptance Testing should include tests of auditing capability

  • 2.6 Business Reports and Analytics; Start afresh
    • Do not start with existing report to define to-be reports; start with KPIs and what to measure. Do this at the blueprint phase itself to ensure we capture right data at right time in the business process cycle

• Build and Test
  • 3.1 Business process owner; Be involved
    • Completion of the design and signing off the business process to be implemented is just the beginning for involvement by Business process owners. As the system configuration work is carried out by consultants, ensure all 'what if'/ processes variants are covered. Don't wait for User Acceptance phase to realize exceptions

    • Configuration involves taking decision on 'production' data and its naming convention. Whether it is the number of general ledger or naming your plants/ storage location, the source of such data has to be Business Users.

  • 3.2 Change Configuration while you do enhancement
    • It is not always practical to complete the configuration before starting the Customer development; Customer development evolves during the development cycle. Hence don't be too rigid on Configuration process. Needless to say, a final configuration check is needed at the completion of Development Phase

    • Integration with external systems may not go hand-in-hand with our plan; leave sufficient lead time in your plan to ensure at least the field level changes and the corresponding configurations

  • 3.3 Testing Strategy; be elaborate
    • Though Testing Strategy is typically developed during the Blueprint Phase, ensure you revisit the same few weeks before the testing cycle. Change to strategy may be required, depending on progress we are making on system availability, Integration requirements, data quality, etc

    • Tools can give you only 'Best Guess' when it comes to possible system performance! Ensure this is part of your testing strategy. Make it real test data and anticipated volumes

    • Concept of Security is very simple; but when you implement it with so many variants/ profile you may end up with undesirable results. Be systematic and involve Business from day-1 to define what is possible and how we are achieving this in the system.

  • 3.4 Data Migration; Migrate what you need
    • While test data load can be success, full load can only give you the big picture on data quality and performance of the system; ensure you have window for minimum of 2 full load trials before final 'live' load

    • Ensure one full load to be done with the vigor and details of a 'live' load to ensure we are confirming the cut-over process, activities and final load window

    • Ensure you migrate only operational data or data that you need to access frequently. Better place for legacy data is its archive. Please be selective and don't go by 'nice to have' approach in the selecting the data

    • To ease data migration certain simplifications will help. For example if there are too many open items, it better to run clearing and then migrate. Similarly if deepest level of granular data is not required then summarization can be performed and only summary records can be migrated.

  • 3.5 Integration
    • All the legacy systems that will continue to perform should be a part of integration & testing. Due to process continuity across the landscape, just a working ERP system with non-performing connectivity to other business system will mar the overall acceptance of the ERP by new users

    • All 3^rd party systems should be a part of integration & testing. Utility specific systems like Work Management, GIS or interfaces to collections, payments etc. should be complete to support end-to-end business process in the live ERP environment.

• Final Preparation
  • 4.1 User Acceptance -- Start Yesterday!
    • Do not wait till user acceptance test to expose the ERP system to the end users. The Screen and navigation may look very complex for beginners. First impression can last too long. Early visibility on the system via Pilot room, Demo session, etc will go a long way in getting acceptance from the users.

    • Ensure Test Scenarios are written quite in advance before User Acceptance test, but after the users have undergone basic ERP training on the subject/ module. Validate the scenarios for adherence to agreed process before commencement of user acceptance test.

  • 4.2 Training is crucial -- when and who?
    • What is the right time to train the end users? Just before go-live or some time before to give opportunity to practice in sand box? Critical question to be answered based on change management and organizational history. In Author's experience, prefer to provide training in advance with a refresher course just before go-live.

    • Who can deliver training to end user better? Consultants or trained Super Users? In Author's experience, the Super users are able to bring the right connect and business context while training and hence Train the Trainer approach can be adopted.

    • Training to call center agents is best imparted by customer's in-house training team as it involves nuances of UI browsing, shortcuts etc. to keep call handle times as before.

  • 4.3 Flexible resource / back-up / buffer -- cutover specific
    • Allow buffer in availability of Business during cut-over period; quick data fix/decision for errors in data cutover is critical for successful go-live.

    • Especially in Global Delivery model, ensure the consulting partner to be co-located during the cutover to ensure faster decision/ change process.

• Go-Live
  • 5.1 Big-bang or drip feed?
    • As the number of customers affected is in millions in a typical Billing solution implementation, Author's experience suggest going with small set of customer and stabilizing it before migration rest of the customers. One of the preferred approaches would be:

    • Start with a Pilot Implementation
      • Your employees as Customer may be the first lot.

    • Subsequent release in staged
      • By geographical regions

      • By type of customer / Billing complexity

      • Give 2 calendar month gap between 2 migrations

    • Selecting what set of customers to migrate in what sequence is an important decision in phased approach. Strategies like customers who have their billing cycle far in future can be selected last for migration. Or customers having least open items or no records with collection agencies can be grouped together and migrated first.
      • What you should not: Migrate Industrial Customer before system stabilization.

  • 5.2 Crack Team; a must have
    • Develop a crack team with high skill levels who have done this before 'many' times; Ensure dress rehearsal based on documented cutover plan to build confidence of succeeding.

  • 5.3 Go-Live Acceptance
    • Be Prepared to go live without every bug resolved -- define a threshold level for acceptance of the solution for productionizing the system; in Author's experience, no go live can happen with all bugs identified and resolved.

  • 5.4 Consulting Partner
    • When migration is done in stages, ensure same consulting partner will continue till all migration process is complete.

    • Ensure Support transition in-house/ other vendor after defined stabilization period/ parameters.

    • If the support team is different, ensure you plan KT even early; it is recommended to keep the original vendor till all migration activities are completed and stabilized to predefined levels.

While the check list can help, it will always remain incomplete! Experience brought in by individual consultants in the program is what is going to make the program successful. So before you embark on your journey, choose the right partner, have a say in who is on-boarded in your program and ensure they bring their learning & most importantly, adopting it into your program.

Other Posts by: Sathyanarayana Krishnamurthy

Related Posts

Comments