This action might not be possible to undo. Are you sure you want to continue?
Curious and warmhearted, we always had great conversations. He approached me with a perplexed look. “Larry” he said, “I am looking at my cycle count reports and it is showing I have greater than 99% accuracy. I have never had accuracy that high.” I looked at his reports and verified his findings. He was correct. I didn’t have a ready answer, these things always take time and research. My duties for this project involved development of UPK content for the user community. Normally consultants aren’t used for these jobs but they were in a tight spot and needed the content developed quickly and accurately. A few days after my conversation with Bill, I began the process of mapping the Cycle Count process within UPK. Since Oracle had already developed much of the content for R12, I was able to leverage it somewhat for the base work of ABC compiling, Cycle Count Creation. When I got to the sections on cycle count entry and adjustments, I decided to ask end users to walk me through their process. Mike was busy and really didn’t have much time for me to talk about how he does his job. I told him what I was trying to accomplish and I really needed his help to verify how he was performing Cycle Counts. He walked me through the basic process and began to explain how they handled adjustments. Certain adjustments, depending on ABC class were processed using Miscellaneous Issues and Receipts. This raised a red flag in my head but I continued with my work. I did confirm the accounts used in the Misc. Receipts and Issues were using the same account used in the Cycle Count adjustments. I thanked Mike for his time and collected my notes. I returned to my desk and began the process of capturing the user screens and actions in UPK Developer. Not to get too far off subject, UPK Developer is a great tool. Prior to its existence, most consultants resorted to manually created Word documents or Oracle Tutor. Neither of them holds a candle to the capabilities of UPK. One of my favorite findings as a result of using UPK is, it give me the excuse to work closely with users to fully understand their processes and reasons for doing things the way they get done. Quite often, they are not the same as management expects. I did a little more research to make sure they were using Miscellaneous Issues and Receipts to adjust inventory stock levels. A few queries into the Material Transactions confirmed what I had been told. I was now ready to go back to Bill and share the news. “Bill” I said, “I think I found the reason your cycle count accuracy is so high. The Miscellaneous Issues and Receipts you are using to adjust inventory aren’t considered in the cycle count accuracy calculations. It ONLY considers cycle count adjustments in those calculations.” Bill explained to me they used the same adjustment account for all transactions and he assumed it was enough to factor into the calculations. I assured him it was not. I went on to explain why I didn’t like the idea of using Miscellaneous Transactions at all in a production environment. I told him it is a little like cheating since Oracle provides almost all other transactions needed to resolve issues with inventory and production. He explained he was informed by past consultants, using these transactions
was alright. I explained most consultants focus on implementations and not production support so they don’t get to see the consequences of their recommendations. This experience turned out to be a bit sobering for Bill. He, like many other recent Oracle users simply blamed the applications for their problems. Oracle was the new mysterious entity where problems happened and never got fixed. I told him it is best to think of Oracle as a big calculator. As long as you enter the numbers correctly, it always provides the right answer. It helps to take the mystery away from Oracle. As our conversation continued, it became a bit more philosophical. Being around Oracle as many years as I have, you begin to see the trends users develop with a new system. One is to do it the same way over and over no matter what. Usually, clients want the process to emulate whatever their process was prior to implementing Oracle. Change is hard. Bill explained it would be hard to explain to auditors the reason for the cycle count accuracy decrease. I asked him if it was hard to explain the cycle count accuracy increase to the auditors. He said, “Not at all. They were thrilled.” I asked, “You mean they didn’t find it odd your cycle count accuracy increased just because you switched your system to Oracle?” They just assumed Oracle must be a better system. I can’t say I was surprised. I am just glad it didn’t get written up in Profit magazine and attributed to Oracle’s superior applications. Bill and I continued our conversation. He explained the cable building operations. Quite often, more cable is used then is called for in the BOM. In those cases the planners change the material requirements in the job. This drives new requirements the next time the plan is run and over time a shortage develops for the cable. I asked if the use of more cable was consistent or sporadic. He said it was consistent. I asked if anyone had created a non-conformance report against the situation. They had and the corrective action was to issue more cable. I explained that is not really a corrective action because it didn’t get to the root cause of the problem. A root cause would be the engineer didn’t allow enough material in the BOM, or the cable machine generates more scrap than is considered by planning or the cable operator isn’t training properly and allows too much scrap in the process or they are making the cables longer than they should. As with many businesses, they are too busy producing than to consider how well they are producing. I explained to Bill, the problems he is experiencing are the same problems most companies fixed back in the 80s. With initiatives like Just in Time, Total Quality Management and more recently the move to Lean Manufacturing, companies resolved these issues and moved on to other problems. This surprised Bill since his company had established quality practices with black belts and Lean manufacturing teams. I told him I had seen this before. Many times those efforts focus on the perceived problems driven down from management or on problems associated with complex build processes. It is natural, engineers and production specialists tend to focus on and fix things they know a lot about. Unless upper management sees cost issues with the area, no one seems to worry about a little cable operation in the back of the warehouse.
“Bill, you need to understand you can’t hide problems in Oracle. You need to let Oracle tell the truth.” I went on to tell him that companies have to measure costs and assign resources based on those costs. The truth is no company ever has enough resources to do all it needs to do. That is why we use statistics to tell us where the worst offences exist and bring those resources to bear against them. Never be afraid of the numbers from Oracle. It is making a statement to guide you to a solution. You just have to be willing to see it. I seem to be giving this speech more often than I should these days. I see so many companies with the resources and knowledge they need but failing to apply them as they should. Well, maybe writing it down for others to read will help. Author: Larry Sherrod Website: www.larrysherrod.com Share this article as much as you wish but please do not modify or change the content.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.