A couple of months ago, I posted a blog “Evaluating SaaS solutions? Watch for these 5 challenges.” In that I highlighted configurations and customizations as the first and most significant challenge. Most SaaS solutions support configurations - changes to UI templates, basic workflows, role based authorization and authentication etc. This is a double-edged sword since some configurations may make the solution more usable, while adding to cost and complexity. Even seemingly small configurations done together might cascade into a considerable effort that must be managed and orchestrated.
Image credit: https://www.flickr.com/photos/paul_houle/
A practical challenge with SaaS solutions is the skills and product knowledge required to enable configurations. Most organizations introducing a SaaS solution into their ecosystem wouldn’t have these skills. These technical and functional skills will need to be sourced, sometimes at a high cost. Just try searching for “workday consultant” or “salesforce project manager” on LinkedIn jobs section and see the number of hits. Technology consulting firms have sensed an opportunity, and developed entire practice areas with armies of consultants focused on specific SaaS solutions.
your business is unique and you have some requirements and business processes that set you apart. All businesses do. This is why Salesforce has the absolute best platform for customization. This is why Salesforce lets you customize your data model by creating custom fields and custom objects. This is why Salesforce has Process Builder which lets you manage your business processes visually and easily. This is why Salesforce gives you App Builder, and Apex, and Lightning and Heroku… Anything you need to do, you can do it on Salesforce.
But sometimes you take it just a little too far.
I like the bluntness with which Jon pushes back at customizations; and the title of his article is direct. However, telling the business executive sponsoring a SaaS solution that “You're Not a Special Snowflake,” is not a way to score brownie points. Working with him and his functional teams to evaluate the the art of the possible is the key to stakeholder management. It is more about minimizing customizations - “You and the CRM are ‘Special’ Snowflakes that don’t need uniquely customized solutions”
Towards the end of his writeup, Jon emphasizes the
community of practices that have evolved around SaaS solutions. He describes the concept of Salesforce’s Ohana “
our family, our culture.”
Salesforce has attracted an amazing community of smart, experienced, like-minded people all willing to help each other get the most value out of their use of Salesforce. When you use standard objects and standard functionality, you’ll be speaking the same language as this community. When you ask for help, they’ll immediately know what you’re talking about, and they’ll already have implemented a solution to your problem in the past. And, when you use standard objects and standard functionality, you’ll often come up with novel solutions that you can contribute it back to grow your own career and personal brand.
I like the way Jon describes the benefit of using
standard objects and minimizing customizations in SFDC. The community of practice is perhaps the most understated tool available to technology teams. Consulting firms have long realized the power of such communities and have even formalized and incentivized “knowledge management” in many areas, not just for SaaS solutions. For instance, my former employer, Infosys, took a lot of pride in their award winning KM platform -
wins The Most Admired Knowledge Enterprises (MAKE) ]
The opportunity to leverage external and internal community of practices should also appeal to functional stakeholders, and their teams. Who – business users included - wouldn’t want to have marketable skills on their resume?
