We programmers talk about getting rid of accidental complexity so that our code contains only essential complexity. And business processes are what we think of as essential complexity. Fair enough. But business processes have accidental complexity as well. Business processes suffer from poor maintenance over time. Business processes need to be refactored as well, and when you have a project to automate a process, you have a certain amount of freedom to challenge the process, to prod and poke it, to question it. Don’t assume that you have to take it as entirely given, a set of requirements cast in stone.I've mentioned the whole accidental complexity thing before, although not in terms of business processes. Reg's post is a great read (and well worth a look), but the post points to an even deeper issue in software development: Trying to convince your customers (or stakeholders if you prefer) to change their business processes.
Now all software developers, in the course of working on some project or another, have always come against some workflow issue and said to themselves, "why the hell do they do that?" I have had plenty of those situations (far more than I'd like to admit, I think) - especially on a recent project. In many cases, instead of trying to point out the problem, we'll happily plod along and do what the customer asks rather than tell them they need to change how they do things. In this sense, we're just as liable for the problems of process complexity as the customer since we don't point them out when we see them.
But one big reason we're content to just shut up and code is because the customer pays the bills: They ask us to build something and we build it. In a lot of situations, they don't want us telling them how to do whatever it is they do - they just want us to build them something. Period. End of story.
Sidebar: This is especially the case in the government sector - where trying to get some organizational unit to change it's business process can take years to do, and may even require action by congress. This is a big reason we get projects like Virtual Case File as results - not enough critical attention is focused to the business processes, since nobody really has the capability to make immediate changes. A bureaucratic (or otherwise complex) process will result in a bureaucratic software system (if it can ever actually be implemented in software, which is not very likely).
So how do we tell the customer/stakeholder to change their business process?
I don't think there's an easy answer to that, since every situation is different: Some customers are simply more receptive to such suggestions than others. I guess the first part of the solution is to make sure you're working with the more receptive customers before you start the project...that way you can avoid the headaches altogether.
Probably the best way to get a customer to change a process is to show them: If you're developing a software solution that follows the business process in question, than being able to show the customer a prototype of a more streamlined business process might help get the point across in a better way than simply saying, "Hey, you're process is flawed. We should look at improving that first" ( and if you're following some rapid development process like XP, or other agile method, this shouldn't be too hard to do.)
If nothing else, this should at least help open a dialog between you and the customer (And we all know how important communication is around here, don't we? :-).
Having that kind of dialog with the customer is the key to getting the customer what they actually need, rather than just what they want.