Outcome Based Approach

Disclaimer: I have been writing the blogs in the style of story telling based on real incidents but with some fiction added to emphasize the message. Hence please do not conclude anything based on the blogs. 

I received an email from Bhahmaji and I knew this will never be simple. Bharhaji recently went and visited a Customer. This means, the email from Bhahmaji will very likely contain all descriptions on how dissatisfied the customer is, and how the Customer is going to terminate the contract, and how Customer may sue us for a penalty of a few millions. Brahmaji loves to have escalations and reminds the customer on what all the areas when Customer can be unhappy. And than we will see Brahmaji floating emails and action plans on how is he going to address all Customer Concerns. Unfortunately even many organizations have a culture of appreciating leaders who address the escalations. But the leaders who do everything proactively and ensure no escalations are ignored and they may even be asked to leave to accommodate another blue eyed boy (or girl) to manage that "smoothly" running Portfolio.

I was used to it but still I needed to give some attention because at times Brahmaji could be right as well. ​When I opened the email, it was all the same. Customer has lots and lots of complaints and all were opened up when Balaji met them. Not even one was discussed in the weekly customer calls and even som daily calls.

Customer has serious concerns on our ability to do Continuous improvements. He was also worried about the Automation Opportunities which we never worked. He is highly disappointed about us not contributing towards any productivity gains. Support was going, all tickets were being fixed but with no interest on Customer's Business Problems.

Brahmaji completed the email with a statement that the Customer who has been with us for the last 5 years may leave us any day in next week including tomorrow.

He scheduled a crisis meeting.

I fortunately had time to accommodate myself to the discussion.

By the time I joined the call, I was hearing Brahmaji shouting on all the team for not doing anything. I heard the conversation without disturbing the flow of communication. Finally I announced my presence and asked Bhrahmaji on what is the action plan now.

Bhrahmaji said that we made action plan already and here are the major items.

​Action item	​Owner	​Target Date	​Status	​Remarks
​Daily Internal review meeting to be scheduled	​Bhahmaji	​Tomorrow	​Completed	​A Daily meeting calendar generated
​Weekly Project review meeting	​​Brahmaji	​Tomorrow	​In Progress	​Checking with Leaders availability
Steering Committe Review Meetinq ​	​Bhahmaji	​Next week	​In progress	​Checking with Steer Co member availability
​Speak to COE for Support on XXX Technologu	​Keshwa	​Next week	​Open	​XXX technology is required to do the task and the Project Manager needs to get the inputs from COE
​Initiate VISA requet for Apparao	​Chris	​Next week	​Open	​Apparao has to travel to execute Quater Closure issues
​....	​....	​....	​....	​...
​	​	​	​	​

I went through the entire list. For some time I didn't understand what is the plan. I was asking Bhrahmaji "What are the issues? and how are we going to address them?"

"Sir, I already shared the action plan. This plan is to address all concerns and issues raised by the Customer"

"OK. Please explain how are we going to address"

"I scheduled a Daily review call to discuss issues every day"

"OK. than?"

"We will fix the issues. We also scheduled a Project review on weekly basis. We talk to Steering committee on weekly basis and ....."

I opened the action items sheet and said. "Bhrahma.. all the action items that you mentioned will be completed once we schedule the meeting calendar and after a couple of discussions like initiating VISA request, discussing with COE etc. But at the end of closing all these action items are we sure the Issues are addressed?"

Bhahmaji was a bit silent.

"No sir. These are for solving the issues"

"Where is the plan to solve the issues and where is the rationale to decide whether the concerns of the Customer are addressed?

"...."

Can you Please explain what do you want to do and what do you expect to hear that the customer is happy?

"Hmm. If we do these reviews regularly ..."

"Bhahma! do you want the customer to explain what needs to be done to make him happy through these review meetings?"

"This is how I have been making him happy ..."

"Probably you could do that but you always wanted to hear from Customer through several discussions and than do the needful. Why cant we do this before Customer puts this much effort?"

"I cant say anything but it worked"

"OK, how are we going to ensure there is continuous improvement? What are the Automation Opportunities? What is the meaning of Fixing issues without interest and how can you convince customer that we are fixing issues with interest? ...."

"As of today I am not sure sir. But through these reviews ...."

They are all interlinked. You need to analyze and review the support tickets and summarize.

The issues can be repetitive. That is when you need to work on educating and ensuring elimination of the issues through root cause analysis. And by nature if they are bound to repeat, prepare a good Solution document and share instead of fixing them every time.

The issues can be knowledge gaps. In such case propose additional training. Once again the training's can be self paced through View Lets, recorded training's or Idiot guides so the audience don't depend on physical training's. Update the training manuals if required.

The issues can be due to Data. The Data issues can be either because poor migration and conversion scripts for data from other systems and cause Data Corruption regularly. It can also be because of the poor development without restricting the wrong entries without validations. You may have to investigate and clean the scripts apart from fixing the specific data issues.

The issues can also be because of wrong set ups of transactions and parameters. Explain on why certain transaction behave because of the setup and educate the customers to arrive at the right setup. You may also visit the documentation and any need for special training's on them.

Finally the tickets can be for technical Bugs. These are fully because your coding was not doing what was intended. Fix them completely and test thoroughly.

For every issue, tailor your ticketing system to take the inputs on how the addressing or not addressing the issue impacts the Business. This helps you understand how the system is being impacted. Identify the kind of tickets which take longer to fix either because of the external dependencies or by the process. And identify those kind of tickets which impact the Business to Maximum. Pick the top ten and try to optimize them to fix them fast and reduce SLA.

Bhrahmaji seems to have understood but his face shows there are still some open questions.

I picked on ticket that too 4 days to fix the issue.

The ticket is for creating a User to one data warehouse. Why is this taking 7 days ? I looked at the SLA for such type of ticket. The SLA itself was 7 days.

I got in to the details. The User enters the Ticket in the system with the details of his system, and many technical parameters such as Proxy address etc. Many users are not familiar to enter these details. I have seen the support engineer taking the appointment to guide the user to enter these details. User enters the details and than resubmits the details. Support engineer gets some details on her own. Finally the synchronization of the Windows user with this Data-warehousing system takes 30 minutes.!!!!

I said this is an automation opportunity. Brahmaji quickly said that this takes 60 person days to make the Single Sign on.

What is the ticket volume for this User creation? 1200 tickets per quarter. (AUTOMATION)

Hence it is worth doing. All tickets of this category will be eliminated to free at-least 2,3 days of effort per ticket of the users who are supposed to work for business. This means about 2400 Person days of productive time gained by the Customer. These hours can be utilized any where-else for the productivity (PRODUCTIVITY GAINS). In addition, the Users start working in the Data-warehouse within no time. This is again Productivity gain !!!

Now, we continue this kind of analysis and present our observations periodically to the Steering Committee for prioritization and some investment from their side as well for more efficient system and with more productivity. (CONTINUOUS IMPROVEMENT)

Can the Customer say now that we are fixing the tickets without Interest on Customer ?

Know your Business Problem: Define Problem Statement

One day, I got an urgent call from my fellow leader Anil rathod that there is a serious escalation from the Customer and needed some help. I immediately went to his work place to understand the situation.

"Khaderao, I need as many technical people as possible from your team for the next 6-8 weeks. Please .. I cant fund them as the project is already overrun but I need your help"

I replied "I will try my best, but can I understand the issue and reason for escalation?"

"We need to load 4000 Sales order lines in to the Customer's ERP. They need this to be completed by this week or next"

"Oh, I heard this Cutomer went live recently. Why this escalation?"

"The customer went live 2 months ago. But they didnt enter any Sales orders and continued in their legacy system. Now they realized that they needed all these lines in ERP"

"If that is the case, why is the escalation?"

"Our team told that this can be done only in 4 weeks and asked for a Change request"

"Hmm"

"Customer says no one guided them and informed that Sales orders needed to be entered in ERP"

"Interesting. Once went live, all transactions must be in ERP unless there was a different plan"

"True. But he says no one informed them on the same"

"OK. Now what is the plan"

"I have a very meticulous plan and I am sure we can get there. But I need about 20-25 technical people to execute the plan"

"Why cant the customer wait for 4 weeks if thats what it takes?"

"One second. Let me check."

Anil called the Onsite Project Manager and after a couple of minutes, he said "the Customer needs these lines to be in the ERP before end of Financial Year to show the accounts receivables.... Otherwise his true budget will not be reflected and he will not get sufficient funds for next year"

"How much is the amount approximately"

Anil called his PM again.

"4.85 Billion Dollars"

"Oh." (Now I understand the business Problem)

"OK Anil, can we meet your team?"

On the way to his team working place, I called my technical people to reach there.

When I went there it was a great scene.

Sikhandi was talking to about 15 people.

"Pani, you take the first 100 lines, Veena take 101 to 200. Charles you 201 to 300..... And all of you will be working here till we are finished. I will arrange food and bed for all of you. Ibrahim, you need work with overlaps and keep updating the Onsite team..."

Sikhandi's face was glowing with excitement about the kind of meticulous plan he is going to execute.

In a span of 1 hour Customer made 2,3 calls to know what is the progress. Entire team is full of pressure . But Sikhandi is quite excited to do this.

In the mean time Sikhandi prepared a Dashboard to show how many lines are completed, in progress and yet to be migrated. He generated some charts as well to show the same report in colors and figures.

While Sikhandi's speech was going on, I went to the team lead kind of person and asked her to let me have a look at the list of lines to be migrated to ERP.

I asked her to sort the list in descending order of Line amounts. I generated a Pareto chart to check the lines that cover 80% of the revenue. It needed about 850 lines which are actually amounting to close to 4 Billions.

I waited till Sikhandi completed the speech.

"Anil, please take these 850 lines and distribute to the teams. Let this round be completed with full focus. and there cant be any errors or iterations and they all must work fine once migrated to ERP"

The team got the redistributed list. I told them to take the same time as planned earlier for 4000 lines but do the migration perfectly.

In the mean time customer made a few more calls. I kept the phone disconnected.

By evening the 850 lines were completed and tested.

I asked Sikhandi to provide the Update. Sikhandi was not happy. He however fed the report. Now the graphs show 850 lines completed with % of work completed and so on.

I tweaked a few things and modified the graphs to show how much revenue is covered instead of lines migrated.

Sikhandi was not happy. "We have been sending the progress in terms of lines. I prepared a great dashboard. Now you are sending something else"

I said "Sikhandi, I am not competing with you. For that matter no leader needs to compete with his own team. You are going to send this email with this progress. In the body of message please clearly mention that you covered 80% of the revenue amount to reflect in the ERP."

Sikhandi is a bit relieved. The email was sent. Anil called the customer and updated the same.

"Now you wont get any more calls from the Customer. Please continue the work and complete the rest of the lines in the order that is prepared by Sikhandi (???). "

"Also please ensure ! the Customer should now enter the sales only in ERP. No more lines in the Legacy system please.... "

***

This may conclude that

•  Understand the Problem Statement instead jumping to Solutions
• The key is to identify what is really impacting the stakeholder from the Problem
• Work for sufficient time to understand and plan the right task in place of jumping to tasks with no plan
• The Focus must be on the final outcome
• Every time lining up bunch of people may not work if the plan is missing

Process Modelling Approach: Some Best Practices

 Modeling Approach and Configuration options

1        Modeling Enterprise Business Processes

1.1      Introduction

Before defining the process in any tool such as Oracle BPA Suite, the Organization / Department needs to work on the way the Models are described along with the amount of granularity that they want to show in the detailing. The modeling structure as well as the way the organization wants the employees to access the information are important before proceeding to define the individual process maps. In this context, the Process Architect or the one who leads the team of process modeling needs to get an understanding on the way the access privileges work on the specific modeling tool being used as some of the decisions may be influenced by the way the access restrictions happen. In this document, I attempted to explain some of the approaches in structuring the process definitions as well as the way we need to configure the Tool for effective modeling.

1.2      Target Audience

The target audience is conversant with the business process definitions and familiar with one or two modeling tools such as Oracle BPA. The scenarios explained in this document referred to Oracle BPA Suite. Hence the familiarity with the tool and its offerings will be handy. The audience is also expected to be knowledgeable on the popular modeling notations such as EPC and BPMN.

1.3      Top-Down Approach

The suggested practice is to follow what is called Top Down approach. Define the possibility of viewing a value-added chain in its entirety, i.e. from the end user to each of the entities (organizations, customers, suppliers and other parties) involved in a procedure, provides a basis for depicting the overall business and establishing the scope for optimization.

The objective is, for example, the improvement of the supply chain, the lowering of procurement and distribution costs of Raw material or the optimization of the information system architecture.

You can define the top process in many forms and some options include Value added chain diagram and E-Business Scenario diagram (Please note that the term E-Business has no relevance to Oracle EBS and is a generic term used in this context).

Value added chain diagram helps you represent the end to end flow in terms of flow of goods and services till the value is achieved. The process starts with the Source and inputs and ends with the value point.

The E-Business scenario diagram representation allows visualization of the content to be examined to attain the designated objectives. By selecting the type of column representation, the interfaces between very different process partners are abstracted and mapped via the column borders. Various reports supplement the models and offer important analysis capabilities.

1.3.1       Value added Chain Diagram

The value-added chain diagram specifies the functions in a company which directly influence the real added value of the company. These functions can be linked to one another in the form of a sequence of functions and thus form a value-added chain.

In the value-added chain diagram, functions can be arranged in a hierarchy similar to a function tree. Process-orientated subordination or superiority is always illustrated.

As well as the representation of function subordination or superiority, a value-added chain diagram represents the links between functions and organizational units and functions and information objects. The allocation of organizational units to functions differentiates, as in process chains, between technical responsibility, IT responsibility and the execution of a function.

An example is shown here.

Figure 1‑1: Value Added Chain Diagram

Major object types that you can use to represent this high level picture of your business include Functions, Organizational unit types (ex: Department like IT), Organization units (ex: Network admin, System admin, Hardware procurement), Person types (roles), groups (grouping objects of similar nature for better presentation) and Product / Service etc (outcome of your process).

For every function you can define the association with the role that is responsible or contributes to the function along with the departments that are associated.

1.3.2       Drill down to the details of High Level process

From the top level process representation you can generate the sub-processes which can be mapped to the function blocks in the higher level process that will help you drill down to the lower level processes. For example, the “Procure to pay” high level process of Value added chain diagram has the functions such as requisitions, RFQ till the last function Invoicing. You may define the elaborated definitions of each of these processes and map to the parent function as assignment.

You have defined the elaborated process definition of, say Requisition as shown in the figure below:

Figure 1‑2: Process at Detail level 1

Represent who performs what

While defining each function you may also define whether the function is performed by person or by an application system.  If performed by an application system, you can provide the details such as which system/ service performs the function along with other pieces of information such as input and output from this function.

If the task is performed by a person you can provide the relevant details of to whom the task is assigned, who must be informed and approval chain (if any).

The function may also be a notification to relevant parties. You can define all the information such as the subject, body of the notification, recipients, FYI recipients and BCC etc.

You may also establish the relation to the parent process Requisitions in the Value added chain diagram to enable the drill down.

In the similar manner, you may create another assignment (Right click à New à Assignment) from say, Manual requisition to create another process model defining the manual requisition process with the established relation between the new model and the superior model (Manual requisition).

Figure 1‑3: Process at Detail Level 2

1.4      Content structure and definitions

Depending on how you want to organize your contents, you may be storing the objects relevant to organization (people, roles, departments etc), Data (all input and output information), Application systems (B2B platform, Enterprise Applications, web services etc that perform automated activities) and the processes in different folders for better management.

Irrespective of organizing your models and objects, the drill down takes you to the relevant information through assignments to next level models and other objects. However, from the aspect of access control and easy management, deciding the folder structure for models and objects is important.

1.4.1       Scenario 1:

You may want to display the model definitions but not all or some of the information related to Business Data, Application Systems and Organization data.

Define the folders somewhat as follows:

Root folder (Main group)

-        Business Processes

-        Business Data

-        Organization Data

-        Application System data

Example:

Procure to pay high level process; elaborated processes of each process are stored in the folder Business Processes. Each of the processes may use the objects from other folders such as Data, Organization and Applications.

All data related objects such as Purchase requisition; Purchase Order, Invoice, and Quote are stored in the Business Data folder.

All objects such as (departments) Warehouse, Finance, (person types) Buyer and Requestor are stored in the folder Organization Data.

All Application / Service related objects such as Oracle requisition lines are stored in the folder Application System Data.

Now in the administration module you can provide the access privileges according to whether the user can access only process, or process and data, process and Organizational data and so on.

Only the person with write privileges for Data folders can define the data objects. In the same manner, only privileged persons will define the other part of process definition.

Modeling Process: type of model and objects

1.      Central server can have the BPA installed with the folder structure

a.      Each modeler owns one folder or sub folder and has rights only to that folder.

2.      The same structure is replicated in the individual modeler systems.

a.      Each Modeler works on each of the folder components in Business processes, Business data, organization data and Application data.

3.      Using the XML Export and Import approach the modified components can be synchronized with the folder of central server.

a.      XML import provides the options on whether the target values are overwritten or retained.

b.      It also provides the option to fill only those elements which don’t have values but retain the rest of target elements

4.      The individual modeler exports the modified components to a file and sends to the administrator.

5.      The administrator imports the contents to the right folder.

In the business publisher, the view of the processes will be according to the access privileges defined.

1.4.2       Scenario 2:

You want to display and restrict the function privileges as per the detail level of the processes. This means some users can view the process definitions only at certain detail levels while the others may have access to more details on the process.

Define the folders somewhat as follows:

Root folder (Main group)

-        Highest process level

-        Drill down level1

-        Drill down level2

-        ……………

Modeling Process:  Level of detail

1.      Central server can have the BPA installed with the folder structure as above

a.      Each modeler owns one folder or sub folder and has rights only to that folder.

2.      The same structure is replicated in the individual modeler systems.

a.      Each Modeler works on each of the folder components in Business processes as per detailed level to which he is authorized.

3.      Using the XML Export and Import approach the modified components can be synchronized with the folder of central server.

a.      XML import provides the options on whether the target values are overwritten or retained.

b.      It also provides the option to fill only those elements which don’t have values but retain the rest of target elements

4.      The individual modeler exports the modified components to a file and sends to the administrator.

5.      The administrator imports the contents to the right folder.

1.4.3       Scenario 3: Combination of both

You may want to manage the models and objects according to the level of detail (High level, detailed level definitions) as well as the type of detail (Model, Data objects, Organization data objects and Application systems)

Define the folders somewhat as follows:

Root folder (Main group)

-        Highest process level

o   Business Processes

o   Business Data

o   Organization Data

o   Application System data

-        Drill down level1

o   Business Processes

o   Business Data

o   Organization Data

o   Application System data

-        Drill down level2

-        ……………

Define the access privileges according to the folder structure and the function privileges you want to assign to the users.

For example, user 1 may be able to database management for only highest level business processes and read only access to business, organization data of high level process. Define the privileges accordingly.

Modeling Process:

1.      Central server can have the BPA installed with the folder structure

a.      Each modeler owns one folder or sub folder and has rights only to that folder.

2.      The same structure is replicated in the individual modeler systems.

a.      Each Modeler works on each of the folder components in Business processes and some or all of the sub folders Business data, organization data and Application data.

3.      Using the XML Export and Import approach the modified components can be synchronized with the folder of central server.

a.      XML import provides the options on whether the target values are overwritten or retained.

b.      It also provides the option to fill only those elements which don’t have values but retain the rest of target elements

4.      The individual modeler exports the modified components to a file and sends to the administrator.

5.      The administrator imports the contents to the right folder.

1.4.4       Scenario 4:  Processes and other data

You want to maintain all the supporting data (Business data, Organization data and Application System data) at the root level but processes are defined as per the extent of details. This may mean that the different modelers may define the models at different details while there will be separate group of people who define the data.

You can define one set of users who can have read, write access to some or all of Business data, Organization data and application data.

You can define another set of users who can have read / write access to some or all of Highest level and other levels of detailed process definitions for modeling.

Modeling Process:

1.      Central server can have the BPA installed with the folder structure

a.      Each modeler owns one folder or sub folder and has rights only to that folder.

2.      The same structure is replicated in the individual modeler systems.

a.      Each Modeler works on each of the folder components in some or all of Business processes and some or all of Business data, organization data and Application data.

3.      Using the XML Export and Import approach the modified components can be synchronized with the folder of central server.

a.      XML import provides the options on whether the target values are overwritten or retained.

b.      It also provides the option to fill only those elements which don’t have values but retain the rest of target elements

4.      The individual modeler exports the modified components to a file and sends to the administrator.

5.      The administrator imports the contents to the right folder.

1.5      What is important?

A good brain storming session among the modelers is important to arrive on the following parameters:

1.      Levels of details for process that you want to have

2.      Naming conventions for all data objects and processes

3.      Identify all the objects (business, data and Application)

4.      The associations of objects with the functions

5.      Access levels for modeling and viewing

6.      Kind of access levels identified for roles, role groups to access the set of published definitions

Review and use the same standards in Modeling.

2        Configuration Options

Equal to the structuring approaches, you need to identify what can be the best configuration for modeling environment.

You need to analyze some of the following parameters for decision making:

1.      The way process modeling happens

2.      The frequency of changes to the process definitions

3.      The complexity levels of the process

4.      The number of process modelers involved in the process definitions on regular and temporary basis

5.      Infrastructure limitations in terms of Hardware/Software as well as capabilities of maintenance

2.1      Client Server Model

The detailed steps of establishing this setup is explained in the document Modeling Configuration_ Client Server.DOC.

In this setup

1.      Each client will have the Oracle Business Process Architect installed.

2.      A development server will have the major software of Oracle Business Process Architect, Oracle Business Process Repository + relevant components installed.

a.      Business Process Architect is not required to be installed in the server unless you want to execute some process definition and refinement at the server as well.

3.      The Production server will have Oracle BPA, Oracle Business Process Repository + relevant components and Oracle Business Process Publisher.

a.      To improve the reliability, you may have Business publisher and Oracle Database in another server that runs on 24 X 7 basis and accessible to the users as per the privileges.

4.      Modelers Access the repository components in development server as remote server from BPA of each client system. The modeler in the server system can access the repository components as in local server.

5.      The work is replicated whenever the model definitions are approved in to the Production server.

6.      The approved work in the Production Server is published in the Business Process Repository.

Hardware Configuration for Process repository servers (development and Production):

WINDOWS:

Minimum System Requirements

Processor: Intel Pentium IV 2.4 GHz

Main Memory: 512 MB RAM

Graphics Card

SVGA, screen resolution: 800 x 600; 256 colors

Recommended System Requirements

Processor: Intel Pentium IV 3.0 GHz

Main Memory: 2 GB RAM

The processor requirements depend on the number of users and the size of the database (1 GB RAM for 50 users). If you use Oracle BPA Suite Converter, you need an additional 256 MB RAM and 512 MB hard disk space for converting a database, for example.

Graphics Card

Screen resolution: 1024 x 768, at least 256 colors

Network High-speed network (100 Mbit) between database server and Oracle Business Process Repository.

Note

Oracle Business Process Repository does not support NAT (Network Address Translation) by default. However, Oracle Corporation offers customized solutions. For further information, Contact through Metalink.

Software Requirements for Business Process Repository

Operating System

Windows Server 2000 Standard Edition + Service Pack 4

Windows Server 2003 Standard Edition + Service Pack 1. This release is not approved for 64-bit Itanium processors.

JDK

If you have installed Oracle Business Process Repository, an internal JDK version is used automatically. You do not need to install this application separately. If you have already installed JDK, your Oracle BPA Suite installation is not used.

Network Communication TCP/IP

Advantages:

1.      Less prone to duplications

2.      Less prone to inconsistencies

3.      Modelers will be working only on their Process definitions and do not need to do any other technical work (XML export etc)

Disadvantages:

1.      For a simple set up with 1, 2 Process modelers working on the process definitions, this setup may result in to overheads.

2.      Whenever the server is down, the latest model definitions cannot be accessed.

2.2      Stand alone modeling

1.      BPA Suite is installed in each of the Modeler system

2.      BPA Suite is installed in the development server.

3.      BPA  Suite and Business Process Publisher are installed in the production Server

4.      Both the clients and server installations of BPA Suite have the similar folder structure for models and objects.

5.      In the server, each modeler user will have write access to the relevant folder

6.      Whenever the modeler completes the work he exports the components in the form of XML File and send to the administrator.

7.      The Administrator logs in to the BPA database in the development server with the specific login of modeler which has appropriate privileges only to the relevant folder.

8.      Once the model definitions in the development server are approved, the work is replicated in the production server and re-published.

The process needs disciplined approach but has minimum overheads.

2.3      Conclusions

The success of the Business Process modeling lies with the capability of Process modeling tool as well as the disciplined approach by the knowledgeable Business Process Architects.

The designing on paper for structuring the Process definitions in terms of hierarchy, level of granularity as well as the way the access privileges are to be maintained is one of the key steps for effective Process definitions and usage.

2.4      References

1.      Oracle Business Process Architect Online Help

2.      Oracle Business Process Architect Suite Installation Manual