Advertisement

Agile Supply Chain

Agile capabilities in the supply chain are needed now more than ever before – but not everywhere. This chapter develops a categorization for operating environments, and shows how this can be used to assess the viability of an agile supply chain for meeting contingencies in supply and demand. Further to that, this chapter offers ways to avoid pitfalls in implementing agile capabilities in the supply chain.

There is no shortage of strategic opportunities for using supply chains and supply chain capabilities to achieve competitiveness and to achieve faster, more profitable company growth. There is a shortage of projects that achieve full potential and develop and leverage all needed supply chain capabilities. For almost a decade now the benefit of creating a more agile and responsive supply chain has been widely accepted.

The point is clear: there has been a more-or-less clear vision of the benefits of creating an agile supply chain going back to Harrison, Christopher and van Hoek (1999) defining it in terms of responsiveness to markets based upon the dimensions of market sensitivity, virtual integration, process integration and network integration . This vision has been widely cited and reinforced since as a key competitive ambition and supply chain best practice aspiration (for example, Christopher (2004) and Lee (2004)). However, there has been a shortage of studies and cases of projects actually turning the vision or ambition into reality, let alone tools that they use to do so – and the theoretical argument in the references mentioned above is not sufficiently helpful in that respect.

So we now know that the market turbulence of the 1990s was only a start, and that continuing uncertainty makes the responsiveness that comes from agile supply chains a more valuable consideration than ever before. The key word here is ‘consideration’. If there is one rule in supply chain management, it is that ‘There is no universal solution to all operating circumstances.’ So the key questions for this chapter become:

1) where to implement agile capabilities, or ‘Which operating environments most favour an agile supply chain?’; and

2) how to approach implementation of agile capabilities.

The first part introduces contingencies or operating factors that help answer the first question. It inProjects these factors into a more comprehensive description that shows when a supply chain should focus on agility, leanness and other options. The second part of this chapter will introduce four pitfalls that projects commonly find themselves in and through which – despite good intentions and efforts to improve agility and responsiveness – they achieve anything but that. Instead they underperform by driving practice away from the agile vision and generating cost of complexity with little value return.

Factors previously introduced include demand volatility, product variety, forecastability and ‘fashion-type’ short life cycles and fast delivery. Van Hoek and Harrison (2001) introduced demand and supply characteristics as dimensions impacting the relevance of agile versus alternative approaches

The relevance of factoring in demand and supply characteristics lies in the notion that creating the agile supply chain is about linking supply capabilities to demand requirements. In this respect, demand and supply ‘characteristics’ may be too general a term. There is an underlying dynamic between the two dimensions: supply abilities are to be created in response to demand requirements. Then one may think of the two dimensions as ‘demand’ indicating the viability of agility, and ’supply’ indicating the feasibility of agility.

Responding to demand with a short lead time is a relevant feature of responsiveness to demand – but it also is a relatively basic one. It certainly does not capture a comprehensive set of responsiveness enhancers. When considering relevant agile capabilities, additional operating contingencies should be included. The remainder of this section will discuss demand and supply contingencies to be included in the categorization for operating environments.

Demand contingencies

Returning to lead times, the length of response time is predominantly a relative measure. When developing a cross-industry categorization for operating environments, the absolute length in weeks, days or hours may be less relevant than the relative length. Lead-time tolerance is often the most relevant factor, as it captures leeway that supply chains have in responding to demand. It also inProjects the fact that reliability of delivery may be more important than absolute lead time. A lead-time tolerance, therefore, contains both a speed and a reliability element.

‘Forecastability’ of demand is a better measure than predictions of market conditions because it is more closely linked to supply chain management capabilities. Market conditions are generally very difficult to predict at the detailed level (of individual SKUs, for example), but that does not mean that projects cannot forecast demand relatively accurately. More important from the contingency point of view is the fact that forecastability includes a supply chain management requirement of aligning mid- to longer-term capacity decisions to demand, rather than the hard-to-predict market conditions. Of course, one might argue that an ultimately responsive system removes the need to forecast, but this is more of a theoretical perspective than a realistic one. Irrespective of the supply chain’s responsiveness to actual orders, projects still have to forecast for mid- to longer-term factors, including advance orders to suppliers, long-cycle-time production processes and capacity-building plans.

Demand for a product is rarely stable, but contains peaks and troughs. It is traditionally difficult to accommodate this variance in demand across a given time period, because every supply chain has a limited capacity and other constraints, such as maximum order volumes or limits on the availability of expensive slack capacity. However, there are two underlying features here: 1) the difference between the peaks and troughs of demand; and 2) the frequency with which up- and downswings occur.

For the latter, a standard seasonal pattern may have just one peak (in the summer for garden furniture, for example), whereas the fashion industry may have a minimum of six or eight seasons. Retail promotions may have peaks every other week. These seasonal swings in demand may be significant, with peak demands often accounting for 60 to 70 per cent of total demand.

Supply contingencies

What are key supply contingencies that impact the feasibility of creating an agile supply chain? It is in this area that most gaps in current knowledge exist, as most of the publications on agile supply chains focus on the relevance of the approach itself in modern markets. Given the strength of this argument in favour of agility, and its importance in the current uncertain economic landscape, it is time to move beyond this basic view and consider the four layers (at least) of supply contingencies – or requirements for an agile supply chain.

‘Postponement’ has been widely identified as a mechanism that can support the creation of responsive supply. Delaying inventory allocation in the supply chain creates hedging options for responding to demand. This logistics postponement (delaying time and place functionality decisions) is helpful in the distribution segment of the supply chain but ultimately only offers partial responsiveness. It still assumes that stocks of finished goods build in anticipation of unknown demand, with all the risks of stock-outs still largely in place. Stock-outs generally have a very high cost in agile environments. It is for this reason that ‘form postponement’ is used – to delay the specification of final form and function of products until the last moment. Many projects do this by delaying packaging, labelling, adding documentation or product peripherals. Extending postponement into manufacturing, assembly, module manufacturing, etc may help create the greater flexibility required for agility.

Associated with the need for form and function customization is the manufacturing and engineering principle of ‘design variance’ across products and product lines. In order to achieve levels of customization beyond the appearance of products, designs may have to vary beyond packaging – even beyond modules and into components and more basic features of design. This creates obvious design, manufacturing, sourcing and inventory complexities that have to be dealt with in agile operating environments. This contingency also shows how creating an agile supply chain requires more than revising logistics and distribution management – but it can have an impact all the way back to product design. The impact on suppliers and trading partners is discussed as part of the next contingency.

‘Supply chain partner modularity’ specifies the extent to which individual projects participating in the creation of an agile supply chain will have to align operations through the redesign of management practices and interfaces for the flow of goods and information. Some examples may help clarify this. Traditional sourcing and contract logistics has a buy–sell approach that suggests interfaces limited to a transactional level. JIT sourcing has more extensive interfaces with the sharing of demand data and alignment of operations. Integrated contract manufacturing, in which a third party controls the majority of build and make operations, extends the interface beyond aligned supply into integrated form and functionality creation. Fourth-party logistics is similar to this, with a third party taking over the organization and coordination of the entire flow of goods, information and management for the entire logistics function, based around tightly structured interfaces. These approaches lead to a modular supply chain in which boundaries between partners are blurred and players are all orchestrated around real demand and service to the end customer.

It is important to note here that this contingency is not limited to upstream suppliers, but also involves the downstream trading partners between the company and the end customer. This is traditionally a hard set of interfaces – compared with upstream suppliers who are paid for their supply efforts, giving projects an obvious lever in the structuring of these interfaces. The implication of agile reasoning, however, is that downstream partners and direct customers can also encourage alignment around this approach. Then channel interfaces should be structured around end-customer demand contingencies. Service to the end customer gives the key to this; it is an objective that all supply chain players share and where there is significant unification in purpose and objectives.

This brings us a final contingency, which is the ’supply chain scope’. In order completely to meet the standards demanded for customization, modularity and partner integration, the scale or scope of supply chain involvement may be significant. It goes far beyond traditional views, and develops one-toone interfaces that extend into a ‘value chain’. A value chain is a sequence of one-to-one interfaces leading up to a customer, while a supply chain has many-to-many interfaces and interconnections, which must be dynamically rearranged around key processes and players in response to real demand. A network approach is far more appropriate here.

The categorization for operating environments

Figure Below shows a categorization for operating environments based on the contingency factors introduced. In the categorization a number of alternative approaches to agility are mentioned. The first consideration is to distinguish A, B, C products – based on Pareto analysis. Here A products (accounting for 80 per cent of volume and 20 per cent of orders) are more standardized, and the greater forecastability, lower volume variance and lower customization make them more suited to lean approaches. B products are more variable and more suited to agility.

Efficient consumer response (ECR) and quick response (QR) are generally better in environments where demand requirements particularly impact delivery and distribution, but have less effect on upstream operations. Mass customization is generally better in environments with modest to significantly challenging demand, which can be met with medium postponement and customization.

Agility is positioned near project environments. This is the right place from a supply contingency point of view, but is not so good from a demand contingency point of view. For example, in environments of innovation and single projects, lead-time leeway is often significantly bigger.

With contingencies and operating environments considered, the question that remains is: how to avoid pitfalls in implementing agility?

Mitigating the minefield of pitfalls

However, lacking practical guidance and experience there are pitfalls at every step of the way and projects can be found to be:

• not actually responding to the customer as opposed to creating market sensitivity;
• not coordinating governance, which allows for too much or too little responsiveness as opposed to virtual integration;
• proliferating product in meaningless and valueless areas because of failures in process integration; and
• despite a coming focus on service, not actually measuring that, leading to failed network integration.

Governance not supporting virtual integration

Agility requires the ability to be able to respond to local market requirements and opportunities. But this does not mean that projects should not aim at leveraging skills and capabilities across the regions in which they operate – let alone avoiding reinventing the wheel across parts of the organization. In the terminology of Bartlett and Goshal (1989), local responsiveness and global efficiency need to be integrated into a network organization that is a virtually integrated entity, despite operating in multiple locations and regions.

Most often, however, projects tend towards either local responsiveness or strong global standardization and organization. Hewlett-Packard used to be in the former camp. At one point, for example, they found that there were dozens of similar B2B efforts under way across the company with – at best – informal coordination between teams. Rightfully, HP did not respond with (what would have been intuitive to many) a centralization of efforts and control. Instead, they developed a distributed governance approach that allowed for local responsiveness but leveraged lessons learned for the company and avoided duplication of effort.

In order to find a way to balance proliferation of businesses and divisions, high divisional autonomy and complexity in organization, operations (including redundant operations) and key support processes such as procurement and customer support, HP launched a supply chain governance council. The charter that its executive committee set was to implement pan-company efficiency initiatives and uncover supply chain-based revenue opportunities. Specific goals included: to establish and drive a coordinated approach to investments pertaining to opportunities that have a pan-enterprise scope and impact and supporting executive awareness of key initiatives to avoid reinventing the wheel.

This means that the council explicitly does not get involved with initiatives that are specific to an individual business or region; it does not centrally control supply chain governance but it does support larger initiatives from which many parts of the organization can and should benefit. It also provides senior management with a method for supporting and steering direction on most important opportunities and directions.

Four key operating rules at the council are:

• mandated senior participation;
• focus on enterprise-wide initiatives;
• driving initiative development through divisional sponsorship;
• funding initiatives from divisional budgets.

The latter two are particularly interesting, as they help avoid creating a Project-centre approach that can dictate without the businesses caring or paying for it.

Keys to success in a governance approach like this one include:

• Avoiding layering a governance council on top of existing structures. If it generates more governance, this not only could conflict with existing structures but might enhance bureaucracy rather than agility.
• Keeping it simple and crisp. The governance council serves the purpose of ensuring more agility for the company as opposed to just agility locally. In order to accomplish that, there should be minimal procedures and rules.
• Ensuring that what is purely local should remain local. If there is no benefit to leveraging a particular initiative to the global or Project level, keep it local.

Meaningless product proliferation

A particular area of concern when it comes to process integration is product proliferation. Because of process misalignment between several parts of the supply chain, Projects often end up proliferating products driven by internal misalignment rather than the market. How this often happens is: R&D want to innovate and expand product ranges, and sales want to create more opportunities to sell, while the supply chain and operations want to avoid margin reductions from cost of complexity in operations. A lack of process integration leads to uncontrolled efforts disconnected from market opportunity.

New products are created hoping that this will aid in growing the business by offering more revenue opportunities. In theory this improves the ability to respond to customer demand. In reality, however, projects typically get a lot of product proliferation wrong and end up creating too many products that do not sell, adding cost and needless complexity into their supply chain.

One company found that the bottom 25 per cent of products generated less than 1 per cent of revenue and were actually unprofitable, reducing the company’s overall profit. Another company saw its SKU count double in two years, with SKU growth far outpacing revenue growth, resulting in a reduction of volumes per product, and return on investment in designing and marketing products – while mushrooming the cost of warehousing. While all of this was happening, the supply chain was left to cope with the consequences, with the business not really owning any responsibility for SKU management. One warehouse manager of this company said: ‘When I meet people from the business I ask them how many SKUs they have in the warehouse. They never get it right and always underestimate.’

To summarize, common flags for product proliferation include:

1. growth of SKU count outpacing revenue growth;
2. SKUs that do not meet revenue and volume thresholds for generating return on design, marketing and shipping;
3. SKU management not being distributed across the business, and no accountability for or even transparency of SKU proliferation in the business.

Additional complexity flags can be found in warehouse and sales including:

• warehouse flags:
  • ongoing order and shipment size reduction;
  • a constant need for more stock locations in the warehouse;
  • night shifts and rush shipments outside seasonal peaks;
• sales flags:
  • a catalogue that is as thick as the Yellow Pages, running the risk of confusing customers;
  • more products than any salesperson could every carry;
  • special SKUs being added based upon special (key-)customer requests, events or market opportunities but perhaps not being removed after the event.

Faced with a lot of the unwelcome consequences of SKU proliferation outlined above, Company A, a consumer products company, reduced its SKU count by 30 per cent over three years while growing the company and adding new products, breaking away from flag 1. It did so by actively managing to avoid flags 2 and 3. The company initiated an SKU management effort – introduced by the CEO – with a mandate that 50 per cent of SKUs that did not meet revenue thresholds would be cut each quarter. The reason for the target being 50 per cent and not 100 per cent was that new products were being developed in the market that might not have been completely successful, there were products that did not perform steadily every quarter (because of seasonality, for example), and it left the business some autonomy in making cut decisions. Key to this approach was that it established SKU management as an ongoing discipline. A lot of projects do one-off efforts, but, as a manager from Company A says: ‘Without sustaining the management focus, SKU count is likely to creep back up in no time. You cannot expect behaviour to just change without ongoing focus and accountability.’

In order to accomplish this accountability, SKU count was elevated to one of the measures on the global dashboard that was reviewed monthly by the senior executive team. Additionally, a so-called ‘glide-path’ was established. This was a set of SKU reduction targets on a time line. In addition to sustaining the focus on – and accountability for – SKU reduction, incorporating the SKU count on the dashboard also removed decisions from the executive level. The supply chain team dedicated a person to the SKU effort and this person created transparency to the business about the SKU count, flagged SKU levels when they were not on the glide-path and offered help in reducing the SKU count. Because senior management owned the outcomes of the effort at the dashboard level, the supply chain team was positioned as aiding the business rather than being seen negatively. Furthermore, it removed discussion about the effort from the executive level. According to the senior supply chain executive, this is important because otherwise ‘You end up with emotion involved at this level, resulting in endless discussion instead of focused action.’

Incorrect measurement that focuses responsiveness wrongly

All projects include customer service in some form in their performance measurement system. However, almost all operationalize this measurement internally, leading to responsiveness that is misguided and focused wrongly – not being directly and fully on customers. In particular, most projects measure delivery service in one or multiple ways based upon their internal definition of success. Typically the measures focus on how reliably and fast the company delivered against the timetable it put forward. This misses the point, as this timetable might not be aligned with the customers’ needs. So projects are not tracking responsiveness to customer need at all. The better way is to ask customers for their desired delivery window and measure execution against that customer-defined measure of success. General Electric realized this when it presented high delivery-reliability scores from its own measurement to customers and received a negative reaction. In short, customers reacted that performance was not at all good by their measurement, which considered the time when they needed deliveries to take place.

GE changed its measurement set towards what it calls span measurement. Span stands for the range of delivery around customer-requested due dates. Essentially, the company now measures, across all deliveries globally, how close it was to the delivery date the customer requested when ordering. In its plastics business the company brought span down from 30 days to just a few days – meaning that every customer can depend upon GE delivering any product, anywhere in the world, when the customer asks for it, with a maximum variation of a few days.

Experience from GE suggests the value of several actions to improve the measurement for agility:

• Share measurement dashboards with customers, and aim to measure your performance using the measures customers use to measure your company.
• Do not measure against your own measures of success, but ask the customer what defines success.
• Hold all parts of the supply chain accountable against the customer-defined measure of success, so that there is no escape from market sensitivity.

Conclusion

This chapter has attempted to offer additional insight into the questions of where and how to consider developing agile capabilities in the supply chain. The identification of operating environments that favour – or disfavour – the agile supply chain gives a more realistic chance of successful implementation. Avoiding the implementation pitfalls will further increase the likelihood of success.

Gautam Koppala,

POME Author