Readers who know me, might remember that I spent quite some years working for a vendor of BPM software.
The first years we offered all kind of separate products that supported doing "something with processes". Think about stuff like:
Modelling tools to model processes (not only the workflow so also data, people, applications, etc)
Workflow management tools to support the execution of well definable processes
Case management tools to support the execution of more dynamic processes
Process mining tools to discover "processes" out of log files of the systems you use to execute
So, specific tools that were, at that time, quite good in what they were designed for.
But, then came the time where "Holistic BPM" was on the rise; taking all aspects, that are needed to manage and (continuously) improve an organization by process, into consideration
Technology wise it led to the era of the BPM suites. Since that time, the names might have changed into things like "Smart Process Platform" or "Digital Business Platform", but the main idea stayed the same: combining the functionality of the separate products and more important; make them work together. In a suite.
As a process nerd I thought this was amazing. Complete overview and control on all your processes from one overall platform.
Starting with a process model, that, if you liked, could be exported to a nice process manual, but also the possibility to develop the model into a system where you can support the execution of a process. With work lists, e-forms, data-integration, monitoring; just everything that could be labeled "case management by process".
Wow, BPM suites; they sound like every process oriented companies' dream. Especially when you want to start form scratch and want to support the execution of your processes with BPM technology.
But, the truth seemed that "starting from scratch" was an illusion in many cases. And that's not so weird, because organizations just have processes. Maybe they could be improved, but they are already executed. Every day.
Besides that, there are many processes in organizations of which you could ask yourself if it's worth the effort to design them, including the supporting software, by yourself.
Think about back office processes like "pay invoice". Many organizations just want "a tool" they can use to do the job. Just buy some best practices (maybe with a little configuration) and get to work.
And that's not so weird at all. I don't know many organizations (or actually some decision taking person) that says "We want BPM".
But, I know many organizations that issue permits, repair bikes, treat patients or develop software. In short, the specific reasons why those organizations exist and customers like to spend their money there.
And that brings me to the traditional BPM approach "a good process starts at the end"
So, I would always start with a clear view of your desired process results. The extra post-it note about "wanting to sleep" is to stress that you always have to be sure that your process results still are the best way to help your customers.
If yes, then ask yourself if that process result is delivered as promised. If not; that could be a reason to take a look at your process(es).
And you know that a process is set of collaborating aspects, of which supporting software is just one.
Maybe you will discover that starting from scratch in a BPM suite is not necessary, but more and more you see that vendors offer "turn key solutions" build on top of their platform.
You'll find them in the warehouse in the "Smart process apps" storage shelf.
But always keep wondering if your process would benefit from a do it yourself kit or that a second hand bed from the jumble sale is more than enough.