This is a cliché topic, from the beginning of the development of SaaS in China to today, the requirements for private deployment have never disappeared, always every now and then, some customers will put forward such requirements, or based on data security considerations (more than 90% are based on this), or based on the consideration of cost costs, or based on the consideration of easy access to data, in short, the requirements for private deployment have never been broken. Let's be clear here that the private deployment refers specifically to the deployment to the customer's own local server.
Almost no SaaS companies are willing to deploy privately, and even if there are private deployments, I believe they are basically forced to do so, which in itself is a contradictory thing. Once privately deployed, it is easy to think of the customer's next requirements, followed by whether secondary development can be carried out, some functions need to be added to your system, and then whether the logic can be changed in a targeted manner, etc. If you are willing to compromise on these, then congratulations on the successful transformation, transform from a SaaS company to a software outsourcing company, and go directly to the outsourcing project.
In a SaaS company, many colleagues around him who have not stepped on the pit occasionally complain about why the company does not carry out private deployment, so that at least the price can be much higher, but in fact, there are many problems behind it that he has not seen. I am fortunate to experience the problems encountered in the private deployment of SaaS software when I first entered this industry, and today I will share with you the pitfalls I encountered on this.
The first pit: deployment
Remember the word "rip", it will be a main theme. Private deployment, need to deploy the software to the server specified by the other party, first of all, the software has requirements for the server, what environment the software needs to run, these are all requirements, which requires the customer to provide equipment and operating environment that meets the requirements, don't think that there will be no problems here, we need the other party's server to install the Windows server system to run the software when we deployed, the other party installed a pirated version in order to save money, and the result caused a series of problems. If you need to connect to the Internet, you also need customers to apply for a domain name, purchase bandwidth, firewall, etc., don't think that these are all things that customers need to prepare, it has nothing to do with us, customers because of the small bandwidth purchased, open the system slowly, they will also come to say that there is a problem with your software. This is just the beginning.
The second pit: operation and maintenance
For the matter of operation and maintenance, you must burn incense and pray that the network management and operation and maintenance personnel of the customer company are excellent people. The server is down, and then restart, they will come to you and say that there is a problem with the system, and everyone can't open it, let you deal with it. In the process of operation and maintenance, there will be various problems that will be pushed to you that there is a problem with the software, and even if the domain name is not renewed when it expires, it will first say that there is a problem with your software. All problems caused by hardware can also be related to software.
There is a particularly interesting thing here, because the customer often complains about the problem of the software, the customer operation and maintenance personnel give us the authorization to remotely control the server in order to save trouble. (Even the authorization of the remote control server was given, was it really for data security that it had to be deployed locally?) Hehe)
The third pit: upgrade and update
One of the major advantages of SaaS is that the update iteration is fast, and all users use the latest version and functions as soon as the manufacturer updates. Private deployments can only send update packages separately and update locally, becauseSaaS itself is updated and iterated quicklyAt the beginning, customers will follow the update, but soon they will feel that these updated small functions and detailed optimization have no practical meaning for them, and some updated functions are not as satisfactory as before, so they simply do not update.
ButAs the SaaS version has gone through many iterations, some features are particularly desired by private deployment customers, and I hope to update to add these functions, but I'm sorry, I can't update it, because there are too many interruptions, and it is impossible to upgrade to the latest version for you。
The fourth pit: training services
The software system administrator of the customer company has left, and you need to give them other personnel product function training, which you may not be able to do, because there is no synchronous update, the privately deployed software is completely different from your current SaaS software, and you can't find where many functions and settings are. These are completely two software, although they used to be the same, but now they are completely different, so even if a customer reports a bug to you, it is not so easy for you to restore and fix it.
The above are just common pits, and the rest are not one by one.
If you insist on private deployment, it is not impossible, it is recommended to agree on a good boundary in the contract to avoid falling into those pitfalls to avoid future troubles.
I hope that small and medium-sized enterprises will not be superstitious about private deployment and the security you think are safe, especially those enterprises that do not have their own operation and maintenance capabilities, and your secrets may not be as important as you think.
Transferred from:The hyperlink login is visible.
|
Posted on 12/18/2021 12:55:50 PM
|
|
|
