In this article, you will learn:
- The basics of formal review
- Step-by-step process of formal review
- What you should pay particular attention to
- Differentiation from content-related approval
The basics of the two-stage Q.wiki release workflow can be found here: Function of the document approval workflow
Q.wiki guarantees the four-eyes principle through the two-stage release workflow. The formal release described here takes place after the content release, by a suitable person (e.g. QM team or Q.wiki implementation team). This person + deputy must be a member of the QM group. The different right groups in Q.wiki can be found here: Detailed overview of rights concept Q.wiki
Here, you can find out how you assign users to different groups: Add or remove users from Q.wiki groups
| Description | Picture |
---|
1 | Previous step: |
|
2 | If necessary, show comparison with released status - Only available if a released status already exists
- i.e. not for the first release of the draft design
|  |
3 | Check whether the correct template has been selected: - Is the content really a process?
- Yes: There are interfaces (column “Responsible”)
- Yes: The process refers to a longer period of time
- Yes: Scope and complexity justify the “process template”
- Is it a work instruction?
- Yes: Only one person carries it out (“Responsible” column is unnecessary)
- Yes: Short period of time
|  |
4 | Manually change template if necessary - Add or remove columns
- Change metadata so that page header is displayed correctly
|  |
5 | Check roles: - Is the role designation correct?
- Have new roles been used that have not yet been created in the Q.wiki roles?
- Create a new role and insert it into the page using the widget
|  |
6 | Formatting and spelling check - Correct spelling/typing errors directly
- Headings in the desired format “Heading 1 or 2”?
- Text in “Normal”
|  |
7 | Check links and add - upstream and downstream processes
- Links within the process description / work instruction
- Do the links make sense?
- Are there other pages that you know of that could be linked?
|
|
8 | Check flowchart - Comparison Flowchart for detailed description
- If necessary, delete flowchart area if it has not been created/is not
- needed
|  |
9 | Editorial review |
|
10 | Assign standards - in edit mode in the metadata
- Have all the requirements of the standard been taken into account?
- Have the guidelines been followed?
|  |
11 | Decide whether formal approval can be granted:
Option 1: Ask for further revision - only if
- an employee wants to make further changes before approval
- is granted
- clarification is needed
- more extensive changes/revision is necessary
- Attention: Smaller changes such as
- e.g. corrections of spelling mistakes can and should
- be made directly by the formal reviewer.
- This will set the page status back to “Change request”
- and everyone can edit it again.
- In addition, the employee who requested the release will be informed.
- Fill in the comment field
- What exactly needs to be revised?
- Select “Ask for further revision”
- Click on “Change status”
Option 2: Reject change request: - Use only in exceptional cases!
- Always: Enter a reason or discuss it personally with the author.
- Otherwise, this has a highly demotivating effect!
- Select “Reject change request/draft”
- Click on “Change status”
Option 3: Issue formal approval - If necessary, fill in the comments field
- The employee who initiated the approval receives this comment with the notification.
|  |