Today I skimmed an article in Desktop Engineering about PLM, and they talked about all kinds of things but not end-user productivity. My experience has been that using PLM to control your released drawings works very well (as plot or image files), but trying to control the native CAD 3D models is a productivity nightmare.
So I'm curious what the rest of you think. What do you use, for which files (3d models, .drw's, released files), and how is it performing? How large are your projects and how much collaboration do you need with your 3D data? Do you have incompatibilities or bugs with it?
So far, my PLM experiences are with Pro/PDM, Pro/Intralink, and customized version of eMatrix. I've seen all of these past employers do the same thing - spend a whole lot of time / money on getting things set up, then discover that most users are getting horrendous performance, and incompatibilities with their data and the PLM system capabilities. Then the money has run out and the company's CAD users are crippled every day with these long checkouts and checkins, and workarounds or limitations because they didn't implement all the features that were planned.
At my current employer we are (fortunately) a small group of engineers and we keep our Pro/E files organized by organized use of network folders. Our released files are archived in a PDM system as .tif documents. Our projects are small enough that we stay out of each other's hair, but if there existing data to be re-used, we usually find it pretty quickly. I'm very happy.
Dave
I have nightmares about working in a mom-and-pop-shop where digital data management is a do-it-yourself project. I think it's bad enough, with an advanced dbm system keeping track of files. I can't imagine a team effort without PDM/PLM/MRP. I too have worked in a variety of them, from Pro/PDM, to Ilink to UG Iman plus a variety of ERP/MRP systems. It's just too complicated unless a) you are very disciplined and/or b) you own a project and its main files then find a way of working with other people's files that somehow parallels the checking activity of Oracle and the verification activity of ModelCheck. This could work in a part design environment, but I don't work on multi-thousand part assemblies, along with a dozen other people, based on verbal/email communication. In fact, it's hard enough when the guy's sitting right next to you to keep track of what each is doing and make sure that you're not stepping on each other's toes, wiping out each other's work. That's enough to get the nightmares going.
As to the check out/check in business, I've had nothing but good "luck" or good network/pdm system admins. The hardware can always be improved, but companies will go cheap on the skilled, technical help before the hardware. Putting it another way, they can get good tax creadits for "capital improvement" (buying a lot of computers) which they'd never get for spending twice as much a year to get a really good, qualified, experienced sysadmin. And, getting a complex system like Ilink or Windchill PDM-Link set up and running smoothly and efficiently takes one of those people. So far, I'm very impressed with how fast such a networked system can run, e.g., 1300 files transferred in 5-10 seconds over a gigabit network is typical. When anything takes longer than this, I suspect network connectivity troubles, heavy network traffic, bottlenecks, slow license servers, slow hubs or ports, a host of other software/hardware network issues. Consider that Pro/e is a heavily networked program, from many years ago. In just launching WF3 SE, xtop opens a port, nmsd opens two ports, pro_com_msg opens two ports, and that's without tring to connect to PTC or establish communications with Ilink/Oracle or a separate license server. Or if you had to negotiate the connection to a Linux file server or Ilink server and a native WinXP instal of Pro/e, you could have tremendous connectivity problems that would require the abilities of a couple skilled network people and Pro/e/Ilink sysadmin people. Aside from whether you got all the program bells and whistles, there's a very big consideration of whether you have the network people to deal with the level of complexity involved in getting Pro/e, Intralink, Oracle and at least one operating system to communicate effortlessly with each other. It's the first place I'd look, anyway!
David Janes