Blog · Aliso Digital
Practical thinking on digital transformation, process, documentation and the people side of change.
No articles found. Try another word or topic.
Ask most people what a technical writer does and they’ll say writing. Fair enough, it’s in the title. Spend a few years doing it though, and you notice the writing is rarely what makes documentation succeed or fail. Well written procedures nobody can find are useless. Plainly written procedures organised
You’ve got a system going in. The budget is approved. Now someone asks who you need to hire. A business analyst, a process analyst, a technical writer? The job ads blur together. Plenty of people use the titles interchangeably. Hire the wrong one, you’ll still get a document. It just
Most system rollouts have 2 sets of documents that never quite meet. On one side sits the process work. A BPMN 2.0 process map, current state, future state, pools and lanes showing who does what. On the other side sits the design work. Wireframes, screen flows, a prototype somebody built
The vendor has a go live date. The steering group has a budget. Then someone asks a simple question. “How does this process actually work today?” Four teams give four different answers. Nobody’s wrong. Nobody has ever written the work down end to end, so the vendor is designing against
Rollout day arrives. The new system goes live, the training is done, the project team is on standby. Then someone in the contact centre asks a simple question about a refund, opens 3 different folders, finds 2 versions of the same document, gives up, then asks the person next to
I’ve been part of digital transformation work for close to 20 years now. Some of it went well. Some of it didn’t, which is more instructive. Looking back at the ones that struggled, the causes were rarely technical. The platform usually worked. The methodology was usually sound. What went wrong
There’s a question that comes up early on most programs, usually as a scheduling problem rather than a role question. Who’s actually documenting the process? The business analyst assumes it’s covered. The change team thinks it’s a project deliverable. The process owner assumed someone did it years ago. Meanwhile the
This comes up in almost every process analyst interview. How do you handle resistance to change. The honest answer is that most people aren’t resisting change itself. They’re resisting being changed by someone who hasn’t asked them anything. There’s a difference, though it takes a while to see it. Once
The default way to run a current state session is to get everyone in a room, put a blank wall in front of them, then build the map live. It’s the accepted approach. It’s also the reason process mapping workshops have the reputation they do. Three hours disappear, the loudest
