DBWorks vs. PDMWorks Enterprise

Yes, DBWorks has ECN (they refer to it as "ECO") functions and standalone seats available at discounted prices for non-SWK's users. DBWorks can also store numerous revisions for rolling back or history reasons. The biggest thing that pushed DBWorks to the forefront was it's capabilities to handle configurations were as PDMWorks has/had problems.

Yes, "workflow" is the term used for this process. We are just getting started with DBWorks and will ease into workflow a little later on.

I have trained as a dbWorks administrator. So here goes.

1. dbWorks does handle workflow. It is highly customizable in this area. There is a special application bundled that allows you to create a great deal of business logic into a dbWorks installation. It can handle MSoft documents if that is how you chose to create the paper part of this process.

1. I wouldn't count on dbWorks being an ERP system. PDM and ERP are two separate things.

2. dbWorks will work well with many ERP systems through either ODBC or XML based interfaces.

1. Implementing PDM and or ERP requires a lot of planning.

Make sure the PDM system you get works well with SW. I have found dbWorks to be one of the best in this area. It handles configurations quite well including revisions of configurations. However, it is not always intuitive and requires training.

Keith:

When you mention "PDMWorks has/had problems", are you talking about the PDMWorks Workgroup that comes with Solidworks as an add-on or the PDMWorks Enterprise (was called Conisio)? I just want to be sure that I am comparing "apples to apples".

I think both PDMWorks have had problems with configurations. That is one reason neither PDMWorks nor Conisio didn't make our short list.

How well does it handle workflows out of the box? Did you have to do a lot of customization to get it to work in a reaonable way for your business? How easy was the customization?

How hard is it to establish the links? Is setting up dbWorks to work with an ERP system relatively straightforward, once you figure out what you want to do?

Any specific pitfalls you would like to point out?

Are you speaking particularly about configurations when you say "it is not always intuitive and requires training"? We gave up on handling configurations in ProductCenter because it seemed to be a lot more trouble than it was worth to us. I'm wondering if we would have the same attitude if we switched to dbWorks.

Jerry Steiger Tripod Data Systems "take the garbage out, dear"

They supply a default simple workflow. The tool they have for this is fairly easy to understand. It can work with MSoft Exchange and MSoft documents like Word.

I'll say this as a blanket statement that applies to any PDM installation, don't expect the software to figure out what it is that you do and to do it for you.

Most of what you initially do is done in setting options. The vendor supplies a few scripts depending on what you are trying to do. It will work just fine out of the box if out of the box is what you do. Probably it isn't.

See my answer above.

Know what it is you do. I mean really know it. People have a hard time sometimes actually explaining what it is that they do. PDM is a program and it needs to make choices based on unambiguous data.

When interfacing with ERP one of the biggest issues is the BOM. Many times the BOM that the ERP uses will not be the BOM that PDM uses. Consider for example the many things that are in a MFG BOM that won't be in PDM like boxes and bags, instruction manuals, tape, glue, etc. Consider that 12 bolts may be sent when there are only ten in the assembly because installation people need extras. Consider that the MFG BOM may group parts differently than engineering and SW because of assembly considerations.

Make sure the ERP vendor is willing to work with dbWorks people in defining how dbWorks is to interface with their ERP. As with any situation where two software have to talk to each other such a relationship is a must. dbWorks can deal with either an ODBC or xml type transfer and has a module called dbWerp that handles the interfacing and business logic translation.

Configurations are absolutely no different than anything else with an item number. Totally transparent. The only thing you have to keep in mind is that when opening an item that is a config is that you are opening/checking out the part or assembly and therefore all configs at the same time. Config revisions can be tracked separately from file revisions. We actually don't look at file revisions but at config revisions. The only monkey business necessary is due to the auto number generator. We enter a bogus part number when creating a new config and it then assigns a number automagically. This is even true when configs are created in a Design Table. Our setup is such that 1st level configs become items and are tracked while sub configs are not. This allows us to have alternate position configs, simplified configs, etc. without fiddling with tracking them in the PDM. dbWorks also will write to custom props or will do it's own version of notes on a drawing.

Now as far as implementation goes I will say this. If you are not comfortable writing and or working with VBScript and SQL I would pay dbWorks to do a turn key installation. In our case I was comfortable and just used their help desk from time to time. But there were some setup issues that had we known the implication would have avoided. That is where their experience would have come in handy.

When implementing I would also plan on the down time necessary to register files and set things up. We tried to use it while still registering and created some problems for ourselves.

There are two vendors in the states. I like both, but have only used one. There is also a user group run by a very capable fellow who also wears suspenders at SWW.

Thanks, Paul. Very good answers to my questions and very good advice to those who want to set up a PDM system.

He's a hell of a good guy!

Jerry Steiger Tripod Data Systems "take the garbage out, dear"