What are Maturity Models? What is CMMI?

Identify two frameworks or maturity models and briefly discuss similarities and differences between them.

1.0 Maturity Models

Maturity models are “generic models that help analysts identify the specific management processes.”

Some of the “frameworks and maturity models that are currently popular … the Project Management Institute's (PMI) Project Management Maturity Model and then consider the Software Engineering Institute's (SEI) CMMI model, the Supply Chain Council's (SCC) SCOR business framework, and the IT Governance Institute's (ITGI) COBIT framework.” (Harmon, 2007).

In this discussion, I will focus on two of these; the Software Engineering Institute's (SEI) Capability Maturity Model Integrated (CMMI) and the Supply Chain Council’s SCOR Framework.

2.1   Software Engineering Institute's (SEI) Capability Maturity Model Integrated (CMMI)

The SEI’s Capability Maturity Model Integrated (CMMI) “is a process improvement approach that provides organizations with the essential elements of effective processes, which will improve their performance. CMMI-based process improvement includes identifying your organization’s process strengths and weaknesses and making process changes to turn weaknesses into strengths.” (http://www.sei.cmu.edu/cmmi/index.cfm).

The model was described in a book, The Capability Maturing Model: Guidelines for Improving the Software Process in 1995. (Reviewed by Paul Harmon at www.bptrends.com).  “In essence, the CMM team defined five stages that organizations go through as they move from an immature to a mature understanding of business processes. These stages were defined using examples from software organizations, but they apply equally to any large organization.”  (Harmon, 2007).

“The key assumption that the CMM team makes is that immature organizations don't perform consistently. Mature organizations, on the other hand, produce quality products or services effectively and consistently.”  (Harmon, Introduction. 2007).

In the CMM book, they describe it this way:

“In a mature organization, managers monitor the quality of the software products and the processes that produce them. There is an objective, quantitative basis for judging product quality and analyzing problems with the product and process. Schedules and budgets are based on historical performance and are realistic; the expected results for cost, schedule, functionality, and quality of the product are usually achieved. In general, the mature organization follows a disciplined process consistently because all of the participants understand the value of doing so, and the necessary infrastructure exists to support the process.”  (Harmon, Introduction. 2007).

Watts Humphrey, one of the leading gurus behind the CMM effort, describes it this way:

“An immature software process resembles a Little League baseball team. When the ball is hit, some players run toward the ball, while others stand around and watch, perhaps not even thinking about the game. In contrast, a mature organization is like a professional baseball team. When the ball is hit, every player reacts in a disciplined manner. Depending on the situation, the pitcher may cover home plate, infielders may set up for a double play, and outfielders prepare to back up their teammates.”  (Harmon, Introduction. 2007).

CMM identified five levels or steps that describe how organizations typically evolve from immature organizations to mature organizations as follows:

Level 1: Initial. The process is characterized by an ad hoc set of activities. The process isn't defined and success depends on individual effort and heroics.

Level 2: Repeatable. At this level, basic project management processes are established to track costs, to schedule, and to define functionality. The discipline is available to repeat earlier successes on similar projects.

Level 3: Defined. The process is documented for both management and engineering activities and standards are defined. All projects use an approved, tailored version of the organization's standard approach to developing and maintaining software.

Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

“The CMM approach is very much in the spirit of the Total Quality Management (TQM) movement that was popular in engineering and manufacturing during the late eighties.  CMMI's focus is on improving processes, but their major assumption is that processes are improved as they are defined, executed consistently, measured and, as a result of measurement, systematically improved.” (Harmon, 2007). 

“CMMI models are collections of best practices that help organizations to dramatically improve effectiveness, efficiency, and quality. These products, or CMMI solutions, consist of practices.  Practices cover topics that include causal analysis; configuration management; quality assurance; verification and validation; risk management; requirements management; supplier management; project management; interface compatibility; make, buy, or reuse analysis; capacity management; availability management; disaster recovery, data collection, process performance; and more.”  (http://www.sei.cmu.edu/cmmi/index.cfm).

2.2   Supply Chain Council’s SCOR Framework

The Supply Chain Council’ SCOR framework “is a management tool. It is a process reference model for supply chain management, spanning from the supplier's supplier to the customer's customer. The SCOR-model has been developed to describe the business activities associated with all phases of satisfying a customer's demand. By describing supply chains using process building blocks, the Model can be used to describe supply chains that are very simple or very complex using a common set of definitions. As a result, disparate industries can be linked to describe the depth and breadth of virtually any supply chain.” (www.supply-chain.org).

SCOR helps manage “a common set of business problems through a standardized language, standardized metrics, and common business practices which accelerate business change and improve performance.”  It is primarily “used to identify, measure, reorganize and improve supply chain processes make up a supply chain system.”  (www.supply-chain.org).

“For each supply chain process, like Source, Make, Deliver, or Return, they require the modeler to add a Plan process. … in effect creating a picture of the process management effort required for a supply chain process.”  (Harmon, 2007).  The Plan sub-process calls for “management of business rules, supply chain performance, data collection, inventory, capital assets, transportation, planning configuration, regulatory requirements and compliance, and supply chain risk” as well as aligning the supply chain plan with the financial plan.  

According to the SCC, a SCOR framework contains “a standard description of management processes, a framework of relationships among the standard processes, standard metrics to measure process performance, management practices that produce best-in-class performance, and standard alignment to features and functionality.  Once a complex management process is captured in Standard Process Reference Model Form, it can be implemented purposefully to achieve competitive advantage, described unambiguously and communicated, measured, managed, and controlled, and tuned and re-tuned to a specific purpose.”  SCOR Frameworks, (www.supply-chain.org).

The SCOR model “provides a unique framework that links business process, metrics, best practices and technology features into a unified structure to support communication among supply chain partners and to improve the effectiveness of supply chain management and related supply chain improvement activities.”  (www.supply-chain.org).

3.0 Similarities and Differences

A number of industry groups “are working to define the processes that managers use when they manage specific processes. Some groups have focused on the activities, skills and processes that a manager would need to manage an ongoing process, and others have focused on the activities, skills and processes a manager would need to manage a project. Some have focused on the activities of senior process managers and others have focused on managers who are responsible for very specific core processes. Organizations that focus on managerial processes usually tend to establish process management training programs to help their managers acquire the skills they need to perform better.”  (Harmon, 2007).

4.0 References

Harmon, P. (2007). Business Process Change: A Guide for Business Managers and BPM and Six Sigma Professionals. Burlington, MA 01803: Morgan Kauffman Publishers.

Harmon, P.  CMMI: Guidelines for Process Integration and Product Improvement. September 02, 2003. www.bptrends.com.

For more information on Software Engineering Institute's (SEI) Capability Maturity Model Integrated (CMMI), visit www.sei.cmu.edu.

For more information on the Supply Chain Council's SCOR framework, visit www.supply-chain.org.

What is Business Process Architecture Methodology?

Business Process Architecture - BPTrends Methodology

According to Harmon, "A Business Process Architecture, ... is a description of the organization's business model and strategy, its goals and its performance metrics. ... the value chains and large scale processes used by an organization that shows how processes support organizational strategies and generate performance metrics."

The enterprise methodology offered by BPTrends isn't the only possible approach, but it is one possible approach that answers the question, how do we as managers systematically address enterprise level concerns?  BPTrends methodology is a means of describing an "ongoing effort on the part of management to create and maintain the tools they need to function as a process-centric organization." 

In defining a methodology, Harmon specifically means "a comprehensive and specific set of instructions for accomplishing a task - in this case, redesigning or improving a business process."  Yet, he differentiates between methodology and algorithm, saying, "no methodology can ever be an algorithm. At best, a methodology provides an overall approach and a collection of heuristics. ... a precise vocabulary, checklists and worksheets, and specific procedures for accomplishing particular tasks that guarantee that trained teams will approach projects in a reasonably consistent manner and usually achieve the same results."  In so doing Harmon moves the definition away from commonly heald distinctions such as framework or taxonomy. "The Supply Chain Council’s SCOR, the TeleManagement Forum’s eTOM, and the Value Chain Group’s VCG Framework are all good examples of generic Business Process Architecture [framework]s."

Although sometimes these terms are used somewhat interchangeably, Sessions helpfully provides the following distinctions:

enterprise architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise

architectural framework—A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like

architectural methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture

BPTrends Process Architecture Methodology is in fact two separate, but complementary methodologies: "one for enterprise change and one for business process change."  The enterprise level methodology is the one that we will focus on here, which allows us to address the enterprise-level concerns (as distinct from the process-level or implementation-level concerns).  The first phase focuses on "understanding the enterprise as a whole."  A term commonly employed when describing business process architecture is holistic, seeing an enterprise as an integrated system of interrelated processes or value chains. 

The second phase narrows the focus to a specific value chain and begins creating a business process architecture for that single value chain.  The complexities of process architecture are such that it is not possible to utilize a methodology on more than one chain at a time, although a company may indeed have many more than one.  It is also at this stage that the architecture methodology allows us to "elucidat[e] the core business processes and subprocesses in the value chain" and to "define how each process will be monitored and measured."  It is also in this phase that management will "align policies and business rules with their processes. ... align IT resources, like software applications and databases. ... align human resources, including jobs, skill requirements, training programs, and knowledge management programs." 

BPTrends methodology usually relies on an "extended version of a business process framework to help managers develop a basic business process architecture and measurement system" and leads to the "development of a plan to manage their organization's business processes."  This plan may take the form of a " matrix that includes both functional and process managers."
It may also stipulate a BPM Group that will undertake process governance, monitoring and ownership.

Harmon further states: “Companies approach enterprise level activities in many different ways. Some, for example, use the Balanced Scorecard approach to help with the alignment of corporate goals and the evaluation of managers, but do not tie that program to business processes in any rigorous way. Others have a business process architecture, but do not tie their architectural models to their ongoing business performance evaluations.”

IBM Actionable Business Architecture

IBM cites "the need for an unprecedented alignment, or rather convergence of IT solutions to business priorities" in the face of a growing competitive environment.  They note that "this [convergence] offers the possibility to exploit the enabling power of IT solutions in defining business strategies. As business and technology become more intertwined, development and deployment of successful IT systems that address the needs of the business today and in the future become extremely critical."

In a series of white papers, IBM Global Business Services articulates its Actionable Business Architecture methodology as "the best way to achieve the above goals of business-IT convergence ... by exploiting Business Architecture. While all organizations have a representative business design, elaboration of a corresponding business architecture may not exist. Implementing such an architecture will create competitive advantages for the organization and enable it to realize operational improvements and efficiencies."

IBM Actionable Business Architecture is "a holistic Business Architecture paradigm" that relies on "three specific perspectives: strategy and transformation (S&T), business process management (BPM) and service oriented architecture (SOA)."

"Business Architecture defines and manages the valued relationships and interactions among the strategy, operating and IT models of a business."  These three models and their interactions are described more fully.

The strategy model "includes the vision, mission, goals, policies and commitments the enterprise develops, commonly classified under business intent or motivation."  It includes "value propositions as well as revenue and pricing models."

The operating model "describe[s] the boundaries of primary business functions and thus, are intimately connected to the pieces of the organization that perform those functions, as well as resources and skills that generate competitive advantage in support of the business strategy."  It can be thought of as "the set of interaction/coordination and learning and transformation processes that transcend functional and organizational boundaries. ... which people, resources, business rules and controls are involved."  The IBM Actionable Business Architecture emphasizes componentization and modularization at this stage. 

The third model is the Information technology (IT) model.  "Process segments are automated and enabled through IT systems, while the specifics of business functions and capabilities are implemented and delivered through IT systems." 
IBM describes the main differentiator between its Actionable Business Architecture and traditional business process architectures as follows:

"At a conceptual level, the Business Architecture described and developed within the scope of enterprise architecture is the same as what is characterized here as being at the intersections of strategy, operating and IT models. However, as presented earlier, the Business Architectures created by existing approaches are not wholly actionable.

Business Architecture realized at the focused intersections of S&T, BPM and SOA will be realistic and actionable. This strategy extends the scope of Business Architecture as typically defined, enhances the details developed by activities that are considered within scope, and prescribes specific approaches for adoption and execution."

Conclusion

"Everything should begin with a corporate strategy," according to Harmon.

Since Michael Porter’s work on value chains, "strategy depends on processes, how processes interact with each other, how process performance is measured, and a deep understanding of how processes interface with customers. Thus, with or without a formal enterprise process enterprise, organizations are engaged in defining enterprise level tools that will provide the structure and the data needed to make important day-to-day decisions and to support key initiatives like the entry into new markets, mergers, acquisitions, or outsourcing. As we have already suggested, a business process enterprise methodology simply provides a systematic way to achieve that goal."

Both the BPTrends methodology and the IBM Actionable Architecture stress the importance of a holistic, process perspective as opposed to a more traditional, functional silo perspective. Harmon advocates that managers "need to think in terms of organizational systems and value chains rather than thinking primarily in terms of divisions, departments, or their own functional unit."  This systems perspective lies at the heart of enterprise architectures and "emphasizes process and connections, and ultimately adaptation."  He further states that "Process thinking is just a subset of systems thinking. Systems thinking puts the emphasis on understanding the organization as a whole. Process thinking stresses thinking about a portion of the system that produces a specific set of results."

Lastly, Harmon reminds us that "Departments don't produce profits; value chains and processes produce profits."  Through the deployment of a business process architecture methodology such as  BPTrends or IBM's Actionable Business Architecture, managers can effectively embrace a holistic, systems perspective toward integrating processes, strategy and information technology leading to greater customer satisfaction and greater stakeholder value.

WORKS CITED

Actionable Business Architecture.  (October 2010). IBM Global Business Services. White paper.
ftp://public.dhe.ibm.com/common/ssi/ecm/.../GBW03113USEN.PDF (Accessed September 12, 2012).

Actionable Business Architecture – IBM’s Approach.  (October 2010). IBM Global Business Services. White paper.
http://www-935.ibm.com/services/de/.../actionable-business-approach.pdf  (Accessed on September 12, 2012).

Harmon, P. (2007). Business Process Change: A Guide for Business Managers and BPM and Six Sigma Professionals. Burlington, MA 01803: Morgan Kauffman Publishers.

Harmon, P.  Enterprise Modeling.  (October 23, 2007).  BPTrends. (5:8). 
http://www.bptrends.com/publicationfiles/advisor20071023.pdf (Accessed on September 10, 2012).

Harmon, P.  What Is Business Architecture?  (November 16, 2010).  BPTrends. (8:19). 
http://www.bptrends.com/publicationfiles/advisor20101116.pdf (Accessed on September 10, 2012).

Harmon, P.  Business Process Methodologies.  (November 16, 2010).  BPTrends. (5:20). 
http://www.bptrends.com/publicationfiles/advisor20071127.pdf (Accessed on September 10, 2012).

Sessions, R. (May 2007). A Comparison of the Top Four Enterprise-Architecture Methodologies. 
http://msdn.microsoft.com/en-us/library/bb466232 (Accessed September 12, 2012).

Case 1, Phase 1

What is business process change?

Organizations undertake process change initiatives for a variety of reasons. What do you think some of these reasons are? Briefly describe one or two of them.

In their article, Davenport and Short define business processes as “a set of logically-related tasks performed to achieve a defined business outcome.” Hammer and Champy define business process as “a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer.”   

According to Hammer and Champy, there are three situations in which a company would engage in business process change;

• The company is in deep trouble, its costs are much higher that the competition’s, it’s product quality is lower, or it’s customer service is poor.  It must change radically or die.
• The company is not yet in trouble, but has the foresight to see trouble coming – new competitors, changing customer requirements or characteristics, an altered regulatory or economic environment, but change is inevitable.
• The company is in peak condition and has no present or approaching difficulties, but uses the opportunity to further its lead and to raise the bar even higher, solidifying its position of leadership.

They colorfully describe these cases as follows: “Companies in the first category are desperate; they have hit the wall and they are lying injured on the ground.  Companies in the second category are cruising along at high speed, but see something rushing toward them in their headlamps.  Could it be a wall?  Companies in the third category are out for a drive on a clear afternoon, with no obstacles in sight.  What a splendid time, they decide, to stop and build a wall for the other guys.” (p 37-38).

So what drives organizations to engage in business process change initiatives?  Harmon posed the following answer:

“In economically bad times, when money is tight, companies seek to make their processes more efficient.  In economically good times, when money is more available, companies seek to expand, to ramp up production and to enter new markets.  They improve processes to offer better products and services in hopes of attracting new customers or taking customers away from competitors.” (p 20).

Pearlson and Saunders distinguish between to two types of business process change, incremental and radical.  “Some examples of situations requiring radical change are when the company is in trouble, when it imminently faces a major change in the operating environment, or when it must change significantly to outpace its competition.” But Hammer rejects the notion of incremental change as not a reengineering or radical redesign of business processes, per se, and therefore not business process change.

“Unless we change these [outmoded] rules, we are merely rearranging the deckchairs on the Titanic. We cannot achieve breakthroughs in performance by cutting fat or automating existing processes. Rather, we must challenge old assumptions and shed the old rules that made the business under perform in the first place.”  Hammer referred to “quantum leaps in performance” in his 1990 Harvard Business Review article.

Pearlson and Saunders also point to the radical aspects of BPC, and highlight some of the key characteristics that they think impel organizations to engage in this radical form of change:

• ·         The need for major change in a short amount of time
• ·         Thinking from a cross-functional process perspective
• ·         Challenging old assumptions
• ·         Networked (cross-functional) organizing
• ·         Empowerment of individuals in the process
• ·         Measurement of success via metrics tied to business goals

Vacecich and Schneider note that “information systems can be used to gain and sustain competitive advantage by supporting and/or streamlining activities along the value chain” and stress the need to “integrate business activities across departmental boundaries.”  They point out that “competitive advantage can be accomplished here by integrating multiple business processes in ways that enable a firm to meet a wide range of unique customer needs. … Information systems allow the company and its suppliers to satisfy the needs of customers efficiently since changes can be identified and managed immediately, creating a competitive advantage for companies that can respond quickly.” (292).

But they also indicate that the essential element underlying business process change is its radical nature.  “BPM [business process management] is similar to quality improvement approaches such as total quality management and continuous process improvement in that they are intended to be cross-functional approaches to improve an organization. BPM differs from these quality improvement approaches, however, in one fundamental way. These quality improvement approaches tend to focus on incremental change and gradual improvement of processes, while the intention behind BPM is radical redesign and drastic improvement of processes.” (297).

So while change is the ultimate driver; change in the market, the overall environment or economy, or change brought about by new competitors, new products and especially new technologies; what prompts companies to engage specifically in business process change initiatives, is a desire to achieve “quantum leaps” in performance by adopting a process perspective and avoiding the incremental improvements attained in the past by focusing on specific functional silos, rather than the end-to-end processes that provide value to the customer.  Recognizing that the new technological possibilities can be a source of dramatic improvement, some companies embrace ERP, CRM or SCM in the hopes of realizing performance improvements, but without first aligning the business activity to the technology, this approach often leads to disappointment. 

WORKS CITED

Thomas H. Davenport & James Short, “The New Industrial Engineering: Information Technology and Business Process Redesign,” Center for Information Systems Research, Massachusetts Institute of Technology, Sloan School of Management (June 1990), 4.  

Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate,” Harvard Business Review (July–August 1990), 4.

Hammer, M. & Champy J. (2003). Reengineering the Corporation: A Manifesto for Business Revolution.  New York, NY: HarperCollins Business Essentials.

Harmon, P. (2007). Business Process Change: A Guide for Business Managers and BPM and Six Sigma Professionals. Burlington, MA 01803: Morgan Kauffman Publishers.

Pearlson, K., & Saunders, C. (2009). Managing and Using Information Systems: A Strategic Approach. Hoboken, New Jersey: John Wiley & Sons, Inc.

Valacich, J. & Schneider, C. (2012). Information Systems Today, Managing in the Digital World. Upper Saddle River, New Jersey: Prentice Hall.