Qualtec's Business Performance Improvement Blog

Last week I published a short article titled What about Lean in a Services Environment?.  It made the case for Lean’s applicability in a non-manufacturing environment.  My goal with that article was to dispel notions that Lean is a manufacturing paradigm.  Building on that, I thought I would talk about a specific services process, and what better place to look than IT ….

Our Lean QuickStart Presentation here.

Remember, Lean is first and foremost about the elimination of waste, and I would argue that there is plenty of waste in IT, hence there is applicability for Lean in IT.   To take things further, since IT is supporting the broader business needs, waste in IT can be magnified into bigger waste (and bigger problems) as it filters through the business.  Let’s look at the elements of waste and make the connection to IT ….

Waste of Defects.  Systems not meeting requirements, software bugs, missed deadlines, blown budgets, etc.  This clearly adds cost to IT, but I would argue that the impact to the business can be even larger in terms of $’s.  Incorrect handling of a single customer transaction can cost the business big in terms of cost, lost revenue, and potentially attrition.

Waste of Overproduction.  Here, overproduction means simply doing things that don’t need to be done, like working on low-impact squeaky wheel projects that really don’t provide value to the business.  This is the classic IT Alignment with the Business problem that has been talked about for years and years.  The cost to the broader business is that strategic projects offer real value don’t get worked.

Waste of Waiting.  Test teams waiting for the next load that’s running behind, development teams waiting for test results, waiting for new hardware, waiting for software upgrades and patches, etc.    But, again, the business impact can be bigger.  Think about slow application response times, inefficient problem escalation process, missed deadlines delaying product launches, etc.

Waste of Overprocessing (non-value add processing).  A good example here is IT keeping track of excessive amounts of technology metrics, and then reporting those metrics to business managers.  Again, the old business / IT alignment demon rears its head.

Waste of Transportation. On site visits to correct hardware/software issues, physical security, compliance, or software audits, vendor visits for equipment that might not really be needed, etc.  

Waste of Excess Motion. Firefighting creates excess motion, and I think it’s safe to say that firefighting is a way of life for many IT organizations and a productivity killer.

Waste of Excess Inventory.  Server sprawl, under-utilized hardware, software installed that no one uses, development and test teams benched, waiting for their next assignment

Waste of Underutilized Talent.  Failure to encourage and capture new ideas for innovation, retention issues, high-value employees used for mundane tasks that really require a much lower skill level, or possibly even automation (i.e. regression testing).   And I’ll add one more here … build vs. buy.  What is the impact when IT leverages its resources to build something inhouse, when a better and cheaper solution could have been bought?  This negatively impacts IT and the business heavily.

I think it’s pretty clear that there are many opportunities to use Lean to remove waste in IT organizations, lower IT costs and resource requirements.  I also believe that, due to most businesses’ increasing dependence on IT, the bigger value to improvements will likely be realized by the business, through smoother operations, better resource utilization, and happier customers and employees.   

Think about it and Contact me if you’d like to discuss how lean can be applied to IT organizations in more detail.

Everyone knows that Lean came from the manufacturing world, and many aren’t quite sure how, or even IF, it applies to more service oriented environments. Well, rest assured, it does.  I see countless examples of Lean success stories in a broad range of services/transactional domains. Financial close, claims processing, call centers, software development, enterprise software implementations, patient waiting times, logistics and supply chain, order fulfillment  …. The list goes on and on.

Our Lean QuickStart Presentation here.

Granted, adoption of Lean in services environments has been a little slow, but adoption is happening now at a rapid pace.  Why?  It could just be the natural progression of things, but I think it’s also a function of the business environment since the recession.  Internal efficiency and productivity, doing more with less, and cutting costs are now just the way business is done, the new norm …. And that, my friends, is what Lean is all about. 

Lean first and foremost is about the elimination of waste, and it defines 7 ( or 8 ) elements of waste. Any activity that doesn’t add value, from the customer’s perspective (internal or external), is by definition non-value-add and should be minimized (or eliminated).   Now, think about this … some very reputable research suggests that, in a typical services process, 80% of the activities are non-value add. 

Yet, all those NVA activities add time and cost, and opportunities for errors to the process. In the case of most back-office processes (e.g. Finance, Customer Service, HR, IT, supply chain, etc), any saving in cycle time / cost filter straight to the bottom line.  

80% NVA activities, savings straight to the bottom line … That tells me that there is ample room and opportunity for Lean in Service-oriented processes.      Think about it and contact me if you’d like to discuss in more detail.

In just the last couple of weeks, I’ve spoken with several managers who have been tasked with implementing or supporting the implementation of large-scale enterprise software solutions. All raise a similar set of frustrations:

• There are a LOT of options, all very different. I just don’t know which is right for us …

• It’s taking much longer than we thought to do this and negatively impacting our business …

• Integration and customization costs are out of control and way over budget …

• We have the system installed and up, but can’t get people to use it …

• We’re different. We just don’t do things in a standard way and no system seems to be able to handle our requirements. Guess we’ll have to build internally …

Coincidence that I keep hearing the same comments? I think not. From my experience, this is absolutely the rule, not the exception. Now,  the question is why does this consistently happen?

I think it’s simply a matter of putting the cart before the horse. So often, technology is looked at as a silver bullet to solve business problems when, in reality, the problem is one of process and not product (i.e. technology solution).  Let’s put this into
perspective … technology solutions should sit on top of good business processes and ideally enable those processes to function better, faster, and cheaper. But,what happens when you try to overlay an ill-defined or just plain bad business process with a technology solution? You guessed it … experiences like those outlined above.

I think some very focused process characterization and Lean work on the front-end of system decisions and implementations could alleviate a lot of the frustration, if people would just take the time to do it. Some things to think about ….

• Start with top level enterprise metrics and a high level value-stream. Identify the key value adding processes, their associated owners, and the metrics those owners manage to. This will help identify critical stakeholders and to crystallize the reporting that is really required

• Start breaking down those top-level processes and characterizing across all operations. Are all operations doing things the same way, measuring the same things, etc? Most likely, they are not. Where differences exist, work collaboratively to identify best practices and consolidate to a best-of-breed process.

• Look for unnecessary complexity, waste and defect-producing aspects of processes. Run focused improvement teams to
  correct. Remove the fat and make processes as LEAN as possible BEFORE trying to systemize. Waste and complexity in processes equals cost in system integration and customization, GUARANTEED.

• Payoff. From steps 1-3 above, a well-defined and actionable set of requirements will be derived AND prioritized. This helps with product selection AND with system integration, customization and testing.  Get it right the first time … what a concept, right?

Of course these actions will take some time on the front-end, but my contention is that the time and expense of doing this process work in front of a system implementation will almost always pay for itself many times over.  Remember, the business processes serve your customers and produce revenue for your company, not the technology you’re trying to implement to supposedly improve those processes.

A little preparation and risk prevention now, or a lot of pain and suffering down the road?         You make the call ….