In my BtB approach I sometimes recommend a Process Oriented Organisation that can consolidate the benefits of BtB, dramatically change your culture for the better, and deliver significant improvements in workforce cooperation, enthusiasm and contribution.

However, a number of people have asked about achieving the same end effect while keeping their existing management structure in place.

Now you can do a “Be the Best” program without changing your management structure.  However, going further and introducing POO means that your existing management structure will change.

The whole point about POO is to free up the inherent skills and attributes in the workforce that are rarely used at work because they’re stifled by a blanket of unnecessary management.

Once BtB has been implemented, it gives you the chance to create a new dynamic organisation through POO that helps you become the best in your business.

As part of your BtB program, you should aspire to implement POO if you can.

In my BtB approach I use kanbans within a manufacturing process to help control the flow of products through the process and achieve our BtB objectives.

I’ve received a number of questions on how to apply kanbans in administrative and other non-manufacturing processes.

Kanbans are applied in exactly the same way in non-manufacturing processes.  The same principles should guide your thinking, and in the same way, the kanbans help to control the flow of information through the process and to achieve your objectives.

Many administrative processes are highly automated and use some form of workflow system to manage the flow of information.  In these circumstances it is usually relatively easy to introduce an electronic kanban in front of the key drumbeat process to manage and control the flow.

In developing BtB planning & scheduling, I recommend the need for a frozen period of at least a week in the production schedule.  However, I’m getting a number of people saying that they have difficulty with this concept.  They say that there are always too many things changing at short notice, whether it’s demand, or material supply, or resources, that they just can’t achieve it no matter how hard they try.

The big advantage of a frozen period is that it allows everyone involved in production operations to plan ahead and make sure that everything is available in terms of resources, equipment and materials.  It also helps to ensure a 100% on time delivery performance.

In addition, the costs of production operations without a frozen period can easily be twice those of operations with a frozen period, so it makes real sense both operationally and financially to apply this as firmly as you can.

If you find that you are unable to achieve at least a one week frozen period then there is something seriously wrong with your end-to-end planning process, and you need to address this as soon as possible by identifying the reasons for the volatility.  You’ll find that many of the reasons that prevent you achieving a frozen period are generated in house, and frankly there is no good reason for tolerating them.

In my approach I describe how to apply BtB in Support Functions to ensure that they then synchronise their activities with the main value adding processes within the business.

I also discuss the ‘value-adding’ steps within the Support Function itself, and I’ve had a number of questions which indicate that there may be some confusion over the term ‘value-adding’ being used in two different contexts.  So let me explain.

Within the business as a whole the main value adding processes are those that deliver an end product to an external customer.

In a manufacturing business, these would be the steps involved in converting the base raw material to the finished product and delivering it to the customer.

In a non-manufacturing business, such as in the service sector, the main value adding processes would be the steps involved in converting the base raw information to the finished information that is delivered to the customer.

In both types of business there will be several Support Functions whose aim is – or should be – to assist the main value adding processes as defined above to be at their most efficient and effective.  Typically these Support Functions would include Quality, Planning, Engineering, Finance, HR, IT, and so on.

Within each Support Function there will also be one or more ‘value adding’ processes, which are those steps involved in taking the base information arriving at the Function and converting it to the final information supplied to the internal customer.

Thus when you are applying BtB in a mini-BtB program within the Support Function, it is these internal ‘value adding’ processes that you will consider in order to synchronise these activities with the main value adding processes within the business.

Hope this helps

I recommend the use of tracking software to identify and measure unplanned stoppages in manufacturing operations.  I’m getting a number of questions such as the above, where people are asking why they shouldn’t just use the operators to gather this information.

In my view you never get accurate stoppage information from operators – not because they’re being wilful or neglectful – but just because they don’t do it consistently and the information is often not accurate.  Thus why I recommend the use of tracking software.

However there seems to be a perception that such software is expensive and difficult to implement, and some people would therefore like to avoid its use if possible.

I must say that I’ve never found it expensive or difficult to implement, but this may indeed be relative to the business context and circumstances.  But I still think that the benefits from getting consistent and reliable data on stoppages more than pays off in developing a relevant improvement program that really gives the best value for your efforts.

It’s great when something you developed and have used for years is suddenly really liked by others.

I usually use the Input Control technique for root cause analyses.  Within this technique I prioritise a series of actions by using the formula B-C=D, ie Benefit – Complexity = Desirability.

This is a really simple technique that ranks the actions in descending order of best value for minimum time and cost.  It’s easy to apply in all instances where you want to prioritise a series of potential actions, and I’m getting some enthusiastic responses to its use.  One client actually used the phrase “Greatest thing since sliced bread” about it.

Another client in the insurance industry found it so useful that they’re considering incorporating it into their risk analysis process.

This subject has raised lots of comments, mainly from the US.  It arises because in my description of the Input Control technique for root cause analyses, I state that if you are asking operators to use judgement in operating the process, then they need to have an above average IQ.  Otherwise they cannot use judgement.

The comments seem to circle around two aspects.  Firstly whether the statement is true, and secondly whether it would be discriminatory to apply it.

Let’s deal with the first point.  Operating any manufacturing or administrative process satisfactorily requires many talents.  These talents include physical, technical, personal and intellectual abilities.

The operator has to have the physical capability to do the process – the aptitude if you like – and this has to be established up front.  If he or she does not have the right aptitude for the task, you’re wasting your time and your company’s money putting them in the job.

In the same way, the operator must have the relevant technical knowledge to operate the process, and again this has to be established up front.  If the operator does not have this knowledge then you have to decide whether it makes sense for you to develop this knowledge after recruitment or not.

Again, you have to establish up front whether the personal qualities of the operator fit with potential work colleagues.  Too often I’ve seen examples of a new employee with different personal qualities disrupt the synergies of the group.

Finally the operator must have the intellectual ability to operate the process, and again this has to be established up front.  The most convenient way of doing this is to measure IQ.  Now, leaving aside all the arguments about IQ and how to measure it, the fact is that commercially available IQ tests, if used correctly, give a reasonably accurate assessment of relative IQ, or intellectual ability.

To use judgement successfully, the operator must have the intellectual capacity to assess the relative importance of a series of factors and come to the correct decision on the way forward.  Generally, the more automated the process, the less intellectual ability is required; and on the other hand, the less automated the process, the more intellectual ability is required.

Thus I believe that intellectual ability, measured by IQ, is equally important in a successful process operation as physical, technical or personal abilities.

Turning now to the second point, whether applying an IQ test up front to establish intellectual ability is discriminatory.  If you accept the argument above, then clearly IQ tests are not discriminatory.

When this point was raised by one of the team in a US company, I illustrated my answer by highlighting the need to check for colour blindness.  Now approximately one in six males are apparently colour blind in the red / green spectrum, and in many industrial processes it is essential, if the process is to be operated properly, that the operators are not colour blind.  Otherwise they simply cannot do the job properly.

My argument therefore is that if colour blindness tests up front are not discriminatory, but essential for a successful process operation, the same must apply to intellectual tests.

Having said all that, I’m sure the argument will continue to run and run.  However, I hope you now understand where I’m coming from.

At the end of the day, it’s your business.  You can decide whether to accept or reject my point of view, but I can assure you it has been developed achieving success over many years with many companies in many sectors in many countries.

I’m getting lots of positive comments about the “Unofficial Influencers” described in The Road to Business Success 3, and how they can be used to lubricate the implementation of the BtB program.  (Check them out on my Linked In profile).

Many people have started following this approach and report great results.

It’s a technique I’ve used successfully for years.

I’ve had a number of questions regarding my “Golden Rules of Presentation” that I use to train teams for their Steering Group presentation, along the lines of, “You don’t mention the use of graphics in your Rules.  Why not?”

This is a fair question.  Lots of people include graphics in their slides showing figures of little people moving around the screen, or shapes expanding or contracting, or other dynamic visuals.

Frankly I usually find such visuals distracting and rarely add anything to the presentation other than showing a clever use of PowerPoint.  I often wonder how long it took to achieve these effects and whether it was a good use of time.

The one exception is on layout drawings showing the before and after situations where dynamic visuals can be useful in illustrating machine or department movements to improve flow paths.

I’m not against the use of dynamic graphics provided they’re done well and illustrate a key point of the BtB solution.  However, as in most BtB activities, less is more.

The “Golden Rules of Presentation” are designed to help teams structure and give their presentations to produce a positive response from their audience.  Time and again I have seen senior management groups enthusiastically congratulate BtB teams when they give presentations following these rules.

However, it’s your choice.  Just try to remember that the message is more important than the medium.

I’ve had a couple of questions from teams regarding the ideal number of Milestones in a BtB project plan.  One team proposed 17 Milestones, the other 23.  They contrasted this with the 7 Milestones I usually have in my BtB project plan.

My view is that you should keep the number of Milestones in your plan to single figures – preferably six or seven maximum.  That way you can sensibly manage the project.

Make sure that you combine as many of the proposed Milestones as you can into obvious groups that sit well together.

In implementing POO, I use a slide showing its Key Principles. The third bullet point on this slide has raised a number of questions, for example, “Is it mandatory for a successful POO that you only have two levels of hierarchy within the PU?”

Well, it’s not mandatory, but if you don’t change the organisation along these lines, your BtB solution could be sub-optimal.

POO is not just an organisation change. It is a powerful culture change which, done properly, helps most businesses become more successful.

It embraces the principle that most people in the workplace have lots of inherent skills and attributes that are rarely used at work because they are stifled by a blanket of unnecessary management.  By uncovering these skills and attributes, and utilising them sensibly, you can allow people to better manage their own performance to meet the objectives of their team without these layers of unnecessary management.

In conjunction with BtB principles, it gives decision making powers much lower down in the organisation structure.  The move to self-direction gives everyone a greater sense of involvement and improves performance and customer service still further.

The outcome of a POO done properly is a dynamic culture where everyone contributes their efforts to help achieve the success of their team and of the business.  The change in attitude is almost tangible.  Everyone involved has a much clearer focus and greater transparency and understanding of the PU objectives, has a much wider business perspective, has greater opportunities for individual development, and has more effective real time communications with others in the company.

People develop a huge pride and high motivation, and very few who have experienced it ever want to go back to working in a more traditional environment.

I hope that this explains the POO hierarchy structure more clearly.

I’ve had some comments on the table of categories I use to design rhythm wheels.  This table shows that irrespective of the number of categories, the highest volume category is listed as running every week.  “This cannot necessarily be true” the comments say.

The comments are correct.  As the number of categories reduces, the highest volume does not have to be classed as a Category A and run every week.  It could well be a Category B (runs every two weeks) or a Category C (runs every four weeks).

You can arrange them to suit your particular application.

I’ve had a couple of questions on this point asking when they should use the bulk demand approach compared with the rhythm wheel approach.

Most batch manufacturing operations make a bulk product first and then take the bulk product and pass it through finishing or packaging or assembly operations to produce finished products.

The bulk demand approach is therefore used in the front end operation to smooth the demand into a consistent pattern to help the manufacturing operation become more predictable.

The rhythm wheel approach is used in the back end operations to match supply to demand for the finished product more accurately.

The number one focus in non-manufacturing processes is to get things right first time.

By doing this, you will automatically give yourself the best chance of achieving very short lead times and high productivity.

However, a number of people have challenged me on this point and suggested that one of these other two objectives could be the main focus of the project depending on circumstances.

I don’t deny that there could well be instances when the main strategic aim of the project is to reduce lead times or increase productivity, but my point is that, in approaching this task, you have to make sure as a first priority that you get things right first time.  Otherwise you get into often complex rework loops that play havoc with achieving your objectives.

This subject has perhaps raised more questions than any other so far.

I always use OAE as the harshest measure of operational effectiveness and demonstrate the difference between OAE and the more usual measure OEE.

Lots of people have said that they use OEE in exactly the same way as I use OAE, and if this is the case then that’s OK.

However, over the years I’ve seen so many different measures for OEE and most of them are very different from my OAE measure.  Hence why I take time to explain the difference.

Provided you follow my guidelines for OAE, then you will always be using the harshest possible measure, irrespective of what you call it.  And the harshest possible measure leads to the highest possible performance.

I’ve been asked several times about whether a Process Oriented Organisation (POO) is absolutely necessary in order to achieve the full BtB benefits in a program.

There’s no doubt that in many cases you can get big benefits from BtB without implementing POO.  However the best programs that produce the best results always apply POO as part of the BtB program.

BtB is usually a huge change program, and it makes sense to consolidate the BtB benefits by taking the opportunity to change the organisation along process lines.

POO is the most logical way of doing this and, if implemented my way, can provide a very welcome change in culture in most companies.

When you see a plant that is running POO the difference in performance and behaviours across the company is very striking, and few people that have experienced a POO environment would ever go back to the more traditional way of operating.

A couple of guys have been asking me about synchronising Support Functions. One works in Engineering and the other works in Purchasing, but both are asking why I tend to focus on Quality in developing the BtB solutions for Support Functions. “Can they apply exactly the same BtB principles in Engineering or Purchasing?” they ask.

The answer is that of course they can. For each Support Function, you need to effectively do a mini BtB program.

I use Quality to illustrate the approach because in most companies it is the one function that if you don’t get it right then it can destroy your business and close you down real quick. Other Support Functions are often equally important in that respect, depending on the sector, so the approach illustrated by using Quality can equally be applied to these other functions in a similar manner.

Among others a customer in the Far East has asked me why I develop a Blue Sky Vision, and then apparently abandon it for a lesser Practical Vision. “Why not stick with the Blue Sky Vision and try to achieve that?” he asks.

It’s important to realise however, that the main reason for developing a Blue Sky Vision is to change the perception of the team on what’s possible compared with the as-is process.

Once they have changed their mindset, it then becomes much easier for them to develop a BtB Practical Vision that is a radical improvement on the as-is performance, and which can be achieved within a year.

Normally the Blue Sky Vision would require much more effort, money and time to achieve it compared with the Practical Vision.

However there have been occasions when the BtB team developed a Blue Sky Vision and decided to go straight for it.  This most usually happens when dealing with non-manufacturing processes.

I recently had a couple of almost identical questions over value stream mapping that are worth sharing with a wider audience.

The questioners were concerned that my version of value stream mapping is way too simplistic and takes no account of control features, data flows, inventory levels, etc.

Now I can understand where these guys are coming from. Like other BtB tools and techniques, a whole industry seems to have grown up around value stream mapping.

I’ve seen lots of examples of people spending weeks and months developing maps of as-is processes that are so complicated with so much detailed information that it takes hours to understand them. There are even software tools available to help with the mapping process.

And in my view all of it is entirely unnecessary.

I do BtB the easy way and that means doing just what’s really necessary to achieve our BtB objectives in the shortest possible time.

My way of mapping the value stream is designed to –

• gather the minimum information you need to accurately reflect the as-is process
• use this information to then challenge out the new potential BtB process using my world-class benchmarks, and
• do it all in the minimum possible time, and that means a few hours at most.

The only real purpose of a value stream map is for you to use it to challenge out the new BtB practical vision and you need to get there as quickly as possible.

I’m getting a number of questions regarding the ideal availability for the members of the core team on a BtB program.

I recommend that, for quickest results, they should ideally be available full time for the duration of the program.

However, in some companies, it’s just not possible to achieve this level because of a lack of resources, and the question arises, “What is the minimum involvement the team members can have and still achieve the BtB objectives in a reasonable time frame?”

I think to answer this we first need to define the “reasonable time frame”. In my view this should be twelve months maximum. Beyond this period too many other things begin to change in companies because of competitor pressures and staff movements, and it can then become difficult to maintain the momentum of the initial BtB program.

In my view therefore, if you can’t have the team members available full time on the project, then to achieve the BtB objectives within a year, you need to have the project team leader available on the project full time, or close to it, with the members of the team available at least 50% of their time. What then happens is that the core team members tend to spend even longer on the BtB program and extend their working days accordingly.

To have less involvement than this risks demotivating the core team members and extending the time frame beyond reasonable.

Among others a customer with an engineering company in Eastern Europe raises the question of competing initiatives.

He recently launched a major quality improvement program involving virtually everyone in the company in quality circles.

He now realises that a BtB program would deliver greater business benefits and wants to start this as soon as possible. He asks, “Can I realistically run both projects at the same time?”

My advice is not to do this. It would cause too much confusion with his staff over what was really a priority, and neither program would be effective.

He should either find a good business reason for stopping the quality improvement program and starting a BtB program, or alternatively delay the BtB program until the quality improvement program has run to a conclusion. The latter is probably the best approach depending on his competitive pressures.

Among others this question comes from a customer in the UK. He works with a Government Agency and believes that they urgently need to apply BtB principles to improve performance.

However, the Agency Manager has said that everyone is too busy to get involved in an Agency-wide BtB program, but if my customer wants to apply BtB in his unit then he’s free to do so.

Now most people are “boss-watchers” and take their cues on attitudes and behaviours from their top management. In this case my customer is unlikely to succeed in launching an Agency-wide BtB program without the clear support of the top man.

However, he should run a BtB program in his own unit, and make sure that he details the before and after scenarios to demonstrate the benefits of BtB to the other unit managers, and then hope that together they can convince the top man that he should apply BtB to the wider Agency.

For me I think the Game works well for the following reasons –

• It’s an enjoyable and practical way of learning the basic BtB principles
• It’s an excellent team building exercise for the core team and senior management, and
• It provides good examples of the basic BtB principles that you can refer to later in the program

If you don’t run this Game (or something similar) with the combined core team and senior management group, I think you reduce the impact of your BtB kick-off. Without the involvement of senior management, the BtB program can then become just another project, and you may find it difficult to achieve the full benefits that are potentially possible.

Done properly, BtB is a huge change program for the business, and I think you need all the help you can get to make it successful. Thus I do think the Game (or similar) as part of the BtB kick-off is essential for success.

In my presentations to clients, I often use an example to illustrate the financial benefits from improving productivity.  I’ve had several questions on this, typically, “Is it based on a real company?” and “Is it too simplistic?”

Let me replicate it here.

Before BtB –

Sales of blister packs = 10m at $1 per pack = $10m

Material costs = 40% of sales = $4m

Direct labour and overheads = 40% of sales = $4m

Thus contribution to fixed overhead and profit = $2m

Unit cost per pack = $0.80

After BtB (assuming a productivity increase of 50% and increasing sales to fill the freed capacity) –

Sales of blister packs = 15m at $1 per pack = $15m

Material costs = 40% of sales = $6m

Direct labour and overheads remain the same = $4m

Thus contribution to fixed overhead and profit = $5m

Unit cost per pack = $0.67

The key to this improvement is the increase in productivity.  That means we put more through the same resources – the same direct labour and overheads.

So, by increasing productivity by 50%, which I think most BtB program could readily achieve, and I have done it before in similar circumstances, you increase your profit contribution by 150% and reduce your unit costs by over 16%.

The figures are indeed based on a real company in Europe and, while the example may be a little bit simplified for the purposes of clarity, it does illustrate well the financial benefits that you can get from increasing productivity. The logic is perfectly sound.