I just spoke to my boss yesterday about my responsibilities and they are what de_ding said plus
- being familiar with and understanding design codes and standards for all disciplines(ANSI, API, AISC, ASTM)
- being willing to work with all peoples and disciplines (people skeells)
- being willing to crank out draft drawings on a project if the need arises (which it does!)
- keeping the company up with the latest software and hardware requirements, and looking at tools beyond just AVEVA products (Navisworks, WalkInside)
- creating training classes and schedules to bring the rest of the team up to speed, whether it be new users to PDMS, or a quick short class on the newer applications in PDMS 11.6.sp2 & sp3
- maintain the pdms master catalog, and be sure that the elements in that catalog are checked and backchecked by very particular checkers, to ENSURE that the company catalog is correct.
- to represent to company in a professional manner when discussing PDMS procedures with other companies and clients
- to create presentations and speak at company meetings on the benefits and drawbacks of using PDMS, and to speak about the accomplishments and disasters encountered while using this software
- to know that there is no task below me, being PDMS Admin does not mean that people work for me, but that I work for people, the PDMS administrator should be a SERVANT to the design team. and that is what I strive to be. I have worked for administrators that refused to do thier own cats and specs, that wouldn't touch draft if thier life depended on it, that couldn't tell you if a 2X1.1/2 PBE SWAGE was male or female (true story) and couldn't place that component in the model. Sure, they could add users to a project, yeah they could write a collection macro, but they didn't know what to do with that collection when they got it. I am a USER first and an ADMIN second. Like DE_DING said, projects should run on autopilot, and while they are on autopilot the admin guy should be useful at something besides waiting to set up the next job. It was made very clear to me by my boss that not only is it ok if I get involved in projects at the engineering and design levels, he fully EXPECTS me to be involved at these levels. You can be a better admin person if you see yourself as a benevolent server to your team, not as some untouchable jerk that sits in thier office all day mulling over pml code and trying to think of the next totally useless tool to implement.
I just spoke to my boss yesterday about my responsibilities and they are what de_ding said plus
- being familiar with and understanding design codes and standards for all disciplines(ANSI, API, AISC, ASTM)
- being willing to work with all peoples and disciplines (people skeells)
- being willing to crank out draft drawings on a project if the need arises (which it does!)
- keeping the company up with the latest software and hardware requirements, and looking at tools beyond just AVEVA products (Navisworks, WalkInside)
- creating training classes and schedules to bring the rest of the team up to speed, whether it be new users to PDMS, or a quick short class on the newer applications in PDMS 11.6.sp2 & sp3
- maintain the pdms master catalog, and be sure that the elements in that catalog are checked and backchecked by very particular checkers, to ENSURE that the company catalog is correct.
- to represent to company in a professional manner when discussing PDMS procedures with other companies and clients
- to create presentations and speak at company meetings on the benefits and drawbacks of using PDMS, and to speak about the accomplishments and disasters encountered while using this software
- to know that there is no task below me, being PDMS Admin does not mean that people work for me, but that I work for people, the PDMS administrator should be a SERVANT to the design team. and that is what I strive to be. I have worked for administrators that refused to do thier own cats and specs, that wouldn't touch draft if thier life depended on it, that couldn't tell you if a 2X1.1/2 PBE SWAGE was male or female (true story) and couldn't place that component in the model. Sure, they could add users to a project, yeah they could write a collection macro, but they didn't know what to do with that collection when they got it. I am a USER first and an ADMIN second. Like DE_DING said, projects should run on autopilot, and while they are on autopilot the admin guy should be useful at something besides waiting to set up the next job. It was made very clear to me by my boss that not only is it ok if I get involved in projects at the engineering and design levels, he fully EXPECTS me to be involved at these levels. You can be a better admin person if you see yourself as a benevolent server to your team, not as some untouchable jerk that sits in thier office all day mulling over pml code and trying to think of the next totally useless tool to implement.