For most organisations, the journey to the Cloud is not an all or nothing endeavor. Nor is it one that is achieved in a single step change. Chances are you will be doing things gradually, biting off manageable chunks – trying out a few servers on Amazon Web Services (AWS) or Microsoft Azure’s platform; signing up for Microsoft’s Office 365 or sampling the delights of a cloud-based SaaS CRM tool (of which there are plenty of choices in addition to SalesForce).
If you’re going to move up the business value stack, from infrastructure as a service (IaaS) cloud offerings, towards more business applications, integration platforms and even business processes as-a-service you will need to embrace the notion of “standard”.
The Challenge with “Standard”
Standard business processes, standard workflows, standard configuration, standard interfaces, standard data structures, and standard reports. In all these cases, “standard” is defined by the cloud vendor, and not by the customer. At least that’s the case if you want to take advantage of Cloud’s promise of inherent flexibility, rapid deployment, avoid excessive costs and access evergreen functionality (i.e. the latest releases).
And, therein lies the challenge – too many organisations have been talking “standard” for a long time. Every CIO, consultant, vendor and industry analyst worth their salt, will utter this universal truth at the start of any conversation about selecting a new product or preparing for a new implementation project – “we need to adopt vanilla/standard” and everybody around the Board table will nod in fervent agreement!
Lots of organisations looking at 2nd/3rd iterations of their business applications platforms, will have identified excessive customisation as a key cost and complexity driver; something to be eliminated in future implementations, and an indicator of the last implementation project’s failings, but it’s a hard nut to crack.
On premise business applications, particularly those in tier 1 and 2 have matured to give customers options during implementations; different ways of configuring certain processes to suit a variety of situations or industry nuances; extension frameworks and facilities to tailor functionality to the point where “standard” often gets construed as a common way of doing things “within an organization”.
These available options, coupled with strong personal preferences and reluctance to change ways of working (or probably more often to change “ways of managing”), results in frequent failure to adhere to this fundamental principle in business applications implementations. At best it leads to “a faithful recreation of legacy”, and an ongoing management headache. At worst, it ends up in disastrous and costly implementations.
Using “Standard” to Exploit the Cloud
You need to take the opportunity to challenge the status quo and existing ways of working to see how close to “standard” you can get. This is key to an organisation’s ability to exploit multi-tenanted, cloud-based business applications. The potential upside lives and dies through adopting “standard” and figuring out, upfront, what really needs to be different or unique to aid differentiation, and what can be “standard”. Nailing down today’s “standard” on its own, is not enough. You will also need to have a firm eye on the longer-term, future-state for your organization.
Standard approaches are good for non-differentiating capabilities, which an organisation needs to execute more efficiently than the competition – or at least as efficiently.
However, where a capability delivers competitive advantage (either as lowest cost producer or as supplier of a value-added differentiated product/service), a standard approach by definition is not what is called for.
The delivery of a differentiated customer-facing capability may require a non-standard combination of standard capabilities, or a completely non-standard approach. This needs to be understood, alongside a very clear understanding of the organisation’s competitive proposition, future direction of propositions and the underlying capabilities required to support these.
When you are performing any initial evaluation of fit to potential solutions, you need the supplier(s) product roadmap to align to your business strategy/roadmap. Sometimes, suppliers are chasing a slightly different market segment.
When you buy in, it’s great for both parties, but you (as the customer) may just be a stepping stone for the supplier as they focus on other segments. What you thought, at the beginning, was a solution targeted at your type of business, suddenly becomes something different and future functionality may not serve your needs. This can lead to a tricky decision. When do you compromise your business model to follow them? Or, do you start looking at changes in your landscape to give you what you need, at affordable risk and cost?
This underlines the importance of taking a whole-enterprise approach, particularly when considering SaaS, cloud-based delivery paradigms.
The following steps will help to mitigate risks inherent in building out your strategic roadmap for business capabilities and their supporting applications:
- Develop a clear future operating model, with the appropriate stepping stones along the way;
- Identify the appropriate business applications and technology platforms that could help you get to where you want to be;
- Drive justification and agreement for uniqueness;
- Figure out alternative solutions for those special areas;
- Keep the business processes supported by cloud-based applications “vanilla”
- Make sure that the points of integration adhere to the cloud vendor’s published integration standards
Finally, keep on top of suppliers’ roadmaps to make sure that your future operating model needs will remain enabled and supported “as standard.”
While industry cloud certifications and standards are emerging and evolving, it’s going to take time and it’s likely that they will primarily exist at the technical level, with “transparency” being a critical commercial endorsement feature.
Getting a good fit with your new SaaS business application, upfront, is essential. So, you need to be clear not how you want to be able to execute a particular business activity, but what you need to be able to do now and in the future, and produce strong justification as to why an area might need to be different, because that will establish the boundary to any standard cloud-based business application. For each non-standard area, determine how that unique capability will be delivered and integrated, because without it you’ll be missing a key item of competitive advantage.
Then document it, build the case for change, form a coalition and strap in for your journey to the clouds!!
