With an entire week devoid of any kind of air travel (vacation), I was a bit behind on my magazine reading. BusinessWeek published their “50 Best Performers” issue, but what I find absolutely amazing was a terrific article on the challenges faced by Chinese factories, due to rising wages and regulation!

The nuts and bolts have to do with rising costs of raw materials, increasing demand for a fixed supply of labor, and currency changes, but the outcomes are what are really interesting. Basically, the message is that cheap labor is not enough, or even necessarily desirable. Companies are looking into increasing worker productivity through automation, and I suspect there will be growing interest in substituting “information for inventory”, which has long been a practice in higher cost economies.

This is very interesting to the B2B world, because one of the traditional challenges in driving B2B into lower cost countries is that the technology costs are not competitive with using people to solve the same problems. This is not to suggest that there is not a lot of sophisticated B2B going on, just that the goal has not been to reduce staff but to gain some kind of edge in speed or customer service.

With the current economic situation, it appears that companies may rebalance their productivity initiatives — focusing as much on using technology to drive productivity as labor arbitrage.

I just returned from a wonderful Spring Break vacation with my family, spent camping in our recently acquired pop-up trailer in the cave region of Kentucky. Mammoth Cave National Park happens to be very close to Bowling Green, so we took the opportunity to visit the National Corvette Museum, and tour GM’s Bowling Green Assembly Plant, the only factory on earth that produces the legendary Corvette…

I have had the opportunity to work with various companies in the auto industry (including GM), but I have never been to a major assembly plant before, and it was a treat. What was especially impressive is that in modern plants like Bowling Green, every car is built to order, despite the appearance of “mass production”. The plant builds both Corvettes and Cadillac XLRs, but the Corvette line fascinated me because the “outside” of the car is assembled (painted, welded, put together) separately from the “inside” (axles, tires, transmission, engine, etc). At one point in the process, the bodies descend from the ceiling and are attached to the drive train. The amazing thing is that most of the components are specific to each car — so the entire assembly operation must be kept in synch.

What impressed me was how little inventory was visible, with mobile racks of kitted parts moving around the plant. Reading the labels that happened to cross in front of me I saw no two kits coming from the same source (mostly GM plants in the midwest, though some tier one suppliers were also in evidence). With not an RFID tag in sight, I saw barcodes aplenty (one dimensional in this case), clearly linked up to a powerful production control system.

I think most of the people on the tour with me were impressed by the plant, it was hard not to be. But I doubt very many were able to appreciate that Bowling Green is so on top of its supply chain parts flow that they can start a car even though many of the kits to produce it are not even at the downstream stations yet. Since every car is built to order, parts from all over the US and some from Mexico must arrive at the station in time to be assembled — and the entire line will have to stop if anything is missing (it didn’t stop in the three plus hours I was there).

I have worked in B2B for a long time, but I still really enjoy seeing what is possible when trading partners can move at the speed of information. It was a beautiful sight…and the cars were nice too.

GXS has a terrific set of clients in the retail industry, some of whom I have worked with for many years, so stories about the industry tend to draw my eye. The other day I was reading a widely syndicated piece from AP about retail retrenchment, when something caught my eye:

“Experts also say merchants are weathering downturns better because of new systems to control inventory and costs.”

I found this very interesting because this was not an article concerned with technology, enterprise IT, or B2B — and when you find statements like that in the general media, it is a good sign that the investments in technology are paying off where it matters the most. What I find interesting is that the article references the systems, but doesn’t really explain how a system can “help control inventory and costs”.

While there are many systems that can affect inventory and costs, I like to think in general that we are attempting to affect a couple of key business capabilities, regardless of the technology:

1. How far in advance we can see what is happening
2. How quickly we can react to changes in demand or supply

These are obviously related, and interact to create “uh-ohs” or “ahas”… First to the “uh-ohs”

The above diagram is my very simplistic picture of the situation when the range of vision is shorter than the range of action, meaning by the time I realize I need to do something, it is too late. This is akin to a ship relying on the sound of scraping metal to alert it that rocks are near, rather than a lighthouse. It is tempting to do focus entirely on the red — that is, seeing farther out — through event management, forecasting, etc — but we can also change the equation by reducing the amount of time to respond to change.

In the B2B world (and not just in retail), it turns out that similar systems and technology help out with both. As a start, companies that manage their supply chain more effectively are able to sense (visibility) and respond (action) much more quickly than rivals. While it is tempting to get excited about the new possibilities of technology, many companies are not even managing the basics, like functional acknowledgements, yet (FAs are an electronic document sent back in reply to an electronic document. Basically, if you don’t get an FA from a partner, they may not have your order/ship notice/invoice/etc). Insisting on B2B integration with your supply chain, and then handling the basics well will provide more rapid information and the ability to execute more quickly. Implementing B2B gives you productivity, but doing it really well helps you see farther and act faster.

Beyond basic B2B, capabilities like logistics tracking and visibility will substantially enhance visibility, and enable members of your team to react more quickly because they have more information at hand. A system like logistics visibility is constantly “watching” the stream of logistics B2B traffic between logistics providers, and watching for exceptions or incidents.

As much as I love the software and services we build and operate for a living, the key thing is really the goal — we have to see problems (and opportunities) early enough to have time to act. Leveraging people, process and technology can get us from “uh-oh” to:

A very interesting piece from AMR Research’s John Fontanella on RFID reaching its tipping point.  This piece is free until March 14th, so click quickly!

John is a terrific analyst, and I really think he hits some great points in this, but I think the most insightful is that the attempt to drive an industry-wide standard of a nascent technology or initiative will usually not be successful (he cites ECR as another example).  RFID is a technology filled with promise, but it is still youthful, and needs the freedom to provide value in a variety of settings now that the Gen 2 standard has arrived.

To me, this is a specific instance of a wider phenomenon that I call “premature standardization”.  This occurs when a group of customers, or prospective customers, try to skip the early, difficult stages of a technology — littered with incompatibilities and proprietary solutions — and skip right to the highly desirable world of commodity technology based on industry standards.  The problem is that both of these cycles are part of a maturity cycle.  You have to go through the awkward teenage years to become a (hopefully) mature adult — there are no shortcuts.

Having said that however, the desire to standardize as rapidly as possible is completely understandable.  Standards based solutions are usually more mature, less expensive, and just plain easier to operate.  Why?  I would submit that all those characteristics are driven by the ugly, early years, when products are immature, expensive and hard to operate.  As various products mature and deliver value, which is the customers’ primary concern, people start to pay attention to all the other aspects, including costs.  Often, though not always, this drives the providers to standardize (Managed File Transfer is a case of an industry that has not standardized yet).  Generally standardization helps a market grow (because customers who were not willing to buy a proprietary solution will buy a standards based solution), and frequently the technology providers will start buying each other (consolidation).

But this is a process, and I don’t know any way to skip a step.  Everyone knows that a 1.0 product at a customer can be scary for all involved, but that first customer must happen (no amount of testing in the lab will substitute, and believe me, GXS does a ton of testing in the lab before the first customer…). 

As John states in his article: “Technologies are broadly adopted because they deliver value, not because their use is mandated.” 

We had a really good session last week with an analyst who covers our industry exceptionally well — and we had a really interesting debate about what multi-tenancy is, and whether it was import for SaaS (or any of the growing number of other “aaS’s” sprouting up…).  For the record, I have a pretty simple definition of multi-tenancy, and I think true multi-tenancy is ultimately required for successful SaaS platforms.  If you are deploying a new stack/instance/virtual machine/OS for every new client, you are not multi-tenant.

When it comes to assessing whether or not a service provider is multi-tenant, I think of the landscape as:

• Sub-divisions - single-tenant
• Townhouses/condominiums - virtualized multi-tenant (meaning, in my opinion, not multi-tenant)
• Hotels - true multi-tenant

Sub-divisions:

If someone is buying hardware, installing an OS, and then populating it with software for you, this is not SaaS, it is hosting!  They may “position” (aka, spin) it as SaaS for purposes of enticing venture capital, but it is not.  If you even know what kind of hardware you are running on within your service provider, you may be in trouble.  If a service provider “consults/notifies/alerts” you when they are doing a memory upgrade — you live in a sub-division.  There is nothing wrong with this, hosting is a very mature business; but you are receiving only operational economies of scale (assuming the provider can operate a data center better than you can…).

So who cares?  Well, you do, maybe.  If you want to be able to scale down as well as up (meaning start small and grow with activity), a suburban home is not a great idea.  I love my 5 bedroom, center-hall colonial, but surprisingly I paid a 5-bedroom mortgage even when only 3 bedrooms were occupied (now its 4, and we’ve decided to live with that 5th bedroom “underutilized”).  I also do not have much cost-efficiency with my neighbors beyond the roads (network).

Looking at it in IT terms, the server infrastructure, disk subsystem, LAN connections, etc are all dedicated.  The OS instance, software licenses, patches, upgrades, etc are being done expressly for me.  This is a great model in many cases, but it is not SaaS.  If you have a say in what version you are running, you are probably not in a true SaaS environment (if fact, here we talk about doing away with version numbers altogether…)

Townhouses/condominiums:

If you live or have-lived in a townhouse or condo, you know that this is really a hybrid model, with some shared infrastructure (typically building maintenance, lawns upkeep, etc), but still essentially a dedicated model once you are “inside”.  In the era of time-sharing this model was fantastic, because computer time was so expensive that the hardware was all we thought about, and software was just “there”.  Although you have some additional shared infrastructure with your neighbors, you still are on the hook for furniture, plumbing, electrical, HVAC, decorating, etc.  Most of us of course prefer it this way in our home life, but not necessarily so in the data center…

In the IT world, a common townhouse model is “virtualization” or “multi-instance”.  In this case, a dedicated software environment (typically from the OS up) is deployed for each customer, on shared hardware infrastructure.  This has a number of advantages over the “sub-division” model, but is still not (in my opinion) SaaS, for reasons we will come to in a moment.  Advantages include not only shared hardware, but efficiencies in hardware management, from server upgrades to back-up management.  This can be a highly efficient model when used for applications like web-hosting for instance (where the hardware cost to software cost is more favorable to hardware).

Under typical 21st century situations, however, this model is not SaaS because the dedicated capacity still includes — usually — an operating system, versioned technology stack, and potentially many customizations to the OS/networking environment that must be operated and maintained.  Look at just one example, OS security patches…  If the OS vendor (or open source development project) issues a patch, it must be checked and out and applied specifically to your environment.  Whoever is doing this may decide to forego this if you do not fund the work, or you may request that the vendor honor a “blackout” period and not apply it right away.  Meanwhile, other customers in the townhouse community may make different choices.  At the end of the day, everyone is “different”, which is actually worse than the “sub-division” because in addition to managing all of that, the operations team has to keep track of who did what when….

Hotel — true multi-tenant:

When you stay in a hotel, whether for an extended stay or overnight, you may worry about the location, the food available, shuttle service to/from the airport, and whether the internet access is fast enough — but I am willing to bet you will not worry about the air conditioning system.  The air conditioning, and a myriad of other details, belong to the proprietors of the establishment, and under normal circumstances you will not need to give them a second thought.  So it is with true SaaS.  SaaS is as much defined by what you don’t have to worry about as what you do:

• installation
• upgrades
• server rollouts/deployment
• backups
• versioning of any sort
• capacity

In its truest form, SaaS bears a striking similarity to the outstanding telecommunications infrastructure offered by the likes of Verizon, or the ubiquitous email connectivity of the BlackBerry (noticed very much recently because of a rare disruption in service).

But what does this have to do with multi-tenancy?  Multi-tenancy is the ultimate discipline, forcing providers to build highly scalable systems because they have no choice.  A typical node of GXS’s B2B outsourcing service might perform work for a dozen clients — which prevents us from doing anything special to the core stack for any one of them.  As a result, if needed, a client may be moved to another node or spread across several, with no change on their part.  We do this not because to operate at scale we must operate a multi-tenant environment (full disclosure, we do operate some dedicated environments to meet data privacy or regulatory requirements, but they are more costly both to us and to the customer).

If there is no multi-tenancy, customer specific configurations will become the norm, assuming the provider is customer oriented.  Over time environments will all become “exceptions” to the standard.  Initially happy customers will become dissatisfied as the promise of SaaS is unrealized, because they have bought space in a data center, not a true service offering. 

A bit of an unusual topic for me, but this was too good not to share.  Fortune Magazine recently did a wonderful article on the rise of the soy industry in Brazil.  What I found so fascinating about this article is how many trends can converge in a large agricultural area with “bad roads”:

• International competition:  US agriculture (soy is a major crop) versus Brazil’s growing dominance in soy (largest exporter since 2006)
• Eco-friendly business:  from the dark days of deforestation, the entire soy industry is striving to be environmentally friendly and energy-independent.  But there remain struggles to balance supply chain efficiency and the environment (see below)
• Innovation and sustainability:  while I think of soy as tofu, the products that now include soybeans as a critical component include:  cotton blends, spandex, shampoo, conditioner, soap, flashing tape, caulk, outdoor paint, glue for plywood cabinets, foam (including for a forth-coming Ford Mustang) and more!

Of particular interest in this article however is the critical role of the supply chain (physical, the article did not explain how information was moved).

Following on the trend from my last post, one “self-contained” supply chain uses soy products to produce fuel and feed for the largest chicken operation in South America.  The farm, processing plant and chicken buildings are literally built in one continuous line, with the trucks carrying the product to market fueled by bio-diesel — talk about a localized supplier network.

The second set of supply chain issues are more complex however, as actual soy consumption within Brazil is very limited.  The challenge is to export the bounty in a cost efficient manner through some of the most environmentally sensitive forests and rivers in the world.  The extensive discussion of the struggle to get the product to market without arousing the ire of the major markets (Europe, US) because of environmental damage is a fascinating twist on the influence globalization has.

We do a lot of business in Brazil, and I hope we have the opportunity to continue to grow in one of the world’s most exciting economies.

The folks over at Supply Chain Digest have put together a collection of thoughts from industry and academia about what is going on in 2008.  Often collections like this are nothing but aphorisms, but this one is different.  Among the gems:

• Jeff Karrenbauer of Insight, Inc — “the obvious outsourcing choice of , for example, the Pacific Basin, is often simply wrong”
• Jon Kirkegard of DCRA, Inc — “Postponed manufacturing state-side of imported key components will increasingly be seen as a major solution to supply chain and business challenges….”
• Larry Lapide of MIT — “Many companies will ’slow down’ their supply chains by using less expensive and slower transit modes”

While there are some areas of agreement, there are far more areas of disagreement about outcomes and effects — which is why I like this article.

For my part, what I find most interesting is the looming impact of fuel and energy costs (combined with changes in currency valuation).  If companies respond — as I hope they will — with much more aggressive leveraging of logistics information and a “postponed manufacturing strategy”, our payback for this more challenging period could be improved productivity, and progress in the quest for a demand-driven supply chain.

GXS spends a lot of time working on the concepts of “the hybrid model”, where software and services are integrated to work together to optimize B2B, but this hardware and services combination is pretty interesting as well!  The idea of hardware service combinations is old hat for cell phone users already, but this is a new approach.  I wonder if this could lead to the sale of USB hard drives that feature online backup services as well?  Could this catch on in the commercial space as well as for consumers?

The attraction of services in this kind of application is the universal availability characteristic.  I have often found myself using Google web applications — like Documents — not as application substitutes (I know it is not cool to speak well of new Microsoft versions, but I am really fond of Office 2007 — best yet!), but to have data available across systems and locations.  This is also a major advantage for companies that utilize supply chain applications running on the grid, as they can access — through a web UI — their information from anywhere they can connect, and know that they are looking at the same data as their partners.  To date the enterprise software market has approached software and SaaS as rivals (note the models of SAP), but I wonder if — like the USB disk — the future is more likely innovative combinations that combine the strength of both.

Hope you are having a wonderful holiday season, full of peace and joy — but courtesy of a recent customer visit, I learned it is not at all restful for some elements of the retail supply chain…

Many people don’t realize that much of the supply chain activity (ordering, forecasting, etc) is in the distant past when “Black Friday” hits after Thanksgiving — but it is.  Aside from the understandable need for advance planning, there is the small fact that information may fly around at the speed of light, but goods for store shelves must still be shipped great distances!  But modern supply chain practice goes far beyond just orders, and not every category of good must be shipped thousands of miles.

Some retail goods that are produced (or warehoused significantly) closer to their ultimate markets have the ability to respond do “demand signals” much more rapidly.  This can be because the goods are shipped by air, or manufactured locally (”locally” meaning within reach of high speed transportation), or warehoused in different regions that are capable of supplying one another.  Traditionally the domain of industrial parts that were JIT (just-in-time), it appears that key consumer goods are now capable of rapid response to demand.

This is of particular interest to me because of the role played by rapid information exchange — especially consumption and forecast data.  As goods fly off the shelves, that information is shared back into the supply chain, which then scrambles to refill the void.  This is an especially lucrative practice for goods that experience enhanced value during the first several days they are on sale, like music, books, movies, and video games (software, not the consoles — alas, see Steve’s column for the realities of complex hi-tech gadgets….).

Assuming you buy that such items can be more flexibly resupplied than many other goods — why the surge in demand?  This was the piece I didn’t understand, but GXS is not a consumer goods company.  The recent swelling of gift card sales, combined with retailer skill in attracting shoppers in the post holiday season has made the few days after December 25th some of the biggest shopping days of the year!  The only challenge is that those stores have been heavily shopped right up to Christmas Eve, and need to be replenished as much as possible to capture all that spend.

It seems that Christmas comes both early and late for retailers, and in those categories where the supply chain has the shortest latency, information can maximize profits for businesses, and satisfaction for customers.

Happy Holidays!

From time to time I like to blog about the work GXS is doing with partners, especially SoftwareAG webMethods and Microsoft (because I am involved in those).  Every so often, I’ll get asked why we partner, and why we don’t “build our own technology”, so I thought I would share something of our philosophy around technical partners and why it is important to understand the partnering philosophy of the software and services providers you use.

Firstly (mostly because I work in engineering and hope my colleagues will continue to return my calls), we do “build our own technology”, quite a bit of it in fact.  We have hundreds of engineers around the world working on software and services to make doing B2B easier and more productive.  In just the last few architecture reviews I’ve led, I’ve seen a new generation of technology to do translation more easily and efficiently, a completely revamped system for tracking the flow of XML data through our services, and a set of shared services that enables companies doing Global Data Synchronization to synchronize data (data pool management, or DPM).  Some days there is so much going on that it is challenge to keep up.  What I did not see — and had better not see — is someone building a database, an application server, or a new publish and subscribe bus for generalized messaging.  The reason is that if we are building core general purpose technology like that, we are not building the specialized technology that has made us successful.  There are too many opportunities to add value to our customers’ operations to squander them on proving we can build a better web serve than the Apache Group or Microsoft (which we can’t…).

Secondly, everyone partners, they just call it “sourcing”.  Last time I checked, ERP systems needed operating systems, databases and networking software.  You can call it sourcing, but when you decide to build your software on a given database technology (for instance), you have a new partner whether you like it or not.  Independent companies usually leave OSes, database, etc to the major players because those products can now be more efficiently provided, and it enables them to focus on the pieces where they can bring extra value.  I don’t know too many companies that would buy a software product that required its own, proprietary operating system these days (full disclosure, GXS once helped create the time-sharing era — working with Dartmouth — by writing an operating system, but only because the ones we could buy didn’t support time-sharing…).  Even folks marketing “software appliances” are tending to build on either a Windows version or a Linux distribution for this reason.

But it goes beyond the traditional economics argument — aside from the partners we need to run “on”, there are partners we need to run “with”.  Most iPod owners would be less ecstatic with their devices if they didn’t work with the computers that they owned, or did not work with non-Apple headphones, speakers, etc.  Likewise, nobody upgrades to new operating systems like Windows Vista of Apple’s Leopard if their software is not going to work — thus partnerships are caused by the customer’s irrational insistence that products work in their world, not just the nice demo center where everything is made by one company.  I feel strongly about this because our best partnerships today share one key element, customers that want to use the partner’s products together.

GXS’s partnering philosophy is simple, we are in business to help companies share data and conduct business processes with their partners (customers and suppliers) — and we work with partners that help us accomplish that.  Sometimes we work with technology partners like BEA, IBM, EMC, Red Hat, Egenera, etc because it is far less expensive to our customers than us doing it ourselves; and sometimes we work with firms that have already earned our customer’s business, like SAP, Oracle, SoftwareAG and Microsoft.

But we don’t partner with everybody, and for a very good reason.  In truth, it is often “easier” to build your own solution from scratch than to work with partners, because you have complete control down to the code.  Partnering at a deep technical level (like the various web services APIs to the GXS Trading Grid we offer) is a long-term commitment, and embedding someone else’s technology means integration work which is harder than straight development (though usually faster and less expensive).  Years and years of integrating with customers’ systems has given us the confidence and experience to select and integrate key partners.  Not every company has the skill and experience to work with technology partners, but I would encourage most companies to stick with those that do.

If you hired a contractor to build your new house, you might be alarmed if he or she brought an ax or starting making his own bricks — and relieved if instead you realized he or she showed a knowledge of the best “subs”.  It’s my hope that the people asking me why we partner will start asking their “technology contractors” why they don’t…