Remapping the Supply Chain Universe

Size: px
Start display at page:

Download "Remapping the Supply Chain Universe"

Transcription

1 By: Sree Hameed August 18, 2010 Supply Chain Management is a truly dynamic field. Over the last few years the fundamental structure of the chains has changed to the point where many of the working assumptions have to be re-evaluated. Introduction Supply Chain Management is a truly dynamic field. Over the last few years the fundamental structure of the chains has changed to the point where many of the working assumptions have to be re-evaluated. One of the changes that has become obvious is that technology misfits have emerged. It s like going to the gym and getting lean, then finding that your clothes no longer fit! Also, if you haven t gotten to the gym lately, you will be surprised at the cool new equipment that has been developed to make you leaner, stronger, and agile! Sometimes when I see this new technology, I am confused about how I will use it, what benefit it will provide, and how it fits into the program I currently have. And, sometimes, a new approach is so revolutionary (for me, at least) that it requires a re-assessment of my entire workout program. In this article we will discuss the technologies, how they enable the new emerging structure of the supply chain; and most importantly, make the case for a fresh approach to selecting technology. Page 1

2 The new supply chain We have all heard about virtual supply chain models as the big innovative change, but that s so 90s!!! Over the last few years, supply chains have evolved with a new model emerging. This model is enabled by a new technology foundation (web, wireless, etc.) Figure 1 Virtual and Federated Supply Chains Supply Chains, to be successful, are market driven, and as such need to be dynamic, reflecting the customer viewpoint. Virtual was an evolutionary structure born out of survival. If you look at the firms that led the way to virtual, it was all about getting cost off the books. And even today this model, first and foremost, is driven by operational goals cost and some operational excellence, if they can achieve it through the 3rd party partner. In the new generation of business model, which we are calling "Federated," responsibility is distributed, and customers now assert their value position. Customers can configure the partnerships. Federations might require new business functionality, but more important, they cannot exist without new technology structures, as well as new Delivery Architecture (more on this later). The web-based real Page 2

3 time architecture to run these models does not just create linkages e but ensures business and information synchronization the Federation acting as one. (How this technology differs from previous models, we will discuss this shortly.) However, it is clear that even fairly traditional business models require stronger linkages with customers, and rely on the e factor, even for fairly linear processes, like trading partner collaboration, CRM, purchasing, sales, etc. And behind firewall technology does not serve very well any time the enterprise reaches out beyond traditional boundaries. Yet, we have not amended our approach to selecting technology as our business model, and technology needs have changed. And those win/lose quadrants tell us very little about how a particular technology can support your business goals and supply chain models. Changing models and new technologies requires a new way to select enablers What are these new enabling technologies? Within this brief article, we cannot explore all the nuances of the new web-enabled technologies for linking enterprise processes, delivered on-demand, which did not exist a decade ago. These intelligent Networks are truly unique, yet little understood. They are designed as a trusted source (can be used as enterprise intelligence not just exchanges) to synchronize the mutual data and processes between the trading partners. Rather than transaction oriented (you send me your data and I pump it through my layers of security and systems, analyze and send you a response), the network is a shared model based on agreement in policy, process, security, etc. A core attribute of this Network model is that it separates the physical supply chain (flow of materials) from the logical supply chain (flow of information) to enable mobility e.g., tracking inventory, people, etc., in motion; providing: Peer to Peer access. A kind of multi-threading, freeing information flows from the bonds of a single bi-directional partnership; allows information to be captured and simultaneously shared with everyone (provided they have access privileges.) And as such, becomes the authoritative single version of the truth one object (data source) which is updated by flows of information stemming from the events and ideas of the value chain. One other technology note and not trivial is the emergence of auto-identification technology and mobility as true business platforms. These technologies have the potential to enable new linkages beyond the traditional thinking about business events, (which are already captured by POS, or barcoding and other data collection systems.) Page 3

4 If you think of decisions as the brain, and execution of those decisions being carried out the limbs, then the Network is the central nervous system, and RFID is your senses, all working together now to create connectivity and responsiveness. Mapping the supply chain universe So, with these two new issues addressed (though briefly), the new supply chain model and the new technology, we are back at the gym. How do I think Delivery Focus about how these innovations fit into my decision making. I need to revise my thinking a bit to incorporate them into my program. For any technology-enabled SCM transformation, we need to look at several key variables or dimensions which are critical to achieving a required business outcome. Figure 2 below shows the 3 key dimensions: 1. SCM Process Functionality: What business functionality and workflows does the product have? Figure 2 2. Delivery Architecture: How is that functionality delivered? Do I need to install the system at my premises? Or is it web enabled, 3rd party hosted, etc.? 3. Domain Knowledge : How much can the vendor help the transformation? Let s get away from the concept of Best of Breed. We always found that term a little strange. After all, it s not a dog show. We will explore these concepts in a little more depth. First, what are the relevant SCM processes? The following process grid shows the spectrum of SCM processes at different decision phases: Page 4

5 Figure 3: Supply Chain by Phases Source: Center for Intelligent Supply Networks, The University of Texas at Dallas This view, though seemingly obvious, has become a wrongly passé component. This is a logical starting point to determine which business processes you are trying to improve and how. Due diligence is still required, so getting deep into the details of the map is required, to determine what needs you require on a functional level, and how your evolving requirements will be supported. Delivery architecture now matters Old models for software selection were focused on getting the right business functionality to support supply chain processes that were largely managed within the enterprise. But as more processes get outsourced to partners, the delivery architecture becomes a key component of my technology selection. Page 5

6 Figure 4: Collaborative Views By looking at the individual process cells and asking simple questions like what do I do within my four walls, and where do I need to collaborate? etc., both a physical and a logical boundary starts to emerge. For example, a company like Dell may physically touch only 20% of the end-to-end supply chain, but logically wants visibility over 100% of it. This sets up the next decision criteria, which is the Delivery Architecture. It poses both a business process question, as well as a technology enablement question, which many businesses are thinking through. Delivery Architectures have nuances, which we don t have the space to discuss here, but suffice to say that a few elements are license, hosted and on-demand. In the above figure 4, we show an example of a Brand Owner who has outsourced much of the supply chain. As we think through the systems boundaries," we see that at the Execution level, they still need an Order Management and Procurement system, but may not need a Transportation Management System or Warehouse Management System. However, at the Planning level, they require close collaboration with their partners to coordinate new product introductions, critical component sourcing, production schedules, logistics capacity, etc., on the supply side, as well as coordinate promotions and post-sales returns and service on the demand side. As you map these boundaries and look at the links with your trading partners, the architecture underpinning becomes critical, because if you are strictly addressing an internal solution, the traditional license software is the likely approach. But if your goal is to synchronize models, a network approach might be required. Buying and installing a package behind your firewalls will not provide the level of visibility chain you are seeking. Or worse, trying to do that will unnecessarily drive up the Total Cost of Ownership. Page 6

7 Domain knowledge Back at the gym, I have this cool new equipment, but how do I actually use it, adapt it to my situation. I want my vendor to also be my personal trainer, potentially. Vendors, on one end of the spectrum, only offer technical assistance to get the product up and running. On the other end, they are capable of actually taking over the process and managing it effectively (3rd parties- 3PLs, EMS, etc.) This might seem obvious, but lack of domain expertise within the team is often the source of many poor implementations. Here again, we examine the desired business outcome and ask the question, Where does this fall on the spectrum of process automation vs. improvement? If exploiting the new technology requires process redesign, new knowledge, and new skills, then the solution provider s ability to effectively transfer that domain expertise to the user team is a major consideration. The question becomes not just does the vendor really know my industry and business as well as I do, but rather do they know this piece of it much better than I do? Are they actually adding knowledge and expertise to my total equation? Domain Knowledge also addresses the Value Proposition. Technology alone does not deposit the ROI. A blending of reinvigorating the process along with the scalability and smarts embedded in the code is what is needed. Domain Knowledge can also be reflected in information services catalogues, content data, semantic mapping $ data cleansing services, etc. that the firm may provide. The reality in supply chain is that there are many intangibles that cannot be fully encapsulated in the technology application, so what else can the technology firm bring to the table? If you take this dimension to its logical extreme, the ideal solution to achieve the desired business outcome may be to outsource that process to a partner who will take responsibility for the enabling technology. Bringing it all together - Collaboration Demands a New Delivery Architecture Thus, when selecting a solution provider to assist in the transformation, one should look at all the criteria within these 3 dimensions. The greater the convergence between the 3 sets of criteria, the better the fit. So how to map these components? Again, we don t have enough time to deal with all the nuances of technology, but let s attempt another example; a Transportation example. If I own a private fleet, behind the firewall application can work just fine so Business Functionality and Domain Expertise is my game. However, most firms rely on a huge network of players to manage their freight. All the trading partners shipper, customer, freight forward, carriers, and 3PLs want access to the single Page 7

8 version of the truth, at all times 3rd party integration. Here is where delivery architecture is central to your decision making. This example is a bit hard to configure in a two dimensional universe, but suffice to say that all three dimensions are now critical. Without the Delivery Architecture addressed, specifically addressing on the web how architecture will support your business vision, supply chain visibly will not be achieved. Figure 5: Assessing Solution Providers Conclusion: Putting the customer at the center of the universe! So in conclusion, our effort to chart the Supply Chain Universe is not so much to create a map that is all that revolutionary, but to get back to a quality approach that includes your contemplation of how your 3Pe - policy, processes, performance and your enablers work together. And by starting from what the business model and process will be, then you are off to find a complementary solution that enables the process and performance goals of the enterprise or federation. This makes the technology selection and fit to the Supply Chain Universe. After having seen too many vendor presentations that show a universe centered on the vendors products (rather than your needs), we cannot underscore the importance of discarding that outdated and irrelevant mindset. It is your Universe take care of it! For more read: The Delivery Architecture - What it Means For the Cloud and On-Demand technologies go to ChainLink Research Page 8