You sit down with someone and ask them to show you what they do and inevitably they begin to show you how they do what they do. “Ok, when I get this, first I go into here and pull this info. Then I go over there to add that to this. Finally I merge this together, sort, add magic fairy dust and then send it off!” The potential pitfall here is to begin mapping out that process.
OK, before we go further, let me clarify. Yes, of course you have to map the process and understand where information is and what exactly is being brought together for consumption. What I’m going to go on about here is what happens when we build out that process.
So anyway, there we are with our construction paper on the walls and enough flow charts to trawl for fish! We map everything out, model it, test it and get user feedback. At the end of the day (well, really at the end of your SDLC) you have successfully replicated the user’s process and now they use this new process to do how they used to do.
Wait! But what did they used to do? It doesn’t make sense to build anything that does something the business already does unless there is some value added. Most of the time that value is in a saving of time and effort, but why are we replicating the process? We should be looking at what exactly they are trying to accomplish. I’ll make up some kind of example here to illustrate my point, hopefully (if not, at least it should be entertaining).
Let’s say John is explaining to an analyst how he handles parts in his shop.
John: “I have a pull cart for this part.”
Analyst: “Why?”
John: “Because it’s too heavy to move.”
Analyst: “Where does it have to be moved to?”
John: “The other side of the building.”
Analyst: “Why does it have to go there?”
John: “Because it needs to be painted.”
Analyst: “What do they do after they paint it?”
John: “Oh, after it dries they bring it back here so I can put it together.”
So the flow gets mapped out and they build a conveyor belt system to move the parts back and forth. And there was much rejoicing!
OK, don’t get too picky with the analysis, just follow along. So here we see a solution built out to improve the process, but the real question should have been, “what do you do?”
John: “I get parts, send them to be painted and when I get them back I put them together.”
Analyst: “So you assemble the part after it’s painted?”
John: “Yes. Once it comes back I put them together.”
So looking at the what, instead of the how, we decide we don’t have to build anything to move the parts around, instead we just move the painting area next to the part area and now they don’t have to move the parts around at all. Less down time waiting for parts to move around, less chance of a mishap, etc. This is because what they are doing is painting and assembling, but how they did it was by moving the parts around the shop.
All kidding aside (and cheesy example), I have seen time and time again, not just in my business, but in others’ as well, that the process gets mapped and then built and in the end the users get something layered on top of their workday to accomplish what they were already doing just with a different tool that doesn’t bring additional value added.
So all I’m saying is to think of what needs to be done when developing solutions and not just how it’s done. You’ll end up with not only a better process, but a more efficient one with added value and everyone will wonder how they ever got things done before.
