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. 

In my previous article “Business Politics before Projects Success: The Games Executives Play,” I propounded a view which stated that  a Business Process Reengineering (BPR) project’s success or failure is highly influenced by a project having multiple accountable executives driving decisions on a project. In this article I will expand on this view by focussing on the concept of Organisation Structures and their influential impact on the BPR project domain.

Many definitions of Organisation Structures exist from various sources, however for the purposes of this article I will summarise and reconstruct the definition as follows:

“Organisation Structure refers to the lines of authority that articulate the controlling of decisions taken and the distribution of type of work performed based on the core purpose and strategic intent of the organisation.”

Eliyahu M. Goldratt (1947-2011), an Israeli physicist turned business guru, established a highly esteemed reputation in business planning, through a series of three novels.

The use of novels to explain business and scientific matters was quite original for the time.  The novels were “The Goal” (1984), “Theory of Constraints” (1990), and “Critical Chain” (1997).

Each explored aspects of his theories. His books were among the most controversial and thought-provoking of the closing decades of the 20^th Century.  They also affected Project Management strongly, through his “Critical Chain” thinking.

Business Analysts provide a critical role in organizations.  In fact, without this role, Business Owners and Developers must work together on a software project, which can be frustrating to both sides.  Indeed, Business Owners may not get what they want and Developers may spend time building functionality that was not needed.  OUCH!   Why is that?  Because the Business Owners and Developers have not learned to communicate to their mutual benefit.  Enter the Business Analyst whose role is to define the needs and recommend solutions that deliver value to the stakeholders (e.g., Business Owners, users, customers, etc.)

According to the International Institute of Business Analysis (IIBA) BA’s do the following 

We live in a process powered world and the only thing the customer is interested in is WIFM (What’s in-it for me?). Customers are tired of hearing phrases such as “customer centric” and “world class” and “service oriented”. If your process outcomes are not aligned to the customer’s goals and you do not provide an excellent service (note: not a superior product) – guess what?

How does this affect Enterprise Architecture?

If an organisation doesn’t change its way of developing products for more than 40 years, do we expect that organisation to stay in business for very much longer?