Three questions you need to ask

There's three questions you need to ask yourself before you invest a large chunk of cash in some enterprise application:

  • Can I use something, rather than configuring something, rather than customising something?
  • How will the solution support the (social) community who will use it?
  • Is there a reason why I can't buy the solution ‘on-demand’ via SaaS?

I was having a couple of beers with Peter Williams{{1}} the other day, and the topic turned to what are the important questions to consider when you're looking at purchasing some large and expensive enterprise application. Pete had three questions; two of them were ‘where does cloud fit into it’ and ‘what's the social angle’, while the third eludes me at the moment. Rolling the list over my mind in the last week though, I've decided that I like ‘can I simply use a solution, rather than heading down the expensive customisation path?’

[[1]]Peter Williams (@rexster) is the Chief Edge Officer in the Australian branch of Deloitte's Centre for the Edge[[1]]

Whenever we begin the journey toward buying some enterprise solution we usually fall back onto old habits: the acquisition, configuration, customisation and installation of some expensive on-premises enterprise application. This made sense in the comparatively slow moving business environment of the past. It makes less sense in today's rapidly changing and uncertain environment{{2}}. However we don't want to simply pounce on the new-new thing whenever we have a problem to solve, as the new-new thing is not necessarily the right thing to do in every circumstance. We need a more measured approach.

[[2]]Peter Evans-Greenwood, The New Instability, Exating[[2]]

In a changing environment the challenge is not just to learn new ideas, but also to unlearn old ideas which are no longer relevent. It's these old ideas – ideas which are no longer compatible with the environment we're working in – that prevent us from adapting. One way to unlearn is to question our assumptions, and these three questions seem to be a good place to start when we want to determine if buying a traditional on-premises enterprise application is the right thing to do.

First, there's the shift from acquiring technology to simply using technology{{3}}. Do we any to buy, to acquire, some technology? Or is it simply a tool we want to use?

[[3]]The North–South Divide @ PEG[[3]]

Our success used to rest of having the very best tools we could find as – in a slowly changing business environment – if our tools failed then we fail too. Consequently we spent a great deal of time investing in our tools, configuring and customising them to ensure that they met our particular requirements, creating complex and narrowly focused solutions that would support us in the challenges we knew we would face in the future.

In the today's rapidly changing and uncertain environment, however, our survival depends on our ability (re)combine the tools we have to create new and novel solutions. When the market shifts we need to be able to adapt, reconfiguring the technological environment around us so that we can respond to the new and unforeseen challenges we face. We want simple, flexible solutions, solutions that we can just pick up, combine and use, rather than solutions that are narrowly focused on a single task.

In terms of enterprise applications, this means adapting our business to the process and the tool that supports it, rather than worrying about configuring the tool to support a highly customised business process. In a uncertain environment the value in a organisation rests in its ability to handle and resolve exceptions, not in the straight-through process{{4}}. We need simple and uncomplicated business processes, and simple and uncomplicated applications to support them, with clear points in the process where the team responsible for it can intervene and respond to exceptions.

[[4]]BPM over promised and under delivered @ PEG[[4]]

For CRM (as an example, though we could just as well use General Ledger or Supply Chain Management) we generally only need two things: a sales pipeline (including customer records) and a sales methodology to enable us to configure the pipeline. We could engage in a long requirements gathering gathering process as we map out our unique sales process and its integration into our web of existing transactional systems. Or we could pick a ‘best of breed’ solution and pay for the Miller Heiman{{5}} or Holden International{{6}} modules. Not only does this provide us with a configured pipeline, it also enables us to call on the training and expertise of the community engaged with the sales method, a solution we would rather pickup and use rather than acquire.

[[5]]MillerHeiman.com[[5]]

[[6]]HoldenIntl.com[[6]]

Second, we want to consider the solutions support for the community of users who will flock around it. Does the solution provide social media features out of the box? Or, and even better, does the solution integrate with the social media tools that your team is already using, tools such as Yammer{{7}} or Jive{{8}}.

[[7]]Yammer.com[[7]]

[[8]]JiveSoftware.com[[8]]

As the value in our organisations has moved from the transactions it processes to the problems it solves, empowering our team to effectively communicate and collaborate is one of the most effective interventions we can make in our organisation. When confronted by a problem, a business exception or opportunity, our team needs to have the tools to communicate and collaborate within themselves, across the organisation, and even with partners, suppliers, and even customers, as they work to solve the problem. John Boyd called this ‘making snowmobiles’{{9}}, reaching around the organisation to find the ideas, the processes, data, abd (most importantly) insight required to synthesise a solution to the problem at hand.

[[9]]The role of snowmobiles in innovation @ PEG[[9]]

We need to consider how any solution we're considering supports and integrates into this group conversation. The solution needs to expose its data and its processes so that they can be referenced, referred to and discussed. This needs to be done in a open, standards complient way (i.e. via URLs etc) rather than ActiveX and other embedded proprietary controls, allowing the converstation to skip across platforms and involve (potentially) the entire organisation.

The solution should support a range of social media platforms, some which might be bundled with the solution (such as Chatter{{10}} with SalesForce.com{{11}}) or others which are standalone products or part of a platform provided by other vendors. It might also provide, or integrate with, visualisation tools to enable users to view and manipulate the data it contains.

[[10]]Chatter by SalesForce.com is a messaging service that enables users to collaborate around data and applications provided by SalesForce.com and its partners.[[10]]

[[11]]SalesForce.com[[11]]

In our CRM example we want to empower our team to discuss problems, customers, opportunities and leads, proposals, transactions, and even closed deals. This discussion might span a range of departments, from Sales, Operations, Customer Support through to partners, suppliers and even customers. The same can be said for General Ledger, as the team collaborates to resolve exceptions and issues as they work to close the books, Supply Chain Management as the extended team works to resolve disruptions in the supply chain, etc.

Third, we need to consider how we want to consume the technology. Is it possible to consume the solution on-demand, wherever our users are?

Traditional enterprise applications have a well defined lifecycle. There's the large up-front CAPEX charges required to fund development, configuration, customisation and installation of the solution. There's ongoing OPEX to fund maintenance of the solution and to support expansion as the business grows. And then there's another CAPEX gulp down the road to renew the solution when either our needs change or the solution becomes too expensive to support as it is.

On-demand delivery models – of which SaaS is the most visible member – convert large CAPEX costs to much lower OPEX costs, and they have a much shorter time to capability. My back of the envelope calculations have SaaS CRM typically being installed in a couple of months and for less than ten percent of the cost of a traditional on-premises solutions. We also end up with fairly simple per-seat charges that can simplify our own internal accounting. This reduces the effort required to provision and support the application, freeing up resources to be focused on more important problems, problems which will have a larger influence on the business success than a commoditized enterprise applications.

The ability to rapidly field and then scale a solution make the difference between responding to an opportunity or a problem, or watching it pass by. During the aftermarth of the recent Christchurch earthquake, for example, the Christchurch council need a solution to help coordinate the huge community of contractors and volunteers involved in the clean-up efforts. Vendors were contacted, solutions evaluated, and the council commissioned a traditional, on-premesis project portfolio management solution. The complex effort to source the software and engage the contractors, procure the hardware and install it in the data centre, configure and test the solution, and train the stakeholders, soon fell apart under its own weight. Under intense time pressure the council decided to change courses, engaging a lightweight SaaS solution. This time the effort to provision and rollout the solution took around two weeks, a solution which went on to successfully support the recover and redevelopment efforts.

IT executives are under intense pressure to not just do more with less, but to also respond to a market where the pace of change seems to be constantly increasing, social media is dominating more and more organisations marketing agenda and big da/ta. The new-new thing has a lot of potential but which of our solutions should be migrated away from legacy? Just because something can be done doesn't mean something should be done. On the other hand, we can't ignore the new-new thing and keep doing what we've done in the past.

Taken together these three questions – ‘can I simply use a solution, rather than heading down the expensive customisation path?’, ‘what's the social angle’ and ‘where does cloud fit into it’ – can help us to navigate the path between the legacy IT that we still run the majority of our business on and the new-new thing.