|
How To Short List Your Shop Management Software Research In
Two Questions
Choosing a shop management
system is a daunting proposition. There are so many that it
would take years of full time research to evaluate them all.
So... how can you quickly rule out 95% of the whole field, and
get yourself down to a short list of eligible candidates? You
can do this by asking two test questions that are
so fundamental that they must be answered before engaging
in any in-depth research about software functionality. Both
must be answered satisfactorily; it doesn't really matter which
one you ask first. An unsatisfactory answer to either question
is fatal.
Question #1: The DNA Test
Who brought this system into the world, and why?
There are only
3 possible answers to this question
(only one of which is acceptable).
Possible Answer #1: We
want to provide you with a real shop management
system...
because that's what we do - shop management. In fact
it's all that we do, and all that we care about.
The system was
brought into the world as a real shop management system, by a
company that wanted to provide a solid shop management
system, for the purpose of properly and effectively managing a
shop. Shop
management is this company's core competency.
Possible Answer #2: We want you to order lots of parts from distributors
that we have relationships with...
and we're willing to pretend to care about shop
management to make that happen.
The system was
brought into the world as a parts ordering mechanism in disguise
as a shop management system, by a parts manufacturer or
distributor, for the purpose of directing
parts orders back to a
specific parts distributor. Other viewpoints that are reflected
by these systems and those that like them: Parts can be
processed through the system like greased lightening, cost of
parts information be damned. Who cares about that? It'll just
slow us down. Who cares about profit anyway? That'll slow us
down too. Technician time management? What's that? Whatever it
is, it's too cumbersome. Writing purchase orders? Not a chance.
Accounting? That's for accountants.
Possible Answer #3:
We have a hole in our product line
as compared to our primary competition...
and guess what it is? That's
right, you guessed it: shop management. Now how fast can we come
up with something to fill this hole? And by the way, we don't
give two cents about shop management, but we're betting you
won't even notice that because the price will be almost
as attractive as Tyra Banks.
The system was brought into the world to fill a hole
in a product line, by a company who's core product and
competency is really something else completely, for the purpose
of rounding (e.g., they are a data provider). These
functionality of systems have more holes than a storeful of
Crispy Kremes, but the price is definitely right.
Accept
only Answer #1.
Every system on the market will fit neatly into one of these
three categories. And
yes, #1 is the only acceptable answer, even though there are
comparatively few systems that can claim such legitimacy in
their DNA. Answers 2 & 3
clearly indicate self-serving motivation behind the product's
very existence; these are red flag answers and any products that
land in either of these two categories should be eliminated from
further consideration.
Shop
management software is a highly-specialized and highly focused
product that should come from an equally specialized and focused
company. Buying a mission-critical product like this from a
company that was doing a thousand other things and then suddenly
decided to go into shop management because it fills a hole in
the product line or because it will force parts purchases back
to them will result in a product that is lacking in solid shop
management processes.
Worse yet, such a company might
just as suddenly decide to get out of shop management -
quickly as they might have gotten in. The industry has seen this
occur several times.
Test Question #2: The Core Technology Test
What's the
programming language and database?
There are many possible answers to
this question. There are a small number of acceptable answers,
but that in our market (shop management software), most of them
will be unacceptable. And just because you might not be able to
interpret the answer doesn't mean you shouldn't ask. You can
always research it later.
The technology
equivalent of the Pre-Purchase Inspection
Asking this question is a technological parallel to
performing a Pre-Purchase Inspection.
Do you offer this service? Most conscientious shops do. And when
you do, what is the
first thing you want to
know? The structural integrity
of the vehicle,
of course. After all, who
cares what the interior looks like if the car has been hit? And
you can't find that out from a walk around or a road test.
You've got to get the car into the shop, on a lift, and up in
the air, and then and take a slow, careful walk under it with a
drop light to find that out.
Development language criteria
The development environment should be written in a modern,
robust programming language which is provided my a company that
is still in business. The language should be in widespread use,
and should be well-suited for developing networked business
applications. The development community associated with it
should be identifiable and thriving. The development community
for any development language is a delicate ecosystem and must be
well-supported.
Database criteria
The database should be something meant to
handle commercial business applications, where many users are
connected to the database at the same time - simultaneously
making data requests, and writing to the database as well. It
should also be capable of storing large amounts of data (several
hundred megabytes) without becoming unstable. It should be able
to handle considerably more than the largest number of users you
can envision having in your shop. For example, even if you only
envision connecting 5 users or less, a database than can only
handle 5 users is simply not adequate; this would represent an
extremely light-duty database that most likely cannot handle the
load you'll be placing on it. If the database is not adequate,
you have yourself a house of cards.
Examples of undesirable databases:
Microsoft Access (commonly used), Microsoft SQL Server 2005
Express, MS FoxPro, Btrieve (now called Pervasive), Clipper,
anything unrecognizable or home-brewed
Examples of desirable databases:
Progress, Oracle, Informix, Sybase, Borland and DB2
Looking at question #2 in the context of question #1
Systems falling into categories #2 and #3 of Question #1 will
generally fail Question #2 entirely. In other words, systems
brought into the world with primary mission of parts ordering,
or to fill a hole in a product line generally suffer from
technological shortcomings of some sort (hastily thrown
together, written a limiting programming language, based on a
light-duty database engine, etc.).
|
