Hidden Costs / Hidden Factory

It seems one of the more common refrains within EA is the need to eliminate redundant applications and associated processes.  Every day at work I am reminded of my company’s own redundant applications and wonder why they were allowed to live on.  I’ve decided it must be the cost associated with retaining the legacy version(s) simply cannot be seen; they are too well hidden.  It’s these hidden costs that I want to explore more deeply, with the hope that I can create a sharper message for eliminating redundant applications up front before it’s too late.

Gartner’s IT Glossary (n.d.) defines total cost of ownership as a comprehensive assessment of IT or other costs across enterprise boundaries over time. For IT, this includes:

• Hardware and software acquisition (hard cost)
• End-user licenses (hard cost)
• Management and support (partial allocation)
• Communications (partial allocation)
• Opportunity cost of downtime, training and other productivity losses.

The hard costs are easy to determine and should encompass licenses and initial setup, data migration and the like.   The allocations are harder to calculate but still relatively easy.  The opportunity costs are the hardest to calculate, and many organizations may not even try.  However, when forced, some reasonably defendable calculation can probably be devised.  These costs are all visible costs, although it could be argued that the opportunity costs are somewhat hidden because of how difficult they can be to calculate.

Naturally, redundant applications have visible costs and hidden costs.  The visible costs will frequently drive decision making, and, to be a bit cynical, since so many businesses seem to have redundant applications, the visible costs must not be compelling or painful enough to motivate businesses to get rid of them up front.  The decisions to get rid of redundant applications seem to come after years of painful experience.  Maybe if we can understand the hidden costs better, we can change the decision-making dynamic.

Redundant systems require training that is more complicated, longer, and harder for staff to learn, and it requires operational staff that can handle the same processes two different ways (I say the same processes, because the inputs and outputs are the same, it’s just that everything in the middle is different).

This leads to productivity issues, which, if we were so motivated, could probably be quantified.  However, where things really break down and the hidden costs soar, is with the resulting quality issues.  The Lean Six Sigma (LSS) world defines the hidden costs associated with quality issues as the “Hidden Factory”, describing these hidden costs as overhead which is smoothed over or thrown together with other costs, making the cost of the quality defects difficult to identify (SixSigmaTutorial.com, 2011).

These hidden costs still don’t have much meaning or definition to them, so I’ll try to address that based on my observations.  When quality becomes a problem, the following bullets start to frequently repeat themselves.

• Large amounts of time are spent addressing customer complaints (and some customers are lost).
• Large amounts of time are spent writing internal emails describing what happened and why.
• Numerous meetings (from executives on down) are held to discuss why quality is suffering.
• Tasks forces are established to identify the most acute quality problems.  These meetings are often notoriously unproductive and involve raised voices and lots of finger pointing.
• Teams of subject-matter experts are assembled to analyze what it will take to retire one of the redundant systems.  They will likely conclude that they do not have the time, so the downward cycle continues.
• In addition to the external, customer-oriented quality issues, there are numerous internal quality issues which also lead to time-eating emails, investigations, meetings, and improvement initiatives.
• Inaccurate management reporting due to the multiple systems.
• Greater likelihood of IT support failures which will lead to Operations not being able to get their work completed on time, overtime, upset employees, and hurried work that will likely lead to more customer quality issues.
• Finance has redundant invoicing processes, making it tough to keep the books balanced, which requires them to spend a lot of time with IT and Operations conducting investigations into what work was actually completed.

All of the above fit the definition of hidden costs or the LSS term of “Hidden Factory”. Naturally, these costs are never part of the up-front decision to retain a redundant application.  There are methods for measuring the hidden costs associated with quality problems, which I hope to explore in a future posting.  For now, I hope EA teams can start to craft a sharper message, urgently warning of the hidden costs/factory up front, rather than relying on years of painful experiences to force a decision to eliminate the redundancy.

References

Gartner. (n.d.). Gartner IT Glossary. Retrieved from http://www.gartner.com/it-glossary/total-cost-of-ownership-tco

SixSigmaTutorial.com. (2011). What are Hidden Factory, Cost of Quality? Retrieved from http://sixsigmatutorial.com/hidden-factory-the-two-types-of-cost-of-quality-visible-and-hidden/113/

It’s Not All About Technology - Part 2

In my previous blog posting, I wrote about how EA focuses too much on technology despite all the guidance that tells us EA should not be IT-centric.  This week I’m going to continue with that theme, having been motivated by Gartner’s article entitled “Making Technology Standards Work” (Gartner, 2006).  I want to use this article as further evidence that EA is too technology and IT-centric.

It this article, Gartner acknowledges a frequent complaint heard from the world of EA is that enterprise technology standards are resisted and often not adhered to.   I have heard this many times in my career and have also lived it while working at GM, where enormous energy was spent on defending technology standards.   What concerned me about the article is the focus on technology standards when the loudest complaints from EA should sound more like:

• Why can’t we get different business units to cooperate on standardizing business functions?
• Why can’t we eliminate multiple points-of-entry for critical data?
• Why can’t we eliminate redundant end-user applications?  

These kinds of questions pertain to business complexity, which I contend is more significant than technology complexity.  When distinguishing technology complexity from business complexity, I believe that end-user applications represent business complexity, while the architectural building blocks of the end-user applications represent technology complexity.

• Technology complexity is caused by excessive or non-standard building blocks pertaining to infrastructure hardware/software, not end-user applications.  This leads to more complex support requirements, which leads to a higher cost of ownership.

• Business complexity is caused by many factors from the number of products or services offered to customers to redundant business functions, which is often caused by redundant end-user applications.

Consider two scenarios:

1. A project team wants one or two deviations on the enterprise technology standards (e.g. they want/need to use MySQL instead of the enterprise standard database which is Oracle) but is diligently engaging other business units to make sure that certain business functions are commonized on the same software and data.  
   
2. A project team is fully compliant on technology standards but claims it cannot find the time to engage with other business units (as they will miss their deadlines) to ensure certain business functions are standardized on new software.

I would hope most of us find the latter to be of greater concern than the former.  To reinforce this point, the consulting firm McKinsey & Company (n.d.) surveyed both executives and employees (two to three level down), asking their perspective on their company’s complexity.  The executives focused responses on the scale and scope of the company, the design of their organization, and new legislation.  Employees talked about unclear reporting lines, hazily defined accountabilities, and inefficient internal processes.  Technology did not come up, which isn’t a surprise because IT people were not the focus of the survey.  Unless IT people are the ones being surveyed, technology complexity will likely go unmentioned, which is my point.  EA should simply be careful to show appropriate concern for the complexities that matter to the business.

It is, of course, necessary for EA to promote, support, and defend technology standards.  When a project team requests a deviation, it increases the enterprise’s technology complexity which must be scrutinized.  My only concern is with EA teams being IT-centric and thinking their mission is to focus on technology standards when business complexity is more harmful to the enterprise.  It is business complexity that should be the ultimate focus of an EA team and the target of our loudest complaints.

References

Gartner. (2006). Making Technology Standards Work.  Retrieved March 15, 2016, from Penn State’s EA-872 class materials.

McKinsey. (n.d.). How do I the complexity in my organization?  Retrieved from http://www.mckinsey.com/~/media/mckinsey/industries/chemicals/our%20insights/organizing%20to%20enable%20the%20shift%20from%20volume%20to%20value/how_do_i_manage_complexity_in_my_organization.ashx

It’s Not All About Technology

I came across a common EA definition using the “city planning” metaphor, which caught my attention.  Here is the definition, as offered by Anna Mar (2011):

An Enterprise Architect is like a city planner. A city planner sets building codes and plans common services such as roads and water. Enterprise Architects do the same thing for technology.

I’ve seen this analogy before, but in this instance, it was the last sentence that caught my attention, where the claim is made that Enterprise Architects do the same thing as city planners, just with technology.  The focus on technology seems a bit off target.  In the book, Enterprise Architecture Good Practices Guide (Schekkerman, 2008, p. 31) we learned that the major elements of an enterprise are people, processes, business, and technology, so it seems like an oversight, ignoring people, processes, and business in an EA definition.  Yet another example of how EA is limited to technology out of convenience (I think it makes it easier to define) and out of custom, as it seems most EA practitioners have technology backgrounds.

In our EA872 class sessions, people have commented on how EA at their company is IT-driven, run by the CIO, and seems more like a technology planning committee, which we, as students of EA, have been cautioned against.  

Would it not make sense for an EA team that is functioning in the true spirit of the enterprise to be as involved with non-technology change as it is with technology change?  For example, my current employer recently decided to move the back-office operations of a subsidiary business from the subsidiary’s headquarters in Virginia to the enterprise’s headquarters in Michigan.  This was a big change, definitely a change to the enterprise’s “architecture”, and yet there was no technology component to the change.  The subsidiary company uses their own systems, with their own processes, and that didn’t change.  This particular form of change was strictly about people and how to optimize staff at the different subsidiaries who perform similar functions.  

I hope it’s realistic for EA to take the lead in identifying and championing non-technology change.  The following 2013 article from InfoWorld titled Enterprise architecture shows its business value, briefly describes four EA success stories.  Three of them are clearly all about technology, but the one from The National Bank of Abu Dhabi actually sounds like a success story that isn’t all about technology - I hope I can find more of these stories over time.

References

Knorr, Eric. (2013). Enterprise architecture shows its business value. InfoWorld. Retrieved from http://www.infoworld.com/article/2612515/enterprise-architecture/enterprise-architecture-shows-its-business-value.html

Mar, Anna. (2011). How to Explain Enterprise Architecture To Your Grandmother. Retrieved from http://simplicable.com/new/how-to-explain-enterprise-architecture-to-your-grandmother

Schekkerman, Jaap. (2008). Enterprise Architecture Good Practices Guide. Trafford Publishing.

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