Tags

, ,

A fair while ago, I used to be a business analyst. Not in name of course, but I would spend time in process mapping workshops, supporting and eventually leading them to gather how stuff was done, and how it could be done better.  I even spent time working on other peoples process maps, to think of better ways of making them fit to technology.

Probably, like the rest of you, I’ve seen a fair few ways of running those sessions. In the usual way of the blog (because all your attention spans are shot to pieces by social media), I’ve catalogued some observations. I would genuinely appreciate comment back on the way YOU run your sessions.

  1. Speak plainly. Adding layers of ‘business speak’ seems to be something some Business Analysts lapse into. Some sentences are wholly redundant (like 90% of all of my blog), and some even contradict in the second clause the bit said in the first clause. No one minds if you talk plainly or provide easy to understand metaphors or similes to paint your point. The role of the facilitator is to simplify and provide clarity.
  2. Understand As Is. Some consultants think it is very effective to skip the ‘as is’ analysis. When I first started out doing these things, we’d spend equal if not more time understanding the current state in detail. Now (especially with technology process mapping), there is an emphasis on just going straight to To Be (purportedly to save some money)  “The software works in a certain way, let’s just tell you what that is”. The point is, you have to understand the way the business works. there’s no way around it. Anything else makes you a shit consultant.
  3. Make your boxes make sense. What you write in the process box:  what it says, how it says it, and where it points to are crucial to making the process map readable.  It SHOULD be readable and understandable. If not, why bother?

So then, on to the best way to run a process mapping workshop?  Devise your idea/notion of an as-is map and walk through this? Start blank and work from there?  I often liked to start with a managers high level view of the process, then bottom it out as I talk to people. I’d often spend time individually to understand it before hand, such that the group session is more about the attendees understanding that they all have subtly different roles in the process and buying into the holistic process before them.

For the future state processes, I start with what I’ve heard and learnt that should be the future vision. Related to, but not hanging off the technology. I ask people to consider impacts more than consider boxes.

I’m no process analyst. I hold no qualifications, nor adhere to any methodologies. Not by choice, but because I’m an idiot. The main goal for me is that the process maps provide clarity of how it was, and how it could be – but most importantly provide a view of the business impacts of that process change.

 

Advertisements