At a recent engagement, I encountered several departments that asked me to help write their departmental policy on a particular subject. When I inquired as to the governance process for changing existing company policy, they looked at me blankly and said no, I didn’t understand – they needed a new policy, just for their department. After a little probing into the governance of their company policy (this enterprise had a single policy covering everything), and some further discussion, we ultimately settled on writing a new procedure and developing accompanying forms and workflows. I ended up helping this department rewrite their documents into the appropriate format, and working with them to better understand the hierarchy.

This got me to reflecting on how many times in my career I’ve heard confusion about policies, standards, procedures, and guidelines. Reasonable people will differ in their definitions, but here’s how I understand them to work best.

This is the second of a two-part look at a “Day in the Life” of a Business Analyst (BA). During the first half of our “day”, the BA met with principal stakeholders multiple times to understand the problem, document the As Is and To Be, and perform a gap analysis between the two that will form the basis for the solution. The BA speculates that this will involve a combination of changes to people, process, and tools but the next step is to list and prioritize what the solution must include. 

I admit it; I waste hours a week playing video games. On my phone, laptop or tablet; on a train, bus or airplane; when I have time and when I don’t, I and millions like me find that the positive feedback from these games keeps us addicted. A silly banner pops up and says “Congratulations, you’re a winner!”, or tells you you’re still lagging behind the champion, and you just have to play again.

Agile. Continuous Improvement. The Virtuous Cycle. It’s true – change is necessary, and we all need to get better at adapting to change at an ever-more rapid pace. The increase in the pace of change in today’s world is exponential.

No one wants to get stuck in analysis-paralysis while the competition moves on without us, and there’s nothing wrong with experimentation and trying new things. However, it does sometime seem that changes are made for the wrong reasons, and not driven by pro-active, intentional movement towards goals. We’ve all seen decisions made without the necessary due diligence, and often those are compounded over and over as companies shoot from the hip, reactively trying to fix (or cover) their original mistake.

This is the third in a series.  The first installment, Building a Process Catalog – The Journey Begins, was published in the April BPM Institute’s online journal.  The second installment, Building  a Process Catalog, The Ongoing Journey, was featured in the August bulletin. 

Recap

My first two features described how I use SIPOC (Supplier, Input, Process, Output, Customer) diagrams to capture some essential characteristics of major business functions. 

Recap

In the last article, I described a project to capture and catalog the major cross-functional processes within a 7-department business unit.  The article provided an example of a modified Supplier, Input, Process, Output, Customer (SIPOC) diagram, discussed the problem statement, and described the steps we took to get buy-in from the Sr. Management of the business unit. 

This time, we’ll explore the modified SIPOC in greater detail to illustrate how it is created, and how it can be used.  We’ll discuss the catalog that is the inventory list of the SIPOC processes that have been diagrammed.