Inventory Tracking & Purchasing
nimr0d writes "I work for a company is subcontracted entirely to the county government. We write the software in-house. We have approximately 100 different locations we service, and don't expect that to change much, for better or for worse. Currently, we have an archaic, DOS-based, ICOBOL inventory system which tracks every piece of digital equipment we have, by a individually unique serial number, which is further tracked by a 'SystemID', which is a container for each individual workstation. We then have another container for the location where the equipment resides. We currently track around 30,000 individual parts. Problem is, our system is very bug-ridden and is constantly prone to 'losing' equipment. We desperately need a new system for PO's, RA's, and inventory/cost/depreciation tracking desperately. Does anyone have any advice?"
"We need to be able to ship an exact copy of the system we originally sold them, in the event of a failure. Some stations serve different functions, so the ability to classify system's and parts by type is also very helpful. We also currently have flags for leased or purchased equipment, and whether that part is covered under warranty or not.
We have looked into several companies that write custom software, but they are looking for upward of $35,000 for a SQL or Access application, which is insane for a company of our size (approximately 25 people) to buy into. There has to be something out there reasonably priced that can do what we need it to, we can't be the only ones."
We have looked into several companies that write custom software, but they are looking for upward of $35,000 for a SQL or Access application, which is insane for a company of our size (approximately 25 people) to buy into. There has to be something out there reasonably priced that can do what we need it to, we can't be the only ones."
He's looking for ONE piece of software, not a handfull of cobbled together code snippets.
Steve's Computer Service, Hobbs, NM
$35,000 is not expensive for something like that.
Produce DETAILED requirements of ALL the processes that need to be performed and all the reports that are required of the system.
Step 2.
Determine what each part of the application is worth to you. How much business would you lose without it, how much easier would your job be if the software did it for you.
Step 3.
Find any existing products free or otherwise.
Step 4.
Compare the features against your requirements.
Step 5.
Offer to pay someone to implement those feature you want, that the software doesn't have. Possibly the original vendor / author of the software or for free software you could offer the job to someone internally if they're up to it, or well anyone really.
Step 6.
Look at what you've now got, realise that it's totally unworkable, just a buggy if not more so as the last software you used, and pay the $35k to someone else who works in the industry and knows what they are doing to sort out the mess.
Here's some free advice. Getting software to work exactly the way you want can be quite complicated and costly. Don't underestimate it.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
I think everyone here who has a programming degree is rolling their eyes. This is a no-brainer:
1. Find and hire a young CS student
2. Pay them well for the summer
3. Discuss exactly what you want the software to do for you
4. Watch the kid build it in record time before your eyes
5. Give them a 1000$ bonus in the end and enjoy the app.
Seriously, this sort of app is the every programming student's first major project. Most "custom business solutions" are basically the exact same thing, but with a glorified interface and extensive, bullshit-ridden documentation to please the bean counters. Let's face it, at least 75% of "business solutions" involve storing all your customer/product/service/billing data and retrieving it later as you need it, then running stats on the aggregate data to help streamling your business processes. It's all just a database with input dialogs and reporting facilities.
-Billco, Fnarg.com
I have a CS degree from the University of Rochester. I worked on a bunch of mentally challenging, but low paying research / robotics projects after college. It was very 'hard' CS work, but I wanted a car, so I got a high paying job in business.
Now, I program a huge order entry system in COBOL.
The problem isn't that writing an order entry system is hard; there's nothing technically difficult about it. The problem is that the order entry system a lot of businesses use has been in place for 50 years. So you aren't writing it from scratch.
That wouldn't even be that hard .... if COBOL was an object oriented language.
Sadly, there is no standard for object oriented COBOL, and so the code you end up working with is absolute spaghetti. The code base is so big that you can't go back and re-engineer the entire system. In fact, you can't even trace the execution of single program, much less the interaction of the hundreds of programs that your order entry system relies on.
Because of the sheer size of the problem (read: legacy code), and because programmers are always under tight deadlines, the goal of programmers in these situations is just to get the code working and get it in there. There isn't time to make it perfect. There just isn't.
So the problem just gets worse and worse and worse until ....
There are better companies/projects/systems out there. There ARE well-organized order entry systems and I'm sure that somewhere, there are programmers that have well-defined specifications. But in the world of business, where the bottom line is the most important thing, coding can be a much bigger headache than you might realize.
burrocrisy
and that would be what? Ruling by jackasses? Never has a slashdot misspelling been more apropos