This Week on SCDigest:
Supply Chain Software App Stores?
Supply Chain Graphic of the Week and Supply Chain by the Numbers
New Cartoon Caption Contest Begins This Week!
SCDigest On-Target e-Magazine
Expert Contributor: Cloud-based Labor Management & Workforce Productivity
Expert Contributor: The Southern Border and its Commercial Traffic - A Fundamental Weakness in US Security Part 2
This Week on "Distribution Digest"
Trivia  Feedback

Become a Sponsor
SCDigest Home Page  
  Newsletter Archives October 28, 2010 - Supply Chain Digest Newsletter

Featured Sponsor: Voxware

Performance Food Group --

Watch The Video Case Study Now!


Videocast: Agility in Consumer Goods Demand Driven Manufacturing

Improving Customer Service Despite Tight Production Constraints

Featuring Filippo Focacci, Product Manager, IBM ILOG Optimization and Analytical Decision Support Solutions

Tuesday, November 2, 2010

Register Now!

Videocast Series: Achieving Real Results with Supply Chain Software

Part 3: Optimizing the Performance of Private Fleet Operations

Featuring Dr. Ray Mundy, UMSL Director of the Center for Transportation Studies, and Mona McFadden, RedPrairie Transportation Product Manager

Tuesday, November 16, 2010

Register Now!

Videocast: A New Decade for Smarter Supply Chain Management

New Rules For A New Decade … A Vision For Smarter Supply Chain Management

Featuring Karen Butner, Program Director, Global Strategies & Market Insights, Supply Chain Management, IBM Global Business Services

Wednesday, November 17, 2010

Register Now!


This Week's Supply Chain News Bites
  - Only from SCDigest


Supply Chain Graphic of the Week: The Impact of Supply Chain Costs and Product Lifecycle Pricing Strategies on Product Profitability

This Week’s Supply Chain by the Numbers for October 28, 2010:

  • Amazon's DC Blitz
  • Trucker Profits Looking Good
  • WalMart Seeks Growth from Massmart
  • More Goverment Pressure on Engine Makers for Truck MPG Growth




October 26, 2010 Contest


See The Full-Sized Cartoon And

Send In Your Entry Today!



Performance Food Group --

Watch The Video Now!

Each Week:

Global Supply Chain
Trends and Issues

Distribution/Material Handling

Weekly On-Target Newsletter
October 26, 2010 Edition

New Cartoon, Truck Weight Limits, China Metals Hardball, WMS Success, and More


By Steve Simmerman
Sales, Marketing and Business Development

Cloud-based Labor Management & Workforce Productivity


By James Giermanski,


Powers International, LLC

The Southern Border and its Commercial Traffic - A Fundamental Weakness in US Security Part 2


HolsteHolste's Blog: As Inventories Levels Continue to Slowly Increase DCs Are Forced To Become More Creative In Their Search For Storage Space

Top Story: With the Right Discipline, WMS Implementation Success Can be Assured
Top Story: Total Landed Cost Calculation, Key to Supply Chain Optimization, Still Immature Practice, 2010 3PL Study Finds
Vendor News: Voxware Inc. Announces 4.0 Of Its Voxware 3 Product Is Now Available


In the early days of the wireless RF terminal industry in distribution (late 1980s throughout most of the 1990s), what long gone company was usually the market share leader?

Click to find the answer below

Supply Chain Software App Stores?

I am freshly returned from the HighJump Software user conference in Scottsdale, and my thinking on supply chain software went in an unexpected direction relative to a new approach to supply chain software functionality enhancements.

At the conference, HighJump announced a new "app store" for its supply chain execution suite (Warehouse Management Systems, etc.).

At first, I assumed it was just some trendy, inconsequential thing to jump on IPhone bandwagon, but I was wrong - though the IPhone app store was the germ of the idea.

Gilmore Says:

"Another question, of course, is would companies really be willing to share those advances? Sometimes yes, sometimes no, I suspect. factoring in competitive issues."

What do you say?

Send us
your Feedback here

As many or most may know, with the rapid rise of Internet-enabled smart phones, especially the IPhone and the Google-based Androids, developers have been busy building add-on applications for these phones. In fact, there are hundreds of thousands of them, many free, some with a small charge. The apps range from tracking what food you eat during the day to tracking a FedEx package and thousands of other utilities.

The key point is that they just work on the IPhone or Android platform. You download what you need and only what you need.

HighJump has adopted a similar philosophy to providing enhancements to its core applications. The HighJump app store will feature pieces of functionality that can be downloaded and added to the functionality of the appropriate module in HighJump's suite that a customer is already running.

So, to cite an example offered at the conference by HighJump VP Chad Collins, there are some specific ways that bakery products coming out of the ovens need to be sorted and put on carts or other storage mechanisms. Specific data needs to be collected using handheld devices or regular screens. With this app store concept, that specific little work flow can be created as a downloadable application, and it can be easily inserted ("called") from the standard application precisely where it is needed in the process, handing back control to the main app when finished.

When you download an app from the HighJump store (free, for now, with a current maintenance agreement), you receive:

  • Required screens/screen changes (regular or RF)
  • Database changes
  • Workflow/screenflow process mappings
  • Documentation on what the app is and how it works.

Implications for Software Industry Could be Many

There are all sorts of potential implications from  this concept. The first is that this may be the perfect way of delivering many/most pieces of functionality specific to companies in different vertical industries or with different supply chain process models. This, as I know quite well, is a constant challenge for those in the software business.

Let's take the bakery example. You sell a WMS to a bakery, which needs this functionality. It's not in the base product. So a modification is required - but of course the bakery wants the capability to be in the core system, so the vendor makes that commitment.

Good for the baker - but not so good for the candlestick maker, the retailer, the widget manufacturer, and everyone else who now has their core system mucked up with more functionality and database stuff that has nothing to do with them. Across dozens of other customers, this becomes a big issue (code and database "bloat".) App stores with specific vertical industry functionality might be the way to solve this issue.

Which then begs the question - is an "app store" the way a supply chain software company might actually primarily deliver new functionality? No more upgrading the full software solution to just to get  the two or three new capabilities that are the ones really needed for the operation. Just download those apps instead.

Likely, some functional improvements would be considered "core" and go into the base product, while some would be consider specialized and be available from the app store. How this would/will play out in practice will be interesting to see.

Obviously, this concept now opens the potential for an "open source" type of community. Service oriented architecture (SOA), software componentry, and workflow tools continue to put more power into the user's hands. As they build their own enhancements, those could be offered back to the app store. HighJump, in fact, is positioned to support this, saying they would vet the quality and workability of the submitted apps and then make them available in the store.

Another question, of course, is would companies really be willing to share those advances? Sometimes yes, sometimes no, I suspect. factoring in competitive issues. Procter & Gamble, as just a for instance, is not likely to gladly submit an app that makes Colgate-Palmolive's distribution life easier.

But during the presentation in Scottsdale, I would estimate 75-80% of the room said they would be open to sharing the apps they might develop internally. This would have to play out. Perhaps companies might want to make it available for most others, but not some specific competitors. Could get tricky.

A couple of years ago, i2 Technologies actually unveiled a somewhat similar notion, with what it called "business content libraries." The idea involved a library of tailored workflows for different scenarios (say a specific process for developing a global, consensus forecast) that its customers could similarly download and implement.

My sense is i2 was thinking "bigger" in terms of scope of the workflows than HighJump is thinking or others might. In addition, to take advantage of this new offering, nearly everyone at the time would have needed to upgrade their i2 platform to take advantage of the new "agile architecture." There was a cost to  be able to access the workflow library (a subscription fee).

Nevertheless, it was a very cool vision, and clearly on the same basic track, if maybe a level above, to both the good and the bad. I am not sure how the concept has fared since the JDA Software acquisition of i2.

There are of course some challenges. Our Mark Fralick, who knows as much about service oriented architecture as anyone around, sees much potential in the basic idea, as well as some challenges.

"The key is the "atomic completeness" of the applications being downloaded," he said. I asked for a translation for that term, and he said that an available app must really be able start and fully execute successfully on its own given the context of the specific environment it is going into.

"That would be pretty easy for things like reports or bills of lading, compliance requirements, things like that," he said. "But as the apps get more complex, things would become more challenging. The app would have to make assumptions about the state of things in the distribution center or the WMS configuration."

Fralick brought up the example of a cart picking enhancement that would add new intelligence to the process.

"Could that be downloaded and installed without breaking something somewhere else? That's the question," he added, saying the smaller the scope of functionality, the easier it would be to achieve atomic completeness.

That said, he believes it would be difficult but not impossible to achieve that completeness for larger chunks of functionality, or that the apps could get a company maybe 75% of the way there for something they need rather than starting from scratch.

There are many more issues here. A vendor would have to have the right type of SOA-based architecture to support the whole notion. To have maximum effect in the long run, users would need tools to easily build their own mini-apps, which could then be shared with the community. The effort to qualify and fix submitted apps as needed could prove very costly to the vendors. Maybe free doesn't work. This only works within a given vendor's system - though I can see maybe specific SAP integrations from best of breed vendors being offered as an app.

Nevertheless, this is a very provocative concept, and one that might have quite an impact on how software functionality is delivered and even the traditional versus on-demand software debate. More on the latter statement in a future column.

What do you think of an app store approach to supply chain software? What are the barriers? Could this have a major impact on how software is delivered? Let us know your thoughts at the Feedback button below.



Send an Email

Web Page/Printable Version of Column


Do you use an RSS reader? Do you have a MyYahoo! or personalized Google page?

For these and more you can have SCDigest delivered right to your personal pages, all week long.

You can subscribe to our RSS feeds in two ways:

  1. Copy our RSS link into your RSS reader - it's easy!

  2. Click on a button below to quickly add it to your favorite readers.


A bit of this and a bit of that this week. That starts with a couple of good letters on our column on how to define and measure supply chain flexibility, including our feedback of the week from Blair Binney, who says that there may be another way to think about the issue.

Another reader takes us to task for how we defined Days Inventory Outstanding - and we again explain it's the source data not our calculation.

All this and more below.

Feedback of the Week - On Defining and Measuring Supply Chain Flexibility:


A couple observations...

We appear to confuse "cost of flexibility" with "cost to achieve flexibility".  As an example, products which do not share sourcing (e.g., AVL, common parts), will incur reduced flexibility in the overall supply chain (demand, supply). There may be a cost to initially to develop and engineer products which pool risk across demand and supply initially, however the final cost of this portfolio will be reduced and flexibility increased. At this level, flexibility may be achieved in optimizing iterations where appropriate to manage risk (e.g., alternate sources for common parts, up-sell).

It may be observed the theme here is risk pooling to manage flexibility which depends on understanding common shared component elements which includes not only the materiel and services in the products themselves, but the processes which support the supply chain.

The article speaks well to what is flexibility, but circles the question of when and how to measure it. The "when" addresses whether flexibility should be performed as a supply chain design-stage step where risk/operational conditions are evaluated analytically as risk scenarios, or/and whether the goal is to identify and extract events from actual operational performance to measure the time dependent sense/respond cycle. The latter leads naturally to a management system that shortens the cycle time from risk events identification (or ideally prediction) to executed resolution minimizing an adverse consequence (e.g., missed customer deliveries, increased expedite and spot buy costs).

Likely the set of steady state supply chain KPI's can be suggested which can be then compared either to scenario-based outcomes, or operationally measured outcomes associated with actual risk events.


Blair Binney


More On Supply Chain Flexibility:


A look at OEE (Overall Equipment Effectiveness) might be helpful as part of a supply chain flexibility discussion. OEE combines three individual measurement KPIs (availability, performance and quality) into one overall metric.

Bob Nardone in your column said he believes that "supply chain flexibility is about quicker response to changes in demand while achieving your cost, service, inventory and return on assets (ROA) objectives."

That's an important issue: can you respond rapidly without breaking the bank?

He adds that "I don't think flexibility can be determined by one measure, but by a composite of metrics that many companies currently measure."

If the supply chain flexibility discussion focuses on those measures and gaining agreement on the keys to achieving flexible response, it could then turn to trying to reach agreement on how to weight each metric and develop a composite measure.

John Shogen

Cardinal IG Company

On Supply Chain Measuring Inventory Performance:

I have been an active follower of your publication for quite a while now. In general, I feel like you do a very nice job covering the current trends and issues in the supply chain.

So I was a bit disappointed to see that in your "Inventory performance in 2009" article, you defined DIO as "Inventory/[Revenues/365)". Forget the typographical issues, the real calculation uses COGS, not revenues-a big difference. And it should be average inventory in the coverage period, not inventory, which usually means ending inventory.


Please correct this statement for your readers.

Sam Israelit


Editor's Note:

Thanks for writing - we go through this every year. We are reporting on what the CFO/REL study reports. They use Revenue, not COGS. I usually put a little note about that, but did not this year. So, as they use revenue, we are simply reporting how their calculation is done.

They are using public financial statements for the analysis, which to the best of my knowledge rarely if ever provides average inventory for a period. Yes, this leads to some potentially faulty results and/or is impacted by end of period gamesmanship, but again, what can you do? You can make this calculation internally, knowing average inventory, but not in the balance sheet numbers that are available.

We are looking at doing something like this ourselves, and may do so, and are thinking we would use quarterly data and average, to get a somewhat better picture of the average, but don't see any real way at it from using SEC filings.

Hope that clarifies.

Dan Gilmore

On Supplier Financial Analysis:


I have been working with corporations around Supply Chain Finance Confirmed Payable programs. My analysis has seen:

1.  Sales Cycles for SCF Confirmed Payable or Reverse Factoring programs are running at 16 to 20 months, and then some subset pilot is started and it takes a long time to start building critical mass.  These programs then get a negative label rather than a positive one.  This is unfortunate.

2.  Procurement is driving the RFPs in these programs more and more (since they directly touch their supplier base)

3.  A keen interest by the market is understanding how corporations view the liquidity management of these programs (single bank, multi-provider funding model, agnostic model) and the granular details within.  For example, under a multi funding model, funding providers will have different KYC standards, pricing thresholds based on their capital models, etc.

Procurement, working in conjunction with Finance & Treasury, needs to get actively involved in these programs to help suppliers, particularly in emerging markets where financing rates are double digits.

David Gustin

Global Business Intelligence



In the early days of the wireless RF terminal industry in distribution (late 1980s throughout most of the 1990s), what long gone company was usually the market share leader?


Telxon. The once high flyer stumbled late in the decade and was acquired by Symbol Technologies in 2000, which in turn was later acquired by Motorola. We suspect there are still quite a few Telxon-branded devices in operation somewhere out there today.