Your message has been sent.
This article has been saved to your account.
Go to my account
This article has been emailed to your Kindle.
Send this article
The adoption of Business Process Management (BPM) is increasingly becoming one of the most popular approaches for boosting overall organizational excellence. Built on Oracle's SOA (Service Oriented Architecture) Suite infrastructure, BPM Suite 11g provides enhanced support for application integration services and business events, Web 2.0 and E2.0 style collaborations, and high scalability. It is a full-featured, enterprise-grade BPMS that has sufficient easy-to-use features to make it also suitable for small departmental quick-win projects.
This article by Heidi Buelow, Manoj Das, Manas Deb, Prasen Palvankar and Meera Srinivasan, authors of the book Getting Started with Oracle BPM Suite 11gR1 - A Hands-On Tutorial, gives an overview of strategies and planning steps helpful in starting individual BPM projects and broader BPM initiatives.
|Read more about this book|
(For more resources on Oracle, see here.)
BPM yields high business benefits in many dimensions when adopted successfully. Thus it is prudent to be familiar, right from the start, with the essential considerations that lead to a successful BPM adoption, and conversely, the absence of which is likely to lead to failure and frustration. However, before we dive into a discussion on how we should prepare for BPM projects, a couple of clarifications are in order.
First, we should point out that not all processes are business processes. A process, particularly a digital description of a process, is essentially a depiction of a sequence of activities along with applicable flow control and business logic. In digital applications such processes appear in a variety of places. Take for example a "customer information update" activity with cross-departmental scope. This may involve updating multiple back-end IT applications, and the exact update operation may differ from application to application in how much to update and in what format to communicate with the application; there may be conditions under which certain updates may or may not take place, and so on. Often, processes are used to explicitly state all the individual tasks and associated logic behind a complex activity such as this system-wide customer information update. While such a customer information update activity will be recognized as an important and essential process at a business level, its lower level details may be expressed by an information mediation process that may be of little interest to a line of business owner. Thus, the associated process is not a business process. In general, business processes will involve activities with direct relevance to the business and the process itself will typically embody all, or a significant part, of some business value-chain.
Compared to the processes that guide data exchange between applications, business processes also typically engage more roles, often played by human participants, and involve complicated decision making, some of which requires sophisticated articulation of business rules; some others require live actions by the human participants. Depending on the situation, certain tasks in a business process may have to be transferred from one participant to the other. In some cases, a business task may require joint activity of several participants, as in collaboration.
These behind-the-scenes, technical workflow processes that exchange data between applications and perform other integration flows in support of the business tasks are generally referred to as service orchestrations to distinguish them from core business processes.
The second clarification concerns the abbreviation BPM, which is commonly used to imply Business Process Modeling, or Business Process Monitoring, or even Business Performance Management. Here we are referring to the full lifecycle of business processes of which modeling and monitoring are specific parts. Business performance management has a finance focus, and of course, business processes can feed useful information to such financial calculations.
Areas of focus for successful BPM adoption
Successful BPM adoption often involves changes in organizational behavior and focus, acquisition of skills in the necessary technology and tools, and implementation of suitable working practices. These practices range from planning to implementation of business processes, working with process instances, and monitoring and management of such processes, including post-implementation process improvement activities.
These are areas of focus that are critical for BPM adoption success. Process-centric or process-driven organizations behave differently than others, in that their leaders are strongly committed to business process excellence, and their employees at all levels are better aware how the business conducts itself. Their processing of business transactions has clearer definition, better visibility, and end-to-end traceability. Such organizations make necessary investments in improving their existing processes and creating newer ones faster than their competition. Suitable change in organizational behavior, when warranted, is critical for successful BPM adoption. The implementation of such organizational changes concerns various aspects of organizational development, such as organizational culture, managerial actions and incentive compatibility, and is not strongly tied to a specific BPMS.
Mastering adequate skills in a BPMS suitable for the scope of BPM adoption is critical for efficient and successful delivery of individual projects. BPM practice, that is, the discipline and organized activities that lead to successful BPM projects, combines BPM methodology with proper use of tools and can be seen as one of the ways an organization committed to process excellence conducts itself. This article will focus on some of the practice aspects of a BPM project.
The scope of a BPM project can also vary from company to company. A BPM project may be limited to simply working on a specific process, either creating a new one or improving an existing one. We would call this a tactical project. On the other hand, a BPM project may be the starting point of a broader scoped BPM adoption that is intended to span multiple sub-organizations and is meant to include families of BPM applications. We would call this a strategic initiative. Of course, you may also be dealing with a BPM project that is one of many being executed under a bigger BPM program. Clearly, your preparation will be somewhat different depending on what type of project you are involved in.
Regardless of the scope of your BPM project, an essential step in assuring project success is to identify the Critical Success Factors (CSFs) of your project. You need to also ensure that these CSFs are relevant to the key stakeholders of the project, including those who fund the project or own or use the outcome of the project.
Once you know the scope of your BPM adoption, an immediate question is, do you have the right capabilities, both in type and level, to execute the chosen initiative successfully? Oracle's BPM methodology provides a BPM Capability Maturity Model framework to articulate your BPM capabilities. It groups nearly a hundred individual capabilities into eight capability domains: business and strategy, organization, governance, project process and service portfolios, architecture, information, infrastructure, and operations, administration, and management—the first half of this list focuses more on organizational aspects while latter half is more technology focused.
Oracle's BPM maturity model also classifies an organization on its level of expertise within each of the capabilities (and thus within each of the capability domains) in one of five maturity levels: Ad-hoc, Opportunistic, Systematic, Managed, and Optimized. The higher the level of maturity, the higher is the ability to execute; conversely, lower levels of maturity identify areas that may require improvement. Target maturity levels for each of the capability domains depend on the scope and goals of a BPM initiative, and any gap between the required and available maturity levels for any of the capabilities, if not remedied, can be a potential source of risk adversely affecting successful execution of the BPM initiative. The following diagram shows capability types and maturity levels per Oracle's BPM methodology:
Starting with the right business process
Something that begins in the right way has a better chance of ending well. This is no different in the case of BPM projects. So, what process would you pick as the focus of your BPM project? In other words, what are the important process selection criteria?
Processes can be characterized by the amount of complexity they exhibit in terms of their suitability for explicit representation (as this is needed for digital modeling), number of activities, amount of logic, diversity of process stakeholders, number and spread of the back end application they connect to, and the type and number of human user interfaces the process needs to support. Process complexity can also be interpreted as a cost and/or risk measure. Processes can also be classified on the basis of the business impact they are likely to make—this is a benefit measure. Thus, processes that have low cost or complexity and a high business impact or benefit are easy picks for starting BPM projects and should be assigned the highest priority. Conversely, processes with high complexity and low business impact should be given the lowest priority.
Other possible combinations of process cost and benefit would have intermediate priorities. Of course, this cost-benefit analysis is useful when you have the possibility of choosing one or few processes from a larger set of possible candidate processes. In some cases certain organizational mandates may require you to consider a process which has been prioritized according to more diverse cost-benefit rankings, for example, a process that may be needed for ensuring certain legal compliance.
Once a process is chosen for a BPM project, it is advisable for the program or project managers to assess BPM capability maturity of the teams involved in the project in the context of the requirements of that project. Should significant gaps be found between the as-is and the required capabilities, strategies for timely bridging of such gaps should be included as part of the project plan.
eBook Price: $35.99
Book Price: $59.99
|Read more about this book|
(For more resources on Oracle, see here.)
Creating a process-based application
So me of the key goals of BPM initiative are to capture streams of business activities and associated logic and to create digital a rendition of these activities and logic, that is, the process model and to execute this model as a computer application. As with most computer applications, the lifecycle stages of a business process involves discovery, analysis, design, solution development and deployment, and operational management of deployed solution. Of course there can be iteration between and across these stages. Occasionally, the entire process, or some select process steps, may be subject to evaluation for the purpose of future improvement.
The goal of the first two stages—process discovery and analysis—is to get a deep understanding of the process itself and its interactions with its ecosystem. This includes individual activities and their flow; cost of executing these activities, business logic, and rules that govern the flow of these activities; data that the process uses or generates; process exceptions, in particular the manual ones that have to be handled; and the various roles, whether they are computer applications or human process operators, that are engaged in advancing the process flow. In addition, process discovery captures how the process impacts the business, relevant process analytics and the Key Performance Indicators (KPIs), and anticipated future change requirements to the process. Typically, as-is and to-be analyses are done to depict existing and desired versions of the process. The execution of process discovery could be done as a top-down or a bottom-up activity or as a combination of the two (as long as sufficient strategic analysis and selection have been done already). In the top-down approach, you will start with the higher level business problem and make your way down to finer details; in bottom-up approach, you will start with finding out finer grain tasks that actually happen in the context of a business process and roll them up to match the high-level business problem. Regardless of how you gather the information, all the stakeholders need to participate in validating the collected information from their points-of-view.
The end result of the discovery and analysis stages is a process definition. As business processes are connected to enterprise value chains, often the high-level definitions are not suitable for computer implementation. Process decomposition is a technique to break-down high level process definitions into finer grain (sub) processes. The decomposition is repeated several times, for example, starting from business function, to process groups, to core business processes, to business activities, to a task, and finally to a step. Typically, business tasks or steps are the ones that are actually implemented, and their actions are rolled up to realize the high-level business processes that reflect business value chains. Functional decomposition is a popular technique to conduct such an exercise. In many industry verticals, standardized process definitions are often leveraged; for example, SCOR for supply chain or eTOM for telecom systems.
Once a process has been defined from its business functionality point of view, technical analysis can follow. The focus of a technical analysis is to identify IT-related aspects of the process. Examples include the systems it needs to connect to, data it needs to access, business events the process needs to respond to or the business events it needs to generate, software and hardware servers needed to execute the process, and a variety of considerations related to manageability, scalability, reliability, and security aspects of the solution.
Analysis leads to the design phase where the process is described in a manner that it can be encoded in a BPMS, ultimately leading to the creation of a process-based application.
Roles in BPM projects
A typical BPM initiative touches many systems and a variety of people in an organization. Roles are used to articulate and manage participation of systems and people at different stages of the lifecycle of a BPM project. BPMN modeling notation also uses the roles concept for the purpose of categorizing participants involved in a business process application. Here we will mainly discuss the roles of people participating in the delivery of a BPM project. While there are no industry-wide standards for BPM roles yet, the following list is representative of popular practice:
- Process sponsor: Process sponsor, typically a business person, is the initiator of the project and provides the senior management connection to the project. Often the sponsor also provides the funding for the project.
- Process owner: This is the role that leads and maintains the overall context of the BPM project. A process owner is familiar with, and influences the high-level characteristics of, the project and the process, goals and KPIs, process variabilities, and future change requirements. He also has an oversight of the key milestones and deliverables. A "process context map" that summarizes all the important aspects of the process is often a useful tool used by this role.
- Program/project manager: Oft en, several related projects are grouped under a program, and hence the role of a program manager may be useful in addition to that of the project manager. The project management role is primarily responsible for creating the Work Breakdown Structure (WBS) for the project, managing schedule, resource and deliverables, and coordination among other roles engaged in the project. The program/project manager is also attentive to capability maturity of the project participants and risks involved in the project. The program/project manager uses executive reporting to keep process sponsor and process owner up-to-date on the project status.
- Enterprise architect/business analyst: Depending on the organization and the project scope, these may be separate roles. The focus here is to capture relevant business architecture, value chains, and strategy maps, and align the target process with them. The business analyst specifies all the business level requirements for the process for the as-is and to-be states. These roles own the use-case level documentation of the processes and also define the process KPIs.
- Business user: This role, sometimes included with in the business analyst role, is a key contributor to the business process discovery activities, and is tasked with continual review of the process model and making changes to business processes that are (relatively) small and not highly technical. In some cases, expert end users (that is, those who work with BPM applications to execute process based transactions) can play this role. One key benefit is to have the business users directly implement such process modifications without initiating new or additional IT involvement.
- Process analyst/architect: This role pertains more to the actual implementation of the process. He may conduct process simulation and suggest incremental refinements. He also contributes to the definitions of the exceptions, and of business indicators and KPIs, and formulates mechanisms to collect necessary input and to compute such metrics. He also provides the necessary technical details required to create the actual process model. In the event that the analyst and architect roles are handled by different individuals, the analyst focuses mainly on the business aspects.
- Process designer/developer: This role is responsible for producing the digital rendition of the process model, encoding business rules, designing the user interfaces, and creating the executable version of the process. Depending on the BPMS and the division of labor in an organization, an additional and more technical role called the IT Developer may supplement this role and perform the tasks of creating and connecting process end-points, some of which can be software services (as in SOA).
Besides the above roles, some of the traditional functions that exist in most IT endeavors, for example, system administration, governance, and release management, are also equally relevant to BPM projects. It should be pointed out here that while roles in the above list are sufficiently distinct, depending on the size and scope of the project, a particular person may handle multiple roles, that is, wear multiple hats, so to say.
Different tools or tool components are better suited for the different BPM roles. As an example, business analyst/enterprise architects can make use of the Oracle BPA (Business Process Analysis) product for their activities—these activities correspond closely with BPMN's descriptive level of modeling. The fully web-based and light-weight Process Composer is better suited for the business user role. The full-featured development environment provided by BPM Studio would be the main work-horse of the process (and IT) developers handling activities that are closely aligned with BPMN's execution level modeling. The analysts may use either Process Composer or the BPM Studio depending on their needs—the analysis activities are aligned with the analytical level of BPMN modeling.
In this article, we briefly discussed how to prepare before you actually get deep into working with a BPMS tool set such as Oracle BPM Suite 11g. We also touched on the various roles that are involved in a BPM project and the types of tool support that are appropriate for some of the key roles.
- Oracle Coherence 3.5 [book]
- EJB 3.0 Database Persistence with Oracle Fusion Middleware 11g [book]
- The Business Analyst's Guide to Oracle Hyperion Interactive Reporting 11 [book]
- Using Oracle Service Bus Console [article]
- BPMN 2.0 Concepts and The Sales Quote Process [article]
- Oracle BPM Suite 11gR1: Creating a BPM Application [article]
- Introduction to Oracle Service Bus & Oracle Service Registry [article]
eBook Price: $35.99
Book Price: $59.99
About the Author :
Heidi Buelow is a BPM Product Manager with Oracle and is responsible for Oracle BPM Suite and programs such as beta and technical previews. Heidi joined Oracle in 2006, and previously was Chief Application Architect developing a Business Process Management engine, developer toolset, and application framework. Heidi started her career as a software developer at Xerox working on the Xerox Network Services and Star Workstation products where she first learned to appreciate object-oriented and services-oriented technologies. She holds a Bachelor of Science degree in Computer Science from the University of Southern California.
Manas Deb is a senior director in the Fusion Middleware/SOA, BPM, Governance Suites Product Group at Oracle HQ. He currently leads outbound product management and many strategic engagements initiatives for Oracle's SOA, BPM, and Governance solutions, worldwide. He is also responsible for Oracle/HQ-based SOA Methodology initiatives. He has worked in the software industry for over twenty years, most of which was spent in software product management/marketing and on architecting and leading a wide variety of enterprise-level application development and business integrations projects in a wide variety of industries. A graduate of The Indian Institute of Technology (KGP), Manas attended post-graduate studies at University of Texas at Austin. He received his PhD in an inter-disciplinary program comprising Computer Science, Applied Mathematics, and Engineering. Manas also has an MBA with specialization in international business.
Manoj is Director of Product Management at Oracle, responsible for Oracle's BPM Suite of products. Manoj's BPM journey started at Siebel Systems, where he was responsible for the next generation process-centric and insight-driven application platform. He plays a leadership role setting BPM and SOA industry standards, especially in BPMN 2.0, BPEL, and Business Rules. He is widely recognized at industry conference and in Information Technology publications. Manoj has a BS in Computer Science from IIT Kanpur and an MBA from UC Berkeley. He has held senior Product Management, Development Management, and Product Development positions at Oracle, Siebel, Mentor Graphics, and elsewhere.
Meera Srinivasan is a BPM Product Manager with Oracle and is responsible for Oracle BPM Suite and Oracle BPA Suite. She has 15 years of extensive experience in integration, SOA, BPM, and EA technologies and represents Oracle at OMG, OASIS and other industry consortia. Meera joined Oracle in 2003, and was part of the SOA Product Management team managing Adapters. Prior to joining Oracle, she spent seven years with TIBCO Software, a pioneer in electronic trading, message-oriented middleware, and enterprise integration. At TIBCO, she was an Engineering Manager involved in managing the development of various Adapters and EAI technologies. She holds a Master of Science degree in Computer Science from the University of Florida at Gainesville.
Prasen Palvankar is a Director of Product Management at Oracle and is responsible for outbound SOA Suite and BPM Suite product-related activities such as providing strategic and architectural support to Oracle's SOA Suite and BPM Suite current and prospective customers and also includes field and partner enablement, and training. Prasen joined Oracle in 1998 and worked as a Technical Director in the Advanced Technology Solutions group in Oracle Consulting delivering large-scale integration projects before taking on his current role five years ago. Prior to joining Oracle, he worked as a Principal Software Engineer at Digital Equipment Corporation.