For the past ten years, I have always made an assumption that, no matter what investment an organisation has made in process-centric software, most of the day to day logic resides in Excel spreadsheets. Millions of pounds invested in ERP and CRM, and its the spreadsheets squirrelled around the place where the business really happens.
There are a number of risks associated with this. First of all, there is no audit trail in spreadsheets. Secondly, there is no ability for more than one user to access the same file at the same time, so files tend to multiply.
In the new world of browser-delivered business applications, multi-user, version-controlled spreadsheets might not only address the problems of Excel described above, but may even end the need for bespoke development. To understand why, one needs to look at why Excel has emerged into its powerful yet clandestine role that it has today, and also at how organisations could be making decisions about technology investment into the future.
Why is Excel so powerful? Well, generally because organisations have made huge investment into process-centred IT into which business processes are hard-baked. Changing your business process then involves making fundamental changes to software, which costs money, takes forever, and is outside of the control of the business unit which is trying to change. In steps Excel using which the business remodels itself, and the process-centred system festers, being used only half-heartedly.
When I worked at the BBC, there was a project which, having been specified around a set of processes which involved a single supplier, was shot to pieces before it even launched when a regulatory change scaled the suppliers from one to in excess of 200. The hard-baked processes documented were out of date before the system arrived.
However, there is something more fundamental to consider here: if you are going to encapsulate business processes into software, which should you choose, and what software approaches should you take?
There are two, two-by-two matrices (the consultant’s favourite!) that I’ve seen to help address this question – John Ward and Joe Peppard’s, and Geoffrey Moore’s. I’ve tried to pull the two together to something that has made sense for me.
Business functions loosely fall into one of four categories, based on two dimensions – whether something sets you apart from your competitors (“Market differentiating”) or not (“Non-differentiating”); and whether you have decided that that function is a “Core” activity (in that it generates value for your and/or your clients) or not (it’s basically a cost). Ultimately, what is seen as core activity is at the heart of an organisation’s strategic direction.
The four quadrants determine different approaches to how technology support should be given:
Non-core, non-differentiating functions are basically your cost centres – transactional activity that every organisation needs to do to exist, but don’t offer any great benefit. This includes accounts payable and receivable, payroll, IT systems management, often facilities and so on. In all of these areas, the first question that should be asked is whether the organisation should be doing the activity itself at all? In most instances, these are areas in which there are economies of scale to be made, and opportunities for services to be improved through finding partners for whom this is their business. Running an email system these days is best left to a Cloud provider, for example. Running payroll is best left to the professionals….
Non-core, potentially differentiating functions are basically a company’s R&D activities. Here, there is potential opportunity to create new services or products but, unless you are in the game of software development, it’s unlikely that much above standard collaboration and office tools would be required.
Core, non-differentiating functions are the things that you and your market competitors all have to do, but are unlikely to set yourself apart on; in my company’s case, this is mostly about the generation of content – and here we buy in tools (mostly for us from Adobe) to perform that task. CRM might be another example, and packaged solutions (or SaaS) are the route forward. Especially if it’s a process-based activity, there is almost certainly a product out there already these days.
The final box is the interesting one – in previous models, the area where bespoke software development was seen as a likely approach. My argument would be that for most organisations these days, with the exception of those who are involved in either software development or heavy number-crunching (hedge funds and so on), market differentiation on your core functions comes from your people, and whilst enabling them to exploit collaboration tools effectively will be of huge value, there is little software development to be done.
One final thought on this for now. I wrote recently about the merging of the transformational elements of HR and IT roles. Looking to the future, the goal for this kind of transformational, collaboration function should be to help an organisation improve its ability to deliver in the top left-hand quadrant: at best, to actually be in that top left-hand quadrant. Helping people to use collaborative tools in innovate ways to set out from the competition; recruiting the right (not necessarily though just “the best”) people; helping teams to function at the best of their ability.
Thanks to Phil for the conversation at lunch yesterday that help me to gel some of this stuff together (I think!).
mmitII 