Archive

Archive for September, 2012

Use Lean to Ease the Pain of Enterprise Software Implementations

September 27th, 2012 2 comments

Use Lean before enterprise software implementationsLarge scale enterprise software implementations … ERP, CRM, BI, BPM, Ware house management, transportation management, talent management, learning management ….. What do they all typically have in common?

I routinely speak with 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 increased cost for 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. Sometimes we seem to for get that it’s the business processes that serve customers and produce revenue, 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 ….

Feel free to contact me if you’d like to discuss. I’d love to hear your insights and ideas.

Lean In IT ? – Surely you Jest ….

September 25th, 2012 4 comments

Lean in ITRepeat after me … Lean is not just for manufacturing … Lean is not just for manufacturing …..  Fire up your browser and just ask Google.  It will enlighten you with many, many examples of  Lean making a big impact on service organizations … reducing costs, making things faster, making things just better.  You’ll find it in healthcare, government services, financial services, logistics,  and one that is near and dear to everyone’s heart ….. IT.  Yes, I said the I-word …

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.  A good way to look at how Lean applies is to 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 InventoryServer sprawl, under-utilized hardware, software installed that no one uses, development and test teams benched, waiting for their next assignment

Waste of Underutilized TalentFailure 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.

Download Lean Services

a short Powerpoint that discusses Lean in a services environment

OK, do can we agree that some (or all) of the above wastes happen in the typical IT department?  I thought so.  And, if Lean thinking and tools can help you reduce these and other wastes???   They can.

So, I think it’s pretty clear that there are many opportunities to use Lean to help IT organizations better serve their customers (i.e. the business), and 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.   There are some really interesting trends like SOA and BigData that I’ll talk about in future articles that make Lean even more applicable.

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

Define Before You Design …

September 20th, 2012 Comments off

Voice of the Customer (VOC) problemI get a kick out of solving a problem. The more complicated the more of a thrill.  I feel like a Master of the Universe when I solve a problem which has befuddled others.  I get this thrill in work and at home.  We all love being great problem solvers.  And our entire educational system is geared to solving problems.  We have problem sets in the back of every math chapter.  We are given problems to solve in every test in every subject.

But there is a problem with being taught to solve problems – the problems are defined and that is rarely the case in real life.  In real life, all we really have is a mess and the first step is to DEFINE the problem.  And nowhere is this truer than when trying to figure out why customers aren’t buying your product or service.  Or when you want to launch a new product or service for which you are being judged by customers’ acceptance.

The fact is that the first step in defining Voice of the Customer (VOC) is to define the problem.  And so there are three steps we must follow to properly capture VOC.

First, ask yourself “Who”.  I was recently working with a client and we were sifting through a pile of “customer” feedback.  Much of the feedback contradicted itself.  We were forced to take a step back and ask ourselves who has the problem we want to solve?  We needed to separate indirect from direct voices. We needed to separate primary from secondary customers.  We needed to focus on who was the customer we were trying to please and excite.

The next action was to ask ourselves “What”.  The key is to ensure the What is viewed from the customers point of view!  We can’t look at a customer and say “this is their problem”.  Start there and you are doomed to failure.

Once you know who has a problem and what that problem is, determine Importance.  Resources are finite. Fix the problems about which customers care and to which they react. The key is action.  And if a customer can’t or won’t tell you priority, focus on what actions are taking place.  How actively are they looking for a solution either internally or externally is certainly an indicator of priority?

Download VOC QFD

a short QFD overview .ppt

Now we can talk a lot about tools such as Segmentation, Pugh Matrices, Houses of Quality and QFD. But at its core, any attempt to identify and address VOC with Designed Solutions will always come back to these three steps – Who do we care about…What is their problem…and How Important is it to them.

I Hear Voices! … Tips for Turning VOC into Good Design

September 13th, 2012 4 comments

voice of the customer - VOCSo often when we have product, service, process, or system failures, we find that the root cause is a lack of connection to what the customer really cares about …. Voice of the Customer (VOC).  Everyone sees the disconnect, agrees it is the problem, and now sets about obtaining VOC.  Now, things really get complicated for when you seek VOC you discover many voices struggling to be heard.  The challenge becomes to sift through all those competing voices and understand which are critical and what they are saying before trying to convert what you’re hearing into a design or redesign.

So, in an effort to help sort through all of this, there are some simple but very important concepts that can be used to put some structure around all those voices you hear when you set about gathering VOC and converting that information for use in design.

  • Direct v. Indirect – When gathering customer information within your organization, make sure you distinguish between direct and indirect voices.  A direct voice is feedback coming from the end customer.  Indirect voices are the customer facing parts of your organization that theoretically act as a proxy for the external end customer.  Indirect voices are important as they represent can provide meaning to what you hear from the external end customer.  BUT, they are not the end customer voice.  Both direct and indirect are important, and are very different.
  • Customer Requirements v. Product Requirements – Recognize when you are hearing a customer requirement or a product requirement.  A customer requirement is usually framed within the context of what the customer experiences while a product requirement is usually a key function or feature of the product.  I want a comfortable ride on my bicycle is a customer requirement.  I want a big soft seat is a product requirement – even if it’s direct feedback from the customer.  When a customer gives you a product requirement, you must ask “WHY?” before designating it as a desirable product requirement to be used in designing a solution.
  • Qualitative v. Quantitative – Qualitative feedback is rich but expensive to get so it is normally provided from a smaller customer base.  Quantitative feedback can be easily obtained from a large population at a significantly lower cost but it is far less descriptive. The answer is not to solely rely on one or the other.  Use interviews to define your survey or your survey to define your script and interview population.  Go back and forth taking advantage of the deep aspects of one and the breadth of the other.
  • Segmentation – Always segment but segment in whatever way is meaningful to your product, service, process or system.  As an example, in designing an internal software application many designers look at the functional departments that are going to use the system.  But you may find it more meaningful to segment according to the type of usage irrespective of functional area.
  • Basic v. Performance v. Excitement – Applying the concepts of the Kano model are invaluable.  You must know what are basic, performance and excitement levels and their marginal returns as they all would receive different priorities depending on your objectives.   The nature of the requirement  becomes especially useful when you sort it by demographic or customer segment.

Download VOC QFD

 a short intro to QFD and how it can be used to create linkage between customer and technical requirements.

After you have sorted, ranked and prioritized your assembled customer information, it is time to compare and rank product characteristics relative to the customer information.  This can be done in a planning matrix (see downloadable PowerPoint document).   The planning matrix can then be used to develop design alternatives. The design alternatives can be ranked and rated against both the product requirements to determine process and production feasibility and versus the customer requirements to determine impact to the customer. The two exercises can then be brought together to choose a design which factors in the value, cost, and feasibility of solutions.

It is incredibly valuable to have VOC information.  It is even more valuable if you understood how you got it and how you plan on using it.  Knowing the end game can also help you determine how you want to gather information and make it an efficient process.  The key is to gather, convert, analyze and use the information in the right way.  Otherwise, whatever you invest in getting VOC will go to waste and you’ll be right back where you started wondering how a newly launched product, service, process, or system, once again, missed the mark.  If you wish to discuss this article or any of its point, please feel free to contact me at jlopezona@ssqi.com.

Voice of the Customer for Service Design – Are you Getting It … Really?

September 6th, 2012 1 comment

We have just finished working with a large international services company which has had challenges rolling out new services.  The most difficult aspect of their business was in discovering the real customer requirements, and converting those requirements into service requirements and, ultimately, a service design.  Like many service companies, they just have an immature process for this.

rorschach_inkblotThe service design team is essentially the sales team. They get multiple voices from many parts of both their organization and the client.  It is literally a cacophony of noise which, when converted to a service, the service process map looks like a Rorschach image.  It is then “launched” for the bugs to be worked out as the service is being delivered.  The rework is expensive, taxes the company’s employees, and rarely produces a happy customer.

To help them, we built a Voice of the Customer (VOC) Maturity Model with laddered capabilities for them to climb. That model was built on some basic premises and observations after working with service companies for many, many engagements over the course of my entire career.  Let me lay these out to you so you understand our final recommendation to any service company struggling with the same problem.

Download VOC Maturity Model

 a short Powerpoint presentation that describes a 5-stage Voice of the Customer (VOC) Maturity Model

First, there are two aspects to VOC – getting it and using it. They are very different.  And there are two basic ways to Get VOC: 1) directly from the customer,  and 2) indirectly from all your company’s customer facing team members.

Our experience has been that companies are better at using what information they have than in getting good information. Further, that what they do to get the information often relies on customer facing team members as surrogates for the customer.    One thing is for sure, while only a small fraction of companies that use it well get it well, almost none of them that manage the information get good information. Why?

I think this is true because after crashing a few launches, companies suffer enough pain to cause them to start gathering information.  Then as they develop the disciplines in using it, they discover it isn’t very good and they need better information.  So until they try to use it, they don’t start improving the quality of the information gathered.  Just as an aside, along with discovering they aren’t getting good information, they often discover they aren’t getting the right information as the system focuses on product specifications rather than customer requirements. So the learning curve goes from we need information to …. we need good information to …. we need the right information.

As a company goes through this discovery process, they have to overcome some assumptions that are being taken as truths, and are really holding them back from progressing.  Why does this happen?

  1. The assumption that customers don’t really know what they need.
  2. Information is gathered once at the beginning by simply asking customers what they want.
  3. They only gather information from surrogates.
  4. They only gathering information from their best relationships (often happy customers).

These are the traps that get you stuck in bad information and more rework. To overcome these traps, information must be gathered both directly and indirectly. The information gathered must be prospective and from a broad population.  And gathering and incorporating information must be continuous, NOT a one-time event.

Needless to say, the process isn’t easy and requires a significant effort.  But the payoff is a multiple of the effort.  There is no doubt that companies that have structured processes for gathering and converting customer information outperform companies that don’t, regardless of whether they do it well or not.  Working with a plan, even if not perfect, outperforms no plan.  And needless to say, if your plan and execution are done well, then your company performs even better.

Take a look at the summary presentation of what we recommended.  If you have any experiences, comments or questions you’d like to share, let me know at jlopezona@ssqi.com.  And by the way, while this is all written based upon an experience with a B2B service organization, it is equally applicable to internal processes such as a Shared Services organization providing a service to operating units.