To Teamcenter or not to Teamcenter that's teh question

[gieter]

Hi all,

We've been using UG for about 10 years. Currently we have 3 CAD seats and 1 CAM seat. Everyone is working on his own parts/assembly's, there's no collaborate design and we don't use BOM's. Assembly versioning is somethimes messy, but seldom problematic (it's more in the sence that you know that you have done something wrong, but there are almost never consequences what so ever). We reuse a lot of what we modelled in the past and this can all be found relatively easy whitin a well structured directory system.

Now, we feel Teamcenter (only CAD file management) might come in handy but we have some worry's:
1. How are old files handeled? Do they need to be "imported" into Teamcenter in some way?
2. How much time is needed to set the whole thing up?
3. What about transitions to new NX versions?
4. Is it realy worthwhile?

"There are easier ways of earning a living than in the casting industry. But few are as exiting"
After Prof. John Campbell

Gieter

 

[looslib]

If you don't run into problems with file versions and 'he who saved last wins' scenarios, don't do TeamCenter.
Setup could take weeks as you need to define your process flow and be sure the software is configured to match. You can also do an OOTB implementation and match your processes to the built-in work flows.
Old files can and should be imported into TeamCenter so you have them all in one location.
NX versions and TemaCenter versions need to coordinated when upgrading. This is usually the hardest part of an upgrade.
Worth it? What are you hoping to gain from TeamCenter? If you have a working process and are not running into problems, then with 4 seats, I would say NO.

I was a CAD admin for a 35 user shop and with home grown GRIP programs and scripts we managed our UG data with very few problems.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[gieter]

Ben,

Thanks for your valuable input. The only reason we would opt for Teamcenter is that we are renegotiating our license bundles. Our current bundles date from 10 years ago and we were now proposed to switch to the MACH series. The problem is in our view we loose a lot of functionality and will pay more license fee. Teamcenter is proclamed as the big asset to compensate this all. But I have my doubts and after your comment even more.

The big problem is that with the MACH (and other) bundles they droped prices but increased license fee's under pressure of the midrange market. The problem for us, long lasting users, is that our bundles are no longer up to current standarts although we payed a lot of money over the years.

Maybe it's time to think of a switch to a midrange software?

"There are easier ways of earning a living than in the casting industry. But few are as exiting"
After Prof. John Campbell

Gieter

 

[looslib]

Take the bundle with TCe in it, just don't implememt TCe!

"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[hudson888]

You'll likely get the better version of the JT viewer if nothing else.

Teamcenter is a very good tool, but like all tools is has a purpose that it is best fitted for. in this case it is a large organisation with lots of users working together often in remote sites where communication takes a back seat to a form of discipline which Teamcenter would aid you in a lot.

If on the other hand you're a smaller concern and need to readily exchange native data with clients of suppliers at the minimum of fuss then you may not really need Teamcenter. Then you start to look at the fact that it needs extra system resources, training and implementation and you might conclude that you're not really in the market for something like that.

If you're in between then Ben's idea has merit since you'll benefit down the track if you later expand or decide to hook up with other companies in your corporate group and make real use of having a database to integrate a wider range of activities.

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum