Tips for Starting (and Ending) a Process Analysis
Laura Brandenburg wrote a series of five tips to get you over the business analyst’s equivalent of writer’s block when starting a process analysis exercise. The first tip is to define the start and end of the process and give the process a name.
It sounds obvious, but there’s real value in just writing that down—it gives you a framework for defining the scope of the exercise.
Without some boundaries, there’s a very real risk that you will never finish—you’ll just keep analyzing forever. In addition to Laura’s other tips, I would add a couple more, adapting things I learned from working in agile software development.
Write down your definition of “done.” It sounds backwards, but knowing the end of your journey can make it easier to take the first step.
Start with the question “Why am I modeling this business process?” The answer might be as a step in a process-improvement initiative—in which case, your definition of done needs to include (a) the costs incurred in the process, (b) the duration of the process, (c) the constraints that bound the process (to know what can and cannot be changed), and (d) what the process actually does. If you’re doing a gap-analysis (comparing what is needed for the future with what is accomplishable today), you may only care about what the process does.
Just as Laura starts with “Give it a name”, I start with “Draw a single box.” The entire process happens inside that box. Before you try to figure out what happens inside that box, capture the inputs and outputs of that box.
My approach to process modeling was changed when I saw a presentation by Kathy Long at the IBRF in 2007. Read Sandy Kemsley’s review of the session. In Kathy's presentation, she made the point that every process has inputs, and that the process “does something” to transform those inputs into outputs. She drew the process box with inputs coming in from the left and outputs going out to the right. Then she added that every process has instructions—guides—that influence how it operates. She drew those as coming in from above the box. And every process has enablers—other systems or people on which the process is dependent. Those were shown entering the process from the bottom.
My next step after “Give it a name” is to identify “What goes in?” For an “online payment process” it might be the user’s (a) account identifier, (b) payment information, and (c) the amount of money to be charged.
Then identify “What comes out?” In this example, it could be (1) the record of a completed transaction, (2) a transfer of funds from the user’s payment source to the vendor, (3) an acknowledgement to the user of the completed transaction, and (4) notification to a fulfillment system to process the order.
Then identify “What guides the process?” That may be (i) tax policies, (ii) PCI/PII protection policies, (iii) transaction processing rules, etc.
Finally, identify “What enables the process?” For this example, it may be to identify the (A) shopping cart, which provides an order ID, (B) the financial systems from which funds are deducted and added, (C) the fulfillment system that delivers the user’s purchased product, etc.
At this point, writer’s block is gone, and I’m ready to say “Inside that box, what are the other boxes?”
