Re: Open source ERP vs Whose standards to use? -- RPG400-L

Here are my thoughts on some of your questions (responses in line).

STEVEN_J_RYAN.NDOA@notes.denso.co.jp wrote:

> 1.  The ability to meet ever changing legislation.  There are nearly 200
> countries in the world now.  How can their various laws (both
> administrative & Tax) be understood and incorporated by purely IT people?
> We are introducing a new tax (Goods & Services Tax) here in Australia in
> less than 5 months time.  All the rules for it are yet to be established.
> How will this opensource ERP meet the challenge of such a rapid
> development, espeacially when most of the players don't even live in the
> country?

As this is Opensource, there will be a little responsibility of the companies
that choose to use it, especially in the beginning.  If a company is using
this software and legislation changes are coming up, they need to address
the issues by either checking to make sure someone is putting in the changes,
or changing it themselves, and making the changes available.

> 2.  The ability to meet local standards.  Our phone numbers in Australia
> are 2 + 8.  The US is 3 + 7.  I've had trouble in the past with US packages
> insisting on their format.  Our Postal codes are 4 numeric, the UK is 6
> Alpha.  Zip Codes at 5 numeric don't work every where!

We should use a modular approach to this.  Perhaps settings that can be
toggled to specify postal format, phone number format, etc...

> 3.  The ability to operate under local customs.  Our dates are DDMMYY. US
> is MMDDYY.  I am just taking a break from hunting down bugs because our US
> sourced software insists upon MMDD dates, and is throwing up all sorts of
> strange data.

We need to make sure this does not happen, and support he use of the
system values for date formats.

> 4.  Documentation.  I know we don't read this as much as we should, but it
> is essential if we are to use software properly.  95% of people buying
> Linux won't even consider looking at, much less changing, the underlying
> source to 'personalise' it.  95% of people buying ERP MUST look at and
> change the source to 'personalise' it.  Without an appropriate level of
> documentation, it will be very difficult to perform the necessary changes
> correctly.  And simply putting in a big effort at the start is no good.
> The documentation must be reviewed on an ongoing basis.

Redhat makes a lot of money off of Linux.  By documenting it.  And it is
still a heck of a lot cheaper than anything not opensource.

> 5.  Support.  If I have a problem with a program written by some one in
> Boulder, Colorado, and I'm in Melbourne Australia, how do I get in contact
> with them?  A mailing list like this is OK for general questions, but
> specific bug hunting in application software is a differnt ball game
> entirely!!!  The problem is compounded if I am using a version that has
> been upgraded 3 times this year..

Welcome to the internet age.

> 6.  Stability.  When applications get upgraded,this is usually via a new
> Release or a bunch of PTF's.  It's quite common to skip a few releases, and
> upgrade every few years.  How is this going to be controlled on an ever
> changing software system?  How will interrelated requirements be
> communicated to users (in order to use the latest version of payroll, you
> must have the following 22 programs from GL as well).

This will have to be worked out, but I don't' think it will be a major problem.

> 7.  Corporate Confidentiallity.  Linux (or similar) will not usually
> incorporate any commercially confidential information.  Application
> software will.  If some one designs a 'gee whiz' add on or extension to a
> module, can this easily be reincorporated back into the standard software
> without violating commercial confidence?  And if it can't, this will
> restrict the number of places that can contribute to the process of
> improving the software?

If something is a corporate secret, then it is up to that corporation to decide
weather they want to include it in the opensource project.  If they will not
disclose the source code, it doesn't go in.

> 8.  New functionality.  How do we know when it's time to do a revamp on
> some part of the system - Warehousing was OK 6 years ago, but should we
> rewrite it?  Don't forget the 'Legacy Code' principle.  Once people have
> got their version settled in, will they want to keep up with ongoing
> changes?

Linux handles this by having various people in charge of various applications.
To maintain and upgrade those sections.

> 9.  Company size.  Who is the target audience?  100,000 employees? 1,000
> employees? 10 employees?  One size does not fit all!  How much technical
> support will be needed?  How much Grunt will the processor need?

I believe the target audience would be from 1 to 100,000 employees. 8-)

> 10.  Longevity.  Being Pissed off today with JDE, MAPICS or any one else is
> not enough reason to keep going in 3, 5 or 10 years time.  But business
> needs the assurance that the system will be developed over time.  They
> can't afford to depend on a system that will be stagnant, while their
> competitors take advantage of new ideas and processes.  While Linux can
> draw on thousands of Microsoft haters, as well as those who want to do it
> for the sheer joy, how much can the As/400 draw upon?  Dozens, at most!
> The scale of the work will not be any less than will be required to keep
> Linux going, but with only 1% of the people to do the work, or to benefit
> from it.  Once the passion has died, who's going to keep the project going?

Linux never had a longevity promise either, but look at it now.

> We are here to solve BUSINESS problems.  Sometimes we get too caught up in
> the technical side of things, and forget that its the BUSINESS results that
> pay for it all.  Sort out the questions businesses will ask first, then
> worry about the technical matters.  If you can't make a GENUINE business
> case, forget it.  Otherwise you could have the greatest system in the
> world, but it won't get taken up.  As someone pointed out at the start of
> this thread, its the CEO who chooses the ERP system, often without even
> involving IT.  You don't have to come up with a system the IT department
> will like, but one the CEO will.  The CEO doesn't care whether Linux or NT
> is running a server in a back room somewhere, but the ERP system is very
> much a concern.

But, we know that this is not always right.  A lot of the time the product the
CEO decides on is not the best product.  I know in a lot of companies, price
plays a major role.

And the quality of a program can improve dramatically when a programmer is
doing it because he wants to, versus doing it because he has to.

Regards,

Jim Langston

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---