Through my years working in IT, implementing different systems, and even working for various companies – I constantly see the same thing. Mapping processes in an organization have been overlooked!
Something is broken and it’s a big deal – let’s throw some software at it and see if it works! (I can definitely see my younger self in this faulty thinking.)
I can stop You right there – if the process is broken or non-existent, fixing it with software just makes an even bigger mess.
Why?
When You start fixing Your problems with apps first (or software) You are going to run into multiple issues.
- The software or app doesn’t do what You want or need.
- The solution – get a new one! Nope, please don’t do that.
- The offered solution does some of what You need but not all that You truly want.
- Need to develop customized solutions, right? Not yet!
At this point in this real-life scenario, a lot of people have wasted their time (which equates to money) and energy on the project. And we still don’t have a working solution.
This all means losing money for the organization. Instead of taking the longer route at first.
What is the long game in this scenario?
Understanding the processes more deeply in Your organization
Before paying for analysts to see if “this software is right for the company” You need to understand Your own processes. Or the lack of them.
This is tedious and boring work that offers a lot of value to Your organization.
So if something breaks – understand what that something is before You start fixing it with an app!
How to go about mapping processes in an organization?
Understand the main process in Your company first – this should be given in every respectable organization.
So for example, if Your company builds houses it could look something like this.
Initial contact
The client becomes aware of Your company > they send an initial request for more information > Your company sends it.
The cost estimate
They come back with “I want a cost estimate!” > your team goes to work and asks for more details > and it goes back and forth > finally You send an estimate > but it can go back and forth still.
If You are going deep into processes – You must map every single move Your company makes. Then You will start to understand why things move and most likely are broken in Your company.
The contract negotiations
Here’s where the two parties argue with one another about specific details.
And at the same time, the planning and production departments are already doing their business – a sub-process that is running simultaneously.
The signing of the contract, payment, and the start of production
This is quite self-evident but I wanted to give an example of a real-life main process in an organization and mapping it.
End of production and installation
This is where the production stops and the houses are installed on site.
Remember that Your specific process might greatly differ. This is just an example of how to think about Your main process within the organization.
Installation finished and “keys” given to the buyer, final payment
The project is finally done and most think that this is it. But not when You are building something with a guarantee! (Hint).
Guarantee works
If something is not up to standard or broken – the guarantee department fixes it. If it broke in the given timeframe detailed in the contract.
And that’s it. That is how You map a main process.
Important things to remember in mapping processes
The deeper You go – the better. You really need to understand what is going on in Your organization before You can fix it.
Preferably before You start throwing software at it.
When does the software come into play?
It seems like we have been mapping processes in an organization with no end in sight. We are just about there…Hang on with Your apps just a moment longer!
I will propose a scenario to You.
You have now mapped the main process in Your organization. And You know how You make money as a company. But as I mentioned, there are a lot of sub-processes everywhere within the main process.
And highly likely that this is where the “problem” happened that You are trying to fix.
It’s time to dive into one of the sub-processes and make it 110% clear for all the stakeholders within the process.
Example of mapping processes in an organization
Let’s take the cost estimate part of the main process. This is often where things go wrong or there’s a bottleneck.
Start with the request – how does the client even communicate their needs to You? Is it on paper? Is there an email? Get into the nitty-gritty details.
After that’s done – who takes care of it on Your side? Who receives it? Who forwards it and where? Are there files involved? Is it done with a ruler and pencil?
So on and so forth. Until You have all the little nuggets mapped out. Go and talk directly to the people involved – this is the best way!
It’s surprisingly boring but interesting work. Crucially important!
Automating and fixing the process with software
Almost…Just a tiny reminder – if the process itself is broken underneath, You need to change it. Once it’s changed, You can proceed with the software. Or if the software itself is the cure – now You understand it (maybe it automates a crucial part and eliminates human error for example.)
You are finally ready to throw some software at Your problem!
Because You understand Your needs. This is a big reason why You map the process in the first place.
Now You can go to a developer and say “I need this, make it for me.” Or a software company with an existing solution. “Hi, we have this problem with these actions – does Your software solve it?”
Things tend to move much more quickly after that!
Hopefully, this helps to shed light on why solving problems just with software isn’t always the best idea.