In Supply Chain, we have to keep the business flowing, regardless of the variations in demand. Integrating key partners, sharing information and events, using dashboards and identifying alternative options to react to the unexpected help operations and make the supply chain more robust and responsive.

 You will obviously ask the question, how we can do that as there are many things happening outside our control. To close the loop, the first thing we need to do is gain control of the operations. So, we better know what happens throughout the ecosystem. This is where the integration with the partners comes in.

You will probably point out many companies provide solutions to link with partners and you are right. Unfortunately, most limit themselves to addressing one specific issue. Some look at inventory levels, other at managing the logistics chain. But to have a complete view of the operations, I need to address all of the above and a series of others. To nail things down, two types of information are required:

• Information on inventory levels, machine throughput and availability, parts or ingredient consumption, forecasts, order and order status etc. should be made available on regular time intervals. This will allow me to understand the "steady state" and extrapolate what will happen without disruptions


• Events have to be communicated when they occur. Advanced Shipment Notifications (ASN), machine downtime, material shortage and many others, should allow early visibility of the upcoming trouble, if I may say so.

Dashboards, using the steady state information, allow me to look at key performance indicators and understand the health of my ecosystem. An event management system, using the messages generated by the supply chain, trigger action. I can then use the gathered information to identify how to minimize the disruption. The end-to-end view allows me to review alternative options and take a decision quickly.

What do I need to put in place to gain that understanding? First, the partners need to agree to share information and events. They will do that if they understand the advantage they gain from doing so. This is where many relations break down. If the supplier realizes the information gathered is used to force price reductions, the exchange will stop quickly. Trust has to be established. Obviously, not all partners have a similar importance in the supply chain. It's worth looking at who are the key ones, and develop such relationships with them first. As earning trust takes time, you should be patient, and realize gaining full vision of operations is not something achieved quickly. The benefits, however, are huge, so it's worth taking the time to do it properly.

Second, the information flows need to be established. Beyond the set-up of the infrastructure, and I would suggest the use of either a business exchange, such as HP's own Business Exchange Services, or a cloud based solution, as described in previous posts,  This however is not enough. Three more elements need to be in place, data, processes and metrics.

Let me start with the data. To understand each other, partners need to agree on the exact meaning of the information they transfer. They have to agree in which measurement unit and in what format they send a specific piece of information. They should gain consensus on what this data really means. Standard enterprise data models can be used to gain agreement. One such model, the Supply Chain Operational Reference Model is quite useful not only to identify data items, but also the business processes established between the partners and metrics, the other two elements required. By describing business processes, partners also define who does what, and that is probably the most important element. The metrics in turn not only allow to see what is happening, but prepare the tactical analysis I will describe in my next post.

The last, but critical step, before going live, is the partner on-boarding. All elements described above are tested. The exactness of the information is verified, the electronic connections are tested and messages are transferred to ensure everything works fine. You may want to use experienced people for your first on-boarding, as this activity will have an immediate impact on how quickly you can run your operations and close the loop.

I'd like to start a series of blog entries titled "Close the Loop" and addressing how, through a better use of supply chain information, companies can improve their operations, creating a more agile ecosystem while reducing risk.

In this entry, I would like to give you an overview of the different elements required to close the loop and I will spend the following entries to go more in details in each of the components.

Yesterday I was at a conference titled "Achieving Excellence in Capacity Planning", and pointed out one of my favourites. "Forecasts are always wrong" and that is what we are starting from to manage our Supply Chain with the hope to have neither stock-outs nor excess stock. This is remarkable, isn't it? Over the years, companies invented many processes to achieve this; the latest is called S&OP, Sales and Operational Planning. This process is becoming the central subject of an increasing amount of conferences and white papers.

However, what we often lack is a deep understanding of how the Supply Chain really operates and reacts. To optimize it, reduce costs while increase responsiveness and agility, we fundamentally need a deeper understanding of how the system reacts. The only way to achieve this is by analysing specific events and how they rippled through the ecosystem. To be able to do this, you will need information of what happens at different points in the supply chain. You need visibility, which you can only obtain from working closely with your suppliers and distribution partners.

You can use this information in three different ways:

• First, understanding what happens now, gives you the opportunity to identify what goes wrong and react to it quickly, reducing the disruption that could be caused by the event. This is what I call the Operational use. It will; allow you to serve your customers better and to improve your service level agreements. Nevertheless, it will not help you to avoid the same problem appearing again in the future. You focus on the moment itself and react to it.


• To avoid the problem in the future, you need to understand why it is appearing at this moment in time. Going back and replaying what has lead up to the event may be an interesting way to find out. Actually what you do here is to add the time dimension. You look at trends, at cause and effect, at how the system ended up in that situation. This is what I call the Tactical use. The operational team does not have time to look at this; their objective is to keep things going. Typically, a business or process analysis team will take care of gaining this understanding.


• Through understanding how the ecosystem behaves, you can establish the key factors that drive it. This will allow you to develop a mathematical model that will react in a similar way as your supply chain. Why would you do this? Well, having such model available, allows you to test potential changes or key decisions you want to take and see how they would avoid the pitfalls you have fallen into previously. This is what I call the Strategic use.

The operational use tries to get you out of trouble with your customer, the tactical one will help reduce the risk of the same problem appearing again, and the strategic one allows you to change the way you operate, improving your responsiveness and make your supply chain more robust. Combining the three in a continuous improvement cycle is what I call closing the loop.

Many things need to be in place for you to implement all three use cases. In the next blog entries we will focus on what is required, how you can go after this and what the benefits will be.

The latest recession has gotten a profound impact on many supply chains and forced rethinking strategies. In a quest to reducing costs, many have diminished safety buffers, established lean thinking, and redesigned their flows. In that process they have made themselves more vulnerable to variance, while their objective is to maximize sales. Doing so implies a much closer relationship with ecosystems partners. Cross Supply Chain collaboration is critical to gain visibility, address issues early and improve agility.

Many "Recession Survival Kits" are out there, and although they will add value and improve the situation, we should not forget the simple communication & collaboration aspects. It is when people talk, share information and experience, and jointly come up with solutions, that problems are resolved.

What is needed to build a culture of collaboration throughout an ecosystem. Obviously, there are technologies out there that facilitate the sharing of information, the interaction and the visibility. Private and public hubs, unified communication, supply chain visibility, are all tools that can be used to develop supply chain communication and collaboration. NiST, in its definition of Cloud, introduces the concept of Community Cloud. This is probably the next technology that addresses ecosystem collaboration.

But my point today is not so much on the technologies to be used, but rather on the intangibles that need to be in place to foster the collaboration. I'd like to highlight following elements:

• Building Collaborative Relations. It may sound obvious, but there must first be a willingness to collaborate. In the late 20^th century, the principle of squeezing suppliers to the last nickel has been promoted and presented as the only way business could be done. Such approach has benefited some companies and pushed many of them to bankruptcy. As a side effect it has inhibited collaboration amongst suppliers and customers, as there was a fear that any information shared would be used to squeeze a little more. So, changing the paradigm and approaching the supplier relationship from a more collaborative angle is mandatory for developing the visibility, communication and collaboration required. Procurement departments may have to adjust to such approaches and move to collaborative sourcing, but they should do so, as it will help the ecosystem becoming more responsive at a lower price point.


• Trust. Sharing information, collaborating, adding value to the community, requires trust to be developed amongst the partners. According to the definition provided by the Merriam-Webster's Online Dictionary, trust is the assured reliance on the character, ability, strength or truth of someone or something, one in which confidence is placed. This very much corresponds to the trust that needs to exist between partners in the supply chain. They need to be willing to hear the bad news, to have confidence in each other, to understand that they both will act for the common good etc. Building such trust between ecosystem partners takes time. This is why I would advocate it can only be established with a small amount of partners.


• Win-Win. This is an overused term, but the essence of it is critical. If the partners do not have the impression they all win from working more closely together, they will not pursue the relationship. It is often counter intuitive for companies to think about how a particular action may benefit their supplier. They are in business to make money, isn't it? But helping the partner and ensuring he also gains benefits, has demonstrated over and over again as a wining proposition in the long run. Despite the fact Wall Street pushes us to focus on this quarter's revenues, looking at long term benefits, ensures the viability of the enterprise. And this should never be forgotten.

 When looking at implementing communication & collaboration tools along the supply chain, the above 4 aspects should never been forgotten. The technology is there, but alone will not provide full advantage. Combining technology and the more intangible aspects are critical to gain full return from a unified communications & collaboration project.

There are an increasing number of cloud based Supply Chain services, offered as SaaS, appearing on the market. But that is not the subject of this blog entry. Actually the question is way simpler. Are you aware of all the players participating in providing you the latest SaaS service you have bought?

Let me take an example. Amitive is an SaaS provider, delivering Community Supply Chain Management services, or as they call it, "SCM in the Cloud^TM". I don't know the company, it just happened to be one that appeared in Bob Trebilcock's review of SCM software in the Cloud.

Going to Amitive's web page, I tried to understand whether they run their software suite on their own environment, or whether they depend on another provider to do so. Finally on page 7 of their white paper "Amitive SCM in the Cloud^TM: Catalyst for the Great Leap Forward in SCM" I find following phrase "Amitive manages a customer account via our multi‐tenant servers in the secure datacenter of our world class infrastructure partner". No information about who this partner is. Later, back-up, scalability, high availability and disaster recovery are highlighted. Are all these provided by the same infrastructure partner or are other ones involved? No information is provided.

Again, I just picked this company as an example. What I want to highlight is the fact most of the SaaS providers use a supply chain to provide their services to their customers, who most often do not even ask questions about the partners, nor assess the risks associated with these partners.

As in physical supply chains, something going wrong with a supplier may result in major disruptions in the whole Supply Chain. One such examples happened on August 8^th, 2008, when a cloud backup service, called The Linkup ceased operations. The company actually used the services from another company, called Nirvanix. Customer data got lost on the way, resulting in closing the service. I found a good description of the whole story in a Network World blog entry from August 11^th, 2008. Again, my objective here is not to argue about this particular case, but to illustrate the importance of understanding the supply chain one subscribes to when using a cloud based service.

You could argue that, like in the "real" world, there are alternatives. And that is indeed the case, but the lack of standards in the cloud today, mean that moving from one infrastructure, platform or service to another is not an easy task.

It is critical for companies wanting to use the cloud in general and Software as a Service in particular, to understand the players in the service provider supply chain, in the same way as they would do for their physical goods supply chain. Similar tools and techniques should be used during that evaluation. As CIO's and IT teams are less familiar with this than procurement departments, they may want to borrow expertise there for such evaluation.

Two weeks ago I was asked to run a workshop on collaboration at an event in China. Based on some of the ideas I shared in an earlier blog, I developed the content of the workshop. What daunted on me, listening to people in the audience, is that both the users and the providers keep talking about tools, without looking at the full portfolio of needs. Let's look at what those are.

I am starting from a very simple model, in collaboration both structured and unstructured information needs to be shared, while interactions may have to be synchronous or asynchronous. Let's look at each of the four areas in a little more details:

• Asynchronous exchange of structured data. Most business to business transactions are of this category. Indeed, information is shared by the sender when it becomes available, and picked up by the receiver when it can be processed. There is no expectation by the sender of an immediate response. EDI transactions for example, follow this scheme.


• Asynchronous exchange of unstructured data. Exchange of documents, review processes, calendar planning etc., typically follow such scheme. Here again the information is shared by the sender at a particular moment in time, and processed by the receiver when he/she has availability. A good example is the review of a document. The author will send it when he/she finishes writing the first draft. The reviewer will take time to review and post comments. When done the document will be sent back to the author who will take the feedback into account and issue draft 2.


• Synchronous exchange of structured data. Some collaboration requires immediate commitments. For example, when an OEM requests whether a contract manufacturer has the necessary capacity available to produce a particular batch of product, the OEM expects a response (positive or negative) allowing him to allocate the production to this or another supplier. This is a two way collaboration where the messages are directly related to each other and as such synchronous.


• Synchronous exchange of unstructured data typically relates to direct human interactions or joint work on a document, a CAD file etc.

You are probably saying, what's the issue? We use B2B software for the first and the third category; we use e-mail for the second and unified communication and telepresence for the fourth. This is how many companies look at the collaboration issues. But they forget one thing, what if within one conversation, we move from one category to another. How do we keep track of what has happened and how things evolved?

Let me take an example. Let's assume an OEM and its contract manufacturer jointly work at the development of a new product. First specifications are written. The OEM develops the first draft, sends it to the CM for review and comment. The CM realizes that by slightly changing the specifications, manufacturing could be done cheaper, resulting in benefits for both companies. They send an updated specification to the OEM. All this happens through e-mail. But the OEM is not really convinced and decides a synchronous interaction is required. So, a call is set-up between the parties and a negotiation takes place, after which a new version of the specifications is developed. At this point in time at least two technologies have been used. But now, the actual development starts, using CAD and CAE tools. Subsequent versions of the design are exchanged to ensure manufacturability, regular design reviews take place, till the product is finalized and production is getting planned. Engineering change management tools, collaboration and communication tools are used throughout the process, but how do we maintain consistency of the information and logging of all decisions taken.

You may ask yourself why this is important. Well, let's assume the product has warranty problems, how can we identify which decision got us in trouble, allowing us to understand better what happened and improve things in the future.

The tools exist today, but each of them is taken in isolation. Google seems to be trying to address that through their Wave project, but Wave is focused at consumers. Who will address the true problem of collaboration in the enterprise space, particularly now that business travel has been reduced while companies become more international? Employees are expected to increase their productivity while neither tools nor training is provided regarding global collaboration.