@ Supply Chain Management

T’is time to go for a boutique? I’d like to draw your attention to this list of articles by Steve Banker of Arc Advisory Group:

Top SCM Boutique Consulting Firms: Part 1, The Logistics Boutiques

Leading SCM Boutiques – Part 2, Supply Chain Planning Vendors

10 Coolest SCM Boutique Consultants

Most of the firms listed in the lists above span from small consultancies to behemoths who make the industry and in some cases is the industry. So what is it that these small fish are thinking when they play in the playground of the behemoths? By the way, why are there small fish anyways? Are the big fish listening?

Tags: The SCM boutiques, SCM players, Consultants – big and small, Arc Advisory, Steve Banker

Running down the path of metrics, I came across this take on the use of metrics in the business world. This article by Julie Fraser titled – Are metrics driving or killing your business? can be found at Manufacturing Business Technology.

The question is whether the behavior that most companies are rewarding actually helps performance, or hurts it.

Ms. Fraser’s line is not really what the right metrics are but whether the measured metrics actually help performance or hurt it. In other words, does it work or not?
Here’s the standard example given (and why am I not surprised that manufacturing gets the short end of the stick?)

Many talk about fact-based management, but outdated manufacturing metrics often conflict with corporate goals. For example, a plant that measures equipment utilization as the top indicator of success may in fact lead the company to carry excess inventory. In another scenario, minimizing overtime might hurt on-time shipments to customers and thus, overall revenues.

But both of these metrics are not manufacturing metrics but confusions arising from accounting. It is true that manufacturing measures equipment utilization is measured in addition to cycle times, changeover times and mean time to failure. However, utilization is measured for accounting reasons not because a manufacturing/plant manager is going to feel extremely accomplished because his/her machine was utilized 95% of the time. The concept of unit cost arises in accounting and not in manufacturing and everything else follows from that.
While Ms. Fraser indicates that measuring equipment utilization “may” in fact lead the company to carry excess inventory but that is not only because manufacturing managers are measured using the notion of efficiency but because unit costs are minimized in large batch production. Costs in production as it is/was measured is a fuzzy concept because it is not related to actual demand and the actual price paid by the customer but a weighted factor of allocation of overheads, raw material costs etc. In order to minimize unit costs using the accounting dimensions, utilization is a key lever and it has been pulled many a time.
But what can one make of the following set of metrics led dead-ends?

Read the rest of this entry »

I have spent the last few days thinking further about metrics (supply chain metrics, financial metrics and all sorts of other metrics) but I haven’t hit upon a foundational idea (or a set of ideas) to order all my thoughts. So the rummaging continues and I took some of that rummaging online:

A thought process when thinking about metrics (any sort of metric) is to ask, how the other metrics in the firm look like. An example of that would be stumbling upon such as this observation by Brad Feld,

Several years ago, some of y’all may remember an event called “the bursting of the Internet bubble.” Immediately preceeding this event, companies (and investors) focused on growth at any cost. This growth took various forms ranging from the one key financial metric that everyone cared about at the time (revenue) to non-financial metrics such as eyeballs, click-throughs, and affiliates. Shortly after the bubble burst, people started focusing on net income, cash flow, cash on hand, and other financial metrics. Not surprisingly, these were things that most rational business owners had paid attention to since – oh – the beginning of time.

Brad is talking about metrics in an industry that for a short period of time saw tremendous growth – the one financial metric used was revenue along with a host of other metrics such as eyeballs, click-throughs and perhaps even today – page views.
As Brad notes further down in his blog, the staple of financial metrics as used internally within a firm would be more along the lines of,

Monthly data we collect (and consolidated so everyone in the firm sees it on a weekly basis) includes revenue, cost of goods, operating expense, EBITDA, headcount, cash burn, cash on hand, debt, projected insolvency date, additional cash required to breakeven, and projected first quarter of profitabiity.

Another interesting take on operational metrics is the following that comes from the profession of lawyers (i.e. a service/consulting type of environment):

The Law Practice Business Model was introduced in 1984 by David Maister as a mathematical expression. Maister’s formula is as follows:
NIPP = (1+L) * (BR) * (U) * (R) * (M) where,
NIPP = Average partner income
L = Leverage (ratio of associates to partners)
BR = the “blended” hourly billing rate
U = Utilization (client hours recorded)
R = Realization (revenues divided by “standard value” of time recorded)
M = Margin (partner’s profit divided by revenues)

M. Thomas Collins notes further that

Maister’s model doesn’t tell the whole story. The financial manager has to be just as concerned about metrics that measure unbilled fees (work-in-process) and billed but uncollected fees (receivables). The managing partner has to be concerned about metrics that are not reflected in the financial numbers but will impact those numbers in the future. For example, are we opening new matters faster than we are closing old ones? Are the partners meeting their individual marketing goals? Is client satisfaction on track or veering off-course? While the Maister model is not the whole story, it is at the heart of the story.

The above mathematic expression is really a current snapshot and I assume that such a snapshot is taken at the end of some period such as a month or quarter. In fact, it can be characterized as a trailing metric (the stock market analogy would be ) and as such is not forward looking because it doesn’t take into account an unfolding reality.

Read the rest of this entry »

SCDigest reports on strong rumors about merger talks between IBM and SAP.

These are just rumors, to be sure, and have been circulating at some level for almost a year.
SAP has strongly denied the rumors during that time, though chairman Hasso Plattner unintentionally put some fuel in the fire last May by saying to the German Financial Times last year that: “There are only three potential buyers [of SAP]: IBM, Microsoft and Google. Of all companies, I don’t see anyone else. If shareholders think that a combination, and not independence, is better, then it will happen.”

From the services model that IBM follows, it makes sense to acquire a behemoth like SAP purely for its installed base and then sell all sorts of services to them. But the larger question is – what’s the room for growth here? From a software sales point of view, the market is pretty much saturated. My own view of the ERP behemoth is that given the utter complexity of something of the order of SAP/Oracle and the implicit insistence that the firm adapt to SAP’s version of reality – there is quite an opportunity for an intelligent class of enterprise software to make deep inroads.
Whatever the big honchos at IBM are thinking, I’m skeptical of such a merger simply because of revenues from any sort of installed base growth. The market space where there is some growth potential seems to be:

IBM and SAP have an existing partnership to bring ERP to the small and mid-sized company market. Penetrating these smaller companies has been a key marketing goal of SAP for the past few years.

The question is – why pick an elephant (or a sheared down version of an elephant) to run what needs to be, strategically and execution-wise, a nimble organization? Any new entrant in the enterprise software space needs to enter via the small and mid-sized company market because that’s where the behemoths are concentrating their efforts.
Old Chinese (Confucius) saying: “Do not use a cannon to kill a mosquito.”
This makes for an exciting few years ahead.

Tags: ERP, Rumors of merger between IBM and SAP, IBM, SAP, SCDigest

SeekingAlpha reports about the results that SAP AG reported today – SAP Warns, Sending Shockwaves Through Enterprise Software.
Eric Savitz of Barron’s reports,

Bad news for the enterprise software sector this afternoon, as SAP (SAP) just warned that fourth quarter software revenue growth came in short of previous guidance. This is a bit confusing, so bear with me. SAP reports product revenues, software revenues, and total revenues, and it reports on both an actual and constant-currency basis. But the bottom line is that software sales came up short for both the quarter and the full year.

The SAP stock (SAP) is off more than 10% as I write and Oracle (ORCL) is also taking a late afternoon dive.

Tags: SAP warns, Enterprise software sales

I was forwarded this whitepaper written by Chuck Cilamore, CTO of Omnify Software. The topic of the whitepaper is to delineate the roles of ERP (Enterprise Resource Planning) and PLM (Product Lifecycle Management) in creating a successful collaborative environment. Omnify Software is a providers of PLM software for OEMs (Original Equipment Manufacturers) and EMS (Electronic Manufacturing Service) providers.
Chuck highlights the following as the essential difference between an ERP and PLM offering:

The manufacturer had an ERP system in place to manage all of the operations-centric business activities such as financials, purchasing, planning and work orders. But the ERP system did not address their engineering design requirements.

Furthermore, the real objective of the PLM is,

A PLM system is designed to manage the full gamut of engineering information in a single location through the many stages of a design. The enterprise server manufacturer used the PLM system to manage the lifecycle and all revisions of their Bill of Materials (a listing of components used in a product), provide revision control of engineering documents (such as assembly drawings, schematics and datasheets), electronically route approvals for New Part Requests (NPRs), manage and automate Engineering Change Orders (ECOs), and control Approved Manufacturer’s List (AML) changes. More importantly, the PLM system helped bridge the gap between engineering and manufacturing. By providing direct data sharing with the ERP system, any changes made in the PLM system were automatically uploaded to ERP so that engineering and manufacturing were always in synch.

The essential distinction being drawn between ERP and PLM by Chuck is a void that exists on the ERP side i.e. an ERP system doesn’t delve into the details and complexities of product development and lifecycle management. However, that void is something that ERP systems will expand into by acquiring some of the PLM players and integrating their products into the ERP suite of offerings. I saw the same thing happening with ERP players gobbling up TMS providers to precisely fill this gap that was perceived in their offerings.

Tags: ERP, PLM, Omnify Software, Chuck Cilamore, Collaboration in Enterprise, Product lifecycle

REA (Resource-Event-Agent) is a semantic model for internet based Supply Chain collaboration developed by Dr. William McCarthy of Michigan State University. In this presentation for the ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2000), Dr. McCarthy and Robert Haugen, Logistical Software LLC outline a web-based semantic model for collaboration.
Before I dived into this thing – I asked myself what do these good people mean by using the word semantic in a semantic model for internet based supply chain collaboration? You can look up the definition here

se.man.tic: Spelled Pronunciation[si-man-tik]
– adjective
of, pertaining to, or arising from the different meanings of words or other symbols
Eg: semantic change; semantic confusion.

So in other words, a semantic model is really a language meaning based model. So, what do the authors mean by using the term sematic model?

By “semantic model” we mean a computer software model of real-world supply chain activities. Another term for semantic model from the field of knowledge representation is “ontology”: the set of classes, relationships, and functions in a universe of discourse.

The authors also try to differentiate it from XML in the following way:

We use the term “semantic model” to differentiate from something like XML, the eXtensible Markup Language, which is often touted as the language of the semantic Web. XML is just a format; it has no content. A semantic model describes the content of the semantic Web: that is, what classes of objects, relationships, and functions are involved in supply chain collaboration. The REA semantic model can be expressed in many formats: XML, UML (the Universal Modeling Language), a relational database, and/or an object-oriented programming language. Using XML as the lingua franca, any REA-based system should be able to interoperate with any other REA-based system, because they understand business objects and events in the same way.

The authors also supply an outline of the aims of using the REA semantic model:

1. supply chain collaboration requires a standard semantic model that all trading partners can use;
2. to achieve Tim Berners-Lee’s vision (in other words, so that anybody can do business with anybody anywhere), the model must be a generally-recognized, non-proprietary Internet standard;
3. the model must be broad (covering the whole supply chain) and deep (covering all relevant business activities);
4. REA is the broadest and deepest currently available semantic model for supply chain collaboration;
5. and REA is non-proprietary, in the public domain, open for developing into an Internet standard.

So what should the REA semantic model achieve in practical operational terms?

As a semantic Web, REA can link economic events together across different companies, industries, and nations. The links are activity-to-activity or agent-to-agent or person-to-person, not just company-to-company. This means each individual in a REA supply chain can be linked directly to each other individual.

Read the rest of this entry »