Posts filed under 'Oracle'
One of my major projects at work the last few months has been to get the Oracle Product Lifecycle Management (PLM) tool up and running. Oracle PLM has also been known as Advanced Product Catalog, but the PLM name seems like it will stick.
The central piece of Oracle PLM is the Item Catalog. The Item Catalog is a hierarchy of all of the items in your company: finished goods, raw materials, everything with a part number. The idea behind the Item Catalog is to create a natural hirearchy of those items. The Item Catalog hierarchy is made with Item Catalog Categories. Now, to those of you familiar with catalogs and categories from the Inventory module, forget everything you’ve learned about them (well, almost everything — they do tie into PLM eventually). However, semantics are important here, the center of PLM is the Item Catalog, which creates a hierarchy of items using Item Catalog Categories (ICCs).
When creating the Item Catalog hierarchy and defining the ICCs you will use, it is important to keep the end in mind. The hierarchy created with the Item Catalog Categories allows for inheritance, and many of the key functional areas of PLM get tied back to the hierarchy. For example, if you want to keep track of the paper size for your printed materials, you can put the Paper Size data element at the Printed Goods ICC and have it inherited to the Brochures ICC and the Posters ICC which belong to the parent Printed Goods ICC. Any items under Brocures or Posters will have a data element for Paper Size because of inheritance.
One key rule to remember is that an item can belong to one and only one Item Catalog Category.
It’s easy to create ICCs to mirror your product lines, but is that the right way to do it? One question to ask is, will Item A have different data requirements than Item B? If it does have different data requirements, it should be in another ICC. Using the data question is a good way to determine the structure of the Item Catalog. At the top of the chain, you should also consider creating a top level ICC. That way if you have any all-encompansing rules or data that is spread across all items, you can attach it at that top level and have it inherited by the lower ICCs.
Having a properly structured Item Catalog will pave the way for a successful implementation of Oracle Product Lifecycle Management (PLM).
July 19th, 2006
Oracle Applications version 11.5.10 introduced an new piece of the Oracle Application Object Library named Oracle User Management. User Management totally changes the user management paradigm. Although I am relatively new to Oracle Applications, I had to quickly understand how users and permissions worked to grant access in the system. With User Management all of that changes… sort of.
The old model consisted of users and responsibilities. A user would be given several different responsibilities (ie Payables User, Inventory Inquiry), and each responsibility would give access to a given application or subset of functions within an application. The user would change responsibility to access different functions of the system.
The new User Management module (short name: UMX) introduces roles. Roles and responsibilities don’t seem to be too different at the surface, but demonstrate many differences when you dive into the details.
One major update is role inheritance. This should simplify user management because of the cascading privileges. For example let’s say a company has three inventory roles: Inventory Inquiry, Inventory User and Inventory Manager. The Oracle group decides to add a new inventory report which should be accessed by all users with any of the three inventory roles. Add permissions for that report to the Inventory Inquiry role and it will be inherited automatically by the Inventory User and Inventory Manager roles. Role inheritance is quite easy to set up.
Allegedly, Oracle User Management also includes the functionality to allow for delegated administration. I haven’t been able to set this up and get it working yet, but it seems like a nice concept. Delegated administration allows a given role to manage other roles. In our example above, the Inventory Manager would be able to bump up an existing user from Inventory Inquiry to the Inventory User role. Because our Oracle group spends several hours per week on this type of issue, getting this functioning properly would free us up to improve other areas of the system.
Similarly, Oracle User Management allows for some self-service by users. They can request additional access to the system, which travels through the workflow approval. Others can request access to the system initially by completing a web form that is accessible at the initial login screen. All of these requests can be monitored and approved or denied through the workflow engine.
Personally, I don’t think User Management is quite ready for primetime. I’ve encountered several bugs and issues during setup, several of which weren’t addressed or fixed to my satisfaction. Many of those problems seem to be because Oracle User Management is new and because it is a significant change from the previous model. We will try it again in 11.5.10.2 and hope Oracle has spent significant time improving the User Management module. Please let me know if you have any more luck than I have had so far.
February 23rd, 2006
I have recently accepted a job as an Oracle Business Analyst at a small, but quickly growing company. As an Oracle Business Analyst I am heavily involved with many aspects of the company’s business software, centered on the Oracle e-Business suite. Here are a few of my lessons learned during my first three months on the job:
I still have a lot to learn. Even though I’ve been a user of large systems, and even spent a couple years as a project manager for several complicated web-based systems, I haven’t ever seen anything as vast as Oracle Applications. Oracle is a whole new world. Our installation includes modules for inventory, accounting, purchasing, distribution, and planning all together, and we’re constantly adding more modules.
I have been tasked with heading up a project configuring Oracle Product Lifecycle Management (PLM) (also known as Advanced Product Catalog). PLM ties into inventory, product setup and change management, adds features for our marketing group to move product ideas into actual products, and adds change management features to move products gracefully from womb to tomb. Sounds easy, right? Nope. I’ve been looking at this module for a couple months now, and I don’t even have a semi-working prototype up and running yet.
User interface matters. Oracle has reinforced my belief that the user interface matters in a software application. I’ve always been one of those IT guys who firmly believes the UI actually is an important piece of the puzzle. Some Oracle Applications have bad reputations strictly because of the user interface. The forms that most users see are java-based and pretty clunky looking, so therefore the perception is that Oracle is clunky as a general rule. Some of the more recent applications have been entirely web-based and feature a more familiar UI. These modules don’t get the same complaints — they are perceived differently by users.
Documentation, documentation, documentation. The Oracle supplied documentation is less than adequate for implementing most modules. Oracle does a good job of providing documentation, but it usually lacks the amount of detailed steps to follow to get the software up and running properly. The questions I have had while implementing PLM and Oracle User Management have not been answered by the supplied documentation.
Because the Oracle documentation doesn’t provide adequate instruction, it is imperative to document any changes made to the system in order to retrace those steps. Usually an implementation will be first done in a development instance, and then eventually moved into production by following those same steps. If you haven’t recorded everything you have done in development, you will spend too much time trying to recreate those same steps in production. Having properly documented those steps will save a great deal of time and trouble.
February 9th, 2006