What cloud PLM cannot do for you?

What cloud PLM cannot do for you?


It has been already few years since I started to discuss cloud PLM opportunities on my blog. I found one of my early blogs about PLM and cloud – PLM and cloud: hold the promise?

So, what changed since then? Actually, quite a lot… We’ve seen massive adoption of cloud and mobile by businesses in many domains. PLM cloud adoption is growing too. Cloud is on the roadmap of all PLM vendors. It is really a question of “how to implement cloud?” rather than a question of “do we need to support cloud”?  We also seen few very interesting examples of cloud applications in CAD/PLM space. I want just to mention few of them – Autodesk design tool Autodesk Fusion360, Dassault SolidWorks Mechanical Conceptual, Autodesk PLM360. Siemens PLM made their TeamCenter PLM available from IaaS infrastructure. Aras announced cloud strategy and introduced cloud product available via partnership with Infor ERP – Infor PLM Innovator. Cloud PLM pioneers, Arena Solutions, introduced several new cloud tools (BOM control and Quality management). Last but not least, GrabCAD, an open community of mechanical engineers released cloud PDM tool – GrabCAD Workbench. Earlier this week, GrabCAD was acquired by 3D printing company Stratasys. According to TechCrunch, article the deal was around $100M. I’m sure missed few products and companies…

Here are things that I discussed back in 2010 – cost of the solution, delivery model, global access, faster implementation, scaling. We learned a lot of about PLM and cloud for the last four years. Today, I want to make a reality check for list of things I discussed before in lights of what cloud PLM can or cannot do.

1- Cost

Cloud PLM made a mental switch in everything we knew about PLM before. According to Engineering.com article, cloud affected negatively on-premise PLM market. Cloud PLM created expectations for alternative pricing models and pushed all vendors to think how to turn PLM into service offering. Today, you can buy cloud PLM subscription with no upfront cost and hardware investment, which is a very good thing. However, I don’t think, total cost of ownership is different if you will calculate it on the period of 5 years. I’d love to see and learn more about that and love if you can share your comments.

2- Deployment, scale and IT

One of the best thing delivered by cloud PLM is related to deployment and IT cost. You can buy and deploy it instantly – almost similar to how you can open a new Gmail account. As a customer, you don’t need to worry about servers, setup cost, ordering hardware. You don’t need to negotiate with IT installation time. However, you cannot eliminate IT completely, especially if you are large company. For most of situations, you will have to discuss and make an alignment with IT about issues related to security and information access.

3- Faster Implementation

So, you can buy cloud PLM without upfront cost, you can deploy it overnight. What about PLM implementation? Implementation is an interesting thing. I’d like to speak about two aspects of implementations – 1/Configuration and customization; 2/ Implementations of business processes.

Four years ago, many companies were concerned about capability of web/cloud applications to deliver the level of flexibility, customization and configurations similar to on-premise PLM deployments. It is true, for most of situations, you cannot hack your cloud PLM with simple SQL script. However, I think, the flexibility of cloud PLM tools today is similar to on-premise PLM systems. However, flexibility of cloud PLM tools cannot provide real advantages compared to on-premise tools. Thanks for virtualization and modern collaboration technologies you can run your implementation remotely also for on-premise PLM systems.

Implementation of business processes is an interesting aspect of PLM implementation. In practice it means to define data structures and business processes. Cloud PLM won’t provide any advantages here. It is all about people, processes and organizational changes. So, the ugly truth is that cloud PLM won’t reduce your need of implementation services. In case of on-premise PLM, implementation will be done on site and collaborate with IT – installing, configuring and debugging customized software. In case of cloud PLM, you will need to work with cloud PLM vendor or hosting provider.

What is my conclusion? Cloud computing changed a lot in our life. PLM on the cloud can do many things differently. With much lower upfront cost and simple deployment, it opens PLM doors for many companies that never thought can buy and implement PLM systems before. However, when it comes to implementation and services, cloud PLM won’t do much different from on-premise PLM systems. You still need to implement it. It will require business process planning and implementation cost. Just my thoughts…

Best, Oleg


Share This Post

  • I think a couple of things to note. You talk about implementation services being equal between cloud and on premise. That’s not quite right. If you consider installation and hardware configuration and load balancing and tuning and all the “stuff” you need to get the PLM system simply “ready” to start working on you can typically have weeks or even months to get there. That’s a huge difference. You also have to consider the upgrade cost. On-Premise is significantly more expensive here. You have to re-buy / upgrade hardware and you have to redeploy the new version and update customizations. Often this process can cost you as much as the original services check for the deployment. All of this is gone with SaaS / Cloud since you’re always up to date and you never have to pay for “more” hardware (scale). (hint: if your vendor is charging you for any of the above they’re not a cloud vendor….)

  • beyondplm

    Brian, thanks for commenting and insight!

    What you said makes sense. To be more specific – everything you said about installation, hardware, configuration, load balancing, upgrade cost, etc. is related in my mind to point #2 – “Deployment, scale and IT”.

    The interesting part here is related to upgrade of implementation (configuration/customization) – there is a potential to break customization by vendor upgrade. Within time, cloud operation tools can become another point of differentiation. In my view, this is something not many enterprise vendors have enough experience with. Another interesting area is to compare TCO for a longer period of time. I trust cloud option should looks better.

    The only thing that cloud won’t give you an advantage is related to implementation planning and actual customization (configuration, scripting, coding, etc.) This is something you still need to do regardless on what PLM system you are going to deploy – cloud and on-premise.

    Best, Oleg

  • Got it – Didn’t catch that above.

    I agreed that cloud doesn’t change your planning but I don’t quite agree on your second point. “customization (configuration, scripting, coding, etc.)”

    Not all systems are configured or customized in an equal way. For example SAP is probably harder than something like SmarTeam or another mid-ranged on-premise PDM / PLM system. So “mileage may vary” with how much effort you will need. While I agree it doesn’t eliminate it; it can reduce it from vendor to vendor.

    Another important point. What I’ve seen with my experience with cloud solutions (Salesforce.com, NetSuite, Autodesk PLM 360) is that products that were built ground up for the cloud have taken different approaches to customization. The way you customize and the simplicity of it is WAY different than on premise systems.

    So again – mileage may vary – but I have seen more modern cloud solutions help you dramatically reduce the time it takes to achieve a similar result vs. an on premise system.

  • beyondplm

    Brian, You are right. On average, newer systems are better designed with better user experience. If new system designed with “flexibility in mind”, it can outperform old dinosaurs. At the same time, the ugly truth, knowledge and experience plays significant role when it comes to customization and configuration. It is like the best programming language is the one you know :). Therefore, I guess, every service team will take time to learn system and adjust their rates for average customization.

  • AvdR

    There is one thing, you must not forget: the more you custemize a system, the more complex each upgrade becomes. For each upgrade you have to check if your customisations still work as before!. –> it might be an advantage to have your premise system, where you can decide if and when you upgrade compared to a cloud where the upgrades are decided for you…

  • beyondplm

    AvdR, thanks for this note! You are absolutely right- more customization leads to higher complexity of upgrades. The good news for cloud – this upgrade will be (most probably) handled by vendors. The bad news – the upgrade complexity is higher for cloud products, especially in multi-tenant environments.

  • Okay, l’m just going to say it…I Hate Customization! …and here’s why.

    It seems like most customization comes about due to inadequate client/vendor efforts to validate a technology product…the POC and the business/technical requirements missed their marks. Also, we often find ourselves neck-deep in implementing before we find what we missed. The result? Our “customization” is often a cobbled-together crutch that will never make it into the core product. Finally, many customizations cross over into “nice to have” and are not really business critical. Sure, the “we can get it to do it” mentality is tempting, but we often decide to customize almost on a whim and without a full evaluation of the consequences. Cloud or on-premise, I Hate Customization!

  • beyondplm

    Chris, you are right! Absence of alignment between vendor and customer can be one reason for customization. Another reason – covering of product gaps, which is variation of first option. However, customization (or how it sometimes called by sales/marketing – configuration) is also driven by specific “custom” needs defined by customer and cannot be avoided. There are few zones in PLM that cannot avoid customization – custom identification (naming, numbering), PLM-ERP integration, data import. Also, typical customization zone is establishing of data structures (models) and workflow processes.

  • Pingback: Why PLM got stuck with people?()

  • Pingback: Why PLM got stuck with people? | Daily PLM Think Tank Blog()

  • Pingback: What PLM industry can learn from… Hollywood?()

  • Pingback: What PLM industry can learn from… Hollywood? | Daily PLM Think Tank Blog()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » PLM – Need for Speed()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » It takes XX months to implement PLM. Can we fix it?()

  • Pingback: It takes XX months to implement PLM. Can we fix it? | Daily PLM Think Tank Blog()

  • Pingback: PLM Implementation as a Service | Daily PLM Think Tank Blog()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog 3 bad PLM implementation habits to kill in 2017 - Beyond PLM (Product Lifecycle Management) Blog()