none

a_senad

none

Miklos_Hollender

As I promised in your survey, I'll explain here why I think the methodologies you mentioned there aren't a good fit for ERP development. First, two kinds of problems exist in general:

1) well structured problems, where the desired result is known beforehand (f.e. repairing a hair drier)

2) badly structured problems where the desired result isn't known beforehand.

ERP development I think falls into the second category, for many reasons, but let's look at the most important reason. If you look at what result a given piece of software delivers: Microsoft Exchange makes your e-mails reach it's receipients, Adobe PhotoShop makes nice advertisements in
newpapers etc. What result does an ERP system deliver? Basically it tries to automate interactions between people, tries to gather information from one participant, transform it and present it in a different way to another one. There isn't any known optimum in the same way that there isn't any known optimum in politics: the priorities and preferences of people differ and always change.

As far as I know, the only thing you can do with a badly structured problem is establishing a "root hypothesis" about what a desirable result could be at the first glance, and solve it. And then evolve both the "root hypothesis" (the assumed optimal result) and the solution until nobody
complains too much anymore. Thus, solving a badly structured problem means iteratively improving your understanding of the problem itself as you build newer and newer solutions, because each solution will introduce newer and newer troubles, thus showing those facets of the original problem you didn't notice or understand completely at the first couple of tries.

In software development, it is called Extreme Programming or Agile Development - which (very roughly) consists of the following process:

1) the users vaguely describe some "dream" on what they'd like to have (at my previous company we called them "wish lists to Santa" as usually users required features they clearly didn't have the budget to have developed therefore the wish lists usually needed to be trimmed heavily)

2) you develop a rough version of it just the way you see it fit according to your imagination and your first vague understanding of the problem, in a RAD environment, in a very short amount of time (a couple of days at most, preferably just hours)

3) show to the users, who play around with it and won't like 60% of it

4) rewrite that 60%

5) next time it's just 40% they won't like... etc. etc.

until you reach 0% - and besides, you have to keep in mind that from about the third iteration on, your code base is a complete horrible spaghetti mess, so you have to do a deep refactoring, redesign as well somewhere along the process.

Of course, the interaction of the different parts of the systems is always a problem in ERP - you can satisfy one given user with this process but won't it break something else in the system? Well, as far as I know, no formal design process, only experience, intelligence and common sense helps. When a user from a logistics department requests some weird way of adjusting stock levels, you simply need to know by yourself how that will likely hit the General Ledger and act accordingly. I don't think this can ever be formalized, only experience helps (or nice, patient users until you get the necessary experience...) .

I found that only this approach works for ERP. But, it requires a really rapid RAD environment - like that one Navision has, as opposed to, for example, SAP ABAP, or the old COBOL, RPG/400 etc. systems...