Tripp is right. Having developed software for mainframes, minicomputers and microcomputers for the last four decades, the most common problem is trying to automate a broken process full of rework loops and workarounds.

First, simplify and streamline the process using Lean; then automate the process. Otherwise you are "hard coding" mistakes, errors and inefficiencies into the software which is much harder to change than a manual process.

Too many companies try to rewrite existing systems rather than fix the 4% of the software that's buggy or enhancement prone. As Frederick Brooks pointed out in The Mythical Man Month, 4% of IBM's 360 code had 64% of the defects. The same is true of all systems that have been around awhile. 4% of the code is buggy; fix it. 4% of the code requires most of the enhancements; fix it by moving flexible things into data tables.

To find the 4% causing most of the mistakes and errors, use the Dirty 30" process for Six Sigma software

knowwareman-

In a system, processes are only one component

I tried not to mention the word lean or systems thinking in this article as it has become divisive.  Deming didn't call it TQM and Ohno didn't call it lean.

Process improvement falls short of doing what needs to be done.  Changing the design and management of work is more than process.  It means our thinking has to change too.  I when I say thinking, I mean management thinking.  The industrialized, economy of scale, functional separation of work, etc. thinking of yesteryear is holding us back.  Every assumption that we have about design and management has to be challenged before technology is put in place.  Otherwise, we are only doing the wrong thing, righter.