Jim Holincheck

Vinnie Mirchandani’s post got me thinking about business application innovation.  In my mind, the first step to identify where innovation is most appropriate.  Geoffrey Moore does a great job defining "Core" vs. "Context" in his books.  Core are the processes that provide competitive differentiation.  Context is pretty much everything else.  What is Core vs. Context will be different for every business, but it is probably appropriate to think of it as a spectrum as opposed to a discrete choice.  On the far end of the spectrum toward Context would be something like payroll.  For almost all organizations (unless you are a Professional Employer Organization – PEO – then it might be closer to Core), payroll is Context — it is a cost of doing business .  On the other end of the spectrum Core is the "secret sauce" of the business.  For Wal-Mart, that might be its supply chain processes and systems.  For Apple, it might be product design and lifecycle management.

Innovation of packaged business applications should be different at each end of the spectrum.  Innovation for Context process should focus on supporting standardization (outsourcing being probably the ultimate in standardization) and cost optimization.  Innovation for Core processes should focus on differentiation and making it easier to maintain that differentiation over time by enabling agility to allow for change as the business and environment changes.  Through this lens, Context innovation, especially for mature application areas, should move away from adding new functionality to making the existing functionality easier to use in standardization efforts.  Core innovation, by definition, cannot be done in packaged application (or if it is done in a packaged application, it is done by pioneering niche vendors for early adopter customers).  If I can do it in a packaged application, then all of my competitors can as well.

The really tricky part is that this is not static.  Over time, what is innovative (leading edge best practice) becomes a standard or accepted practice.  This leads to an interesting conclusion: established vendors should focus on adding new functionality that is transitioning from Core to Context.  So, where does that leave us?  Vendors should:

• Make it easy for customers to consume Core innovations that are either custom-developed or available from leading edge niche vendors.  Platform development and ecosystem efforts from vendors like Oracle and SAP are directed at this need.
• Develop new functionality for innovations that are transitioning from Core to Context.  Megavendors are typically fast followers (when mainstream customers want this functionality, the vendor adds it to the suite) because even if they build it, it is hard to get customers to upgrade frequently.  However, SaaS has increased the pace of this type of innovation  and it has been difficult for the megavendors to keep up (at least in the HCM world).  SAP’s enhancement packages is one strategy for addressing more rapid customer upgrades
• Context innovation should focus on making it easier to standardize processes and lowering TCO (people, process, and technology).

I would argue that Oracle and SAP have focused a lot on supporting Core innovations (though it is still a work in progress)  They continue to develop new functionality (or buy vendors that offer that new functionality) that is moving from Core to Context to keep up with the market and be "good enough" for the majority of customers. 

Ironically, Context innovations have had the least progress, but would probably be the most important to the majority of existing business application customers.  One could argue that BPO has been the biggest Context innovation (and the business application vendors have been an enabler, but not driving the innovation).  The biggest innovation I see possible here is simplification.  In mature application areas take a fresh look at the design starting from the mindset of standardization.  How can I make it easier for customers to standardize processes?  If the customer has standardized a process and does not want to change it, how can the system be designed to not impact that process during an upgrade?  These are just examples and I do not mean to pick on just Oracle and SAP.  Oracle would probably argue that its efforts around Superior Ownership Experience (the successor to PeopleSoft’s Total Ownership Experience) have helped.  It has to some degree, but customers still have angst over 22% annual maintenance fees and costly implementation and upgrade projects.  There are a lot of vendors that struggle with this issue. 

What do you think about the level of innovation in packaged business applications today?  What kinds of innovation do you expect from business application vendors?

1 Comment »

Category: Uncategorized     Tags: ERP

Share