Customization: an enemy of SaaS? (part 2)
This is part 2 of the same issue: Is Customization an enemy of SaaS?
In the previous entry, I referred to some examples that will create pressure to the SaaS Vendor because a) these Change Requests are “logical” or “rational” on behalf of the Buyer and b) they are technically complex.
Now let’s see some more aspects of the problem:
Example #3: Look’n’feel
Let’s assume that your SaaS platform has covered some ground in the area of personalization, color schemes, logos etc.
Now, a new customer comes along and requires some extra elements of personalization that your app does not cover. E.g. I recently hit on a case that the customer wanted the color scheme in all web forms to change! Another customer said that “the correct way to place fields in the customer file is last name – first name and not first name – last name”. He actually wanted to swap the positions of these two fields because he felt that his users will have difficulty adopting the “layout of the new system”. Questions:
Do you accept this kind of change?
Do you dare say to the end customer that “small changes like that” will cost him $ XXX ?
Where does this “change-this-change-that” end?
Be careful of what you answer. It’s more than likely that other SaaS vendors will answer… differently!
Example #4: Reporting
Over time, a number of reports has been created and you probably give these reports for free to your new customers. But new reports are requested from time to time and you charge the requestor in order to develop them. This will soon create an enormous number of reports inside the system and you will have to somehow manage this volume and also the different versions of the same report per user (e.g. have you ever seen the “monthly sales report” of two companies being the same?). If the report is pre-fabricated in the system (i.e. there is a specific program that creates a specific report), this can soon end-up in a nightmare. The solution to the problem is to create these reports through some kind of report generator. Does your SaaS app have one? If not, then can the Buyer buy another software and “plug” it to your SaaS database? If yes, then there is a possible security risk that an external system plugs and interrogates a SaaS (multitenant) database! Therefore, you have to think of new ways to raise “Chinese walls” between your tenants. Or maybe, you don’t allow access to your main database; you build a kind-of MIS database “beside” the main database of the system, so that the external interfaces interrogate a “safe” environment (and the cost is obviously all yours). Now, you see how a simple thing like “reporting” can be a real pain!
Example #5: What happens with project-scale changes after “disembarkation”?
In my previous blog post, in example 1, I dealt with the issue of “heavy customization equals project”. And then I talked about the complexity of the version-control. Now, I’d like to highlight another view of the same problem. Suppose that this big request comes during the early stages of your pre-sales function. You try to convince the customer to board your SaaS app and you will form and execute a customized project for his complex request. Now I will play the “devil’s advocate” (i.e. the customer!) and ask you the following:
How much does this project will cost me, since you will develop new functionality that will enhance your position to the market and, giving you more revenue? Shouldn’t I get a share of that revenue?
What happens if I decide to disembark your SaaS app? Is my initial investment on the “project” going to be lost? Or will you reimburse me for that value?
If I am reimbursed, will you add interest for the money I invested on your SaaS app X years ago?
I hope that the above gave you a glimpse of how small problems become nightmares in a SaaS environment. If you are a buyer, then you should consider your specific needs, complexity and business culture and maybe you will find that SaaS is not the right solution for you. Or maybe, SaaS is OK as long as it is not multitenant.
I think that we have been lead to the simple conclusion that “in-premise is not dead yet!”. And this comes from a SaaS enthusiast like myself…
In the previous entry, I referred to some examples that will create pressure to the SaaS Vendor because a) these Change Requests are “logical” or “rational” on behalf of the Buyer and b) they are technically complex.
Now let’s see some more aspects of the problem:
Example #3: Look’n’feel
Let’s assume that your SaaS platform has covered some ground in the area of personalization, color schemes, logos etc.
Now, a new customer comes along and requires some extra elements of personalization that your app does not cover. E.g. I recently hit on a case that the customer wanted the color scheme in all web forms to change! Another customer said that “the correct way to place fields in the customer file is last name – first name and not first name – last name”. He actually wanted to swap the positions of these two fields because he felt that his users will have difficulty adopting the “layout of the new system”. Questions:
Be careful of what you answer. It’s more than likely that other SaaS vendors will answer… differently!
Example #4: Reporting
Over time, a number of reports has been created and you probably give these reports for free to your new customers. But new reports are requested from time to time and you charge the requestor in order to develop them. This will soon create an enormous number of reports inside the system and you will have to somehow manage this volume and also the different versions of the same report per user (e.g. have you ever seen the “monthly sales report” of two companies being the same?). If the report is pre-fabricated in the system (i.e. there is a specific program that creates a specific report), this can soon end-up in a nightmare. The solution to the problem is to create these reports through some kind of report generator. Does your SaaS app have one? If not, then can the Buyer buy another software and “plug” it to your SaaS database? If yes, then there is a possible security risk that an external system plugs and interrogates a SaaS (multitenant) database! Therefore, you have to think of new ways to raise “Chinese walls” between your tenants. Or maybe, you don’t allow access to your main database; you build a kind-of MIS database “beside” the main database of the system, so that the external interfaces interrogate a “safe” environment (and the cost is obviously all yours). Now, you see how a simple thing like “reporting” can be a real pain!
Example #5: What happens with project-scale changes after “disembarkation”?
In my previous blog post, in example 1, I dealt with the issue of “heavy customization equals project”. And then I talked about the complexity of the version-control. Now, I’d like to highlight another view of the same problem. Suppose that this big request comes during the early stages of your pre-sales function. You try to convince the customer to board your SaaS app and you will form and execute a customized project for his complex request. Now I will play the “devil’s advocate” (i.e. the customer!) and ask you the following:
I hope that the above gave you a glimpse of how small problems become nightmares in a SaaS environment. If you are a buyer, then you should consider your specific needs, complexity and business culture and maybe you will find that SaaS is not the right solution for you. Or maybe, SaaS is OK as long as it is not multitenant.
I think that we have been lead to the simple conclusion that “in-premise is not dead yet!”. And this comes from a SaaS enthusiast like myself…
THANK YOU FOR THE INFORMATION
ReplyDeletePLEASE VISIT US
erp software companies