Here are my notes on the business process modeling training I attended the other week, which may be of interest to people who … model business processes?
40+ years of experience, continues to work as a consultant as well as training. Impressed me with his practical, thorough knowledge of the subject matter.
Business analysis is a way to understand the as-is, discover or create improvements, and describe the to-be. A key tool is business analysis is modeling, and a very common way to model is by drawing pictures. Another way to analyze a business process is with a use case.
We did two days of modeling, and one day of use cases.
Types of business analysis
We covered a few standardized types of diagrams. They are primarily useful to help people communicate within a single project; maintaining a library of detailed process documents and keeping them current with any changes is very expensive and probably not woth the trouble. Instead, create documents to help specific groups of people work through specific problems, and set them aside once those problems are solved.
"Context-level diagrams." High-level diagrams that show a business process. I think this is what Yourdon calls a Data Flow Diagram. It has four ingredients:
You can then apply some rules, such as, no arrows between squares, which means, no data flows between two different external entities. By putting everything into a model and then applying mechanical rules, you can uncover both the incomplete parts of the model and, more helpfully, places where the model accurately represents a broken process.
"Question File." A list of questions that you accumulate as you analyze a process. You then keep working through the list until all questions are answered (or dropped). I did this on my last project without realizing that it was a thing, with a name. The main value of much of the modeling is to generate questions, which in turn will expose parts of the process that weren't fully thought through or which don't or won't work as designed.
"Hierachical Model". When the process model gets really complicated, i.e., bigger than one page, you can make a one-page high-level model and then decompose processes on that page into more detailed models on their own pages.
"Wall Chart". For people who don't like hierchical models. Everything is modeled at the lowest level, all on one big page.
"Main Line". The normal path through the process should start on the left side, halfway up, and proceed across the page horizontally to end on the right side, halfway up. Then exceptions and alternatives go above and below, and it's easy to distinguish the most common path from the wierder paths.
"Swimlane". Parallel lines added to activity diagram or process model to show segmentation along a dimension, e.g, a department
"Business Rules." I've been using this term for a long time, without a concrete definition. The way I've heard it used implies a definition like "the subset of product requirements that are specific to a customer's business, as opposed to technical requirements, or requirements that are about some functionality that isn't directly related to the customer's needs. By this definition, for example, the list of users who have access to post things is part of business rules, but the details of how password recovery should work are not.
"Business Rules" is a term invented by Barbara Van Halle in the 1980s and 1990s. As I interpret the instructor's telling of Van Halle's intent, a business rule is a functional requirement for a system which could change, at least within known boundaries, and therefore should usually be implemented as a user-configurable feature within a program. For my previous example, the list of users who can post things will clearly change as users come and go, and so some user needs the ability to administer that list without changing the program. Password recovery might have some business rules too, such as how many times you can ask for your password. But the fact that the system emails your password, rather than faxing it or calling you with it, is probably not a business rule, and can be hard-coded into the system.
Five types of business rules:
"Near learning" vs "Far learning". These were new terms for me. After googling, it appears that they are from the "Transfer of Learning" theory, dating back to 1901 and intending to explain how (or if) people take something they learned in one context and apply it in another context. To take a silly example, If you learned how to tie your shoelaces, then tying boot laces would require near learning, but tying the knots on a sailboat would be far learning. Where I think this applies to what we are doing is in customizing training for users. One thing that often confounds users in training is that the examples may not be relevant to their normal work. We saw this in training in Macon: the sample business process that we practiced modeling had to do with orders and inventory and shipping, not with HR applications and vacancies. Learning the modeling requires one level of mental effort, and understanding the specific process to be modeled requires a different mental effort. Since we didn't already understand the process we were modeling, we had to do woth levels of effort, and they can conflict with each other. We were doing two kinds of far learning at once. We managed to work through it, but it slowed us down a bit.
The fact that users get confounded by examples can in turn confound us as trainers: "I'm trying to show you how to post a vacancy but you seem to be stuck on the fact that it's a Coast Guard vacancy, and you're in the Army. I know you don't post Coast Guard vacancies in the Army. Why can't you just pretend it's an Army vacancy?" But what's happening is that the user is being asked to do too much learning, and too much "far" learning, at once. Dennis and I were talking about customizing training materials. It's a big expense and something we may not have the capacity to do, but if there's any way to make it happen, I think it can really pay off by reducing the effort required by the trainees.
(This is not a full summary, just my notes on the ideas that jumped out at me as new or better compared to what I knew before)
Use cases are helpful for describing interactions between the user and the system. They are not helpful for describing automated functions, batch jobs, etc.
Use the "T-shape" to show a dialog between the user (left column) and the system (right column)
A "scenario" is a blow-by-blow account of one actor doing all of the steps to complete a task, including the specific data input and output. It can be a stepping stone to a use case.
There used to be a distinction between "business use cases" and "system use cases"; this is being replaced by the concept of use cases on a spectrum of detail rather than two distinct types.