Interesting discussion over the weekend with a few friends with C level responsibilities. People were cursing their past efficiency drives, that have boxed them in so much, that transformation costs look prohibitive as they attempt to do things different. Two things are constant : Change and Efficiency. How does one drive change in an environment that is running efficiently, and meeting customer expectations? At the outset the question sounds quiet ridiculous. If your place is running efficiently, and your customers are not complaining, why change ? We narrowed down the reasons for change in an efficient environment:
1) Aligning with eco-system changes
2) Meet the ever changing customer need that most of times goes unstated or not captured
3) Differentiate yourself from competition
Most of the guys at the bar counter cited reason 3 as the biggest driver to initiate change. Once a pioneer innovates and institutionalizes the processes to the extreme to drive inefficiencies, you have a tightly boxed in system that works like an well oiled assembly line with no need for any maintenance. It does not take much time and effort for your competition to observe and replicate. Giving the innovator the benefit of doubt, lets assume that competition does run the process less efficiently, at the end of the day, the innovator is no different from the competition anymore. They all offer the same service. Perils of service industry. One Tequila shot later, much to my delight, most of the people came around to a consensus that reason 2 is the trigger for change and not 3 - work on the customer , not your competition! More like the 3 idiots philosophy of run after excellence, success will follow. Apologies for digression, but this is how the discussion actually went into a tangent and a couple of us brought the prime issue back on the table. Does the efficiency drive kill your ability to change at reasonable costs?
Sometimes, the BI folks, who are generally at arms length from the nuances of business operations dynamics, come up with head turning stuff that becomes compelling to contemplate the change. Really good ideas that are disruptive and transformational, need the core processes to be uprooted and an invasive surgery done on the business operations to put an idea into action. To mitigate the risk of failure one decides to prototype and pilot. The costs associated with such an implementation approach are quite taxing on organizational bandwidth, time and coffers.
I though the cloud is a good way to offset some of these costs (non HR related costs). Lets say, the BI folks come up with a unique and different way to restructure mortgages that may/may-not deliver additional delight to your customers, but defiantly adds to your bottom-line without taxing the customer any more that status-quo . Your existing systems and processes are run at the best possible efficiency levels and hence are tightly coupled with the eco-system to deliver the results. How will you implement the prototype to test the concept without executing all the changes to the existing systems and processes? Will you ask your eco-system partners to participate in this change, and at what cost?
I would implement the challenger process on the cloud as a service. The only changes I would make to my IT setup would be to add integration points on my ESB to connect the service on the cloud to my data. This way I could get both the challenger and the campion process to work on the same data set ; and I now have an environment where :
1) Both the challenger and champion processes can run at the same time enabling more accurate comparison
2) They both run simultaneously on the same data set and hence I can compare results
3) I do not change my existing eco-system and hence offset the risks
4) In the event the challenger proved itself to be far more exciting and since I did not invest in changing my IT
eco-system to create the prototype, maybe I now have a more amicable scenario where one could discuss
the merits of running the process in-house or outsource it!
eco-system to create the prototype, maybe I now have a more amicable scenario where one could discuss
the merits of running the process in-house or outsource it!
Some elements of investment cannot be shied away from. To implement the prototype, there will be investment needed on re-training, re-structuring and job role re-definition. Since this is a prototype, the scale is much smaller and change management easier. Walking thru this prototype experience also sheds light on the merits/de-merits of outsourcing a successful challenger prototype.
This approach requires building the challenger process from scratch and this could be done in a loosely coupled manner. If indeed outsourcing a successful challenger seems a good choice, since the prototype was built from scratch without tinkering with the incumbent mix of legacy/non-legacy / soon-to-be-legacy systems, you have a complete BRS that could just make the RFP really informative. One could look at using the prototype build as a bargain-able asset during negotiations with the RFP contenders.
I have not had the opportunity to walk this path as yet, but it seems a good concept and a framework to keep at the back of my head.
Pearl Zhu said on October 15, 2012 12:41 PM
ReplyDeleteThanks for sharing this interesting blog. Like a few approaches recommended in the blog, such as both the challenger and champion processes can run at the same time enabling more accurate comparison. Business/IT these days at least should focus on both productivity/efficiency, and value/competitive capability, the process management may also need well capture such true value to differentiate self from competition and optimize end customer experience.
Keith Nunnery said on October 15, 2012 12:48 PM
ReplyDeleteWell said Pearl! Sometimes the word “efficiency” gets confused with “cost cutting”.
What we do is ask IT and Business to present their opinion on what problems they believe must be solved. Finding the right tools and methods at reasonable costs is part of the equation to reaching “efficiency”, as defined by the organization. However, IT moves so fast that latency in the decision-making process and execution can be problematic. Planned obsolescence is often overlooked or under estimated.
Pearl Zhu : Fair evaluation can be done only on a level playing field. Else we end up capturing our perceptions rather than data and present them at empirical evidence. IT has found it expensive to create test beds…and they end up being just that…a little away from real scenarios. With cloud technology now we could have experiments run in real life scenario and on real data parallel to incumbent processes. This not only helps in easing in new processes as a part of planned obsolescence, but also helps in trying out disruptive ideas to check if new thinking can really deliver more bang for the buck, rather than status quo.
ReplyDeleteKeith Nunnery : Thank you for sharing your thoughts. At the outset the intent of the blog post was to highlight the issues of introducing change in an highly efficient environment and the costs associated with the same. Flip side of efficiency is a highly regulated , highly coupled systems and processes that are difficult to de-link. In such a scenario the entire exercise of trying to figure out if new ideas are worth pursuing, becomes a challenging tasks. Some environments have the problem where IT is seen to be a very slow mover. Some environments are very IT savvy and the complaint is that of alignment. I guess when revenue does not flow in, support functions come under intense scrutiny. In such scenarios trying out new ideas without disrupting the status quo becomes important.
ReplyDelete