As-Is

Traditionally, a PLM implementation was carried out using large internal servers and associated IT infrastructure – what is now termed “on-premise”. Such implementations would be configured and customized to suit the processes and requirements of the business. Although most PLM customers would pay lip service to “Out of the box (OOTB)”, most would immediately turn around and apply customization.

So, what are the problems associated with this model? Let’s list a few of them:

Upgrades

Because an on-premise installation is static it is normally frozen at the level at the time of installation. The software vendors are constantly improving their offerings and normally have an annual upgrade cycle. Large implementations with multiple customizations and external connections are very difficult to upgrade (not least of the problems is that the original software vendor does not support customizations). This leads to the situation that these environments often are several years behind the latest release and are hugely expensive to upgrade when this becomes an imperative.

Underlying Hardware and Software

A PLM installation is dependent on underlying operating systems, databases and browsers. If these are upgraded or changed often the PLM environment will not operate

Supplier Compatibility

A typical automotive or aerospace supplier (and there are many) runs at least 5 different versions of the same CAD package. This is required to make sure that they have the required version for each OEM they supply to. Large OEMs have lengthy and update cycles and are not synchronized. Of course, anyone who has touched a CAD file with the wrong version, will understand the potential pain.

In addition, suppliers must maintain a unique connection for each OEM they work for and must manually extract and upload data from these connections. Definitely wasted effort.

Software Bugs

Ever submitted a ticket about a software bug to a PLM company? The first response from their technical support will be – Can the error be replicated in an OOTB environment, we do not support customized environments? So, if the error is in a customized environment, you will largely be on your own trying to solve the problem.

Technical Team

To maintain a large on-premise PLM implementation, an organization needs a dedicated technical team. These resources are difficult to recruit and expensive to maintain.

Technology Access

Technology is constantly improving, including PLM applications. So, what holds back companies from using the latest? In a large majority of cases the answer is – we cannot move until our major customers move.

To-Be

Consider that Salesforce was founded in 1999 and in just over twenty years has revolutionized CRM applications. A large part of their success – a cloud-based Software as a Service (SaaS) offering on a multi tenet architecture.

The PLM landscape is showing a shift toward a cloud-based SaaS model, similar to Salesforce. Its adoption is still small but growing.

So how does a cloud-based SaaS PLM approach overcome all the problems associated with the on-premise model? Here is a list.

Automatic upgrades

As the software vendor is responsible for upgrading the environment, every user is automatically up to date with the latest version – no more expensive, lengthy upgrades. Everybody always has the latest technology.

Simplified IT

Because all the complicated software behind a cloud-based PLM is transparent to the customer and users, IT requirements for a cloud-based system are greatly simplified. Usually these are restricted to browsers and workstation operating systems. Also, no more large IT team to support the PLM implementation.

Supplier Collaboration

This is one of the largest benefits. No more running multiple versions: everybody is automatically on the same release and patch level. The other potential huge benefit from a cloud PLM is the concept of a single license have access to multiple tenets – in this scenario a user would log out of his tenet, log into an OEM tenet, retrieve data or collaborate and then use the same license to access his tenet. No more custom connections, ftp or email!

Objections?

Of course, there will always be objections to progress. Here are a few:

Cloud security is a large technical topic and beyond the scope of this article. However, lets revisit the example of Salesforce mentioned earlier. Is not a company’s contacts, sales leads, pipeline and revenue forecasts very valuable and sensitive? All stored on the Salesforce cloud. Probably of equal value is engineering data and associated documents, so why not have them on the cloud?

It is true that a cloud-based application such as PLM requires a larger and reliable Internet connection. But think of the on-premise servers that are been saved.

Cloud based SaaS model allows little or limited configuration/customization possibilities. This goes to the heart of another age-old PLM debate – change business processes to suit the system or change the system to suit the business. Organizations always pay lip service to the former (“We want OOTB”) but adopt the latter (“Can we implement our smart part numbering system”). A cloud PLM will keep everybody honest.

The Future of PLM

This short article probably does not completely cover the topic but makes some compelling arguments. The future of PLM is on the cloud! Let’s embrace our destiny!