At the Horizon – Does Cloud meet OnPremise?
On one of my long flights, I had ample time to reflect on our experiences working with customers on the terra firma (the on-premise world of Siebel) and in the cloud (primarily, Salesforce.com). I was struck by how similar these applications have become.
We
have had Salesforce.com as our internal CRM for over five years and I have
always marveled on how easy it has been to implement. Yes, it required no programming. We were able to configure it within a couple
of hours and our team was fully functional – no training necessary. For Siebel specialists that we are, this was
indeed too good to be true!
Platform
as a Service or On-premise in the Cloud
Simplicity
and ease of implementation has been the engine behind Salesforce.com’s rapid
adoption across many customers.
Salesforce has since released a lot of powerful features such as Apex
programming, Visualforce, Salesforce1, the Force.com ecosystem, etc., to evolve
from an SFA application to an enterprise-level front office platform in the
cloud. These features have enabled
customers to write custom scripts, create custom objects, add custom fields,
and design custom applications, workflows and processes – something commonplace
in the on-premise world. The flexibility
offered by these features in on-premise applications is what got many of them
into trouble.
Insights
from the Field
Indeed
we see customers with cloud-based CRM apps facing challenges similar to those seen
in the on-premise world.
I
was talking to the Director of Sales Processes of a customer regarding
initiatives they have underway. She
mentioned “Reducing Sales Drag” as their main initiative for the year. I asked her to elaborate upon what ‘sales
drag” meant to them. She listed user adoption,
complex user interface, too many approvals, and non-standardized rules as issues
they are trying to address. My jaw
dropped open. These are things we normally
hear from customers who have had on-premise apps such as Siebel.
I
was visiting with another client a few weeks ago. Our discussions touched upon various topics,
one of which was expanding the footprint of salesforce.com across their
organization. The Director of IT was
concerned that a wider roll out of Salesforce would be a non-trivial task. One of their divisions had already used 438
fields on the Customer object! A wider
roll out would hit up against the limit of 500 fields per object in Salesforce.
The
Takeaways
In
each of the above cases, after some further due diligence we uncovered the root
causes for these problems. These are lessons many on-premise customers have
learnt, albeit too late, and are equally applicable in the cloud world.
1. Process Design:
Because it is on the cloud doesn't mean that process design can be ignored. Invest in designing the right processes
before embarking on the implementation.
2. Release Hygiene: Just because it is easy to add a new field, implement
an Apex script, and quickly release it to production, doesn't mean you
should. One needs to make sure the
changes are in line with the process design that has been agreed upon for the
application.
3. Coding Discipline: Cloud is no more about No Software. Apex is the lingua franca across Salesforce.com. One needs to follow the software development
best practices in order to obviate performance and maintainability issues.
