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?

For years, I’ve been telling my federal customers that an IT Strategy is often not very helpful, and that all of an agency’s resources (whether people, processes, technologies, services, or facilities) should be collectively aligned and applied to enable a single enterprise strategy that is driven by mission and business needs – in short, an Enterprise Business Strategy. “Instead of an IT Strategy,”¹

I would go on to say, “What an agency needs is an IT Roadmap.” Despite that advice, which did go against the grain of prevailing government practices, nearly every CIO would persist in his or her efforts to promulgate an IT Strategy – as an emblem or accoutrement of the office they held, it often seemed.

Lean six sigma methodologies focus on removing wasteful activities from processes. However, at times we need process activities that come in handy when the expected process is not followed or are essential for fraud prevention and/or regulation. During my recent trip to India I came across two such examples, which made me think about the importance of compliance, fraud detection and customer centric activities that correct process deviation. While these activities may not further process KPI’s, they are certainly necessary. As in everything, it is all about striking a balance. Add too many such activities and your process may not be “lean”, not having any may lead to issues in other related processes. Let me describe both these examples.

Airport Security:

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.”