Ray Kroc once said, “the two most important requirements for major success are: First, being in the right place at the right time. And second, doing something about it.”
We see this all the time with organizations. During software development or ERP selection, at one point or another, we have all heard the term “requirements.” What are requirements? Why are they so important? Once you have them, what are you supposed to do with them?
The most condensed answer to this question is: requirements are what an ERP system/implementation or a company must be able to do to perform their jobs.
To simplify things, let’s take software out of the picture. If you were to ask a bricklayer what they need to do their job they might rattle off a list like: bricks, a way to transport bricks to the site, mortar to lay the bricks, a way to transport mortar to the site, a blueprint or reference of what we are building with the bricks. Furthermore, they need a process to determine when the job is done and if the job is finished to specifications.
Notice that in the analogy I never once specified the “how,” only the “what.” During the process of requirements gathering, there is no need to spend precious time on how you want to be able to complete a task. Instead, spend your time on simply completing the task.
Another comparison is the job of a Hollywood screenwriter. A common trap that novice screenwriters fall into is that invariably describing camera angles, music crescendos, lighting motifs and sound effects. This is not their job, their job is to tell a story, the foundation of the entire movie. Without them, you get 90 minutes of bangs, explosions and special effects without any story or characterization that anyone would care about.
SAP vs. Oracle Case Study
SAP and Oracle both invest heavily in cloud technology. However, our client was skeptical about cloud scalability and unsure if the products were mature and proven.
The same holds true for requirements. During the requirements process, it is important to focus on what the software should be able to do, not how. Do not get caught in the trap of “the function key F5 must pull up a screen of orders to be processed”. What we need is a screen of orders to be processed, the F5 key is irrelevant. You may settle on a ERP vendor software package that uses a click to open the screen. Choosing software based on specific points like an F-key that must be pressed is a hard justification. Are you really going to choose the software package on that criteria alone?
Now that we have covered the “what” aspect of requirements gathering, what is the best approach to it? There are horror stories related to how requirement sessions go off the rails, rabbit holes are explored to no end and all active participants are talking about details that have nothing to do with the scheduled functional area. The best counter to this hazard is to follow a proven methodology of requirements gathering that consists of careful consideration to workshop session structure and making sure the subject matter experts and process owners are in the room. In many cases, the subject matter expert knows every detail of the process, but the higher-level intentions of the process are the domain of the process owner.
Next up is mapping the process. This illustrates the process in front of everyone so that nothing is lost. After that, you take the process maps and make them into requirements. For example, looking at a process map we may see: Receive order from website EDI > transfer order to picking > deliver product. We have several requirements for the software such as: the ability to integrate with 3rd party website EDI, the ability to display list of products that need to be picked from the warehouse, the ability to mark products as picked, The ability to transfer picked products to delivery module, the ability to recognize delivery route based on customer delivery address….and so on. Then you will categorize the requirements by process, and in turn by functional area. The requirements can then be delivered to the software developer or vendor to determine if the work can be done or not.
Requirements communicate need. What do you need to do? What does your business need to function? Your business has unique operations and characteristics that set you apart. Don’t let those unique attributes hit the ground because your time was spent talking about what your business doesn’t need. Your business needs to be able to manufacture and deliver products and services to customers. I guarantee that your business doesn’t need the F-key.