As I briefly mentioned in a previous post Six Steps for Executing Successful ERP Requirements Workshops, there are many ways to document an ERP requirements workshop. I stated that the common theme must be to capture an accurate and thorough description of what’s being discussed during the workshop. Ability to dissect a conversation down to an individual functional requirement is also a key factor. In this post, I want to elaborate on the various methods, which can be used to document the project.
Requirements must be defined at various stages of the ERP project. The stage of the project dictates the level of detail that must be captured. For example, during the ERP software selection process it’s necessary to capture requirements at a higher level of detail than during actual ERP implementation. Whereas the level of detail needed to write computer code for a new software program, requires an even higher level of detail.
However, the reoccurring theme is to capture the critical component of a given business process and convert that discussion point into a requirement at the appropriate level of detail.
During a high-level requirements definition workshop, there are a number of tools and techniques, which can and should be employed in order to reduce the risk of missing a key requirement.
- Actor Map – defines the relationships among the actors in the actor table.
- Actor Table – Defines the roles played by people and things that will interact directly.
- Domain Model – Defines groups of information that must be stored in the ERP system and the relationships among the groups.
- Use Cases – Describe the major functions that the ERP software will perform for external actors, and also the goals that the ERP system achieves for those actors along the way.
- Use Case Map – illustrates the predecessor and successor relationship among use cases.
When documenting the workshop activities, a spreadsheet can greatly assist in organizing each final requirement specification by functional area, which will aid in the final presentation the requirements in the forms mentioned above.
During some of my workshops, with the spreadsheet open on a screen for the group to see, I begin by discussing the pain points of the group’s functional area. This gets the conversation rolling and allows the group to open up about their needs and desires. It also allows me to capture the actors for that area and begin creating a domain model. Within in each functional area, I then ask pointed questions about different subjects within their area. This allows me to capture the detail necessary to produce use cases and a use case map.
Finally, the information captured is usually in a very rough form. It is much more important to capture the essence of the information being presented by the group, than it is to record that information in a formal, grammatically correct and stylish form. The cleanup of the workshop notes can then be completed separately and after the requirements workshop is completed.
Click to learn more about the software selection methodology used within our ERP selection projects.
Blog entry written by Kevin Cahill, an ERP Consultant at Panorama Consulting Group.