Trupeer Blog
요약
Most SAP S/4HANA programmes are in a hurry to design the future. Workshops start with SAP's best practices and a fresh process model, and the old system is treated as something to leave behind. Then, months later, the gaps appear: the month-end adjustment nobody mentioned, the intercompany workaround that lives in a spreadsheet, the approval rule that only one person in finance understands. Each one becomes a late change request, a failed test or a frustrated user after go-live.
The fix is unglamorous but powerful: in any SAP S/4HANA transformation, document as-is processes first. This guide explains why the as-is matters even when you're moving to SAP standard, what to capture, how much detail you need, how to document as-is processes quickly from screen recordings, and how that documentation pays off in fit-gap, testing, training and knowledge transfer.
What does documenting as-is processes mean in an SAP S/4HANA transformation?
As-is process documentation records how work is actually done today in your current SAP ECC or other systems: the steps, roles, transactions, reports, controls, exceptions and workarounds. In an SAP S/4HANA transformation, it's the baseline you compare the future design against, so you know what must be kept, what can be simplified and what will change for people. For the difference between the two views, see as-is vs to-be process.
Why should you document as-is processes before an SAP S/4HANA transformation?
Hidden requirements surface early. Exceptions, period-end tasks and workarounds show up before design is fixed, not in testing.
Fit-gap analysis is grounded in reality. You compare SAP standard with what people really do, not what they remember in a workshop.
Change impact is clear. You can see exactly what will change for each role, which drives training and communication.
Testing has real scenarios. As-is processes give testers the edge cases that matter.
Knowledge is protected. Experienced users may leave during a long programme; their knowledge stays.
Training starts from a known point. Users learn the new system faster when training explains what's different from today.
Does as-is documentation matter for greenfield as well as brownfield?
Yes, for different reasons:
Greenfield: you're redesigning processes, often closer to SAP standard. The as-is tells you what the new design must still handle, such as legal requirements, controls and exceptions, and shows how big the change is for each team.
Brownfield: processes largely stay the same, so the as-is becomes the starting point for updated SOPs and delta training, and helps find what simplification items affect.
Selective or hybrid: you need the as-is to decide which areas to redesign and which to convert.
See S/4HANA greenfield vs brownfield for what each approach means for training and documentation.
Which processes should you document first in an SAP S/4HANA transformation?
Start with the end-to-end processes in scope, then go deeper where risk, volume or complexity is highest:
End-to-end process | Examples of what to capture |
|---|---|
Procure to pay | Requisitions, purchase orders, goods receipts, invoice matching, exceptions, payment runs |
Order to cash | Order entry, pricing, credit checks, delivery, billing, collections, disputes |
Record to report | Journals, accruals, intercompany, reconciliations, period-end close, reporting |
Hire to retire | Hiring, onboarding, payroll inputs, changes, leavers |
Plan to produce | Planning runs, production orders, confirmations, quality checks |
Asset and maintenance | Asset creation, depreciation, maintenance orders |
For a worked example of one end-to-end process, see the procure to pay process flow.
How much detail does as-is documentation need?
Many SAP programmes use a process hierarchy to decide the level of detail:
Level | What it describes | Example |
|---|---|---|
Level 1 | Value chain or end-to-end process | Procure to pay |
Level 2 | Process group | Invoice processing |
Level 3 | Process | Process a PO invoice |
Level 4 | Task and screen-level steps | Post an invoice and resolve a quantity variance |
You don't need Level 4 for everything. Go to task level for high-volume, high-risk and exception-heavy processes, where hidden detail causes most problems later. Elsewhere, Level 3 with key exceptions noted is usually enough.
What should as-is documentation capture?
Steps and roles: who does what, in what order.
Systems and transactions: the SAP transactions, reports and other tools used, including spreadsheets.
Custom objects in use: custom transactions, reports and enhancements people rely on.
Exceptions and workarounds: what happens when something doesn't fit the standard path.
Controls and approvals: checks, limits and segregation of duties.
Volumes and timing: how often, how many and when, including period-end peaks.
Pain points: what's slow, error-prone or frustrating today.
Who knows it: the SMEs who hold the knowledge.
How do you document as-is processes for an SAP S/4HANA transformation, step by step?
Step 1: Define scope and the process hierarchy
List the end-to-end processes in scope and agree the level of detail for each.
Step 2: Identify SMEs and knowledge risks
For each process, name the SMEs and flag where knowledge sits with only one or two people. A tribal knowledge audit helps find those risks.
Step 3: Interview with structure
Use a consistent set of questions in every session, covering steps, exceptions, controls, volumes and pain points. The process discovery checklist gives you a template.
Step 4: Record SMEs doing the real work
Ask SMEs to perform each task in the current system while recording their screen with Trupeer's AI screen recorder, narrating what they do and why. Ask them to show the exceptions and the spreadsheets they use outside SAP. A recording captures detail that interview notes miss.
Step 5: Turn recordings into as-is documents
Trupeer turns each recording into a step-by-step process document with screenshots and a searchable video. Analysts review and annotate the drafts instead of writing everything from scratch.
Step 6: Map the flows
Draw the end-to-end flow for each process, with roles, handoffs, decisions and exceptions, and link each step to its recording.
Step 7: Validate with process owners
Play back the recordings and documents with process owners, correct anything missing and sign off the baseline.
Step 8: Store it where the programme can use it
Keep the as-is library in one searchable place so design, testing, training and support teams can all use it.
How does as-is documentation pay off later in the programme?
Phase | How the as-is helps |
|---|---|
Requirements and fit-gap | Every requirement can point back to how the process runs today; see ERP requirements gathering |
Design | Designers see exceptions and controls the new process must handle |
Change impact | Each role's changes are clear, so communication and training are targeted |
Testing | Real scenarios and edge cases become test cases |
Training | Training explains what's different from today, which speeds up learning |
Knowledge transfer | Knowledge is captured even if SMEs leave during the programme |
Post-go-live | Support teams understand what users were used to and why they ask what they ask |
Turning as-is recordings into S/4HANA training
The as-is library also shortens the path to end user training. Once the new system is configured, key users record the same tasks in S/4HANA, and Trupeer turns those recordings into role-based guides and videos. Comparing the old and new recordings makes "what's changed" training straightforward. See the SAP S/4HANA training video guide for end users.
Trupeer's SAP enablement platform brings the as-is library, the new-system training and the knowledge base together in one place.
Common mistakes when documenting as-is processes
Skipping the as-is entirely because the future will be "SAP standard".
Relying on workshop memory instead of watching the real work.
Documenting only the happy path and missing exceptions and period-end tasks.
Going too deep everywhere, so the as-is never finishes.
Ignoring spreadsheets and side tools that hold critical steps.
Letting the as-is sit unused in a project folder instead of feeding design, testing and training.
SAP S/4HANA transformation as-is checklist
End-to-end processes in scope are listed, with agreed detail levels.
SMEs are named and single-person knowledge risks are flagged.
High-risk and high-volume tasks are recorded in the current system.
Exceptions, workarounds and spreadsheets are captured.
Controls, volumes and pain points are documented.
Flows are mapped and linked to recordings.
Process owners have validated and signed off the baseline.
The library is searchable and shared with design, test and training teams.
Start your SAP S/4HANA transformation with Trupeer
Trupeer helps you document as-is processes in your SAP S/4HANA transformation by turning SME recordings into searchable process documents, then turns the same approach into role-based training once the new system is ready. See Trupeer's SAP adoption platform or start free with Trupeer.
Frequently asked questions
Why document as-is processes before an SAP S/4HANA transformation?
Because the as-is surfaces hidden requirements, exceptions and controls early, grounds fit-gap analysis in reality, shows the change impact for each role and protects knowledge if SMEs leave.
Do you need as-is documentation for a greenfield S/4HANA implementation?
Yes. Even when processes are redesigned, the as-is shows what the new design must still handle and how much change each team faces.
How detailed should as-is documentation be?
Use a process hierarchy. Go to task and screen level for high-volume, high-risk or exception-heavy processes, and stay at process level elsewhere.
What should as-is process documentation include?
Steps and roles, systems and transactions, custom objects in use, exceptions and workarounds, controls and approvals, volumes and timing, pain points and the SMEs who hold the knowledge.
How do you document as-is processes quickly?
Record SMEs doing each task in the current system and use a tool like Trupeer to turn the recordings into step-by-step process documents, then validate them with process owners.
Who should be involved in as-is documentation?
Process owners, SMEs who do the work, business analysts, and representatives from IT, finance controls and the training team.
How long does as-is documentation take?
It depends on scope, but recording processes rather than writing everything from interviews shortens the effort considerably and reduces follow-up sessions.
How does as-is documentation help training?
It shows exactly what changes for each role, so training can focus on differences, and the same recording approach produces training for the new system.
