Re: Open source ERP vs Whose standards to use?

At last, someone with a bit of an idea that this won't be the greatest
thing since sliced bread.

I don't want to be a wet blanket, but I think all these people who want to
develop an opensource ERP need to sit back, calm down and think about this
as a BUSINESS project, not a technical one.

It's one thing to do a Linux, it's completely different to do an
Application system, especially one with interconnected modules.

Consider what a business needs for its application software.

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?

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!

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.

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.

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

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

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?

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?

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?

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?



There's heaps more I could go on with, but I would just like to sum it up
as follows.

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.




Rob Berendt <rob@dekko.com> on 11/02/2000 06:53:32

Please respond to RPG400-L@midrange.com

To:   RPG400-L@midrange.com
cc:    (bcc: STEVEN J RYAN/DIAU)

Subject:  Re: Open source ERP vs Whose standards to use?




I am curious as to how this will actually work in practice.  For example:
Will everyone be the Database Administrator?
Will they use a Field Reference File?
Will they use DDS or SQL to define their files?
Will they use common names in all files?  Will item number be called
ITEMNBR
in all files, or will each file have it's own manual prefix?  Or will the
PREFIX keyword be used?
How will they determine field size?  ANSI X.12, EDIFACT, or wing it?
Will they use SQL or OPNQRYF?
What about file naming conventions?
               BPCS:           IIM for the PF, IIML01, IIML02, etc for the
logicals, or,
               Software Plus:  All logicals begin with a Z.  Facilitates
                               upgrades by DLTF lib/Z*
Most of this will have to be worked out prior to one line of code being
written.
Maybe replies on this need to wait until the new list is complete.  Perhaps
use
this as food for thought as to whether or not this is a doable project.
+---
| 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
+---






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