Three ERP requirements gathering best practices
There’s a lot of discussion about requirement-setting these days, particularly when it comes to selecting ERP platforms. From a senior management perspective, many executives fail to accept today’s necessary technological dependencies, and simply assume that just as long as their enterprise systems blink, make the right noises every day, and deliver tons of reports everything will be okay – right?
Well, here’s the news; that assertion is plain wrong, since the fewer hours spent on understanding how these systems work in concert with your workforce operating patterns, the weaker your competitive position will be sooner rather than later. Oh, I know; executives are busy people; but clearly establishing and understanding who, what and how your company does what it does every day, is really the most important job you have, aside from fostering bottom-line revenues of course.
This means that smart executives intrinsically involve themselves whenever a large-scale enterprise system is being considered, and this particularly applies to administrative, operational, and technical requirements that are likely to direct the movement and manipulation of every data record in a particular enterprise. So, let’s illuminate a couple of requirements best practice management scenarios to see if we can help those in the executive suite become more than just a group of willing followers but a group of ‘involved doers’ too.
Three ERP requirements gathering best practices
1. Be involved
Many executives indirectly delegate lower-tier managers to processes relating to requirements gathering, however, while this may have worked in the past, the approach is no longer prudent even at the top of the food chain. There are a couple of simple reasons for this; 1) to be able to be completely familiar with how an ERP platform will involve itself in terms of various workforce impacts; and 2) gain an opportunity to directly interact with a lower management cadre, thereby ensuring that the boss’ goals can be made crystal clear.
For example, when I served as a CIO, my organizational up-chains were usually COOs, followed by CEOs. In both cases, although I was typically tasked with activating one or more requirement-gathering efforts, I always encouraged both of those ‘executive partners’ to take part in my start-to-finish tech requirements.
Sometimes it took considerable effort to get my seniors to pay attention to what I was suggesting or even read in work materials, but in all cases, they always came away from those experiences better prepared and less jittery down the road, and much less prone to being critical of any final results my tech teams may have created at a detailed requirements level.
2. Read and respond quickly
As I mentioned earlier, it is accepted that senior managers are busy people. Nevertheless, given today’s operating tendencies toward ‘cloud-everything’ so as a practical matter, senior folks knowing that everything relating to their operational lifeblood is likely to end ‘up there’ tends to offer some remote anxiety right from the start.
Consequently, when developing cloud-based ERP requirements, the goal should be to first understand and accept the senior tier’s intrinsic concerns, then follow up by constantly assuaging any concerns by delivering constant information well-beyond what is expected from typical WIP status. In this event, this usually takes the form of a reciprocal process where the requirements team leader delivers meaningful status, and in turn, senior managers read the materials and respond directly, either querying for more information, or in effect, signing off on the results of the proffered set of data points.
The goal is to create a direct communications continuum that offers a clearly stated process supported by regular goal measurement, while also establishing confidence in all the folks involved.
3. Reduce conflicts between senior management and shop level
Another way to set the requirements scene more effective is to encourage senior managers to be ‘seen in and about’ workforce areas as part of a requirements effort. This allows two central advantages; 1) the experience allows workers to gain a sense of how confident senior people are about the premise of turning their operational world upside down; and 2) the process allows senior managers an opportunity to arbitrate on various elements relating to the requirements evolution, thereby de-conflicting any issues sooner rather than later when decisions may or may not have been ‘set in stone.’
Frankly, the simple truth is that even the most granular ERP requirement, signed off by the CEO and everyone else at the top of the organizational pyramid won’t matter if the enterprise workforce isn’t on board. So, if you miss this step and fail to take your workers into account from the outset, you are just asking for very expensive trouble sooner rather than later.
So there you go; three best practices scenarios for you folks to chew on. Obviously, this particular article is generally tailored to an executive audience, although remember that the head points while the body follows. So be heads up by thinking smart when it comes to requirements, then translate that ‘smartness’ downward all the way to the loading dock.
Featured white papers
70 features to look for in your next ERP
A comprehensive guide to help you identify requirements for your ERP selectionDownload
ERP Software Pricing Guide
Get your comprehensive guide to the cost of ERP softwareDownload
60-Step ERP Selection Checklist
Get the comprehensive checklist for your ERP selection projectDownload
Evaluating the responses from your invitation to tender
How to evaluate and score your ITT responses
The invitation to tender process for ERP
What should be included in your ERP ITT
Considering specialty ERP requirements during selection
What industries require specialist ERP features and why they're useful during selection