Renting and Buying Cars and What We Can Learn About ERP Buying

Recently, on a vacation, I rented a car. Back at work, we have been helping various municipalities purchase new ERP systems. So, as I drove my kid to baseball games in the Arizona heat, I started thinking about these two things and how perhaps they should be more similar than they are. Look, in my defence, it was really, really hot.

When you rent a car, you get a few options, economy, mid-sized, SUV, luxury, van, truck—and so on, but not many more than that.

They don't ask you if you want four wheels, if you want seats, or a windshield, an engine, or brakes. That's just assumed, it's unnecessary. Of course, it might have been different in 1925, but today all vehicles have those features, so you don't need to ask for them.

You do need to decide what you will be using the vehicle for: moving Grandma's furniture? You might need a truck. Ferrying a football team to practices and games? You might need a van or large SUV. Cruising in California with your new boyfriend? Perhaps a two-seater convertible.

But of course you don't need to remind them that you need windshield wipers or lights on the vehicle. That's understood.

The idea here is that when you are buying a new ERP, you also don't need to spec every little thing. You don't need to specify how GL works or the details of everything that happens in the system. Every system can process an invoice, track the GL, do journal entries, set a budget, provide actuals versus budget reports.

What you need to figure out is what you are going to use it for and what your specific, idiosyncratic needs are: Is library in or out? Will you use it for utility billing? Do you have an applicant tracking system already? Will it interface with the GIS?

We understand that everyone wants to be careful and comprehensive, and that your peer municipality put out a spreadsheet with 1,800 rows and that gives them confidence that they have nailed their requirements.

But the reality is that the 1,800-row spreadsheet is horrible for vendors to complete (and they are using AI and other tools to automatically complete their responses), and it's terrible for evaluators to understand or effectively evaluate.

Worse, it gives you a sense of comprehensiveness that isn't real. You've probably missed more than 1,800 requirements in your spec if you wanted to spec everything at the same level and no one really has the energy to review every line.

We see a lot of municipalities put a lot of effort into "the requirements." We are not arguing that you do not need to spend time reviewing and discussing and getting straight on what you need, just that the 1,800-row spreadsheet is perhaps not the optimal output from that.

We've been developing an alternative approach, using descriptions and a smaller set of specifics for contract commitment that we think is a better way and we're working with clients now to apply the improved method.

Buying over Renting

Now, Ben, you might say, renting a car is very different from buying your own car.

When you are renting, you need the basics but perhaps it doesn't need to be as "good" (however you define that) as your daily driver. This is absolutely true. Although the Hyundai had almost a one-to-one match of features to the Volvo, it just isn't quite as "nice" as imperceptible and personal as that is.

So let's think now of the car-buying process.

When I want to buy a car, I am daydreaming about all the options, all the cars I ever wanted since I was a kid.

I make a big list of all the cars I could desire: Porsche, Range Rover, Rivian, F150, Bronco, Ranger. The list will get way too long.

Then I slowly whittle that list down based on my priorities, practicality, reality, affordability.

Perhaps with the price of gas going through the roof, I don't want a truck. Perhaps I need an EV. Perhaps with kids leaving home, I don't need as big a vehicle as I used to have.

So our long list is getting shorter

Next I am into testing and figuring out what's right for me. Off to dealerships for test drives, checking that everyone fits, that the vehicles on the list meet our needs as a family and get me excited. Slowly, a few more fall off the list.

Now we're down to one, two, or three that you would like to buy.

So now we are in negotiation stage. What price will they give you? Is there any wiggle room? What extras will they throw in? Can you jump up a spec level for the same price? Will they throw in a service plan? Can you get an extended warranty added?

Today, pretty much all vendors and all vehicles have all features if you are willing to pay for them. My rental car had lane assist, CarPlay...

But some won't have the features that you want, so they drop off the list.

What Is of Value to Your Organization

There is a question here of the value of "nice." If we are trying to make user experience good, nice has value.

There was a time where we provided users with Android phones because they had all the same features and were cheaper. Increasingly we offer iPhones to users as part of a CYOD program because they are nicer.

Apple Macs are more expensive, and depending on your perspective, nicer. But municipalities in the main continue to provide users with Windows-based laptops and PCs. In fact, numerous studies have shown that Macs hold their value and thus the cost of ownership is lower than a cheaper comparable device.

In the UK, police departments buy BMWs and Volvos and other vehicles considered luxury vehicles. They do that for the same reason, they retain their value better, and thus the TCO goes down.

Does nice have value in the municipal marketplace? Are we willing to pay for nice? Are we willing to pay for a better staff experience in the ERP?

When GIS comes up in municipalities, the conversation usually starts with maps.

That’s fine. That’s where it begins.

But the municipalities getting real value aren’t focused on the map. They’re focused on what it helps them decide.

That’s the shift.

Previous
Previous

5 Ways Municipalities Are Using GIS to Make Better Decisions

Next
Next

ERP Is an Organizational Decision, Not a Technology Decision