Extend Non Conformities functionality
Extend Non Conformities, to support "Findings" and Actions resulting from them, including but not limited to Non Conformities.
Context
A management system continuous improvement process can look like this:
(a) Findings can be reported by anyone including Partners, from direct observation, complaints, suggestions etc. Audits are also a way to produce findings.
(b) They are categorized and handled: Non Conformities [NC], Improvement Opportunities [IO], Remarks.
(c) First, line manager performs "Analysis and Causes" (keep record of who and when) and defines immediate corrective actions.
(d) Second, the Manager defines an "Action Plan" (keep record of who and when): Corrective and Preventive actions.
(e) Later, an assigned responsible person performs "Action Evaluation" (keep record of who and when), verifying effectiveness. If ineffective, this may result in additional actions (eventually through a new Finding → Action cycle)
Mapping with current features
Best matches in the module for these functions and main gaps:
(a),(b)-> "Claims"; needs linking to following steps - NCs or IO Actions.
(c)->"Non conformities"; needs to record who and when performed analysis.
(d)->"Non conformities" + "Actions"; needs to record who and when decided plan.
(e)->"Non conformities"; needs to record who and when evaluated effectiveness; needs link to further actions or occurrences
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Medium
- Drafter:
- Daniel Reis
- Direction:
- Approved
- Definition:
- Discussion
- Series goal:
- Accepted for 6.1
- Implementation:
-
Implemented
- Milestone target:
- None
- Completed by
- Maxime Chambreuil (http://www.savoirfairelinux.com)
Whiteboard
=== Maxime, Svoir-faire Linux ===
Your requirements mean moving information from fields of the NC object to a new object, where we would benefit from the framework to know the creation date and the creation user.
A NC would be linked to:
* many claims
* one analysis (Analysis object = root cause + text description of the analysis)
* 3 effectiveness evaluations for each action (immediate, corrective and preventive)
I would not create an action plan object as it basically means creating the actions we already have as mgmtsystem_action object.
Would that work for you?
=== Daniel Reis ===
Regarding the "moving information from fields of the NC object to a new object" design option:
I feel that creating new objects add's unnecessary complexity, compared to adding a few date fields or a stage field to NCs.
A "stage" (or "state") centred solution would be easier and more flexible (it's easy to reconfigure the default to specific customer needs). The stage evolution (who, when, what) can be recorded in the NCs message history. With this, even the new date fields could be discarded, but having them makes it easier to build reports.
Not creating new objects would also have the benefit of not requiring data migration for production installations.
=== Maxime ===
The modules already provide 2 new groups : Auditor and Manager and use the groupe Employee. Would you need other?
So we would add a workflow to NC with following states:
* New or Draft : an Employee creating a NC would fill in the header, the description and the origin. Other field would not appear.
* Open : Auditor open the NC. Cause and analysis fields would appear so he can fill them up and click on "To plan" to move to the next state.
* To plan : Auditor creates immediate, corrective and preventive actions and assign them. He clicks on "In progress" to move to the next state.
* In progress : Employees works on closing their actions. When all actions of an NC are closed, the NC move to the next state "To review".
* To review : Auditor review the actions and fill in the effectiveness fields. He clicks on Close to close and archive the NC.
* Closed : Every field are read-only.
and a history tab with user and date of each state change.
Regarding claims, I would add fields to relate one claim with:
* many immediate actions
* many NC
== FINAL SPECIFICATION ==
(Daniel Reis: use case proposal)
(a) [Employee] creates new "Claim". An "origin/source" can/should be specified.
At Mgmt System Claim form:
- "Followup" tab removed
- "Category" field used to specify the claim's origin. For example: Customer complaint.
(b) [Employee Manager] reviews New Claims and decides to handle it as:
b1. Remark -> fill a "remarks" field and close.
b2. Improvement Opportunity [IO] -> associate a new Action to the claim. One Claim can give origin to many Actions.
b3. Nonconformity [NC] -> "Create NEW NC" button and jumps to the NC (similar to Issues -> Create Task). One Claim can give origin to many NCs.
At Mgmt System Claim form:
- "Stage" defines resolution type: "Remark", "Improvement Opportunity", "Nonconformity"
- "Followup" tab fields removed, except for the ones specified next.:
- Stage "Remark" enables field "resolution", reused for "Remarks"
- Stage "Nonconformity" enables button "Create NC". Create o2m relationship with NCs.
- Other Stages enable button "Create Action". Create o2m relationship with Actions.
- Button "Create NC" generates new NC and changes state to "Open".
- Button "Create Action" generates new Action and changes state to "Open".
(c) [Employee Manager] reviews the NC in state New/Draft. He is the "Responsible" person.
Completes the "Description" that was copied from Claim.
Evaluates (complaint) severity.
Performs "Analysis and Causes".
Defines and assigns an Immediate Action, if necessary.
Clicks a "Send for Review" button, changing to "Review Pending" state.
At Nonconformity form:
- States allowed change to standard list: 'draft', 'open', 'pending', 'cancel', 'close'.
- State "pending" renamed to "Review pending", and form button renamed to "Send for Review"
- "Description" moves to be the first tab.
- Add a "Severity" m2o field to "Description" tab.
- "Analysis and Causes" merge into a single tab.
- immediate_action_id moves to "Analysis and Causes" tab
- "Action" tab is invisible on state 'draft'
(d) [Mgmt System User] (an authorized manager) reviews NC in state Pending . He is the "Manager" person.
This the accountable person, with authority over an area, department, or process.
Reviews Analysis, Causes and categorization.
Defines the Action Plan: Corrective and Preventive actions.
Clicks "Start/Open" button, changing to "In Progress" state.
At Nonconformity form:
- Effectiveness evaluation fields are removed
- Corrective and Preventive action fields are replaced by a single o2m field on Actions.
(e) Actions are monitored, and evaluated following what is defined for each: evaluation responsible, evaluation date,....
Related NC state can be set to "Closed" after all related Actions are completed. (This could be automated.)
At Action form:
- New tab "Effectiveness", with Responsible, Last Evaluation Date, Stage (resulting from evaluation's assessment), 'evaluation' text description field.
Roles overview:
[Employee] is standard.
[Employee Manager] is implemented in an HR extension.
[Mgmt System User] is new - business managers with mgmt. system responsibilities.
[Mgmt System Manager] and [Auditor] are implemented in Mgmt-system, but not required in this workflow.
Please note thet the [Auditor] role is not required to be involved.
The workflow is handled directly by the organization's hierarchy.
Quality Assurance ("Mgmt System Manager" role?) or Auditors could be involved in phase (e) "Evaluate effectiveness of actions".
Work Items
Work items:
New group creation: DONE
Form views redesigned: DONE
Workflow integration: DONE
Access rights with the new group: TODO
