Making Tea with GMD: A Case Study in OPM Product Development 11i10

An Oracle White Paper January, 2005

Making Tea with GMD: A Case Study in OPM Product Development 11i10
Imagination is the beginning of creation. You imagine what you desire, you will what you imagine and at last you create what you will. - George Bernard Shaw
Abstract With the release of E-business suite Release 11i6, Oracle Process Manufacturing (OPM) Product Development emerged restructured to enhance its compliance with Industry requirements and to achieve greater adherence to contemporary business flows in the process industry. With the introduction of OPM Release 11i7 (11i.OPM_PF.G & 11i.OPM_PF.H), was born the OPM New Product Development module. This re-designed module replaced the OPM Laboratory and Formula Management applications found in the previous releases. A new recipe structure was introduced that complied with the industry standards for recipe definition. Product Development brought with it a security option that enables organizations to restrict access to and modification of formula information. Release 11i10 has taken this process of growth and consolidation a step further by introducing tools such as Computer Aided Formula Analysis and the Graphical Recipe Designer and the Routing Designer. This paper walks the reader through the major concepts in OPM Product Development as we see it today in Release 11i10. The concepts are built around a simple case study of a tea-processing unit that produces bottled black tea. We begin with the basic building blocks of defining units of measure and items that would go into the formulas that would in turn merge into the final recipes. Scope The content of this paper adheres to the boundary established by the Oracle Process Manufacturing Product Development User's Guide Release 11i, July 2003 (Part No. A92170-05) and Oracle Process Manufacturing Product Development User's Guide Release 11i, August 2004 (Part No. A92170-06). This paper is intended for foundation and intermediate level users, as well as users of OPM Release 11i10 and users of discrete manufacturing seeking an insight into OPM Product Development. The paper adopts a direct approach beginning with the defining of units of measures (UOM) and items, and then defining the appropriate UOM conversions for some of these items. Having laid the foundation, we move on to defining formulas, activities, resources, operations, routings and so on. The emphasis all through the paper is to demonstrate how these concepts are being fruitfully put to use in our tea-processing unit. This approach, it is hoped would give the reader a semblance of how OPM Product Development works in a real-life scenario. The intent of this paper is not so much to highlight the processes in the tea-industry as it is to emphasise how the utilities built into the GMD product assist in streamlining activities and in improving productivity in any given industry engaged in process manufacturing. The processes ascribed to the tea industry in this paper are drawn from the author's study of tea processing in the "tea-rich" districts of Darjeeling and Kurseong in the state of West Bengal in the eastern part of India. When presenting these processes on paper they have been fairly simplified, so as not to deviate from the prime objective of this paper, which is to ensure that the explanation of the features and the concepts in GMD remain crisp and lucid. This paper does not claim to be an exhaustive document on the GMD module (as it would be virtually impossible to cover the entire gamut of features and utilities in GMD in one white paper), nor does it purport to be a substitute for any official literature on GMD. Lastly, due to the paucity of time (and space), the topic of Technical Parameters and their use in Computer Aided Formula Analysis, has not been covered in this paper as it was felt that this topic deserves a separate treatment to do justice to it.

The Relevance of OPM White Paper (Note 279673.1) to this paper This paper begins from where the OPM White Paper (Note 279673.1) left. The two OPM Organizations we had defined in the previous paper Process Industries Bangalore (PRB) and Process Industries Hyderabad (PRH) will be used in this paper as our tea-processing plants. The UOM Milliliter (Fig 1), which we had defined in the previous paper, will be used (for some items) as the primary UOM in conjunction with the seeded UOM LT, which will be used as the Dual UOM. Another UOM that we shall define in this paper is Crate (Fig 2). All other UOMs used are seeded UOMs. A quick preview of the UOMs defined and used Responsibility: OPM System Administration Navigation: OPM System Setup > Units of Measure > Units of Measure

Fig 1. Defining the UOM Milliliter We had defined Milliliter (ML) as a UOM in Note 279673.1 as shown in Fig 1. We now define a second UOM as shown in Fig 2.

Fig 2. Defining the UOM Crate When defining tea leaf as an item, the primary unit of measure is kept as grams (GM) and for tea liquor and fruit essence it is milliliters (ML). Although these items will be transacted in the processing unit in much larger units of kilograms (KGM) and liters (LT) respectively, we still retain GM and ML as the primary UOM for a very specific reason. When the final product tea liquor is ready, specialised personnel known as tea-tasters subject it to a rigorous process of screening. Based on the quality/grade of tea leaf that went into the process, the flavour differs from one batch to the next. As the name suggests, the tea-tasters take a sip for each sample of tea liquor to determine the relative quality and consequently the price that a lot or a batch should command. Since the samples are tested at such a micro-level (in small quantities), to facilitate record keeping by tea tasters, the UOMs are kept at the micro level hence the use of GM and ML. A day in the life of a tea-producing unit Fig 3 and Fig 4, display the product/ingredient/by-product chart for the entire process detailed below. Process Industries Bangalore, begins the day with collecting fresh, tea leaves from its tea plantations. The tea plants are grown on special farms called plantations. When the plants are three to five years old, the leaves are ready for picking. Women are employed to perform the delicate task of selecting and picking the right tea leaves and collecting them in the cloth basket that are hung by a strap worn on the head. Only the bud and the top two leaves of the new shoot are picked. The baskets get quite heavy, since tea picking is done early in the morning when the leaves are still covered with dew. The early morning hours are ideal for this task as it helps avoid avoid wilting and damage to the tea leaves by the hot tropical sun. The tea leaf picking process usually ends by 12:00 PM. Each worker is then paid on a per kilogram basis for the total weight of leaves collected by that worker within the stipulated period. Once the leaves are collected at the collection center, these tea leaves are put through a controlled process to bring out the flavouring juices on to the surface and make the leaves ready for brewing.

The leaves are then put through the following steps: Withering (In this paper Activity Code: WITHERING) After picking, the green leaves are spread out on tiers of racks to wither for about 12 to 18 hours. During the long withering process, the leaves lose most of their moisture, becoming soft and pliable so they can be rolled. Rolling (In this paper Activity Code: ROLLING T LEAF) During rolling, the membranes of the leaves are broken, allowing the juices and essential oils (that give the tea its aroma) to develop. After rolling, the leaves are brought into large, cool, humid rooms where they are spread in layers of about four inches high to oxidize. Fermentation (In this paper Activity Code: FERMENT) During the oxidation process, the leaf color darkens, and the initially bitter juices mellow. The characteristic flavours of black tea ranging from flowery to fruity, nutty and spicy begin to emerge. The oxidation process must be stopped at the point where the aroma and flavour have fully developed. Drying (In this paper Activity Code: FIRING T LEAF) Firing the leaves in large ovens achieves this. The flavourful juices dry on the surface of the leaves and remain relatively stable until exposed to boiling water during infusion. The successful completion of the drying process gives Bangalore Process Industries (PRB) their first ingredient the FRESH TEA LEAF. Brewing (In this paper Activity Code: BREWING T) This is the process where the tea leaves are put into hot water to extract the juice from the preprocessed leaves. The ingredients at this stage are FRESH TEA LEAF and WATER. Flavouring (In this paper Activity Code: FLAVOURING T) Once infusion takes place and the juice from the tea leaves mingles with the hot water, the concoction brings forth the natural flavour of tea. However, based on consumer preferences it may be necessary to add a hint of fruity flavour to the brew. This is where a flavouring agent is added. So, the ingredient here is FRUIT ESSENCE. Filtering (In this paper Activity Code: FILTERING T) Once the fruit flavoured concoction of tea is ready, it needs to be segregated from the used tea leaves. Sieving or filtration achieves this. USED TEA LEAF is the by-product. The product is TEA LIQUOR. Bottling (In this paper Activity Code: BOTTLING) This is the last step. The TEA LIQUOR is now packaged into 500 Milliliter bottles, and the bottles are appropriately labeled. The ingredients here are TEA LIQUOR, BOTTLE 500 and BLACK TEA LABEL. The output is our final product BOTTLED FLAVOURED TEA.

Fig 3. The Product Structure of TEA LIQUOR

Fig 4. The Product Structure of BOTTLED FLAVOURED TEA

Defining the Items Responsibility: OPM All/OPM Inventory Navigation: OPM Inventory Control > Setup > Item Organization Here we shall add the four OPM Warehouses that we had defined under the OPM Organizations PRB and PRH with PRB as the Item Master (Note 279673.1). This ensures that OPM Inventory Items defined henceforth will be available to these new organizations (Fig 5).

Fig 5. Adding the OPM Warehouses under PRB and PRH to the Item Organizations list Responsibility: OPM All/OPM Inventory Navigation: OPM Inventory Control > Setup > Item Master

Fig 6. Our first Item

A Note on the profile GMD: Yield Type When defining a formula, the total output quantity for that formula is calculated by converting product and by-product quantities from their respective UOMs into a specific UOM and adding up their total. This is one option used to create a Batch (total output quantity of products). Similarly, total input quantity is calculated by converting all of the ingredients from a formula into the same UOM and adding up their total. The UOM into which these conversions take place is the Base UOM of the UOM Class that has been specified against the profile option GMD: Yield Type.

Fig 7. The Profile that decides the Total Output Quantity in a Formula In Fig 7, we see that the default value against this profile is the UOM Class MASS (Description: Mass (Process)). The Base UOM for this UOM Class is LB. Therefore, we need to ensure during the item definition stage that if an item is being defined with a Primary UOM belonging to a UOM Class different from MASS, then in the Item/Lot Conversions screen, we need to define the conversion between the Base UOMs of these two UOM Classes. If such conversions are not defined, then the Total Output Qty and the Total Input Qty cannot be calculated, and the system will typically throw up an error as shown in Fig 8 below. This will also prevent the user from creating a batch using the total input or output quantity options.

Fig 8. Error on not defining item UOM conversion with that of GMD: Yield Type The first item that we have defined in Fig 6 has a Primary UOM (GM) that belongs to the UOM Class MASS. Hence, no additional conversions need be defined. When we define our second item (Fig 9), we ensure that there is a conversion defined as explained above.

Fig 9. Defining our second item alongwith the Item/Lot UOM Conversion Details of the other items The other items we have defined are detailed below.

Fig 10. Defining our Flavouring Agent

Fig 11. Defining Item Lot/Sublot Standard Conversion for FRUIT ESSENCE The Fruit Essence concentrate that was recorded for this paper had a specific gravity of 1.9, hence approximated to 2.0. Therefore, 1 GL = 16.66 LB of Fruit Essence.

Fig 12. Defining Liquor Tea which is the intermediate product

Fig 13. Defining Item Lot/Sublot Standard Conversion for TEA LIQUOR Note: The Tea Liquor processed in eastern parts of India usually has a specific gravity of 1.06 (approximately), hence the GL to LB conversion factor of 8.8298 as shown in Fig 13.

Fig 14. Defining our By-product No item UOM conversion is required for USED TEA LEAF, as the UOMs GM and KGM are seeded UOMs and belong to the same UOM class as LB.

Fig 15. Defining our container ingredient

10

Fig 16. Defining Item Lot/Sublot Standard Conversion for BOTTLE 500

Fig 17. Defining our Final Product

Fig 18. Defining Item Lot/Sublot Standard Conversion for BOTTLED FLAVOURED TEA

Fig 19. Defining our labeling ingredient

Fig 20. Defining Item Lot/Sublot Standard Conversion for BLACK TEA LABEL This completes our item definition phase. Setting up our Formulas The first thing to do is to set up the Formula Classes. Formula Class is used to group and classify Formulas, based on some criterion. Responsibility: Formulator

11

Navigation: Setup > Formula Class

Fig 21. Defining our Formula Classes for Tea based on the final product Our tea-processing unit PRB can produce many varieties of packaged tea to satisfy consumer demand. These are Black Tea, Green Tea, Decaffinated Tea and Herbal Tea. Each employs a different process and a different formula. Accordingly, four different Formula Classes have been defined (Fig 21). For our case study, we shall be using only the first of these i.e. BLACK-T. Responsibility: Formulator Navigation: Formula Workbench We have used the Formula Workbench to create our formulas.

Fig 22. The Formula for Tea Liquor as seen from the Formula Workbench

12

Fig 23. Defining our Formula for Tea Liquor Notes on a few important terms Scaling: We have enabled the Scaling Allowed checkbox at the Formula Header level. We would therefore be able to scale this formula when required. The Scale Type for the Product, Byproduct and all the Ingredients has been set to Proportional. The types of scaling and their significance has been explained with examples in Oracle Process Manufacturing Product Development User's Guide Release 11i (Part No. A92170-05). A little later we shall be using a Formula in a Recipe and at that point of time we shall scale the Formula and see the changes. Packaging: The Packaging checkbox, is intended to be used to default certain values in formula material details, such as Contributes to Yield. However, any specific packaging features are yet to be implemented. Currently, this checkbox is for reference only. Scrap Factor: 10% of the ingredient Water gets absorbed in the Brewing process by the tea leaves. We threfore specify a Scrap Factor of 10 for water.

Fig 24. Specifying the Scrap Factor

13

Consequently, the system calculates the Required Quantity of Water as Quantity * (1 + Scrap Factor/100) = 500 * (1 + 0.1) = 550 Formula Status Change: Since we are not using the Approval Workflow, we use the Actions (M) > Change Status path to select the appropriate Status for this Formula (Approved for General Use). When creating a Formula for the first time, or creating a new revision for an existing Formula, the Status always defaults as New. This applies to Operations, Routings, Recipes and Validity Rules as well. We now move onto creating our second formula. Fig 25 to 28, demonstrate our second and final formula.

Fig 25. The Formula for Bottled Tea Liquor as seen from the Formula Workbench

Fig 26. On exploding the Bottled Tea Liquor Formula in the Workbench

14

Fig 27. Defining our Formula for Bottled Flavoured Tea

Fig 28. Integer Scaling for Bottled Flavoured Tea Tea Liquor is only dispensed in multiples of 10 LT. This is a business decision in keeping with the minimum capacity constraint of the resources involved in producing Liquor Tea. Thus Liquor Tea has a Scale Type as Integer and a Scale Multiple of 10 LT. BOTTLE 500 and BLACK TEA LABEL cannot have quantities in decimals, which is why they too have Scale Type set to Integer. 10 LT of Liquor Tea would require 10 LT/500 ML = 10 LT/0.5 LT = 20 Bottles of 500 ML capacity each. And each Bottle requires one label. Thus, BOTTLE 500 and BLACK TEA LABEL, each have a Scale Multiple of 20. The Scale Rounding Variance has been set to 100% of the Quantity after scaling, and the direction of scaling will always be upwards which means that the quantity of TEA LIQUOR, BOTTLE 500 and BLACK TEA LABEL will be rounded up to the next higher scale multiple. Let us examine this setup with a few specific examples. If we want to scale by the product BOTTLED FLAVOURED TEA, and select the New Item Quantity as 743, then the Ingredients are scaled as shown in Table 1.

15

Table 1 Item BOTTLED FLAVOURED TEA TEA LIQUOR BOTTLE 500 BLACK TEA LABEL Formula Quantity 1000 500 1000 1000 Quantity after Scaling 743 380 760 760

If we want to scale by BOTTLED FLAVOURED TEA and select the New Item Quantity as 1050, then the Ingredients are scaled as shown in Table 2. Table 2 Item BOTTLED FLAVOURED TEA TEA LIQUOR BOTTLE 500 BLACK TEA LABEL Formula Quantity 1000 500 1000 1000 Quantity after Scaling 1050 530 1060 1060

So we find that the system always calculates the exact number of 500 Milliliter bottles required for packing the new quantity of Tea Liquor generated after scaling. There is no mismatch. This is precisely what we want. If we want to scale a formula based on an Ingredient and the Ingredient has Integer Scaling (as in our case), we must ensure that the New Quantity to scale must be a multiple of the Scale Multiple specified for that Ingredient. If not, then we get the error message as shown in Fig 29.

Fig 29. In Integer type Scaling, the New Quantity must be a multiple of the Scale Multiple In Fig 29, if we change the New Quantity to 1720 or 1740 (multiples of the Scale Multiple 20), then the calculations proceed as expected. Defining Activities Responsibility: Process Engineer Navigation: Setup > Activities

16

In keeping with the steps used in producing tea, we have defined a set of Activities (Fig 30) that we shall be using when defining Operations.

Fig 30. Activities in producing Bottled, Flavoured Liquor Tea Defining Resources Generic Resources must be defined for us to create Operations. These can be used to represent one or more actual resources in a Plant. The Calculate Charges checkbox indicates that this resource can be used to calculate charges (refer Fig 73) when a recipe is being created. Charges are calculated at the step level within a Routing and a Recipe and are based on the Maximum Capacity defined within a resource. Another point to note is with reference to the field Usage UOM. If we want Batches to be scheduled based on the Batch Quantity and the Resource Usage in the Operation, then the Usage UOM field must have the same UOM as the UOM defined against the profile option GMP: UOM for Hours. The default value for this profile is Hour. This is why our Resource Usage is measured in Hours, as the figures that follow demonstrate. Responsibility: Process Engineer Navigation: Setup > Generic Resources

17

Fig 31. The Manual Labor used for Processing Raw, Hand-Picked Tea Leaves

Fig 32. The Machine used for Rolling Raw, Withered Tea Leaves

Fig 33. Machine to induce Fermentation in Rolled Tea Leaves

18

Fig 34. Ovens used in the final stage for Drying Fermented Tea Leaves

Fig 35. Machine, which contains and stirs the mix of Tea Leaf, Water and Fruit Essence during Brewing

Fig 36. Heater used in Brewing

19

Fig 37. Separating Used Tea Leaf from Tea Liquor

Fig 38. Machine for Bottling Liquor Tea

Fig 39. Manual Labor for labeling the Bottles

20

Defining Operation Class This is an optional setup. However, defining Operation Classes helps in classifying Operations on some basis for reference purpose. When defining an Operation the Operation Class is associated at the header level. Responsibility: Process Engineer Navigation: Setup > Operation Classes As Fig 40 shows, we have defined three Operation Classes. The classification is based on the three major stages through which the tea production process flows before we get the packaged, ready-to-drink tea out of the raw tea leaf.

Fig 40. Defining Operation Classes for our business Defining Operations Responsibility: Process Engineer Navigation: Operations Operation: LEAF PROCESSING The first operation to be defined is LEAF PROCESSING. The information entered in the header for this operation is shown in Fig 41.

Fig 41. Header Information for the Leaf Processing Operation

21

Thereafter, we need to enter the Activities associated with this Operation and the details of the Resource associated with each Activity. To obtain a bird's eye view of this structure let us take a look at the Operation details as seen on the Product Development Workbench.

Fig 42. The Leaf Processing Operation as seen from the Product Development Workbench Legend:

As Fig 42 shows, there are four Activities in Operation LEAF PROCESSING. Each of these Activities has one Primary Resource associated with it. These are: WITHERING The details of the Resource associated are shown in Fig 43.

Fig 43. Resource details for Withering Tea Leaf ROLLING T LEAF The details of the Resource associated are shown in Fig 44.

22

Fig 44. Resource details of Rolling Tea Leaf FERMENT The details of the Resource associated are shown in Fig 45.

Fig 45. Resource details of Fermenting Tea Leaf FIRING T LEAF The details of the Resource associated are shown in Fig 46.

23

Fig 46. Resource details of Firing Tea Leaf Once the Activity and the corresponding Resource details are in place, the Operation status is changed from New to Approved for General Use so that the Operation can be used in Routings for Production. Operation: BLENDING The second operation to be defined is BLENDING. The information entered in the header for this operation is shown in Fig 47.

Fig 47. Header Information for the Blending Operation

Fig 48. The Blending Operation as seen from the Product Development Workbench

24

The Blending Operation consists of the following Activities and Resources: MIX This Activity involves the mixing of Fresh Tea Leaf and Water, prior to heating. The details of the Resource associated are shown in Fig 49.

Fig 49. Resource details of Mixing Tea Leaf and Water BREWING T This is the Activity of stirring the tea leaves and heating the mix of tea leaves and water. The details of the Resource associated are shown in Fig 50.

Fig 50. Resource details of Brewing the tea concoction FLAVOURING T This Activity involves the adding of Fruit Essence to the tea brew to give it a specific fruity flavour. The details of the Resource associated are shown in Fig 51.

25

Fig 51. Resource details of adding Fruit Essence to the Brew Operation: FILTERING The third operation to be defined is FILTERING. The information entered in the header for this operation is shown in Fig 52.

Fig 52. Header Information for the Filtering Operation

Fig 53. The Filtering Operation as seen from the Product Development Workbench This operation comprises only one Activity FILTERING T. This Activity involves the segregation of used tea leaf (by-product) from the tea liquor. The details of the Resource associated are shown in Fig 54.

26

Fig 54. Resource details of filtering Used Tea Leaf from Tea Liquor Operation: BOTTLING The fourth operation to be defined is BOTTLING. The information entered in the header for this operation is shown in Fig 55.

Fig 55. Header Information for the Bottling Operation

Fig 56. The Bottling Operation as seen from the Product Development Workbench This operation comprises only one Activity that of packing the fruit flavoured liquor tea in bottles with labels. There are two Resources employed under this Activity - T-BOTTLING M/C and TLABELING. Of these, T-BOTTLING M/C is the Primary Resource. This implies that the bottling machine is the critical (bottleneck) resource. This resource limits or determines the throughput. The other resource signifies the use of labor in putting the labels on the bottles. This is an Auxiliary Resource. This resource simply works as an accompaniment to the bottling machine. Labeling bottles is a task that is quick and easy, and does not limit the rate of the Operation.

27

These resource details are shown in Fig 57 and Fig 58.

Fig 57. Resource details for packing Flavoured, Liquor Tea in Bottles

Fig 58. Resource details for Labeling Liquor Tea Bottles Defining the Routing Class Responsibility: Process Engineer Navigation: Setup > Routing Classes This is an optional setup. Due to factors such as evaporation or changeovers, materials can be lost or rendered unrecoverable in a production step. If such losses are anticipated in a Routing then we can define a Routing Class with Theoretical Process Loss percentage figures defined for specific quantity ranges of the material. When defining the Routing, we can assign the Routing Class to the Routing.

28

Fig 59. We have defined a Routing Class for the Black Tea process as shown in Fig 59. Navigation: Setup > Routing Classes > (B) Theoretical Process Loss

Fig 60. Process Loss figures for the tea making process Fig 60, states that when the quantity of Liquor Tea produced is upto 10,000 Liters, then the process loss expected is 2%. However, if the production quantity is anywhere between 10,000 Liters to 100,000 Liters, then the producer usually expect a loss of 2.5%. Defining the Routing Having defined our Activities, Resources and Operations, we are now set to define our Routings. We shall first be defining the Routing for Tea Liquor. Once through, we shall then define the Routing for Bottled Flavoured Tea. Fig 61 shows the header details for the Routing for Tea Liquor.

29

Fig 61.

Fig 62. The Routing for Tea Liquor as seen from the Engineering Workbench

Fig 63. Operations attached to the Routing for Tea Liquor Similarly, Fig 64 and Fig 65 detail the Routing for Bottled Flavoured Tea.

30

Fig 64. The single operation Routing for Bottled Flavoured Tea

Fig 65. The Routing for Bottled Flavoured Tea as seen from the Engineering Workbench Defining the Recipe Having defined the Formulas and the Routings we are now prepared to define our Recipes. The Recipe is what links together a Formula and Routing to make a particular product. A Recipe must have a Formula. A Routing however, is optional. In the course of our testing, we have created more than one version of the Tea Liquor formula (Fig 66).

31

Fig 66. Multiple versions of the same Formula Of these three versions (Fig 66), version 1 and version 3 have been placed on Hold. However version 2 has been Approved for General Use. We will pick this formula version as the base for our Recipe. However, version 2 has a Product (Tea Liquor) Quantity of 2000 LT. We want to scale this down to 500 LT.

Fig 67. Scaling down our Tea Liquor Formula When we save our work, we get the following alert. This is because, we had set the profile option GMD: Formula Version Control to Optional. Had this profile been set to No (default setting), the changes would have been incorporated into the same version. Had this profile been set to Yes, the changes would have been incorporated into a new version of the formula without asking for any intervention from the user.

Fig 68. The consequence of setting GMD: Formula Version Control to "Optional"

32

We click on OK. This creates a new version version 4 of the formula where the Product Quantity is 500 LT. The Ingreditnts and the By-product are scaled down accordingly as shown in Fig 69.

Fig 69. Ingredient and By-product Quantities after scaling down The status of this formula is now set to Approved for General Use. Note: The formula version 4 (just created) will not be visible on the Product Development Workbench. For this formula to be displayed, the Workbench will need to be refreshed. We now proceed to create our first Recipe directly from the Product Development Workbench by selecting Recipes and selecting 'New' from the pop-up we get when we right-click on Recipes (Fig 70).

Fig 70. Creating a Recipe from the Product Development Workbench

33

Fig 71. Step Quantities default from the Routing When entering the Recipe details (Fig. 71), the Total Output Qty in the header is derived by the system by converting the sum of 500 LT of TEA LIQUOR (Product) and 17 KGM of USED TEA LEAF (By-Product) into the Base UOM of the UOM Class specified in the profile option GMD: Yield Type, which is LB. 1 GL = 3.7854 LT = 8.8298 LB of Tea Liquor (as per the conversion factor in Fig 13) Thus, 500 LT of Tea Liquor = (8.8298/3.7854) * 500 LB th = 1166.2968 LB (rounding-off to the 4 decimal place) 1 KGM = 2.2204623 LB Thus, 17 KGM Used Tea Leaf = 17 * 2.2204623 LB th = 37.4786 LB (rounding-off to the 4 decimal place) Thus Total Output Qty = Weight of Product in LB + weight of By-Product in LB = 1166.2968 LB + 37.4786 LB = 1203.7754 LB The Step Quantity against each Operation defaults from what we had entered in the Routing. We have kept the Calculate Step Qty checkbox unchecked as we want to enter step quantities manually. The Plant/Laboratory allows organizations to be linked which use this Recipe, and also to override the default Process Loss. Note: OPM Organizations, which have been defined, as Non-Manufacturing Plants will not be available in the Organizations LOV here.

34

Fig 72. The Validity Rule with which OPM organization PRB uses this Recipe For this paper, we shall have two organizations using the TEA LIQUOR Recipe. Process Industries Bangalore (PRB) is the first of these organizations. Each such organization can have a Validity Rule of its own. Validity Rules allow the user to define how the Recipe will be used in that organization. To enter these details, once we have entered the organization under the Plant/Laboratory tab, we need to click on the Organization Details button. This opens the Organization Details form wherein we can create our Validity Rule for the organization. For organization PRB, we have defined a validity rule (Fig 72) wherein, the Std Qty has been entered as 1000 LT. Note: The Standard Quantity in the validity rule defaults from the Product Quantity entered in the Formula. In our case, the default is 500 LT. It indicates the quantity of product that is made in this organization using the Formula. The Standard Quantity is used for costing purposes. It does not restrict the quantity that can be produced using the Formula specified in the Recipe. Now, keeping Fig 71 and Fig 72 in mind let us look at how step quantities get calculated for validity rules associated to organizations using the Recipe. As per Fig 71, for a Product Quantity of 500 LT, the individual Step Quantities are Step 10 20 30 Operation LEAF PROCESSING BLENDING FILTERING Step Quantity 150 5500 170 UOM KGM LT KGM

However, when we enter the Standard Quantity as 1000 LT for organization PRB, the step quantities in the associated validity rule get calculated as shown in Fig 73.

35

Fig 73. Step Quantities for the Validity Rule associated with org PRB Thus, we find that a/b = c/d where, a = Product Quantity in the Recipe Header (here, 500 LT) b = Step Quantity of a given operation, say Operation 10 in the Recipe Details (here, 150 KGM) c = Standard Quantity of the Product in a given Validity Rule (here, 1000 LT) d = Step Quantity of the same operation (Operation 10) in that Validity Rule (here, 300 KGM) The Charges column also deserves an explanation. Charges are the number of times the Operation must be performed to complete the Step for the specified Step Quantity. For example, the BLENDING operation has three activities - MIX, BREWING T and FLAVOURING T. Each of these activities has a Primary Resource that has a Maximum Capacity of 1000 LT (as can be seen under the Capacity tab in the Organization Details screen). Hence, for a Step Quantity of 11,000 LT, the BLENDING operation will have to be repeated 11 times. Similarly, we have entered another OPM organization Process Industries Hyderabad (PRH) under Plant/Laboratory tab. This organization has its own validity rule with the Product Standard Quantity as 2500 LT. The step quantities and Charges for PRH are calculated accordingly, as explained above. Note: In the white paper Note 279673.1, we had defined PRH as a Non-Manufacturing Plant. In order to use this organization under the Plant/Laboratory tab, we have changed PRH into a Manufacturing Plant. Next, we need to define the Step Material Associations. In the main Recipe Details form, click on the Step/Material Association button at the bottom right corner. The Step Material Association button displays a form, which allows the user to associate each step in the Routing with the materials in the Formula. In this form we simply need to select the appropriate operation step and the Formula Line from separate LOVs and associate one with the other. Fig 74, shows the LOVs we get for selecting operation steps and Formula lines respectively. Fig 75, displays the Step Material associations once they have been completed.

36

Fig 74. The List of Values for selecting Operation Steps and Formula Lines

Fig 75. The Completed Step Material Associations We can now set the Status of the Recipe for TEA LIQUOR from New to Approved for General Use. Once that is done, we proceed to approve the individual validity rules as well. Note: The Status of the Recipe cannot be changed to an approved status if the Formula and/or the Routing are at a lower level. Thus, for a Recipe to be set to Approved for General Use the Formula and the Routing must have the same status as well. The same applies to the relation that the status of a Recipe has with the statuses of its Validity Rules. Approval of the Validity Rules has to wait till the Recipe is approved. Fig 76 shows the Recipe we just created, as seen in the Workbench. Here, we can see the Material associations with each operation step, but not the resources.

37

Fig 76. The Recipe for Tea Liquor as seen on the Workbench Finally, we define the Recipe for our final product, which is BOTTLED FLAVOURED TEA.

Fig 77. Recipe Details of Bottled Flavoured Tea Fig 77, displays the details of the Recipe for Bottled Flavoured Tea. This Recipe too is used by the two organizations PRB and PRH and has a validity rule for each of these organizations. There is just one operation - BOTTLING, for which the step quantity is also shown above.

38

Fig 78. The Step Material Association for Bottled Flavoured Tea Once we are through with entering these details, we approve the recipe for use and then approve the validity rules. Fig 79, displays the Recipe for Bottled Flavoured Tea as seen on the Product Development Workbench.

39

Fig 79. Recipe for Bottle Flavoured Tea as seen in the Workbench The Graphical Recipe Designer Release 11i10 The graphical recipe designer introduced in Release 11.5.10 greatly simplifies the task of creating and maintaining recipes. This is an integrated graphical environment, where formulators and process engineers can collaborate in the recipe development process. All the features available to the Formula, Routing and Recipe forms are now available from a single form the Recipe Designer. It facilitates development of new products as well as making changes to existing products with consummate ease. Recipe Designer is certified for Jinitiator version 1.1.8.16 and above. We shall now repeat the steps of formula, Routing and Recipe creation using the Recipe and the Routing Designer provided in 11.5.10. This helps us appreciate the simplicity with which products can be formulated now, as opposed to the direct entry mode using the Formula, Routing and Recipe details forms. Creating a Formula in the Recipe Designer Formulator > Recipe Designer The blank Recipe Designer screen is displayed in Fig 80.

40

Fig 80. The Recipe Designer To create a Formula we will need to click on the Formula tab. Since we are about to create a new formula, the Formula icon displays the word NEW followed by a comma (,) and the number 1 denoting the version. Right-click on this icon and select Properties... from the pop-up list as shown in Fig 81.

Fig 81. Creating a new Formula in the Recipe Designer This will launch the Formula Properties window. Enter the Formula header details in this window as shown in Fig 82.

41

Fig 82. Entering the Formula Header information We now need to enter the Formula Line details (Fig 83).

Fig 83. The Product, Ingredient, By-Product needs to be associated Navigate to the Item List region at the bottom left of the designer. In the Find field enter part of the item code and then click on the Find button. This will retrieve from the Item Master, the item(s) matching the search criterion.

Fig 84. Conducting the Item Search

42

Now, click on this item and drag it to the Navigator region (Fig 85) and drop it into the TEA LIQUOR formula.

Fig 85. Drag and drop operation performed for the first item A successful drag and drop operation will pop-up the New Item window as shown in Fig 86. Select the Type as Product and enter the Quantity (default value 0) and the UOM, which you want this item to have in the Formula. Click OK. We have just defined the Product for our Formula (Fig 87).

43

Fig 86. Enter the details for the item

Fig 87. The product for the Formula has been defined

Fig 88. When required to add details to an Ingredient

44

Continuing in this manner, we add WATER as an Ingredient. However, there are a few details to be added to this Ingredient. Select the Ingredient from the Navigator and right-click on it. Select Properties from the pop-up list (Fig 88). This will open the Ingredient Properties window (Fig 89). Here, we enter the Scrap Factor of 10%, and consequently, the Required Quantity would be set to 550 LT (Fig 89).

Fig 89. Adding detailed information in a Formula Line At any step during the designing of the Formula, if we want to add Process Instructions to any of the entities constituting the Formula, all that we need to do is to select that entity, right click on it and select Edit Process Instructions from the pop-up list (Fig 90).

45

Fig 90. To write Process Instructions for FRESH TEA LEAF This will open a window where we can enter the required text (Fig 91).

Fig 91. Writing Process Instructions for FRESH TEA LEAF Note: This method of entering Process Instructions applies to Formulas and Recipes entered through the Recipe Designer and to Routings entered through the Routing Designer. The Process Instructions entered in this manner will reflect immediately on the right half of the Recipe Designer screen, under the Process Instruction Sheet tab. When trying to save the Formula, we get a message as in Fig 92. This error implies that a Recipe has not yet been associated to the Formula. As soon as we click on the OK button, we are presented with the Recipe Properties window (Fig 93).

46

Fig 92. This error implies that a Recipe has not yet been associated to the Formula

Fig 93. Creating a Recipe for our new Formula At this stage, we use this window to enter the bare minimum Recipe Header level information, and then click OK. Thus we complete creating a Formula for TEA LIQUOR with the creation of a Recipe of the same name. Creating a Routing in the Routing Designer Process Engineer > Routing Designer Since a Routing is not a mandatory component of a Recipe, a separate graphical tool has been provided in the form of the Routing Designer, to create Routings using the drag and drop utility. In just about the same way as we created a Formula in the Recipe Designer, we begin designing our Routing by entering the header level information (Fig 94).

47

Fig 94. Entering Header level information for our Routing We then search for our first operation LEAF PROCESSING and use the drag and drop feature to attach it with the TEA LIQUOR Routing (Fig 95). The moment the drag and drop operation succeeds, the Step Properties window pops up (Fig 96). Here, we can enter the details of the Operation. At this point of time we will not be able to enter Step Dependency information. Entering this information will have to wait.

48

Fig 95. Using drag and drop to associate an Operation with the Routing

Fig 96. Entering Operation information in the Step Properties window In this way, our Routing gets created (Fig 97).

49

Fig 97. Our Routing now has its Operations in place What remains now, is to create the Step Dependencies. We need to click on the Step Dependency tab on the bottom right corner of the Routing Designer screen. The operations we had attached to this Routing are available and displayed, but the step dependencies between them are yet to be defined (Fig 98).

Fig 98. Operations with no Step Dependency defined

50

From the menu bar select Actions > Generate Step Dependencies. Select the radio button that displays the required Dependency Type (Fig 99).

Fig 99. Defining the Step Dependency If you want to select the orientation (vertical or horizontal) in which the operations will be arranged for display, check the Distribute Steps checkbox and then go on to select the appropriate Style.

Fig 100. Step Dependencies created

51

The system immediately creates the dependencies marked by arrows (Fig 100) and based on the sequence of the step numbers that we had entered for each operation in the Step Properties window (Fig 96). Now, if we double click on the arrow between say, Operation 20 and Operation 30, the Step Dependency Properties will be displayed in a separate window of the same name (Fig 101). In this window, we can modify the Dependency Type, Standard Delay and the Transfer%.

Fig 101. Step Dependency Properties This completes our Routing definition in the Routing Designer. Creating our Recipe in the Recipe Designer Process Engineer > Recipe Designer When creating our Formula for Tea Liquor, we were required to associate it with a new Recipe of the same name (Fig 93). At that point of time our purpose was served simply by entering the Recipe Name and Description.

52

Fig 102. Adding details to the existing Recipe in the Recipe Designer Therefore, we already have a Recipe called TEA LIQUOR. Select this Recipe, right-click on it and then select Properties from the pop-up menu. This will bring up the Recipe Properties window. In this window, under the Recipe and the Formula tabs, the information already exists. However, under the Routing tab there is no information as a Routing is yet to be associated with this Recipe. To fill this gap, we shall attach here, the TEA LIQUOR Routing that we have already defined (Fig 103).

53

Fig 103. Associating a Routing to the Recipe in the Recipe Designer Now, once again we can open the Recipe Properties window and click on the Plant/Laboratory or the Organization Details button. This will open the Organization Details form wherein we can enter the OPM Organizations or Laboratories that use this Recipe, and enter the organization specific Standard Quantity (for the Product TEA LIQUOR) and other details if required. In this mannner, we can enter Validity Rules for these organizations, create Step Material association and then commit our work. Thus the Recipe Designer displays the Recipe as shown in Fig 104.

Fig 104. Our Recipe in the Recipe Designer

54

Using the Recipe Designer to modify our Recipe The drag and drop utility built into the Recipe Designer can also be used to conveniently add, replace or remove components from recipes. In our case, suppose we plan to introduce Sugar as an Ingredient into the Blending operation. To begin with, search for items in the Item Master. Select Item Master from the drop down list that had earlier displayed Formula Items, enter "%" in the Find field and click on the Find button. All items are now displayed in the bottom half of the screen. Scroll down to select Sugar (Item Code 4812) from this list (Fig 105).

Fig 105. Dragging and dropping additional Ingredients from the Item Master into the Recipe Enter the appropriate Quantity in the New Item window that pops up (Fig 106).

55

Fig 106. Entering the details of the new Ingredient

Fig 107. The Item 4812 has been added as Line 4 under Operation 20 in the Step Material Associations of the Recipe The inclusion of Sugar (Item Code 4812) as seen in Fig 107, will also reflect in the Formula associated with this Recipe. Safeguarding Our Formula Information Setting Up Formula Security Up until now, the formulas we have created are accessible to all users from the Formula Workbench. Using the Formula Security feature bulit into OPM Product Development and introduced in OPM Release 11i7, we can ensure that once the Formula Security feature is enabled, only specific users and/or Responsibilities that (i) are assigned to the organizations owning the formulas, and (ii) have been included in the security profiles for the formulas owned by these organizations will be able to either view in query-only mode or update these formulas. Two responsibilities are pivotal to the implementation of this feature. These are the Product Development Security Manager and the Product Development Security Profile Manager. The person setting up Formula Security (referred to as the Product Development Security Manager) needs to be given these two responsibilities.

56

The Product Development Security Manager assigns organizations to formula security, and determines if access to formulas is controlled at the user level, responsibility level or at both levels. The organizations assigned to formula security are organizations that own the formulas. The organization owning the formula determines the access to that formula. The Product Development Security Manager also controls the activation and the deactivation of formula security. The Product Development Security Profile Manager assigns security profiles for the formulas owned by the organizations. A security profile determines a user's access to these formulas. Access is defined at the user level or the responsibility level depending on the level of control specified by the Product Development Security Manager. The user must be associated with the owning organization to qualify for the security profile unless the Other Organization field is specified. If the Other Organization field is specified then the user must be granted access to the Other Organization. Returning to the case presented in this paper, we are yet to set up Formula Security. In the absence of Formula Security the situation stands as depicted in Fig 108.

Fig 108. Formulas other than the ones that I own are also accesible to me Responsibility: Product Development Security Manager Navigation: Security Control This will open the Product Development Security Access form (Fig 109). This form enables the Product Development Security Manager to control access to the Formulas. Here, we have listed PRB and PRH as two organizations that own formulas to which access needs to be restricted. For both PRB and PRH, we have set the User field to Yes. This implies that for both these organizations, we shall be able to specify user level access to formulas in the Product Development Security Profile form.

57

Fig 109. Restricting access to formulas owned by organizations PRB and PRH Similarly, setting the Responsibility field to Yes, implies that we desire to have the option of specifying responsibility level access to formulas in the Product Development Security Profile form. The Formula Security Enabled checkbox if clear, implies that formula security is disabled. The recommended practice is to complete entering data in the current form and then complete dataentry in the Product Development Security Profile form before checking this box. Save your work. Responsibility: Product Development Security Profile Manager Navigation: Security Profiles Here, we get an LOV listing the two organizations we had enterd in the Product Development Security Access form (Fig 109). We select PRB. Note: As of now, no formulas have been defined in PRH. We are now in the Product Development Security Profile window (Fig 110). In the User field we enter the user name SAUMIT. The Assign Method field has two options Automatic and Manual. Automatic implies that the specified View or Update access level is assigned automatically to the specified user, organization, and responsibility combination. Manual indicates that the specified View or Update access level has to be granted manually for individual formulas using the Users Assigned to Formula window.

58

Fig 110. Providing Update rights to user SAUMIT for all Formulas owned by organization PRB There are two values for Access Level Update or View. Update implies that the user, organization and responsibility combination has the privilege to modify or update existing formulas. View implies that the formulas can be accessed in query-only mode. Save your work. Responsibility: Product Development Security Manager Navigation: Security Control We now check the Formula Security Enabled box (Fig 111), and commit our work.

Fig 111. Enabling Formula Security Responsibility: OPM All Navigation: Formulator > Formulator Workbench Now, on the Product Development Workbench, the user SAUMIT can only see the formulas that are owned by the organization PRB (Fig 112).

59

Fig 112. What the user SAUMIT now sees in the Formula Workbench Bringing in JOE_SOMEBODY There are times when a Formula Setting should be applied to all users. So instead of listing each individual user, we require some utility by which we can set up a "generic" user. We therefore need to define a generic user and then specify this user name against a profile option GMD: User Name for All. Responsibility: System Administration Navigation: Security > User > Define We shall now create our generic user - JOE_SOMEBODY (Fig 113).

Fig 113. Creating a Generic User representing ALL other users We shall now log out as user SAUMIT and log in as JOE_SOMEBODY (Fig 114).

60

Fig 114. Logging in as our Generic User Responsibility: OPM All (This is the only responsibility that JOE_SOMEBODY has) Navigation: System Admin > System Setup > User Organizations We need to assign JOE_SOMEBODY to the two organizations PRB and PRH, which have been entered in the Product Development Security Access window (Fig 115).

Fig 115. Assigning our Generic User to the Formula Owning organizations Still logged in as JOE_SOMEBODY, if we now open the Formulator Workbench, we find that this user does not have access to any formula! There are still a few more steps to be completed. Log out as JOE_SOMEBODY and log in as SAUMIT. Responsibility: System Administrator Navigation: Profile > System Enter JOE_SOMEBODY against the profile GMD: User Name for All (Fig 116).

61

Fig 116. Now, JOE_SOMEBODY becomes a representative for all users Note: The profile GMD: User Name for All must always be set at the Site level, since it is the value that Formula Security uses to indicate that all users for an organization are given a certain level of access to the formulas. Responsibility: Product Development Security Profile Manager Navigation: Security Profiles Select organization PRB. Add a security profile for JOE_SOMEBODY, such that this user can view (not update) all formulas owned by PRB (Fig 117).

Fig 117. Creating a security profile for JOE_SOMEBODY For the last time, log out as SAUMIT and log in as JOE_SOMEBODY Access the Formulator Workbench. JOE_SOMEBODY can now see the formulas owned by PRB (Fig 118).

62

Fig 118. Formulas accessible to JOE_SOMEBODY Now, open the Formula TEA LIQUOR in the Formula Details form. The form opens up in queryonly mode (Fig 119) confirming that JOE_SOMEBODY has View only access to these formulas.

Fig 119. JOE_SOMEBODY can only View, not Update these Formulas This completes our Formula Security Setup. ACKNOWLEDGEMENTS I wish to record my sincere appreciation towards Bill Stearns, Glenn Ruhl, Duan R. Hope, Pieter Els, Robert Vanderhagen and Samir Karoui. The content published in this paper is a culmination of the valuable inputs and feedback received from these individuals from time to time. I am deeply grateful to my friends Moloy Das and Debojeet Halder from the Simulbari and Marionbari Tea Estates of Kurseong Police Station in Kurseong Sub-Division of the District of Darjeeling in the state of West Bengal, India. The able guidance provided to the author by these two individuals has been pivotal to the documentation of the processes employed in the production of the famed "Darjeeling tea". Last but not the least, my heartfelt thanks are reserved for Diane Davis for her invaluable help with the publishing of this paper. About the Author Saumit Mandal CPIM, is a Principal Support Engineer at Oracles India Support Center, Bangalore. As a member of the Global Applications BDE team, he works on the domain comprising the products under Core Manufacturing.

63

References OPM Product Development Functional Overview: Recipe Designer presented by Bill Stearns (content published by Oracle University). Oracle Process Manufacturing Product Development User's Guide Release 11i (Part No. A92170-05), July 2003. Oracle Process Manufacturing Product Development User's Guide Release 11i (Part No. A92170-06), August 2004. A Guide to Oracle Process Manufacturing System Setup; An Oracle White Paper, July, 2004 (Note 279673.1) Saumit Mandal CPIM.

White Paper: Making Tea with GMD: A Case Study in OPM Product Development 11i10 January, 2005 Author: Saumit Mandal CPIM Oracle Corporation World Headquarters 520 Oracle Parkway Redwood Shores, CA 94265 U.S.A. Worldwide Inquiries: Phone: +1.652.526.7000 Fax: +1.652.526.7200 www.oracle.com Oracle is a registered trademark of Oracle Corporation. Various product and service names referenced herein may be trademarks of Oracle Corporation. All other product and service names mentioned may be trademarks of their respective owners. Copyright 2005 Oracle Corporation All rights reserved.

64