Switch from MvBase to MS Access?

Switch from MvBase to MS Access?

Post by jala » Sun, 27 Jul 2003 22:34:49



Quote:

> What we need is a group of capable people to start an open source pick
> database product.  I'm sure that eventually you could easily convert
> most everyone already on linux implementations of their commerical
> linux based pick database to it:  if it was of quality/compatible.   A
> business of strickly maintenance and development: allowing contracts /
> pay per incident.  Hmmm.  That would be cool.

> -Adam

  There is a wonderful project that's been underway called Maverick
  take a look at http://www.maverick-dbms.org/ for more. Not far from
  rev 1.0.

  jal

 
 
 

Switch from MvBase to MS Access?

Post by Ed Sheeha » Mon, 28 Jul 2003 01:30:40


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.

Switching to

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
employees.

Quote:

> 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.

Quote:> More info would help...
> Good Luck in any case.

> Tony

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.

Ed


>> Gang,

>> 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
>> labor-expensive.

>> Thanks for any ideas,

>> Ed


 
 
 

Switch from MvBase to MS Access?

Post by Ross Ferr » Mon, 28 Jul 2003 22:59:17


Could also be "Application Software Maintenance Costs" - if the guy
had a 100 user system, chances are the application vendor is still
charging at that rate --> 1st step would to be reduce seat count for
mvBASE and the application ..... bearing in mind of course that he may
have to re-purchase these seats when things pick up !

> The whole thing sounds suspect.  How does one get the support cost of
> a Mv/base application to $50,000?  The only thought I have is that
> there must be an Employee cost included there, or a consultant is
> getting a bunch of money from them.

> If the cost is an employee, this charge will not go away, and may even
> go up.

> Secondly, they must be talking about going to a ACCESS based front end
> application with a SQL Server backend.  As another poster stated the
> Access Database is not able to handle any type of real load, it is
> primarily a single user database.

> Finally, a Access and/or VB front end application is going to possible
> require new hardware on the client ends.  Old machines will not be
> able to run a Gui app quickly.

> - Patrick

 
 
 

Switch from MvBase to MS Access?

Post by Ross Ferr » Mon, 28 Jul 2003 23:02:31


That would be MaVerick - written in Java & "pluggable" backend databases !

Quote:> What we need is a group of capable people to start an open source pick
> database product.  I'm sure that eventually you could easily convert
> most everyone already on linux implementations of their commerical
> linux based pick database to it:  if it was of quality/compatible.   A
> business of strickly maintenance and development: allowing contracts /
> pay per incident.  Hmmm.  That would be cool.

> -Adam

 
 
 

Switch from MvBase to MS Access?

Post by ashel.. » Wed, 30 Jul 2003 02:38:34


I'm not sure exactly how much we're paying and i'm definately not in a
position to discuss it publicly.  but we are a 425 seat license on d3
with a p660 on aix.  I bet if one were to add up the costs it'd be up
there.

-Adam

On Fri, 25 Jul 2003 20:31:54 -0700, "Homer L. Hazel"


>ashelley - you say you are not surprised by a Raining Database
>that costs $50,000 per year for support.  Man, I'd like to be able
>to work at a site like that.  Most of my clients balk at paying the
>$2,000 or $3,000 maintenance fee Raining Data charges.  My clients
>generally range from 20 to 30 users and trust me, I'm not making anywhere
>near 50,000 from any of them.  I just don't see how a Raining Data system
>can generate an application cost of $50,000 per year for only 6 employees.

>Larry Hazel



>> I agree with you 100%.  When i first read the post it sounded as if
>> the application was costing him 50,000 a year, which wouldn't surprise
>> me if you are running an application running on a RD database
>> platform.

><snip>

 
 
 

Switch from MvBase to MS Access?

Post by ashel.. » Wed, 30 Jul 2003 02:53:27


All I can say is wow, good job.

I haven't installed it and checked it out yet but this is something
that hopefully one day it will put commericial implementations in
their place.  I can definately see, once a stable release is out: if
the required performance/functionality is all there it would be great
for VARS to offer a discounted version of their apps without the
overhead of expensive seats.

Wow.

-Adam


Quote:

>> What we need is a group of capable people to start an open source pick
>> database product.  I'm sure that eventually you could easily convert
>> most everyone already on linux implementations of their commerical
>> linux based pick database to it:  if it was of quality/compatible.   A
>> business of strickly maintenance and development: allowing contracts /
>> pay per incident.  Hmmm.  That would be cool.

>> -Adam

>  There is a wonderful project that's been underway called Maverick
>  take a look at http://www.maverick-dbms.org/ for more. Not far from
>  rev 1.0.

>  jal

 
 
 

Switch from MvBase to MS Access?

Post by Ron Whit » Wed, 30 Jul 2003 05:46:11


If you are running green screen you might give Ladybridge a look.
They have a database that is basically a stripped down UniVerse.
It doesn't have callhttp or several other features of UniVerse but
it also doesn't have the high cost of UniVerse.  It probably wouldn't
be too difficult to convert your apps to the platform.  Have a look
at http://www.ladybridge.com/qm.htm.

Ron White


> Gang,

> 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 labor-expensive.

> Thanks for any ideas,

> Ed

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
 
 
 

Switch from MvBase to MS Access?

Post by Tony Gravagn » Wed, 30 Jul 2003 07:12:18



>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.

Could you share an example of the "needs of the software"?  I'm
wondering how established Pick software can consume so many resources
(granted, 50k/6 people).  If their development costs are high in an
established site then maybe they need to re-evaluate "needs" vs
"wants" on a per-item basis.

Compared to my original post, I'll swing the other way on this now.
If they're trying to add complexity to the software and the costs are
going to cause the software to get tossed as a result, by all means
reduce the complexity!  The question comes back to what are they
trying to change in the older software that new software is expected
to provide?

Tony

"Beware of the young doctor and the old barber."
- Benjamin Franklin

 
 
 

Switch from MvBase to MS Access?

Post by Ed Sheeha » Wed, 30 Jul 2003 07:44:10




>> 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.

> Could you share an example of the "needs of the software"?  I'm
> wondering how established Pick software can consume so many resources
> (granted, 50k/6 people).  If their development costs are high in an
> established site then maybe they need to re-evaluate "needs" vs
> "wants" on a per-item basis.

I can say this much: Procedures were implemented over the years after new
and needed features were added. This caused more plople to be added to
service these added procedures. Now some of these features and procedures
are irrelevant due to simpler requirements. But the "corporate memory" has
been damaged to some extent by the loss of some key employees. So we're now
left with people afraid to abandon some of these procedures for fear that
something critical will happen to the DBMS integrity.

That's why there's a gut-level urge to tip the whole thing over a cliff, and
develop "new" procedures based on something "easy" like MS Access. Yes, I
know what you're thinking, and you're right. They need to keep what they've
got, and survey their business rules as stated implicitly in the code, then
put in abeyance those rules which can be abandoned without compromising the
core data structure.

When the owner is finished with his preliminary analysis, I'll pitch this to
him. It's gotta be way better than the alternative: throwing the baby out
with the bathwater.

Quote:

> Compared to my original post, I'll swing the other way on this now.
> If they're trying to add complexity to the software

Actually the other way around. They want to reduce complexity now, but (in
their minds) where?

Quote:> and the costs are
> going to cause the software to get tossed as a result, by all means
> reduce the complexity!  The question comes back to what are they
> trying to change in the older software that new software is expected
> to provide?

Change enough to eliminate a few employees, but with years of custom
programming, it's daunting to know where to pare.
Quote:

> Tony

> "Beware of the young doctor and the old barber."
> - Benjamin Franklin