I've been reading 'Start With Why' by Simon Sinek and while I think the entire book is fabulous, one thing that stood out last night was the idea that without Trust people are unwilling to take risks. The idea is that even way back, hunters and gatherers had to trust their community to watch over their loved ones while they would go out in search of food.
They knew that if it rained someone would help get their family to shelter, they knew if it got cold someone would light a fire to warm the group, overall the community lived by rules and because of that they felt comfortable taking the risk to hunt because they knew that their group would do XYZ. If they didn't trust the people around them they wouldn't have been willing to leave their families 'in the cave' with a bunch of crazies. It is the trust they had in their community that made them comfortable with taking the risk to leave and hunt.
The same is true in the workplace. Employees need to be able trust their manager, co-workers, and company before they are willing to take risks, for example like presenting innovative ideas. If there is no framework or established pattern that employees can easily recognize then presenting something new is now a huge risk because you would have no idea what the repercussions would be. Without that trust the majority of their time will be focused on trying to figure out how to do work without getting into trouble or rocking the boat.
However, if the community in which they work plays by a set of known rules, the employee knows what to expect and can craft their creativity into the culture in which they work. This doesn't eliminate risk but it greatly reduces it from the employees point of view because they can more closely predict the response from management or others on their idea and thus can feel more comfortable thinking outside the box.
Management needs to ensure that they are consistent in what they do. That consistency allows employees to understand the 'set of rules' that are used on their team and, hopefully, begins to build trust within the team. Once trust exists employees become more creative and more willing to take risks (hopefully for the good of the team and company). But without that trust, the majority of employees avoid any risk by doing just enough to stay out of trouble.
Tuesday, October 1, 2013
Wednesday, September 26, 2012
Process Knowledge = Efficiency
Not understanding your company’s business processes has to be considered a cardinal sin, especially during this economic recession. For the past five years the majority of companies have either downsized their workforce or issued hiring freezes to cope with the economic conditions. Because of this downturn, sales forecasts and revenue expectations at most companies are tempered, however the number of operational improvement and cost saving projects seem to be increasing in an effort to offset the decrease in sales. Essentially, senior management is demanding that Operation’s increase their workload without increasing their workforce. So how does understanding your company’s business processes help solve the problem?
Historically, the people who cared most about what affect department A’s operations had on department B’s were project managers. The project manager would scope out dependencies and document task sequences. Working with project managers offloaded the need to understand any task that fell outside your immediate circle of responsibility. With good project managers this solution works well. The problem arises when the number of projects is greater than the number of project managers. By having management demand a multitude of cost saving projects you’ve increased the demand for project managers without increasing the supply. It’s important to note that a project manager, as described above, isn’t necessarily an employee assigned that job title but instead the person who spearheads the project.
With limited or no project management help it now becomes imperative for employees to understand, at least at a high level, your business process flow. That’s not to say they need to fill the role of a project manager but what it does mean is they need to understand how they get their inputs and who uses their outputs. These inputs and outputs are not only physical, but include things like accounting information, database code, shipping terms, and lead times. As employees begin to understand these processes and how their job affects those downstream, a host of benefits arise. These benefits might include; cross department collaboration, decrease in project implementation time, improved time management and multitasking, and increased visibility and awareness.
Take, for example, a buyer who’s been told he needs to reduce the costs of submitting RFP’s to suppliers. This buyer might turn to IT for web option to facilitate this process decreasing emails and phone calls effectively reducing the cost of submitting the RFP. If the buyer understands the IT development process, he’ll know upfront the inputs he’ll need to provide include; business requirement documents, supplier data to be used in development, security requirements, and webpage design ideas. If the buyer understands the process he’ll also know that somewhere in the middle of the project IT is going to provide a beta version of the solution as an output that he’ll need to critique, test, evaluate and summarize as an input back to IT so they can finish the process.
By knowing the process the buyer reduces development time, he understands he can work on other projects until IT has the beta version ready, and he knows when that version is ready he needs to allocate some of his time to testing. Essentially, because he knows the process he becomes more efficient. That efficiency is the key to weathering the storm during this recession. With more efficient employees; your reliance on project management greatly decreases, it’s easier to accept the workload that comes with cost savings projects, and hiring freezes don’t hurt as much. In the end, you see why not understanding your company’s business processes has to be considered a cardinal sin, especially during this economic recession… because it severely limits your overall efficiency.
Historically, the people who cared most about what affect department A’s operations had on department B’s were project managers. The project manager would scope out dependencies and document task sequences. Working with project managers offloaded the need to understand any task that fell outside your immediate circle of responsibility. With good project managers this solution works well. The problem arises when the number of projects is greater than the number of project managers. By having management demand a multitude of cost saving projects you’ve increased the demand for project managers without increasing the supply. It’s important to note that a project manager, as described above, isn’t necessarily an employee assigned that job title but instead the person who spearheads the project.
With limited or no project management help it now becomes imperative for employees to understand, at least at a high level, your business process flow. That’s not to say they need to fill the role of a project manager but what it does mean is they need to understand how they get their inputs and who uses their outputs. These inputs and outputs are not only physical, but include things like accounting information, database code, shipping terms, and lead times. As employees begin to understand these processes and how their job affects those downstream, a host of benefits arise. These benefits might include; cross department collaboration, decrease in project implementation time, improved time management and multitasking, and increased visibility and awareness.
Take, for example, a buyer who’s been told he needs to reduce the costs of submitting RFP’s to suppliers. This buyer might turn to IT for web option to facilitate this process decreasing emails and phone calls effectively reducing the cost of submitting the RFP. If the buyer understands the IT development process, he’ll know upfront the inputs he’ll need to provide include; business requirement documents, supplier data to be used in development, security requirements, and webpage design ideas. If the buyer understands the process he’ll also know that somewhere in the middle of the project IT is going to provide a beta version of the solution as an output that he’ll need to critique, test, evaluate and summarize as an input back to IT so they can finish the process.
By knowing the process the buyer reduces development time, he understands he can work on other projects until IT has the beta version ready, and he knows when that version is ready he needs to allocate some of his time to testing. Essentially, because he knows the process he becomes more efficient. That efficiency is the key to weathering the storm during this recession. With more efficient employees; your reliance on project management greatly decreases, it’s easier to accept the workload that comes with cost savings projects, and hiring freezes don’t hurt as much. In the end, you see why not understanding your company’s business processes has to be considered a cardinal sin, especially during this economic recession… because it severely limits your overall efficiency.
Saturday, November 20, 2010
Focus and Happiness
Just read an article that I really enjoyed. The article, Will Focus Make You Happier, talks about how when someone is focused on a task they tend to be happier than when they are kind of floundering. I found this article to describe my mood at work to a T. When I am focused/invested/engaged in what I'm doing I find that I am much happier than when I'm not. It's interesting, though, that I often find it very difficult to get myself engaged in a new project. It's hard to find the energy to get things started but after reading this article is seems like by not investing my energy and focus into projects I'm keeping myself from being as happy at my job. Overall, just kind of a really interesting article.
Friday, August 20, 2010
Another article on our upgrade
After writing the two articles for OAUG Insight about our upgrade to release 12 I was contacted by SearchOracle.com to see if I would be willing to write a similar high level summary for their website. Well, that summary is finished and can be found HERE. It is basically just the process we went through to upgrade our system to release 12. If you have any specific questions about that process feel free to contact me (I'll respond to any comments I see on this post).
Friday, August 13, 2010
How Will You Measure Your Life: An article from a Harvard Professor
I read an incredible article this past week in the Harvard Business Review that outlines ideas on how to live your life. Its a completely refreshing view about how there is so much more to life than simply climbing to the top of the 'ladder' and collecting gobs of cash along the way.
I particularly enjoyed the authors view on allocating your personal resources appropriately and consciously creating a culture in your personal life instead of letting circumstances and lack of attention create a culture for you.
I highly recommend reading this article.
How Will You Measure Your Life
I particularly enjoyed the authors view on allocating your personal resources appropriately and consciously creating a culture in your personal life instead of letting circumstances and lack of attention create a culture for you.
I highly recommend reading this article.
How Will You Measure Your Life
Friday, August 6, 2010
Making Progress With MES
It's been a little bit since I've posted anything about our MES project so I thought I ought to try and give an update as to where we currently stand. Back in April I talked about how the hardware that we had was making it extremely difficult to get the scales integrated and functioning with Oracle. There were a couple reasons for that:
1st: The Mettler ID30 product that we own is considered and marketed as a complete dispensing solution and as such Mettler makes it extremely difficult to use the ID30 in any way other than as an end to end dispensing solution. We tried for a couple of weeks to figure out how to send and receive messages from the ID30 but in the end it would have taken much more effort than we felt it was worth. One example showing the difficulty of using the ID30 is, without going into too much detail, the ID30 uses an activeX control to communicate with the scales, in order to pass commands from Oracle to the scale you would have to use the existing activeX commands which meant we would have to develop our own internal application to send and receive information.
2nd: The WMS module is something that wasn't available to OPM customers until release 12 so there was definitely a learning curve on our side as to how setup a device to communicate with Oracle. So in my post back in April I mentioned the possibility of working with Kepware to help us get MES setup but as we looked into their product offering a little more we realized that it didn't make much sense to continue down that path. The reason for this is that the basic request to weigh a product would initiate from an Oracle form via a button push or something like that. Once the button is pushed a request is sent to WMS that essentially says 'talk to the scale'. WMS sends a message to the scale and then receives the response and then that response is entered back into the Oracle form. Well, regardless if you're using WMS or Kepware the process is exactly the same and since we are only sending 1 request (read the scale weight) it seemed really foolish to spend a couple thousand dollars to have a company do that for us.
Those were two of the big issues we've had to deal with as we've moved down this MES path. What we decided to do to get around the ID30 is we've gone ahead and purchased a new indicator (the hardware that is used to view the output from the scales and which connects to the netword) from Mettler Toledo, the model we purchased is the IND780. It's much more user friendly because it was designed to send and receive messages from other sources. We just recently received this product so I'm in the process of setting it up to communicate with the scales and with WMS in a TEST instance.
Hopefully we can get this TEST instance up and running quickly, we are pretty anxious to get the solution in place and replace the formweigh system we currently are using for dispensing.
1st: The Mettler ID30 product that we own is considered and marketed as a complete dispensing solution and as such Mettler makes it extremely difficult to use the ID30 in any way other than as an end to end dispensing solution. We tried for a couple of weeks to figure out how to send and receive messages from the ID30 but in the end it would have taken much more effort than we felt it was worth. One example showing the difficulty of using the ID30 is, without going into too much detail, the ID30 uses an activeX control to communicate with the scales, in order to pass commands from Oracle to the scale you would have to use the existing activeX commands which meant we would have to develop our own internal application to send and receive information.
2nd: The WMS module is something that wasn't available to OPM customers until release 12 so there was definitely a learning curve on our side as to how setup a device to communicate with Oracle. So in my post back in April I mentioned the possibility of working with Kepware to help us get MES setup but as we looked into their product offering a little more we realized that it didn't make much sense to continue down that path. The reason for this is that the basic request to weigh a product would initiate from an Oracle form via a button push or something like that. Once the button is pushed a request is sent to WMS that essentially says 'talk to the scale'. WMS sends a message to the scale and then receives the response and then that response is entered back into the Oracle form. Well, regardless if you're using WMS or Kepware the process is exactly the same and since we are only sending 1 request (read the scale weight) it seemed really foolish to spend a couple thousand dollars to have a company do that for us.
Those were two of the big issues we've had to deal with as we've moved down this MES path. What we decided to do to get around the ID30 is we've gone ahead and purchased a new indicator (the hardware that is used to view the output from the scales and which connects to the netword) from Mettler Toledo, the model we purchased is the IND780. It's much more user friendly because it was designed to send and receive messages from other sources. We just recently received this product so I'm in the process of setting it up to communicate with the scales and with WMS in a TEST instance.
Hopefully we can get this TEST instance up and running quickly, we are pretty anxious to get the solution in place and replace the formweigh system we currently are using for dispensing.
Tuesday, August 3, 2010
Our Upgrade Story
This past year I was contacted by the publisher of OAUG Insight magazine and was asked if I would be willing to write an article about our experience upgrading from 11.5.10 to R12. My original article was to long and so the editor asked if we could split it into two parts. Part one covers how USANA went about upgrading to Release12 and part two details some of the functional issues to watch out for after migrating.
Part One: Page 18
Part Two: Page 15
Part One: Page 18
Part Two: Page 15
Wednesday, April 28, 2010
Integrating Scales: Not That Easy
Here we are about 5 weeks since MES got approved and purchased and I have good news and bad news.
Good News: It was pretty easy to get the basic features of the product up and running in the application. Pretty much you run a couple concurrent requests, setup a few items as dispensable, setup a dispensing area and a dispensing booth and there you go. Okay, maybe its a little more complex then that but not by much.
Bad News: We use scales from Mettler Toledo. A few years ago we purchased their ID30 weigh station solution which is essentially a scale, a monitor, what they call an 'indicator', and a little pc. The monitor runs their ScaleXplorer software which uses an ActiveX control to communicate with the scales.
This week I spoke with Mettler about how to use their scales with MES and the answer is that we still have to use their ELO box (which is the indicator and the little pc) but in order to use them on a network we would have to write a listening app and install it on each ELO box and then also write an app that would use the ActiveX control to communicate with the scales. (FYI I'm not a developer nor do I do much with networks so I'm definitely pushing past anything I know and understand).
So here we are today. We have some internal developers who could probably create these two apps for us but they are swamped with other projects right now and probably wouldn't be able to get to it for another couple months. Next option is to check out a product offered by Kepware which an Oracle developer recommended that apparently is an all in one solution for integrating devices with MES. If that doesn't work or is too expensive I guess I go back to Mettler and see what they can offer.
Wish me luck.
Interesting Article on the different philosophies of Oracle and SAP pertaining to manufacturing execution systems.
Good News: It was pretty easy to get the basic features of the product up and running in the application. Pretty much you run a couple concurrent requests, setup a few items as dispensable, setup a dispensing area and a dispensing booth and there you go. Okay, maybe its a little more complex then that but not by much.
Bad News: We use scales from Mettler Toledo. A few years ago we purchased their ID30 weigh station solution which is essentially a scale, a monitor, what they call an 'indicator', and a little pc. The monitor runs their ScaleXplorer software which uses an ActiveX control to communicate with the scales.
This week I spoke with Mettler about how to use their scales with MES and the answer is that we still have to use their ELO box (which is the indicator and the little pc) but in order to use them on a network we would have to write a listening app and install it on each ELO box and then also write an app that would use the ActiveX control to communicate with the scales. (FYI I'm not a developer nor do I do much with networks so I'm definitely pushing past anything I know and understand).
So here we are today. We have some internal developers who could probably create these two apps for us but they are swamped with other projects right now and probably wouldn't be able to get to it for another couple months. Next option is to check out a product offered by Kepware which an Oracle developer recommended that apparently is an all in one solution for integrating devices with MES. If that doesn't work or is too expensive I guess I go back to Mettler and see what they can offer.
Wish me luck.
Interesting Article on the different philosophies of Oracle and SAP pertaining to manufacturing execution systems.
Friday, April 16, 2010
My Oracle Support Community...
During an OPM SIG conference call (held monthly to discuss different issues or topics that the group is facing) Russ Bayless got on and suggested that we all check out this 'cool new' Oracle Support Community feature found on metalink...I mean found on 'My Oracle Support'. He said the intention was to create a forum (much like it.toolbox) where users would be able to help each other not only with technical questions that you'd normally submit to oracle support but also with setup and operation questions that might be specific to each company.
I liked the idea of this, especially since the Process Manufacturing Community is so small, so I created a profile and signed up for some of the 'communities' on the site. Well, it's been a month and a half now and I'm definitely not impressed. I think the biggest problem is that users don't know about this feature and so there are very few people reviewing questions and forums (ie there is not much participation). I've submitted 7 different questions and have had 0 usable responses so far.
I'm writing this blog post to vent a little I guess but also to make others aware of this feature offered by Oracle. If we can get more people on board it will definitely increase participation. For me, IT Toolbox has been a great resource for very technical oracle issue but not such a good resource for day to day usage like creating approver groups in AME, or finding help understanding supply tolerancing. My hope is that somewhere, either on IT Toolbox or on My Oracle Support Community, I can find a forum where I can get more participation and answers to operational questions.
Here is the link to 'My Oracle Support Community'. You do have to have a user name and password to log in but its the same as you would use to log into metalink.
I liked the idea of this, especially since the Process Manufacturing Community is so small, so I created a profile and signed up for some of the 'communities' on the site. Well, it's been a month and a half now and I'm definitely not impressed. I think the biggest problem is that users don't know about this feature and so there are very few people reviewing questions and forums (ie there is not much participation). I've submitted 7 different questions and have had 0 usable responses so far.
I'm writing this blog post to vent a little I guess but also to make others aware of this feature offered by Oracle. If we can get more people on board it will definitely increase participation. For me, IT Toolbox has been a great resource for very technical oracle issue but not such a good resource for day to day usage like creating approver groups in AME, or finding help understanding supply tolerancing. My hope is that somewhere, either on IT Toolbox or on My Oracle Support Community, I can find a forum where I can get more participation and answers to operational questions.
Here is the link to 'My Oracle Support Community'. You do have to have a user name and password to log in but its the same as you would use to log into metalink.
Wednesday, March 31, 2010
A Quick Oracle MES Implementation Update
The past two weeks I've been working to get a quick setup done of MES so that I can show the MFG departments what to expect, unfortunately my expectations were a bit unrealistic in terms of the simplicity of the setup. I had only minor issues getting the module to work in the application but now we are getting to the device integration and that has turned out to be a rather complex process.
Let me walk you through a little bit of the problem we are facing. Last June we had an Oracle employee come out and look at our scales and how they were hooked up to see if we would need to change anything when we got to the point of implementing MES. His findings were that things looked good and the transition would be very smooth.
Fast forward nine months and it turns out our scales can't communicate via TCP/IP. I had a phone call with Oracle to get a better understanding and what I think I learned is that in order for a scale (or any device) to communicate with MES it has to be assigned its own IP address. The device setup must mimic the setup required for a device to function in WCS (there is a white paper from July 2006 called Oracle Warehouse Management System Warehouse Control System (WCS)/Material Handling Equipment (MHE)that goes over the requirements and the setup process). Basically the communication goes from the database to a middle tier which they reference as the 'Carousel Bridge' or Carbri which then communicates with the device simulator and in order for that communication to take place Carbri must know 'where' it needs to send its messages thus the need for an IP address.
So our current scales come from Mettler Toledo, we use the ID30 weigh system which connects a scale and a monitor via what they call an ELO box. The connection from the scale to this box isn't via a serial cable or usb connection, its hardwired which makes our transition to MES a little more difficult because I can't simply unplug the scale from the ELO box and plug it into something else.
Anyway, the next week or so I'm hoping we can figure out the setup and integration of these scales so we can move forward with the MES project as a whole.
--The minor issue we had with setting up the MES module was that when we tried to select an item for dispensing the system said the lot status was invalid even though it was not. We worked with Oracle for about a week and they came up with patch 9472114 which resolved the issue.
Let me walk you through a little bit of the problem we are facing. Last June we had an Oracle employee come out and look at our scales and how they were hooked up to see if we would need to change anything when we got to the point of implementing MES. His findings were that things looked good and the transition would be very smooth.
Fast forward nine months and it turns out our scales can't communicate via TCP/IP. I had a phone call with Oracle to get a better understanding and what I think I learned is that in order for a scale (or any device) to communicate with MES it has to be assigned its own IP address. The device setup must mimic the setup required for a device to function in WCS (there is a white paper from July 2006 called Oracle Warehouse Management System Warehouse Control System (WCS)/Material Handling Equipment (MHE)that goes over the requirements and the setup process). Basically the communication goes from the database to a middle tier which they reference as the 'Carousel Bridge' or Carbri which then communicates with the device simulator and in order for that communication to take place Carbri must know 'where' it needs to send its messages thus the need for an IP address.
So our current scales come from Mettler Toledo, we use the ID30 weigh system which connects a scale and a monitor via what they call an ELO box. The connection from the scale to this box isn't via a serial cable or usb connection, its hardwired which makes our transition to MES a little more difficult because I can't simply unplug the scale from the ELO box and plug it into something else.
Anyway, the next week or so I'm hoping we can figure out the setup and integration of these scales so we can move forward with the MES project as a whole.
--The minor issue we had with setting up the MES module was that when we tried to select an item for dispensing the system said the lot status was invalid even though it was not. We worked with Oracle for about a week and they came up with patch 9472114 which resolved the issue.
MES Made it Through
Our board has finished reviewing the budget/projects for 2010 and the great news is that MES (Manufacturing Execution System) has made it through (thats a big win,they were leaning towards cutting it because we couldn't find anyone in the US that has implemented this module but I guess things changed). We have a meeting on Friday to start implementing our project plan.
Phase 1 consists of replacing a third part pre-weigh system in all our dispensing rooms and Phase 2 will be to switch over completely to a paperless batch record.
In order for this to work we have begun working on the setup of ERES and AME. Both of those really need to be in place in order for us to fully utilize the MES module.
Anyway, I'll make sure to keep you updated on how the project goes.
Phase 1 consists of replacing a third part pre-weigh system in all our dispensing rooms and Phase 2 will be to switch over completely to a paperless batch record.
In order for this to work we have begun working on the setup of ERES and AME. Both of those really need to be in place in order for us to fully utilize the MES module.
Anyway, I'll make sure to keep you updated on how the project goes.
Unwanted Planned Orders in ASCP
I love it when oracle support deems the solution to all your problems is simply upgrading to the latest CU patchset. Don't mind the fact that we just performed an upgrade from 11.5.10.2 to 12.1.1 less than two months ago, obviously our code level is extremely outaded already.
When we launch a plan from ASCP everything works fine except that the calculation for projected available balance isn't recognizing on hand inventory. Awesome! Because of this when we view the output of the plan in the workbench, we have a planned order for every item in our forecast for tomorrow regardless of whether there is sufficient onhand inventory to meet the next two months worth of demand or not.
We brought this up with support, we have Sev2 ticket open and they say they found the error in the code and have provided a one off patch to resolve the problem but.....we have to apply a 2.3GB Consolidated update patch as a pre-req for our little 28K one off.
I understand that its tough to provide fixes for all these different code levels, I guess I just assumed that by upgrading to 12.1.1 we would be on a pretty darn current version so we would be able to get fixes without having to go through a couple weeks of testing before we validate the affects of applying this huge CU3.
Anyway, hopefully by getting to CU3 and then applying this little one off we get the problem of unwanted planned orders resolved.
When we launch a plan from ASCP everything works fine except that the calculation for projected available balance isn't recognizing on hand inventory. Awesome! Because of this when we view the output of the plan in the workbench, we have a planned order for every item in our forecast for tomorrow regardless of whether there is sufficient onhand inventory to meet the next two months worth of demand or not.
We brought this up with support, we have Sev2 ticket open and they say they found the error in the code and have provided a one off patch to resolve the problem but.....we have to apply a 2.3GB Consolidated update patch as a pre-req for our little 28K one off.
I understand that its tough to provide fixes for all these different code levels, I guess I just assumed that by upgrading to 12.1.1 we would be on a pretty darn current version so we would be able to get fixes without having to go through a couple weeks of testing before we validate the affects of applying this huge CU3.
Anyway, hopefully by getting to CU3 and then applying this little one off we get the problem of unwanted planned orders resolved.
Friday, January 29, 2010
Account Derivation Rule for Using PO Charge Account
Cost accounting has enjoyed the new SLA module since we upgrade to R12. Overall they find it much simpler to maintain and troubleshoot. Being able to view exactly which entries were invalid and why they were invalid during the creation of a subledger really reduces the troubleshooting they were doing in 11i. However, they did have one issue with the way we originally setup the account assignments.
--Quick review of how SLA is setup--
Essentially you create account derivation rules for each journal line type. These derivation rules are pretty much a 'where' clause that you would use when writing SQL. An example would be 'when journal line type is EXP and operating unit is XYZ set the segment ACCT to 4567'. You can also have the ACCT segment assigned based on a source (when you create a physical count you have to put in an account number so you could have the account derivation rule use that account number, whatever it is, as the acount that gets posted in the subledger)
--Back to my post--
Originally we were assigning a constant value for journal line type of EXP but the accountants wanted to be able to pull in the charge account that was entered on the PO. This was our first attempt at using a value type of source in the account derivation rule.
To make a long story short if your using OPM and want to use the charge account that is entered during the creation of the PO select a source of 'Transaction Account' in the account derivation rule. We played around with this for a while trying the distribution account (the column in the database table where this information is stored was called something like distribution account id) and a couple others but the solution was 'Transaction Account'.
--Quick review of how SLA is setup--
Essentially you create account derivation rules for each journal line type. These derivation rules are pretty much a 'where' clause that you would use when writing SQL. An example would be 'when journal line type is EXP and operating unit is XYZ set the segment ACCT to 4567'. You can also have the ACCT segment assigned based on a source (when you create a physical count you have to put in an account number so you could have the account derivation rule use that account number, whatever it is, as the acount that gets posted in the subledger)
--Back to my post--
Originally we were assigning a constant value for journal line type of EXP but the accountants wanted to be able to pull in the charge account that was entered on the PO. This was our first attempt at using a value type of source in the account derivation rule.
To make a long story short if your using OPM and want to use the charge account that is entered during the creation of the PO select a source of 'Transaction Account' in the account derivation rule. We played around with this for a while trying the distribution account (the column in the database table where this information is stored was called something like distribution account id) and a couple others but the solution was 'Transaction Account'.
Onhand vs Lot Status in Release 12
One of the biggest issues we've had since our upgrade is trying to reconcile the difference between lot status and material onhand status. In 11i OPM used lot status which meant that all of a lot was either accepted or not. In R12 a new feature, called material status, is introduced. The feature as a whole is excellent because it allows you to determine the status of a lot + a location (onhand). The benefit of this is that if a portion of a pallet is crushed you can seperate the pallet into two parts and assign the bad crushed part a status of 'throw away' while assigning the good portion an acceptable status.
This feature is great except that the status only persists as long as you have inventory onhand. Once your inventory goes to 0 for a certain lot or location the status no longer exists. Most of the time that is completely acceptable but where we run into problems is when you issue material to a batch (and that issue 0's out the onhand quantity) and then find that you need to perform a wip return for a portion of that quantity. Since the onhand was 0 because the wip issue consumed it all the previous status no longer exists so when a wip return happens and inventory is put back into the location from which it was issued the status defaults to whatever status is setup in the item master for that organization.
For us, this means that whenever an item is returned it defaults back to a status of 'QUAR' which is a status that does not allow wip issues. Since our quality department is the only team who can update that status each time a wip return occurs as described above we have to alert them and they have to go verify that indeed its okay to change the status to acceptable for mfg use.
In 11i the lot status persisted even if the quantity were 0 and so if a return was performed the returned material would be assigned the status of the lot. In R12, everything goes back to the default status setup in the item master. After discussing this with Oracle it seems like our only solution is going to be through customization, at least for the next year or so.
This feature is great except that the status only persists as long as you have inventory onhand. Once your inventory goes to 0 for a certain lot or location the status no longer exists. Most of the time that is completely acceptable but where we run into problems is when you issue material to a batch (and that issue 0's out the onhand quantity) and then find that you need to perform a wip return for a portion of that quantity. Since the onhand was 0 because the wip issue consumed it all the previous status no longer exists so when a wip return happens and inventory is put back into the location from which it was issued the status defaults to whatever status is setup in the item master for that organization.
For us, this means that whenever an item is returned it defaults back to a status of 'QUAR' which is a status that does not allow wip issues. Since our quality department is the only team who can update that status each time a wip return occurs as described above we have to alert them and they have to go verify that indeed its okay to change the status to acceptable for mfg use.
In 11i the lot status persisted even if the quantity were 0 and so if a return was performed the returned material would be assigned the status of the lot. In R12, everything goes back to the default status setup in the item master. After discussing this with Oracle it seems like our only solution is going to be through customization, at least for the next year or so.
Unwanted Planned Orders in ASCP
I love it when oracle support deems the solution to all your problems is simply upgrading to the latest CU patchset. Don't mind the fact that we just performed an upgrade from 11.5.10.2 to 12.1.1 less than two months ago, obviously our code level is extremely outaded already.
When we launch a plan from ASCP everything works fine except that the calculation for projected available balance isn't recognizing on hand inventory. Awesome! Because of this when we view the output of the plan in the workbench, we have a planned order for every item in our forecast for tomorrow regardless of whether there is sufficient onhand inventory to meet the next two months worth of demand or not.
We brought this up with support, we have Sev2 ticket open and they say they found the error in the code and have provided a one off patch to resolve the problem but.....we have to apply a 2.3GB Consolidated update patch as a pre-req for our little 28K one off.
I understand that its tough to provide fixes for all these different code levels, I guess I just assumed that by upgrading to 12.1.1 we would be on a pretty darn current version so we would be able to get fixes without having to go through a couple weeks of testing before we validate the affects of applying this huge CU3.
Anyway, hopefully by getting to CU3 and then applying this little one off we get the problem of unwanted planned orders resolved.
When we launch a plan from ASCP everything works fine except that the calculation for projected available balance isn't recognizing on hand inventory. Awesome! Because of this when we view the output of the plan in the workbench, we have a planned order for every item in our forecast for tomorrow regardless of whether there is sufficient onhand inventory to meet the next two months worth of demand or not.
We brought this up with support, we have Sev2 ticket open and they say they found the error in the code and have provided a one off patch to resolve the problem but.....we have to apply a 2.3GB Consolidated update patch as a pre-req for our little 28K one off.
I understand that its tough to provide fixes for all these different code levels, I guess I just assumed that by upgrading to 12.1.1 we would be on a pretty darn current version so we would be able to get fixes without having to go through a couple weeks of testing before we validate the affects of applying this huge CU3.
Anyway, hopefully by getting to CU3 and then applying this little one off we get the problem of unwanted planned orders resolved.
Thursday, December 31, 2009
(Upgrade + Interfaces) = (Potato Chips + Bubble Gum)
Well, we have been live on R12.1 for a full month now. We made it through our first month end and now we are days away from closing out the year. While no upgrade is void of significant issues I would have to say ours has played out better than I could have hoped. Really, from an operations standpoint, the only major issues we had were getting our custom interfaces to work properly (which brings me to the topic of this post).
My new personal opinion is that (Upgrade + Interfaces) = (Potato Chips + Bubble Gum). What I mean is that the upgrade by itself is a very good thing and our custom interfaces by themselves really are superb but when you combine them together its like chewing bubble gum while eating potato chips, they just don't go well together.
We have three major interfaces that we maintain, all on the operations side. Two of the three interfaces were created to link a third party solution into oracle applications. In those two cases we were only able to test that information was put into and taken out of the interface tables the same way it was before the migration. As much as you try and replicate these interfaces without being able to test the process all the way through from beginning to end it becomes very difficult to verify that your solution will process correctly post upgrade. To complicate matters even more, our two third parties didn't have test instances available in which we could validate our code pre migraiton.
Here we are now, four weeks later and we are hoping that we've gotten the last 'glitch' resolved with our interfaces. It's been a hectic and very busy month essentially 'testing' our updated code in our production instance but we might finally be on our way to wrapping things up.
The lesson learned: things are sure easier when you don't have custom interfaces. To me it drives home the idea that its better to have a single fully integrated ERP system then it is to have a multiple systems trying to interface with each other. Granted, the price is very different between the cost of those two solutions unless you add in the cost of hiring developers to maintain and constantly monitor your code. For me, I'm taking the integrated system any day of the week.
My new personal opinion is that (Upgrade + Interfaces) = (Potato Chips + Bubble Gum). What I mean is that the upgrade by itself is a very good thing and our custom interfaces by themselves really are superb but when you combine them together its like chewing bubble gum while eating potato chips, they just don't go well together.
We have three major interfaces that we maintain, all on the operations side. Two of the three interfaces were created to link a third party solution into oracle applications. In those two cases we were only able to test that information was put into and taken out of the interface tables the same way it was before the migration. As much as you try and replicate these interfaces without being able to test the process all the way through from beginning to end it becomes very difficult to verify that your solution will process correctly post upgrade. To complicate matters even more, our two third parties didn't have test instances available in which we could validate our code pre migraiton.
Here we are now, four weeks later and we are hoping that we've gotten the last 'glitch' resolved with our interfaces. It's been a hectic and very busy month essentially 'testing' our updated code in our production instance but we might finally be on our way to wrapping things up.
The lesson learned: things are sure easier when you don't have custom interfaces. To me it drives home the idea that its better to have a single fully integrated ERP system then it is to have a multiple systems trying to interface with each other. Granted, the price is very different between the cost of those two solutions unless you add in the cost of hiring developers to maintain and constantly monitor your code. For me, I'm taking the integrated system any day of the week.
Thursday, November 12, 2009
The Calm Before the Storm
We are officially two weeks away from taking our production instance down and migrating from 11.5.10 to 12.1. You'd think I'd be swamped with problems and issues from every which department, but as of today the only thing I have to work on is documentation (training and validation), and rewriting reports. --Sadly our discoverer reports aren't going to migrate so well since they were built on OPM inventory views.
My mind is going about 2,000 mph trying to see if I've missed any testing or any possible business process that might be affected by the upgrade but so far things look good. I wish I had a little more 'stress free' free time so I could update this blog with things I've learned during the upgrade but I think those entries are going to have to come later.
I will however make a small list of things to consider during your upgrade
Those are just a few thoughts, hopefully they might help you out during your upgrade. Well, I have more reports to rewrite, wish me luck.
My mind is going about 2,000 mph trying to see if I've missed any testing or any possible business process that might be affected by the upgrade but so far things look good. I wish I had a little more 'stress free' free time so I could update this blog with things I've learned during the upgrade but I think those entries are going to have to come later.
I will however make a small list of things to consider during your upgrade
- Discoverer reports/workbooks don't migrate, at least that is what Oracle consulting told us. If you are using discoverer before the migration you're going to have to recreate your workbooks after the migration (assuming those workbooks are built on views that get changed during upgrade)
- In OPM users are forced to choose an existing lot number when performing move immediates and adjust immediates. In 12.1 users are not forced to choose existing lots. They can enter a new lot any time (subinventory transfers, account alias transactions, inter-org transfers)
- This one is random but in 11.5.10 we had routings setup which had resources with a usage of 0. In 12.1 if you have a primary resource assigned to a routing and that primary resource has a usage of 0 then when you run collections, the Recipe which uses that routing will not be collected and it will not show demand for that product/raw materials
Those are just a few thoughts, hopefully they might help you out during your upgrade. Well, I have more reports to rewrite, wish me luck.
Thursday, October 1, 2009
How MAC data and mappings gets migrated into the SLA
If you've read any of my previous posts you know that I'm by no means an expert on OPM Cost Accounting. However, for the last two weeks the majority of my time has been spent on becoming an wanna-be expert in this area. Hopefully I can break down what I think I've learned in a way that's understandable and that doesn't reveal my limited accounting knowledge.
In 11.5.10 OPM customers use the MAC to define how transactions and events will be mapped to the subledger and then on to the general ledger. This mapping can be very generic (when sub-event 'X' occurs use account number 'Y') or it can be very specific (when sub-event 'X' occurs in Whse 'A' with a reason code of 'B' and account title 'D' and a GL Item Category of 'C' then use account 'Y'). The question, then, is how does this mapping get migrated into R12?
--Please understand that the following opinion and explanation is based on my personal experience which means it might not be 100% correct--
In order to explain how MAC data gets migrated into SLA I first should explain just a titch about how the SLA works in comparison to the MAC. In MAC you have events, subevents, account titles, and account mapping attributes which you use to define account mappings. These same things exist in R12 they are just re-named so:
In release 12 your bottom level is your journal line types and your account derivation rules. A new mapping tool is introduced in 12 and it's called Journal Line Definitions. You use journal line definitions as the place were you select what account derivation rule you want to use to for each journal line type per event class.
Lets take the event class Miscellaneous Transaction as an example. This event class has two journal line types assigned to it, 'INV' (inventory valuation) and 'IVA' (inventory adjustment expense). With a journal line definition you are basically saying when event class miscellaneous transaction occurs for journal line type 'INV' use accounting derivation rule 'X'. Journal line types exist across multiple event classes so the journal line definition allows you use different derivation rules per event class. So, for the event class Batch Material Transactions, I can associate account derivation rule 'A' to journal line type 'INV' through the journal line definition and.
The journal line type will migrate without any problem because it is essentially just a copy of your existing account titles in 11.5.10. Account derivation rules is where OPM users are going to affected. Account derivation rules are created for every unique combination of: account title, set of books, and account segment. My company has a six segment accounting flexfield in R12 after migration I'll haves six account derivation rules per journal line type.
Our accounting flexfield is XX-XX-XXXX-XX-XXX-XXX so my accounting derivation rule (ADR) for journal line type 'INV' will be like this:
So the one mapping rule in 11.5.10 comes across as 6 different rules in Release 12. Obviously you don't need 6 different rules to define every journal line type every time. But, this post is about how things migrate so I'll have to go over that another time.
I'm a little short on time right now but hopefully this helps explain a little on how the data and account mapping that existed in 11.5.10 gets mapped over the release 12 during migration.
In 11.5.10 OPM customers use the MAC to define how transactions and events will be mapped to the subledger and then on to the general ledger. This mapping can be very generic (when sub-event 'X' occurs use account number 'Y') or it can be very specific (when sub-event 'X' occurs in Whse 'A' with a reason code of 'B' and account title 'D' and a GL Item Category of 'C' then use account 'Y'). The question, then, is how does this mapping get migrated into R12?
--Please understand that the following opinion and explanation is based on my personal experience which means it might not be 100% correct--
In order to explain how MAC data gets migrated into SLA I first should explain just a titch about how the SLA works in comparison to the MAC. In MAC you have events, subevents, account titles, and account mapping attributes which you use to define account mappings. These same things exist in R12 they are just re-named so:
- event = event entity
- sub-event = event class
- account titles = journal line types
- account mapping attributes = sources
- account mapping = account derivation rules
In release 12 your bottom level is your journal line types and your account derivation rules. A new mapping tool is introduced in 12 and it's called Journal Line Definitions. You use journal line definitions as the place were you select what account derivation rule you want to use to for each journal line type per event class.
Lets take the event class Miscellaneous Transaction as an example. This event class has two journal line types assigned to it, 'INV' (inventory valuation) and 'IVA' (inventory adjustment expense). With a journal line definition you are basically saying when event class miscellaneous transaction occurs for journal line type 'INV' use accounting derivation rule 'X'. Journal line types exist across multiple event classes so the journal line definition allows you use different derivation rules per event class. So, for the event class Batch Material Transactions, I can associate account derivation rule 'A' to journal line type 'INV' through the journal line definition and.
The journal line type will migrate without any problem because it is essentially just a copy of your existing account titles in 11.5.10. Account derivation rules is where OPM users are going to affected. Account derivation rules are created for every unique combination of: account title, set of books, and account segment. My company has a six segment accounting flexfield in R12 after migration I'll haves six account derivation rules per journal line type.
Our accounting flexfield is XX-XX-XXXX-XX-XXX-XXX so my accounting derivation rule (ADR) for journal line type 'INV' will be like this:
- ADR1 XX
- ADR2 XX
- ADR3 XXXX
- ADR4 XX
- ADR5 XXX
- ADR6 XXX
So the one mapping rule in 11.5.10 comes across as 6 different rules in Release 12. Obviously you don't need 6 different rules to define every journal line type every time. But, this post is about how things migrate so I'll have to go over that another time.
I'm a little short on time right now but hopefully this helps explain a little on how the data and account mapping that existed in 11.5.10 gets mapped over the release 12 during migration.
Monday, September 21, 2009
OPM and SLA
This week's task is tryng to get my hands completely around how to switch from using the OPM MAC to the Oracle SLA module. I hoped that since we were upgrading from 11 to 12 that maybe our business logic would migrate over for cost accounting but unfortunately that wasn't quite the case (some of the logic did migrate but most of it did not).
Now comes the fun part of trying to get the SLA up and running in a way that will jive with our cost accounting department. While there's plenty of documentation out there on how to implement SLA, there isn't quite as much about what needs to be done in order for SLA to function properly with OPM. However, today I did find a jewel on metalink that helps quite a bit, its Doc ID 822303.1. This doc goes through a step by step setup process, including screen shots, of how to get the SLA correctly configured to function with OPM.
The other helpful document I found last week dealing with this topic is a case study done by Satyam Computer Services which outlines a migration from MAC to SLA in R12 for an OPM company. You can also find this on metalink under Doc Id 562601.1.
Hopefully by the end of this week I'll be an expert on OPM and SLA.
Now comes the fun part of trying to get the SLA up and running in a way that will jive with our cost accounting department. While there's plenty of documentation out there on how to implement SLA, there isn't quite as much about what needs to be done in order for SLA to function properly with OPM. However, today I did find a jewel on metalink that helps quite a bit, its Doc ID 822303.1. This doc goes through a step by step setup process, including screen shots, of how to get the SLA correctly configured to function with OPM.
The other helpful document I found last week dealing with this topic is a case study done by Satyam Computer Services which outlines a migration from MAC to SLA in R12 for an OPM company. You can also find this on metalink under Doc Id 562601.1.
Hopefully by the end of this week I'll be an expert on OPM and SLA.
Friday, September 11, 2009
EAM Migration to 12.1
Found out yesterday that there are some specific pre-migration setup steps that need to be completed in order for EAM assets to migrate correctly. Apprently EAM gets integrated with Oracle Installed Base in release 12 and for that integration to work you have to have your Install Base parameters set up appropriately. It would have been nice of Oracle to include this in their upgrade documentation (Oracle Applications Upgrade Guide Release 11i to 12.1.1 Part No, E14010-01) but as Sept 11, 2009 this step is not included.
From what I understand a script runs during patch 6678700 called eamsnupd.sql which inserts the eam asset number into the csi_item_instance but if you do not have the Install Base parameters setup then when the sql tries to fetch an internal_party_id it fails to get any records from the csi_install_parameters.
Its interesting that they included this setup information in the EAM Release Notes for 12.0.6 but not for 12.1.1. So far I've only been able to find two metalink documents that explain this install base setup(437577.1 and 748070.1 this second doc being the release notes for 12.0.6).
So, just want to make you aware, if you are upgrading from 11i to 12.1 and you have EAM installed but aren't currently using Install Base then you need to setup the Install Base parameters before you migrate so that EAM asset numbers can be inserted into the item instance table.
Here is what the Oracle Release Notes say you need to do to setup Installed Base parameters:
Updated Sept 14th: Found another link on metalink, Doc Id 885895.1. This one seems to be the most detailed of the three docs.
From what I understand a script runs during patch 6678700 called eamsnupd.sql which inserts the eam asset number into the csi_item_instance but if you do not have the Install Base parameters setup then when the sql tries to fetch an internal_party_id it fails to get any records from the csi_install_parameters.
Its interesting that they included this setup information in the EAM Release Notes for 12.0.6 but not for 12.1.1. So far I've only been able to find two metalink documents that explain this install base setup(437577.1 and 748070.1 this second doc being the release notes for 12.0.6).
So, just want to make you aware, if you are upgrading from 11i to 12.1 and you have EAM installed but aren't currently using Install Base then you need to setup the Install Base parameters before you migrate so that EAM asset numbers can be inserted into the item instance table.
Here is what the Oracle Release Notes say you need to do to setup Installed Base parameters:
Beginning with Release 12.0, Oracle Enterprise Asset Management is integrated with Oracle Installed Base. Therefore, the Installed Base parameters must be set up to ensure that assets are created correctly in eAM.
We added a new section to the Setting Up chapter in the Oracle Enterprise Asset Management User's Guide relating to the installation parameters for Installed Base. These parameters must be set up in order to create asset correctly. This issue is related to Note 437577.1.
Setting Up Installed Base Parameters
You must perform the following steps in Oracle Installed Base:
Navigate to the Install Base Administrator responsibility.
Under the Setups menu, click the Install Parameters link.
Set up the Install Parameters for Installed Base. Additional Information: See Oracle Installed Base Implementation Guide for assistance on how to set up the Installed Base parameters. See "Set Up Installation Parameters", Setup Steps within Oracle Installed Base, Oracle Installed Base Implementation Guide.
Make sure that the Freeze checkbox has been selected. If it is unchecked, then select the checkbox.
Save your work.' (Oracle Metalink Doc Id 748070.1)
Updated Sept 14th: Found another link on metalink, Doc Id 885895.1. This one seems to be the most detailed of the three docs.
Subscribe to:
Posts (Atom)