Almost unanimously, it tops the innovation agenda of every Utility Retailer executive- Reducing the time to market new energy and energy related products. Every modern Utility uses one or the other- either home grown or from a software vendor, software solutions to run their business. Why is it then, so hard to bring a new energy product to market?
Context
Historically almost all the Utilities were regulated and they just did what the name implied- provide ‘Utility- electricity, water, gas etc.’ to the citizens. Of course, the citizens had to pay for the Utility they consumed on a monthly, quarterly etc. basis, at a rate/tariff determined by the regulator. The tariffs normally differed with customer segments- residential, mid-size, commercial. The main task for the Utility was to be able to measure what the consumer is consuming, have a representation of the different tariffs and then charge the consumption with the suitable tariff to generate a bill. This is how the early Utilities CIS (Customer Information Systems) were designed- more or less. Terms like ‘Selling’, ‘Products’ didn’t yet debut.
Things, however, changed with De-regulation. The Utilities were no longer the default service providers in the areas they operated in, rather they had to compete with other Utilities. More importantly, this led to a ‘Mindshift’- they had to focus on ‘selling’ differentiated ‘products’ rather than just ‘billing’ a ‘tariff’. The commodity (e.g. electricity) had to be differentiated, not just on price. Hence the ‘tariff’ started to get attributes like contract duration, price guarantee, weekends free etc. Obviously, the existing CIS couldn’t handle this leading to introduction of CRM systems which focused on modelling the Utility product and selling it. The connection to ‘tariff/billing’ was lost and had to be done through integration projects between CIS and CRM. With growing importance of online channels like web, mobile, social, CRM further mutated into many different sales systems each optimizing a specific channel like web shop, call center based selling etc. As you could already guess, its more complex now and so is also introducing new products to the market. Let’s see how.
Challenge
Let’s imagine that a Utility Product manager wants to introduce a new Energy product/s in the market. Most likely she would design it in some offline tool or if she is lucky in one of the sales system perhaps. Then an IT expert, either manually or via a custom program, will ensure that similar product is set up in the different sales systems. Additionally, an IT expert with help from an SME, also must model an equivalent rate/tariff in the CIS system and ensure that the necessary integration/mapping is done to ensure that a contract with this product can be billed. Of course, this should be tested before releasing it for productive use. Given the multiplicity of the systems, manual steps and requirement of human resources of different skill sets, the whole process is slow and prone to errors. Beyond the fact that the product manager does not have a central Product application to work with, the crux of the problem lies in the fact that they are two parallel worlds: ‘Selling or CRM’ and the ‘Billing or CIS’. Both have a different view of the Utilities product which need to be aligned, often manually or through complex integration, for the complete process to work. Is there a pragmatic way out, assuming the likely scenario of the Utilities continuing to use their existing systems?
Proposed Solution
We believe the answers is ‘Yes’ with a solution that focuses on the tasks of the product manager and automates the steps that are needed to make the process work but do not add any value.
As depicted in the figure above, the main proposal is to isolate the tasks of a Product manager in a single application. The application serves as the central repository where the products/product bundles are created, managed and retried, removing the duplication of tasks across different sales systems. An important characteristic is the ability to add billing attributes (tariff e.g. x cents/kwh), in addition to the sales attributes (e.g. price guarantee), thereby establishing the connection between ‘Selling’ and ‘Billing’ world right at the time of product definition. Another crucial design consideration should be to hide the IT complexities from the product manager. The User Interface should not only be simple but should reflect the business environment that a Product manager is familiar with. Analytical capabilities to further streamline the work and decision making of the Product manager should also be considered. An example would be: The Product Manager monitoring the performance of the products e.g. which products are currently active, in which regions and how much sales/revenue they have generated so far.
The rest is designing the interfaces into existing systems that automate the non-value adding but necessary steps.
Intf1: After the product is activated, the corresponding tariff structure is generated in the billing system
Intf2: Post Product activation, the product should be distributed to the relevant sales systems including the connection to the Product app for calculating the expected price of the Product during the sales process e.g. the customer when checking out the ‘Flex24 Elec’ sees that it would cost approx. 1000€/year for consumption of 3000 kwh.
Intf3: Once a sale is done e.g. a shopping cart in web shop or a quotation/contract created by the call center agent, the sales systems passes that on to the CIS/billing system for subsequent billing. Inf3 recognizes the product, determines the relevant tariff structure generated by Intf1 and then sets up the relevant billing construct making sure the necessary market communication processes are completed if applicable
Let’s now revisit our initial challenge- A product manager wanting to introduce a new Utility product. She now goes into central product app, models the product and then activates it. Automatically, the product is available in the sales systems and equivalent tariff structure in the CIS/Billing system. While selling the product, price estimation is available. Once the product is sold, contract with the equivalent tariff structure - already created after product activation, is set up in the CIS/Billing system, ready to be billed in the next billing run. No manual steps, no dependency on IT, much better than how it works today for most Utilities.
At SAP, we decided to solve this problem for our customers. Therefore, we would like to invite you to join our co-innovation project called ‘Utilities product simplification’
Comments, feedback, questions are welcome.
Context
Historically almost all the Utilities were regulated and they just did what the name implied- provide ‘Utility- electricity, water, gas etc.’ to the citizens. Of course, the citizens had to pay for the Utility they consumed on a monthly, quarterly etc. basis, at a rate/tariff determined by the regulator. The tariffs normally differed with customer segments- residential, mid-size, commercial. The main task for the Utility was to be able to measure what the consumer is consuming, have a representation of the different tariffs and then charge the consumption with the suitable tariff to generate a bill. This is how the early Utilities CIS (Customer Information Systems) were designed- more or less. Terms like ‘Selling’, ‘Products’ didn’t yet debut.
Things, however, changed with De-regulation. The Utilities were no longer the default service providers in the areas they operated in, rather they had to compete with other Utilities. More importantly, this led to a ‘Mindshift’- they had to focus on ‘selling’ differentiated ‘products’ rather than just ‘billing’ a ‘tariff’. The commodity (e.g. electricity) had to be differentiated, not just on price. Hence the ‘tariff’ started to get attributes like contract duration, price guarantee, weekends free etc. Obviously, the existing CIS couldn’t handle this leading to introduction of CRM systems which focused on modelling the Utility product and selling it. The connection to ‘tariff/billing’ was lost and had to be done through integration projects between CIS and CRM. With growing importance of online channels like web, mobile, social, CRM further mutated into many different sales systems each optimizing a specific channel like web shop, call center based selling etc. As you could already guess, its more complex now and so is also introducing new products to the market. Let’s see how.
Challenge
Let’s imagine that a Utility Product manager wants to introduce a new Energy product/s in the market. Most likely she would design it in some offline tool or if she is lucky in one of the sales system perhaps. Then an IT expert, either manually or via a custom program, will ensure that similar product is set up in the different sales systems. Additionally, an IT expert with help from an SME, also must model an equivalent rate/tariff in the CIS system and ensure that the necessary integration/mapping is done to ensure that a contract with this product can be billed. Of course, this should be tested before releasing it for productive use. Given the multiplicity of the systems, manual steps and requirement of human resources of different skill sets, the whole process is slow and prone to errors. Beyond the fact that the product manager does not have a central Product application to work with, the crux of the problem lies in the fact that they are two parallel worlds: ‘Selling or CRM’ and the ‘Billing or CIS’. Both have a different view of the Utilities product which need to be aligned, often manually or through complex integration, for the complete process to work. Is there a pragmatic way out, assuming the likely scenario of the Utilities continuing to use their existing systems?
Proposed Solution
We believe the answers is ‘Yes’ with a solution that focuses on the tasks of the product manager and automates the steps that are needed to make the process work but do not add any value.
As depicted in the figure above, the main proposal is to isolate the tasks of a Product manager in a single application. The application serves as the central repository where the products/product bundles are created, managed and retried, removing the duplication of tasks across different sales systems. An important characteristic is the ability to add billing attributes (tariff e.g. x cents/kwh), in addition to the sales attributes (e.g. price guarantee), thereby establishing the connection between ‘Selling’ and ‘Billing’ world right at the time of product definition. Another crucial design consideration should be to hide the IT complexities from the product manager. The User Interface should not only be simple but should reflect the business environment that a Product manager is familiar with. Analytical capabilities to further streamline the work and decision making of the Product manager should also be considered. An example would be: The Product Manager monitoring the performance of the products e.g. which products are currently active, in which regions and how much sales/revenue they have generated so far.
The rest is designing the interfaces into existing systems that automate the non-value adding but necessary steps.
Intf1: After the product is activated, the corresponding tariff structure is generated in the billing system
Intf2: Post Product activation, the product should be distributed to the relevant sales systems including the connection to the Product app for calculating the expected price of the Product during the sales process e.g. the customer when checking out the ‘Flex24 Elec’ sees that it would cost approx. 1000€/year for consumption of 3000 kwh.
Intf3: Once a sale is done e.g. a shopping cart in web shop or a quotation/contract created by the call center agent, the sales systems passes that on to the CIS/billing system for subsequent billing. Inf3 recognizes the product, determines the relevant tariff structure generated by Intf1 and then sets up the relevant billing construct making sure the necessary market communication processes are completed if applicable
Let’s now revisit our initial challenge- A product manager wanting to introduce a new Utility product. She now goes into central product app, models the product and then activates it. Automatically, the product is available in the sales systems and equivalent tariff structure in the CIS/Billing system. While selling the product, price estimation is available. Once the product is sold, contract with the equivalent tariff structure - already created after product activation, is set up in the CIS/Billing system, ready to be billed in the next billing run. No manual steps, no dependency on IT, much better than how it works today for most Utilities.
At SAP, we decided to solve this problem for our customers. Therefore, we would like to invite you to join our co-innovation project called ‘Utilities product simplification’
( Note: While the registration is offically closed, you can still join by clicking the 'Contact Project Managers' link at the CEI page)
Comments, feedback, questions are welcome.
- SAP Managed Tags:
1 Comment