It is fair to say that most companies today already utilize a Software-as-a-Service (SaaS) solution somewhere in their application architecture. For instance, SaaS solutions account for a very large part of customer relationship management (CRM) deployments. In 2019, Gartner forecasted that SaaS sales software would account for 84% of total sales spend in CRM deployments. In contrast, while most companies may have adopted SaaS for their CRM solutions rather quickly, these same companies have been slow to move their product lifecycle management (PLM) systems to SaaS. Most of the SaaS PLM early adopters came from small to medium size companies that were able to easily adapt to the standard applications made available by SaaS software providers, but large companies with specific requirements have been slow to adapt to SaaS and the cloud. Now, with having experienced the effects of the pandemic, the situation has quickly changed.
Moving to a SaaS solution for the first time can create culture shock for some information technology (IT) professionals. Since the beginning (of IT departments), IT professionals have been managing every aspect of application delivery - from the physical data center and infrastructure, through the networking, software, security, and deployments. Many years were spent developing standards, processes, and procedures to ensure the protection of a company’s IP and the performance of the systems that develop their products. When a company signs on the SaaS dotted line, they are handing almost all these tasks to an outside service partner. Once the ink is dry, the service provider delivers everything on the agreement as outlined by the service level agreement (SLA). How this is done under the covers is no longer the concern of the IT department, as long as the service vendor meets the SLA agreement. While this may be an adjustment for those who are used to controlling every aspect of system delivery, SaaS solutions have ultimately proved to work out better for everyone involved. Companies are freed from day-to-day operations, and third-party vendors can focus on driving efficiency by the economy of scale as they deliver a solution to multiple customers.
Since most large companies have already adopted SaaS for at least one of their enterprise applications, there is an understanding throughout these organizations about the implications of turning over day-to-day operations to a service provider. What may be a bit of a surprise for companies moving their PLM to SaaS is that the products they have been using on-premise may not be the same as the ones they will be using on the cloud. Hence, here are three things you should know before signing on the SaaS PLM dotted line.
1. Will your SaaS PLM allow you to create customizations or new solutions?
This should be your first question. If you don’t get the answer you want, stop the conversation, ask for the check, and move on. The business case for supplying SaaS solutions depends on economy of scale. SaaS offerings are profitable for the supplier because they can provide the same system and environment to multiple customers using a minimal number of resources. If the SaaS offering is not built to strategically support an organization’s unique requirements through customization and new functionality to meet future requirements, then there’s a problem. As any large company painfully knows, there is no such thing as going live with an out-of-the-box solution. If your PLM cannot support customizations, you are back to complex workarounds to meet your specific requirements. You can actually see the benefits of SaaS disappearing out the window.
If the answer to the first question is “sure – you can customize our SaaS PLM,” then part two of this question is how is it done? Does the SaaS environment allow for customizations to be built strategically without affecting future upgrades or creating technical debt? ? If the answer is that you need to build customizations in another development application, and it will “work seamlessly” with the PLM, you may see a red flag going up. You may also find yourself back in the system workaround business very quickly.
If you get past the first two questions, part three is the big one. How does your service provider manage customizations? Do they have a flexible deployment model to support customizations? Can they support continuous deployment of new enhancements? If you expect your PLM system to keep up with the frequent demands of your business, it not only needs to support customer specific application changes, but it needs to be managed using DevOps processes to automate testing and deployments. If your prospective SaaS PLM offering does not provide everything you need to manage system changes, then you can be sure they are not expecting you to make any.
2. Can I delay an upgrade if the timing is problematic?
As I mentioned earlier, the business case for SaaS depends on the providers being able to manage identical instances of their software with the same set of resources. For many SaaS solutions, when the provider is ready to send an update, it’s coming - like it or not. Large companies have strict business schedules with firm dependencies and timing that often results in “code freezes” where no application changes to can be made for a period of time. A typical example is year-end or quarter-end financial closings. To mitigate any risks of inconsistent data, once the process of closing the books starts, everything else stops. What happens if you have no way of stopping an update to your PLM system and it creates a data issue when finance is closing their books? I don’t want to be part of that conversation.
3. Is my SaaS software the same as my on-premise system?
Just because a PLM provider offers their flagship product as a SaaS offering, it does not mean that the same applications and capabilities will be available. Many large PLM companies have issues reengineering their products to make them available as part of their new SaaS offerings. You should ask if there is complete parity of functionality between their standard on-premise offering and their SaaS offering. Again, if the answer is no, get the check and move on.
If your organization is in the process of moving its legacy PLM to the cloud, but does not want to sacrifice the power and flexibility of an on-premise deployment, take a look at Aras Enterprise SaaS. You will like the answers to these tough questions.