Single Database – Single Source ERP for Manufacturing
Single Database – Single Source ERP for Manufacturing
A Little History of Lessons Learned
From the beginning of my career in manufacturing I saw the need for a comprehensive system to control the whole process from start to finish. It was clear to me that a single database was the way to go. One version of the truth was very illusive when it came to manufacturing information – how to make a product or even how many to make and when. There were many places to look for answers and sometimes none of them were correct.
Microcomputers were just coming out and I was really interested in them. My friend Dewayne Clinton and I attended the Home Brew Computer Club meetings held in an auditorium at the Stanford Linear Accelerator Center. I thought it would really be cool to create such a system using a microcomputer.
I started programming around 1982 on 8 bit machines using CPM/dBase II while working at a custom manufacturing company in the San Francisco Bay Area. I was a production foreman and my future wife worked in the office. We had to take orders, purchase raw materials, and manually schedule the shop resources including machines and labor. Our boss was very demanding when it came to production performance and reporting. He insisted on have a detailed production report including profit contribution on a daily basis. Performing these tasks manually was very time consuming and prone to error since everything could change overnight. The manufacturing control system I developed was infinitely more capable and user friendly than their current IBM System 36 RPG punch card-input based system in use at the time. This is when I developed many of the same demand-driven concepts in use today in the EnterpriseIQ ERP products.
With the new system all we had to do was make sure the sales orders were entered and the finished goods/raw material perpetual inventory was kept up by doing all packing slips and receivers from the software. We would start the MRP engine (we called it IRV) and go to lunch. When we returned the output told us the parts to run and the materials to order. Time-phased calculations that had taken two or three days were completed in an hour. OK, sometimes we took an hour and a half for lunch but we got more done with much better accuracy than any other time in the history of that company.
In 1986 I went to work for GE Plastics as a tech service rep based in the LA area. With this job I didn’t need to worry about scheduling production or dealing with employees. Through that job I met many owners and managers of manufacturing companies who were struggling with the same problems my wife and I able to handle via computers and software when we worked in the Bay Area. I would mention (brag about) this at customer dinners and lunches. Soon I got called on it by a husband and wife who owned a custom injection molding company in the LA area. The conversation went like this: “Wow! That system sounds great. Why don’t you write the same thing for me?” I responded that I couldn’t possibly because it was a lot of work and I really liked my job at GE. After a few more conversations I let them know that I would write a system which would do the basics including a MRP engine, with the understanding that I would sell the same system to other companies as it was developed. I started programming in August of 1988 on nights and weekends.
Back then DOS was the operating system of choice. Hardware was cheap and local area networks were making their debut. The Clipper programming language offered a familiar dBase syntax and .dbf file storage system. CPU clock speeds and storage capability were increasing all the time so I figured that if I wrote a comprehensive system, the hardware would come.
In 1989 my wife and I quit our jobs, mortgaged the house and started IQMS (then known as IQ Management Systems). My objective was to develop an all encompassing manufacturing software system (long before the term ERP was coined). I envisioned a software system which provided the tools and automation necessary to enable the smartest manufacturing operations possible.
We found ourselves with over 100 customer installations by 1996. By then, I was no longer programming but took on the architecture and design of the manufacturing modules of our product named IQ/Genesis. We had complete Accounting, Inventory, MRP, Finite Scheduling, RealTime Machine Monitoring, Preventative Maintenance, Payroll and Time and Attendance modules. File based data storage systems are inherently weak when run in a multi-user network environment. “Re-indexing” data files became a way of life when the network wasn’t stable. It was always hard to explain to your customer that the problem was their hardware – not your product. In spite of the weak foundation the product was a hit with our customers – most of which we still have today. Service had a lot to do with our customer retention (as it does today). Coming up with software solutions to customer problems is one of the reasons the product had so much depth. Software updates came fast and furious and were always at no extra cost.
At this time it was evident that DOS was dead. We were starting to get hammered in the market place by systems with far less functionality that were Windows-based. Going to a demo with a DOS based system was like going to a gun fight with a knife. IQMS as a company had to decide if we were going to continue to grow or just survive on loyal customer maintenance contracts until they went away. It would have been a slow death to my vision of the single-source/single-database all-encompassing manufacturing software system.
It was decided that we would “burn the ships” and go forward. We made the decision to abandon the millions of lines of IQ/Genesis code. We threw everything away except the concepts developed and the lessons learned over the prior 7 to 8 years. It was time to pull out the stops and come up with a bullet proof foundation to build the next generation of IQMS ERP products…..
(I’ll continue the story of how IQMS got where it is today in my next blog.)