Out with the old: replacing a fleet management system.

An old fleet management system can result in lost time and lost money, but implementing a new system should be done carefully and with plenty of feedback from the field.

Like well-used family cars, many fleet management systems now running across the country are starting to show their age.

Demands for greater efficiency, cost control and accountability lead to newer and better systems, but the challenge is avoiding the detours and dead ends that seem to plague implementation.

Asking the right questions is the best place to start when making system changes. This will help analyze needs and clarify functional requirements. A team should concentrate on why a new system is needed rather than what the new system should do. This will keep everyone focused on the bigger picture, i.e., the operational and economic improvements not available with the current system.

Making the “why” more important than the “what” is valuable for two reasons: it forces people to focus on those areas with the greatest return, and it creates unity by showing how the new system will benefit everyone.

GET EVERYONE INVOLVED

Asking other fleet managers to share their experiences also can help to avoid danger, and it can illustrate how other cities and counties are using modern fleet systems to reduce costs and work more effectively.

“Implementing a fleet management system should be driven from the bottom up, not the top down,” says Marc West, fleet coordinator with Denver Water. “Look at what your mechanics are doing now and how you are tracking it, and ask if there’s a better way. Of course, you need upper management support and input, but the front-line people will be using the system, and they should be assigned to the project team designing the functional requirements.”

Steve Moody, a software systems analyst for the city of Tulsa, Okla., agrees. “You’ve got to involve the `little people’ from the beginning, or you’ll end up with a system that [only] kind of works in the field.”

That philosophy worked for the Vermont Agency of Transportation (VAT). “At the time we installed our fleet system, another department was also installing a new system, but that group had a narrow focus with little input from the end users in the planning stages,” says VAT Fleet Manager George Combes. “With a lot of hard work, we had our fleet system running in four months and, by year’s end, it was totally functional at all our garages. The other group was on-line before us, but they’re now looking at as much as three years to get their system to function properly.”

Implementing a fleet system requires a strongly committed project leader with a clear set of goals to accomplish; the fleet manager should have control and assume the responsibility to keep things on track. “The fleet department should drive the project,” West says, “but the teamwork and cooperation of other departments is critical to success.”

This involves good communication and cooperation between the various departments. When communication breaks down, any number of expensive problems can occur. For example, one city’s data processing department dictated the brand of hand-held bar code devices the fleet had to use, simply because it already was in use at another city department. It turned out the readers were totally useless in a fleet environment, and $40,000 was wasted in the process.

“It’s important to justify not only the expense of a new system, but why you’re asking people to change procedure,” says Jim Dormer, fleet manager for the city of Lincoln, Neb. “If you get everyone involved early, it’s a lot easier to get agreement and create a team spirit.”

The makeup of the project team is key. Don Broadsword, a 24-year veteran in fleet management with Spokane County, Wash., recommends going two or three levels deep into the organization, with people from finance, data processing, operations and fleets being assigned to the team.

“First, I always educated my departments about the latest state-of-the-art systems capabilities, so they understood where they could benefit from new technology,” Broadsword says. “Then we picked a team and told members to develop an implementation plan that would meet the objectives of upper management. And we told them to disregard the way we do things today.”

While teamwork is a critical intangible element, the implementation plan should be solid and substantial.

“Make sure every important item is in the plan,” Combes says. “Conduct a thorough analysis of needs and then identify the primary and `must have’ features so the final system will give you the benefits you want to achieve. Don’t worry about the `nice-to-have’ features, and steer away from the bells and whistles.”

A plan should cover the five most basic activities in a new system implementation: hardware, software, data conversion/loading, documentation and training. There may be anywhere from 500 to 5,000 individual steps, and each step should be coordinated by a project leader. If the plan sits on someone’s desk gathering dust, there will be problems.

Be realistic, and most importantly, do not deviate from the plan or get sidetracked. “Most of the bumpy roads are created in-house when one department wants a module changed and another wants something entirely different,” Moody says. He adds these differences should be ironed out before implementation.

Broadsword believes in prioritizing needs, as opposed to bringing the system up all at once. “I start with work flow and shop scheduling,” he says. “If you start all at once, the amount of information is overwhelming.”

NO SHORT CUTS

Having adequate resources for the implementation also is important. Most managers either underestimate the amount of work involved or allocate too much manpower at the beginning and not enough at the end. “I implemented our system with four key people,” Combes says, “and they were averaging 65-70 hours per week for almost five months. In retrospect, I should have had more people assigned to the project.”

If a fleet manager purchases a new fleet system from a software vendor, the packaged system should run with vendor specifications for at least a year before any major modifications or customizations are made.

“You need some time to see how the data you put in comes back out,” says Lincoln’s Dormer. “I wouldn’t touch it in the first year until I was more familiar with it, and then I would get with the people who developed the system.”

Taking short cuts can be just as dangerous to a smooth implementation. For example, one main objective in a fleet system is to have the system automatically charge each department for the repairs to the vehicles it uses. However, some fleets are so anxious to get their system up and running, they do not take the time to set up these individual departmental accounts. Instead, they create a generic department and charge all repairs to this “dummy” account. The system will run this way, but at the end of the month it is difficult to assign charges to the appropriate departments — all because of the short cut.

Short cuts taken in the training program will put an implementation in the slow lane every time. Mechanics and parts people are the bedrock of a fleet system and a successful implementation depends on their acceptance, motivation and training. Getting them involved early will gain their support and increase their motivation, but only training will build their competence.

“Training is most important,” West says. “Our data is as accurate as what is put into the system. If someone’s not putting it in right, we have a training issue or an attitude problem we need to address.”

Training extends to all the other departments and front-line people using the system. “As soon as we purchased our system, we brought the project team together and showed them how their procedures would be changing because of the system,” Broadsword says. “Then they went back to their departments and trained their co-workers.”

Unfortunately, if people are not trained to do what is right, they will fall back and do what works. This is especially true for mechanics who may be confronting computer technology for the first time. Imagine sitting at a terminal that is asking for specific information and not knowing what to do. Instead of entering the correct information, the mechanic cleverly figures out that by hitting the number and return keys enough times, the system will let him proceed.

HOLD VENDORS TO THEIR WORD

Every fleet manager has a healthy skepticism about the promises made by software vendors. Dormer’s advice is simple: “Don’t purchase any package unless the vendor can prove the system has the functionality you were promised.”

“Buying a package that has to be modified extensively to fit is just going to cause major problems throughout the system’s lifecycle for you and the vendor,” Moody says. “If, for instance, your platform is the oddball of the majority of the client base the vendor supports, expect to experience problems every time a new release or enhancement is distributed to the client base.”

Many fleet managers feel the latest systems are so complex that it does not pay to build in-house. “It’s better left to the people who specialize in developing fleet systems,” Dormer says.

After the sale, make the vendor part of the team and maximize its expertise, resources and support. “When evaluating packaged systems, it’s important to find a vendor that will work best with you,” Combes says. “And make that part of your RFP evaluation.”

Ultimately, a successful implementation requires the teamwork and cooperation of everyone involved in the project. To get started on the right path, the project leader must justify not only the expense of a new system but the need to change internal procedures as well. Getting people to focus on the operational and economic benefits a new system will bring to the organization will make the job easier for everyone.

Jim Paulits is president of Control Software, Wayne, Pa.