I did a consulting gig some time ago where I had to redo the back-end business processes of a large online bookstore (handling, shipping, credit card approvals, feedback, internal communications etc. etc.) and not until now do I realise that what these guys should have gotten under normal circumstances was a full-blown ERP system.
What I did, however, was simply to go around the different staff and ask them what they did, how they did it, and how they thought it could be done better. Then I made HTML mock-ups and asked them to click around and tell me what they thought. Since these were the people that would actually use the system everyday they obviously had lots of complaints and ideas for doing it better. So we had a few iterations, and ended up with a HTML mock-up that everybody thought would be the best way to do things. The mock-up with comments then served as the specifications, and was easy to implement.
They paid me 10% of what they would for an ERP system, and it cut their internal costs by more than 60%.
Attention founders working on the premise that "where there's muck, there's brass:"
Enterprises need software products and backing services that assume the client will use the software to attain enlightenment about how they ought to change their own processes.
Figuring out how to do that with a model that can get around the distribution/sales/paperwork hurdle will make you rich.
"The business and developers need to work together to create a set of requirements that doesn't map the processes as they are, but maps the processes as they should be."
And therein lies the problem.
In the current ERP industry, you have 100 vendors, 10,000 programmers, 20,000 salesmen, and 6 people who know how to define requirements "as they should be". So you do what any sleight of hand expert does: you change the agenda.
"Do you really want to risk your audit if you don't buy software from my brother-in-law?"
What I did, however, was simply to go around the different staff and ask them what they did, how they did it, and how they thought it could be done better. Then I made HTML mock-ups and asked them to click around and tell me what they thought. Since these were the people that would actually use the system everyday they obviously had lots of complaints and ideas for doing it better. So we had a few iterations, and ended up with a HTML mock-up that everybody thought would be the best way to do things. The mock-up with comments then served as the specifications, and was easy to implement.
They paid me 10% of what they would for an ERP system, and it cut their internal costs by more than 60%.
It's all about process.