How Does Digital Transformation Start, and in What Order?
The most common answer to how digital transformation starts is wrong: “by choosing software”. The right answer is dull but saving — by writing down the current state. 🪜
Short answer: four stages — current state, simplification, tool selection and setup, adoption. Software arrives at stage three; projects that start there stall halfway.
Below: the four stages, the pilot logic, a typical timeline and week one’s work. 🗓️
Stage one: writing the current state
The real answer to how digital transformation starts lives here.
Stage two: simplification
The cheapest and most profitable stage of the project.
Stage three: tool selection and setup
Software can finally enter the conversation.
Stage four: adoption
Most projects die here.
What’s a typical timeline?
Writing the expectation down saves the project.
First week, first month, first quarter
Week 1: process inventory and baseline measurement. Month 1: writing and simplifying one process, building the requirement list. Month 2: product selection, setup, data migration. Month 3: pilot use and the first comparison measurement. By the end of month three you talk in numbers; timing sits in the results article, all questions on the consulting page. 🗓️
📝 Field Notes
In one project the client wanted to start in all branches on the same day. We persuaded them to begin with one; five configuration errors surfaced in week one and were fixed in that single branch. Had the same errors appeared across six branches at once, the project would probably have been stopped. A pilot isn’t lost speed; it’s insurance. 👥
📖 Quick Glossary
Process inventory: a table of processes with frequency and error counts. Baseline table: the measurement record before work begins. Pilot: a first implementation with a small team. Parallel running: old and new systems used together for a period.
⚡ Quick Summary
Four stages: current state, simplification, tool and setup, adoption. 🪜 Software arrives at stage three. Digitising without simplifying sets the mess in concrete. A pilot shrinks risk. By month three you talk in numbers.
🎯 Next Step
Let’s do week one together: process inventory and baseline measurement are free — the digital audit. Scope on the consulting page. 🗓️
Frequently Asked Questions
Sık Sorulan Sorular
No complex method is needed: who starts the job, what happens next, who approves, where the information sits, when it ends. Write it on the floor, with the person doing the work. A process written at a desk differs from the one on the floor — and the desk version is the wrong one. ✍️
Because a baseline table can’t be built later. How many hours are spent, how many errors occur, how many days until collection — if these three aren’t measured now, “did it help?” goes unanswered six months on; the method sits in the return article. 📊
Three kinds disappear: approvals nobody reads, points where the same information is written twice, and controls added years ago for a problem that has since passed. This cleanup needs no software and its gain is felt immediately. ✂️
The mess moves onto a screen. A seven-step process becomes seven steps in software — now harder to change. That’s the reason for simplifying first; the full concept sits in the transformation article. 🚧
The requirement list of the simplified process. Split must-have from nice-to-have, trial two or three products with your own data, and run the export test. The decision logic sits in the off-the-shelf-or-custom article. 🧩
Because old records are messy, and migrated without cleaning the new system gets dirty too. A cleanup round before migration is the project’s dullest but most valuable work. 🧹
Because changing the whole company at once magnifies risk. A small team starts with a single process; problems get solved while they’re small, and once the gain is visible others join willingly. Details in the team article. 👥
Once the pilot team works comfortably in the new system and data accuracy is confirmed. Running two systems in parallel for long is the most exhausting scenario; set the closing date up front. 🔚
It takes a few days short term and saves weeks long term. Rebuilding software bought without it takes months. A rough write-up works too; waiting for a perfect document never starts the project.
A few people who live that process daily and are open to change. Choose the people doing the work rather than managers. The pilot team’s experience becomes the training material for the wider rollout.
It does, just shortened: write the process now, simplify it, then adapt the tool to it. In many cases the existing tool becomes sufficient with the right setup. A tool change should only be decided after the process is written.
Source: PMI — project management