Work instructions

A work instruction is a short, task-focused document a user keeps next to the screen: how to do one job in the new system, step by step, with the decisions and checks that matter. Good work instructions reduce hypercare tickets more than almost anything else, because users look things up instead of calling for help.

From test scenario to work instruction

Key users already have the best raw material: test scenarios that passed. A test scenario says what to do and what result to expect. A work instruction keeps that, removes the test-only parts, and adds what a new user needs: why, when and what to do if something goes wrong.

A one-page structure

1. Title and purpose: "Release a sales order from credit block", one sentence on why.
2. Role and access: who uses it and which launchpad app or transaction, named exactly as it appears on the user's launchpad for the credit release process your project designed.
3. Before you start: what must be true, such as the order number and the credit manager's approval.
4. Steps: numbered, one action each, naming the app, field and button; five to twelve steps.
5. Check: what the user should see when it worked, such as the order status no longer blocked and the delivery possible.
6. If it goes wrong: the two or three most common messages and what to do.
7. Version and owner: version number, date, release it was checked against, and the owner.

Which instructions to write first

Nobody has time to document everything before go-live. Rank tasks by how often users perform them and how costly a mistake is. Daily, high-risk tasks such as posting goods issue or releasing an order from credit block come first. Rare but high-risk tasks, such as cancelling a billing document that already posted to accounting, come next, because nobody remembers them from training. Frequent, low-risk tasks may need only a quick reference line. Rare, low-risk tasks can wait until after go-live.

Store the instructions in one place users already know, with a simple index by role and task. A shared library that requires three clicks and a search term the user does not know will not be used under pressure on a Monday morning.

Screens and screenshots

Screenshots of your own system help users recognize where they are. Use them sparingly: one per key screen, cropped to the area that matters, with the field to fill highlighted. Mask customer and personal data. Screenshots age fastest of anything in the document, so record the release they were taken on. Where the project uses a tool for guided help or simulations, such as SAP Enable Now if licensed, the same rules apply: base it on the tested scenario and version it.

Versioning for upgrades

SAP S/4HANA changes over time: feature packs, upgrades and transports adjust screens and steps. A work instruction without a version and an owner becomes wrong silently. Keep instructions in one controlled location, link each to the test scenario it came from, and re-check them when that scenario is changed or re-tested in a regression cycle.