Search results matching tag 'supply chain'

Closing the Loop, Optimizing the Supply Chain

christianverstraete — Fri, 20 Nov 2009 18:50:00 GMT

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 Cost of Cloud

christianverstraete — Fri, 13 Nov 2009 10:33:00 GMT

Does the cost of cloud computing limits the usability of a community cloud to support a supply chain? This is really the question I'd like to address today.

Last April, McKinsey and last September, IDC have done an exercise of costing the difference between running applications in the cloud and in a datacenter. The McKinsey study has resulted in very strong reactions from bloggers, pointing out "McKinsey's Cloud Computing Report is Partly Clouded" to take one example. The IDC presentation, done at the Cloud Computing Summit, got much less exposure. Computerworld UK and Linux.com comment, surprisingly rather in a positive note. Why is that?

Well, where McKinsey was reasonably vague in their comparison, IDC very clearly pointed out they compared running applications in a next generation datacenter versus running them in the cloud. In the current terminology, you could argue that a next generation datacenter is nothing else than a private cloud, so that the debate becomes irrelevant.

Highly virtualized datacenters used by large enterprises can achieve efficiencies that are very close to the ones reached in public clouds. Cloud companies needing to make profit, it is logic that such private clouds will be cheaper in the long run. Fundamentally this is what IDC demonstrates. The whole argument for the cloud is the one of elasticity, and the case study of Animoto is often quoted. They managed to get from 50 to 5000 servers in a week-end. This is really great, but let's be frank for a minute, how many large enterprises are confronted by such issues? What is the true demand variability?

In all the discussions above, we are talking about hosting existing functionality in the datacenter or the cloud. But what should we do with new functionality? In several blog entries, I have been talking about the development of community or ecosystem clouds to support an improved management and collaboration in the supply chain. These functionalities do not exist in most enterprises, and the question should really be whether such functionality needs to reside in the datacenter or in the cloud. Today, I would argue that it should be in the cloud for multiple reasons:

First, building the required infrastructure in a datacenter costs money, it's typically CaPEX, which is not highly regarded by most financial people these days. Putting the functionality in the cloud limits or eliminates the start-up costs, and turns the on-going cost in OPEX, a move that is regarded more positively by finance.
Second, establishing the visibility and collaboration function in the cloud can be seen as a natural evolution of existing B2B exchanges. Supply Chain partners, already connected to an exchange might be able to use similar connections to the community cloud. It makes the development of such a cloud acceptable by the supplier base.
Third, using the cloud establishes a neutral party that maintains the service. It builds trust and may facilitate the acceptance in the supplier community
Lastly, using cloud technologies, the shared data can remain under the control of the data owner, as the technology allows the access of distributed data. Suppliers can decide which information to share, while avoiding the proliferation of that data across the internet.

Obviously, security is an important topic to address, but progress is slowly but surely made. Governance and how the service evolves over time is the other, is another aspect that needs to be addressed. Some large OEM's may take the lead and direct their suppliers to attend, but in most situations, we expect a trusted third party to run the service. Obviously, in that case, having a team looking after the evolution of the service, what new functionality is taken in service when, becomes important. Building a community around the service will make the members feel part of a team, which is exactly what you are looking for to establish a successful service.

Culture and the Supply Chain

christianverstraete — Mon, 09 Nov 2009 10:10:00 GMT

In my previous post, I spoke about the tangibles and intangibles of Supply Chain Collaboration, but intentionally did not address one element, the cultural aspects of Supply Chain Collaboration. Companies have increased the outsourcing of their manufacturing and over the years, China has become the "Factory of the World" in the eyes of many. In a quest for reducing costs, companies have gone to India for services and China for manufacturing.

What many companies forget, when outsourcing their manufacturing or some of the back-office services (eg. Purchasing processes), is the cultural issues inherent with such moves. First, employees that used to go down the hall now have to coop with time differences, remote collaboration and all the usual issues related with moving activities to different locations. On top of that, the latest recession has reduced travel, resulting in more work to be done over the telephone. And then there are the culture clashes. The expected benefits are often not met within the timeframes expected as a result of these culture shocks.

Particularly employees living in large countries with more homogeneous cultures have difficult to understand that people may not react in the same way as they do, that the same word may not have the same meaning, and that, as a result of those misunderstandings, expected activities are not performed.

To share my personal experience, when I started working with people in India in the mid 90's, I took yes for granted. In my culture, when somebody says yes, that means he/she will do what has been said. I got really frustrated when I realized things were not been done, that I was not respected, thinking people were not listening at what I asked. It took me a couple visits to India, where I experienced the difference in saying yes, and several discussions for me to understand yes had many meanings out there. Actually, one of my local friends one day put it to me: "In Hindi there are 40 ways to say yes, and no way to say no". Whether that is correct or not, does not really matter, but it is important to understand that, as simple of a word as the word yes, may mean very different things to different people.

In a blog entry titled "Culture clashes and how to avoid them", Brenda Townsend Hall gives a number of examples related to culture clashes in enterprises. They are related to the UK culture, but many of us can recognize the implications for their own cultures.

So, when starting to work remotely with people, it is important to identify the differences in culture, understand how people react to events, what key words mean for them, how they experience leadership and management etc.

As our work environment becomes more diverse, due to immigration, people will start experience the implications of cultural diversity in their day to day work. This may help resolve some of the problems related with outsourcing. However, to take full advantage of outsourcing, companies need to address the cultural diversity of the future teams. I would suggest the process starts with a detailed description of the culture of the country where the activity is outsourced to. Taking the time to explain what is important for people, how they react, what is important for them etc. will pay later in the process. One interesting approach is, once the teams have started working together, to continue feeding them with general information of what happens in the other location. This may include politics, sport, cultural events etc. Such awareness will facilitate discussions between the parties, allowing the members to know each other better, in turn building trust and facilitating communication. Also make sure employees know some words of the other language.

One very simple element we implemented when working with remote teams, was the exchange of photos, allowing us to depict the person that was speaking at the other end of the telephone.

Outsourcing manufacturing to China? Well you may want to look at "Formation of Cultural Competitive Force when doing Business in China", written by Maohua Sun.

Global operations are affected by cultural differences, denying it or refusing to address the aspect does not help in the long run. So, to improve the working of their Supply Chains, companies should address the cultural differences of its ecosystem partners to foster a global team. It is not easy but will pay of greatly.

Feel free to share your cultural experience by contributing to this blog.

The Tangibles and Intangibles of Supply Chain Collaboration

christianverstraete — Mon, 02 Nov 2009 11:38:00 GMT

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.

EFPIA Announcements

StevenSimske — Mon, 26 Oct 2009 17:12:00 GMT

Hi, all

The next few blogs will point you to information on the recent announcement of the EFPIA 2D labelling scheme. The EFPIA is the European Federation of Pharmaceutical and Industries Association.

In-Pharma's article on this announcement is:

http://www.in-pharmatechnologist.com/Packaging/2D-barcodes-make-faking-less-attractive-says-EFPIA/?c=JiBz%2FX6W8967KGa2Liah%2FA%3D%3D&utm_source=newsletter_daily&utm_medium=email&utm_campaign=Newsletter%2BDaily

Importantly, as our partner Siemens notes,

[Siemens] "will provide connectivity for pharmacies and manufacturers to the EFPIA database, which is hosted by Hewlett Packard (HP). Manufacturers will populate the EFPIA database with the serial numbers of the saleable units shipped, and pharmacies will read those serial numbers at the point of sale (via 2D barcode) and authenticate the unit sold against the EFPIA database."

In other words, the cloud enables the crowd. 2D barcode readers are not just in the hands of the pharmacists. Look for us all--corporations, enterprises, brand owners, shippers, retailers, consumers, environmentalists--to embrace this approach. It helps level the playing field for everyone, except--one hopes--the counterfeiters.

Cheers,

Steve

Is Supply Chain Data safe in the Cloud?

christianverstraete — Mon, 26 Oct 2009 12:28:00 GMT

At the Gartner Symposium, last week, HP's CEO Mark Hurd was quoted about the lack of security in the Cloud. This is only one of the voices heard about cloud computing security. So, should we stop thinking about linking our partners in the cloud to gain visibility in our Supply Chain? Maybe, maybe not. What vulnerability are we talking about? In public clouds there are three major:

The transfer of information from your partner to the cloud. There standard SSL security (with 128 bit encryption) is used. This issue is not specific to cloud, it is actually applicable to e-commerce etc. Yes, there have been breaches at that level (nothing is fully secured), but we continue shopping, don't we. To address this, some cloud providers allow VPN connections, but often more in a "private cloud" type offering.
The hacking of the datacenter in which the data may be maintained. And here again this has happened in multiple environments. Mark Hurd pointed out that HP gets 1000 attacks per day. Obviously, hosting applications and data in the cloud, forces companies to trust the cloud providers who, for very understandable reasons, do typically not highlight/explain all the security measures they take. So, this is a chicken and egg problem. Data centers have been hacked, but it is not stopping companies storing credit card numbers etc. in internet enabled datacenters.
The third vulnerability is the least known one. As the cloud implies the running of applications in shared environments, using virtual machines, there is a possibility for tech savvy hackers to co-locate themselves with the application they want to hack and penetrate that VM container. This is obviously only applicable in public cloud environments. The security at hypervisor (the software allowing multiple VM's to run on the same hardware) level is the main question here. Unfortunately in this space there is not a huge amount of experience yet as this is rather a young area. HPLabs is currently working on the concept of secure cells to address this.

So, this being said, should we use cloud computing to share our ecosystem information? The fundamental question to ask ourselves is how private this information really is. Let me give an example. If you are a cosmetic company, you are probably not interested in putting perfume recipes in the cloud, as that is what makes you unique. So, even with a very small chance of the information becoming public, it does not make sense to take that risk. On the other hand, marketing material and prices/discounts are publically available. Yes competitors may have to search a little, but they can/will find the information if they wish so. Having that information in the cloud does not augment the risk drastically.

So, prior to using cloud services to collaborate in the Supply Chain, it is important to assess the confidential nature of that information, and whether this data can be obtained by other means. Objectively assessing the nature of the information is critical to establish whether putting the data in the cloud is/or is not a real tread for the future of the enterprise and its ecosystem.

If no clear consensus can be obtained, you may want to look at intermediate solutions. For example, utility based environments such as AIS (Adaptive Infrastructure Services) provide a secure access to the environment (using VPN or leased lines). As these environments have more stringent security rules, they may appear to the community as less subject to hacking. Ultimately, the security debate is one about trust. The fundamental question is whether the supply chain community trusts the provider or not.

New security techniques will be developed in the future and will change the perception of companies. However, if companies want to start experimenting with cloud today, they should start in non-critical areas.

End-to-End Supply Chain and Metrics

christianverstraete — Mon, 12 Oct 2009 17:02:00 GMT

Last week, I was in Singapore at the SCM Logistics World 2009. My presentation was around how to build a weatherproof Supply Chain through the increase of visibility across the ecosystem. Having talked about the subject previously on this blog, I'd like to focus this time on a debate that took place amongst the participants, and this one was focused on how to look at the end-to-end supply chain holistically and identify how the performance of this one could be measured.

Over the last 12 to 18 months, companies have cut costs as never before. The smart ones have done this in such a way that their supply chains have become leaner and meaner, resulting in real savings that benefit the end consumer. In doing so, they have lowered the inventory buffers that shielded portion of their supply chain from variability and uncertainty in others, and as such increased the level of risk across the ecosystem.

So, understanding the supply chain, its dynamics, how it behaves, and implementing the management processes and governance required becomes critical. Many people will agree with the statement I just made, but it is how to do this that holds people back. Actually, when browsing the internet on this subject provides little useful information. Yes there are a couple software packages and the odd presentation (to be paid for), but nothing else. Interesting.

Companies have been focused on their supply chains for years, but they do not seem to have thought through how to measure them end-to-end. I believe there is no need to make things more complicated that they are. The industry has been using the SCOR^TM (Supply Chain Operational Reference) model for years. This model proposes for each node in the supply chain a series of KPI's. Could we use those for an end-to-end measurement? That was the debate in the corridors of the conference. Let's look at it in a little more details.

Let's look at the level 1 KPI's. The first one, Perfect Order Fulfillment, is really a Supply Chain KPI, as it relies on all partners in the supply chain to deliver their elements to ensure the final product is complete, meets the specifications and addresses the expectations of the customer. With the buffer inventories disappearing, the ecosystem is no longer compartmentalized and using this measure as an end-to-end one makes sense.

The second one, order fulfillment cycle time is an interesting one. Indeed, if the supply chain manufactures to order, it is clearly a measure of the supply chain performance. On the other hand, if the customer is delivered from stock, obviously there is only a portion of the supply chain that affects this measure. This demonstrates that not all KPI's are applicable in the same way to the supply chain. However, the exercise remains interesting.

The next three, Upside Supply Chain Flexibility, Upside Supply Chain Adaptability (The maximum sustainable percentage increase in quantity delivered that can be achieved in 30 days) and Downside Supply Chain Adaptability (The reduction in quantities ordered sustainable at 30 days prior to delivery with no inventory or cost penalties)., are by nature supply chain measures, so do fit our approach here. The same applies to Supply Chain Management costs.

Cost of Goods Sold (The cost associated with buying raw materials and producing finished goods. This cost includes direct costs (labor, materials) and indirect costs (overhead)) is one that is difficult to calculate across a supply chain as not all partners are willing to work "open books", which is what you would need to correctly calculate this metrics from a end-to-end supply chain level. So, this is probably not a good metric to go with. The same applies to two other metrics, the return on Supply Chain fixed Assets and the Return on Working Capital.

The last KPI, Cash-to-Cash Cycle Time is applicable for supply chains that work in a deliver order model, but not for the ones that deliver from stock.

All in all, a number of KPI's are useful and could be applied if the appropriate data can be gathered across the supply chain. From experience I do know the use of a small number of KPI's already makes a large difference, so while we may want to think at creating a couple more, using the ones we already have, would help companies focus on optimizing their ecosystems and in turn improve their delivery capabilities in addressing the new opportunities that appear on the horizon.

Could Community Clouds improve Supply Chain Collaboration?

christianverstraete — Fri, 18 Sep 2009 01:17:00 GMT

As President Obama announces a cloud computing initiative for the US, it is interesting to note that in their definition of Cloud Computing, the federal government includes an interesting deployment model, called community cloud. In their definition the cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premise or off premise.

Over the years, companies have outsourced parts of their supply chain, making it increasingly difficult for them to maintain full control over what happens in the ecosystem. As I have described in a number of entries in the current blog, there exist ways to increase visibility and regain control. However, they require the development of a trustworthy relationship with partners and the development of a communication infrastructure capable of supporting the information transfer in a secure manner. Around the turn of the century, hubs seemed to be the solution. They came in two flavours, public and private ones. The public ones were created mostly by small start-ups that provided services to a particular community. I remember one moment where there were around 700 different ones. Unfortunately, for the most part, the business model was nonexistent and after having burned their start-up capital, most disappeared. A few are left in specific industries.

Private clouds have survived, but they required the ecosystem leader (often an OEM) to invest in the development and maintenance of the communication infrastructure required. Some companies, and amongst them HP, have done this to build competitive advantage and it served them well. However, many did wait for a less costly approach.

A community cloud could be just that approach as it provides the partners in the ecosystem with a mechanism to collaborate without having to spend a large initial cost to set-up an infrastructure. A service provider could develop a community platform and make it available to the members for a pay-per-use model. Actually, this is precisely what GS1 and ourselves did with the Food Recall Service we announced a couple weeks ago.

Beside the benefit of not having to invest in the infrastructure upfront, other benefits are the capability of cloud based applications to access distributed information, allowing for the key data to remain on the premises of the partner and under his control. With the current security fears in the cloud, this is an important aspect.

While researching for this entry, I ran into a really interesting article titled: "Digital Ecosystems in the Clouds: Towards Community Cloud Computing" written by Gerard Briscoe from the London School of Economics and Alexandros Marinos from the University of Surrey in the UK. They actually go one step further, and propose the use of the spare capacity in the community members' data-centers as an infrastructure pool for the community cloud. They go on explaining the benefits of this approach and in particular highlight the integration of both the social structures and technology paradigm of this approach. They point out the steps required to build such approach. Unfortunately, there is one main element they do not speak about and that is the compensation mechanism for the partners that make capacity available. Obviously you can argue they have the capacity anyway, so the additional cost of running virtual machines on the infrastructure is limited. But we all know that companies expect a reward for a service delivered.

A couple years ago, a similar approach was suggested, the desktop grid. It has been used for torrent applications and others. However a number of issues remain and these include:

System security, obviously the community members won't want their applications to be affected by the cloud one that is consuming the spare capacity.
Application security, how do we ensure the computer owners do not intercept and mingle with the data processed by the cloud application
Performance, due to the wide variety of CPU's, networks and storage available, one can expect great variations in performance, making the dispatching of cloud services much more complex than in the existing cloud environments where the resources are standardized
Reliability, spare capacity will come and go at short notice as the computers used have a primary purpose, and this is to run the company's applications. Reliability of services is becoming quite complex in such environment

The community cloud as described in the article may still be somewhat of a vision, however, companies should take a look at community clouds as they may help them increase the visibility and management of their ecosystems, even if they start by running services of a cloud service provider.

Sustainable procurement: 80 % of respondents invest and the trend is increasing

vp9a83272 — Thu, 17 Sep 2009 10:24:00 GMT

As one of HP’s supply chain auditors, I always look for news and best practices relating to responsible supply chain management and procurement. This summer HEC Paris and EcoVadis published an interesting study: The Sustainable Procurement Benchmark report. The study is based on a questionnaire which was sent to procurement executives in 95 of Europe’s largest corporations. Here are my personal highlights of the study.

It is good to read that around 75% of respondents take Corporate Social Responsibility issues into consideration when they go to the market. What is more relevant for me, however, is to see that nearly a third of the respondents use CSR as selection criteria. That is good news and I would think that this number will increase even more. For us at HP, sustainable and ethical practices undertaken by our suppliers are decisive factors when we consider them for inclusion in our supplier base. Our regular evaluations and audits aim to ensure that our Social and Environmental standards based on the EICC (Electronics Industry Code of Conduct) are met by our suppliers’ factories.

The final highlight of the study from HEC Paris and EcoVadis is that around three quarters of respondents apply sustainable procurements as a measure for supplier performance. This is an acceptable high percentage, isn’t it? Sustainable procurement is at the top of the agenda and the study indicates that it is there to stay.

For those companies who are interested in learning more about responsible supply chain management, they can visit the CSR Europe portal. Whether you are a buyer or supplier, you can find a wide set of available standards and codes and a lot of other materials on best practices relevant to a sustainable supply chain.

I am always on the look out for supply chain or procurement studies. If you come across some, please let me know.

Karl Daumüller, SC SER Lead Auditor

Don't forget the Cloud Supply Chain

christianverstraete — Fri, 11 Sep 2009 19:09:00 GMT

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.