Posted by Randy Flamm on Wed, Sep 01, 2010 @ 07:50 PM
Single Database – Single Source ERP for Manufacturing
A Little History - 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.)
Posted by Liz Alflen on Thu, Aug 26, 2010 @ 05:52 AM
I can't say I have it all figured out, but I know there's an answer to the balancing game and it's mine to find.
Sometimes I like being at work better than I like being at home and other people have commented on this phenomena to me as well. At work, responsibilities are somewhat orderly or at least defined in some way, whereas all kinds of crazy things can go hay-wire at home. Mates, spouses, kids, cooking, household appliances, neighbors, "inventory" - all kinds of surprises can be waiting for you upon your arrival back at your happy home.
Granted, all kinds of surprises can be waiting at work, too, not all pleasant, but a person can say, "at least I don't live here".
Well, that's only sort of true.
We all know we spend more waking hours at work than we do at home. And depending on where you are in your life, home can represent a near equivalent (given your situation) of the stress represented at work.
So why do we do this? Because work provides income we can use to feather our nests, or perhaps to enjoy a vacation: those blissful hours and days spent away from the office and sometimes away from the routine at home, too. It's not that you can ever really get "away" from your responsibilities, but you can hold them at bay for some defined period of time.
That is, unless work calls you away from vacation, or you just can't resist logging on to your manufacturing ERP system from your BlackBerry or home computer. It happens to all of us at some time ("Honey, I just want to check my email real-quick, just give me a few minutes"). Your BlackBerry can deliver your email to you anywhere and it can deliver your Manufacturing ERP to you anywhere, too (ex., EnterpriseIQ for the BlackBerry). Is this a blessing or a curse?
Communication is undeniably more efficient than every before and we rely on it. Is it so bad to take a call when you are supposed to be "off"? If you have the information available to make the necessary decision in the most efficient manner, you can avoid a bigger problem to be waiting for you later upon your return to the office. If you can access information while sitting by the pool or on a beach, does it alleviate your worries? There may be no nicer place to check the status of your orders or your meeting schedule in CRM than pool- or beach-side.
It may seem that you missed part of your vacation time, but to avoid problems lurking, I don't mind. I have an investment in my work, and work supports any time I can get away from it, whether at home or away, so I'll take the benefits along with the drawbacks. Don't take away my vacation and don't take away my BlackBerry!
Posted by Diane Ramaglia on Tue, Aug 03, 2010 @ 08:40 AM
Some people do not realize the impact of what happens within an Enterprise Resource Planning (ERP) system when your inventory is not accurate. And when I say accurate; I mean at least 98% accurate.
A common issue at companies is they do not have the disciplines in place to assure inventory accuracy. Some common pitfalls of inventory inaccuracy would be that bills of material (BOM) are incorrect. I have a history working with plastic processing (along with other types of manufacturing) and one thing that throws off inventory is incorrect part and runner/sprue weights in the BOMs. A lot of manufacturers also do assembly/secondary processes and the quantity per could be incorrect in the BOMs. There are two different ways I have seen consumption of materials being completed during production reporting.
One is the function of back-flushing material based on parts produced based on your BOM. Many systems that I have used allow for the back-flushing of their materials when they report production. This is the time when you can catch inventory issues due to BOM inaccuracies. You can check your work center location inventory and verify at the end of shift if the computer matches the actual inventory counts. If not, start weighing your parts and checking your BOM.
The other type of system out there allows you to issue material to a job/work order. The downside to this is you can’t see this inventory since it is typically removed from any on-hand quantities. You have to reconcile at the end of the job/run.
Another common factor with inventory inaccuracy is that your users are not moving material to proper locations based on procedures. If your system allows a location to go negative, it's time to check a negative report and get to root cause of what may have cause this. It can come down to material not being moved or inaccurate BOMs. I hate repeating myself on the BOM issue but I have seen issues time and time again. In fact, I have recently worked with two customers who are struggling with negative locations. If a location is negative and other locations are positive, what is your true on-hand quantities? One can only guess.
What happens within your ERP when your inventory is inaccurate? The system might not generate work/job orders for customer orders if it thinks you have finished goods/work in process stock. If you don’t have the inventory or the work orders you will likely miss shipments. Customers won’t be too happy if you don’t have on-time shipments. In addition, if the work orders are not generated the system will not tell you to purchase material. It’s a downhill spiral from here.
Speaking of purchased material, let’s talk raw materials and purchased on-hand balances. If these are not correct, you will not have product to produce your manufactured parts. You will possibly be expediting material which can become very costly to your company. On top of that, it can cause havoc on the production floor. A scheduler has to decide to keep running parts that might not be due for over a month or lose costly production time by keeping the machine in downtime.
Think of the breakdown for downtime costs due to material inaccuracy in this way: If a machine rate if $50 per hour and your machines sits down for 48 hours, the cost is $2,400 for two days. If that happens weekly, the annual lost utilization is $124,800. That is more than a lot of peoples' salaries on the production floor. For this annual cost, you can justify hiring people to fix the inventory issues.
Add to this cost, other factors such as the cost to deal with machines that need to be changed over quickly to fill an order because your finished goods on-hand counts were inaccurate. How much does it cost your company when you have to switch over jobs that you were not thinking you had to run? What is the time it takes to switch over jobs? Depending on the jobs, setup times can range from one hour to ten hours. That is a lot of downtime for changeovers.
What can you do to start fixing these issues?
- Have the right people handle inventory management – they have to care and be analytical.
- Training/education– you need to make sure that people know what they are supposed to do in the system and what the impacts are if they don’t.
- Get to root cause of the inventory issues and have a corrective action to prevent this from happening again.
- Track the downtime costs due to inventory issues (waiting on material, changeover/setup)
- Create a process to validate bills of material.
- Ensure people are following their procedures.
I hope this helps some of you out there in the manufacturing world.
Posted by Liz Alflen on Thu, Jul 29, 2010 @ 02:33 PM
One unfortunate morning a few years ago, I got an early call at home from my boss informing me that my 1st floor office had been broken into and my computer was stolen. It so happened that I had left my laptop on my desk, hooked to an external monitor, a VOIP phone and a printer. When the burglar alarm/noise-intrusion sensor went off, scaring the intruders into a more heightened sense of urgency, they made a quick grab for my laptop, but ended up dragging along the monitor, the phone and the printer. Pieces of my printer (the paper tray, paper, little broken plastic pieces) were strewn across the parking lot. By the time the police arrived on the scene, the intruders were long gone, miscellaneous plastic parts left behind, and they were likely on the highway headed out of town.
Not surprisingly, I panicked at this news. What about all my information? My reports? My data? What would I do? How painful would this be?
The local police made note of all the pertinent information but offered little hope for recovery. Our IT department made available an alternate computer for my use while ordering me a new one; I received the usual talking-to about backing-up my data. When I finally got back to work, I quickly found that I wasn’t in too much trouble.
I still had access to our EnterpriseIQ ERP system! They couldn’t take that away from me. I can access the system from anywhere, log in, run a report, review documents, respond to workflows - from anywhere.
Until that day, I hadn’t realized that the bulk of any day’s work was not dependent on my personal computer, my stored information or my reports. Most of any day’s work could be completed by accessing information in EnterpriseIQ, views or reports.
For my purposes related to both Administration and HR, areas I access on any given day include:
And on and on. It was almost disappointing. My data isn’t even really special (although my particular role is); I’m replaceable by someone else (or perhaps multiple individuals) who is (are) trained in the system, can access the same information, and plan equivalent courses of action. One of the tremendous values in having a comprehensive ERP system is in the ease with which I can fulfill my responsibilities, independent of specific hardware or location, as well as the ease with which a “backup” could do the same.
I still try to remember to back-up the data on my personal computer, but I’m confident that most of the information I need at work will be available to me when I need it. It’s nice to NOT worry about something!
Posted by Diane Ramaglia on Tue, Jul 06, 2010 @ 07:10 AM
There is one thing that I am aware of when a consultant comes on-site to assist with an Enterprise Resource Planning (ERP) Implementation, they ask "why" a lot.
I was a customer not so long ago and our project team would get a little frustrated when the consultant kept asking them why we did things a certain way. Now that I am a manager of a Professional Services Group and I have been a consultant for an ERP vendor for the past 6 years, I know why they ask why. They want to understand the reason why you may be doing something a certain way when utilizing your current system and why you might want to do it the same way in a new ERP system. Sometimes it takes your consultant asking "why" five times before they know the "real" reason is discovered of why you may be doing something a specific way.
Manufacturing Resource Planning (MRPII) systems have been around for a long time and a lot of companies have been utilizing the same system for twenty plus years. Older systems definitely have limitations compared to the newer systems available. Older systems often can't be upgraded because of all the numerous changes they had customized way back in the stone ages (kidding of course!). Knowing this, we realize that older MRP systems had limitations that forced users to do things a certain way.
Here are some common answers that consultants get when it comes to asking "Why":
- We have always done it that way. It works for us so why change it.
- I wasn't around when they implemented this system so I have no idea why they've been doing it that way.
- That's the way I was shown so I don't question why we are doing it that way.
- The best one is: Because I want to do it that way!
An ERP consultant is not your enemy; they are there to assist you with best business practices on maximizing the ERP system. They are asking questions to better understand your processes/procedures that will allow them to help you utilize your "new" system. They are not to questioning you just to question you; they want to better understand how they can help you. We understand that you may have done it that way for the past 20 years but things have changed and ERP systems have come a long way in the past 20 - 30 years that you no longer have to process data the same way.
Here is an example of a specific process that a customer had requested recently: They wanted to be able to put a note in a location to explain why they did not want to ship a specific lot of product and they wanted this note to follow through the system. After asking why they needed this note, the main reason was because they did not want to be able to ship this product. Solution, instead of changing the program at a potential thousand dollar cost to the customer, we discussed with them adding an attribute that would simply not allow them to ship this lot. Not being able to ship a lot is much easier to address than changing all the programs that were affected by any inventory transaction within the system.
So think about this and do yourself a favor the next time you are asked to answer the "why" questions because you just might be pleasantly surprised by the results!