topic Re: Why use a Problem Report? in Windchill

Why use a Problem Report?

lgrant — Tue, 24 Feb 2026 20:13:54 GMT

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).

Re: Why use a Problem Report?

avillanueva — Tue, 24 Feb 2026 21:39:24 GMT

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.

Re: Why use a Problem Report?

jbailey — Wed, 25 Feb 2026 01:05:26 GMT

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).

Re: Why use a Problem Report?

lgrant — Wed, 25 Feb 2026 15:07:04 GMT

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

Re: Why use a Problem Report?

LewisLawrence — Thu, 26 Feb 2026 10:26:32 GMT

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.