EA and Lean Six Sigma

I recently became Lean Six Sigma (LSS) White Belt certified through my current employer.  My company’s intention is to white belt certify all employees while continuing with more advanced certifications for management.  The question this raises with me, and a question that has been raised by many others, is how does an LSS initiative align with an EA initiative?

My take is that they are complimentary, but one does not fully embody the other and they both should operate independently.  I think it is extremely healthy for LSS principles to permeate the EA Team and be part of the team’s culture (as it should be for the entire enterprise), however, that doesn’t mean the EA Team can, or should own the application and promotion of LSS throughout the enterprise.

LSS is defined as a set of process improvement tools for reducing waste associated with the flow of materials and information in a process (moresteam.com, n.d.).  Enterprise Architecture, as my EA Foundations I class at Penn State taught me, is defined as the process of translating business vision and strategy in effective enterprise change.  The scope of each is very different; process improvement versus strategic planning.  

Another way of highlighting the distinction is this; LSS is focused on optimizing the current-state, while EA is focused on defining the future-state.  With such different scopes and objectives, it seems clear that they are separate initiatives, and one should not own the other.  With that said, there should certainly be plenty of joint planning, participation, and knowledge sharing.  An LSS initiative will benefit by having knowledge of the future-state and enterprise-level changes that are forthcoming, while EA will benefit from a culture of “lean” and from the business knowledge obtained by LSS process improvement efforts.

One final point.  My posting thus far assumes that there is a central LSS team that is training, mentoring, and leading the charge for process improvements throughout the enterprise.  This may be the typical model for most enterprises when they first adopt LSS, however, it does not have to remain that way.  Once an enterprise matures its LSS capabilities to the point it permeates the entire enterprise and is truly embedded into the culture, it is possible to disband the centralized LSS team.  One of LSS’ strongest proponents, Xerox, recently did just that, as the following excerpt from the Democrat & Chronicle states (Daneman, 2014).  

In a memo to employees earlier this month, president of corporate operations Herve Tessler said that Xerox, having met its goal of “embedding the principles and practices of (Lean Six Sigma) within the business ... we no longer have a need for a centralized LSS function and (will) disband the corporate LSS team.”

My final thoughts on EA and LSS can be summarized by saying that 1) enterprises should embrace both, 2) if LSS is not in place, then EA should encourage the adoption, 3) they are separate initiatives, EA should not try to own LSS, and 4) EA should engage and partner with LSS for knowledge sharing and for, of course, keeping EA’s own processes “lean”.

References

Moresteam.com. (n.d.). Retrieved from https://www.moresteam.com/new-to-lean-six-sigma.cfm#lean

Daneman, Matthew. (2014). Xerox cutting back on Lean Six Sigma program, jobs.  Retrieved from http://safechild.org/categoryparents/preventing-bullying/

Measuring Complexity and Keeping It Simple

I’m about to undertake an initiative at my current place of work to measure complexity throughout the enterprise.  As an SMB, this is actually a realistic undertaking.  In my 18 months on the job, I have frequently lamented the enormous complexity-burden the business has built up over the years.  Every enterprise has more complexity than they would like, however, in over thirty years of experience, I can say that my current enterprise has built up a truly noteworthy and inglorious burden.  

In Chapter 1 of Enterprise Architecture As Strategy (Ross, Weill, & Robertson, 2006), we learned about the importance of building a foundation for execution. Some examples of an enterprise lacking such a foundation are:

1. Different parts of the company give different answers to the same questions.
2. The business lacks agility.
3. IT is consistently a bottleneck.

There were several other examples and all of them accurately describe the current state of my enterprise.  I would even add one more to the list, that being intractable quality issues.  The bottom line is, we need to build our foundation for execution by attacking our complexity.

As I mentioned, I repeatedly lament our complexity problems, however, talk is cheap and it is imperative that I do more to give meaning and substance to the issue, and to make it stick in the minds of the executives.  So, I decided to start by quantifying our complexity, which, admittedly, seems like a complex undertaking that should be doomed to fail due to its own complexity.

To drive home the complexity of assessing complexity, I offer the following text from the Harvard Business Review (Sargut, G., McGrath, Rita, 2011) describing complexity in the modern business and how to assess it.

Three properties determine the complexity of an environment. The first, multiplicity, refers to the number of potentially interacting elements. The second, interdependence, relates to how connected those elements are. The third, diversity, has to do with the degree of their heterogeneity. The greater the multiplicity, interdependence, and diversity, the greater the complexity.

I do not disagree with the theory whatsoever, but I also know that measuring the three properties of complexity are a non-starter - it truly is too complex, at least for me.  It seems then, the critical success factor in measuring complexity is to keep it simple - really simple.  

After a lot of thought and many spreadsheets, it hit me - just count things.  Nearly all problems that burden a workplace can be expressed in the form of a count.  For example, as a law firm, each of our clients (banks) have unique processing requirements that we have a difficult time keeping straight, which in turn leads to quality issues. So, let’s express this problem with a count and consider counting the number of clients with less than five cases per year (these clients add to our complexity without adding much to our revenue).  The bottom line is that a business or IT problem can almost always be expressed as a count.

Eventually, weighting factors will need to be added to show more importance to, say, the number of finance systems in use (a whopping five at my current SMB enterprise) versus something slightly more innocuous, like the number of different database versions we’re running.

A simple four column spreadsheet of 1) the name of the count, 2) the actual count, 3) the weighting factor, and 4) the product of 2 and 3 is what I’ll be using.  By summing up column 4, I’ll get my enterprise’s complexity factor, which, of course, over time we want to drive down.

Some guidelines I’m using for populating my list of counts are:

1. Structure or phrase the count so that simplification is measured by a reduction in the count.
2. Be sure to get the important counts (like the number of unique finance systems) without stressing over the less important counts.  However, when you trip across something, count it.  As an example, when an intranet website was down, I discovered that it was not running on our designated intranet web server.  This adds to our complexity, and even though it’s not a huge deal, it’s still a complexity I’d like to erase, as these small items do add up.
3. Don’t just count IT things, also count business things, such as the number of clients, the number of business units, the number of products, the number of states or countries operating in, the number of facilities, etc.  
4. Don’t avoid counting business things that would be considered negatives if the number went down, such as the number of clients or number of employees.  No matter what, the bigger the number, the greater the complexity, and the goal is to draw attention to the enterprise’s complexity.

This exercise/experiment is full of challenges, such as the subjectivity of the weighting factors, the difficulty of measuring progress if we keep tinkering with the weighting factors, or the difficulty of measure progress if we keep uncovering and adding pre-existing complexities.  

Nevertheless, counting things truly is simple.  It gives an EA Team a metric that can be measured and hopefully evolved into something meaningful and it will help permeate the thinking of the business, leading to decisions that simplify the enterprise, helping to create a foundation for execution.

References

Ross, Jeanne, Weill, Peter, Robertson, David. (2006). Enterprise Architecture As Strategy. Boston, MA: Harvard Business School Press

Sargut, G., McGrath, Rita. (2011, September). Learning to Live with Complexity. Retrieved from
 https://hbr.org/2011/09/learning-to-live-with-complexity

SLAs as an EA Tool

This week I want to write about service level agreements (SLAs) as a tool EA teams should use throughout the enterprise to drive improved performance and measurement.  In Chapter 2 of Enterprise Architecture As Strategy (Ross, Weill, & Robertson, 2006) the importance of defining a company’s operating model, and furthermore, on the integration between processes is stressed.  It is here, with the integration between processes, that SLAs should be applied.  

When operational problems arise at my current employer, it is fairly common for one department to lay blame on the preceding department (in the affected end-to-end business process).  The dispersions sound something like “If Team Xyz would only provide complete and accurate inputs to our team, then we’d be able to do our job properly.”  Ensuing discussions meander and usually devolve into a “venting” session rather than a constructive examination of the business process.

In a similar manner, there’s a catch-phrase we use of “clear to cheer” that is meant as a warning to teams that push for the rapid elimination of a backlog through overtime or incentives (hence the catchphrase, where clearing the backlog leads to cheers).  The reason for the warning is that the backlog problem simply gets passed on to the next department in the process.  We’re passing the problem on instead of solving the reason for the backlog.

The aforementioned are examples of what happens when the handoffs (the inputs and outputs) involved in a process are not formally defined and governed, and that’s where SLAs come in.  

SLAs are extremely common in IT and other service-oriented organizations, but not common at all among the operating departments within an enterprise or business unit.  Every inter-departmental handoff in an end-to-end process should be governed by an SLA, which will give us several benefits:

1. Clear departmental accountability.  Those meandering meetings with lots of “venting” will become more constructive.
2. Goal and objective setting for individuals and teams become easier and more quantitative.  
3. Strategic opportunities become clearer and the ability to analyze the impact of changes becomes easier when input and output requirements are defined.
4. SLAs will highlight the ideal granularity of business process documentation.  We learned about the “burden of knowledge” in “Enterprise Architecture Pitfalls - Current State First?” (Bittler, 2012), where EA teams are cautioned against documenting too much of the current state.  I would certainly characterize the documenting of processes within departments as a “burden of knowledge”, however, documenting processes at the level of each department-to-department hand-off (the SLA level) may be just the right level of process documentation.
5. SLAs give us a set of measurement requirements.  My blog posting from last week addressed designing for ease of measurement.  If our business processes have SLAs in place, then future technology projects can take these requirements and actually design for ease of measurement.

Last week I asserted that EA teams should take the lead in ensuring that enterprise’s design for ease of measurement.  This week, I will assert that EA teams should also take the lead in ensuring SLAs are a requirement for all inter-department processes. This strikes me as an opportunity for EA teams to show how they can positively impact the business and even transform it without always proposing new technology solutions.

References

Ross, Jeanne, Weill, Peter, Robertson, David. (2006). Enterprise Architecture As Strategy. Boston, MA: Harvard Business School Press

Bittler, Scott. (2012, January 31). Enterprise Architecture Pitfalls - Current State First?. Retrieved from Penn State EA-872 class material

Designing for Ease of Measurement

This past week I spent some time thinking about the importance of metrics in an EA program, and more specifically, the importance of metrics that have a strong connection to the business.  When it comes to a successful EA program, I’m more concerned about implementing business-oriented metrics as opposed to the metrics that are more internal to the EA Team, such as refresh cycles, the amount of staff trained, and the number of variances.  The business is going to care a lot more amount cost, quality, revenue, and productivity metrics than internal facing EA metrics.  It’s the business-oriented metrics that will drive engagement and a stronger partnership.

The problem with the business-oriented metrics is with the ability to follow through on them and to actually implement the measurements.  It seems wherever I go in my career, the list of desired business metrics is quite long while the list of business metrics that can easily be implemented and measured is extremely short.  

The reasons are typically the same - it’s the software systems and databases used for day-to-day operations.  They either don’t have the data needed, they have the data in a manner that makes the measurements complicated, difficult, and suspect, or there are multiple systems in use that makes data gathering extremely time-consuming and costly.  These are all problems that can be solved, but when time and cost are considered, the desired measurements get shelved for a more convenient time (which rarely arrives).

When contemplating this reality, I was struck by the notion that software and data structures usually are not designed with ease of measurement in mind (especially for business metrics).  We design for performance, we design for usability, we design for reusability, and we design for ease of maintenance, but I don’t think we design for ease of measurement.  We need to give ease of measurement serious forethought (rather than the typical afterthought) when designing systems and data structures.  

This is a natural area for EA to provide leadership and guidance throughout the neverending journey to the future state. If EA takes the lead on designing for ease of measurement, the business will become more engaged and the partnership between IT and the business will be strengthened.  One final thought from the world of Lean Six Sigma and the book “Making Quality Work: A Leadership Guide for the Results-Driven Manager” (Chang, Labovitz, Rosansky, 1994):

“The World-Class organization is continuously bathed in a stream of integrated data.”

References

Chang, Y.S., Labovitz, George, Rosansky, Victor. (1994). Making Quality Work: A Leadership Guide for the Results-Driven Manager, Oliver Wight Ltd Publishing