Friday, October 12, 2012

What are process metrics?


As Harmon says one of the key steps in developing a business process architecture is to "determine how you will measure whether or not the value chain achieves its goals."  This is a point that is reiterated by Cooper and Patterson; "Success with BPM is almost always measured with a clear simple business metric … If you can't identify a metric that is meaningful to your business partners, you need to step back and evaluate if you have identified the right target process.”  (Cooper and Patterson, 2007).  Measurement is closely related to the steps of identifying a specific value chain and determining the specific strategic goals that the value chain is to achieve. 

Harmon indicates that there are two types of measures of business processes; internal and external.  The external measures focus on the results achieved by the value chain that the process is a part of and relate to the ultimate customer of the value chain.  Internal measures are focused inward on the process itself and relate to the efficiency of the process.  "External measures let us know how well the process is doing what it is intended to do. Internal measures let us know how effective the process is in producing outputs. Put slightly differently, External measures check results and Internal measures check productivity."

One similarity is that both internal and external measures can be thought of as relating the activity of the process to its customer, if one wants to consider any process that receives another processes' outputs as its customer.  In that sense a process is both "a supplier of one process and a customer of another."  Looking at metrics related to the output of a process and the customer satisfaction with that output is what binds both internal and external metrics together. 

One key difference between internal and external metrics, is that internal measures are leading indicators and are easy for managers to identify, collect and interpret.  External measures are often harder to identify and obtain in concrete quantifiable measures.  Measures like customer satisfaction also tend to be lagging indicators and knowing about them only comes after the performance of the process.  However, Harmon points out that although they should be used in conjunction, "to effectively evaluate the performance of an organization, you must focus on the external measures.  Once you "lock down" the external measures, then you can begin to focus on improving your internal measures."

Works cited
Cooper, M., Patterson, P. (April, 2007). Business Process Management (BPM) Definition and Solutions. http://www.cio.com/article/106609/Business_Process_Management_BPM_Definition_and_Solutions (Accessed on September 18,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.  Measurement and Services. (May 13, 2008).  BPTrends. (6:9).
http://www.bptrends.com/publicationfiles/advisor20080513.pdf (Accessed on October 3, 2012).

What is Enterprise Architecture? What is Zachman's Framework?



Briefly describe the Zachman's Enterprise Architecture framework. Describe 1-2 of its strengths.

1.0   Enterprise Architecture Defined
According to Gartner.com, (http://www.gartner.com/it-glossary/enterprise-architecture-ea/) an Enterprise Architecture is defined as:

“the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.”

Capgemini defines Enterprise Architecture as:

“a set of principles, rules, standards, and guidelines, expressing and visualizing a vision and implementing concepts, containing a mixture of style, engineering, and construction principles.”

The Open Group’s Architectural Framework (TOGAF) notes that:

“[Enterprise] Architecture has two meanings depending upon its contextual usage: (1) A formal description of a system, or a detailed plan of the system at component level to guide its implementation; (2) The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.”

US Federal Enterprise Architecture Framework (FEAF) definition:

“Enterprise architecture is a management practice to maximize the contribution of an agency’s resources, IT investments, and system development activities to achieve its performance goals. Architecture describes clear relationships from strategic goals and objectives through investments to measurable performance improvements for the entire enterprise or a portion (or segment) of the enterprise”

2.0   Enterprise Architecture Framework

An Enterprise Architecture is an extremely complex and complicated systems model.  Because of its size and complexity, EA frameworks or methodologies have been developed that provide a set of tools, techniques and terms to bring the EA into focus.

According to Sessions (2007):

“Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:

The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy

The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process

The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture

The Gartner Methodology—Can be best described as an enterprise architectural practice

3.0   Zachman’s Framework

“The field of enterprise architecture [methodologies] essentially started in 1987, with the publication in the IBM Systems Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman.  In that paper, Zachman laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years.  The challenge was to manage the complexity of increasingly distributed systems.  As Zachman said:

The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems. [02]

Zachman's vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. His multiperspective approach to architecting systems is what Zachman originally described as an information systems architectural framework and soon renamed to be an enterprise architecture framework.”

Zachman’s framework “summarizes a collection of perspectives” and is a “logical structure for classifying and organizing descriptive representations.”  It is depicted as a grid or matrix of six rows and six columns.  “Zachman proposed that there are six descriptive foci (data, function, network, people, time, and motivation) and six player perspectives (planner, owner, designer, builder, subcontractor, and enterprise.) These two dimensions can be arranged in a grid…There are 36 intersecting cells in a Zachman grid—one for each meeting point between a player's perspective (for example, business owner) and a descriptive focus (for example, data.)”

4.0   Strengths of Zachman’s framework

One of the strengths of this framework is that “it explicitly shows a comprehensive set of views that can be addressed by enterprise architecture.”
Another strength of this framework is that it provides for a very high level of detail in the artifacts created or depicted.

Because of the relatively large number of perspectives engendered in the framework, it provides a very narrow focus on each of the Enterprise Architecture components.

WORKS CITED

Op’t Land, M.; Proper, E.; Waage, M.; Cloo, J.; Steghuis, C. (2009). Enterprise Architecture: Creating Value by Informed Governance. Springer. (http://www.springerlink.com/content/978-3-540-85231-5) (Retrieved September 17, 2012).

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

Zachman, J.A. "A Framework for Information Systems Architecture." IBM Systems Journal, Volume 26, Number 3, (1987).

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.