 | Level: Introductory Cecile Peraire, Method Architect, Global Business Services,
IBM
15 Jul 2008 
from The Rational Edge: Read how IBM Rational Method Composer is being used to document global and local IBM Global Business Services customer relationship management (CRM) business processes within IBM. The Rational Method Composer solution is based on a unified framework for documenting CRM business processes, called the Unified CRM Business Process Framework
From The Rational Edge.
For many years, IBM® has been among the world's largest business and technology services providers, helping companies around the globe manage their IT operations and resources to ensure that their investments contribute to profitable growth. Based on that experience, IBM Global Business Services
1
(GBS) -- the consulting arm of IBM -- has formally defined an end-to-end business process governing any GBS engagement: the GBS Customer Relationship Management (CRM) Business Process.
The GBS CRM Business Process guides practitioners who perform day-to-day activities throughout the client engagement lifecycle, from the identification of an opportunity, to the definition of a proposal, all the way to the delivery of the solution. All GBS engagements must follow the CRM Business Process in order to reasonably ensure that engagements are handled consistently across GBS world-wide, in a seamless and efficient manner, while complying with a minimal but sufficient set of business and legal controls. The process includes controls to support and protect IBM, its customers, and its shareholders. Controls ensure compliance with all corporate and local laws and obligations, including the U.S. Sarbanes-Oxley Act and export regulations.
Because IBM is a global company serving clients in hundreds of countries, documenting the GBS CRM Business Process is a challenging task. We must capture not only the global business process to be followed world-wide, but also the local adjustments specific to each region or country. This implies the creation and maintenance of a number of process variants, which could potentially lead to content redundancy, inconsistency, high maintenance cost, or poor usability.
The global process is called "Global CRM Process," while local processes are documented in "playbooks." Playbooks include both global and local content. Since their primary goal is to guide practitioners effectively during engagements and reduce audit failure, the Global CRM Process and playbooks must be entirely traceable and consistent. Playbooks must always include the latest version of the global content. Traceability between global and local content must be clear, to ensure the local content is aligned with the global version, and to fully understand the impact of changes. Quality and consumability must be high, with a consistent user experience across process variants. In addition, the various processes must be created and maintained by globally distributed teams, and the maintenance cost must be minimized.
This article reports on an initiative to overcome the challenge of documenting the global and local GBS CRM business processes by using IBM Rational® Method Composer (RMC). The proposed RMC solution is based on the definition of a unified framework for documenting CRM business processes, called the Unified CRM Business Process Framework.
The Unified CRM Business Process Framework provides:
-
A standard definition of the Global CRM Process (global content)
-
A skeleton/template for defining local adjustments (local content), with traceability to global content
-
The ability to define global and local content in distributed environments
-
The ability to build a playbook by reusing content from the standard Global CRM Process and merging global and local content as necessary
Processes built under the Unified CRM Business Process Framework are published as IBM internal Websites sharing the same structure and appearance to provide a consistent user experience across regions and countries.
This article is targeted toward process engineers (also called method engineers, method architects, or method designers) who need guidance on architecture and development using RMC and are looking for a reference architecture in order to organize their process models. The article assumes some elementary knowledge of RMC.
2
The first section of the article introduces the global and local GBS CRM business processes and illustrates how the solution presented in the article is being used and provides value. The second section presents the component-based architecture of the Unified CRM Business Process Framework, allowing for a distributed development of the global and local content. The third section introduces a couple of RMC mechanisms -- variability and configuration -- enabling content reuse and merge. The fourth section shows how RMC relationships are leveraged for usability purposes. These sections include examples derived from real-life artifacts that have been simplified for clarity purposes. Finally, the article ends with a word of caution for modeling gurus.
Global and local GBS CRM business processes
Before introducing the Unified CRM Business Process Framework and drilling down into the details of the RMC solution, this section introduces the global and local GBS CRM business processes along with a few scenarios illustrating how the solution is being used and provides value.
The intent of this initiative is to establish a central portal on the internal IBM intranet for the GBS CRM business processes, including global process and local playbooks. The portal provides practitioners with the ability to access all process Websites, as illustrated in Figure 1. All intranet Websites are consistent across the globe in terms of structure, content, and look-and-feel, therefore providing a unified user experience.
Figure 1: Consistent process Websites across the globe
The Global CRM Process captures the business process applicable worldwide and serves as the foundation for the local playbooks. Therefore, the Global CRM Process Website is accessed mostly by process owners and subject matter experts from both global and local CRM teams, as a reference and base for reflection and discussions around process improvement and deployment. In addition, the Global CRM Process Website can be leveraged for training purposes, as it represents a "light" version of the process free of locale-specific content, and is therefore suitable for beginners.
During engagements, however, practitioners go directly to their local playbook to quickly access the information they need in order to perform a given activity or task in the engagement cycle. Playbooks provide them with process guidance, business rules, and legal controls, which are either global or specific to their region or country. Practitioners have the flexibility to navigate their playbook Website directly from the IBM intranet, or to download a copy of the Website in order to have a local replica on their machine when working offline.
As an example, consider a consultant from IBM GBS New Zealand, sent to Spain on an assignment at a critical client site. This consultant may want to download the Spanish Playbook Website on her laptop from her home office before leaving for the airport, and surf the site during her flight to Madrid. Since the Spanish Playbook is similar to the Australia/New Zealand (ANZ) Playbook, she has no problem navigating the Website. While at the client site, the consultant accesses the Spanish Playbook as necessary to obtain specific process guidance and make sure her work complies with both global and Spanish business rules and regulations. For instance, at the end of the engagement, she can obtain some guidance on how to archive essential project records by looking at the "Archive Project Records" task. As illustrated in Figure 2, she can perform a side-by-side comparison between the Spanish and ANZ versions of the task. The comparison helps her quickly understand how archiving is done differently in Spain compared to New Zealand. In this case, archiving is a fully automated process in Spain, while in New Zealand some steps remain to be performed manually (detailed guidance on how to perform the ANZ steps is available by expanding the steps).
Figure 2: Side-by-side comparison between Spanish and ANZ playbooks
The following sections demonstrate how to leverage the power of RMC in order to generate process Websites that are consistent across the globe in terms of structure, content, and look-and-feel, therefore providing a unified user experience. The proposed RMC solution is based on a layered architecture and a set of RMC mechanisms allowing for distributed development and for minimizing redundancy, inconsistency, and maintenance cost.
Component-based architecture
This section presents the component-based architecture of the Unified CRM Business Process Framework, allowing for parallel and geographically distributed development, as well as distribution of ownership.
The CRM processes (global process and playbooks) need to be authored and maintained in parallel by teams distributed across different regions of the world. Furthermore, the authoring and maintenance of each individual process itself may be performed by a distributed team. This level of parallelism and distribution is primarily achieved through a component-based architecture, together with the use of a configuration management tool (in our case, IBM Rational ClearCase®
3
). However, since clear ownership is a critical ingredient of project success, reliance on a tool for parallel development should be minimized through an architecture that enables an easy distribution of component ownership.
The architecture of the Unified CRM Business Process Framework is illustrated by the Unified Modeling Language
4
(UML) package diagram in Figure 3, created using IBM Rational Software Modeler
5
(RSM). This is a layered architecture organized as follows:
- The Global Layer contains the Global CRM Process.
- The Regional Layer contains the content specific to the regional playbooks, a region being a set of countries organized into an integrated operating team.
- The Country Layer contains the content specific to the country playbooks.
- Dependencies among layers go from Country to Regional to Global, since each playbook is formed by leveraging content from lower levels as necessary. For instance, the Country C3 Playbook is formed by leveraging content from the Global CRM Process while contributing its own content, including business rules, templates, and tool usage requirements.
Figure 3: Architecture overview of the Unified CRM Business Process Framework
Each process in Figure 3 is defined using the CRM process pattern illustrated by the UML class diagram in Figure 4, created using RSM. The pattern provides a skeleton enabling process engineers to quickly develop processes that have a consistent structure across the globe and are able to share content, which reduces the cost of creation and maintenance.
The pattern defines a CRM process as an end-to-end delivery process composed of three independent practices -- Opportunity Management, Solution Design, and Solution Delivery -- supported by a number of roles, work products, and guidance (like templates, tool mentors, or checklists). Practices, roles, work products, and guidance can be categorized as necessary.
Figure 4: CRM process pattern
In RMC, all content is organized using method plug-ins. Plug-ins are the key components of the architecture. The CRM process pattern in Figure 4 defines a process in terms of the following plug-ins and their dependencies:
- The delivery_process plug-in includes the CRM delivery process, which is an end-to-end complete engagement lifecycle. The delivery process is built out of practices.
- The om_practice plug-in includes the Opportunity Management practice. It includes the activities, tasks, and guidance related to opportunity management. Similarly, the sol_design_practice and sol_delivery_practice plug-ins includes the Solution Design and Solution Delivery practices.
- The roles plug-in includes the roles and related guidance.
- The work products plug-in includes the work products and related guidance.
- The guidance plug-in includes the guidance (like templates, tool mentors, or checklists) common to several plug-ins.
- The categories plug-in includes the categories of the process. Refer to the "Usability and RMC relationships" section below for more information on categories.
- The config_support plug-in defines the elements, such as views and welcome page, that support a configuration. Refer to the "Content reuse and merge using variability and configuration" section below for more information on configuration.
Figure 5 shows how the plug-ins forming the Global CRM Process are displayed in RMC. Dependencies among plug-ins are defined in accordance with the CRM process pattern, as illustrated for the config_support plug-in, which depends on all the other plug-ins in the pattern.
Figure 5: RMC plug-ins forming the Global CRM Process
Finally, a plug-in of a given layer (see Figure 3) depends on its corresponding plug-in at the layer below. For instance, the om_practice plug-in in Adjustments Country C3 depends on the om_practice plug-in in the Global CRM Process.
This decomposition into plug-ins
6
and their dependencies organize the architecture into highly cohesive and loosely coupled components, allowing for parallel and geographically distributed development, as well as distribution of ownership. It also facilitates comprehension and increases flexibility and opportunities for reuse. The architecture is resilient: as changes are needed, it evolves easily. Business processes are expected to need corrections and additions over time to remain compliant with ever-changing laws and regulations.
Content reuse and merge using variability and configuration
Playbooks are localized versions of the Global CRM Process. They include selected content from the Global CRM Process, while introducing additions and deviations. For instance, a playbook may have to add guidance related to the CRM tool used in a region or country, and replace a number of global business rules and process control points with local ones.
In order to minimize maintenance and inconsistencies, content redundancy between the Global CRM Process and playbooks (and among playbooks) must be minimized. For instance, a playbook should not be created by copying and modifying the content of the Global CRM Process. This would require playbook maintenance each time a change is made to the global process. Also, providing the users with the Global CRM Process and a separate list of local additions and deviations does not satisfy usability requirements.
This section describes how the Unified CRM Business Process Framework overcomes this challenge using a couple of RMC mechanisms that enable content reuse and merge: variability and configuration.
RMC variability
RMC variability is an authoring mechanism for defining a new element by referencing an existing one and specifying the differences between them. Variability allows you to create new elements based on existing ones without directly modifying their original content. In our case, authors may reuse and customize existing global elements in the context of a new playbook, without directly modifying the original content of the global element.
Among the different types of RMC variability relationships,
7
the CRM processes leverage "Contributes" and "Replaces." This article focuses mostly on the "Contributes" capability, as this relationship is used extensively. ("Replaces" allows you to replace an existing element with a completely new variant and is needed only in a few instances. In playbooks, it is used to replace elements of the Global CRM Process, like business rules not applicable at the regional or country level, with appropriate ones.)
The "Contributes" variability relationship allows you to define a new element by reusing an existing one and contributing new content to it. In creating a playbook, this means reusing an existing global task, customizing the task by contributing local information (e.g., how to perform the task using a local tool), and publishing the playbook with the customized task. Figures 6 and 7 below illustrate this example.
Figure 6: The "Archive Project Records" task in the Global CRM Process
Figure 7: Country C3 adjustments made to the "Archive Project Records" task
Figure 6 shows the global content (simplified version) for the "Archive Project Records" task, as it appears in the Global CRM Process. Figure 7 shows the local adjustments made to the "Archive Project Records" task by Country C3, contributing information related to the "C3 Records Management" tool in use in the country. Figure 7 also shows how the "Contributes" relationship is established between the Country C3 adjustments and global task. Note that the content presented in Figure 7 is the only content that Country C3 creates and maintains in relation with the "Archive Project Records" task; the global content is created and maintained by the global team.
Figure 9 in the following section shows the new "Archive Project Records" task as it appears in the Country C3 playbook. The new task results from the merge of the global content in Figure 6 and country content in Figure 7. However, the actual content merge can be performed only after the appropriate RMC configuration has been defined, as described below.
RMC configuration
An RMC configuration allows definition of the content of the published Website, by selecting among all available content the appropriate subset that needs to be included for publication. Going back to our example above, a configuration allows us to define how to compose a CRM process (Global CRM Process or playbook) based on the content included in a selection of RMC plug-ins and packages, as illustrated in Figure 8. For instance, let's assume that three countries (C1, C2, and C3) are contributing content to the same global task, "Archive Project Records." This creates three new variants of the "Archive Project Records" task. A configuration allows selecting the variant appropriate for a given country playbook.
Figure 8: Country C3 playbook configuration (defined in RMC configuration editor)
Figure 8 shows the configuration for the Country C3 playbook. The configuration is built by selecting -- among all the RMC packages and plug-ins defining the architecture of the Unified CRM Business Process Framework as illustrated in Figures 3 and 4 -- the packages and plug-ins, including content, that need to be incorporated into the playbook. Specifically, the playbook is composed by selecting the global content under "Global_CRM_Process," together with the country content under "Adjustments_Country_C3." Within this well-defined context, the "Contributes" relationship merges the content of the global "Archive Project Records" task (Figure 6) with the Country C3 adjustments (Figure 7), creating a new task specific to the Country C3 playbook, as shown in Figure 9.
Figure 9: The "Archive Project Records" task in the Country C3 Playbook
Finally, with only a few mouse clicks in the configuration editor, another playbook can be published. For instance, the Country C1 playbook is published by selecting "Adjustments_Country_C1" instead of "Adjustments_Country_C3" in Figure 8. This generates a new variant for the "Archive Project Records" task, as illustrated in Figure 10. This new variant includes a series of steps. By expanding the steps the practitioner accesses detailed guidance on how to perform these steps within Country C1.
Figure 10: The "Archive Project Records" task in the Country C1 Playbook
Taken together, the RMC variability authoring mechanism and RMC configuration publishing mechanism form a powerful tool for content reuse and merge, allowing authors to create new local elements by customizing existing global elements, without directly modifying the original content of these elements.
Usability and RMC relationships
Because usability is a prerequisite for method or process adoption, creating an architecture with RMC requires you to focus on the usability of the RMC-generated Websites. This section introduces RMC relationships that have proven to be an effective usability asset greatly appreciated by the users, and illustrates how RMC relationships are being leveraged to improve the usability of the CRM Websites.
Compared to most Web design and development tools, RMC provides a powerful solution for authoring methods or processes. This is because RMC structures content according to a formal underlying schema: the IBM Unified Method Architecture (UMA). This schema allows authors to define meaningful relationships among elements easily, creating a rich network of related content with well-defined semantics. These relationships are stored and maintained by RMC, and automatically presented to the practitioner in the published Website, allowing for quick access to information and hence remarkable usability. For instance, the "Relationships" section in Figure 11 presents the relationships for the "Opportunity Noticer (ON)" role. It shows that the role performs a couple of tasks and is responsible for three outcomes. From the role page, only one click is necessary to learn more about a related element.
Figure 11: Quick access to elements related to the "Opportunity Noticer (ON)" role
Similarly, the "Relationships" section in Figure 9 presents the relationships for the "Archive Project Records" task. They include the primary role performing the task, as well as the task input and output. In addition, the "More Information" section shows that a relationship has been created between the task and a guideline, and between the task and a tool mentor. As a result, the tool mentor page, for instance, automatically includes the "Archive Project Records" task among the list of elements recommending the use of this tool mentor, as shown in Figure 12.
Figure 12: Quick access to elements related to the tool mentor
In addition, relationships can be created using RMC categories. Categories allow you to organize content into logical collections. They provide a means to group content easily using predefined standard categories in line with best practices for creating structured methods (like grouping related roles using role sets), or using custom categories in line with any user-defined scheme.
In the CRM Websites, categories are used, among other things, to provide practitioners with fast access to roles, tasks, work products, and control points. Figures 13 and 14 respectively show how opportunity management roles are organized into a role set for quick access to this type of role, and how control points are grouped into three categories for quick access to critical control information.
Figure 13: Quick access to opportunity management roles
Figure 14: Quick access to control points
Last but not least, RMC categories are also used to create navigation views. Navigation views are another powerful mechanism that enables practitioners to access the information they need quickly. Figure 15 shows an example of a navigation view for the Global CRM Process, providing fast access to key CRM content.
Figure 15: Navigation view for the Global CRM Process
When it comes to usability, users know best. Therefore, it is critical to encourage continuous feedback from users (and from other key stakeholders), especially on the creation of the categories that play a key role in structuring RMC-generated Websites. The user feedback on the CRM Websites has been tremendously positive. However, because of the subjective dimension of usability, the CRM development team sometimes gets unexpected reactions and has to deal with stakeholders questioning the usability of a playbook. So far the team has been able to accommodate most requests for improvement, thanks to the flexibility of RMC. For instance, the Website look-and-feel as well as the structure of the different types of page can be entirely customized through the use of RMC skins.
8
This capability can be a project-saver when the unhappy stakeholders are quite influential!
A word of caution
In the section "Component-based architecture" above, I introduced the architecture of the Unified CRM Business Process Framework, and illustrated it using UML diagrams generated by RSM. However, even though the Rational organization strongly believes in sound and resilient architecture and the power of visual modeling, I would like to convey a word of caution about visual modeling in the context of method development projects (including process development projects).
First of all, the beauty of the architecture and the fun of creating visual models should not obscure the main objectives of a method development project. Indeed, the number one objective is a high-quality method that allows users to quickly find the information they need. The method should be made available on time, possibly together with the necessary deployment material. Another key objective is to develop a method that can be easily maintained and evolved to satisfy future requirements. Therefore, any modeling effort -- and more generally any effort -- performed during the project should serve these goals.
In order to reach these project goals, the recommended approach is to adopt an iterative and risk-driven approach to method development
9
that focuses on delivering tangible results incrementally in each iteration. This allows for ongoing stakeholder feedback and mid-course corrections. It also mitigates high risks early in the project, including validating all architecturally significant project decisions. As in any time-boxed development approach, proper expectation setting is critical in gaining support from stakeholders; they must be kept aware of the target dates so that scope and priorities can be properly managed. In the case of the CRM project, new versions of the CRM business process Websites were presented to the stakeholders on a weekly basis, allowing stakeholders to literally drive the development effort (within boundaries set by the development team) and therefore embrace and own the project outcome.
Early in the project, the recommended approach is to outline the method using a method sketch. The goal of the method sketch is to help the team identity candidate method elements and some of their relationships, and to propose an early description for some of the key elements. To do so, the method sketch may take various forms. For instance, it may include a walk-through of the lifecycle, a list of candidate method elements and their relationships, an early Work Breakdown Structure (WBS), a mockup of the method Website, a visual model, an RMC prototype, etc. The sketch is meant to encourage creative thinking and allow the team to define and review some first outlines of the method using the content, format, notation, and support that best fit their needs and skills.
In order to avoid "sketch paralysis," it is important not to spend too much time detailing the sketch upfront. Once the new method, or part of the method, starts to emerge from the sketch, it is time to launch RMC, in which the method can be more formally and completely defined. The sketch can be abandoned at this point, or kept to investigate other areas and optionally to track elements to be authored.
If the method sketch includes visual models, it may be a good idea in some circumstances to evolve these models into formal project artifacts (e.g., method architecture or method design). However, in many projects, most of the architecture and design of a method can be clearly defined and comprehended directly within RMC. Consequently, any modeling effort outside of RMC should focus on complementing RMC by illustrating critical information not obviously presented within the tool. As an example, a visual model could be created to help define the relationships between plug-ins without creating circular dependencies. In addition, a visual model adds value to the project if it can be leveraged to jumpstart a project task or a future activity such as method evolution, maintenance, knowledge transfer, or training. In the case of the CRM business process, a UML diagram was created to document the design pattern guiding the creation of any new playbook. In many other circumstances, visual models can potentially be counterproductive, as they often involve creating or maintaining redundant information and require cycles from the development team that could otherwise be spent more effectively.
Similarly, it may be desirable to include some visual diagrams as illustrations within the method under development itself. In that case, you should leverage the visual capability of RMC, which allows creating workflow diagrams, for instance. There is no reason to create these diagrams outside of RMC.
In summary, visual modeling is a powerful technique with the potential of adding tremendous value to a method development project when used with caution to avoid being counter-productive.
Conclusion
This article presents an approach for documenting a global and local GBS CRM business processes by leveraging the power of Rational Method Composer. The proposed RMC solution is based on the definition of the Unified CRM Business Process Framework. The framework provides, among other things, a standard definition of the Global CRM Process (global content), a skeleton for defining local adjustments (local content), and the ability to build local playbooks by reusing global content from the standard Global CRM Process and merging global and local content as necessary.
This approach considerably reduces the effort involved in creating new playbooks, as defining a playbook only requires specifying the deltas between global and local content. This provides small countries with limited resources reduced audit exposure by quickly defining high-quality processes.
This approach also reduces maintenance significantly, as it removes redundancy -- hence inconsistency -- between the Global CRM Process and playbooks and eliminates the need for manually updating playbook global content at each new release of the Global CRM Process: i.e., republishing the playbooks picks up the global updates automatically.
Furthermore, the solution should reduce redundancy among playbooks over time, as content common to several playbooks can easily be identified and factored out. Consequently, the amount of content associated to each playbook, and ultimately the number of playbooks, should decrease over time, reducing even further the maintenance and overhead cost.
This approach also increases playbook quality and consumability, as it minimizes inconsistencies and establishes formal relationships among process elements enabling fast access to the information. In addition, processes built under the Unified CRM Business Process Framework are published as Websites sharing the same structure and look-and-feel, providing a consistent user experience across regions and countries.
Acknowledgments
I would like to acknowledge the contributions of all the reviewers, and thank them for their insightful comments on early drafts of this article. A special thanks to Peter Haumer and Steve Lew for their thorough review and invaluable suggestions.
Notes
- IBM Global Business Services:
http://www-935.ibm.com/services/us/gbs/bus/html/bcs_aboutus.html
- The project uses IBM Rational Method Composer (RMC) version 7.2. For more information on RMC, see the following resources:
- IBM Rational ClearCase:
http://www.ibm.com/developerworks/rational/products/clearcase/
- Unified Modeling Language:
http://www.ibm.com/software/rational/uml/
- IBM Rational Software Modeler:
http://www.ibm.com/developerworks/rational/products/rsm/
- The plug-ins can be either all located in the same RMC library, or distributed across several distributed libraries using RMC workspaces.
- The RMC meta-model, or Unified Method Architecture (UMA), is mostly compliant with the OMG Software and Systems Process Engineering Meta-Model (SPEM 2.0). More information is available at: http://www.omg.org/spec/SPEM/2.0/Beta2. You may want to refer to SPEM 2.0 for a standard definition of the variability relationships.
- To learn how to create your own publication skin in RMC 7.2, refer to the tutorial: "Customizing Publication Skins in IBM Rational Method Composer."
http://www.ibm.com/developerworks/rational/library/08/0708_gangavaram-haumer/index.html
- Cécile Péraire, "A Roadmap to Method Development," The Rational Edge, February 2007:
http://www.ibm.com/developerworks/rational/library/feb07/peraire/index.html
Resources
About the author | 
| | Cécile Péraire (cperaire@us.ibm.com) is a method architect with IBM Global Business Services (GBS), responsible for the architecture and development of the Unified GBS Customer Relationship Management Business Process Framework. Before joining GBS, Cécile was a member of the IBM Rational Unified Process® (RUP®) team, where she led development of the RUP method plug-ins. She has sixteen years of experience in the field of software engineering, as method architect and author, project manager, consultant, mentor, teacher, and researcher. She holds a Ph.D. in software testing from the Swiss Federal Institute of Technology in Lausanne (EPFL). |
Rate this page
| |
