Thinking Faster

Paving the goat path

This is one of my favorite expressions.  It comes from my history of implementing ERP software - especially SAP.  What it refers to is trying to use new software to overlay the same old processes.  I've been in many firms with ERP and CRM systems especially where we simply configured new software to do what the old systems and processes did!

But what's damaging about forcing software, especially packaged software, to meet existing processes is the range and depth of changes required to implement successfully.  Rather than simply changing the business process and the culture (gulp!) to fit the software application, many firms decide to change the software to meet the existing business process.  This is short-sighted for at least four reasons:

1.  Do you really think EVERY one of your business processes is so unique and provides a competitive advantage?  Can you learn something from what has to be a fairly common business process like cutting a purchase order?

2.  When you change the software - even just in the configuration of switches and tables - you are creating a new maintenance issue for the long term.  Every change you make means something that has to be tracked and tested upon each upgrade or change in the system.

3.  When you change the software, you may create data validation errors.  Are you using fields for one function that should have been used for another function?  Did you add fields to the database?  Will this cause limitations in how you can grow with the software over time?

4.  When you change the software, you impact the process documentation and possibly the underlying business processes inherent in the software.  This could be important in an environment where validation of the business processes is important - pharmaceutical or medical supplies for example.

Now I'm not suggesting that you should change your entire process and culture for every software application that your business leaders or IT team considers, but you should carefully weigh the tradeoffs when changing the business processes inherent in an enterprise application.  By making these changes you are dramatically limiting your ability to grow with the software and creating maintenance headaches down the road.  I recognize the power of corporate culture, and I know that enterprise software developers need to take more real world examples into consideration when they develop software. 

Ask yourself this question as you prepare to install software - will my business processes look just like they do today in two or three years?  If you have any question about how stable those processes are and how important they are to your business - determine the right business processes before you install software to support them.

The Need for Speed

Many business writers and thinkers talk about the need for speed - to speed up supply chains, work more closely with the customer, to get ahead of the trends and business cycles.  I think speed, like any other attribute of a business, can be a valuable feature or a killer.

However, I do want to point out the need for speed in creating change in an organization, especially process and information systems change.  An unfortunate outgrowth of the ERP and CRM implementations of the mid to late 90s has led to what I call kitchen sink thinking when it comes to information technology systems.  That is, while we are going to replace system "X", why not also bring system "Y" in and change system "Z"?  We've become accustomed to large, unwieldy projects with lots of moving parts.

The problem unfolds in several ways - in time, resources and risk.  I was trying to explain to a potential customer the reason our estimates increased more dramatically as the project she suggested lengthened.  I have a rule of thumb when it comes to system implementation - time increases incrementally, resources required increase arithmetically and risk increases exponentially.  Why?  In the long run, everything changes.  Given the pace of our businesses and trends in the environment, talking today about what systems we'l implement in eight to ten months from now is fraught with peril, since in that time so much could change.  Management teams are more fluid, customer tastes and demands more fickle, Wall Street more interested in mergers and acquisitions than steady growth.

Where possible, we need to administer short, sharp shocks to the day to day process infrastructure.  Make process and information system changes, but try to contain the scope and timeframe of the project at all costs.  To be frank, some of the biggest challenges to long projects are simply short attention spans.  After a while, hearing about the same project makes anyone wonder - when will they get done?  Are they STILL working on that?  And inevitably, once you've opened the cookie jar of software, some one from senior management will have a bright idea about adding a new set of features that was not planned for initially.  You had the code opened up anyway, right?

After a while IT fatigue sets in and there are new and interesting projects and trends which attract people's attention.  The longer a project goes, the more likely it is to fail.

OK, so what's my recommendation?  Reduce and manage these risks by tightly controlling the scope of a project, and attempting to accomplish as much as possible in as short a time as possible.  Delivering many short wins that can be identified as wins - even incremental wins - builds excitement and lets the team know that there is always an end in sight.  I think many IT managers will look at this approach with either excitement - since their teams want to work this way, or disappointment - since its harder to build an empire on smaller, shorter projects.

When implementing process or information system changes, slow and steady doesn't necessarily win the race.  You have the need for speed.

Individual Acts of Heroism

We're about to launch a new software product, and I am always interested in observing the process.  For months we've planned the launch, evaluated the risks and challenges and tried to plan for contingencies.  Yet in the end, what has happened and what often happens is that a few people are the bottleneck or the reason the product will get launched.

I've always wondered about how productive and effective most businesses are, and whether they become effective in their processes through strong culture, great business processes or what I call individual acts of heroism.  What I mean by individual acts of heroism is that, generally speaking, a few subject matter experts in a business do almost anything to make the process work, sacrificing a lot to complete a project or process.

What struck me about this was a contemplation of some of the places I've worked or had the opportunity to observe.  I worked as a consultant for a large hotel chain with a very strong corporate culture, that is the model of customer service.  However, the inner workings of the business were less than ideal.  Many of the people in the business were long time employees and had fully invested in the corporate culture, and were willing to do almost anything to make any project or process succeed.  The business processes and systems were faulty and a constant roadblock to getting anything done, so a few people in each business function did heroic things to overcome poor processes and systems.  From the outside, the firm was a model of customer service.  From the inside it was a business process disaster.

I also had the chance to observe Southwest Airlines from a distance, as a friend worked there.  Southwest is an innovator in the way it positioned itself, and a great airline to fly.  Almost always on time, low fares and employees with a humorous outlook.  However, according to friends who worked there, the business processes in many of the functional areas were a mess.  People bought into the culture and worked heroically to help the company succeed.  Some of those cracks are coming to the surface now, in the strikes the flight attendants and others are conducting.

What's risky about poor processes and heroic performance is that these concepts are not sustainable or scalable.  Eventually, one or two heroic people will simply wear out because too much is constantly placed on their shoulders, or they will become a significant bottleneck for the work that needs to get done.  I think its better to have a simple, clear process that everyone understands and follows than these individual heroics.  It's interesting to me that many firms with strong cultures I've seen (just two examples above) often get started because people took on the heroic mantle, and these firms may encourage that attitude among their employees, but it simply won't work over the long run.  The firm has to transition to well-defined and communicated business processes that enable collaboration, communication and improved working conditions.  Does a strong corporate culture create as part of its ethos heroes who must rise above the processes?  Can't we create processes to satisfy the high demands of a strong corporate culture?

Conversely, firms that may not have a strong culture (or employee loyalty) rely more on process.  Take a fast food restaurant for example.  All the steps are clearly identified, everyone has a specific place and workstation.  No one individual stands apart.  Obviously this is important due to the nature of the work and the turnover rate.  But why should manufacturing line workers and fast food workers have clearly defined business processes and expectations, while knowledge workers continue to work as if every project or process may require them to be a hero?

Outside looking in

In the quest to become more productive, we all try a lot of different approaches to improve the way we work.  Some people will try to work with consultants or coaches, some will try new technologies.  Unfortunately some folks will decide that it's beyond their power to change and will do nothing.

One of the most powerful approaches to consider how you do business is to step outside your regular business process and consider it as if you were a customer or a vendor to the process or organization you wish to improve.  We are often so caught up in our own culture and process that we neglect to consider what the situation we are in might look like from a disinterested viewer's perspective.  Ask yourself this question - have I ever had to be a customer of my process?  I call this the Rubik's cube view of life.

Remember the Rubik's cube?  A simple cube with six sides and nine squares on a side?  All you had to do was move the squares around until all sides contained nine squares with the same color.  I likethe cube as an analogy because the Rubik's cube forces the person trying to solve it to move it around and examine it from many different perspectives.  How often do we do that when we think about our business processes?

What I often want to do is step outside my business process or function and look at it as if I am on the "outside looking in" - as if I am a disinterested third party.  If I were that disinterested third party, would I think the process makes sense?  Does it solve my needs?  Does it address what I want as a customer or a vendor to that process?  I wrote earlier in this blog about Stapling Yourself to an order.  How many of us have been consumers of our own process or service?

I often wonder if any senior executive of my bank has ever called the bank's call centers seeking help for a problem.  If they have, then they obviously don't understand customer service.  My suspicion is that none of the senior executives there have called customer service to test what it's like to interact with the service agents.  Not to cast stones - I'm guilty of this too, and we've learned some things about trying out our own services and are looking at ways to improve them from a customer's perspective.

What should you do?  Step outside of your function or your business process and look at it critically.  What would a disinterested observer say about the process?  Does it make sense?  Can it be improved, both from the perspective of the flow of information and from the perspective of the people - customers and vendors to the process - who have to interact with it?

The Power of the informal

Concepts and processes that enhance productivity are often found informal places and in keepers of the culture.  For example, we all know that each business has a well defined organizational structure, with boxes and lines delineating who reports to who (whom?).  But we also know that there is an informal power structure as well that is not reflected in the boxes and lines, and people in certain positions can have much more power than the chart implies.

The same is true about getting things done.  Is it better to create sidewalks where the builders expect the traffic to flow, or to watch the traffic flow, then build the sidewalks where the patterns emerge?

Hidden in the dusty corners of your business is a person, let's call her Marge. Every business has a Marge, in fact most business functions have a Marge.  Marge is the keeper of the "How Do I" list.  She knows the best way to accomplish many tasks, and knows why these approaches are correct.  When a new employee joins your firm, if she manages to meet Marge, she will quickly learn about the informal power structure and how to get things done.  The good news about these informal processes and knowledge databases is that we finally have the tools to capture and share them.  Now, we aren't talking about Short Cuts, but about the most effective methods to obtaining information about the culture that may not be readily apparent.

I've written about WiKis before, but I can hardly think of a better use for them than the underground knowledge about how to get things done that exists in any business.  If we can capture the knowledge that Marge has and publish it in a Wiki for more people to share, we'll all be more effective.  If a website can have a Frequently Asked Questions, why can't a business process or a work team?

When I first started working with the Getting Things Done methodology, rather than create files I created piles.  Then, over a period of several weeks I reorganized the piles and used those piles to create my folders.  There were patterns and logic in the piles that I might not have captured at first, and that became evident with a little contemplation.

What's my point?  There are informal knowledge sources and "experts" in doing business in your business.  Capture their knowledge and expertise and publish it to the workteam or division, so that everyone can become more productive.

The Weakest Link

I've been writing a lot about productivity and methods to improve it.  A great source for thinking about improving productivity in firms has been a book called "The Goal" (one of my key book selections).  For those of you with a more manufacturing or operations mindset, this is a novel which incorporates the Theory of Constraints.  I know, hard to believe, but Goldratt keeps it interesting throughout.

I am interested in productivity, especially in knowledge based businesses, since manufacturing in the US is increasingly moving overseas.  The concepts of The Theory of Constraints still apply to non-manufacturing organizations.  Let's call it the theory of the weakest link.

Basically, the Theory of Constraints says that your process is limited by a bottleneck.  There is always a step in any process that is a bottleneck - usually because it cannot scale to accomodate more throughput while the rest of the process can.  See this description and a good website on process management for more information.  In any process, there are steps which can create bottlenecks to efficiency.  It's our responsibility as managers to eliminate or at least reduce the bottlenecks in the process.

In a previous posting, Business Process improvement for dummies, I wrote about the classic HBR paper in which the authors recommended literally following an order through the customer order process.  These authors were focused on the elapsed time that the order took to complete a process, and the tiny fraction of that elapsed time that the order was actually being reviewed, approved and filled.  In the same manner, I think we should evaluate our processes and find and eliminate any constraints or bottlenecks, so that our processes operate as effectively as possible.

I once worked as a consultant for a large hotel chain.  In working through various process improvement projects, we discovered a large bottleneck in the purchasing organization.  There, the purchasing managers carefully reviewed every requisition from the hotel brand design teams.  This review meant that products were often late to arrive at hotel sites.  When quizzed on the time and care placed on the review, the response from the purchasing team was - the design team rarely specified the right products, and without the careful review by the purchasing team, many sites would receive the wrong chandeliers, coffee makers and carpets.  Rather than creating a standard item database and training the design team, the purchasing team had become a constraint, but in this case they were both a positive constraint and a negative constraint.  We worked with them to train the designers and to establish a common product naming/numbering scheme.  Eventually this meant that product specification and purchasing time were reduced by over 40%, without an increase in product specification errors.

Before our evaluation of the process, it was simply assumed that purchasing was a bottleneck and should work "faster".  Upon further review, we discovered that purchasing was taking on both a quality review of design's work as well as their own procurement duties.  But the culture of the firm did not encourage purchasing to train the design team and create a common item database.  Take some time to evaluate and understand the bottlenecks in your processes - why they are there and how to improve the process.

What's the weakest link in your business processes?  Have you effectively evaluated your most important business processes to remove non valued added time and to eliminate bottlenecks?  What would be the impact to your customer service, your design cycle or your financial closings if you did eliminate the weakest links?

Business process improvement for dummies

in 1992, a seminal article appeared in the Harvard Business Review.  It was called "Staple yourself to an order".  The article pointed out that the customer order management process in many companies was overly long and complicated and that led to customer dissatisfaction.  Shapiro, Rangan and Sviokla, the authors, did not use statistical analysis and linear regression models to demonstrate what was wrong with the customer order business processes.  They simply followed the order from desk to desk through the entire order process.  They found that many processes had a significant amount of time that was not adding value to the process.  For example, they found that a customer order that required 20 elapsed days for processing was only actually worked on for a total of 10 hours.  There was a lot of non-value added time in the process.

Now, their point was to encourage businesses to improve the customer order process and make it more efficient, to remove time from the process that did not add value to the order.  I think the same approach should work for any business process in any organization.  Many organizations have formal or informal business processes for requesting information, creating a request for funds for a new project, purchasing a new piece of equipment or other needs.  Some of these processes are established, and some must be created periodically since the business need waxes and wanes.

However, virtually any process gets clogged up and information eddys and time sinks are created.  Anything that gets in the way of getting things done without adding value is a roadblock to success.  What are your most important business processes, and do they operate with maximum efficiency?

Which of your most important processes are documented?  Have you tuned those processes to be highly efficient?  If a process is not helping you become more efficient and more productive, then it is standing in the way of your success.

Define your most important business processes, document them and ensure they are as efficient as possible, with as little time "waiting for approval" as possible. Staple yourself to a business process and find the inefficiencies in your business that hamper your productivity.