1. Introduction: Business Process Management deals with defining, analyzing, managing and implementing the interaction among internal systems, people and external trading partners. BPM provides a holistic approach to Software development involving technology (objective) and human behavior (subjective). In traditional systems, Business Logic (objective part) and Business Rules (subjective part) in a Business Process are tightly coupled. Hence, any requirement change in either one results redesign or re-factoring (depends on the extent of the change) of business process. However, laws, rules and regulations of certain business processes change constantly. This necessitates the decoupling or loose coupling of Business Rules and Business Logic. Business Logic is hard coded (means, business logic change depends only on requirement change). On the other hand, transient changes in rules, laws and regulations are encapsulated in Business Rules. These Business Rules may or may not need human intervention. Business Logic is implemented in Application server (for example, an EJB or IoC container). Business Rules, which need human intervention is implemented in Workflow server. Business Rules, which do not need human intervention is implemented in Rules Engine.
2. Components of BPM: The major components of BPM are described below.
a) Business Logic: Defines the objective behavior of permanent nature. In software terms, this attribute never changes unless and until requirement changes. This also implies that there is nothing absolutely permanent in software development. The core business model of the enterprise is captured in the business logic.
b) Business Rules: Defines the objective behavior of transient nature. However, this attribute changes within the confines of the requirements. This encapsulates the forces outside the enterprise which influence the core business model such as market forces and government policies. The daily or weekly promotion sale of the company or changing the sales tax structure due to government policies are few such examples.
c) Work flow: Defines the subjective behavior of transient nature. This is where the human aspect interacts with the core business model. For example, a customer agent partially forgives the overdue penalty of a customer and her supervisor completely forgives it due to good payment record of the customer.
d) Trading Partner Interaction (B2B integration): Defines the business relationship with other enterprises. In the current integrated business environment, business to business transaction is inevitable one way or the other.
e) Enterprise Application Integration (EAI): Defines the integration of various software and data assets within the enterprise. It can be legacy assets accrued over the years such as main frame or software written in C language.
f) Life cycle management: Almost every business model has to perform a sequence of tasks from inception to fulfillment, to complete the business process. It can be a claim processing, an order fulfillment of a shopping cart or a loan processing etc. BPM provides the state management of individual steps involved in the Business
Process. Figure 1: Components of BPM
g) Monitoring: The entire software development project is business requirement driven. The business requirement is stake holder driven. Hence, directly or indirectly the business manager is the ultimate stake holder of the software development. However, the business manager may not have the technical acumen to understand the complexities of the software process. She has to believe what she is told by the development team. This poses considerable challenge to the Business Manager on day to day operations of Business Process. The monitoring tools of BPM provide such a visibility to the business process. Monitoring may include but not limited to Business Activity Monitoring (BAM) of Key Performance Indicators(KPI), Six-Sigma, compliance monitoring (like SOX), process analytics etc.
3) Necessity of BPM: A typical example in pharmacuitical industry is the life cycle of a medicine development . Rules and laws continuously change as new legislation and new discoveries come into effect every year. However, it is extremely difficult to change or re-factor the existing applications which process the orders as per every change in the market conditions and FDA laws. The best strategy is to separate business logic and business rules from the business process. The subjective and transient supply management features are encapsulated in business rules. The objective and permanent supply logic is encapsulated in the business logic. The Business logic may reside in various disparate systems which need to be integrated (EAI) using adapters or interfaces. Whenever the FDA regulation changes, the business manager creates a business rule associated with the new law and stores it in a rules engine. When the system receives an order, the application server applies business logic and rules engine applies business rules on the data. The data is sent through a Workflow if it needs to go through human intervention such as evaluating various steps in the drug development. In most of the cases external trading partners (B2B integration) are to be involved such as FDA and patent agencies. In many cases, data and software assets reside in legacy systems and other disparate systems which need to be integrated. For example, medicine history is processed in C based systems while patent management is processed in COBOL systems. Above all, an oversight by the Business stake holder or upper management (using BAM) is essential for the proper management of the life cycle of the medicine development. To integrate such a complex and disparate business process, a BPM system is absolutely necessary.
Figure 2: BPM Project life cycle in modified waterfall methodology
4) Architecture of BPM: A BPM system must be able to integrate with Application server environments, Workflow servers, Rules engines, B2B trading partners, Legacy systems and Enterprise application Integration systems. The BPM system must provide a design environment to capture and model the business process and create compile time stubs. The BPM application must have a process engine to monitor the run time processing and KPIs. A high level, logical, design time and run time architectural topologies are shown below.
Figure 6: BPM Run Time Architecture in Amazon Cloud
5) Design and Building a BPM application: The following steps describe salient features of a BPM application from design to production release.
a) Capturing and Modeling Business Processes: The first step is to capture the logical business process with the help of a business stake holder (or business analyst). Coarse grained processes may be sub-processed to capture underlying fine grained processes. The business analyst may iterate through the processes to refine the business process model. Steps are used to capture the business process and transitions are used to direct the flow among the business process. Such a logical Business process model is shown below.
Using a Modeler or Designer, create a physical business process model out of the logical one. Create stub to develop code to represent the underlying process. Such a physical model is shown below.
Figure 8: Physical Business Process Model
b) Creating and mapping Logical Data Dictionary (LDD). The LDD is a master reference table containing each and every attribute used in the business process. The meta data pertaining to each attribute is described in the table such as data type, data size, default value, list of values if enumerated, definition of attribute, container hierarchy (xPath) and type of attribute. The relative location of the attribute depends on the structure of the format where the attribute is located as shown in the figure below.
Figure 9: Data transformation and mapping in data formats.
The naming convention and associated meta data information are captured under each domain specific formats. For example, three attributes - order number, social security number and credit card type as it passes through different domain formats are shown below.
Figure 10: Logical Data Dictionary
The LDD is used as a reference document by analysts, architects, designers, developers, managers and testers for their respective needs. If LDD becomes too big to manage, it can be split into domain specific categories. The initial investment in the form of effort and time to build a Logical Data Dictionary is considerable. However, it is worth every penny as it prevents potential problems during the subsequent application development.
c) Creating the Canonical data structure. A canonical document, usually in XML format has to be derived based on the attributes collected in LDD. Thus, the LDD contains every attribute and its structure based on xPath. Different types of strategies can be used to arrive at the canonical XML. The canonical XML can be a subset of industry standard (such as SPL (Structured Product Labeling) , HL7, eCTD (electronic Common Techinical Document, HIPAA), a combination of SPL, HL7, eCTD, HIPAA and trading partner proprietary XML, derived from Business Objects or entirely a new XML structure as shown below.
d) Identifying and creating Unique Id. Every instance in the Business Process is identified by a unique id, similar to RFID (Radio Frequency IDentification). This id enables to maintain the life cycle of the instance even if it leaves the business process engine. For medicines, it can be National Drug code(NDC).
f) Monitoring the Business Processes. Once deployed into production, each instance can be monitored using a monitor or BAM enabled portal interface as shown below.
6) Big Data analysis in BPM:As BPM claim process gather large amount of data, those data can be used for big data analysis. These data can reside in various sources in various format such as Object data in S3, NoSQL data in DynamoDB, Relational data in RDS, Warehouse data in RedShift, Archived data in Glacier and Streamed data in Kinesis. These data can be used, for example for predictive analysis. To test the billing claim variables against the time series (ARIMA - AutoRegressive Integrated Moving Average) model or against random walk (MCMC - Markov Chain Monte Carlo) using Python as shown below
Figure 17. Big Data analysis using EMR (Elastic Map Reduce) Cluster.
•EC2 instances are created in a VPC(Virtual Private Cloud) in the respective Availability Zone.
•A master node and slaves nodes are created in each EC2 instance.
•Hadoop, Spark and Python code to run ARIMA mode is installed in the Master node. Hadoop and Spark are managed by YARN in the master node. Fail over is managed by AutoScaling group in the cluster.
•Input data is read from any of the data sources and processed by the Python code. The results are written to one of the data storage for further analysis.
5) Conclusion: Most of the ills associated with the current application development are the inability of the business stake holder to have proper oversight. Most of the software development environment does not provide any such tools. The important benefits of BPM are,
a) SAVING MONEY: By completely automating all the business processes, virtually eliminates the unnecessary overheads in the loan processing and saves millions over the years.
b) LESS HUMAN ERROR: By automation, business processes have less human intervention and thus human error is minimized.
c) INCREASED PRODUCTIVITY: Faster loan processing enables better throughput (loans processed per unit time).
d) SUPERIOR OVERSIGHT: Upper management or business stakeholder gets a birds eye view of the entire loan process. In other words, management knows what is exactly going on rather than being told.
e) MONITORING AND OPTIMIZATION: In-depth monitoring of data at every step of the business process.
f) SUPERIOR ERROR HANDLING: Easy resubmission of process at a failed step.
g) ROI: Investing in BPM implementation gives the best return in the long run.
h) USER FRIENDLY: These models are extremely user friendly and provide a visual representation of the business processes which can easily be understood even by non-technical or uninitiated.
i) Fast Development and Implementation: Very fast and easy development life cycle and process refinement.
______________________________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this document is to be used or reproduced without the written consent from the author (roychettan@gmail.com).
No comments:
Post a Comment