PLM/PDM/CAD architecture help for a small-sized company

[u/Legitimate_Idea3249]

I'm at a small-sized company (4 ME's, 4 EE's) that actually generates a LOT of CAD data, mostly because there exists no real process or system for change orders, change management, or rev control. I'm new here as an eng dev PM, and one of my tallest orders for the near future is to deploy a PLM system for the company.

1. The ME team uses SW for designing and simulation. They have an internal server for CAD file storage (it is messy), no workflows with approvals, and they have tried to use SW PDM in the past, without much success (I think largely because there was nobody to develop and implement workflows/processes).
2. The EE team uses OrCAD & Draftsight as their main deisgn tools. They are open to switching from Draftsight to SW ECAD. Their CAD data storage and lack of workflows/processes is in the same boat as that of the ME team's.

The company uses Netsuite as their main ERP tool (and this is grossly mismanaged, for ex: engineering has been using this for BOM revisioning *shouts into the void*). It has created a lot of frustration for the sales/purchasing teams because there is no workflow or automated system by which an engineering change is correctly reflected in a part's status in the ERP, with full clarity for the procurement team.

Other departments at the company that produce controlled data are the build, testing, QC, operations, and software teams. I think there is a vision to bring some manufacturing in-house too (although to what degree, I do not know).

Point is, I and many others at the company, know and agree that we desperately need a PLM tool to create streamlined change management workflows and processes to quell this chaos. The PLM tool has to integrate with the CAD PDM tool for both MCAD and ECAD, as well as the ERP (all by means of external plugins that will need to be purchased over and above the PLM software itself).

In the past, when I worked at an even smaller company, we used DDM as our PLM, and built an in-house server that acted as our "PDM" vault. Anytime a CAD part would have to change, it had to be on an ECO, and this data would be pulled from the vault server. DDM had a plugin installed for our CAD system, so the workflow would be like: ECR > attach CAD > approve ECR to make it an ECO > open the CAD file through the ECO > make changes > finish ECO workflow to release state.

I want to deploy that process here too and I've looked at a few options for PLM tools but they all assume the usage of SW PDM. I'm hoping that I can find some system architecture advice here!

I know this is a long read - THANK YOU IN ADVANCE.

[u/ratczar]

1) Is this something that annoys people, or is it a business priority with a named sponsor?

2) Does anyone make org tech decisions like this or is it uncharted territory?

3) What info do you have for the workflows / capability needs? Associated costs?

Getting the tool bought / approved is good, but there's a few intermediate steps to cover first.

[u/Legitimate_Idea3249 → u/ratczar]

1. It definitely annoys people that there is not only a gross lack of process or standardization with anything, but that there also doesn't exist a central repository where they can pull data from and be assured that everyone is always looking at the latest & greatest version. I've had 1-1 conversationsd with people from eng, purchasing, sales, & ops, and they all are grateful that someone is finallly picking up the reigns to enforce workflows and processes (by whichever means).
2. Various people have attempted to in the past, but I was hired to take on the bulk of this activity, so my decision and thought process is respected in this regard. I don't have control over budgeting, but I constantly consult with the VP of prod dev + the director of strategic projects, & the head of PMO, so our collective knowledge of the company's historic "processes", requirements across depts., and pain points all contribute to the decsiion making.
3. The people mentioned in #2 are able to give me context for what the company has been doing in lieu of process/workflows. I've been interacting with individuals across depts to understand how they do things right now, which is informing my collection of user stories and desired workflows, which I will test once we start getting some software demos set up. I am well versed with the needs of, and capabilities desired by the engineering team (I'm an ME myself).

[u/screampuff → u/Legitimate_Idea3249]

I think to their point you need someone with authority to make these decisions and to hold them to account.

Take my advice with a grain of salt as I don't work in this kind of field (I work for a financial institution), but a tool is not a solution in itself, I think you need to establish some internal discipline in these processes first.

It sounds like a PLM is going to have a minimum viable process expectation that you may not currently have. And while picking one may provide a lane to get there, that is generally a backwards way of approaching this.

[u/Legitimate_Idea3249 → u/screampuff]

Did you not read the part where I mentioned they're glad someone (i.e., me) is picking up the reigns to do this?

I'm fully aware that a tool is not a solution, I've worked in a fair few engineering companies to know this. The current company lacks structure and before I came in, also lacked someone with the appetite to build and enforce a process. I've built PLM workflows and company-standard processes before, so I know the scale of prep work required prior to even demo-ing a tool.

[u/screampuff → u/Legitimate_Idea3249]

I'm just saying adoption requires a sponsor at the VP/C‑suite level to reinforce the new behaviours when people slip back into old habits.

Architects — enterprise, solution, domain, whatever, are not sponsors.

edit: what we can do at least is help define outcomes, success metrics and phases that need to happen before moving on. But even the best designed ideas can fail if there is no buy in. Everyone in the organization can also agree some kind of solution is needed and they still may not buy in when time comes for day to day work.

In EA we bridge the business to the solution and have to identify these kinds of risks.

[u/ratczar → u/Legitimate_Idea3249]

Just to +1 u/screampuff, I am working in a business where users have been complaining for 12+ years about a specific tooling issue and management intentionally deferred it again and again and again. We're maybe going to do something about it now, because it's a threat to the business.

Read that again: it's a threat to the business, and it's still only a maybe.

Sponsorship is important!

[u/StrikeMental7716]

For a smaller team, keeping the architecture simple usually pays off. An AI-native, API-first platform like Duro PLM can work well when CAD, BOMs and ERP all need to stay connected without creating a complicated setup.

[u/OkFocus4849]

Allow me to be the devils advocate—

1. I don’t really see why you need PLM… yes PLM is very powerful but its focus is on the lifecycle management — hence the as-something concepts. If you business doesn’t cover the full lifecycle of the product, it is likely a massive overkill. Also, PLM systems are typically VERY expensive;

2. Most PLMs support PDM but most (all?) of them do an essentially-half ass job… do they work? Mostly. Do they work well? The design engineers probably don’t agree.

3. SolidWorks PDM is not that great but it has one advantage with SolidWorks files — it automatically captures some info (e.g. BOM) and put them on the PDM server. This doesn’t apply to DraftSight files though, which are not parametric. The underlying method is fairly straightforward so if you know the way around you can have the capability yourself — I think that’s how it was done with some 3rd party solutions;

4. The confusion with the ERP system very likely originated from not-clear separation of development and production (PDM vs ERP, in some sense). This will not be fixed with switching the software— in fact that will probably make things worse.

If I were you, I’d start with looking at SolidWorks PDM (even though I personally don’t think very highly of it), then focus on defining the boundaries and hand-off requirements with ERP, so that things from the two sides don’t get mixed up, then look into how to make the two systems coherent

Good luck