Consolidated comments inline (to address all replies):
> Ed, I think it would really help if you can explain how 12 people are
> using 100 licenses. Maybe the whole point is that they have 100
> licenses and only have 12 employees, so why pay support on the extra
> 88 licenses? If you can't negotiate with RD on this then cancel the
> 100 user contract and purchase a new 12 user contract, no?
When they were bigger, they had many employees ( >= 80, multiple locations).
Some business reversals and the economic slowdown caused a major contraction
for them. So they had way more licenses at the end than seats. But the real
problem is that, since they're processing and shipping way less than before,
they don't need all the features in the current software.
As you know, adding new features and complexity to accomodate growing
business rules can create whole new departments and new staff. So the owner
is thinking that the software is actually demanding much of the current
staffing requirements. He's worried that in order to "service the
application" properly, the staffing levels are at or near an irreducible
minimum, hence why not throw the whole thing out (and half the staff) and
start from scratch.
Quote:> I think the trick for the end-user is to work smarter, not harder. If
> it takes x minutes to enter an order then cut that down.
He's happy with the processing time for orders and shipping. That's why the
extra staffing seems overkill. He's blaming the "needs of the software" for
the extra employees.
Quote:> a new platform does not in any way guarantee that it will take less
> time in the end to enter the same volume of orders. The answer is to
> fundamentally change the way orders are processed. I know this goes
> against your thinking but I think the answer is to try to automate the
> order entry process. Get their clients to pump orders in via EDI,
> SOAP, web pages, or some other way so that employees don't spend their
> time doing data entry.
My solution is to give him a streamlined menu subset, so that unneeded
structure and behavior can be eliminated; sort of automating away several
> About MS Access: Nope. If you're going to go for another DBMS due to
> costs, then like others, I'd suggest MySQL with a front-end that is
> designed to cut down data entry time. Access doesn't scale and you
> don't want to have to jump into SQL Server as soon as you have Access
> up and overloaded.
He thought of Access because it's a database, and cheap. SO far, not much
more thinking has gone into it, which means he's open to alternatives.
Quote:> It keeps coming back to how they do business, the front-end for data
> entry (re-do it or lose it), and the business rules. I don't think
> this is a DBMS thing based on the info available. If they migrate out
> of MV in order to cut costs then they're still going to need to find a
> new application and suitable business rules. That just runs up
> purchase and/or development costs.
At first it sounded like it was the DBMS costs that were too high. But it's
really the labor cost. It's not exactly 50K divided by 6 employees, but
close. If I can get him to keep the DBMS, and spend a few thousand for a
"streamline rewrite," he may go for it. He's still analyzing.
> More info would help...
> Good Luck in any case.
Thanks everyone for your input. I needed to get this question onto CDP asap,
so I could get some insight, so some details were unavailable first go. At
this point, he may think that a single user solution may work. They already
have offloaded financials to Quickbooks, so only O/E and associated
inventory control and sales reporting are left. I just hate to see another
Pick shop bite the dust.
>> I have a client who process about 300 order per week. Currently
>> running MvBase/NT with probably 100 licensed seats. They say they're
>> spending approximately $50K/year on costs.
>> They are considering dumping the whole ball of wax and putting
>> everything on MS Access. I'm getting more specific cost info now,
>> but I know that they have OE, inventory, reporting, and all the
>> other functionality that goes with distribution. They just can't
>> handle the TCO with their current cash flow.
>> But I can't see them on MS access either. Is there a cheaper Pick
>> solution out there wich would allow them to migrate from Pick to
>> Pick? I believe that going to MS Access would be product-cheap and
>> Thanks for any ideas,