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
