We narrow market interactions these down to two interaction types:
Operator interactions (all interactions with the market operator and its systems)
Bilateral interactions (all interactions direct between market parties not the market operator)
Operator interactions are covered extensively by the market operators (MOSL and CMA) and within the various Code documents. Here, we focus on the Bilateral interactions (whether they are formalised or not in the Wholesale-Retail Code and indeed whether they are in fact multi-lateral interactions).
Bilateral Interactions: Where we are today
These are a big issue, primarily because of two things: (a) different approaches adopted across the market and (b) the fact that retailers have to go to many different places to interact with wholesalers.
Let's look at why that is the case...
(a) Different approaches
For market opening, the Wholesale-Retail Code (WRC) inherited a range of Operational forms from the model adopted in Scotland. Although conceived as a paper/PDF form-based process, there was an appetite to encourage more efficient ways of information transfer.
Digital standards were created, much like the ones for market transactions. The standards were optional - a necessary compromise to get some level of acceptance but an uncomfortable state for anyone considering investing in digital exchange. The transport standard was also a compromise: the Key-Value Pair approach may facilitate dynamic changes in structure while the market goes through stabilisation but it was another risk to those looking to build with confidence. The lack of formality meant that there was no uniformity in how these interactions work, hence the different ways of working.
(b) Many different places
While emphasis was on getting ready for the market, wholesalers needed to do something to help them manage these interactions and in the absence of a common approach, it was natural that they looked at what was within their own control.
The best reference point was Scottish Water's retailer portal for the Scottish market and most wholesalers developed something similar, where retailers could submit forms and so on. In itself, that is all logical and understandable but the issue that retailers face is that there are many versions of these. This means that to service one national customer, a retailer may need to access 20 or more different systems.
There is another subtle element to this - there simply wasn't a consensus on what was needed. The requirements of a wholesaler are quite different to those of a retailer; new entrant retailers have a far greater appetite for manual entry, given the smaller portfolios they manage than their larger competitors. So, although the case for a single solution was clear, the specifics of what it might look like were not.
Bilateral Interactions: What is being done about it?
The Digital Strategy Committee (DSC), a MOSL group, has commissioned a subgroup to look at the requirements and business case for a common solution.
One of the options will surely be to use CMOS, and that has some appealing facets. CGI and The Water Report made a good case for that in the latter's January edition this year. We offer some counter points to using CMOS in our blog but it is an option that deserves consideration.
At the Utility Week/Water.Retail "Future Retail #1" event, I had the opportunity to talk with CGI about some of their vision and while it would be unfair and inappropriate to discuss that openly, there is some very interesting thinking developing.
At this stage, we understand that the subgroup is looking at requirements rather than considering specific solutions but there must be some room for solutions to inform rather than just reflect the current thinking and anything that technology providers can do to be proactive ought to be welcome.
Bilateral Interactions: Our views
A single solution
Our view remains that companies do not have the common requirements to justify a 'one size fits all' portal approach. Some companies will benefit from a dedicated system that will manage their bilateral workflows and interact with other companies - what we call Bring Your Own Portal (BYOP) solutions, such as C&C Group's SWIM product. Others may want their ERP or CRM system to manage these interactions, while some may want to perform all these transactions manually somehow.
That's not to say there shouldn't be a central solution - the need for that is clear; ask any retailer.
But we think that what is needed is something that can broker between companies, allowing each to interact with it in the way that best suits them, be that manually (LVI), through spreadsheet (MVI) or through XML interactions (HVI). Flexibility is key.
There is a place for Wholesaler portals still - these can extend and enrich the overall service provision, especially for things like booking certain services (at least until all of that is also standardised).
But it seems likely that any outcome that does not consolidate the interactions into one place will lead to an escalation by the retail community anyway.
The Five Pillars
The lack of formality to the standards has been a problem. We feel that adoption by any party of HVI (or MVI) should be optional but once adopted, one common standard should be enforced (although a central solution should transform between OSD0601/OSD0602 and any new versions to reduce re-work).
There are shortcomings in both OSD601&2 anyway so this should be an opportunity to address those.
Overall, we see five pillars that underpin effective bilateral interactions.
Formalised (and revised) standards for digital exchange (including an extended catalogue).
A usage model that means each company only uses - and pays for - what it needs.
The flexibility for companies to adopt specific capabilities at their own pace - no 'big bang' deployments.
Sophisticated work flow management capabilities to help optimise processes and SLAs.
Embedded data management techniques to reduce misalignment between corporate and market systems