Short URL: http://bit.ly/TopDown_BottomUp
There are two approaches to ERP requirement gathering. Top Down and Bottom Up.
There are two approaches to ERP requirement gathering. Top Down and Bottom Up.
Top Down approach starts with reports. Consultant starts by collecting the critical reports that company uses / requires and start her requirement gathering by analyzing these reports. She asks questions on these reports, get clarity on the report requirements before moving on to discussing the process requirements. The top down approach starts with the consultant sitting with the senior management before she sits down with the users to discuss the process requirements. Thus the consultant gets a feel of the important information requirements for the customer
Bottom up approach is the reverse. It is the traditional approach to ERP requirement gathering Consultant starts off the requirement gathering sessions by sitting down with the users. They might open the RFP document, if there is any, and then go through each of the processes one by one. The process requirements are then documented and signed off.
Which is the better approach?
In my opinion, you must always start off with the critical reports ie. Top Down Approach. It ensures that every stakeholder feels involved in the ERP implementation and senior management feels that the implementation team has heard their requirements. This approach caters to the requirements that are important to the Organization and ensures that these requirements are considered during the solution design
The ERP cycle always starts from Top Down. Since senior management is deeply involved in the proposal, one way or other, their information requirement will find a place in RFP. If these are not mentioned explicitly, the proposal will implicitly mention these requirements most of the time. For instance, an information requirement will be couched as a process requirement. In this way, Top Down Approach is harmonious with the ERP Cycle.
If Top Down approach is the superior approach, why are many projects not using this approach?
There are six reasons.
1. RFP does not specifically state the report requirement: Neither in the RFP nor in the proposal, the reporting requirements are detailed. All you will see in the proposal is a generic statement that goes something like 'XYZ Company will deliver 10 custom reports as a part of this project. Of this 4 will be of high complexity (refer appendix B for definition of complexity), 3 will be of medium complexity and 3 will be of low complexity'. This means that in the proposal stage, the report requirements are not clear to either the client or the SI (System Integrator, also called Implementation Partner)
2. 'Loss of information' as it flows from the bid team to the consultant: As I mentioned earlier, the reports are definitely discussed during the pre-sales stage. However as the communication flows down the ERP Cycle, there is 'Information Loss' and the consultant will not be knowing about the report / information requirement
3. Vendor's implementation methodology encourages bottom up requirement gathering: All the major ERP vendors have their own implementation methodology that details their implementation philosophy. All of them have a stage of 'Requirements Definition in which the consultant is expected to collect information from the customer users. The discussion will focus on processes with reports being cursorily mentioned if at all. This is classic Bottom Up approach
4. Power users, with whom consultants spend most of the time, are not aware of the critical reports requirements: Power users are the point of interface between the customer and the implementation team. They are the ones who will give inputs to the consultants. Since most of them spend time mostly with process owners and end users, they are more conversant with the process requirements of the transactional users rather than the report requirements of the senior management.
5. The terminology: What we are discussing is 'Information Requirement' from ERP, which should be an integral part of Solution Design. By using the term 'Report Requirement' we are segregating this as an esoteric technical activity to be done by a technical developer, and which has to be planned as a separate phase after freezing the Solution Design. This brings us to point 6 below.
6. Project plan schedules reports discussion after Solution Design: This goes with the implementation methodology. Report requirements are considered different from Information Requirements and the development of reports is considered to be an independent technical activity rather than one integral to the solution. Due to this the design and configuration considered required to capture information to be display in reports is missed out.
How do we get around this conundrum?
The solution lies in the question itself. Ensure that report specifications are documented early in the project cycle either in RFP or in Proposal or not later than in Requirements Definition Document. Ensure that the implementation consultant factors in information requirements in the solution design and configuration. The project manager should schedule requirements discussion with the senior management as well as the Power Users as a part of the requirements gathering phase of the project.
Following a ‘Top Down’ approach will ensure that all stakeholders are involved in solution design and this will lead to Customer Delight, rather than just Customer Satisfaction.
About the author
He has implemented more than 25 highly successful ERP implementations. He has worked on Scala, Peoplesoft, Oracle EBS (11i and R12) and Oracle Fusion Cloud in various roles including CIO, Program Manager, Delivery Manager, Project Manager, Solution Architect, Functional Lead and Consultant. One thing common among all these roles is an average customer satisfaction rating of more than 90% over his over 20 years of ERP Implementation expertise.
In a career spanning more than 30 years, Ram worked in Manufacturing, Academia and ERP Implementation. He has implemented ERP Solution in all business areas including Procurement, Inventory, Manufacturing, Costing, Order Fulfillment, Financials and Budgeting. He has also worked as a CIO of a Food Product Company and has experienced ERP from both sides of the spectrum. Having done many implementations in India, Ram knows India Localization like the back of his hand.
He loves ERP Implementation and the value that it can add to a customer business and the smile on the face of a delighted customer.
He is currently looking out for opportunities. You can download his latest CV from his LinkedIn Profile www.linkedin.com/in/vkramaswamy. He can be contacted on LinkedIn, Email (vkrama01@gmail.com) and Phone (+919880179317)
Work with him for a perfect, on-time ERP Implementation.
No comments:
Post a Comment