Compliance: the Market Subset of the Command Economy
All businesses are impacted by governmental "command" - most visibly through the imposition of taxes and regulations of the sort discussed on the compliance page. However, what this page addresses is the non-governmental command subset of the market economy, a perhaps underappreciated force.

Between the willing buyers and sellers of the free market, there often exists a "command" element, and in fact many readers will have "commanded" a trading partner to do something that the trading partner would not do in the normal course of business - e.g., implement an EDI trading relationship, inplement bar code tagging or RFID tagging, invoice via procurement card. Many readers may also recall - perhaps more vividly - being "commanded" by some trading partner. As with governmentally commanded taxes and regulations, it is important both to the economy at large as well as to the participants that commanded expenditures of money and effort produce a net return rather than waste.
A cautionary first step is that all of us - when doing the commanding -  recognize an obligation to make these commands payback on a macro level. Also, win-lose supply chain mandates may be a source of imposed inefficiencies, because one party is inappropriately spending someone else's money..

Command Subset of the Market Economy

"Command" in the free market occurs when a trading partner requires another trading partner to follow imposed rules, behaviors and processes. Although not governmental laws or regulations, a trading partner may embed those rules in a contract, which then gives them legal force. The other trading partner is of course free to reject the imposed rules - up to the point that those rules become contractually enforceable, but may accept them because the costs and efforts involved are small in comparison to the value of the commercial relationship.

Sometimes the situation is reversed and the seller has enough influence to impose requirements on the buyer - e.g., to order in lot sizes that the seller does not normally prefer, to provide information not normally provided, to implement inapproprate eBusiness processes, etc.

In comparison to true governmental bodies, the power of trading partners to "command" is limited, but these concessions not infrequently can represent the rough equivalent of a 1%-3% "sales tax." One peculiarity is that the negotiators on both sides are often organizationally and psychologically  far removed from the cost impact of the "commands," and negotiators who would battle hard about a one penny per unit price change are much less sensitive about these "soft costs."  The concessions become what in U.S. political terms is sometimes termed an "unfunded mandate."

Such an unfunded mandate can sometimes flash back on the entity commanding that the mandate be addressed. For example, during the .com era (and beyond), some of those "commanding" that vendors transmit catalog content in some prescribed (and often peculiar) form were later distressed to find that managing those data feeds created an unfunded mandate within their own enterprise.

As with taxes, a key question is whether these commands represent sound expenditures or end up as waste

Many good things come from taxes - including the Internet itself. Much of the original Internet investment and direction came from the U.S. Department of Defense, some of the key technologies of the web (such as http) came out of CERN in Europe, and some of the early work on browsers came out of taxpayer funded institutions such as the University of Illinois.

However, taxes and the quasi-taxes cited here can general waste, and the power to create mandates needs to be employed with due regard for the consequences. In the context of supply chain streamlining and business-to-business eBusiness, there are "good" commands and "bad" ones although, given technology and market changes, what is good and bad shifts over time.

"Good" commands foster productivity-enhancing innovation and standards, while accelerating adoption of useful technologies. "Bad" commands have the opposite effect - retarding innovation and delaying advances. Apart from "big ticket" commands that are good or bad on a grand scale, there is also a substantial amount of command "noise" - forced measures that are small-scale and not especially onerous, but that may create drag and fear uncertainty and doubt.

To be specific, the author regards a command from a buyer to a seller to implement "punchout" as "good" because punchout benefits both the buyer and seller. The "goodness" is still there if the seller "commands" the buyer, as occasionally is the case. See
OBI revisited for more detail regarding this topic. Of course, even if "punchout" is good,  such a command comes with a price, especially if the given seller never before implemented punchout. Typically the buyer who forces the seller to adopt punchout is better preparing the seller for future opportunities.

On the other side, the author regards a current trend - that of commanding sellers to key their invoices into buyers' web sites as being "bad," meaning wasteful. The sellers typically operate sophisticated invoicing systems and often have associated eBusiness capabilities using advanced software from SAP or Oracle or Peoplesoft or others. Nevertheless, there are cases where the buyer "commands" those sellers to key the invoice data into the buyer's portal or into some third party portal, which means the seller has to print the invoices at the seller's premises and then have someone key the data.

To be fair, there is sometimes a potential mitigating circumstance. If the buyer has also provided the seller with a feasible option for delivering invoice data in some streamlined, electronic way, but the buyer picks inefficient rekeying because of shortcomings on the seller's part, then the "command" is really a choice. 

Command-Inflicted Noise - Data Practices

The command subset that creates the most productivity drag - in the author's experience - is data field level "noise" - off-pitch, off-beat data practices imposed by one trading partner on another. Although not as dramatic as, for example, a requirement to implement RFID, command-imposed data peculiarities can be more insidious, because there is ongoing, error-prone extra work associated with these practices.

In the context of data "noise," automated invoice processing is the equivalent of the canary miners long ago took down the mines to provide early warning of toxic fumes. If there are implementation difficulties, it is symptomatic of data issues - often with "command" origins.

Looking at an EDI standards book or some corresponding XML transaction standards, it would appear that automating invoice evaluation - matching purchase orders, invoices and, as needed, receiving and ship notice transactions - is pretty straightforward, even easy for a beginning-level programmer. Software is needed to cross-check product IDs, units, units of measure, unit prices, etc. and, except for some presumably rare mismatches, the program would automate payment approval and scheduling.
Indeed, there are operating examples which attain 99% plus automated payment approval, with no data "collisions".

On the other hand, there are mandated data practices that create drag - making automation more expensive or perhaps infeasible. As an example, a trading partner may issue a purchase order in which the line items are not individual products, but "months." That is, if the order starts in January and runs for twelve months, the "command" would be that everything invoiced in April should be invoiced as line item 4. The organization "mandating" such a practice (and there are hundreds of variants) is usually "solving" an internal problem in a backwards way - e.g., in this case, making it easy to determine what was spent on product X in April, but only by  creating substantial complexities for the trading partners. In effect, line item has become a proxy for invoice period.

To cite another example, an AIAG (auto Industry Action Group) study of one automobile company found that the company's EDI environment mandated that EDI transactions many "required fields" that in fact were not relevant to the automobile company's own internal systems. To meet this mandate, people worked diligently to fill in the blanks acceptably.

Note that these problems are not "data quality" problems, but "mandated" injections of noise and drag into inter-entity processes. Further, it does not take much such "noise" to eliminate the value of automated processes. For example, if one invoice in ten rejects, in all likelihood the cost of detecting, diagnosing and fixing the problem eats up all of the savings and more of having the other nine flow through with no human intervention. It does not take much noxious data to kill the hypothetical canary.

One reason that it has become something of a fashion to mandate that suppliers key invoice data into customer-controlled portals is to delegate to some unlucky supplier employee the task of navigating through the noise. Therefore, reliance on such a process is a symptom of deeper problems that need to be addressed.

Looking Ahead

Not mandating anything is probably not possible, because a single enterprise cannot deal with an endless multiplicity of options.  Mandates can play a positive role. Still, caution is appropriate.

Mandates are not just something that large enterprises inflict on small ones. Every enterprise in some context creates mandates - including small to large, and data practice manadated "noise" comes from "everywhere." Indeed, one massive source of "mandates" is small business, which often mandates use of manual methods long after there are suitable automated alternatives - the small company "Lilliputions" tieing down the big company "Gulliver

Pushing mandates on anyone still requires thoughtfulness. The .com era is behind us, but "irrational exuberance" still lurks, along with its polar opposite, irrational pessimism. We face new choices because of new technology options, but also there is a need to consider revived and modernized reruns of old choices.

Mandating RFID tags, for example, could be a product of "irrational exuberance," but on the other hand an analysis of the facts could reveal that resisting that mandate is based on irrational pessimism. What is important is to focus on the facts, not wishful think or FUD. Given that initiating mandates usually involves spending someone else's money and, at least as precious, spending their energy and creativity, caution and thoughtfulness are necessary.


We typically have well-formed views and defensive mechanisms regarding government mandates. In the U.S. and elsewhere, those mandates go through various levels of public review, debate, and notice-posting. Nevertheless, we are not always happy with their impact.

In contrast, the private mandates that occur between free market trading partners tend not to be even considered as paralleling government regulations or taxes, even though they have some of the same effects - for good or for ill.  The U.S. B2B goods economy exceeds $3.5 trillion per year, and even 1% of that devoted to implementing such mandates equates to $35 billion per year in quasi-"taxes."

Given that mandates are necessary and often aids to productivity, there is no avoiding them entirely. On the other hand,  what is important it to prevent waste by: 1) being very, very cautious if your mandate inflicts a win-lose arrangement, 2) and spend extra time validating that your command makes sense for the long term rather than being a measure to postpone addressing root cause problems, and 3) being willing to "gain share." Willingness to share gains equitably is not only beneficial as an incentive to change, but forces the party doing the commanding to take some economic responsibility.