I remember the day Carl Bass went on his “rant.”
While what Carl was saying was eyebrow-raising, I distinctly recall finding the reactions of those around me just as interesting. The foreign press and analysts, listening to Carl’s words being translated through their headphones, exchanged quizzical looks that spoke volumes: “is this translating correctly?” The US press and analysts mostly had smirks on their face. Carl was saying things that mirrored the thoughts of many in industry. Most just wouldn’t say it out loud.
Fast-forward to today, and Autodesk is launching a PLM offering. But it’s not exactly more of the same. It’s different. Most of it seems very promising. Some seems a little suspect.
What you’ll find below are my thoughts on this new offering’s capabilities and what the implications are for engineers and others involved in product development.
Background
On Tuesday, November 29, 2011, Autodesk announced they will be launching a new PLM product called Autodesk 360 Nexus. This new product is part of the software family called Autodesk 360. Vault, Autodesk’s PDM system, and Buzzsaw, Autodesk’s cloud-based system for collaboration, are also part of this software suite. For more details, take a gander at the official press release.
Capabilities Provided
So what exactly does Nexus offer or do? The core functionality of today’s PLM systems seems pretty standard. However, Nexus has some interesting characteristics that set it apart: for good and bad.
Completely Cloud-Based
Nexus will be exclusively hosted in the cloud. Autodesk at the time didn’t disclose exactly if it was being hosted by third-party, but I will be highly surprised if they hosted it themselves. Most likely they’ll be using Amazon’s or someone else’s service. So, no, you cannot deploy it on premise at your location.
PLM Decoupled from PDM
For most PLM systems, PDM is a foundational module. The idea is that design data and development processes should be uniformly tied to one another. However, that’s not the case with Nexus. It doesn’t provide any PDM functionality whatsoever. Autodesk’s Vault system has filled that role for years and that won’t be changing anytime soon. The folks at Autodesk stated that PDM is actually an extension of CAD, and because of that and the fact it will be working with such heavyweight design data, it needs to be more of a heavier client/server architecture. Nexus will have a lighter weight web and mobile app type of interface. Furthermore, Nexus and Vault will work completely independently or as integrated as individual customers desire.
Focused on Processes, Starting with Templates
So if in Nexus doesn’t manage design data, what does it do? It focuses on processes on business information about products as they progress from inception to retirement. And it seems as if the key enabling technology is it’s workflow engine.
At the launch, Autodesk talked about only a few process areas that will be supported initially such as NPI, compliance management and program management. However, in other discussions, they have disclosed that there are somewhere in the range of 140 “apps”, each of which can be adopted individually or in an interconnected combination. These start to get incredibly granular. For example there’s one for FMEAs, CAPAs and the like. These templated apps can be used as-is or act as a starting point for each customer organization to then configure.
Tailoring the Templates
A phrase that was bandied about quite a bit at the launch was “insanely configurable.” After getting an up close demonstration, I started to understand what they meant. There is finely detailed control over creating or modifying fields, workflows or even the apps themselves through Nexus itself. There was a minimal need to program or code any specialized functionality into any of the apps. The vast majority of it could be done through the Nexus interface. There is a capability to script more complex behaviors as part of the workflow engine. But that functionality can be reserved for the extreme edge cases in supporting processes. But what I found most interesting was the fact that of the 140 granular apps that are a part of Nexus, a good number of them were created by various members of Autodesk that aren’t in the development organization. I think that’s a proof point of how quickly and easily Nexus can be configured.
Integrated Project Management
So far, I’ve talked about the generic characteristics or capabilities of nexus. But there was actually one specific piece of app functionality that stood out. And that was project management. In most PLM systems, project management functionality lets you define tasks with predecessors and successors. But it is commonly decoupled from other process workflows. In Nexus, project management functionality is integrated with any and all of the other apps. This means that the individual steps of a workflow from another app can be shown as part of a Gantt chart in project management. In fact, workflows from multiple apps can be shown in one project management schedule.
A Flat Cost
How is it priced? You pay one subscription per user for all of the 140 apps. There are no additional modules to purchase.
Commentary and Analysis
Okay. We talked a lot about the functionality of Nexus. But what does it mean? Below you’ll find my thoughts on any benefits or detriments these capabilities might provide.
“Instant-On” and an Evolutionary Approach
This was another phrase that was repeated consistently during Autodesk University. The fact that Nexus is in the cloud, has templated apps and can be configured quickly has important implication. As soon as an organization purchases Nexus, they can begin to use those processes that day. There’s no installation. No need to make infrastructure investments. No need to curate databases. None of the carefully crafted activities typically associated with standing up a PLM system. Just point your browser to the right place and it’s there.
Over time, that organization can quickly or slowly tweak Nexus to their needs. This slow evolutionary approach stands in stark contrast to the typical deployment of a big box PLM system, where planning and customization can take months if not years.
However, let’s be honest. Almost any PLM system can be installed and made accessible in days. The real hold up typically falls into two areas. The first is in process planning where the organization, or multiple organizations, has to come to a consensus on process definitions. This second is in configuring or customizing the PLM system.
Autodesk is preaching approach to “turn on” Nexus and quickly configure it to represent the processes you run today. It sounds good in theory, but I imagine organizations will continue to engage in their politics over processes regardless. Will the “insanely configurable” characteristics of Nexus hold up on production systems? Will it break running processes along the way?
Overall, I think these concepts are incredibly powerful and beneficial. I think it is the approach that makes sense. But then again, this is all theory as there are only a couple of customers on Nexus right now. Only time will tell if it lives up to the promise.
Granularity and Incremental Deployment
I have to admit that, per a past post I wrote titled My Points in the ‘Why Hasn’t PLM Taken Over the World’ Live Blog Debate, I agree with a definition of PLM where it is decoupled from other types of applications and systems. And I think PLM independent of PDM is a sound concept.
PLM doesn’t include CAD, CAE, CAM or Digital Manufacturing: I like to separate out these other technologies so I can truly asses that PLM is delivering value independent of any other type of engineering software. Otherwise, how do you know if your investment in PLM was worth it?
And furthermore, I have to admit that I see an increasing attractiveness of granularity for PLM functionality per a post I wrote titled Point Solutions, Integrated Solutions and the Granularity Value Proposition.
PLM Granularity: So what’s the concept here? Actually, I originally heard about this concept from Oleg. And he’s written about it time and again at his blog beyondplm.com, but the fundamental idea is that you layer on different solutions that each do something very specific and well. Basically it is the point solution approach but from an ecosystem perspective. It would include something like leaving your workgroup PDM software in place. Layer on top of that a workflow. Then add some social computing solution for collaboration. Then you can add in a project management solution. You get the idea. Leave what you have in place. Add in other point solutions where needed. And integrate them as lightly as you can.
The Motivation behind PLM Granularity: So why take an ecosystem approach with point solutions? Well, I think the answer to that question is a whole lot more about someone’s history with PLM than anything else. You see, there’s a host of people out there that have championed a PLM solution. They introduced the concept to the company. They got it purchased by an executive. They were most likely the lead in getting it deployed. And it some of those cases, it failed. Not all. But not all PLM deployments are not successful. And that’s a detriment not only to the organization but to that champion’s career.
That has led some champions as well as some executives pledge a vow to never again pursue a large long scale deployment of PLM. They’re scared of it. And in some cases rightfully so. But they’re not willing to give up on technology as an enabler of better product development. They often still believe in that. So the most palatable means forward is a granular approach. Not because it offers better capabilities or will enable the organization to necessarily do more. But because it is far less risky, both for the organization and their careers. But ultimately, this is all about backlash against the big box approach to PLM.
Nexus seems to fit this sort of profile. The ability to turn on one app’s functionality at a time is important in this regard. It lets an organization adopt PLM in a granular fashion. Other PLM systems certainly offer modules with functionality that has been separated out. However, with Nexus, the individual apps are so granular, remember that there are over 140 of them, that organizations will have an unprecedented set of choices to move forward with PLM.
Venturing Where No PLM…
During demonstrations of Nexus’ dizzying number of apps, I came across some things that surprised me. I saw some process definitions that not only were applicable to those outside engineering, but some processes they had no application to engineering at all. For example, there is an app that supports the tendering process, where supplier can submit their request to be involved in RFP activities.
That’s when I came to an interesting realization. Nexus is a generic workflow engine with some product development stuff added on the side. You can use this offering for processes for all sorts of different organizations within a manufacturer such as procurement, finance, supply chain, quality, human resources and so on.
Now there’s an interesting implication here. With this product Autodesk is not only entering the fray with PLM providers like Siemens PLM, PTC, Dassault Systemes and others. They could find themselves in competing with any provider of workflow like functionality within the enterprise.
If you’re the PLM champion in your organization, be careful how far you position Nexus into the company. Make a wrong step, perhaps under the toes of a champion for the ERP, SCM or sourcing system, and you could find yourself in a political war. Proceed with caution.
Conclusion and Questions
At the end of November 2011, Autodesk unveiled a PLM product called Autodesk 360 Nexus. This product is part of a software family called Autodesk 360 that also includes Autodesk Vault and Autodesk Buzzsaw. Nexus is cloud based, includes over 140 apps and provides what seems to be quick and easy configurable functionality.
From my perspective, these characteristics in theory translate into an “instant on” PLM system. It promises to allow organizations to start using the system immediately, tweak the app templates to represent existing processes and evolved them over time as necessary. It also allows organizations to adopt PLM in a granular fashion as opposed to the long and drawn out deployment of a big box PLM system. This new product seems very promising in terms of successfully rolling out PLM and then tweaking it to your needs as they shift.
As you consider Nexus, take into account that this newly launched offering that has yet to be adopted wide scale. If your PLM strategy is particularly reliant on the “insanely configurable” capabilities, make sure you test them against a working environment that represents the evolutionary environment you plan to have.
I’ve given you my perspective, now it’s your turn. What do you think are the most important capabilities of Nexus? Does it seem truly different to you? Are there any other areas of concern? I’m interested to get your perspective.
Take care. Talk soon. And thanks for reading.
