Re: Open source ERP vs Whose standards to use?

My reply to all your questions Steven is read Eric S Raymonds essay "the
Cathedral and the Bazaar" you will find a link to it on the front page
of my site http://www.springfieldtn.net/users/leslier .


Jim Langston wrote:
> 
> 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
> +---

--
L. S. Russell Programmer/Analyst
Datrek Professional Bags, Inc.
2413 Industrial Drive
Springfield, TN. 37172
mailto:leslier@datrek.com
http://www.datrek.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
+---