As always OJ good points , I have to agree with your disclaimer of bias as a dev. The BA is as usual the meat in the sandwich and blamed for bad analysis . In my experience more often than not BA's are aware of the bad business process and have raised this as an issue. The result is that the business owner has made the call to move forward and deal with it from a technological point of view rather than re-engineering the process.( In the long run I have found this comes back to bite them in the wallet ).

I must say that I am a fan of devs who wish to be involved with the BA's and business partners. From my point of view I will always encourage this as I believe the better informed a dev is of the problem and process that is trying to be solved the better the end solution.

I return to the comment that there is no excuse for BA's/Dev's to get this wrong , it was poorly worded . I should have expanded on that the in the terms that if they are provided with the right specs and the right mapping they should get it right.

I am struggling to see how I've answered my own question :) I can definitely see how over time it becomes harder for people to realise and understand the flaws in their process. I can also see that if the process of mapping and documenting the existing process will help in uncovering and understanding the flaws. However, those insights don't make the connection between your two points :)

As far as your last point is concerned (re: no excuse for the devs/BAs) I'm not sure I agree 100%. You see, most of the time (particularly in enterprise software development) the devs do not have a hand in the mapping process. They are given requirements from the BAs and that's what has to be mapped to software. The work done by the BA to map the process in the first place is what they have to rely on. I'm generalising, as sometimes this isn't the case. On the whole, this happens more often than not. Even though a perceptive dev will be able to spot certain types of flaws (ie. the ones that defy logic, rather than what go against the goals of the business process itself) and hence push back on the BA to find out what the issue is and resolve it. But there will always be some business processes that slip through the gaps and make it into production. I put this down to poor work by the BA, and really shouldn't be blamed on the devs.

Disclaimer: I'm biased, because I'm a dev :) But I am a dev who tends to try to be involved more with the BAs and the business to try and reduce the likelihood of this happening in the first place.

Very well spotted OJ ,
You also mention that you have seen business processes that are a dogs breakfast and the business don't even understand their own process , let alone recognise the flaws.
In a way you have answered your own question, you see as a BPM practitioner I often see after a mapping process that the business are startled by the flaws that are evident. You see most business processes have evolved over many years and have had so many layers added to them that it is impossible for them to see the flaws until the mapping peels back the layers of the onion.
In terms of your second scenario , in my experience if the mapping is done in the first place then there is no excuse for the dev's and BA's not get it right .

Tony,

I can't help but notice that there's a little bit of a flaw in your post :) You start by indicating the issue is that the business process itself is flawed. You then conclude with the implication that the failure is that we fail to do a proper job of describing and mapping the business process.

So which is it? Because if the business process is flawed, I would be happy about not wasting time mapping it :)

I've had a mixture of the two during my experience. There have been many times when I have worked on software which is designed to solve a problem with either the problem doesn't exist or the problem exists because the process that the business is trying to follow is basically a dog's breakfast. The issue here is that they really don't understand what their own business process is, let alone recognise that it's flawed in the first place.

There have also been times where I've worked on a solution where the problem is well understood by the business and the process they follow is actually quite good, but the BAs and Devs have done a poor job of mapping out and understanding that process and hence end up with a flawed interpretation/implementation of the solution. This leads to pain of a diff kind.

Which set of experiences is the target of this post? :)