Determining the right business solution requires examination of an essential element—which business processes need to be fixed. My organization, a large industrial service and supplies company, recently wanted to replace an archaic Platinum software application used for general accounting and reporting purposes on the back-end only. The goal was to replace manual efforts with front-end automation capabilities, useful management reports, and real-time transaction and processing capabilities. Here, I outlined how we used a team-based approach to examine the issues to be solved by a new technology.

Our next task was to evaluate potential solutions. I’ll explain how we approached the decision-making process as a team and what we learned.

Solutions for a big problem
Once our core team had defined and outlined problematic causes (as described in the previous article), it was time for our team to meet again to outline potential solutions. The solutions column on our data-gathering chart needed to be filled with one or more of the following keys:

  • Technology (TE)
  • Training (TR)
  • Process re-engineering (BPR)
  • External (EX)

Figure A illustrates some typical answers. The core team met after normal working hours and was able to complete the task in two nights.
Figure A


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 B explains our code system.
Figure B


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

Later that week, four documents were created from the data-gathering charts: Technology Solutions, Training Requirements, Process Re-engineering, and External.

The consultant discussed the technology solutions with me, the training requirements with HR, the re-engineering findings with the materials manager, and the external factors and solutions with the CEO. Each member was now responsible for his or her designated area. All core members received copies of each document.

Getting technical with the RFP
Next, it was time to combine the technology findings and the results from the questionnaire. We filtered the technology requirements into two areas:

  • Internal solutions
  • Business application solutions

The business application solution was then built into a request for proposals (RFP). See Figure C.
Figure C


Accounting (continued)

Mandatory – M
Desirable – D
0-5 Highest score – 5

Item
Requirements
Need
Weight
Score
Vendor comments
Cost
 
 		Telephone expense  M 5  
 		 
 		 
 
 		Service department report M  5  
 		 
 		 
 
 		Sales by salesmen  M 5  
 		 
 		 
 
Receivables     
 
 		Ages analysis  M 5  
 		 
 		 
 
 		Daily cash receipts  M 5  
 		 
 		 
 
Payables      
 
 		WIP analysis  M 5  
 		 
 		 
 
 		Entertainment report   M 5  
 		 
 		 
 
 		Gas bills summary  M 5  
 		 
 		 
 
 		Petty cash  M 5  
 		 
 		 

The CEO and the core team reviewed the final document. We drafted a cover letter explaining the RFP and set a deadline. Then the software vendor bidding process began.

The bidders were required to fill in the comments section; this indicated whether their software could provide the requirement. They were also required to fill in the cost column wherever the software could not fill the requirement without additional cost. In some cases, the vendor entered “cannot fulfill” in the comments field, and no cost would be attached: This meant that it was not possible for the vendor.

The core team reviewed the submitted proposals from the various bidding vendors. After deliberating and filtering, we contacted the final accepted bidders and set initial meeting dates. We sent thank-you letters to those vendors that didn’t make it through the review process.

Fighting for the gold
Each vendor demonstrated the capabilities of its software, starting with a general overview and following through fulfillment of the requirements definition.

For each section of the demonstration, relevant departments were brought in to make their markings in the score column of the main table of the RFP. Each section of each demonstration ended with a short Q&A session. Each demonstration ended with a demo of additional features that were not requested as part of the RFP—a vendor sales pitch; we allowed this so that we could view other useful areas of the software. We collected the scorecards before this section started, so that it wouldn’t bias our scoring.

The core team members were part of the entire demonstration, and each kept his or her own score for each deliverable as well. The demands on the core team were high, considering that we had five demonstrations in two weeks. Unfortunately, we didn’t plan for rescheduling or delays. Our consultant wasn’t very flexible when it came to schedules, especially with vendors. He argued that if a vendor couldn’t make the visit at a proposed time when trying to secure a sale, it meant we could expect poor support after we made the purchase. Fortunately, no core team members required any time off during those two weeks. I remember being told that “IT people” cannot get sick—it wasn’t allowed.

Once the demonstrations were completed and the scores were tallied, the final results were sent to the CEO, the decision maker. He called a meeting with the core team, and three vendors were chosen based on cost and ability to deliver requirements. We expected a cost that fit within the budget and a minimum of 90 percent coverage on the requirements definition.

The final stretch home
We called in all the chosen vendors and reviewed their proposals and contractual terms. The final choice was based on the following:

  • Skill set and educational background of the vendors’ implementation teams
  • Length of time in business
  • Reference checks of each vendor (in some cases, we visited client sites)
  • Flexibility of vendor team members
  • Compatibility of vendor team members with internal core team members and my four-member IT team
  • Contractual terms that we could be satisfied with—the terms of agreement contained a clause that required a refund if the vendor couldn’t meet all requirements as stated in the bid
  • Cost: hidden costs, additional costs due to more powerful server, support costs, etc.

Once we chose the vendor, it was time for the real challenge: implementation, training, and employee buy-in.

Implementation overview
The core team and the chosen vendor had a kick-off meeting, during which we discussed the implementation plan and defined roles for the implementation. The vendor made more recommendations on additional hardware and special devices that we could opt to purchase—no harm in the sales pitch. At least we were privy to the latest in backup solutions, redundant servers, and fail-over systems.

At that point, the core team decided to meet every Tuesday for a one-hour status update meeting. During that meeting, we would each report on the status of the assigned tasks for the week. We would discuss any issues, potential issues, or risks and determine possible solutions. We would then review the next week’s assignments and adjourn until the next week.
Figure D


Metrics
Planned vs. actual


Item
Planned
Actual
Budget $1.0 M $0.75 M
RFP preparation 6 weeks 8 weeks
Vendor selection + planning 4 weeks 3 weeks
Training + implementation 2 weeks 4 weeks
Customization + tweaking 4 weeks 6 weeks

Figure D shows an overview of the budgeted and actual time spent on the entire project. The core team considered the project a success, and we all learned some valuable lessons during the effort:

  • A proper methodology is important for attaining the right business solution.
  • Although a consultant may add value to the process, the “true” contributors to the exercise are the employees who will use the software in the end.
  • Involving the relevant staff reduces their fear of change and improves their buy-in to the project and the new software.
  • Always budget extra time for a project, no matter how much planning goes into it; a further word of advice is to include risk management as part of your project planning so you can deal with failures and/or delays.
  • The selection of a package is not an exercise in technology; it is a business exercise. Although I didn’t go into the details of the other portions of the overall exercise (training, re-engineering, internal technological solutions, and external solutions), they all had to be completed. Failure of one section would have a definite effect on another section.
  • The project must have initial senior management buy-in.

These are some of the most important benefits realized after the final implementation:

  • Paper savings: The old system wasn’t capable of exporting reports into Excel like the new system; the old system printed out all pertinent information during end-of-day posting and backup procedures.
  • Reduced burden on accounting staff: Point-of-sales terminals were implemented, and sales transactions were entered at the actual time of sales.
  • Manual back-office procedures (such as manual end-of-day postings from batches to GL checks being written through the software and both the vendor accounts and the GL being updated automatically): In addition, no end-of-day posting procedures were required because the GL is updated in real time and payments on accounts are taken directly into the system and update the A/R customer database and GL in real time.
  • Improved system uptime: The old system had an uptime of greater than 75 percent; the new system approached 100 percent.
  • An easy-to-use interface: Senior management never used the old text-based interface software; with the new software, senior management could run their own reports instead of requesting them from the accounting department.
  • Improved security with the system.
  • Support for remote locations: Remote locations no longer had to send their sales and other information to the head office for data entry and back-office processing.
  • A sturdier backup system and contingency policy.
  • Integrated payroll: Eliminating the old system meant no more maintenance of the Excel spreadsheet and no more manual updates to the payroll accounts.
  • Employee time tracking: The integrated personnel management system allows tracking of overtime, benefits, sick leave, maternity leave, employee history, and much more.
  • Uniform interface: The new system provides an interface with shared real-time data for all aspects of the company at the touch of a button.