Gumming up the Works
I have been working in both Business and Digital Transformation and it has become apparent that there is an often underappreciated underlying issue that is stopping many people from really delivering the level of improvement that they could. This issue is complexity!
Think about it. Complexity is at least part of the root cause of most major operating problems. While some complexity is removed by workflow or process streamlining, the real problem lies deeper than workflow. At a fundamental level, ask yourself what really stops companies from changing their business operations and their IT application support quickly? Yes, resources and funding are always issues. But whether you have sufficient staff and budget or not, you still have to deal with improving or transforming the business operation. Also, even if you apply Lean and streamline the work, you still have the complexity that underlies the work that is left and really guides the operation.
My purpose in this column is to help readers consider this issue and how addressing it can, over time, bring substantial improvement in the way the company functions. The problem is that complexity is increasing rapidly and its impact is being felt in higher cost, lower productivity, lower quality, and numerous other ways. If companies are to compete, they must be nimble. But even streamlined new operational designs and progressive moves like adding new technology or going paperless can increase complexity in our hyper connected business operations. To prepare for the future, I believe that this issue of complexity must be addressed. I also believe that this is a serious detriment to operating in the rapidly changing global market.
Complexity is something that managers and staff are all too familiar with. They may not know where it really comes from, but they clearly know when it is there and they clearly will tell you it is increasing.
When we look, we find it everywhere in a business operation – no group is spared. Complexity is built into the way work must be performed – the rules, procedures, policies, approval requirements, and the way decisions, work steps, and calculations are performed. It lives in trying to set a rule for every possible situation and in the procedure and policy manuals that have years of changes stuffed into binders – that no one reads or can really use because of the conflicts between different notes, memos, etc. And, it lives in tribal knowledge that has built up over time. These are the things that determine complexity. If you streamline a workflow or at a higher level, a process, you can eliminate activities or tasks, but if you don’t deal with the complexity of decisions, levels of approval, rules that govern steps, or the policies that dictate how the laws will be complied with, you will not have simplified the work.
Streamlining vs Simplification
Improvement and transformation teams typically try to streamline workflow and apply Lean to eliminate unneeded work – deleting tasks and reducing cycle time. This focuses on what is done and why – the activities and tasks and the contributions each makes in creating a product or service and thus its value. This helps to eliminate unneeded “non-value add” activity from the workflow and cuts cost. This is also true at the process level. However, when the team looks at how work is done in each activity, it is easy to find complexity - adding time and cost to the operation.
As noted above, streamlining is really related to eliminating work steps or activities. It deals with what must be done to deliver a service or product. While this does some operational simplification, and it can deal with human/IT application simplification, it does not usually go deep into the “how’s” that guide the work and control governance and performance.
Dealing with Complexity
Complexity is everywhere. You can find it in policies, procedures, rules, decisions, approvals, and you can find it in the ever increasing difficulty in the skills needed to interact with the company’s technology. It is incorporated into those things that govern work, but are seldom checked. For example, is there anyone who has an inventory of all the policies in the company? Does anyone know what parts of the business each policy applies to? Are the policies still relevant? Are they clear – does anyone understand them? Is interpretation a problem? Do policies try to cover all possible conditions? Do they conflict? Are some redundant? Do they still have a reason to exist? Are they really applied as intended? The list of questions goes on and applies equally to procedures, rules, decision trees, and approval hierarchies’ data integrity.
The bottom line can be summed up in the question “Is the complexity these things cause really needed?”
The fact is that any new business change will likely add to the operation’s complexity through new interpretations of policies and rules and new work around tasks. IT support changes will also, at a minimum, add to application program and application interface complexity along with human interaction complexity. Data content, data flow/transform/integrity issues are also impacted by all changes in IT operations – often in unpredictable ways. So, the “catch 22” is that while you are improving the operation you may be adding to its operational complexity. That is why increasing complexity often goes unnoticed until it becomes a burden.
Addressing these types of issues is really what reengineering is all about – eliminating unneeded work, then reducing complexity, and finally streamlining what is left while eliminating problems and error. But to reengineer, you must be open to going beyond improvement and you must question everything that is being done, why it is done, and the policies/rules/procedures that control how it is done before any change is in its final design.
So, what can be done to address this issue? The first thing that must be understood is that this problem is natural and results from needed continuous change in the business operation, and a reluctance to challenge operational governance and controls. For IT, this complexity is in its infrastructure, its operations, and in the way data is handled in the unending changes to applications – instead of rewriting or replacing them. The fact is that applications can only be changed so much before they become overly complex and in some cases so complex that the outcome of another change cannot be predicted. That is the infamous IT ripple effect. And at a broader level, as new IT applications are added by cobbling them into the application mix with interfaces, the overall complexity of an IT application portfolio increases – along with the time it takes to make further changes. Correcting this situation within IT is the real promise of Digital Transformation.
For these reasons, complexity will continuously creep back into any business. However, if finding and eliminating it is a priority, it can be built into all projects and controlled. It can also be the reason for a periodic complexity analysis – with recommended actions.
Declaring War on Complexity
I think that the first step in dealing with this issue should, like most significant issues, be to obtain a commitment at all levels in the company. The implication in this commitment is the approval to challenge all historic presidencies and all policies, procedures, rules, decision trees, and approval levels. Really anything that slows work down is a candidate for scrutiny.
Because this should be a goal in all projects, the elimination of complexity should also be part of any project’s success evaluation. This will require that simplification activities be built into any business or IT project methodology in the company. This installs the goal into the project fabric of the company and encourages all managers and project leaders to pay close attention to it.
I also suggest that the design teams consider focusing on the commonly performed work and leave the seldom encountered situations alone – there is simply not much to gain in addressing infrequently encountered activity in this type of project. Let more highly skilled staff make decisions on infrequently encountered events based on the facts of the situation. If necessary, these seldom encountered situations can be addressed in a later project.
All IT related complexities the team finds in the work support should also be noted and discussed with the IT collaborative team members. Things that can be done within the constraints of the IT infrastructure/capabilities to simplify the work in any activity should be noted for inclusion in the IT requirements for the solution. This will help align and simplify the business and IT sides of the solution.
A collaborative, supportable identification of the impact of the complexity in terms of cost, quality, cycle time, staffing, error, etc., can now be created as a baseline for evaluating the benefit of any removal.
The Impact on IT is Even Greater than the Impact on the Business Operation
IT today carries around the result of 50 years of continuous change to the infrastructure, additions to the applications portfolio, and changes to the “legacy” applications. The cobbling in of new computers and applications, the addition of new operating systems, the constant changes to the operating systems and the technical software tools that keep everything running, and the implementation of new technical tools all have had their impact and have added to complexity.
The latest round of changes is driven by cloud storage, application generation, and the social mobility app revolution. The problem in many companies’ IT operations is that there is no formal comprehensive, integrated technology, application architecture that everything must fit within. For many IT groups, the lack of this comprehensive IT environment architecture is itself the result of evolution – the original architectures have changed to the point where the models are obsolete. What has been retained is that all new hardware and software must be capable of fitting (with custom modification) into the general IT operating environment. The result is that the computers and other hardware work through a very complex set of interfaces that connect everything together and allow it to work. On the application side, communication between applications is through equally complex interfaces. While attempts using Application Program Interfaces and Service Oriented Architecture techniques (API’s and SOA) have been made to simplify these interfaces, they largely remain extremely complicated.
The addition or deletion of different hardware and technical software is thus not an easy task. In many companies, the addition/deletion/change of applications is even more difficult with chancy results.
The use of ERP and CRM integrated packages has helped, but has not eliminated this complexity. While these large packaged application groups have simplified IT application interfaces, they have required that the business activities change around the application package capabilities. While this has not really been a significant issue with accounting, HR, and other core applications that do not provide competitive advantage, it can be an issue in systems that deliver capabilities that differentiate the company.
BPMS tools and the applications that they generate have the potential to eventually simplify the business operation and change, but they have not yet often been used to look at entire processes and generate all of the supporting applications (including social mobility applications) that are needed by the process. Using a BPMS, all the applications, all the business models, rules, etc., are available for reuse in other processes and for iteration as the business needs for the process change. This, if set up properly, can reduce IT complexity. However, the business solution’s designs can still be as complex as what they replace, if complexity reduction is not a strategic imperative in all projects and all BPMS solutions.
To really take simplification as far as possible, all efforts to simplify, should address both the business and IT sides of any solution. Complexity is everywhere – once you start to look for it. The goal of weeding out as much complexity as possible should be pervasive in the approach taken by the improvement or transformation teams.
The solution for controlling the evolving operational and IT complexity issues seem to center on challenging the policies, rules, procedures, decision models, ways to deal with issues, and the inclusion of simplification in all change. I do however, think that simplification needs to be a core requirement in all projects and anything that can drive complexity must be challenged.
While this is true in business activity, it is even more important in IT where interfaced applications and data issues have become real problems.
I urge my readers to check out my new book, “The Business Transformation Field Guide”, published through Whit-Kiffer Press and available on Amazon Books. The reviews are great and I am certain you will find the 800 plus experience based best practice “hints” of value in helping CI, process improvement, and business transformation projects succeed.
I would also like to announce that I am leading a two-day workshop at the PEX Network's OPEX conference in Orlando in January 2017. The workshop will serve a dual purpose – it will help bring practitioners to a Business Process Architect level and it will prepare attendees to take the Association of Business Process Management Professional’s Certified Business Process Professional® (CBPP®) exam. This is a Business Process Architect level certification from the largest professional BPM association.
I hope that you enjoyed the column. I am, of course, always eager to hear from you. Please call me at 630-290-4858 or email me at email@example.com .