To date, enterprises have worked with everything from home-grown hand-coded systems to off the shelf enterprise applications. These started off as highly focused applications, such as those looking at supply chain automation (SCA) or sales force automation (SFA), but rapidly grew to embrace an increasing number of business functions.
Therefore, we now have (what pretend to be) focused customer relationship management (CRM) and enterprise resource planning (ERP) systems, that heavily overlap in what they do – and attempt to replace other third-party systems at the same time.
There are pros to this, of course. A single solution from a single software vendor requires only one contract and one set of payments. Any problems that arise must be on that software; therefore, there is no finger-pointing when trying to solve the problem.
Except, this isn’t how it works. Few organisations install vanilla, unmodified code. They find that certain functions provided are sub-optimal; therefore, they search out better third-party plug-ins or replacements. Multiple contracts are still the norm and finger-pointing continues.
Indeed, many organisations deem that the best way for them to use large enterprise software systems is not by trying to bend the software to fit in best with their business; it is often more cost-effective to bend the business to fit the software. This leads to an organisation being, at best, as good as the rest.
Competing in today’s market requires an organisation to create and use a platform that is far more dynamic and flexible than that which is offered by today’s enterprise apps.
As an MSP, you might want to take this into consideration instead of just taking those enterprise apps and hosting them. While multi-tenanted enterprise apps give economies of scale to you and your customers, the result is still a “one-size fits all” platform. An app where the customer can adapt the base system to their own needs is complex to support and manage – particularly when it comes to major upgrades to the underlying system.
Anticipating the next step
What MSPs today should be looking at is how the overall playing field is going to change. The great promise of cloud computing is that functionality can be picked up from anywhere. Does this mean that everyone should just be looking for SaaS-based CRM or ERP? No – what they want is the capability to gain access to functional items that can be built to create a platform that supports their business processes at a specific moment in time.
As an example, it could well be that an organisation wants a process where a prospect is turned into a customer. Sounds like a CRM, doesn’t it? Breaking it down into a set of sub-tasks, however, starts to show how complex the various areas can be.
First is prospect identification. An organisation could buy a list from a third party, populate its CRM system, and start an outbound campaign. Or, it could go to a highly-specialised MSP that can aggregate and analyse multiple different data sources and highly focus a campaign.
Those ‘hot prospects’ need to be targeted against a possible item or service for sale. Again, a CRM system could do this: however, highly-specialised MSPs can provide much more granular reporting in real time against what is happening and allow for faster changes to be introduced where issues are seen to be happening.
Similarly, as we move along the whole process chain, compare an MSP that specialises in payment acquisition and clearing to one that focuses on finding and implementing the best delivery service for the goods according to the customer’s wishes; etc.
For MSPs, the best way to do all of this is to:
1) Have domain expertise in specific areas
2) Use containers as a means of delivering the functionality in an easily managed and consumable manner.
Through the use of microservices held in Docker, rkt, LXC, or other containers, new instances can be rapidly spun up where greater capacity is required. Containers can be used to airlock different instances, providing specific customers with their own highly secure instances. Instances can be updated and managed more simply, with any rollback due to faulty updates being a simple case of knocking down the updated container and spinning the old one back up.
Microservice containers can also be quite easily published via open directories, making it simple for customers to find the functions they want when it comes to their immediate needs. MSPs that want to serve a more general purpose can offer multiple microservices and a centralised means of integrating to provide the overall composite app that the customer needs. Using this approach, MSPs can then also integrate third party functions into their composite app, building a best-of-breed solution to a customer’s immediate needs.
There will be problems –around standards and security, which I will cover in my next post. However, it is my firm belief that MSPs will fail if they attempt to just replicate existing application approaches with the only change being that they are provided via SaaS. Those that take a far more radical approach will be the ones that lay the foundations for ongoing success.
Photo: 5 second Studio / Shutterstock
