Monthly Archives: July 2010

Are You Ready for the Black Swan?

As recent events have shown us again and again, he’s coming. You better be ready. This means you have to stop worrying about death by a thousand white swan-bites, because, having dealt with the flock day-in and day-out, you know how to deal with them. Their bites might hurt a bit, but you know that you’ve gotten quite good at sterilizing and bandaging the wound so that it heals fast, because you wouldn’t still be around had you not. However, you aren’t (as) familiar with the black swan yet. You are unaccustomed to the poison that accompanies his bite and, chances are, you aren’t stocking the antidote to treat it. This is problematic because the venom is fast acting, and if you don’t treat it in time, it can kill you.

Just because the appearance of the black swan is a fourth quadrant extreme event which cannot be statistically predicted, doesn’t mean that you can’t plan for it. That’s what real risk management is all about. True risk management is all about figuring out where the black swan could appear, what type of damage it could do, and how you will contain the damage and clean up the mess before it spreads beyond your control (and bankrupts your company).

It’s identifying those things that everyone thinks can’t go wrong, but that can, in actuality, go extremely wrong if an extreme event occurs. Like an unexpected market crash, an earthquake in a low-risk area destroying a factory, or an uprising closing a border. And then it’s having damage prevention or containment plans (with necessary equipment and resources ready to go) to deal with a sudden loss of supply, extreme market volatility in the preferred currency markets, or a lack of containment when an earthquake or explosion causes chemicals to start leaking rapidly. Because just like an overinflated balloon will eventually explode with the pressure, so will anything else we keep pumping money or resources into with expectations of a perpetual performance or growth. As nature has shown us, everything breaks down eventually. Even mountains crumble. And it doesn’t necessarily take a deluge to wash away your supply chain, and your company with it. So get ready for the black swan, and maybe you’ll be the one to survive his bite.

Share This on Linked In

A Hitchhiker’s Guide to e-Procurement: Purchase Orders, Part I

Mostly Harmless, Part VI

Previous Post

Formally, a purchase order is a commercial document issued by a buyer to a seller that indicates the type, quantity, and agreed upon prices for one or more products or services that the buyer is offering to buy from the seller. Once the seller accepts the purchase order, it forms a (one-off) contract between the buyer and seller, who will deliver goods and services at the agreed upon prices, in the agreed upon timeframes, to the buyer who must then, upon receipt of the agreed upon goods, in the agreed upon condition, make payment to the seller for the agreed upon amount.

A purchase order is the result of an approved requisition, but the relationship is not necessarily one to one. One requisition can generate multiple purchase orders, and this will commonly happen when a purchase order contains requisitions for goods and services from multiple suppliers. And while normally there will be one purchase order per supplier, if the goods and/or services are coming from multiple locations, there might be multiple purchase orders per supplier. In addition, a purchase order might be associated with more than one requisition, as requisitions from multiple buyers for similar goods to a similar location may be bundled into a single Purchase Order to save delivery and processing costs. As a result, the e-Procurement system must be capable of handling the many-to-many relationship between requisitions and purchase orders (and suppliers).

In addition to all of the information tracked on the requisition, the purchase order must also track approval information, delivery information, payment terms, and any other specific information required by the supplier. It must support attachments and include any attachments, schedules, or statements of work that are specified as necessary in any contracts that are in effect.

Furthermore, since the delivery of goods and services will generally result in the production of goods receipts and invoices, the e-Procurement system must support the association of purchase orders with the corresponding goods receipts and invoices, which, like the purchase order and requisition relationship, can be many to many. If the order is large, or if some items are not immediately available, a supplier may ship the order in multiple shipments, which would result in multiple goods receipts and which may be accompanied by multiple invoices.

In addition to tracking all of the relevant information, the system must be capable of translating the purchase orders in the standard EDI and XML formats that are used by the primary suppliers and electronically delivering them to those suppliers who have networks, marketplaces, or another on-line presence capable of automatically receiving an electronic purchase order.

When evaluating the purchase order capability of an e-Procurement system, which should support tight integration with the invoicing module, one should keep in mind the associated challenges of purchase order management, keep an eye out for best practice support, and insure that the solution will deliver the intended benefits. These topics will be addressed in the next post.

Next Post: Purchase Orders, Part I

Share This on Linked In

Saving on Systems Integration Costs

If you’ve ever bought an enterprise system, you know that the sticker price is usually only a small fraction of the total cost of ownership and that the implementation and integration costs can dwarf the sticker price by an order of magnitude. As a result, integration costs often present supply management with an opportunity to save six or seven figures. But how? Especially when 70% of enterprise projects fail to deliver on their initial promise?

In a word, planning. According to several experts in the field, the most common problems that arise when companies set out to integrate procurement, distribution, warehousing and communication systems come not in executing their plans, but rather in conceptualizing them. The reality is that if your plans are good enough, you can get a junior team fresh out of an India technical school to implement them successfully*. But if the plans aren’t good enough, you might as well take that money to Las Vegas, because those 10% odds of success are better than the odds of your project succeeding.

Not only do you need a shared view of success at the enterprise level, as discussed in this article on drawing the lines on system integration, but you need a detailed plan that describes what systems will be integrated, what modules will be linked, what data will be exchanged, what functionality will result from the integration, and what success cases look like. Coding is rarely the challenge. It’s usually knowing what to code.

* Unfortunately, the doctor has never seen plans this good. It is possible to create them, but it seems that companies never spend enough time in the planning stage anymore …

Share This on Linked In

Before You Take to the Clouds

… where you are likely to experience asphyxia, hallucinations, brain-damage, and death, make sure you secure your rights, namely:

  1. You own your data,
  2. you’re entitled to the service levels you are promised, and
  3. you have a right to come down when you’re ready to breathe again!

As per James Urquhart’s Cloud Computing Bill of Rights, your data is your data. This means that the vendor:

  • must never claim any ownership of any data you upload, create, generate, modify, host, or otherwise associate with your IP;
  • must always provide you with APIs that not only allow you to upload data as needed, but to download all of your data in a standard format at any time; and
  • must inform you where your data is being hosted and must host only at those locations you agree to.

Furthermore, while it is your responsibility to undertake any integration and perform any necessary maintenance that may be required, from time to time, that you agree to, it is fundamentally the vendor’s responsibility to meet the service targets they promise. This means that vendors:

  • must do everything in their power to meet service level targets;
  • must monitor service levels and give customers access to the same metrics and logs they use to monitor those service levels;
  • must not terminate your contract for any reason not explicitly stated as grounds for termination in the contract; and
  • must not invoke “act of nature”, “act of god”, or force majeure clauses except for true force majeure events which could not be predicted or prevented against (occasional loss of power from the main provider or loss of internet from the main provider is to be expected and power, internet, and other key systems must be fully redundant, etc.).

But most importantly, you have a right to come down when you’re ready to breathe again! The vendor, subject to the terms of the agreement:

  • must let you extract all of your data and end the contract whenever you have the right to;
  • must not charge you to download your data; and
  • must not charge you any additional fees other than any early termination penalties you agree to.

It’s your data. It’s your solution. It’s your business. And if you decide down the road that you don’t want to experience asphyxia, hallucinations, brain-damage, and death, that’s your right!

Share This on Linked In

Speaking Like a CFO — Part II

Today’s guest post is from Robert A. Rudzki, President of Greybeard Advisors LLC, who has (co-) authored a number of acclaimed business books, including Beat the Odds: Avoid Corporate Death and Build a Resilient Enterprise, On-Demand Supply Management, and the supply management best seller Straight to the Bottom Line.

Another important aspect of Speaking Like a CFO is knowing how to build a business case in support of your overall transformation agenda, as well as business cases related to specific subjects such as technology investments.

When we work with clients, we prefer to start with a business case from a total transformation perspective. Why? It is part of a logical sequence. Once you’ve assessed your current state and compared it to best practices, identified the opportunities from successfully transforming your practices, and designed the detailed roadmap to get you there, why not request the full amount of resources needed to do the job well?

It might sound optimistic to ask for more resources when the current business outlook for your company is weak — but it can work if you approach the subject in the manner I described. In fact, we’ve worked with several companies who — as a result of following the process outlined — added more resources to their strategic procurement staff during the recession. Today, they are receiving the bottom-line benefits of taking that bold leap.

The alternative, quite frankly, is to be subject to the same headcount reduction guidelines that often are widely applied to all departments in times of business stress. That’s not where you want to find yourself; and, quite frankly, there is no reason to end up there.

Thanks, Bob!

Share This on Linked In