Whichever reason it is, I find myself being asked a lot of similar questions by potential customers:
- "What will I be able to change in my SaaS environment?"
- "How can I change the system to meet my requirements?"
- "Why can't I write bespoke code in my SaaS environment?"
With SaaS, the key is is the 'S' at the end of the word.
S stands for Service.
Nowadays, nearly everyone uses the Internet for commerce, be it banking, ordering theatre tickets, buying a seat on a train or a plane or buying books. We don't log on to Amazon refuse to use it just because we expect it to provide us with a detailed breakdown of every time the author has used the word 'widget', even if we think that would be very useful.
We don't expect the screens to be displayed in a different order or colour scheme just because we have certain preferences. We simply accept the 'service' the system is providing us and make the best use of the functionality it delivers.
When we use Microsoft Office tools like Excel and Word, we don't refuse to use it because Word don't allow us to type in a complex algebraic equation and then solve it for us, nor do we complain about Excel because we want it to operate like a word processor. We make use of the functionality each provides us within its limitations. If necessary, we other tools to make up any deficiencies.
So, why don't we have this attitude with ERP systems which are delivered as SaaS?
We must start to have a new way of thinking, and of implementing. We must start to deploy the SaaS package and help customers work with it, rather than radically change it. Fusion Applications, and specifically HCM, come with a range of tools which allow us to 'tailor' the application. The composers allow us to adapt out of the box User Interfaces, Processes, Data and Reports, without altering or 'customising' the underlying software. Fusion Applications provides a much richer functionality than it's predecessor applications (EBS / PeopleSoft etc.), so the need to customise should be vastly reduced.
Our new way of thinking leads to a new way of implementing. Now, we should be looking at getting the application out of the box, configuring it (functionally) to represent the customers enterprise and then deploying, maybe in a phased approach. Keep it simple at first and then build on the system later.
Result? Quicker, simpler and cheaper implementations. Makes you think doesn't it.....?