Disclaimer:
The articles in this blog post are those that I found interesting and
relevant to the topic of ERP and technology in general. I have no
commercial association with any of the entities mentioned in this
article. I may be following a few of these entities on LinkedIn and even
some of these entities may be on my LinkedIn or Social Media network.
These articles are selected purely based on their relevance to the
objective of this blog, to promote ERP. Finally, the summary is mine.
While I stay close to the points in the articles, I also elaborate a few
of them based on my understanding.
The Short URL for this post is https://bit.ly/2uNXK4B
The steps in ERP Implementation are:
5. ERP Implementation: ERP Project Management
6. ERP Implementation: Requirements Gathering
7. ERP Implementation: Solution Design
8. ERP Implementation: Solution Testing
9. ERP Implementation: End user training
10. ERP Implementation: RICE
11. ERP Implementation: Integration
12. ERP Implementation: Data Conversion
6. ERP Implementation: Requirements Gathering
7. ERP Implementation: Solution Design
8. ERP Implementation: Solution Testing
9. ERP Implementation: End user training
10. ERP Implementation: RICE
11. ERP Implementation: Integration
12. ERP Implementation: Data Conversion
13. Post Implementation Support and Stabilization
This week's theme is ERP Requirements Gathering. A bad requirement gathering process has been found to be the root cause of most of the ERP implementation failures with almost 50% of the cases pointing to this one issue.
I really enjoyed preparing this post. I learned a lot while reading the articles. The first article says that a consultant must factor Stakeholders, Value Proposition and Approach while considering the requirement gathering exercise. The second article is from my blog. I talk about four layers of requirement gathering and the similarity between that and peeling an onion. Third article by Brett Beaubouef, talks about different requirement gathering strategies like process driven, solutions driven and configurations driven strategies. The last two articles are academic papers that give different perspectives to requirement gathering. The fourth article talks about the costs of a missed requirement, while the fifth article talks brings in a totally new perspective to this process. It says that failure of requirement gathering is due to different language spoken by the giver of the requirements and the receiver of the requirements. I never looked at it that way before.
Also checkout the section on additional readings. That section packs a punch.
https://www.erpfocus.com/requirements-management-considerations-for-erp-implementation.html
An ERP implementation could be of three types. The 'Big T' (large scale enterprise transformations), the 'Little T' (minor transformation in one or more business functions) and 'Lift and Shift' (essentially technology upgrades from one application to another). Irrespective of your transformation type, you need to have a strategic approach to requirements gathering.
The five aspects of requirement management to consider when starting an ERP project are:
1. Stakeholders: It is important to identify the stakeholders and address their implicit and explicit expectations. There are 16 stakeholders including regulatory agencies, vendors and customer, competitors, potential customers or users, the funding organization etc.
2. The value proposition: It is very important to start an ERP implementation with a business case that outlines the objectives and expected benefits of the project. During implementation it is very important to tie back the project progress to this document and ensure that all aspects of implementation are in sync with this document. In my experience, most of the ERP implementation get bogged down in the mechanical aspects of implementation and lose sight of the business case. This is a very important point.
3. Approach and plans: MoSCoW traceability matrix is the best tool to capture, prioritize, trace and track requirements over the duration of the project. This should be accompanied by test strategy and acceptance criteria. Together they ensure that all the important requirements are met during the course of the project.
4. Requirements analysis: The first iteration of MoSCoW list will baseline the requirements. Any further changes should be accompanied by integrated change management plan and issue tracking (this point is not covered in this article) process to ensure that identified and prioritized requirements are configured and tested during the course of ERP implementation.
5. Look beyond RICE: Most ERP implementation get stuck at the RICE (Reports, Interfaces, Customizations and Extensions) stage of solutioning. Over the course of implementation they miss the wood for the trees and lose focus on the stakeholder expectations. It is important to look at ERP as a Business Solution rather than an IT solution.
Great article. Thank you Brian Williamson
https://erp-consultancy.blogspot.com/2018/11/how-do-you-peel-onion-in-erp.html
The requirement gathering is like peeling an Onion. You cannot peel an inner layer without first peeling the outer layer. As you peel the outer layer, you move towards the core part of Onion. Similarly a customer will provide you ERP requirements in layers. You will earn the right to the inner layer only if you provide solutions to the outer layers. And as you go deeper, the quality of the requirements and their business value add becomes significantly higher. Also, deeper you go, the requirements will be provided by higher authorities in the Organization
The first layer of requirements are mostly mechanical like interfaces, data conversion scripts, simple reports and straight forward processes. The consultant is expected to solve them. If she does solve them, she will not get any credit. However, if these are not resolved, the System Integrator will be blamed. This requirement is usually given by the end users
The second layer of requirements are the ones in the AS IS document. This could lead to some effort to be put by consultant. If these are resolved, the consultant is not going to get a lot of credit. It will only reinforce the idea that the customer has purchased a product of right fit. Many consultants spend too much time on this layer and hence the customers rate their ERP implementation as 'average'. These requirements are provided by the department managers.
The third layer of requirements are normally not formally documented. These are gleaned by the consultant during 'Water cooler sessions' with the CFO or Directors. These requirements will require significant configurations and use of advanced features of the applications. A consultant who can provide solutions to these requirements will end up delighting the customer.
The final level of requirements are given by CEO. These will relate to strategic aspects of the Organization including Security, Access control and advanced reporting. This is where repeat customers are made.
Most of the implementations remain stuck at second layer.
This article is from my blog.
https://gbeaubouef.wordpress.com/2011/01/09/gather-erp-requirements/
This is an old article, but still I consider is a gem of an article because of its simplicity and practical aspects. There are three different strategies of requirement gathering. They are:
1. Requirements Driven: This is the traditional approach where the consultant sits with the user, listens and documents the requirements. There are three flip-sides to this approach, the requirements gathering lead time will be higher, the user will provide a lot of non-value added requirements and third (not mentioned in the article), the ERP implementation will become a better mousetrap.
2. Solutions Driven: This focuses on the gap business requirements. This approach is popular in Rapid ERP implementations. In this approach the consultant gives the solutions to common business processes. There is a lot of resistance to this approach from the customer since it doesn't consider the customer's specific process requirements
3. Configurations Driven: In this approach, the customer knows their requirements and expect the consultant to configure the same in ERP. This can happen in cases of 'Lift and Shift' that we discussed in the first article.
The best approach is a blend of all the three. Author suggests three iterations of requirement gathering and review. In iteration #1, the customer speaks and consultant listens. Customer should feel that he is being listened to and should be actively engaged with and clarification sought. In iteration #2, consultant leads with a proposed solution giving opportunity to the customer to raise pertinent issues and seek clarifications. In iteration #3, both negotiate with each other on how to handle issues and exceptions. In this iteration the customer may agree to drop a requirement or accept a work around for example.
Nice article. Thank you Mr.Brett Beaubouef...
https://goo.gl/wkzZ6d
The causes of failures of most of the large projects can be traced to missed, ambiguous or mismanaged requirements. Studies have shown that almost 40% of the cause of project failure can be traced to requirement gathering.
Requirement is defined as a statement of a
customers need, a condition of a deliverable, a specified capability, a
characteristic, or a specified quality a system must provide in order to meet
the need and provide value to the end-user. Requirements should
contain attributes that make them unambiguous, verifiable, traceable,
modifiable, usable, consistent, and complete. Requirement gathering
activities or phases for a project include elicitation, analysis and
negotiation,and verification and validation.
Requirement
specification are derived during the elicitation stage, and refined during the
analysis and negotiation stage of the gathering process. Requirement
specification allows the requirement to have tractability throughout the
project life cycle.
Why is requirement elicitation in the early stages of the project cycle important. As per studies, the costs to find and fix a gap increases exponentially as the project life cycle progresses. This is shown in the diagram below.
Finally any requirement management process must be accompanied by a change management process
Great document. Read it. It is worth it.
https://goo.gl/r4J6yg
This is a fascinating article that added a different perspective to my understanding of requirement gathering. The premise of this article is that requirement gathering becomes sub-optimal because the 'givers' of the requirements talk a different language than the 'receivers' of the requirements. The requirements are given in business language where as the same is understood in the language of the software. I have covered this issue in my post on 'Analytical versus Transactional Information' where the users says 'Depot wise trial balance' to mean 'Depot wise profitability' and the consultant understands the requirement literally and configures an extensive system to deliver 'Depot wise trial balance'.
The problem is the integration between 'Business Requirements' and 'Software Requirements'. The new framework proposed by the authors talk of a five step approach where tools like BPMN (Business Process Model and Notation) and UML (Unified Modelling Language) are used extensively. The framework is as follows.
Business practice is converted into requirements in the form of narratives. This will be further converted into Business Analysis using simple BPMN tool. The key stakeholders find it easy to validate these requirements since the tool is simple. The requirements in BPMN is passed to the consultant who maps them in UML and the same is again approved. Once there is a sync between BPMN and UML, the same is configured as solution in ERP.
Note that the languages used by the giver and taker of information are still different, however there is One to One mapping between the two, so the possibility of confusion is averted.
This is an awesome article to end this blog post.
Additional Reading
(https://erp-consultancy.blogspot.com/2013/04/requirement-gathering-how-to.html)
(https://www.cmswire.com/cms/web-cms/8-tips-to-capture-better-requirements-for-your-software-project-012470.php)
(https://www.cio.com/article/2990512/why-capturing-enterprise-software-requirements-is-so-difficult.html)
(https://www.panorama-consulting.com/does-your-erp-requirements-gathering-process-need-a-diet/)
(https://4pm.com/2017/09/18/requirements-gathering-4pm-com-2/)
No comments:
Post a Comment