SAP for Utilities Blogs
Discover insights and practical tips to optimize operations, reduce costs, and deliver reliable energy with SAP technology. Contribute your own blog post!
cancel
Showing results for 
Search instead for 
Did you mean: 

Today is back to the future day. October 21st 2015 is the date to which Marty traveled. This was back in the 80s.

Back to the past with mobility and CRM. An industry expert recently told me how mobility worked in the 80s when a big utility in Latin America introduced mobile meter reading. At that time, paper-based processes were standard, sometimes the paper was then read by machines. Battery technology was at the stage of supporting flashlights, RC toys and starting cars. So the mobile meter reading solution consisted of a mobile computer and a 12 V car battery that would last a couple of hours, drawn on a small cart behind the meter reader. It was an advance from the past, worked well and was so much better than using paper. Synchronizing the data was rarely an issue, orders were downloaded and results were uploaded via file transfer. Data inconsistencies in the route or with exchanged and new meters required manual steps. There were no big complaints overall using this technology.

Fast forward to today when mobile devices, battery technology and mobile networks have advanced to a degree that hardware is no longer a concern. But mobile meter reading solutions still follow the same process principle: Meter reading information is replicated to a mobile device and then synchronized back to the billing system. Of course, there can be cases when data get’s out of sync. If data is replicated and distributed both ways, updates can collide. While the meter reader is in an offline mode, even if it was minutes, seconds or less, an agent in the call center could have entered another meter reading for the same meter or even changed the meter in the backend. In this case, the update would create an exception.

Is there a way to avoid or minimize these collisions? Yes, for most cases but not completely. If the data is always as fresh as possible, delayed updates are seldom. The more we move to real-time and cloud based solution, the less we delay updates. Stopping to change the same data in different systems at the same time is however more of a process issue.

Now think about your personal mobile devices. You might have noticed that sometimes for example your address book asks you to check certain entries or simply creates duplicates. This usually stems from colliding updates on your phone, tablet or laptop trying to sync. Changing the same contact, appointment, task or whatever you replicate to different applications can cause offline / online update collisions.

From the beginning, CRM, a separate system, was integrated with ECC via replication. A number of data objects like the business partner, the contract or the premise are replicated. Also since the beginning of CRM, we have the never-ending discussion about replication issues. And it seems hard to explain why in certain cases a data replication can fail and needs a user interaction and why this should be acceptable. Now I found another way to explain this.

When I see a call center agent opening 3 screens in parallel during a call and changing the same data on different screens, the same customer, the same contract or same premise at the same time, I simply say: Now imagine doing this with your mobile devices. Change the same contact, appointment, task or whatever you synchronize between those devices on your phone, tablet and laptop at the same time and see how it lines up later. That explains.

Most fundamentals never change. Where is my hoverboard?

Cheers,

Robert

Top kudoed authors