Deficiencies in Problem Report workflow

[avillanueva]

I am working with my team to make better use and integration with Problem Reports. They have a good idea of their function and use but we failed to put in the process checks to fully integrate them. I came up with a working list of deficiencies and I would like your input. Do you agree or have I missed anything? I have an older version of the PR workflow so it does not have the sync robot at the end of the process. I am leery of adding more sync robots instances to the system.

Deficiencies with Current Workflow

Deficiency	Description and Commentary
There is no method to manually resolve Problem Reports after disposition.	There are multiple cases here to address: Accepted Problem Report is not properly associated to a Change Request and that change request is resolved. The Problem Report should be linked and moved to the Resolved State but the resolution date would not be set. This is typically done via workflow. The resolution state is not an editable field. Customization is needed here. After acceptance, the program decides to not handle issue documented in the Problem Report. If this was being dispositioned later, it might not have have been accepted.  Problem Report is against a subcontract design which may not have a CR/CN to resolve it. Must be resolved manually.
It is difficult to determine if a Resolved Problem Report was not confirmed and closed or resolved via CR/CN process.	This is not true. This captured in the "Confirmation Category" attribute which can be added to searches and reports. The values seems to be associated to a resource bundle so if routing choices change, the resource bundle may need to be updated to match.
There are no tasks after confirmation to capture immediate actions that must be taken.	After acceptance, the workflow sets states, emails a status notification and ends. If action must be taken immediately, there needs to be changes to the workflow to capture those decisions and actions as well as tasks to direct people to take action.
Nothing in the system alerts users to the existence of Problem Reports against objects undergoing change.	When objects are added to affected objects during the CR definition or more likely the change task, nothing in those workflows alerts the author or responsible roles to the existence of a Problem Report against those object. A workflow expression could be added but it is a program/engineering decision if this CR/CN should pick up that that Problem Report for additional incorporation. The Problem Report must then be associated to the Change Request (access might be restricted based on state).  This can be automated but it would require a UI to pick from possible Problem Reports to include.  The CR/CN write might need to change as well.
No standards exist as to which objects are required to be associated to a Problem Report. What happens if mixed versions and configuration as added?	A company standard might need to be developed but it would need to be validated in the Problem Report workflow at some point. If the user chose the wrong version or object, things could be missed when CR/CNs are created.
Don't ask questions in Problem Report write ups.	Description fields offer open text fields for authors to document and describe the issue they are raising. In practice, it has be used to flag notes or other design aspects in the form of a question back to Engineering. With the Problem Report being accepted, this leaves a resolution somewhat ambiguous. It would be better to update the Problem Report with a declarative resolution to the question raised. Accepting should also indicated what changes should be made which can be flowed into design changes.

[avillanueva]

Just checking field. Has anyone added anything special to their PR workflows after acceptance?

[HelesicPetr]

Hi @avillanueva 

I did something in past where autocreation has been done by code. 

If the PR is accepted then ChangeRequest and change Notice is created without any user interaction

The point was to avoid a CR workflow because it was not needed. 

Nowadays it is possible to set a business rules to link PR directly to CN so today I would automate this work CN creation. ..

PetrH

[IanW]

I have added a last task after the PR has been accepted.  The task is sent to the Product Line SMEs.  This allows for the PR not getting lost in the mess of CNs.  We then add the PR to the CN once we decide to address the issue.  The PR will get set to Resolved after the CN completes by the SME completing the final task of the PR workflow.