�ݺ�ߣ

Editor's Notes

• #3: This definition covers any repeatable body of work, from low-level tasks and procedures to enterprise-level processes. It is to ambiguous for our purposes, but unfortunately is what is often being used within the BA community, and hence creates confusion among the stakeholders. Hence, what we need is concrete tests or guidelines to determine if one collection of activities qualifies as a business process and another doesn’t.
• #4: A process is a set of activities or a sequence of steps and decisions completed by a person or a machine or both. Note that the “result” is far more important to the definition of a business process than the work that goes into it. This is the 1st step in deciding whether or not you have a process; verb-noun (e.g. Assign Inspector), verb-qualifier-noun (e.g. Assign Backup Inspector), verb-noun-noun (e.g. Assign Inspector to Route). The verb-noun must indicate the result of the process. noun-is-verbed (e.g. Inspector is Assigned)
• #5: Discreet and identifiable means: one can differentiate individual instances of the result, where it makes sense to talk about “one of them”. Countable means: one can count how many of that result have been produced within a given timeframe.Essential means: the process is fundamentally necessary to the operation of the enterprise, not just a consequence of the current implementation. Named in the singular: this focuses attention on a single, specific, countable result.
• #6: In determining process results – i.e. the output the process produces – don’t confuse results with objectives. For a process to achieve certain organizational objectives, it must attain certain results that meet that objective. However, result and objective are not the same thing.
• #7: Note that you begin to factor in who and how later in analysis – who by cross-referencing the process to the organizations and actors that are involved, and who and how by developing swimlane diagrams. In data modeling focus on what things the business needs to maintain information about, regardless of how (e.g. files, databases, etc…)In requirements modeling services describe what the application must do, and use cases describe who needs access to a service and how they will interact with a system to receive it.
• #8: By this definition a process should be technology and/or organization agnostic. The delivered result which defines the process does not depend on the technology that may implement the process, nor on the organization that uses it.
• #9: What starts a process? It is some triggering event, and there are three types:Action Event: These happen when a person or organization decides to do something, for whatever reason; (e.g. customer decides to place an order, manager decides the company needs a new employee, etc). You can’t predict exactly in advance when a particular action event will occur. Temporal Event: These happen when some predetermined date or time is reached at which some activity must begin. Many processes in an organization are triggered by temporal events; (e.g. time to run payroll, time to close the books, time to take inventory, etc). You always know exactly when a particular temporal event will next happen, because it will be recorded somewhere within the business system. Conditional or Rule Event: These happened when a monitoring activity detects some exception condition’ (e.g. smoke alarm set off, stock price hitting some predetermined limit, etc). You can’t predict in advance exactly when a particular condition event will occur.
• #10: We can call this the organizing framework. At one end is the triggering event, at the other end is a result, or multiple results. In the middle there is the action being carried out. We define the middle as a sequence of steps and decisions, or a related set of activities. For predictable, transaction-handling processes, we’ll say it is a defined sequence of steps and decisions. For less predictable, collaborative or creative processes, we’ll say it is a set of related activities.
• #12: A business process is simply a special type of process. Here we concentrate on that type.
• #13: The last two bullet points are empirical findings based on years of practice in the field.
• #14: This slide shows how processes and/or activities (within a process) are linked to each other. They can be either one-to-many, many-to-one, many-to-many, one-to-zero, or one-to-one. Q: Why do the first three indicate boundaries between business processes? A: Within a single, end-to-end business process it is the same “token” or “work item” that moves through the process, even though it’s state is being changed. This makes it a one-to-one (1:1) relationship between activities. Whenever a 1:M or M:M connection is encountered you will find a different token to be the focus of the process.
• #17: For example, on the last bullet item, a loan application moves all the way through a “loan application process”, eventually a booked loan. These clear and repeatable guidelines are very useful in practice. Note also, that linked sub-processes assemble into business processes, whereas related business processes assemble into process areas.
• #19: Note that you can have a well defined business process, with a clear event and result, but it might not be possible to model the entire process in a flow model.
• #20: A process is a way for an enterprise to organize work and resources (people equipment, information, and so forth) to accomplish its aims. An enterprise organizes resources into functions, but will try to organize work to contribute to the achievement of a specific output – a result – for a specific customer. This is process orientation and gives rise to the above definition. The word “activity” is used here generically to refer to work that might be named as a single unit, but can involve multiple actors, where each makes a separate contribution. Note by contrast that a “step” refers to work that is done by one actor at a point in time. Consider the term “…achieve a specific, discrete result…”.  The only reason a business process exists is to deliver a specific result, and the main guideline is that the result must be individually identifiable and countable. Note also, that a good process name clearly indicates the result or end state of the process. Consider the term “…for the customer and other stakeholders…”.  this is the recipient or beneficiary of the result produced by the business process. It can be a person, an organization, a broad marketplace. It can also be internal to the organization that works the business process. Key is, the customer can be identified and judge the process results as to how satisfactory it is. Note too, that the business process is likely to provide a result to more than one stakeholder, notably the organization itself. Consider the term “…initiated in response to a triggering event...”.  You must know what the earliest event is that makes the process go. Often, it is a specific request for the result the process produces. Note that identifying the earliest event may be difficult at times. There may be more than one triggering event, where either one or the other is required. Once you have an event and a result, it is much easier to trace the flow of work that transforms the former into the latter. Consider the term “…activities…”.  here is where semantics matter, so we can minimize ambiguity. During process discovery we refer to “activities”. During framing we identify “sub-processes”. During workflow modeling we specify “steps”. This is, because workflow models show process steps performed by actors. Note that an initial workflow model step, is likely to be further decomposed into more and finer steps during development of more detailed models. Consider the term “…collection of interrelated…”.  activities in a process must interrelate. They do so through sequence and dependency. I.e. the completion of one step leads to (flows into) the initiation of the next step, in sequence. The sequence can be arbitrary, or dependent, meaning that step B cannot take place until step A has completed. The steps are interrelated in that they deal with the same token or work item, and by being traceable back to the same initiating event.
• #22: They are seldom immediately evident, because they are hidden by organizational structure, job definitions, systems, geography, product lines, etc. Often, it is easier for the customer to define the business process because they are the only ones who see it all. Even if the organization doesn’t recognize it, the process is there, because somehow, the initiating event makes its way to a result. It is hard for organizations to identify their processes because of years of looking at things organizationally. Business processes coordinate their elements: people, resources, systems, and work. In a well-designed process, all of the elements are well coordinated, including the individual work steps. If you take a single “natural” process, it will virtually always perform better if designed as a single end-to-end business process than if the same result was achieved through five smaller processes. Why? In an ideal process, the inputs and outputs of the individual steps are well coordinated. I.e. the output from one step flows smoothly and uninterrupted to become the input of the next step in the process. The problem is, that there is a strong tendency, when trying to achieve optimization within their area, for designers to put constraints on work entering and leaving their process. This may make the process internally optimal, but the overall – natural, end-to-end business process – is slowed down, because there is now additional work that must be performed to move from one “process” to another. Hence: processes should be defined as large as possible, because multiple small processes each tend to strive for internal efficiency, resulting in local optimization, but causing overall sub-optimization. Politics, conflict, and emotions, are all hidden issues that can make process discovery difficult. Specifically, some are:Who “owns” the process, and how can they influence the various functional areas?There may be conflicting performance targets for the participating organizations and individuals.The blame game may arise – participants often feel that they are blamed for poor process performance.Process improvements can have unanticipated consequences, and they are usually bad.