The CMM Hype [1]
Copyright 2006 Robert J. Glushko
Capability Assessment
Introduction to Process Modeling
The Abstraction Hierarchy in Process Models
Transactions and Collaborations
Assignment 7 -- Business Process Analysis
As we've seen in case studies and news articles, the success or failure of a document engineering project critically depends on whether the context and scope are "reasonable" for the parties involved
The activities we called "analyzing the context" in Chapter 8 and "document inventory" in Chapter 9 often provide an informal sense of how ready an organization is to carry out a document engineering project
Professional services and consulting firms go one step further and offer "capability assessment" or "readiness" services to help clients maximize the return on their project investments, especially in software development but more recently for business processes and SOA
You can measure the performance of an organization after it builds a product or carries out a project
But you can't measure performance on something it has never done before
And if can be expensive if the product or project is a failure; it may be harmful or fatal to your business
An alternative to measurement is capability assessment: can you predict the likely quality of its products or its success in carrying out a project?
Guiding assumption is that the processes used determine the quality of the products produced
The Software Engineering Institute at Carnegie-Mellon University developed a Capability Maturity Model for Software in 1980s-90s (http://www.sei.cmu.edu/cmm/)
Goal was to improve US government's (DOD) selection of defense contractors
The CMM describes the principles and practices underlying software process maturity to help software organizations improve the maturity of their software processes
"The CMM became a de facto standard for assessing and improving software processes... an effective means of modeling, defining, and measuring the maturity of the processes used by organizations developing and maintaining software-intensive systems"
But most of the Indian outsourcing firms claim to be CMM Level 5; entangled in the outsourcing debate "we're not just cheaper, we're better" (google for CMM, outsourcing, India)
The Pros & Cons of CMM (http://www.computerworld.com/managementtopics/outsourcing/story/0,10801,87882,00.html)
Bursting the CMM Hype (http://www.cio.com/archive/030104/cmm.html)
How would you obtain a CMM rating higher than you deserve?
Nevertheless, the concepts and "metamodel" of the CMM are extremely useful and relevant
The CMM was developed for the domain of software development, but is a useful "metamodel" for understanding an organization's problems and prospects in other domains
You need to understand current capabilities and perspectives to plan how to improve them
You need a standard way to package the results of the assessment
For many years I worked as a consultant or as the head of a consulting firm and found it useful to modify the CMM and use it in our engagements
Use assessment questions and procedures appropriate to our business domain (electronic publishing, document engineering)
Make two important changes to standard CMM:
Don't force assessments into levels
Distinguish technology maturity from process maturity
In an explicit capability assessment one or more "assessors" visits an organization to ask questions and examine artifacts to determine its capabilities and biases about technology and process
The questions should be designed so the "right" answer must be confirmable by real evidence so that coaching can't skew the assessment
But we'll illustrate the ideas with some multiple-choice questions
Why is your organization considering web services and XML?
We could be more responsive to our suppliers and customers, we could process and generate the appropriate business documents more accurately and quickly, and we could provide customers with a personalized catalog from our "content database"
Web services will reduce our costs of doing business
Our competitors are adopting web services and XML and we have to keep up
Our engineers think they can do some exciting stuff with XML because they've found some cool open source tools
Which of the following best describes the overall process by which your documents or publications are created?
There is an explicit and formal step-by-step process that is generally followed and our documents and publications are produced on time while meeting our explicit quality criteria
There is an explicit and formal step-by-step process, but people sometimes "work around" it to meet their schedule and quality requirements
The process is informal, but people are usually successful at producing documents and publications on time with acceptable quality
The process is informal, and there is sometimes a panic or crisis atmosphere, but we usually manage to get the documents and publications out when we have to
We have no process, and we sometimes just publish whatever information we have when the product is ready to ship or when the customer demands it, even if we know the documents aren't complete or entirely accurate
To ensure that all participants, stakeholders, software providers, standards developers, etc. have a common understanding of the enterprise and business domain
To understand the enterprise independent of its current or future technology
To identify and understand gaps, inefficiencies, overlaps, and opportunities
We perform an "as-is" analysis of how the enterprise conducts its activities today
We identify requirements that may result in new or revised activities / processes / transactions – the "to-be" model
We look for existing patterns or opportunities to use patterns in the models
We may "re-engineer" the "as-is" model to optimize the processes; this is business process design
Document engineering involves the analysis and modeling of both business processes and "documents," but it is useful to describe business process analysis as a separate specialty
The primary roles of the business process analyst are those of any analyst (and those are?)
Additional required skills
Ability to view and analyze a problem from the viewpoint of business goals, business requirements, and processes
Familiarity with business reference models
Less need for technology and implementation skills than the Document Analyst
The business process analyst asks many of the same questions as the document analyst but the focus is on understanding the processes that produce and consume documents rather than on the documents themselves
The business process analyst need to be comfortable talking with people at many organizational levels, from "factory floor" workers to executives
If someone asks you "what are you doing now?" what might you say?
"I'm living in Berkeley and taking courses at the University"
"I'm studying Document Engineering"
"I'm listening to a lecture on business processes and was just asked what I was doing now"
You can answer the question at many different levels of abstraction
What determines how you answer it?
Select recipe
Turn on as many lights as necessary to ensure adequate lighting in preparation and cooking area
Assemble required ingredients after washing and drying hands.
Sift 1/2 kg of flour into a large mixing bowl (preferably plastic), and then add a pinch of salt and pepper
Follow the rest of the preparation instructions in the recipe to make the pizza.
Pre-heat the oven to 350 degrees Fahrenheit.
Open the oven door, place the pizza in the oven, and close the door.
When the pizza is done remove it from the oven
The fundamental difference between document models and process models is the range of abstractness / granularity with which you can describe processes
We can model processes at an organizational level from the perspective of the nature and pattern of "value exchanges" between an enterprise and its suppliers, customers, and other entities in its "value chain"
We can treat a group of interconnected or choreographed transactions as a construct in a process model; this is what we most often mean by "business process"
We can model documents and processes at the same abstraction level when we focus on business transactions
The most important concept in business process modeling – and the most overloaded one – is transaction
A business transaction is an atomic unit of work in a trading or commercial relationship between two parties
A business transaction is conducted between two parties playing the requesting and responding roles
There is always a requesting business document and optionally a responding business document depending on whether the transaction semantics are one-way or two-way
A business transaction either succeeds or fails.
If it succeeds it may imply a legally binding contract or obligation between the parties participating in the transaction or otherwise govern their collaborating activities
If the business transaction fails each partner must relinquish any mutual claim that would have been established by a successful transaction
Business transactions cannot be "rolled back" but the obligations established by a successful transaction can sometimes be undone by a compensating transaction
The time scale for a business transaction can range from seconds to days, weeks, or longer
A transaction is a group of statements or instructions to a database whose changes can be made permanent or undone only as a unit
Transactions provide a simple model of success or failure – a transaction either commits (all its actions happen) or it aborts (all its pending actions are undone). This all-or-nothing quality makes for a simple programming model
A transaction can be "rolled back" in the same unit with which it was committed to undo all of its effects and return the database to a prior state
The time scale for a database transaction is measured in fractions of a second
An abstract / coarse / strategic / domain view of processes is the top-down perspective from senior management
The granular / transactional view is bottom-up, less likely to be technology-independent, and naturally emerges from operational personnel as they describe the processes and documents they work with
We need to close this gap to get a complete, balanced, and actionable view of the processes
Two or more business transactions can be sequenced to carry out a business collaboration
A business collaboration is a series of activities carried out by two or more partners for the purpose of achieving a business goal; these activities are business transactions
The set of transactions have meaningful and necessary semantic overlap with each other
The choreography describes the sequence and transition between business transactions that make up a business collaboration. Choreography is often depicted using UML Activity Diagrams and their associated concepts like start state, completion state, activities, synchronization, transitions, and guards
Brian Hayes led the ebXML effort to develop Worksheet Views to capture information in a less prescriptive and more user-friendly manner
Philosophical approach:
Worksheets are just views into the underlying meta-model
You can tailor the modeling approach by customizing worksheets to fit your or your client's methodology and language
This is a less prescriptive approach that lets the analyst capture "fragments" of the metamodel whenever they arise or are discovered
Modeling the process of buying a used car
You'll produce some worksheets and diagrams
Due on Friday 24 March
"Staple yourself to an order"
"The Myth of the Paperless Office"