The 'How To' guide to ERP Requirement Gathering

Requirement gathering in an ERP Implementation is always difficult. You are always worried if you are doing it right.

Am I getting all the requirements?

Should I ask direct questions and get the requirements or should I ask open questions and somehow 'progress' gradually towards the actual requirements?

Should I follow the 'Checklist' approach?

Should I follow the 'Process Flow' approach?

Is requirement gathering worth it? Isn't it better to demonstrate the flows that exist in ERP and ask the client to modify their process to suit ERP requirements?

What if I miss an important requirement? How should I handle it when it hits me in the face at a critical phase in the project?

Despite my experience in many ERP Implementations, requirement gathering always stresses me out. I am always wondering if I got it right, if I asked the right questions, the right follow up questions, did I document it all, should I have taken an audio recorder, should I have videotaped it....

So many questions.

Ain't I happy that some process exist?

So how do I go about it?

Normally I plan for about three weeks of requirement gathering. In the first week, I configure the application as close as possible to the clients environment. I ensure that the company name is the same as that of the client (Not some esoteric ''Vision Incorporated"), I get the correct address, I get the key account numbers, the item names, the supplier names.....

The works...

Having configured the same, I do the process demo in that environment. If I do this properly, I find that the client themselves comes out with the requirements. I just have to document the same. And most importantly, I do not miss out on any key requirements. And the icing on the cake is that the design automatically gets generated.

I generally take a 'Process Cycle' approach. Some consultants prefer the module approach, but I think that the module approach do not factor in the module integration aspect of the ERP. Even Though I take the 'Cycle' approach, I modify that to also include the GL aspects of the demo. By this, I mean that I create transactions, create accounting, post to GL and show the P&L and Balance Sheet impact of each transaction. I see that this resonates well with the customer and give them a very clear perspective of ERP.

I also give a lot of emphasis on the reports during the requirement gathering. I start of by collecting copies of all the reports and documents that the customer will require. I review them very thoroughly. The external reports like Purchase Orders will give me clues on various key business aspects as well as the nature of the business. Some of the internal reports show me what Organizations consider as important and I also start planning the design of the solution around the key information that management require.

One thing that I do not encourage is customization. Early in my ERP career, I used to implement an ERP application called 'SCALA' which was non-customizable. Since every customer has his or her own business process requirement, every time I implemented SCALA, I was forced to come out with creative workarounds to handle customer requirements. I carry that culture even to my Oracle Implementations. I try my level best to give workaround solutions to customer rather than customize the application. With the DFF feature in Oracle, it is much easier to provide workarounds.

Another key aspect I ensure during requirement gathering is the creation of workflow diagrams demonstrating each process being discussed. This helps to logically build the business processed during the implementation. 

I also use the soft skills like listening intently to the customer (this habit developed when I was implementing the ERP for a Spanish Customer, who could speak English very hesitantly) and also paraphrasing each point that the customer is making and drawing the same as flow diagrams on the board.

I have observed that most of the key requirements are elicited during informal 'water cooler' moments. That is when the customer opens up about his fears, his anxieties and organizational expectations. To ensure that I do not miss important requirements, I always carry a pocket diary with me in which I jot down these critical requirements and ensure that I move these requirements into the final document.

Requirement gathering is completed with the creation of two documents. One, the requirement document and Two, the MOSCOW List.

There is not need to elaborate on the Requirement Document. MOSCOW List is the acronym of Must Have, Should Have, Could Have and Dont Have. Must Haves are mandatory for the customer. Without meeting these, the ERP implementation cannot progress. Normally ERP applications can handle most of the must haves, but if the ERP Application cannot handle it, we have to go for customization.

Should Haves are also very important for the customer, but in case of Should Haves, the customer is willing for some compromise like process change.

Could Haves are 'Nice to Have' kind of requirement. While the customer is not very demanding about these, most of the time the customer delight is obtained only when Could Haves are delivered. In these kind of requirements, I generally set a very low expectation and later when I deliver these, customer is very happy.

Don't Haves are those requirements that are redundant because of better features available in ERP. One example is replacing the paper based approval system with Notification based Approval that most ERPs provide.

Finally, I also identify at least three solution approaches with their pros and cons for each critical requirement. This helps the customer to make an informed choice during their implementation.

This is a part of my next article on solution design in the 'How To' series.

Well, this is my approach, what about yours?

Additional Reading:

• Brett Beaubouef Blog