16. Business Process Analysis
DE + IA (INFO 243) - 12 March 2007
Bob Glushko
Plan for Today's Class
- Capability Assessment
- Introduction to Process Modeling
- The Abstraction Hierarchy in Process Models
"Myth of the Paperless Office" -- DanTech
- What were DanTech's motives for going paperless?
- What are the costs and benefits of co-locating people and the documents they create and use?
- How might a paperless office change the cost/benefit tradeoffs?
- What DanTech document types most easily became paperless? What document types resisted becoming paperless? What principles determine this?
- What happens to legacy information in the transition to a paperless office?
- How did DanTech hope to handle naming and classification of new documents? Why did the initial approach fail? Did the revised approach work any better?
- What were the benefits to DanTech of going (almost) paperless?
"Myth of the Paperless Office" -- UKCom
- What were UKCom's motives for going paperless?
- What UKCom document types most easily became paperless? What document types resisted becoming paperless?
- How did improved information access by Account Managers improve their processes? Why did they not reciprocate by sharing information with Bids and Sales?
- What's the key lesson to learn from UKCom's experience?
Context and Capability
- As we've seen in case studies land news articles, the success or failure of a document engineering project largely 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 11 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
- EXAMPLE: "IBM Core Systems Strategic Assessment"
Capability Assessment: Motivation
- 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
- An alternative to measurement is capability assessment: can you predict the likely quality of its products/services or its success in carrying out a project?
Capability Maturity – Concepts
- Fundamental assumption of capability maturity assessment is that the processes used determine the quality of the results
- 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"
CMM Level 1 – Initial
- Competent People and Heroics
-
Processes are ad hoc, and occasionally even chaotic
- No stable environment for development and maintenance
- Schedules are "backed in" and not based on quality
CMM Level 2 – Repeatable
- Basic Project Management
- Projects start from requirements that are subsequently tracked
-
Processes are established to manage cost, schedule, and functionality
- An effective process is one that is documented, trained, practiced, enforced, and capable of being improved
CMM Level 3 – Defined
- Process Standardization
-
Processes for both management and engineering activities is documented, standardized, and integrated into a standard process for the organization
- Typically depends on some group or department responsible for developing and standardizing processes
- Training programs for ensuring that all staff and managers have required knowledge and skills
CMM Level 4 – Quantitative
- Quantitative Management
-
Detailed measures of the process and product quality are collected
- Processes and products are quantitatively understood and controlled
- Capabilities are quantifiable and predictable, with measurable limits and tolerances
- When problems (variation from prediction) arise, the causes are identified and addressed
CMM Level 5 – Optimizing
- Continuous process improvement
-
Enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
- The entire organization is focused on identifying best practices and institutionalizing them
The CMM Hype [2]
- 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 as "Metamodel"
- 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
Adapting the CMM
- 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
The "Technology-Process Framework"
"Cultures" or Capability Biases
Capability Biases and Technology Adoption
Capability Biases and Technology Adoption
Capability Biases and Technology Adoption
Explicit Capability Assessment
- 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
Generic Assessment Questions in Document Engineering
- 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
Generic Assessment Questions in Document Engineering
- 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
Documents and Processes -- Yin and Yang
Modeling Documents {and,vs,or} Modeling Processes
- A document exchange consists of both the documents and the processes that produce and consume them
- By understanding the information in the documents, we learn what kinds of processes are possible
- By understanding the processes, we learn what kinds of information are needed
Why We Analyze Business Processes
- 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
Business Process Analysis
- 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
The Business Process Analyst (1)
- 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 (2)
- 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
What Are You Doing Now?
- 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?
Making a Pizza
- 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 Abstraction Hierarchy in Process Models
- 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 see these at the highest levels of SCOR, RosettaNet, MIT Process Handbook
- A group of interconnected or choreographed transactions as a construct in a process model is what we most often mean by "business process"
- Documents and processes are at the same abstraction level when we focus on business transactions -- this is the level of the RosettaNet PIPs and UBL
- Process models have little abstraction when we want to specify every detail of control and decision logic needed in an implementation
Levels of Abstraction in Pizza Process Models
The ebXML Process Metamodel
For Wednesday March 14
- "BPM Process Patterns: Repeatable Designs for BPM Process Models" (January 2006)
