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.

1
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.

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.

3
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 pre-
processed 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.

4
Fig 3. The Product Structure of TEA LIQUOR

5
Fig 4. The Product Structure of BOTTLED FLAVOURED TEA

6
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

7
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.

8
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

9
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, By-
product 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 Formula Quantity Quantity after Scaling

BOTTLED FLAVOURED TEA 1000 743
TEA LIQUOR 500 380
BOTTLE 500 1000 760
BLACK TEA LABEL 1000 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 Formula Quantity Quantity after Scaling

BOTTLED FLAVOURED TEA 1000 1050
TEA LIQUOR 500 530
BOTTLE 500 1000 1060
BLACK TEA LABEL 1000 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 T-
LABELING. 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 Operation Step Quantity UOM

10 LEAF PROCESSING 150 KGM
20 BLENDING 5500 LT
30 FILTERING 170 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 data-
entry 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 query-
only 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