Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Open Source for Manufacturing

By japhar81 in Technology
Tue Jan 16, 2001 at 02:43:22 AM EST
Tags: Software (all tags)
Software

I'm currently the know-it-all hacker type at a manufacturing company. Were currently using (and I use that term lightly) Great Plains eEnterprise (with their manufacturing module) to do all of our finance, process management, and the rest of that good manufacturing stuff I know nothing about. We've found GP to be an absolute nightmare, and I'd like to propose to the powers-that-be that we switch to something open-sourced running on top of UNIX.


So my question to you all is this: Is there something out there that will do the same thing as Great Plains (everything from printing payroll checks to engineering change management) and, ideally, provide a way to migrate our current data?

I know there are some small quickbooks-style apps out there, I've seen them. What I'm talking about here is a system that will do everything. Payroll, overtime, vacation accrual, the printing of W-2 forms (Not sure whats involved with that one). On the manufacturing side, it would need to conform to ISO 9001 standards and be able to handle shipping and recieving MOs (Manufacturing Orders), SOs (Sales Orders), and the rest of those funky manufacturing docs. I guess the best I can explain it is to say go look at Great Plains, and then picture it running on top of unix, and, um, working.

I'm actually half-tempted to write something decent myself, and I'll likey attempt it if I can't find anything readily available. If anyone's interested in helping, feel free to give me a shout.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Should I even try and home-grow something?
o Yes 17%
o No 12%
o Will your fiancee mind not seeing you for a year? 34%
o Lay off the crack 29%
o Get a new job 6%

Votes: 91
Results | Other Polls

Related Links
o Also by japhar81


Display: Sort:
Open Source for Manufacturing | 22 comments (17 topical, 5 editorial, 0 hidden)
argh-- "I don't understand it, lemme rewrite (4.50 / 8) (#2)
by Speare on Mon Jan 15, 2001 at 02:36:20 PM EST

If I had a dollar for every time I heard the argument, "I don't understand it, lemme rewrite it," then I wouldn't need to go to venture capitalists.

Great Plains eEnterprise to do all of our finance, process management, and the rest of that good manufacturing stuff I know nothing about. We've found GP to be an absolute nightmare, and I'd like to propose to the powers-that-be that we switch to something open-sourced running on top of UNIX. I'm actually half-tempted to write something decent myself, and I'll likey attempt it if I can't find anything readily available.

While that one off-the-shelf product doesn't feel right to you, it was probably written by someone who knows more about the problems involved than you do. You can't become an expert with one project, and incompetent "finance, process management, and manufacturing stuff" could get your company embroiled in liability nightmares you haven't even dreamed about. While the typical geek thinks badly of the typical 'bean-counter,' I think it's a shortcoming of the geek, not the suit.

My recommendation to your boss: find something more productive for you to do, and find some other off-the-shelf system that might cover your company's financial and process management needs.


[ e d @ h a l l e y . c c ]
I dont claim to be an expert... (3.00 / 2) (#3)
by japhar81 on Mon Jan 15, 2001 at 02:44:39 PM EST

I have several folks here who are experts in manufacturing, finance, and the rest of that muck. I don't claim to know anything except programming. Im pretty confident that we could write something decent, its just a question of do we have to reinvent the wheel.

<H6>Rome is always burning, and the younger generation never respects its elders. The time of your second coming, japhar81, is no exception. -- Aphasia</H6&gt
[ Parent ]
Dig deeper... (4.66 / 3) (#5)
by sugarman on Mon Jan 15, 2001 at 03:15:53 PM EST

question of do we have to reinvent the wheel.

I'm going to agree with Speare, above, and suggest that this might not be what you need. From my own work experience, the system we're using has loads of options, and every week or so someone will send out a note about a new 'feature' that has been 'discovered', which in fact has been there all along.

So, I guess the question would be, how well does this enterprise-wide, integrated system meet the needs of all it's users? If it meets the needs of the HR and Finance departments, is it worth it to change? Will they even let you?

Also, how tightly is the production system wedded to the other modules? If you implemented a different system for production, would you be able to co-exist with the rest of the software, that HR and Finance will likely want to keep.

Furthermore, have you explored all the nooks and crannies of the current system? Are there functions that are tucked away, unreported, or maybe locked out? Are there other modules available that would provide the functionality you seek? Often, users are limited to what functions are available (again, HR and Finance) for confidentiality reasons. Talk to some people and dig more?

And last but not least, let's put this in perspective. ERP software is a *big* thing. How big is this undertaking you're looking into? For a parallel, the GIMP has most of the functionality of Adobe Photoshop. For sake of the arguement, let's call them equivalent. How long, and how many man-hours did it take the GIMP team to achieve this level of functionality? Now compare that with Great White. How long do you think it took them to produce this product? Is this something you can commit the same amount of time and effort to?

--sugarman--
[ Parent ]

Large projects (4.33 / 3) (#4)
by Pac on Mon Jan 15, 2001 at 03:10:43 PM EST

I am presently involved in a one to two years (somewhat risky) project to re-write most of the system of a formerly medium sized medical enterprise. I say "formerly medium sized" because this company has already bought two other companies in its line of business and is planning to buy some more.

The proposed system will take care of all consumer interection (personal, phone, Internet) and will also included a complete rewrite of all technical systems (probably comparable with the plant control system in you case). The system has interfaces to a financial system, a commercial system and a ERP.

To give you a taste of our estimates, we have a 6 developers team growing to 8 soon, at least 4 of those senior developers. 3 of these developers are employed by our client. We have two managers, me and my boss. We have two part-time designers. Soon we will have a full-time DBA and a full-time network admin. The client is also making available to us a general manager for the project (that also takes care of smoothing our interface with the various involved parties from their side) and a permanent group of 3 content expert (one for the medical area, one for the consumer relationship area, one for the commercial area).

The size of the effort is enormous. The risks are huge. And the present system is not expected to survive many more fusions and buyouts. The later is the main reason this project exists, really. And also our higher time constraint.

A large software project is a very special beast. Just do not tell your boss that next month you will have it. Tell him that next month you will have a plan. Then plan like hell, because the only thing that will save you if they ever let you do it is your plan and their signature in it.


Evolution doesn't take prisoners


Open Source != Holy Grail (4.66 / 6) (#6)
by retinaburn on Mon Jan 15, 2001 at 03:24:14 PM EST

A lot of people are jumping ship on commercial applications to go with an Open Source solution. First of all when doing this you often lose support and documentation (besides the code itself). If some bug is found in a commercial app, at least you have someone to blame...and hopefully to poke at with a pointy stick until its fixed. With open source my feeling is your up the creek sans paddle.

Financial systems are notoriously complex and if it doesn't seem to be working right it probably a) isn't configured correctly or b) ins't being used correctly.

It sounds like no one at the company let alone you knows how to determine if this is true and rectify the problem ...due to inexperience not lack of intelligence.

Check around with other companies and see if they'll tell you what they use. Try to get Great Plains to tell you some of their other customers and talk to them. Maybe if see if your company can "borrow" an expert from somewhere else to get everything up and running.

If you hear that this product is notoriously bad then I would advise jumping ship to another commercial product. A one person development team for an all encompassing finance package is ludicrious, even a one-person hacker for an open source project to do the mod's (if needed) sounds a little scary.

May the force be with you, you'll need it.


I think that we are a young species that often fucks with things we don't know how to unfuck. -- Tycho


Having just been there... (4.75 / 12) (#7)
by MTDilbert on Mon Jan 15, 2001 at 05:11:45 PM EST

My predecessor tried to do the same thing, and we are 6 months into cleaning it up and moving to a canned package.

The problem with a "DIY" approach, I think, for something of this scale, is that unless you actually have a programming staff, a test box/environment, and no outside life to speak of, you are going to be better off to evaluate some of the other products that are out there.

From my perspective, what happened in this instance was that once the package got to the point of "turning it on," the bug fixes and functionality changes that were needed to bring the system fully functional were far too overwhelming for one person to handle. Thus, many things were done on an ad hoc basis -- in firefighting mode. This left a spaghetti system with incomplete documentation, no data dictionary or file layout to speak of, and we had to figure out what it was doing. It wasn't fun.

Since I'm treading dangerously into OT territory, I will say that I'd be glad to correspond via email on what we have learned in the past 7 months.

FWIW, though, we do have a couple of Linux boxen in here, serving web and email and sharing files. They work like a champ, and as far as anyone can tell, they are NT boxes, which makes "Nobody got fired for buying M$" types happy.

Don't mod me down because you disagree. Show me the error of my ways.

Commercial software for these tasks... (4.90 / 10) (#8)
by Miniluv on Mon Jan 15, 2001 at 06:05:38 PM EST

Having worked in the warehousing and transportation industry for 2 years before jumping into the full time IT industry, I understand some of the tasks involved in a project like this, and some of the things the software tries to do. The last thing my company was doing before I left, they hadn't yet finished the project, was a complete from scratch developement of a new software package to handle accounting, payroll, inventory management and transportation tracking. This was 18 months of developement with a team of 6 coders and one DBA.

One of the biggest lessons we learned was that there's a reason Oracle charges so much for their database software. It's because writing a good database is hard, writing one to handle transactions, large volume, large datasets, and all the other things you expect of an enterprise RDBMS is even harder. The one written by our team of good, solid coders sucked serious ass. We also learned why SAP R3 is damn expensive, because ERP software is even harder to write than databases. The cost of developement on these projects is incredibly high, and the demands placed on the code for flexibility and reliability is also incredibly high.

All this leads to me to say I doubt there is an open source project out there to do what you need, nor do I see it likely there'd be one anytime soon. One person would spend years getting something like this into a working beta stage, let alone something ready for a company to trust.

I would strongly advise working with the software vendor to examine your configuration and see if that might be the issue. If that cannot see the problems resolved to your satisfaction let a bid for other vendors to come propose solutions and grill them on the technical details to make sure you don't get involved in another disaster. Most of these vendors can migrate data between each other's projects, as people switch semi-regularly enough to have engineered migration paths.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'

WOW (4.00 / 1) (#16)
by retinaburn on Tue Jan 16, 2001 at 09:06:45 AM EST

You guys tried to right your own DB, insanity :)

I started working with some DB2 and our group uses it all over the place. And while I used to moan about how expensive software like DB2 was once I see it in action, see how stable it is (when used correctly) and the functionality (when used correctly) I was thoroughly impressed. I even thought thats its worth more than they charge ;)


I think that we are a young species that often fucks with things we don't know how to unfuck. -- Tycho


[ Parent ]
Defending my honor... (4.00 / 1) (#19)
by Miniluv on Tue Jan 16, 2001 at 04:44:29 PM EST

So everyone knows, I was not directly involved in the project as I was a fairly junior person at the company, despite being the second senior person in our IT group...wasn't a big deal because our group only had two employees.

Once I started finding out the details of the project I was horrified. We had purchased, in the contract, the rights to all source so that we could hire people to support this code once it was developed, but nowhere did the contract specify what language documentation, in code and on paper, had to be written in so we ended up with a massive construction of C++ code commented in Spanish. No big deal sometimes, but when the company is based in Chicago Spanish speaking C++ jocks aren't exactly plentiful.

They ended up, from what I hear, rewriting the database functions to interface with an MSSQL7 server, I kinda wonder how much better that'll work.

Long and short of it, I learned that when there's commercial software out there to do a job and it costs $8K plus, there's a reason and you need to do your homework before trying to replace it with homebrew.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

I don't think anything meets your needs yet (4.12 / 8) (#9)
by goonie on Mon Jan 15, 2001 at 07:25:55 PM EST

As somebody that works on the GnuCash project, we keep an eye on progress in open-source projects in this area, for our own interest and partly because in the future we intend to take GnuCash beyond personal accounting into the business world. If you have a look at our website, we've got links to some open-source business accounting software, most notably Linux-Kontor and GnuE. GnuE seems to have goals that approximately align with your own, but I doubt they're to the point where you'd be prepared to bet your business on their technology.

Real-World Manufacturing Systems (4.66 / 3) (#12)
by mindless on Mon Jan 15, 2001 at 09:48:35 PM EST

I've been working on a proprietry system that does all of this for the past eight months, originally written back in 1983 (written in C, currently running on SCO Unix with plans to migrate to Linux at some time). It's had fairly minimal upkeep done to it, mostly bugfixes and y2k stuff done by the previous guy, so portions have gradually fallen into disuse. I'm gradually expanding the system to more closely mirror the current business processes and manufacturing systems the company uses, making it far more useful to the company.

This is the major advantage of having a custom system - you can change the programs to suit the business, rather than the business to suit the program. Fairly recently, we looked at upgrading the system to a commercial system - the main forces for the change coming from the accounts department. (The men in suits like GUIs, it seems.) One section of the company had been using a commercial version for about a year, which was generally viewed as unsatisfactory to everyone except accounts. The 'renegade' department has since been converted back to the current unix system. Every commercial system we look at is incredibly expensive and requires substantial modification for the business processes the company uses, making it far cheaper to modify the existing model. This is where an OS version would be excellent - allowing smaller companies that can't afford the extensive development time of implementing their own version, or the exorbitant licencing fees of many vendors to utilize a customizable and powerful management and accounts tool.

On the other hand, this is one complicated beast. There's no documentation apart from what I've written since I got here, and the guy who previously used the system has left the company. It's taken me a little while to get used to the system, and even after eight months of hands on deep-in-the-guts programming, I've only got a clear picture of about a third of the system. Anyone attempting to write one of these from scratch better have a rock solid design, quite a few mates, and a couple of years to spare. Good luck, and if the OS version does take off, I'd be happy to donate some time and as much experience my limited career can give.

mik
------- "i really don't know what i'm doing here..." rs, the cure
Potential issues (4.85 / 7) (#14)
by onyxruby on Mon Jan 15, 2001 at 11:11:52 PM EST

My comments that follow concern only the tax and accounting part of your proposed system.

I worked in IT in the finance industry for a bit and had some potential concerns about liability. You are wanting this system to take care of tax records and accounting issues. This is going to be a lot different than just making a system that handles inventory. If you create this, and there is an error in the software that affects taxes, there would be significant liability issues. The tax codes change constantly, are very hard to decipher, and quite likely require more training to stay current on than the IT field.

If your going to do this, you need to make sure than you have a CPA on hand to make sure the tax data that is being used is current and accurate, for each tax jurisdiction that it will be used at. You also need to make sure you have that same CPA available after you create the product. You have to keep all tax data current, quarter to quarter (not year to year), this is very definitely not a write and forget type of application. This system would need to reviewable by multiple goverment agencies, especially the IRS, and more than likely the SEC. (Data used would affect what is disclosed to stockholders - major accountability issue there)

I am not trying to discourage you from doing this. If your company is large enough, you could quite possibly justify the cost of development, right down to the CPA, with cost saving over Great Plains. There would certainly be a large number of parties interested in the final product, if the lawyers would ever allow it to be released. Even if you don't charge for something, if it is distributed by your company, you can be held legally liable for it. When I worked for a large snowmobile manufacturing company, they had to throw away a large amount of perfectly good winter clothing out every winter instead of donating it for this very reason.

The moon is covered with the results of astronomical odds.

I have one word for that... (none / 0) (#22)
by Steeltoe on Thu Jan 18, 2001 at 10:22:55 AM EST

"When I worked for a large snowmobile manufacturing company, they had to throw away a large amount of perfectly good winter clothing out every winter instead of donating it for this very reason."

Insane in the membrain!

- Steeltoe
Explore the Art of Living

[ Parent ]
GNU Enterprise (5.00 / 2) (#17)
by jamest on Tue Jan 16, 2001 at 09:53:10 AM EST

Well, we've got a long way to go before we get there but we're working on a system that will be able to provide quite a bit of what you require. You can find more information at www.gnue.org. We are an offical gnu.org project so everything is GPLd. And though we've historically been a bit slow due to lack of assistance, personal time constraints, etc, etc we are in it for the long haul. (GNUe's history can be traced back at least 2 years.) I'm also happy to say that momentum has been picking up steadily for the last 6-8 months. There's alot more I'd love to say about the project but I'll save the bandwidth. If you are interested please join us in IRC (irc.openprojects.net port 6667 channel #gnuenterprise) as someone is usually arround to answer questions. So, before you write your own please consider lending us a hand.

jamest@gnue.org

ArsDigita Community System (5.00 / 2) (#18)
by crasch on Tue Jan 16, 2001 at 01:58:52 PM EST

I'm typing this while on a break from data entry into Solomon IV, another Great Plains accounting package. I have to enter invoices by hand, because the import program doesn't work. Overall, my Dad's company has spent $100,000+ and more than a year trying to get it to work for a relatively small service company. It crashes at random intervals, the user-interface is cumbersome, and the software makes it difficult to make changes once you've entered the data.

Unfortunately, I don't believe any of the current crop of open source accounting packages could meet your needs off the shelf. I believe the closest may be the Linux-Kontor project. You should also check out Christopher Browne's canonical list of links to open source accounting/finance packages. For a small company, SQL-Ledger is also worth a look.

Personally, I would love to see someone create accounting modules for the ArsDigita Community System. It is a web collaboration toolkit initially developed by Philip Greenspun, Tracy Adams, and others at MIT. It is now currently maintained and extended by the developers at the ArsDigita Corporation (250+ mostly MIT/Caltech trained programmers), as well as a healthy external community of developers. Currently, there are two versions of the ACS: ACS "Classic", which runs on Oracle, and OpenACS, a port to the open source PostgreSQL database.

The ACS has been used build a number of high-volume, high-security web services for large companies including Oracle, Siemens AG, and Hewlett Packard. The ACS was used to build an experimental "pants-tracking system" for Levi's (though Levi's ultimately decided not to make the system live.) Other projects include an electronic medical records system and a site for selling municipal bonds. (See case studies page for more details.) Also check out http://www.arsdigita.com/pages/toolkit/modules.adp. for a list of the modules currently available.

It is extensively documented, and training is widely available. Among the resources:

Philip Greenspun's book "Philip and Alex's Guide to Web Publishing" (200+ five star reviews from Amazon.com; also completely available online at http://www.arsdigita.com/books/panda/)

Complete course content of MIT course 6.916: Software Engineering of Innovative Web Services, which teaches you to use the ACS, is available at: http://philip.greenspun.com/teaching/psets/ps1/ps1 This course has since been adopted by Stanford, Berkely, Caltech, and a number of other universities.

Free 1 - 3 week boot camps taught by ArsDigita employees: http://www.arsdigita.com/boot-camp/

Detailed installation guide for both OpenACS: http://www.openacs.org/doc/openacs/index.html and ACS Classic: http://www.arsdigita.com/ad-training/acs-install/

Procedure by procedure documentation: http://www.arsdigita.com/api-doc/

Note, I have no association with ArsDigita, other than as a fan of the company and software.

Underestimating the task... (none / 0) (#20)
by pingflood on Tue Jan 16, 2001 at 06:42:02 PM EST

I don't know how familiar you are with these types of systems, nor the size of your company. However, having worked with ERP systems for a while, I can offer a few comments.

First off: writing a system of this magnitude is an enormous undertaking. The system I work with (SAP R/3) contains well over 10,000 (that's ten thousand) database tables, and thousands upon thousands of separate programs. Among the documents you probably want to be able to handle are: quotes, sales orders (gratis orders included), purchase orders, transport orders (if you have multiple plants/warehouses), deliveries, production orders, planned orders, etc.. if you also want to incorporate the financial part, you have to deal with a multitude of documents there; not to mention the nightmare taxes can be. We have an entire separate subsystem that does nothing but tax work.

That said, if you do decide to attempt it, it will make you learn more about every aspect of a company than you could ever imagine; there are tons and tons of little things that go into every area, and not much room for error in your millions of lines of code. Enjoy. :)

-pf

PS: inventory management and forecasting is fun, too. Not to mention material master data -- we store about 300 pieces of information about each material, not including the BOMs. :)
Sell fitness equipment, make bucks. Cool affiliate program.

With all due respect... (none / 0) (#21)
by mjs on Tue Jan 16, 2001 at 11:07:19 PM EST

I don't think that you really understand the problem. The scope of what you are asking is enormous. I've specialized in MRP/MRP II/ERP software for 20 years. I've written large chunks and designed larger ones. I was one of the original designers of what is (or at least, used to be: I've not kept up with it for years,) CA's "CA-PRMS" package, back when it was originated on the IBM S/38.

You don't want to do this.

No, seriously.

The worst news is that so far as I know, what you want doesn't exist for Linux. Actually, a couple of years ago I got a bug up my butt (coincidentally, simultaneously with my employer purchasing a real piece of garbage ERP package written in -get this!- Visual Foxpro!) for Win/NT. About three weeks into the scope document I came to my senses. But there is some use out of this little discussion: I see some interesting links in other replies. Gonna go check 'em out right now! mjs

Open Source for Manufacturing | 22 comments (17 topical, 5 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!