Technology Supporting a Process

Have you ever bought technology because it’s cool, whether it be for home or work?  You look at it and think, “Wow!  Cool!  Look at all the features it has and the things it can do.  This will be great!”  Six weeks, six months, six years later you look back and realize you didn’t even use half of it’s capabilities.  I would be a rich man right now if I just paid for the part of the technology that I did use.  Maybe sitting on a beach somewhere warm.

Truth is we get enamored with the neat stuff.  Myself included.  What we end up doing is trying to fit our life (or process) into the technology.  We go out of way to use it and then over time we realize it is more hassle than it is worth and we stop using it.  Instead we should be looking at our life and seeing how the technology can support or enhance it.  The technology is something that fits right into our life so well that it almost seems seamless.

This happens a lot at work too.  The most common example is software.  The IT department buys a software package with 100 different functions that could possibly help with work that is getting done.  The found the software package because 10 of the functions fill a need that was asked by someone to go and fill.  Then they find this wonderful product and the other 90 functions will save the rest of your world too.  The department likes it too and so the software is bought.  One year later, an audit is done.  It shows only the 10 functions that were originally needed are being used, while the other 90 just sit. The company has wasted the money they spent on all these added features.  Eight years later, someone needs to have a new feature.  Everyone has forgotten about the extra 90 features the current software has, so IT goes out and finds another software package to add the new feature but it also, comes with all kinds of wonderful add-ons and so the cycle starts again.  While all along, the original software had the feature and the company just needed to use it.

This is all waste.  Waste of time, money, resources, and on and on.  The technology we use should be Just-In-Time just like our material.  Get what we need, when we need and at the time we need it.  No more, no less.  When the technology is bought, we need to ask how this technology will help support and enhance what we are doing AND make it easier for us to do.  In other words, the technology needs to support our process and work.  Don’t buy technology and then build the process or work to fit it’s capabilities.  If the technology does not support what you are doing, then it probably isn’t something you want for your process.

ERP systems can be a great example of buying technology and then fitting your process to support the buying of the ERP system.  Most companies doing lean well are taking the decisions an ERP system is making and make it visual out on the floor so anyone on the floor can make the same decision.  Why?  Because the ERP system does not support the process the lean company is trying to implement.  (Side note: Who is going to be the first ERP system to go away from ERP and build a great lean software tool to replace ERP?  Or does a software tool even need to be built?).

I’m not against technology.  That is a bad rap that lean can get.  I am against buying technology that does not support the process or the future state of the process.  It must be proven and it must enhance and make easier what we are already doing.

Why do you think people still technology for the sake of buying technology?  Have you seen this where you work?

Share

Advertisements

Posted on July 12, 2010, in Waste and tagged , , , , , . Bookmark the permalink. 4 Comments.

  1. Interesting timing on your post. I apologize in advance for the long comment.

    I’ve just been working with an organization implementing a new ERP system replacing a number of legacy systems, manual approval cycles and spreadsheets. Working from requisition to payment, we did current state maps and found the average took 111 steps – both manual and automated. The lead time from a req to a PO was 2 1/2 weeks. The future state maps reduced that dramatically and a big part of it was eliminating redundant work because of the lack of an integrated database and the benefit of electronic workflow. Along the way we are questioning why a req needs 3 levels of approval, the PO needs 3 levels of approval (many the same people), and the receiver needs 2 levels. Separate buyers and planners makes for a lot of redundancy as well.

    Their current processes are broken and cannot be fixed within the context of very antiquated batch-oriented systems, disjointed Excel spreadsheets, and manual logging. In this case, ERP is essential in order to eliminate duplication, delay, and later reconciliation of the differences. (All hugh wastes). As a result, the ERP implementation has become the driver for a much more comprehensive business process review than was anticipated but it will deliver the benefits. And using lean as the guidance on future state design makes all the difference between ERP as a software exercise or as a business process exercise.

    To your desire for a lean ERP. That’s our vision, to develop fully integrated and truly comprehensive lean and green functionality in an ERP solution. We have field-tested prototype software now. Don’t wait for the big software players on this one. They’ll do only enough “lean” to be able to check off lean on the functionality checklist – normally kanban and that’s about it. Getting to the next level of “lean software” will come only when there’s a proven market and today there is none.

    By disparaging ERP, the lean community and especially the lean consulting community has done itself a disservice by alienating the ERP players. In reality, lean and ERP must cooperate, the chasm between them is entire counterproductive. Big ERP software will include more lean only when their customers demand it. So long as the lean community continues to maintain that all you need is a white board, that won’t happen.

    Just as a note of realism here, if you are high volume repetitive running with steady demand and dedicated lines, using lean to manage independent of ERP might be possible and even optimal. If you are HMLV with hundreds of products, constant demand and mix changes, alternate routings, highly branched value streams and shared resources, how are you going to manage all that without some software assist? I think that manufacturing in North America is going to look more and more like HMLV – all the high-volume repetitive has gone or will go offshore. For those of us who think there will be a manufacturing industry left, we are going to have to get good at managing variation. And that applies whether we are working with traditional MRP or with lean.

    • Phil, that was very well put. Thanks for adding to the discussion. You re right on with it all. Sometimes I let me emotions get the best of me. I agree. ERP and lean are going to have to coexist in a world of high variation. My previous employer did a good job of modifying the ERP system to coexist with lean when needed. Also, the consolidation of legacy systems can be a huge benefit. Thanks for taking the emotion out and putting the facts in.

  2. Great post. I couldn’t agree more. Everyone jumps to a computerized automated solution. I have more examples of disater that way than I care to count. The problem is they don’t think through the solution. They go on the belief that this software will solve the problem. I always say garbage in is garbage out. In some cases automation of the waste can also be dangerous. Sometimes it just helps you make more mistakes faster. I recommend trying to solve problems with a manual solution first to try it out and then decide after it works to use technology as another improvement.

  3. This is a great post. sadly I’ve had to witness several large companies burn many, many thousands of dollars trying to solve their problems with a big software solution. I won’t reiterate the problems with this approach. You would think it would be obvious that adding software will not fix bad processes. Absolutely what Tims says, “more mistakes faster”! I have a software engineering background so most people are suprised when I’m the one against putting in the “big software fix”. I think too many times the company is looking for a quick solution to problems that have evolved over many years. Unfortunetly, by the time the company reaches the point that they can no longer ignore the problems, the last thing they want to hear is that the real answer is is to apply lean principles (deep understanding, root cause, etc) before any technology is applied. And so the software salesman gets a nice commission.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: