Moving into Teamcenter any advice? 1

[TTRYON]

Can anyone please advise?

My company is currently planning on moving into Teamcenter from native UG. We are fairly large company with at least 7,0000 individual parts and an estimated 8x as many .prt files. I am most concerned about the planning of this project. The individual responsible for the change over has never set eyes on Teamcenter and believes that it will be a "Plug n Play" event. I have some experience with Teamcenter through General Motors and Boeing but not enough to understand the migration process. If any of you have migrated into Teamcenter, I would apreciate any advise you could offer.

Thanks in advance,

TCT

 

[fgbrender]

You will find out that Teamcenter is not "Plug N Play". There is carfull planning and configuration that must be done before a single part goes into Tc.

First of all, what do you want to migrate into Tc? NX data? Part specifications? Change management? Manufacturing data? Product Visualization?

Second who will be using it and for what purpose? Designers, managers, engineers.

Third, training will be needed.

My advice is find someone who specializes in Tc migration. I have been involved in Tc developement, training, migration, etc, since 1996 and I think I can say with some authority that you need expert help if you want to have a smooth migration.

 

[TTRYON]

Do you have specific examples that I can bring up to management that might open thier eyes.

TCT

 

[Shadowspawn]

Ttryon,
I've no experience actually migrating to Tce from an IT perspective, but I got a bit of experience as a user... When the company I was working made the migration, a lot of it was plug and play but we still had a ton of work to do and we never got all the bugs worked out.

For starters, plan on spending some time addressing the probs you will encounter with how your planning to handle (if the following situations apply...they did with us) 1) seed parts, template parts, your standard library, tabulated parts, revisioning rules, load options, mating conditions, reference sets, how you'll distinguish legacy parts (pre-Tce) and parts created in Tce...

*breath* ...depending on how much customization you have with programming and how your treating your standard library (assumming you put dwg formats, decals, notes, etc, in there...) you'll have to addressing distinguishing between the native and Tce environments (ie calling parts from the native directory and calling parts from the Tce db (encode/decode the file name/rev)). We used a bit of grip that called patterns and we never could get that part of it working right...

I'd certainly advise getting someone experienced with actually migrating UG into Tce and resolving the issues. Generally speaking, the actual migration of the part files was a lot easier and painless than discovering and resolving all the issues that cropped up. Good luck with it all... ;-)

Regards,
SS
CAD should pay for itself, shouldn't it?

 

[fgbrender]

Wow, I could write a book on it...

First you need to determine exactly what you want Tc to do for you. If you are only going to store parts you need to determine what Item Types and dataset context to use. You need to determine workflow and create the workflow. You need to determine roles and create user IDs for those roles. You need to determine release status. You need to determine how you are going to map your native parts to Tc and create a migration utility to migrate the parts. You need to train your users. You have to decide which attributes to sync between Tc and NX. Not to mention are you going to be using Tc Vis, Tc Web, Tc Manufacturing. What about variant condition and BOM configuration. Are you going to use Design Context, if so there is configuration to be done. You'll need DBAs who will need additional training. Probably need some support folks as well.

For every point I mentioned, there are ten I did not.

Like I said, I've been involved in Tc migration and developement and training and support. Migration is not a hard thing to do but it take knowledge and planning. You will not even begin to get the answers you need from this forum. There's just way too much to consider.

My best advice is to have Tc set up and tested prior to attempting to migrate. You don't want to put data into Tc unless it is meeting your needs first.

You really need some experts. If you don't have them internally, there are some very good companies that specialize in Tc implementation.

 

[TTRYON]

Fbbrender,

Thanks for your post, it is all great advice. I spoke with our manager about the issue and they are beginning to look at some of these points. I have been encouraging them to get outside assistance but I have the feeling that I will be difficult to get funds allocated. I am hoping that I can enough people trying to do this the right way that we don’t end up with a huge mess.

Thanks again,

TCT

 

[fgbrender]

Ttryon,
Your company can probably do a successful migration without any outside help. Just keep in mind to define exactly what you hope to accomplish prior to migrating. Read the docs that come with Tc, they're pretty good but some experience helps.

When asking questions on this forum, be specific. For example instead of asking how to write workflow, give details on who will be using workflow in what roles (designer, approver, checker, etc.).

Don't be afraid to ask questions. Some things may seem pretty simple, but a second or third opinion may save time and money.

Also, there is a reason the Tc experts get paid big bucks. It's because they know what they are doing. You may save some money up front but all that savings probably will be lost with all of the problems you will encounter as well as the extended time it will take to migrate. I've seen it happen on more than one occasion and it's not pretty.

Good luck on your migration and feel free to ask anything, just keep it specific. Tc is a great tool but like anything else it requires some sort of investment (time or money) to get the most out of it. The more you put into it the more you will get out of it.

 

[pinetti]

As an example of things going the wrong way, after two years we are still trying to get TC to work properly.

Therefore, everybody here is rigth. Help is needed, but not expert UG help but TC expert help.
We have had around people very good with NX and often enought they told us "this works in native NX!!!"

And also make sure that NX users and IT people are involved from the beginning!!!!

Good luck

 

[fgbrender]

Good point, it takes more than just a "Tc expert" to have a successful implementation.

A well rounded team is vital. Your end users are also experts. Not Tc experts but they are experts in their deliverable.

A good team consists of the following:

A Project Manager - this person is responsible for making sure the project is on track and all requirements are being met. He/she reports to management and the rest of the team reports to him/her for the duration of the project. This person does not need to be a Tc expert but should be well rounded in your overall product development process and flow.

Tc Expert - This person or persons should know everything there is to know about Tc. This role will provide advice on Tc configuration, will provide training during the testing phase and to end users, will act as a mentor, etc. This person should also be able to do basic Tc configuration such as workflow authoring, ID creation, build queries, etc.

Tc developer(s) - This role would do any site Tc customizations involving the use of ITK and programming in C and Java. Not needed if you are using out of the box Tc.

End Users - Designers, Product Engineers, Manufacturing Engineers, etc. These people will be defining requirements and testing to make sure the requirements are met. These requirements are for Tc setup and for enduser training. Basically htey need to represent anyone the would have a role in Tc. It is a good idea to get a good cross section of skill sets here. Get some experts and novices so you can be sure all skill sets will understand the tool.

IT - Someone needs to install and maintain.

Steps involved predeployment:

Training - All team members should be trained in out of the box Tc before even starting the project.

Requirements gathering and documentation - Define exactly what you want to do with Tc. Don't be afraid to ask for the world. It's better to ask for something you can't have that to not ask for something you can. Espescially if that something will save you time and money. It's a good idea to have UGS involvement at this point. They can tell you what Tc is capable of and give advise. Just make sure you tell them what you want and don't let them tell you what they think you want. This is also a good time to develope a training and an implementation plan (including schedule).

Installation in a test invironment - Tc should be installed and configured in a test environment. This is where your end users will make everything works as desired. The test database should contain enough data (parts) to mimic the production environment. This is where you try to break the process. Notice I didn't say "break Tc". If there are any breakdowns, it is because you are trying to do something Tc cannot do or is not yet configured to do. Once you figure out what is wrong, it can be fixed prior to production implementation.

Testing - This is where the end users on your team will run production senerios in Tc and make sure the requirements have been met.

Training developement - Develope the training for the production community. This includes any specific courses that will be needed as well as any high level work instructions.

Training delivery - Train your production community. This should be done in conjuction with production implementation. You want your users to leave training and go right to work in Tc.

Production implementation - Implement Tc for production.

Mentoring and support - There will be an extended time where end users will need help.

Like I said before, I could write a book on this subject. Its pretty involved but done right it is also pretty easy.

Most companies allow up to a year for Tc implementation. The most important thing to remember is get it right before going to production.