Control the present, plan for the future: Business Process Management as a base for clear and relevant software requirements.
The office, 09:30. My colleague, who sits next to me, starts to laugh and says: "check this cartoon, do you recognise this?". When it's 09:30 in the office and someone mentions a cartoon, you have a 99% chance it's a Dilbert. It was. The mentioned cartoon was about the struggle for getting decent software requirements on paper, you might have seen it pass by in your feed somewhere in the past few days.
"check this cartoon, do you recognise this?"
It inspired me to write a few thoughts on this topic. No rocket science (I wish I knew something about rocket science), just something I believe in. For those who have ever been involved in the different stages of the software development lifecycle, it will not come as a shock when I say that outlining what is needed or expected from software is a difficult process and that a waterfall approach fails. First of all, there is the idea of progressive insight, which allows the limited mind of the human being to explore and discover more along the road. The more you try to analyse and design, the more obstacles and new discoveries you encounter. Forests have disappeared to provide the paper for the books that have been written on this topic and being a fan of SCRUM or similar agile methodologies, I do not feel the need to cover this topic again.
But secondly, there is the ambiguity or unclarity regarding the 'base' to start from. A lot of organisations and companies are in the dark when it comes to the current state of the processes that are in scope for changes. Software should mainly provide functionality and information to support specific parts of a Business Process. Sure, there is more to applications than business related functionality (as there are the non-functionals or functionality that is not driven by a specific business need), but in the end, the main goal is still to bring added business value.
"A lot of organisations and companies are in the dark when it comes to the current state of the processes that are in scope for changes."
The thing is, the very old (might be Chinese) saying "innovate, don't just automate" doesn't always seem to be kept in high regard. Organisations tend to jump too quickly to the software side of the innovation and improvement process, disregarding the fact that they should first and foremost get control of their current processes (the AS-IS if you will) and just then define where they want to go (the TO-BE side of the story).
This provides them with a clear GAP, which is needed to understand what should be covered. Partially by implementing the right software and equally important by transforming your organisation through change management. Getting a grip on your Business Architecture allows you to do this and in my opinion, nothings else will. Even for start-ups and smaller organisations, however basic it may be, the benefits of documenting your processes (and by doing so making that knowledge explicit) are legit. It provides a common view on what you are doing, should be doing and where you want to go.
"Even for start-ups and smaller organisations, however basic it may be, the benefits of documenting your processes (and by doing so making that knowledge explicit) are legit."
Many companies seem to be afraid of Business Process Management, because "it requires too much work to set it up and maintain". But in my opinion and experience, having no BPM initiative at all will bring the kind of unclarity that causes bad decisions, mistakes and a lot of rework, resulting in value lost. This goes obviously beyond the scope of software development, but I honestly believe it is crucially important in this area.
"having no BPM initiative at all will bring the kind of unclarity that causes bad decisions, mistakes and a lot of rework, resulting in value lost"
Feel free to reply or start the discussion, as everything we hear is an opinion, not a fact. And everything we see is a perspective, not the truth.
Have an inspiring and joyful weekend,
Jonas
Interesting thoughts Jonas, even though I'm asking myself what your definition is of BPM in all of this: is it simply documenting how you run your business (as a team, as a company, as a business owner) or is it more "trying to think as a software/system maker who runs a business" by structuring stuff on paper. Personally I think the first one is obvious if you want to evolve as a company, the second one is less obvious, but nonetheless crucial when defining the GAP; it's more a question of attitude and state of mind of the individuals working on the project. Have fun catching those poké beasts ! Or catch other stuff like me :)