Skip to Content

Complex Integration scenarios and integration design patterns

This blog is a part of a series of blogs around SAP Industry Solution for Utilities. You can find the main blog here. In this blog, we will discuss about some of the complex integration scenarios that we have to deal in the utilities business processes especially around Outage Management and Restoration.

Before we proceed further, please read this fine print. All the views provided below are my personal opinion and doesn’t necessarily reflect my employer’s. I work for my employer as a Netweaver Integration consultant with a focus in Utilities Industry but every customer’s requirement is unique and you should definitely seek for professional opinion before making your business decisions. Treat the inputs in this blog series as just opinions, nothing more, nothing less.

All of us have faced an utility outage situation at some point in our life. For e.g., a thunder storm can knock down power lines impacting thousands of customers in a single event. Such a wide spread outage event is a big deal for utilities because they are mandated by regulators to restore the outages within a stipulated period of time. Also, an outage means lost revenue. So the utilities are under constant pressure to detect the source of outage, organize the field crew and restore power as soon as they can. As customers, we don’t realize how complex the outage restoration process really is. Let me explain this with an example.

Assume that you live in a high rise condo that has 200 apartments. Consider an electric pole goes down in your street because of a thunder storm. This means all the customers who are downstream that pole will lose electric power. Now, if you happen to be one of those customers, you would first check your fuse and if everything is in order, report an outage to the utility. What you don’t know at the point is all the 200 customers in your condo and other customers down the street will be reporting an outage with the utility. What seems like an outage incident for 200 customers can actually be solved by fixing one single pole and here is where the utility needs to smart about dispatching it’s crew to fix it. It cannot raise 200 odd service orders for the field crew to fix the outage whereas it only needs to create one. To achieve this, Utilities generally use multiple systems to triangulate the issue and resolve the outage. These systems are –

Interactive Voice Response (IVR) – During an outage scenario, this is the first system you will encounter as a customer. The IVR system usually integrates with the customer information system (in our case SAP ECC – IS/U) to identify your account information (for e.g. based on your registered phone number) and once identified, it registers your outage as an incident or trouble ticket in an outage management system (more on this later)

Customer self service portal – If you are like me who has very little patience for recorded messages, utilities provide a self service portal for reporting outages as well. This could be a web portal where customer’s can log in to report outages or other communication channels like web chat, SMS or emails. Of course, smart phones play a major role in this.

Customer Relationship Management – Sometimes an outage could be an emergency event as well. For e.g., a live wire because of a pole going down creates electric shock hazard and in such cases, the customer may have to speak to a customer service agent so that they can dispatch a field crew immediately to fix it. The customer service agent will have access the customer information through SAP CRM system.

Outage Management System (OMS) – These are pretty sophisticated piece of software that is capable of taking inputs from SCADA (Supervisory Control and Data Acquisition) systems, AMI (Advanced Metering Infrastructure) systems etc and coupled with the various outage incidents reported by customers to predict the reason for the outage. Once predicted, it also tries to predict the expected restoration time for the outage. Then it sends work orders to the work management system so as to mobilize the field crews to fix the outage.

Geographical Information Systems (GIS) – The GIS system provides geo-spatial information about the various utility nodes. This information is vital in triangulating the source of the outage so that the field crew can be provided with enough information to identify the location of outage.

Work Management System(WMS) – These systems are used to manage the work for both outage restoration and non outage scenarios. In the context of outage restoration, they also deal with scheduling of various field crews including emergency field crews. It also integrates with mobile work management systems to capture the latest status on the outage restoration work so that it can relay back the realistic expected restoration back to customer information and outage management systems.

In an SAP implementation, at a bare minimum, we have to integrate the backend SAP ECC system with the systems listed above so that outages can be identified and fixed in time. Usually there are other systems like Fleet Management, Complex scheduling systems etc. but for the purpose of simplicity, we will only deal with integration with the above systems.


Outage System Centric

In this approach, all customer incident calls are routed to the outage management system (OMS). The OMS system aggregates all the reported incidents and coupled with the outages reported from SCADA, AMI systems etc, is able to pin point the reason and location of the outage. Based on the outage node, it is also able to determine the all the customers (or devices) that are impacted because of this outage. Once an outage has been identified, a work order is generated and sent to the work management system. The work order will have the information about the location of the outage, nature of outage, priority etc. The work management system in turn schedules the work and assign required field personnel to a particular work order (based on their schedules). The field personnel, while working on the outage, will also constantly report the expected restoration time to the work management system which in turn is updated in to the outage management system as well. If the customer calls regarding the status of the outage, the OMS system is able to provide them with the latest restoration time reported.

OMSCentric.pngCustomer System Centric

In this approach, all customer incident calls are routed through the customer information system, that is the SAP ECC system. The SAP system in turn will integrate with the OMS system to either report an incident or if already reported, get the initial expected restoration time. The SAP ECC system will also create the work order for the work management system and receive the status of the work orders from the work order management system to report the expected restoration time to the customer.


The biggest advantage of customer system centric approach is that the various integration artifacts and interfaces built between the SAP ECC system and the work management system can be re-used for non outage work order management processes as well. Also, since customer data resides in the customer system, it makes sense to route all customer incidents through this system.

On the other hand, the biggest advantage of outage system centric approach is the improved system performance whereby you are reducing the number of hops required to report outages. Also, depending on your implementation strategy, your call center will need all the processing power in the customer system to deal with customer calls, so it may make sense to route all other traffic, such as the ones through the IVR system to the OMS system.

Choosing an approach is purely dependent on your unique situation but one thing is for sure, the option you chose must meet the expectations set up by the regulators to handle the large call volumes during an outage situation. Not only customers want to report outages easily, it is also important to report the expected restoration time as accurately as possible and the outage restored as early as possible.

Utilities are known to use best of breed applications to deal with specific business process. As seen in this blog, they use field management systems for the field crew, work order management systems for work management, outage management systems for outage management, customer information systems (like SAP IS-U) for customer management, call center management system like SAP CRM etc. With best of breed systems come integration challenges but keeping a holistic view of the business process and innovative use of technology, it is possible to build seamless integration with these systems so that customers get the best service from utilities.

You must be Logged on to comment or reply to a post.
  • Hi Krishna,

    Nice and very detalied writing.

    I have worked on few large Utility project/support on NW and based on that I believe, you have covered only one integration scenario (Outage) , there are lot more (e.g.- Collection,Metering,Sourcing…),hope you will share on these.

    I am also very eager to have your next blog on error handling fremework…

    • Yes, there are lot more scenarios but this one keeps coming up in every implementation and is considered very complex and critical as it deals some SLAs for the utility. Yes, there are other complex scenarios in DM/AMI/FICA/WM.

      thanks for your comments, the error handling framework blog should be out in a week or so.

  • Hi Krishna,

    Great insight to the subject.

    I would appreciate if you let me know few details and best practices of going about the Outage System Centric Integration. In our scenario, we receive thousands calls and complaints daily regarding outages and faults which lands at our SAP CRM System. We now want to integrate SAP CRM with our Outage Management System for which I see two possibilities.

    1. Service based, using SAP PI
    2. Using BAPIs

    1. Service based, using SAP PI: For our outage complaint or other Inquires CRM system has to query or log a ticket in the Outage Management System (OMS). Since the number of complaints/Inquires is high, the overall transactions via SAP PI grows and hence would cost a lot in terms of PI Sizing Licensing Cost.

    Also in case of logging a ticket in OMS, OMS has to communicate the status of the ticket to CRM every time it changes e.g. Crew changes status of a ticket from New to In-Process and hence again it results in the increase in the number of transactions via SAP PI.

    2. Using BAPIs: I am not very much familiar with ABAP and BAPIs but I read somewhere that OMS’s Web Services can be raised in BAPIs written in SAP CRM and vice versa. The only difficulty I see in this approach is the ‘Message Mapping’ and Interface Mappings which would still need to be done in case of SAP PI Approach but BAPIs approach would save us licensing cost.

    Can you enlighten me as to how weigh one over the other? The trade-offs? Robustness of each approach? Cost? Manageability? Etc.

    Any input would be much appreciated.


    Adil Khalil

    • Adil, all the OMS systems I have integrated to are non-SAP systems. If that is true in your case, you can’t use BAPIs. Your question is about an overall integration strategy – middleware based approach or point to point. Both has it’s pros and cons – reusability, centralized monitoring and error handling, interface governance, ease of development, maintenance etc. I can’t comment on the licensing costs, but in your case, I would suggest do a pro and con analysis on your specific situation and chose the option that is most suited for your requirements. In my experience, I have always used services based approach and only go point-to-point as an exception (for e.g., payload volume is huge)

      • If that is true in your case, you can’t use BAPIs..




        I have always used services based approach and only go point-to-point as an exception (for e.g., payload volume is huge)

        Thank you Krishnakumar for your response.

        Please elaborate on this a little.

        1. We shouldn’t use BAPIs or CAN’T use BAPIs?
        2. By Service Based integration do you mean mediated (using a Middleware) or Application to Application?
        3. If mediated, what middleware did you use? Can I not go with Fusion Middleware and to not use SAP PI?


        Adil Khalil

  • Thank you Krishnakumar

    This is a very interesting article and gave me some guidance on the  2 views .

    I am have designed  and implemented  the interfaces between SAP ISU / PM  and OMS

    using SAP PI . (API Messages)

    Are there any other implementations that you are aware of that are in design stage .

    I am hoping to move to a new project .