Industry Insights

Read articles by industry leading experts at Tata Technoloiges as they present information about PLM products, training, knowledge expertise and more. Sign-up below to receive updates on posts by email.

Fundamental to any PLM system is the idea of Access Control and data security. Only authorized personnel can access a PLM system and view or manipulate its contents. This is controlled via a login procedure that includes a user password. Personnel are added to the list of authorized users by the PLM administrator after someone has approved of their specific access rights.

Once access has been granted to users, it must then be determined what operations they can carry out on the PLM system. The simplest (and default) security model which allows all users to carry out any operation is very undesirable and could lead to actions that can destroy or leak vital data.

This scenario requires the development of a Security model which determines which user can carry out which operations. Security models are normally based on two concepts:

  1. Roles
  2. Organizations

A role in the database would define what the user who is assigned that role is allowed to do. Typical roles are as follows:

  1. Viewer – this role would be allowed to view data but not make any alterations or modifications
  2. Team Member – this role would be allowed to alter and update a limited subset of the data along with being able to carry out certain operations (e.g. initiate a workflow)
  3. Team Leader – this role would be able to do everything that a Team Member could do along with the ability to operate on a larger subset of data and carry out more operations (e.g. progress a workflow, change ownership)
  4. Approver – this role would be able to approve certain operations on the data (e.g. approve a release of information)
  5. Database Admin – normally limited to a handful of technically qualified people

Once roles in a database have been defined, the organizations are put in place. These normally mirror actual organizational structure, although this is not a necessity. Organizations in a PLM system usually work on specific projects or programs. Once the organization is defined, users are allocated to various organizations and are assigned specific roles.

The final result can be represented in a table as follows:

Within Organization Outside Organization
User Role View Modify Approve View Modify  
John Doe Team Leader Y Y N Y N
Paul Revere Team Member Y Y N N N
David Earp Approver Y N Y Y N

So how is security set up in your PLM system? Are all the security capabilities been used to ensure that no intellectual property is destroyed or leaked?

Back in the day…

There it was, one of the first internet communities, Usenet, about to undergo a sea-change unlike any it had seen before. It was 1993, September, a month that would never end.

IT - Ethernet Cable outletIt started much like the years had before; an influx of new people coming into the universities, getting online for the first time. The community absorbed them in much the same manner as they had in the past. These first-timers were indoctrinated with the well-established etiquette and protocols that were required to thrive in this brave new world.

It seems archaic now, but back then, in the “before times”, there was no way for mass discussion; social media had not yet been born.

The plot twist

And then it happened. AOL, then a name synonymous with the internet, decided to grant access to Usenet for all of its customers. Picture the mobs that gather outside department stores the morning after Thanksgiving: the unlocking of the door let loose a mass of people that overwhelmed the community. There were just not enough graceful souls able to help coach these new users in “civilized” net behavior. Social norms were thrashed; standards went out the window. It was the equivalent of the wild, wild west. In a word, it was chaos.

Future looking

Misc-Walking-peopleNow think of how you on-board new designers or engineers. You show them who’s helpful and who to avoid. You show them around, pointing out places of interest, teach them company standards, design methodologies, workflow processes, etc. Over the coming decade (to be exact, 2014 through 2024), according to stats provided by the Bureau of Labor Statistics (BLS), the Architecture and Engineering field will grow an average of 3.4%, or about 710,000 jobs.

The biggest (projected) job gainers:

  • Civil – 106,700
  • Mechanical – 102,500
  • Industrial – 72,800
  • Electrical – 41,100

Manufacturing - SuspensionCouple this with the BLS projection of labor force participation over the same time period where we’ll see a 1:1.3 ratio of people leaving the work force to people entering. That will be a lot of churn, meaning a lot of people to on-board. The products will be ever more complicated, and the enabling technology will be as well. Technology is cited as one of the reasons the field isn’t growing as fast as other areas.  The productivity gains in PLM are making companies more efficient, even as the complexity grows.

Conclusion

Business - Chess pawn inverseCompanies will need a strategy for managing changes in their employee base as well as the technology evolution. We offer a series of benchmarking and analysis services called PLM Analytics, and there is one specifically aimed at this issue called PLM Support. Let us know if we can help solve your Eternal September.

So your company has embarked on the PLM journey. Strategy is agreed, budget is approved, the preliminary plan for execution is in place and Return on Investment has been computed.

The next step in the process is choosing a software suite and an associated vendor. Unfortunately, the nature of software is such that one cannot mix and match programs or modules to suit specific requirements; the major vendors design their solutions is such a way that organizations are locked into a specific monolithic offering. The choice of vendor then has long term ramifications and, on the face of it appears to be a momentous decision.

So, how does one choose a PLM technology vendor? For the purposes of answering, let us submit two potential techniques:

  1. Undertake a comprehensive study to evaluate the merits of each vendors solution against requirements, conduct benchmarks and produce recommendations (The bake off)
  2. Meet in the main boardroom of the company, ensure attendance of auditors and all interested parties and toss a coin to decide which vendor to choose (The coin toss)

Before debating the merits and demerits of each technique, it is instructive to outline a methodology for the bake off option. The high level steps required to conduct a study are as follows:

  1. Outline business imperatives and goals (e.g. global engineering)
  2. Identify the PLM processes that have to be put in place or facilitated to meet these goals (e.g. extended design reviews)
  3. Create use cases to illustrate the processes (e.g. ability to load complete product into webex session and have geographically dispersed teams critique)
  4. Evaluate each technology against the use case and score its capability to support the use case (e.g. how long does it take to load a product into a review session)
  5. Total up all the scores and make a recommendation.

Clearly the bake off would be the conventional business approach. It offers the advantages of rigor, objectivity and a comprehensive approach. By following the evaluation methodology, an organization is guaranteed of having a technology that supports its needs.

So why even consider the coin toss? Any business person worth his salt would recoil at the thought of employing such a sloppy and unscientific method. But before dismissing this out of hand, consider a few items. Firstly, technology changes at an alarming pace and what is good today in one vendors solution will be outpaced by next year’s release. Secondly, the tough part of PLM implementations is managing organizational change and this has nothing to do with technology. Thirdly, agonizing over decisions is probably worse than making a snap decision – fortune favors the bold.

So consider the coin toss or a at least a compressed bake off; it can certainly save time and maybe allow an organization to leap ahead of its competition.

Need help making your plan? Our PLM Analytics Benchmark process will give you the tools you need for your bake-off. Click here to request a session.

So you’re an executive at a manufacturing company. You make things that are useful to your customers and you return profits to ever-demanding shareholders. You have probably heard of PLM before; perhaps your staff have mentioned the acronym. But how badly do you need it?

Here are 10 indicators that you definitely need PLM:

  1. Your engineering organization is often late meeting customer deadlines. This results from poorly executed projects, inefficient processes and lack of clear deliverables. All of these problems can be addressed by a PLM system supporting the engineering organization.
  2. Warranty costs are creeping up. One of the largest contributors to poor product quality is sloppy design and incomplete engineering definition. Installing appropriate PLM technology to support design activities results in a better specification been communicated to manufacturing.
  3. Factory scrap rates are above industry standards. For example, scrap and rework is often traced back to a wrong drawing, an incorrect dimension or a poorly specified component. Complete and accurate product design is supported by a robust PLM system.
  4. R&D costs as a percentage of revenue are excessive. Engineering and design activity is bloated with too much headcount and overhead. Yet they are late with deliverables. PLM means efficiency in R&D.
  5. The organization struggles with coordination. It appears as if manufacturing and engineering are always at odds with both departments blaming one another for mistakes. PLM can offer objective data to resolve these issues.
  6. There is no accountability in the organization. It is difficult to diagnose where mistakes were made and who is responsible. People are always blaming other departments. A PLM system can provide objective data that allows the root cause to be addressed.
  7. Expedited freight costs are bleeding away your profits. Excessive expedited freight costs are common in companies that are late with deliveries and have to ship under duress to avoid customer penalties. Better upstream engineering supported by PLM can improve this problem.
  8. Your competitors always beat you to market with new products. Is innovation management and new product introduction a problem for your organization? A better PLM system can make dramatic differences in this area.
  9. Customers complain that they do not get the information they need. You owe your customers information at various stages during the engagement cycle and they never get it in a timely manner. A suitably configured PLM system can improve this dramatically.
  10. Your suppliers provide the wrong information. This can be a common problem diagnosed by your engineering staff. But do your suppliers have the right request to begin with? PLM technology can bridge this gap

Do you have three or more of these issues keeping you up at night? Time to take a serious look at a PLM system.

Any organization managing product introduction must have an underlying project plan determining how this is going to happen. Any design process goes through various stages from initial concept to final product. A generic process is illustrated below:

Project-Deliverables-Diagram

Now, this may be simple at a concept level, but can become incredibly complex at an execution level. Consider if you had a 500-person team working on a project and all of their activities needed to be coordinated. Even more crucial to the overall success is the management of deliverables – has every participant delivered his or her contribution to the project on time and to the required quality?

This is where an integrated PLM and project management system can be a powerful tool. In such a system, engineering and design deliverables are attached to tasks in a project plan, and the associated task can only be considered complete once this has occurred. If project management is executed using a standalone system, there is no link between task and deliverable; no way of knowing for certain if what is reflected in the project plan corresponds with reality.

So as a project manager, which would you prefer?

  1. A project plan that is disconnected from the required deliverables and may or may not reflect reality.
  2. An integrated system where the project plan is tied to engineering and design deliverables.

There are several consequences of such an integrated system:

  1. Project managers can immediately see if deliverables have been fulfilled. No requirement to verbally or formally query a project participant
  2. Milestone reviews can be conducted efficiently; either the milestone deliverable is in the system or it is not.
  3. Project managers are presented with real time status reports and dashboards. As a deliverable is attached to a task, the report is updated.
  4. There is no hiding the dates for completing a task. The timestamp of when a deliverable is completed is visible for all to see.

All of this allows for what the PLM world calls “automatic” or “invisible” project governance. Projects are self-governing, with all participants being aware of status in real time.

Wouldn’t you want this kind of system?

i GET IT has just released a new Basics of FEA (Finite Element Analysis) course for subscribers.  The course has 2 hours of video-based instructional lessons to teach engineers an understanding of FEA and is a valuable part of our skills offering.  All i GET IT
Professional Subscribers will have access to this course.

If you would like to find out more about this course, follow this link: https://www.myigetit.com/Library/Topics/1036?name=Finite_Element_Analysis

 

© Tata Technologies 2009-2015. All rights reserved.