Why use a Problem Report?

[lgrant]

Just wanted to see if anyone has some good reasons to not use a Problem Report (PR)?

The why is about identifying a problem (potential or existing) or enhancement.

PR's can be directly acted on (start a CR) or staged for the next change to the item.

It is a way to have a technical review before moving to the CR.

They can be a proactive feed  and not a reactive feed ( NCMR, Deviation, Complaint, Line down, audit).

[avillanueva]

Our interpretation of Problem Reports is that they are issues, hence the object name change issue. They are precurors to formal change requests or change activity. It is meant to capture anything the might occur about a product that may or may not results in future changes. We use them for changes we would like to see but to be done later. Then they can be collected and group into a single CR/CN to be acted upon. They can document assembly issues, supplier issues. shimmies, shakes, electrical anomolies, something that may be fleeting but see enough of it, and it moves from unreproducable to yes, let's take action in this. Say you have a field product where a part breaks. Oh well. It happens. But later you find 30% break. Time to collect those PRs and investigate as to why and make a change. Hope that helps.

[jbailey]

I will be honest, I came from an organization where they didn't even want to use the formal change process because they were so ingrained in paper based processes. I made it a point to every group I demo'd Windchill to, that even if they did manual change (manual revise, then re-promote with a promotion) they should absolutely use Problem Reports to document issues. Where I came from Teams changed annually, and projects lasted years (or decades). Just documenting issues so new team members or auditors could at least easily find the issues documented along the design path is super useful.  

Also, as @avillanueva mentions, they can be used to support changes down the road based on trending issues collected. There are probably a couple of ways you can look at it based on your current process to see where it fits in.

Additionally, The following Change Objects are in your tool box out of the box in Base Windchill

• Problem Report
• Variance
• Review (Design or Peer)
• Change Request
• Change Notice

Based on your current process, ask yourself:

• Is my product subject to audit? (Med device, Government product, Space product, Aerospace, Safety regulations)
  • Justifying change / tracking risk is generally required for many industries for several reasons. Accurately tracking issues against your design helps you to show you are evaluating changes for risk.
  • Not part of the above? I bet your company cares about evaluating proposed changes for risk (to schedule, cost, time to market, MTTR etc) and COST in general. Having a way to track recurring or related issues helps your bottom line.
• What happens when someone reports a problem with your product (product failure, manufacturing issue, design defect, etc)
  • How is it reported?
  • How is the report evaluated?
  • How is the report logged?
  • What is the decision tree? (Should a Change be made eventually? immediately? No change at all?
  • Is additional review required?

If in the review above you find that you:

• take reports of issues related to a product
• Evaluate the report for correctness/completeness and documentation
• log that issue against the product
• decide what to do with it (change/no change to design)

Then you probably could take use of Problem reports to replace (probably a paper based or word of mouth process). 

All of this ignores whether or not your Quality process is in Windchill, because then you add the possibilities of CAPA, Nonconformance, Audit etc.

In my experience, Engineers / Designers / Software Engineers are doers. They're great at solving problems / fixing things ... but not always good at documenting the what/why.

A Problem Report is a great way to make sure users are documenting issues that eventually lead to change (good Config Mgmt).

[lgrant]

Nice input folks. I feel like I am building a good case for the use. See attached.

[LewisLawrence]

My opinion is that Problem Reports are a good way for consumers (majority of users in most organisations) of PLM data to give feedback on anything to do with a product and its digital definition to the responsible party. The Problem Report workflow can seamlessly route to the individuals responsible for the data and make direct communication "from the coal face" to the Engineering office much more efficient. The problem is tracked against the object, has history and lives on in PLM, which unlike email or teams messages provides a lot of value over time. Another important consideration is licensing, there is a "Contribute" license (one above View/Print) for people who need to complete tasks in PLM, this license also covers Problem reports. While any of the other Change objects require a full Author license for creation/editing.