Discovery & analysis
As-Is processes
Document how the work flows today — not how you would like it to flow. Only once you see the current situation honestly can you improve it with Gfacility.
Updated Jan 23, 2026
Discovery · 3.2
Why this first
Software forces your process into a shape. If you don’t know the current shape, you’re designing blind. Two common mistakes without As-Is:
- The management version gets recorded (“this is how it should be”) instead of the shop-floor version (“this is how we really do it”). The configuration drifts from reality → adoption collapses.
- Forgotten steps surface only during UAT. E.g. “we always ask the manager for approval over email before we book” — invisible at design time.
What do you deliver?
List of 3-7 core processes
Don't document everything. Pick the processes that cost the most time or generate the most complaints.
Process map per process
Swim-lane (role per column), trigger → closure, with handovers and waiting times.
Process facts
Monthly volume, average lead time, number of variants, cost per cycle.
Owner per process
One named role or person who gives answers, decides and validates names.
Steps
- 1Select candidate processes — ask stakeholders: "what costs you the most time or energy day to day?" Build a list of 5-15 names.
- 2Prioritise down to 3-7 — choose based on volume × pain. Documenting too many processes → analysis paralysis.
- 3Workshop per process — 60-90 minutes, with the people who do the work (not just managers). Whiteboard or an online tool with sticky notes.
- 4Use 7 questions to structure — see the template below. Force concreteness.
- 5Draw the swim-lane — roles as horizontal lanes, steps as boxes, arrows for handovers.
- 6Validate with a second group — have another team that uses the same flow review the map. Differences = valuable signal.
- 7Harvest pain points as a by-product — note what frustrates people while drawing, feed them into 3.3 Pain points & opportunities.
Template — The 7 process questions
Use these in the workshop. Not as an interview, but as an anchor to come back to when discussion drifts.
1. Trigger
What sets the process in motion? An email, a phone call, a button click, a calendar item?
2. First actor
Who picks it up? Does it land with a specific person, a mailbox, a team?
3. Steps & handovers
Which steps follow? Where does it land after each step? How does that next person know it's their turn?
4. Decision points
Where is a choice made? By whom? On the basis of which information?
5. Waiting times
Where does the time go? Between which steps do we wait? How long on average?
6. Exceptions
Which variants exist? What happens for urgent cases, with external parties, on weekends?
7. Closure
When is it “done”? Who decides? Is anyone informed? Is something archived or forwarded for reporting?
Template — Process facts
Fill in per process after the workshop. The numbers don’t need to be exact — order of magnitude is enough.
| Process | Volume / month | Lead time | Variants | Owner | Key handover |
|---|---|---|---|---|---|
| E.g. Fault report | ~120 | 2.5 days | Standard / urgent / preventive | Head of Facility | Reception → field team |
| … | … | … | … | … | … |
Best practices
→ Walk the shop floor
An hour sitting next to someone yields more than 5 hours of interviews. You see the silent actions no one mentions.
→ Ask for the exception
"How does it usually go?" gives you the ideal. "How did it go last time it went wrong?" gives you reality.
→ Visual beats textual
A swim-lane on a whiteboard surfaces weak spots by itself. Word documents hide them.
→ Find the Excel shadow IT
Nearly every department has an Excel file or SharePoint list that fills in for the official system. That tells you what the system can't do.