views:

198

answers:

3

When developing an ERP-like software or any other complex business system, what resources do you go to for best practices?

I'm a developer, not an accountant, not a purchaser, not a manager.
I do have project management experience in engineering (non-software related) and I have a fair amount of experience on business processes in Design, Purchasing, Stock management, Sales, Manufacturing, Quality Control, After Sales, etc.

My issue though is that when developing business software you always end-up confronted to areas where you lack expertise and I believe that a good understanding of the processes and how others solved similar issues are absolutely essential for developing competent software.

So, are there any online resources with some best practices or collections of practical experiences on how people solve and implement business rules and processes in ERP systems and the like?

+1  A: 

I'll assume that you don't mean best practices for software. You're talking about business practices, right?

Where do you go? It seems obvious, but you have to find domain experts somewhere. They should be inside your company if it's of any size. If you don't know the subject well, and it's unlikely that you'd be an expert developer AND a guru on GAAP, you need to find sources that do know.

I think this is the right place for buy versus build decisions. Why write an accounting package when there are so many available that do it for you? Most people who decide they need to write their own general ledger usually justify it by citing "ridiculous" licensing costs, but they fail to accurately estimate the true cost of designing, implementing, testing, and maintaining their own system. Buying a package means acquiring the distilled expertise of all the people those developers contacted. You assume that they did a good job of it, too.

duffymo
+1  A: 

In order to understand 'how the things work', you'll first have to look at your client's internal procedures: procurement procedures are good examples. They are usually fully documented, as procurement process is considered a potential source of problems in most companies (On the opposite, accounting procedures are usually poorly documented because they rely on official and mandatory rules).

Through these procedures, you will discover all standard forms in use in the company, who does what, what has to be kept or archived, etc. This will help you understand the processes before meeting the persons in charge. Allways keep in mind that your application shall stick to these procedures and, if procedures do not exist, the app will de facto become the procedure: in this case, you will usually have the opportunity to (1) buy as proposed by #duffymo or (2) build following your clients requests and specs. In this last case, I'd advise you to collect from the users the different documents they already use, usually some Word templates + some Excel sheets for data follow-up. It could be a major source of inspiration and could help you to elaborate smart proposals...

A module for procedures follow-up and management (annexes, draft proposals, etc) could be a nice way to start with your 'ERP like' system.

Philippe Grondier
__>They are usually fully documented__ In a perfect world, yes, they should be, but in practice they're often either not well documented, not reflecting reality, out of date or just missing.
Renaud Bompuis
You're right! We were just reviewing these days the official procedures for document archiving ... completely out of date!
Philippe Grondier
+1  A: 

There's APICS, the Association for Operations Management at www.apics.org. (The "I" stood for Inventory, but paradigms change ... ) Many cities have a local chapter with regular meetings.

Smandoli