Tipps for creating content in Q.wiki - Process description vs. Work instruction

Content

• When do I use the Q.wiki template ‘process description’ and when do I use ‘work instructions’?
• How do I write a recipe in Q.wiki?
  • 1. Description column
  • 2. Column on work equipment and documentation
  • 3. Column for those responsible and contributors

6 Basic tips

1. Define your goal clearly:
2. First think about who you want to reach with the description. Is it experts or people who are new to the topic? Is the process complicated or rather simple? Depending on this, adjust the level of detail in the description.
3. Choose the appropriate level of detail:
4. Only go into as much detail as necessary. A simple process requires less detail, while a more error-prone process needs more information. The description should enrich everyday work and not just meet external requirements.
5. Create a process-oriented knowledge portal:
6. If you want to use Q.wiki as a knowledge portal, it is important not only to say what to do, but above all how to do it. Explain the steps clearly, as in a recipe, and link the steps to all the important information and ‘ingredients’ needed to carry out the process (documents, links, etc.).
7. Design it to be decentralized:
8. Give all employees in the company the freedom to add information and new insights. This will keep the documentation fresh and up to date with current circumstances and needs.
9. Flexible adaptation:
10. Keep the description flexible so that it can be adapted to new requirements. A rigid description can quickly become unusable. It is easier to add bullet points than long-winded and grammatically complex continuous text.
11. Why questions tend to be neglected:
12. The question ‘Why is it being done?’ is often not that important. It usually only plays a role when training new employees. Much more important: How is it done? Formulate actively. Write ‘train employees’ and not ‘carry out employee training’. This clearly conveys the objective of a process step and thus prevents misunderstandings.

The most important information in brief:

A good process description documents the standard cases. It is clear, relevant and adapts to current events in the company.

	Key points, not continuous text!
	What am I doing? – Active formulation in 3-5 words.
	How am I doing it? – As much detail as necessary, as little detail as possible.
	Link documents and systems.
	There can only ever be one role responsible.
	Design it process-oriented.

When do I use the Q.wiki template ‘process description’ and when do I use ‘work instructions’?

Process description in Q.wiki				Work instruction in Q.wiki
Comprehensive process with a medium level of detail in the individual sub-process steps (detailed information).				Narrowly defined process with high level of detail in the individual steps (step-by-step, click-by-click instructions).
Changing responsibilities often occur, but not necessarily.				To be carried out by one person and no changing responsibilities.
Not necessarily consecutive activity over a long period of time.				Consecutive activity over a limited period of time.

How do I write a recipe in Q.wiki?

In table form with the template ‘process description’

1. Description column

Linking of the upstream and downstream processes as the first and last table points Detailed description of the sub-process steps modelled in bullet point form enriched with the experience of employees Comment on deviations from the actual process and spontaneous suggestions for improvement, or enter them directly as a change request.

2. Column on work equipment and documentation

Use symbols Input: < (the arrow goes ‘into the process step’) Output: > (the arrow goes ‘out of the process step’) Upload the necessary documents to Q.wiki E-mail templates Templates (e.g. forms in Word, Excel, PowerPoint, etc.) Checklists NOTE: What must not be put in Q.wiki? ‘Living’ documents (customer documents, completed templates, etc.). These belong in a folder in your file storage system (e.g. the SharePoint folder in which the document can be found is to be linked).

3. Column for those responsible and contributors

Clearly defined responsibility in the form of a role Do not enter names, but role descriptions (e.g. Head of Purchasing) Develop a role concept –> central maintenance of role owners possible Enter other roles involved under ‘Contributor’ Advantage: Interfaces become visible very quickly Optimizations can be identified Risks can be minimized