Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Truth in Oracle (a manufacturing perspective)

Truth in Oracle (a manufacturing perspective)



|Views: 266|Likes:
Published by Larry Sherrod
This is an article about Oracle applications and some of the things you find out when implementing the applications. You can find more of my documents at www.larrysherrod.com.
This is an article about Oracle applications and some of the things you find out when implementing the applications. You can find more of my documents at www.larrysherrod.com.

More info:

Published by: Larry Sherrod on Jan 22, 2009
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC or read online from Scribd
See more
See less


Truth in Oracle
Bill had a fine manner about him. Curious and warmhearted, we always had greatconversations. He approached me with a perplexed look. “Larry” he said, “I am lookingat my cycle count reports and it is showing I have greater than 99% accuracy. I havenever had accuracy that high.” I looked at his reports and verified his findings. He wascorrect. 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 neededthe content developed quickly and accurately. A few days after my conversation withBill, I began the process of mapping the Cycle Count process within UPK. Since Oraclehad already developed much of the content for R12, I was able to leverage it somewhatfor the base work of ABC compiling, Cycle Count Creation. When I got to the sectionson 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 howhe was performing Cycle Counts. He walked me through the basic process and began toexplain how they handled adjustments. Certain adjustments, depending on ABC classwere processed using Miscellaneous Issues and Receipts. This raised a red flag in myhead 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. Ithanked 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, mostconsultants 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 notthe same as management expects.I did a little more research to make sure they were using Miscellaneous Issues andReceipts to adjust inventory stock levels. A few queries into the Material Transactionsconfirmed 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. TheMiscellaneous Issues and Receipts you are using to adjust inventory aren’t considered inthe cycle count accuracy calculations. It ONLY considers cycle count adjustments inthose calculations.” Bill explained to me they used the same adjustment account for alltransactions and he assumed it was enough to factor into the calculations. I assured himit was not. I went on to explain why I didn’t like the idea of using MiscellaneousTransactions at all in a production environment. I told him it is a little like cheating sinceOracle 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 productionsupport 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 recentOracle users simply blamed the applications for their problems. Oracle was the newmysterious entity where problems happened and never got fixed. I told him it is best tothink 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 Oracleas 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 ishard.Bill explained it would be hard to explain to auditors the reason for the cycle countaccuracy decrease. I asked him if it was hard to explain the cycle count accuracyincrease to the auditors. He said, “Not at all. They were thrilled.” I asked, “You meanthey didn’t find it odd your cycle count accuracy increased just because you switchedyour system to Oracle?” They just assumed Oracle must be a better system. I can’t say Iwas surprised. I am just glad it didn’t get written up in Profit magazine and attributed toOracle’s superior applications.Bill and I continued our conversation. He explained the cable building operations. Quiteoften, more cable is used then is called for in the BOM. In those cases the plannerschange the material requirements in the job. This drives new requirements the next timethe plan is run and over time a shortage develops for the cable. I asked if the use of morecable was consistent or sporadic. He said it was consistent. I asked if anyone had createda non-conformance report against the situation. They had and the corrective action wasto issue more cable. I explained that is not really a corrective action because it didn’t getto the root cause of the problem. A root cause would be the engineer didn’t allow enoughmaterial 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 mostcompanies fixed back in the 80s. With initiatives like Just in Time, Total QualityManagement and more recently the move to Lean Manufacturing, companies resolvedthese issues and moved on to other problems. This surprised Bill since his company hadestablished quality practices with black belts and Lean manufacturing teams. I told him Ihad seen this before. Many times those efforts focus on the perceived problems drivendown from management or on problems associated with complex build processes. It isnatural, engineers and production specialists tend to focus on and fix things they know alot about. Unless upper management sees cost issues with the area, no one seems toworry about a little cable operation in the back of the warehouse.

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->