#process documentation

Photos here are from the first successful print: full 8-page run, continuous feed spilling off the sofa; close-ups of the corrupted bands, the overwritten lines, and the handwritten note sitting on top of it all.

Process video for Manny Calavera from Grim Fandango. I had a lot of fun painting him, but nowhere near as much fun choosing the music.

Swimlane diagrams Swimlane diagrams are supposed to create clarity. In most organizations, they do the opposite after 30-60 days. Because the diagram becomes a picture that has to be manually “kept up to date” by dragging boxes and reconnecting lines. That work feels harmless until the process changes weekly. Then the map drifts. Then nobody trusts it. Then leaders stop using it. Then the map becomes shelfware. A swimlane diagram works best when it is treated as a view of a dataset. The dataset is the model. The diagram is the renderer. That sounds abstract until the 1st time a process owner asks: “Can this be shown by customer type?” “Can this be shown by system touchpoint?” “Can this be shown by approval tier?” “Can this be shown by value-added vs non-value-added?” “Can this be shown by risk and control type?” If the process is a drawing, every new view is a redraw. If the process is data, every new view is a reclassification. A practical way to do this inside the Microsoft toolchain: 1. Capture the process as a table (Excel / TSV). 2. Keep 1 stable step ID per row. 3. Store connections using Next Step IDs (branches can be comma-separated). 4. Use Function as the swimlane field. 5. Import into Visio Data Visualizer to generate the diagram. 6. When the process changes, update the table and refresh. This is where most teams get stuck: • lane names drift (Ops vs Operations vs Operations Team) • step IDs get reused • a single blank line breaks the import • branches are represented as extra rows instead of a single “Next Step ID” cell • handoffs are not visible because lanes are too generic Once those basics are standardized, swimlanes stop being “diagram work” and become “process control.” That is why “swimlane diagrams” is not just a diagram topic. It is an operations topic. It is a governance topic. It is a decision-speed topic. The payoff is immediate: • fewer redraws • faster updates • cleaner reviews • easier analysis in Excel • easier handoff conversations • templates that prevent accidental format drift A useful test: If a swimlane diagram is already being maintained by hand, the process model is already drifting. The fastest upgrade is converting it into a dataset-first swimlane diagram that can be regenerated. When the diagram becomes regeneratable, the team finally has a system of record that can produce multiple consistent views without rework. If this problem shows up every week, the workflow probably needs a data backbone. What is the biggest frustration with swimlane diagrams right now: keeping them updated, making them readable, or getting people to agree on ownership? A clean template + a generator that produces Data Visualizer-ready TSV can remove most of the friction. process improvement, process mapping, operations, business analysis, workflow, visio, swimlane, automation, lean, standard work

Swimlane diagrams Swimlane diagrams are supposed to create clarity. In most organizations, they do the opposite after 30-60 days. Because the diagram becomes a picture that has to be manually “kept up to date” by dragging boxes and reconnecting lines. That work feels harmless until the process changes weekly. Then the map drifts. Then nobody trusts it. Then leaders stop using it. Then the map becomes shelfware. A swimlane diagram works best when it is treated as a view of a dataset. The dataset is the model. The diagram is the renderer. That sounds abstract until the 1st time a process owner asks: “Can this be shown by customer type?” “Can this be shown by system touchpoint?” “Can this be shown by approval tier?” “Can this be shown by value-added vs non-value-added?” “Can this be shown by risk and control type?” If the process is a drawing, every new view is a redraw. If the process is data, every new view is a reclassification. A practical way to do this inside the Microsoft toolchain: 1. Capture the process as a table (Excel / TSV). 2. Keep 1 stable step ID per row. 3. Store connections using Next Step IDs (branches can be comma-separated). 4. Use Function as the swimlane field. 5. Import into Visio Data Visualizer to generate the diagram. 6. When the process changes, update the table and refresh. This is where most teams get stuck: • lane names drift (Ops vs Operations vs Operations Team) • step IDs get reused • a single blank line breaks the import • branches are represented as extra rows instead of a single “Next Step ID” cell • handoffs are not visible because lanes are too generic Once those basics are standardized, swimlanes stop being “diagram work” and become “process control.” That is why “swimlane diagrams” is not just a diagram topic. It is an operations topic. It is a governance topic. It is a decision-speed topic. The payoff is immediate: • fewer redraws • faster updates • cleaner reviews • easier analysis in Excel • easier handoff conversations • templates that prevent accidental format drift A useful test: If a swimlane diagram is already being maintained by hand, the process model is already drifting. The fastest upgrade is converting it into a dataset-first swimlane diagram that can be regenerated. When the diagram becomes regeneratable, the team finally has a system of record that can produce multiple consistent views without rework. If this problem shows up every week, the workflow probably needs a data backbone. What is the biggest frustration with swimlane diagrams right now: keeping them updated, making them readable, or getting people to agree on ownership? A clean template + a generator that produces Data Visualizer-ready TSV can remove most of the friction. process improvement, process mapping, operations, business analysis, workflow, visio, swimlane, automation, lean, standard work

Swimlane diagram vs cross functional flowchart: what’s the difference? “Swimlane diagram” vs “cross functional flowchart” sounds like a difference. Most of the time it is not. In day-to-day process work, these phrases are usually describing the same deliverable: A flowchart where steps are arranged in lanes to show who does what and where handoffs occur. So why do both terms exist? Because different communities use different labels: • “Swimlane diagram” is common in general business and project work • “Cross functional flowchart” is common in operations, quality, and Lean documentation • “Deployment flowchart” shows up in Six Sigma language Here is the practical difference that matters: A basic flowchart answers: “What happens next?” A swimlane or cross functional flowchart answers: “Who owns each step, and where does work cross boundaries?” That “crossing” is the point. Handoffs create delay, rework, and approvals. Which should be used? Use the term your audience searches and recognizes. If the team is asking for accountability, use “swimlane diagram”. If the team is asking for a standard process artifact, use “cross functional flowchart”. On a website, the winning approach is to treat them as related terms and cover both intents in the same topic cluster. A simple decision guide: Use a swimlane diagram / cross functional flowchart when: • there are 2+ roles or departments involved • delays are suspected at handoffs • approvals and queues need to be made visible • the goal is governance, auditability, or automation planning Use a basic flowchart when: • ownership is not the question • it is a single-person or single-system procedure • the goal is training on the sequence only Now the leverage: If swimlanes are drawn, every change becomes redraw work. If swimlanes are data, the diagram becomes maintainable. In Visio Data Visualizer, lanes come from the Function column in the dataset. Change Function in Excel, re-import, and the swimlane view updates. That means 1 process model can generate: • department view • role view • system touchpoint view • value stream lens view (VA/BVA/NVA) Same steps. Same connections. Different lens. Common mistakes when teams request these diagrams: • mixing departments and systems in the same lane scheme • creating 25+ lanes (nobody reads it) • leaving lane names inconsistent (Ops vs Operations) Quick test: Convert 20 steps into a dataset, import once, then reassign 1 step to a different Function and refresh. If the view changes cleanly, the swimlane diagram is now a living asset instead of shelfware. #Visio #ProcessMapping #SwimlaneDiagram #CrossFunctionalFlowchart #BusinessAnalysis #Operations Best starting point: use a Data Visualizer-ready template and a small example dataset, then scale only after the round-trip import is reliable. process improvement, process mapping, operations, business analysis, workflow, visio, swimlane, automation, lean, standard work

Visio process mapping that stays current Visio process mapping has a predictable failure pattern: Teams invest time to create a current-state swimlane diagram. Then reality changes. Updating the diagram becomes diagram surgery. A month later, nobody trusts the map. The root issue is not effort. It’s the data model. A Visio drawing is a picture. A process map that stays current needs to behave like a model – a small dataset that can be edited, reviewed, versioned, and re-rendered. A practical “process mapping as data” workflow: 1. Store the process as a table At minimum: • Step ID (stable – treat it like a primary key) • Step description (written consistently) • Next Step ID (connections) • Shape type (process, decision, start, end) • Function (owner / swimlane) • Phase (stage) 2. Generate the diagram from the dataset Visio Data Visualizer can render a cross-functional flowchart (swimlane diagram) from the table. 3. Update the dataset, not the drawing Ownership changes become a Function edit. Stage changes become a Phase edit. New steps become new rows. New connections become Next Step ID edits. That’s the maintenance unlock. Then the bigger unlock: one model, many views. Because lanes and phases are just fields, the same process can be reclassified to create different lenses: • RACI (Responsible, Accountable, Consulted, Informed) • value stream mapping (value-added vs non-value-added plus active vs waiting vs rework) • systems touchpoints (where work happens in ERP, CRM, email, spreadsheets) • automation readiness (high vs medium vs low) • risk and control mapping (preventive, detective, corrective) The process stays the same. The viewpoint changes. What makes this work in a real organization: • keep a controlled lane list (no Ops vs Operations vs Ops Team sprawl) • never reuse Step IDs across versions • store branching as comma-separated next steps with no spaces (example: 040,050) • version the dataset file and regenerate the diagram from data every time Fast validation: take one real process map, convert the first 20 steps, regenerate the diagram, then make one change in Excel and re-import. If that round-trip works, everything else gets easier. Lite is a good way to prove the workflow on a real file. Standard removes the limit for full-size diagrams and a maintainable process library. What to map first (to avoid a never-ending project): • start-to-finish scope with a clear trigger and clear done state • capture handoffs and approvals first – those drive waiting • leave edge cases for later; add them as branches once the core imports cleanly A simple standard for success: If the dataset can regenerate the diagram, the process map can finally stay current. #Visio #ProcessMapping #DataVisualizer #SwimlaneDiagrams #BusinessAnalysis #ContinuousImprovement #Operations process improvement, process mapping, operations, business analysis, workflow, visio, swimlane, automation, lean, standard work

Visio swimlane diagram Most Visio swimlane diagrams die in silence. They start as clarity. They end as shelfware. The failure mode is not artistic. It is operational. A process changes. Someone opens the drawing. Boxes get moved. Connectors get “fixed.” Formatting drifts. Lane labels quietly split (Ops vs Operations vs Operations Team). A month later, the diagram is still “nice” – and it is wrong. That is when people stop trusting it. A Visio swimlane diagram stays useful when it stops being the source of truth. Model = a simple dataset. View = the diagram. Visio Data Visualizer already works this way. It renders a cross functional flowchart (swimlane diagram) from a strict table, usually exported as tab-separated values (TSV). The table only needs a few fields to become powerful: • Process Step ID (stable, unique) • Process Step Description (short, action-oriented) • Next Step ID (connections and branches) • Shape Type (Start, Process, Decision, End) • Function (the swimlane owner) • Phase (optional stages) Once the process is data: • updates become row edits, not redraws • handoffs can be counted and reduced • approvals can be isolated • rework loops can be made explicit • the same process can be rendered in consistent views without starting over A practical build sequence inside Visio: 1. Start with 10-20 real steps (a slice that changes often). 2. Standardize Function labels so lanes do not drift. 3. Store branching as comma-separated Next Step IDs in 1 cell (no spaces). 4. Import into Data Visualizer and confirm it renders cleanly. 5. Expand the dataset only after the format is proven. 6. When the process changes, edit the dataset and refresh the diagram. Most “Visio swimlane diagram” frustrations come from boring mistakes: • blank lines in TSV • header mismatches • Next Step IDs pointing to missing steps • inconsistent lane naming • branches modeled as extra rows Strict templates are boring on purpose. They prevent the silent drift that turns a useful swimlane into decoration. A clean way to start is to generate a small dataset, prove the import, then scale. That keeps the effort focused on process decisions, not shape nudging. The point is not to draw faster. The point is to stop redrawing. process improvement, process mapping, operations, business analysis, workflow, visio, swimlane, automation, lean, standard work