Small Buisness ERP/MRP.  What do you use?....... - Page 1
Forum section: electronics / general

author: Smokey
author_rank: Super Contributor
timestamp: April 28, 2016, 02:27:03 am
content: For those that don't know, this is the software that essentially runs your company especially if you do manufacturing or have to keep inventory.https://en.wikipedia.org/wiki/Material_requirements_planninghttps://en.wikipedia.org/wiki/Enterprise_resource_planningGiven how big of a long term decision it is picking an ERP/MRP software package, I figured I'd start a thread so we can discuss issues related to MRP and ERP.What do you guys use? Are you happy with it?

author: amspire
author_rank: Super Contributor
timestamp: April 28, 2016, 02:52:38 am
content: There are a lot of commercial solutions.In terms of free/open source solutions, Odoo (was OpenERP) is really nice to use, but last I checked, they do not provide update scripts is you are using the free Community version. Very easy to get started. Very intuitive, and the modular nature means you can start of symple and build the features up.https://www.odoo.comI think the best true Open Source ERP is Tryton:http://www.tryton.orgThere are some major projects done in Tryton including GNU Health - basically a full Hospital/Doctor patient medical database system for a small country. They started with OpenERP, but when OpenERP started going commercial, they switched to Tryton.The problem in choosing Open Source for a company is the moment you start discussing the support issues, Business owners usually want to run to a commercial provider for a solution so they can get direct support, even if it costs thousands/month.

author: apelly
author_rank: Unknown
timestamp: April 28, 2016, 03:59:26 am
content: Number of employees?I would suggest open source. Anything worth while, commercial, and under a million bucks will be limiting in the extreme and unfixable. But kpmg and pricewaterhouse will love you.The good stuff will be comprehensive. This will be daunting. Possibly extremely so. Get help from someone with many years experience. They will not be cheap, but youdo notwant a 25 year old computer guy doing this. It will end in tears. If you have 1 employee you can do the implementation yourself. If you have a few you will struggle. More than a few and you need a dedicated implementation guy.I haven't looked at tryton, but openERP was indeed adequate for at least a few dozen employees. I will look into tryton for myself now.I can not speak for manufaturing. To the best of my knowledge none of the generic packages are much chop at inventory management. But you can more or less do that manually for the first few 100m2Remember, your business is not unique, or even unusual, no matter what you do. Wherever possible, fit your business to the software, not the other way.

author: EEVblog
author_rank: Unknown
timestamp: April 28, 2016, 04:07:45 am
content: Quote from: apelly on April 28, 2016, 03:59:26 amAccording to Australia Post and every ecommerce integrator I've spoken to, I'm the only one they have heard of who ships >95% of packages internationally.It wasimpossibleto find an off-the shelf Woocommerce eparcel integration that handled international shipping properly. I've used three different systems now over the years and with every one of them I've had to fix bugs, have been the only to request blatently obvious essential features etc. Heck, I even found anentire country missingfrom Australia Post's own system!

author: apelly
author_rank: Unknown
timestamp: April 28, 2016, 04:49:46 am
content: Not unique. Or even unusual. How does all of China and Hong Kong and eBay work again? Also, you're a one man band so your processes are flexible to the point of being different every single time.Every modestly sized company has custom code written for interfacing their inventory system with their preferred carrier. Complexity varies, but:Quote from: EEVblog on April 28, 2016, 04:07:45 amSounds like they didn't know what they were talking about. You might be the only one that uses the post office for it though.But you're saying that the national postal service doesn't have a facility to easily pay, print a label and stick it on a box? Hard to believe.Quote from: EEVblog on April 28, 2016, 04:07:45 amStill hard to believe. I do believe the Australian freight companies would have a shit solution. I doubt anyone serious uses their "free" software.You need labels and a manifest. That's it. Labels are a pain. Each company wants something slightly different, odd barcodes and odd shaped forms which might have multiple layers.But you're sending what, a dozen things a week? I can not believe you can't just sit down on shipping Mondays and print off your stuff.Quote from: EEVblog on April 28, 2016, 04:07:45 amThis part I have no trouble believing. Nobody uses the shipper-provided stuff because it's shit. They only have it so the sales guy can say "Oh, did I mention? We have our own special software, look; clickety print. You'll never have to worry aboutthatprocess again!"Anyway, I will concede that addresses are hard. Australia has good ones. Nowhere else does. Different country, different format. That's why your label fields are always address1 through 4, country, postcode. I can imagine it would be tricky getting a Russian or Malaysian address into any system, let alone one designed by some 20 year old at Aus Post who's never been outside of Sydney.

author: Smokey
author_rank: Super Contributor
timestamp: April 28, 2016, 04:59:05 am
content: We are most certainly a small business, but at our size and complexity going open source for something as critical as ERP isn't a real option. It's the makerbot 3d printer/kicad problem. Sure they work with enough effort, but we can't spend all our time fixing the tools when we need to be using them. This is a system that MUST work, and it's worth the support cost. There would need to be a company like Redhat behind any open source program that could provide comprehensive support before it would even be considered.The thing we are trying to implement now is GlobalShop. Functionality wise it looks really good with a lot of really powerful useful features. Under the hood it appears to be a cobbled together mess of old code modules that have been patched over with new GUIs.I'm trying not to get too suck in the "This is different from what I'm used to and I don't know how to use it yet so that makes it a piece of crap" trap, but so far I'm not impressed at the procedures and all the steps you have to go through to get the data the way the program needs it and keep it from bugging out. I'm sure this is always the case, but data migration to the new system is an absolute clusterfcuk.

author: Ice-Tea
author_rank: Super Contributor
timestamp: April 28, 2016, 05:49:08 am
content: I was at a company where the boss decided on a blue monday: hey let's transfer it all to OpenERP, it's open source, how hard can it be?Don't do that. Take some time to think about it, expect a lenghty and costly project. If you just start hammering away, it will suck up a bucketload of energy (and money) without any returns.And continuously ask yourself the question: is there anything here that I can't do with a simple (or not-so simple) spreadsheet?

author: apelly
author_rank: Unknown
timestamp: April 28, 2016, 05:58:16 am
content: Quote from: Smokey on April 28, 2016, 04:59:05 amNot with that attitude.But seriously, do not underestimate the implementation effort required. There is no such thing as a drop-in solution. These are systems of surprising complexity. Some clues about how big we're talking would be helpful here.Were you the guy asking about part numbers in another thread? If you were, it's pretty safe to say you don't want ERP.Quote from: Smokey on April 28, 2016, 04:59:05 amYou're dreaming. This is what will happen, no matter what you choose:Financials will work. AR/AP will work. You won't understand enough about purchasing to make it work properly, but it'll work. Inventory will work, but your procedures will be shit and you'll have picking and shipping error rates an order of magnitude too high. Goods inwards will vary depending on the product. Returns will be a total nightmare.I can't speak for manufacturing, but the management accountant should be able to get a handle on the basics without any trouble.Support costs will be the same for both, but for commercial you also have annual licensing.Quote from: Smokey on April 28, 2016, 04:59:05 amIf you look, you will certainly find professional support. Have you at least published an RFP?Quote from: Smokey on April 28, 2016, 04:59:05 amAll large systems are a nightmare under the hood. These are things that have taken years to develop. The current thing to do is marry best in class software for each of your business silos. You don't want to do that. You do that later when you're stable and have time to notice what needs improving.Quote from: Smokey on April 28, 2016, 04:59:05 amYou already have a system? This stuff can be a major part of your implementation. If you get this wrong you will have consequences for the life of the new system.Look, maybe I'm overreacting. I don't care what you do, I just have some suggestions based on my own experience. If you've got less than 20 people, turnover is under 500k, and you have less than, say 1k SKUs, anything will do. If you are any bigger than that then you also pretty much need a full time support person for the software. At consulting rates that can get pretty pricey. I've never seen a small implementation done for under 500k just in consulting or so. 3 million would be closer to the mark.Now, youcando it cheaper. Which is what I'm trying to tell you. If you're careful with that 500k and you flex your processes to match the software (which probably does it better than you do at the moment anyway) instead of changing the software, wherever possible (and I mean that literally), do your prep, and engage a good implementation manager you might get away with a mere 50k. That's the cost of the implementation manager for a long month. He'll need a couple of your own guys pretty much full time too.

author: apelly
author_rank: Unknown
timestamp: April 28, 2016, 05:59:46 am
content: Quote from: Ice-Tea on April 28, 2016, 05:49:08 amThis! You don't want to behere!

author: amspire
author_rank: Super Contributor
timestamp: April 28, 2016, 07:21:03 am
content: The best customers for ERP systems are the ones who are not terrified by having to change to a new system in the future. Migrating is a pain, but use the ERP system as a chance to get your data totally clean (All postcodes.zip codes entered everywhere, no duplicate records for the same customer, no use of fields for non-intended purposes - like putting addresses in an unneeded tax field). Then you do not have to feel like you are making the perfect choice the first time. If it is a wrong choice and your data is clean, it should be possible for a smooth migration to a new ERP, and you will know what you want better the second time around.If you head of into the world of ERP saying - "we absolutely have to get this right the first time - it has to work perfectly", then you are in for a rough ride.People who are terrified of things like ERP systems often end up making bad choices - like spending a lot of money to get the "safest" system. I hate to think of the number of people who have gone down the track of a high end SAP-based system and after a million or two spent, still do not have a properly working system. I have seen companies that have spent $2million for a bad solution, and they could have spent $50,000 on a far more suitable solution.The other huge mistake that is always a disaster is when the company management do not get involved in the setup of the ERP system - if they leave it all to an "expert". If the management is not centrally involved in the ERP system, the company should not have an ERP system.You definitely want some kind of external support - whether it is open source or commercial - and it may be finding the right team to support you is more important then the actual package you choose.

author: MrSlack
author_rank: Frequent Contributor
timestamp: April 28, 2016, 07:48:07 am
content: I wrote a massive ERP system in HP Workmanager and Oracle about 15 years ago that integrated with end to end engineering stuffb I.e. assets, CAD, the lot. Then rewrote bits of it in Java EE. From this project I derived two important facts:1. ERP is a magic bean. It looks good on paper. When it comes down to real world, it's a giant beanstalk that rains turds upon you. They are never a precise match for business processes and induces much pain. Small businesses can't afford it, simple as.2. £££££££££. Some £££££££££. Then some more. Oh and bend over and throw some more £££££££££.If I'm honest, you'd be better hacking your own up that matches your business in Access or something similar and integrating it where you need with Office 365 or something as a CRM. Then adapt it as your business evolves yourself. Lots of small chess moves initially and test to see if the ideas work. Full control over it. Do as much or as little as you need to. If you need some help, hire a generic office/access contractor, not a CRM guy as they are all about sales, not tailoring stuff to your business. If you're large enough to take on an IT guy, do it and get someone to look after it, all your kit and help evolve business automation with it as they can easily pay their own salary and keep your business running smoothly.

author: StuUK
author_rank: Frequent Contributor
timestamp: April 28, 2016, 08:01:57 am
content: Quote from: EEVblog on April 28, 2016, 04:07:45 amMaybe you should emigrate to the UK

author: apelly
author_rank: Unknown
timestamp: April 28, 2016, 08:05:29 am
content: Pretty much.Quote from: amspire on April 28, 2016, 07:21:03 amYes. There are many, many complexities to consider. If I merge two customers what do I do with the existing invoices? What happens to their sales data? How does it affect future commissions? Had the customer come to expect different bills for different products? How will this affect sales analysis spanning the merge? Do you give a shit about any of this?Do you sell the same product as two different items currently, for different reporting requirements? Have you got items that you sell as kits, or items that come in two boxes that together make one product. Are you selling batched items? Serialised? What history of these do you care about?Quote from: amspire on April 28, 2016, 07:21:03 amI'm not sure about this. After you're out of pocket this much the scale of the fuckup has to be gargantuan to warrant going through the whole process again. It's Ok though, because if you have good (any?) advice it probably won't crush your business.Quote from: amspire on April 28, 2016, 07:21:03 amShe's a pretty rough road at the best of times I'm afraid. There will be pain, and there will be joy, and there will be post-project depression.Quote from: amspire on April 28, 2016, 07:21:03 amThere's no such thing as safe. SAP and Oracle are happy to hang you out to dry after your cash dries up. And boy oh boy can they soak up cash. $2million is probably the minimum spend to even realise you're in serious shit.Quote from: amspire on April 28, 2016, 07:21:03 amYes. Very much so. You're installing a management tool. That is pretty much the point of it. Do everything only once, and get a full company view at any time. Less people, better reporting, smarter management, bigger rewards. Managers who do not understand this have no place in a highly productive company. Also, good managers ask good questions of your implementation team.Quote from: amspire on April 28, 2016, 07:21:03 amYes. You will need to work intimately with a few quite expensive people. You need to trust that you're getting value for your money.

author: apelly
author_rank: Unknown
timestamp: April 28, 2016, 08:20:17 am
content: Quote from: MrSlack on April 28, 2016, 07:48:07 amNo. You didn't. I don't know what you wrote, but it was neither massive nor ERP. Even a modest ERP system has dozens of coder years of code in it. Did you mean to say you had a team of 30 people write one?Quote from: MrSlack on April 28, 2016, 07:48:07 amTrue. That's because you're doing it wrong. All companies are inept at most things. A decent ERP system pulls best practice from different industries into a cohesive whole.Quote from: MrSlack on April 28, 2016, 07:48:07 amPretty much.Quote from: MrSlack on April 28, 2016, 07:48:07 amGood luck auditing that. Sure, if you're a one man job-shop that'll do, but you're still better off with a decent paper system. This is bad advice.Quote from: MrSlack on April 28, 2016, 07:48:07 amIf you're not large enough, abandon the whole idea right now.But that IT guy; he's a software guy. Don't make him back up your server. He'll be shit at one job or the other and he'll hate you and leave.

author: MrSlack
author_rank: Frequent Contributor
timestamp: April 28, 2016, 08:28:58 am
content: Yes, we had a 22 man team and 15 overseas and I was the principal architect for this product. It took 3 years. 15,000 users. This wasn't a clown outfit. I think there was about 3.5TiB of data online which was a big deal back then.If you take a COTS ERP and try and customise it, you're not pulling in a host of industry best practices, you're pulling one opinion in that doesn't match your own business processes. The cost is either you change your business processes to match the incumbent process which is met with resistance or bend the product the other way. Neither really fit the real world. I think there are too many management process types out there who will sell an ideology rather than try and understand the business. Six Sigma comes to mind.Agree with paper system if you're going to do it on a small scale.I've seen more small businesses derive value from a small custom solution built in house than I have elsewhere. The current state of things and the audit requirements are not congruent. The business lives now which is the 99% use case and the audit trail lives in the past. The two can be separated very easily. As for audit, Lightswitch has process structure and auditing built in if you want to go down that route.As for the software guy and the operations guy. Note the focus on Office 365. Someone else should be doing your operations in 2016 if you're a small business. A software guy can quite happily change a toner cartridge, phone up the broadband supplier if something goes pop or reinstall a windows machine. The rest of their time is spent on business automation which is an efficiency step.

author: amspire
author_rank: Super Contributor
timestamp: April 28, 2016, 09:07:43 am
content: Quote from: apelly on April 28, 2016, 08:05:29 amYou never plan to make a mistake, but if things don't work out, don't let it be a disaster. When I have tested ERP systems, one of the first things I do after importing test data is to try and export it again - check it works, that the export data is good. I want to know that at any time, I can export into CSVs, JSON, or XML all the important ERP records quickly. I do all this well before there is thought of using the ERP in production. I want to see what records in the ERP use very convoluted layers of tables, and if there is a way to flatten this complexity in the exports. If for some reason, you decide after a year or two that the ERP is not right or there is something better, it will hurt, but with good planning, it is not a disaster.QuoteWhen you spend $2million, you know you have a lot of custom code - in other words, every bug in that code is going to be discovered the hard way by your company. Low end but powerful ERP packages like Odoo cost to license about $25 a user if you use the commercial version, have a big customer base, can be extended with extra fields and extra modules in a pretty safe way, and have a simple enough interface so that much of the setup can be done by the company's own staff. That leave the job of the consultant to manage the import of data, and the fine tuning of modules - things like localization. You can get a pretty good result at a pretty economical price with the right consultant.Often the secret to keeping the costs down is to be flexible enough to be able to use the default way the ERP works, but this may be impossible. The kind of things that cause the problems often sound simple - like at what point an item is actually sold. At what point is an item still in the warehouse shelves? If you have one LM324 opamp and you sell one LM324 but the part is still on the shelves in the warehouse, should the ERP say it is on the shelves, or should it move it to an imaginary pre-delivery location in the ERP? At what point is it delivered - when it leaves your door or when it arrives at a customer?These questions almost sound so unimportant that it doesn't matter, but the ramifications of these decision points go right to the core of the ERP system. Change them and there can be a never ending stream of surprise consequences that you could never imagine.If you can live with the ERP rules as it was written, then it is possible you can suffer a minimum of pain. If you insist that the ERP has to be adapted to work exactly the way you imagine your company should function, then make sure you have a big chequebook and an infinite amount of patience.

author: VK3DRB
author_rank: Super Contributor
timestamp: April 28, 2016, 09:35:05 am
content: Sometimes it is worth developing your own "ERP" system. Off-the-shelf is not always the right way to go.I wrote a system entirely in LabWindows/CVI 14 years ago. It worked a treat and had features unavailable by SAP (See And Puke) or any other off-the-shelf system. The sequence was this...- Sales enters an order for a highly configurable telecommunications machine in Melbourne.- The parts are picked and built into a system by a vendor in Sydney.- The system is then fully functionally tested automatically.- Upon passing the tests, PGP license keys for software features are configured.- Barcode scanning is done for every commodity in the system.- The machine is packed and a shipping label is printed and the system is shipped to the customer from the remote location in Sydney.- Records, including stocking levels, machine history, and licenses are all updated in Melbourne and an invoice is issued to the purchaser.This system did the entire order-to-shipping processing, including actually testing the system at a technical level (it interfaced to a W&G PCM 4, HP test equipment and some special purpose test equipment I had developed). In addition it handled all the license keys including testing them.It took me 6 months to plan the project and write the code. Much cheaper and more appropriate than any B2B system.

author: apelly
author_rank: Unknown
timestamp: April 28, 2016, 10:41:03 am
content: Quote from: MrSlack on April 28, 2016, 08:28:58 amWriting software on that scale is crazy. No wonder you had problems. Hell, mature products have bugs. I can't imagine that would have been usable for years. Maybe I exaggerate a bit, but man, there's a lot of corner cases that are going to come out of the woodwork.Quote from: MrSlack on April 28, 2016, 08:28:58 amHere’s the thing, no ERP vendor develops their product in a vacuum. Every business develops its processes that way though.I know I’m generalising, but pretty much all the time the business benefits by doing a smarter process assisted by the software. Larger companies require more rigid processes. Choosing software of the wrong scale is going to be painful. I’m looking at you SAP. But only empire-building wankers select software that’s a bad overall fit. When you do your investigation with an open mind you will find a suitable candidate.Quote from: MrSlack on April 28, 2016, 08:28:58 amAnd writing a whole system is better? What was the budget? And what compromises did you have to make?You simply can’t please all the users all the time. Further, what the user wants and does is only useful if it fits the big picture. Jo the sales lady wants to have all of her stuff in stock all the time. She needs it. Because she neither knows nor cares about the cost of inventory. She cares about commission. Just saying.My point is, don't customise it. Your business process isn't awesome or special, it's just an abortion that evolved for years as the company grew and works 95% of the time. Maybe less. The company is always wrong. The software isn't necessarily ideal but it's almost always better, if different from, your current process. Middle managers should have their bonuses clipped in proportion to the changes they ‘need.’If you haven't got that attitude Oracle really wants a chat with you. You can have an afternoon on Larry's boat.Quote from: MrSlack on April 28, 2016, 08:28:58 amFuck the ideology! Although some of the manufacturing theory is interesting. I think there are too many people emotionally attached to broken processes and romantic ideals. In this part of the world you can’t even find a purchasing manager who’s authorised to buy things, let alone comprehend any kind of forecasting theory.Automate. Install software. Do more with less people. Looked at any economics theory lately?Quote from: MrSlack on April 28, 2016, 08:28:58 amThe most value I’ve seen is stock write-downs, and transfer loading done in excel.I’ve only seen one small company with custom software outside of macros. A mechanic wrote some mortgage broking software in dbase. I was not impressed. But they had a high margin product and it did work until you touched it.Quote from: MrSlack on April 28, 2016, 08:28:58 amFrom a management perspective. SOX compliance much? But I was thinking of bigger companies when I wrote that.Quote from: MrSlack on April 28, 2016, 08:28:58 amTransactions, mate. They’re there for a reason.Quote from: MrSlack on April 28, 2016, 08:28:58 amVery much so!Quote from: MrSlack on April 28, 2016, 08:28:58 amThe user can sort out the printer as well as the software guy. in 2016 why the fuck is toner still an IT issue? They manage OK at home don’t they?The biggest productivity killer in software development is interruptions. I’m telling you, the guy will leave if you don’t let him get on with the software. If you want incremental improvement go and talk to the management accountant, who spends his day with his finger up his arse, and get him to write you a macro. As soon as you get the programmer dicking around with infrastructure you’ve wasted him.

author: apelly
author_rank: Unknown
timestamp: April 28, 2016, 10:54:58 am
content: Quote from: amspire on April 28, 2016, 09:07:43 amYou say a lot of sensible things.Don't agree with the data export though. Exportisa doddle compared to the initial take on, but you know you can get it out. By the time any sort of export is needed the thing'll be customised up the wahzoo and whatever you wrote will no longer work out of the box.Biggest issue in my opinion is the ability to roll back to the original system in the first few days. You can do all the pilots you like, but they didn't predict my one infant server fatality three days in. Dickhead in IT hadn't done a backup the previous night either. All worked out in the end.

author: amspire
author_rank: Super Contributor
timestamp: April 28, 2016, 11:28:16 am
content: Quote from: apelly on April 28, 2016, 10:54:58 amThe problem is that in a flexible ERP system, the data that was in one CSV files ends up spread across 30 tables. If you export as 30 tables, you have to recreate the ERP schema to reassemble it.Say in the original data, you had a client customer. You had the main contact and their details.In Odoo, you have a record for the company. You have a second record for the Contact person and he has a link to the company. Each person can have multiple addresses, so addresses are in another table. That contact person could be the contact for other companies so you can have multiple links from the contact person. In the addresses, instead of including a City/Suburb field, you can link to a table of City/Suburbs. Now each of them has a postcode/zip code, but you can have multiple suburbs under one postcode so that is another table linked to the city/suburbs table. The more flexibility the ERP has, the more fragmented the data will be. Again Odoo rationalizes things (from memory of OpenERP) and puts companies, contacts, staff all in one table. Makes sense as a member of staff can also be a customer. A customer contact can become a member of staff. A member of staff however links to totally different tables then does a customer. When there are thousands of tables and relationships you do not have a clue what half of them do, the thought of simply exporting the data is no longer that simple. Exporting is dead simple. Exporting in a useful form is not.ERPs can fail spectacularly and with the very complex schema's and data rationalizations in modern ERP systems, I like to have the useful exports in place before the ERP is in use. I don't want to be working out how to extract data from thousands of cryptic linked fields in thousands of tables at the point the ERP has crashed while the CEO is crying about loosing $100K a day. If the emergency plan B is to use Excel spreadsheets short term in the case of a disaster, I want to be able to press a button and make those Excel CSV's immediately.

author: Wilksey
author_rank: Super Contributor
timestamp: April 28, 2016, 11:56:24 am
content: We have an in house "crafted" turd of a database, not even an MRP / ERP sniff of a system, just a big ass pile of database poo.They won't cough up the £££'s for a proper system.

author: apelly
author_rank: Unknown
timestamp: April 28, 2016, 12:38:49 pm
content: Quote from: amspire on April 28, 2016, 11:28:16 amIf I accept that, then everything else you say is sane and reasonable.Does a spectacular failure not cause a restore from backup? Are you talking about some sort of insidious, slow failure?I would beextremelyuncomfortable, say, switching to spreadsheets for a couple of days and then switching back. Better to be down for a day to restore and take paper orders as best you can than risk the mayhem of importing a broken spreadsheet.I feel like I'm missing something foolish.

author: amspire
author_rank: Super Contributor
timestamp: April 28, 2016, 01:13:07 pm
content: Quote from: apelly on April 28, 2016, 12:38:49 pmMany of the ERPs are big - millions of lines of code. The ERPs that are this size are this big not so much from the actual logic that does the work, but from all the tools that automatically rebuild the database tables when extra fields are added and when extra relational definition files are added that can add extra complex functionality. If you have ERP with code that allows you to fully customise the ERP for most companies needs without custom programming, you have something that is potentially much more manageable, much more upgradeable and potentially more reliable but you have to accept the complexity that comes with this code.Any program this size can has a chance of a big bug. The fancy code may have corrupted tables in a way that will be a major job to fix.Backups are great if the problem is only a database corruption. If there is a serious program bug, until you know what it is, all you can do is trial and error. It may be me, but I like to be prepared before disaster hits. I do not like having the companies existence based on the assumption that a huge piece of code is going to be perfect. I am sure that there are IT guys who just accept that disasters happen, and if they do, they will have to go without sleep for two or three nights until the panic is over. I just detest those kind of panics and I like my sleep.The reason I mentioned spreadsheets is that a lot of companies that are first time ERP users think "SPREADSHEETS" when there is an IT problem. It is the universal solution to everything.

author: Scrts
author_rank: Frequent Contributor
timestamp: April 28, 2016, 05:51:01 pm
content: A very interesting thread!I wonder how much is expensive in terms of commercial systems? I see that SAP offers 150$/month/user. SAP is very well known system I'd say. Is it considered expensive?

author: ade
author_rank: Unknown
timestamp: April 28, 2016, 06:42:23 pm
content: A mid-size business, say $100mm in annual revenues, might spend $5 million on an ERP implementation or about 5% of revenue. This would be in-line with other strategic projects the business might take on.Smaller businesses might spend a higher proportion of revenue on an ERP (and other projects)... maybe 10% to 20%, which might be justified to achieve growth.

author: nctnico
author_rank: Super Contributor
timestamp: April 28, 2016, 07:37:40 pm
content: Quote from: apelly on April 28, 2016, 03:59:26 amThis is very good advice! Fitting your business to the software also means you'll be streamlining your business because -if the software exists for a while- it will be based on good business practises.One of my former employers insisted we needed a custom made planning tool. So instead of putting a very bright intern on much needed software development for a product a planning tool got developed. It turned out it wasn't so easy so extra features had to be added making it just as difficult to use as a commercial tool.

author: nctnico
author_rank: Super Contributor
timestamp: April 28, 2016, 07:44:39 pm
content: Quote from: amspire on April 28, 2016, 11:28:16 amIn theory you handle the relations in a database abstraction layer which can be SQL functions inside the database. For a more complex project I have designed/used such a setup where the client software was talking to SQL functions only. This allowed the database tables to be completely different (which the database guy did at some point) without needing to change the client software. Simple import/exports can be made from similar SQL functions. The point is: you can create a database in a way that the internal table complexity is completely hidden from the outside world.

author: Smokey
author_rank: Super Contributor
timestamp: September 01, 2024, 07:33:05 am
content: ... Well this is now something I need to deal with again, unfortunately.The circumstances have changed a little and the functionality is much more basic, but I still need a software solution for manufacturing.Has anyone recently tried to use one of the big accounting platforms that claim some manufacturing features and support, like Zoho specifically?

author: RJSV
author_rank: Super Contributor
timestamp: September 01, 2024, 03:11:49 pm
content: Back in the day, we had that OTHER building, at Qantel (in Hayward, CA.), considered more of a marketing deal, for the MRP software customers. Called QMRP there are some reminders of the enterprise software, kept alive during the MDS QANTEL downward decay, as a system manufacturer.While factory operations got shuttered, there has been some limited hold-out customers that were either locked-in, liked the features enough to not switch software vendors. Some of those hold-out customers had invested in custom features, for inventory control.Of course that's an increasingly small and special niche.