Determining the right business application requires an in-depth, team-oriented approach. An IT manager outlines the specific approach his organisation used to evaluate business needs that the new solution would address.

When corporate division heads complain about how technology isn't working, or that a change is needed to improve systems, few of the complainers propose solutions or ideas to propel the wanted change. Executive management simply sees an "IT problem".

They may provide a small budget and a mandate--fix the problem and find the perfect package. Or they may decide to hire a "big bucks" consultant to find the "perfect fit" for the organisation. In either scenario, the project rarely makes proper headway, and the resulting system can end up as inefficient as the old one.

CIOs can avoid this all-too-common path by determining what needs to be changed, the best tool to implement the change, and how to effectively manage the risks inherent in change.

In this article, I'll describe how my organisation, a large industrial service and supplies company, initiated its search for a new business application. My company wanted to replace an archaic Platinum software application used for general accounting and reporting purposes on the back end. All transactions were done manually, which was time-consuming and often redundant because the data was eventually plugged into the data program. This system had been in place for five years.

The company wanted front-end automation capabilities, more useful management reports, improved system stability, and real-time transaction and processing capabilities. We started by conducting an investigation to determine the best tool.

Establishing a cross-functional team

The first step was to establish a strong cross-functional team consisting of middle management staff and the CEO and/or an experienced business management consultant (not an IT consultant).

I think the CEO is the better team member choice, since the person in that position needs to understand the business better than anyone. However, in our case, the CEO's time was too constrained, so we hired a business management consultant. The CEO was responsible for choosing the right consultant. The minimum requirements were a master's degree, 15 years of experience in the industry, and at least 10 years as a consultant.

The core team consisted of the consultant, an accountant, the materials manager, the HR manager, and me, the IT manager. We had an initial, general meeting with the core team, the CEO, and a few members of the board. During that meeting, the consultant discussed his proposed approach.

The consultant outlined a time frame for the stages he expected the project to span: investigation, request for proposal (RFP) creation, vendor choice and planning, implementation and training, and tweaking and customisation.

At this meeting, we discussed only general ideas and focused on a simple overview with a proposed budget and ROI. The budget was to be reviewed by the consultant and the CEO at a meeting the next day; the CEO would then seek approval from the board of directors.

After the next board meeting, we received the news that the board had given the project and budget final approval. We contacted the consultant and the project kicked off.

The first core team meeting

• I was responsible for the provision of technical advice and meeting minutes.
• The accountant's role was not immediate, but he was scheduled to create the chart of accounts and back-office procedures.
• The materials manager was responsible for capturing the existing business processes and for recording any new business processes required.
• The HR manager's role was also not immediate, but she was brought on board early enough to ensure proper understanding of the exercise, so that she could begin developing a training plan. Lack of training is one of the most common failure points of a new implementation.
• The consultant defined his role as the facilitator.

The first exercise involved data gathering from each functional business unit. The materials manager, the consultant, and I were responsible for this task.

The consultant distributed a questionnaire for review and explained some basic principles of systems analysis. We planned to distribute the questionnaires to each department's manager and set up meetings with key members and their managers. These meetings would allow us to gather all pertinent data to create the RFP.

The key questions were:

• What do you do at this company? What is the purpose of your job?
• What are the problems you're experiencing that affect the efficiency of your job?
• What information do you need to do your job properly?
• What form does the information come in? Can it be improved?
• Who/what department does your information come from? Is it delivered on time?
• What do you do with the information you receive?
• Is this an integral part of achieving your objective?
• What reports do you produce, and who are the users of these reports?
• Do you think users of your reports are satisfied with them? Are they always asking for additional information?
• What hardware/software do you use?
• Are you satisfied with the way that hardware/software improves your efficiency?

The information-gathering process

The materials manager distributed the questionnaire and a tentative project schedule. Managers were asked to meet with the materials manager to finalise meeting dates and to clarify questions that the questionnaire may have created. Forty out of almost 100 employees were to be interviewed for the process.

At the beginning of each meeting, the employees handed in their questionnaires and the consultant reviewed them. The consultant then asked the questions in a different format, to ensure that all bases were covered.

Our consultant demonstrated a unique approach. He asked: "What reports do you use and who are the users of these reports?" The consultant then drew a diagram, as shown in Figure A, and asked the employees to write the departments/business units that "constantly nagged them" for information in the rectangular blocks. Employees were asked to name the departments that they constantly visited to get information. These were marked in the decision-type boxes.

Employees were then asked to think of all the information that they needed from each department. This information was entered by each department's box. Employees were asked whether the information came on time, late, too late, or not at all, and what else they thought they needed from each department, but were unable to get, in other words, their wish list.

Figure A

Getting procedures right

The total exercise was completed two weeks past the projected three-week time frame, but we honestly never expected to get through it so quickly.

Milestone 1

After all the information was gathered, the materials manager was responsible for writing up all the "requirements" (as they were now called) on a flip chart, as illustrated in Figure B.

Planning meetings

An all-day Saturday meeting was called that involved all the players that were part of the exercise. Besides Sunday, this was the only day we could get a full six-hour commitment from busy business unit managers and sales staff.

We taped the flip charts on the walls, and teams filled in causes and effects using codes, as shown in Figure C.

Getting answers

The blue type in the cells in Figure B illustrates the typical answers for each column. Teams rotated, so that one team would fill in the causes for one group of problems and another would fill in the effects.

After the day was over, everyone felt a sense of accomplishment; employees were able to acknowledge weaknesses in the systems that they had followed for years. This way, they were pointing out problems, and we hoped they would embrace the changes more easily because they would be aware of the possible benefits. One of the mistakes many firms make is not involving the users in the preparation for change.

Stay tuned for the second part of this series, in which I’ll explain how we evaluated potential solutions and ultimately chose a new product.

Figure B

Cause Effect Findings Solutions     (a) Suppliers   EX OE Not sticking to promised delivery date EX     No communication on change of delivery date       Slow response to request for information       Invoices not received on time       Company still communicating via faxes       (b) Product Manager/Salesmen       Missing information on foreign requisition form       Duplication of work by product managers and purchasing department   MA OE Placing verbal orders with suppliers TE     Setting unrealistic delivery dates   TE DU Duplication in order follow-ups TE     Lack of communication re. Setting realistic delivery dates, changes, and updates on products, etc.   LA $C Not updating purchasing department on revised information for purchase orders TE; BPR     (c) Freight Forwarders       Lack of communication on goods received in their warehouse

.
Figure C

Key Causes Effect CO - Control (lack of)   DE - Deficiencies CU - Customer satisfaction DU - Duplication EX - External LA - lack of timely information IC - Internal customers OE - Operations efficiency MA - Manual MI - Management inefficiencies PA - Superfluous paper SE - Security PE - Personnel SP - Space UR - Untimely reporting UU - Under utilization TE - Technology TR - Training $C - Cost to company $F - No cash flow management CC - Communication (lack of)   LI - Lack of information DI - Data integrity

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.