Defining the requirements of software is where a company sets the expectations of the software and specifies how it is to function in specific circumstances. This should not be the initial attempt at this process. As part of the package selection process, the broad specifications of the software should have already been defined and used to evaluate and ensure that the selected software is the best fit for your company. In the requirements definition task, you should be expanding and extending the Request For Proposal (RFP) with more details, examples, and specificity. If you appear to be starting from scratch and are handed a blank sheet of paper, be afraid, be very afraid.
typified with today's ERP software, applications have soft controls, switches,
and settings to determine how they function. Additionally, there are fields
with variable meanings and purposes. Determining the settings and field values
are the deliverables from the requirements definition task. This task consists
of the As Is, To Be, and Gap Analysis phases. As depicted below, a progression
through these phases should provide users with a clear vision on the operation
of the software.
As we will see later, the typical sequence of these phases is As Is, To Be, and, then, the Gap Analysis. The software that you purchased acts a bridge to get you all or part of the way to the To Be environment. The Gap Analysis will determine how much weight this bridge can accommodate. We will discuss each phase in more detail, indicating the approach, deliverables, and potential speed bumps.
As Is Phase
As its name suggests, in the As Is phase we are documenting the current practices, methodologies, and procedures of the business. Users frequently want to bypass this phase as being unnecessary. This would be a mistake. Complaints like "What value is there in knowing how things were done yesterday?" or "Let's gets started on re-designing the future" are all too common. Instead, once getting pass these objections, users can be heard to say "I was just doing it that way because I thought you needed it that way," "I could have saved you time by doing that way", or, my personal favorite, "You mean that I spend hours preparing that report and you throw it away."
starting this phase, if existing documentation or flowcharts are available,
this information can be put to good use. However, the currency of this information
must be validated. Regardless, and assuming on the availability of the process
experts, multiple and iterative "white board" sessions are a valuable technique
to flush out the process flows. For example, in the manufacturing process, the
experts would describe:
How are raw materials allocated
How are resources selected and scheduled
How is the routing determined
How are yields calculated and variances handled
How is production reported
How is/are ..
As the experts go through the flows, questions are dealt with and issues are addressed. The natural tendency is to drift into a discussion on how things should be done. This should be avoided or discouraged else you will miss the target of the exercise, namely a validated understanding of how things are done today.
Typically, you will have engaged consultants from the package vendor to assist in implementation and training. The As Is phase is an excellent opportunity to bring the consultants up to speed on your company's business and practices. While the consultant's role will be more of a passive nature in this phase, their contributions and activities will increase significantly in the next two phases.
Finally, it is beneficial for the entire project team to see the final version of all of the process flows. This could mark the start of breaking down of the barriers that may exist between departments and eliminate the tunnel vision that may have infected the organization. If not eliminated, these obstructions will become more contentious in an integrated ERP or CRM environments.
To Be Phase
In the To Be phase, you get a chance to play king or queen for the day. As if you owned the company, you can legitimately ask, "How should things be done?" This may be a little farfetched but you clearly should think outside the box. Using the As Is documentation to identify the bottlenecks and obstacles to making or increasing profits, you now decide how to eliminate or, at least, minimize them.
The biggest problem encountered in this phase is that project teams and users go hog wild. Let's face it; you are not painting a picture starting with a blank canvas. You already have a charcoal outline in terms of the solution provided by the package software that has been selected. You still need to stay within the lines and, as with colors, ensure that the requirements blend and integrate with each other. In this phase, you expect the consultant to play an active role in channeling ideas and improvements that can be best satisfied by the selected package. While not to suggest that creativity be stifled, the reality of the situation is that decisions have been made and contracts have been signed. Unless you are prepared to, or even can, undo the selection process, you need to keep a tight reign on the To Be phase.
Another potential problem is a company that states that it will rely solely on the best practices of the software. This is rarely realistic or practical. Taking this misguided approach in the To Be phase will result in problems surfacing when the software is being piloted. Take the time and perform the due diligence now to anticipate the future needs of your company.
Gap Analysis Phase
far you know: (1) what you are doing today via the As Is and (2) what you want
to do going forward via the To Be. Now, in the Gap Analysis, you will determine
how far down the road the selected software will take you to your To Be state
and, more importantly, the sections of roadway missing or under serious construction.
Having identified these gaps, there are three alternatives to filling them:
Change current practices to eliminate the gap
Use the best practices of the software and associated procedures
Enhance the package so that it conforms to your business practices
first two alternatives are the least costly and troublesome and, to be candid,
make the most of your investment in the software. The enhancement alternative
can have long-term impact in terms of costs and support. As Olin Thompson stated
in his article on software modifications, Should
You Modify an Application Product, "Are modifications bad? The answer is
yes." A good rule of thumb is that an enhancement today will cost an additional
20% each time the enhancement has to be retrofitted to a new release. Assuming
that the initial cost of enhancement was $50,000 and at least one new release
or service pack is issued each year, over the 5-year period the true cost of
the enhancement is $100,000. Consequently, when determining the cost/benefit,
ROI, or payback period, you need to consider the total cost of the enhancement.
A useful control technique regarding enhancements is to assign budgetary responsibility for enhancements to each user department. In so doing, departments are more adapt to control themselves as to the necessity of an enhancement
Perhaps an example will illustrate how the As Is, To Be, and Gap Analysis phases can work together. Assume that your company's current business practice entails utilizing a factor for its receivables. This becomes apparent when the flow is diagramed on the "white board" during the As Is. However, going forward and to reduce the costs of outside services, the company intends on establishing separate credit terms and limits and finance orders internally. This requirement was outlined by both Vice Presidents of Finance and Customer Service during your To Be discussions and interviews. In the Gap Analysis, you confirmed with the consultants that the desired credit terms processing is a standard feature of the package. However, factoring is not part of the standard functionality. The price tag for enhancing the package to accommodate factoring is estimated to be $125,000 or $250,000 over a 5-year period. Since the intent to phase out factoring altogether, the recommendation is to handle factoring offline and avoid the expense of the enhancement.
You might think that the above scenario is just a simple example to illustrate a point. Simple, yes, but taken from a real project. By involving all concerned parties in the process, the rationale for the decision was understood and a consensus was obtained.
importance of correctly defining the requirements cannot be overstated. Following
a logical and deliberate path will help ensure that you will avoid any detours,
maneuver through obstacles, and achieve the stated objectives.
the sequence of phases discussed in this article will encourage the full participation
of the project team, users, and executive management and increase the overall
confidence in the software. If done correctly, you will be surprised by what
you will learn and you will be able to balance all of those
J. Strub has extensive experience as a manager and senior consultant
in planning and executing ERP projects for manufacturing and distribution systems
for large to medium-size companies in the food & beverage, chemical, and CPG
process industries. Additionally, Mr. Strub was a consultant and Information
Systems Auditor with PricewaterhouseCoopers and an applications
development and support manager for a Fortune 100 company.
can be reached at JoeStrub@writecompanyplus.com.