The aggregate effect of the business trends we have worked out is for a considerable increase in the need for SMEs to become involved with EC. In terms of needed EC products and services, however, a finer distinction can be made, namely the demands made by a business trend on:

• improving a company's internal system integration, and/or on
• inter-company communication.

Certainly both are important, and just as certainly, it is hard to affect one without affecting the other. Still, relative impact along these two dimensions does have different consequences for SMEs.

As an example contrast two of the business trends we have identified: 1- foreign sales opportunities, and 2- outsourcing of inventory management. The former places a major demand on an SME's ability to communicate with potential customers, as would be the case with on-line catalogues and ordering systems. A company in this situation doing a small to moderate amount of business could get by with a good Web presence even if it did not have a high level capacity to automatically enter incoming orders into an order processing system. Contrast this situation with the second example where both good internal integration and inter-company communication are necessary for success.

An important element in these examples is the concept of "scale". At some point internal integration will be critical for any EC activity because information that cannot be managed internally cannot be communicated meaningfully to the outside world. I do not believe, however, that most SMEs operate on that large a scale. I believe that practical guidance about the EC needs of SMEs should assume that 80% of SMEs have information handling needs in the "low to moderately high" range, and that this is the group on which we should concentrate our efforts.

Ratings of the EC consequences of SME business trends appear in Table 1.

1. The ratings are a initial estimates which are intended to be revised through discussion and consensus.
2. Ratings are for the 80% of SMEs whose business requires "low" to "moderately high" levels of EC. Excluded are the 20% whose business requires large scale EC.
3. "x" denotes most likely rating. In some cases an "o" appears as an alternate rating when the situation would be very different for an SME as it moves toward the upper end of the "low to moderately high" continuum.
4. Not all the trends we originally identified are included. Ratings are given only for those trends for which this system applies.

Return to beginning

As with business trends, the technological trends are those we worked out earlier. In this system a technological trend 's primary impact is viewed as affecting a vendor indirectly, through its consequences for a potential end user. As an example, it is not really critical that vendors can build more security into EC data transmission systems. What is important is how potential users of EC technology will react to products with different levels of security. It is that reaction that will govern the extent to which vendors push their technical capability to assure data security. Ratings of how technical trends in EC may affect SMEs appear in Table 2.

1. The ratings are a initial estimates which are intended to be revised through discussion and consensus.
2. A rating of "high" or "low" for the present is made relative to the likely value in the future. (It would be interesting to use graphs rather than tables, but so doing would imply more information than we actually have about magnitude and patterns of change.)
3. These are overall ratings, and may very well differ for particular EC products.
4. Whether something is rated as a facilitator or inhibitor depends on its present impact on EC.
5. The "impact" column is an estimate of how important each trend is. As an example, the problem of "system administration burden" and "portability of EC applications across platforms" are both trends related to EC technology, but they are not equally important in terms of promoting EC among SMEs. Ratings are done on a 3 point scale, 1 = low impact, 3= high impact.
6. * Denotes a trend that is particularly problematic because it is: 1- important, and 2- likely to move in a counterproductive direction.

The effects of EC innovations can be categorized by a two dimensional matrix, with particular innovations falling into one or more categories. Some examples follow. (Thanks to my colleague Manish Desai for coming up with the financial ... customer dimension.)

List of examples:

1. X-12 based EDI is used to send traditional purchase orders faster and with less expense. Without EDI purchase orders would still flow, but not as quickly and with greater expense.
2. The Web is useful for searching for items within catalogues that are instantiated on servers. This makes shopping easier and faster, but paper catalogues are available and more than adequate for most tasks.
3. Engineering change notices, complete with graphics, can be sent via mail or over a network. As with purchase orders, the information would get be sent anyway, but can be transmitted more quickly (and perhaps in more usable form) through a network.
4. Evaluated receipts settlement.
5. Large-scale just-in-time production systems.
6. Concurrent engineering among geographically separated design teams.
7. Vendor managed inventory based on point of sale data capture
8. Groups of non-competing suppliers forming "one stop shopping" systems for mutual customers.

By placing each of these examples into the matrix we end up with Table 3.

Prediction Ability

The visual clarity of the transition arrows represents the increasing difficulty of prediction as we move from one level of EC impact to the next. Increasing the efficiency of known processes is subject to traditional cost benefit and market research methods. The situation is less clear at the second stage, where a technology's success depends on a greater level of organizational and business process change. Because the outcome of change management is hard to foretell, so too is the ultimate value of the enabling EC technology. The situation is murkiest at the third level because in addition to new ways of doing business, success requires a change people's beliefs about where and how value derives from different ways of doing business. Table 4 uses EDI to illustrate an example of the difficulties of analysis as one moves through these three levels.

Return to beginning

As new technologies and business processes are introduced, they create demands on the complex SME support system that exists in this country. The activities of organizations such as community colleges, members of the NIST Manufacturing Extension Program, and Electronic Commerce Resource Centers can have a decided impact on the success or failure a new technology. Consider the following two examples of interdependence between the vendor community and the manufacturing support system.

Example #1: simulation modeling and community colleges: In this case a vendor of powerful simulation software was working with community colleges to help them apply simulation as an educational aid in a variety of technical courses, and also to establish training courses in the use of simulation software. The self interest here is obvious, but so too is the wisdom of the strategy. The long term success of simulation modeling depends on a critical mass of people in manufacturing who appreciate the power of the technology, complemented by a critical mass of experts who can actually do simulation. Given the educational role of community colleges, they are an ideal context for both types of training.

Example #2: EDI and Electronic Commerce Resource Centers (ECRC): Given their funding base and purpose (to help improve the DoD acquisition life cycle through the application of EC), ECRCs are well suited to the time consuming work of providing EC training to the numerous small firms who need to know about EC, but who are not likely to actively seek out and pay for such training. The success or failure of the ECRC effort will have discernible impact on the demands for product and technical support that SMEs are likely to make of EDI vendors.

Return to beginning

This box in the diagram has wide borders to symbolize its importance in the model. The success of EC among SMEs will depend in large measure on the ability of vendors to offer products which truly meet SME requirements in terms of supporting business need, affordability, and ease of implementation. To fulfill those requirements, vendors have to think in terms of how their customers will be affected by the interaction between increased reliance on EC, development directions of EC technologies, and the capabilities of the SME support structure.

Return to beginning

This section contains an example of how the system described above might be applied to a specific EC need among SMEs. The example is the "universal translator" for EDI. Consider an SME's system integration problem if it wishes to provide an automated data flow from incoming EDI to business applications such as order entry or MRP. Figure 2 illustrates the situation. Regardless of how data come in, its format from different trading partners will differ. Depending on the strength of industry conventions for X-12 formats, and the variety of industrial sectors with which the company is doing business, the formats may differ by larger and smaller degrees. But one way or another, some differences are inevitable. As long as a company is willing to make do with EDI output to paper, these differences are insignificant. But when integration is involved, the implications are that the company will be forced into implementing and maintaining different integration systems for each customer. To make matters worse, even small differences in format require disproportionately large investments in customizing integration systems. Clearly this situation is a major impediment to any SME that wishes to do serious integration with data from a wide variety of customers.

Many different groups are proposing technological solutions to this problem, all with the common characteristic of switching the systems integration burden from individual users to EC product developers. Those developers would set up a system with a database that would keep information on all allowable X-12 formats. With such a system users would input the structure of the application into which the EDI would flow, and the "universal translator" would do the rest. Figure 3 illustrates this situation. While this approach still requires users to maintain their internal systems, it frees them of the burden of maintaining separate integration routines for each stream of incoming EDI data. Because one set of developers can sell the product to many users, the cost is amortized over a large installed base, thus lowering the cost to each individual user.

To be sure there are lots of debates about what a "universal translator" would look like. Will it reside on the Web or as a piece of software on individual computers? Will it be confined to X-12 based EDI or contain a large amount of information to facilitate the virtual enterprise? And so on. But one way or another, the plan is for a product that will provide an affordable technological solution to the multiple EDI standards problem. With this example in mind, let's now trace the "universal translator" through the assessment approach presented in earlier sections.

First, what are the business trends touched by the translator? These are presented in Table 5.

An inspection of the ratings for these trends shows that in the aggregate they place a high demand on both internal integration and inter-company communication. (Considering the number of trends that score low on either communication or integration, this was not a predictable finding.) One important implication is that universal translators will find their most receptive market among the minority of SMEs who are committed to integration. While an analysis of business trends shows that the number of those firms is likely to grow, we also know that the initial market is relatively small.

The issue of market size and development reappears as we trace the universal translator through the "SME Business Implications" of the diagram. Let us see how the "universal translator" manifests itself through the different levels of application shown in the diagram. (See Table 6.)

Table 6: Assessing Market for "Universal Translator"
Level	Application	Prediction Difficulty	Reasons for Prediction Difficulty
Improve established business process	Move from "rip and read" to integration of diverse streams of EDI data into other applications		Relatively easy to determine current number of SMEs doing EDI, extent of present integration, integration plans for immediate future, likely EDI demands of OEMs, and other pertinent data. Implementation of new system is a straight forward replacement of older systems, or establishment of a new integration method where none previously existed.
Increase practicality of known process	SME's automation and speeding of flow of requirements to their suppliers, based on EDI/MRP integration and analysis of customers' release data.		In addition to a greater level of technological sophistication, success requires major changes in buyers' business processes and in business arrangements with suppliers. Risk and number of unknowns are greater.
New type of product or service	Use newfound ability to respond to customers to bid on business that requires a faster response time than do one's traditional customers.		In addition to the uncertainties articulated above, this activity requires leadership and ability to identify and enter new markets. We can say the number of success here will be smaller than successes in the above categories, but from the point of view of a vendor of integration technology, its extremely difficult to know how many potential customers would use the product in this (or a similar) manner.

The above market assessment also tells us something about the role of the support infrastructure in helping SMEs take advantage of "universal translator" technology. Primarily, SMEs will need help at the second and third levels of application. At the second level, using EDI with one's suppliers implies setting up technological and business processes that are a challenge even for large companies with deep expertise in information systems. Without deployment assistance, wide-scale use of supplier-EDI by SMEs will be considerably slowed.

In terms of using increased response time to cater to new markets, there is little assurance that such markets exist for any given SME, or whether it would be worth their while to pursue those opportunities. Further, SMEs are often not in a position to research those markets, or to develop the business plans needed to enter them. Here too the infrastructure and be of assistance, as for example, the ability of SBDCs to assist with market research.

Given this specific market situation, what additional information can be gleaned from an inspection of technological issues? The answer is presented in Table 7, which contains:

• technological issues that are relevant to the "universal translator's" use by SMEs
• an explanation of why these particular issues were chosen, and
• an explanation of what has to happen to assure that these technological issues help establish the translator as a facilitator of EC among 7

A theme that runs through much of Table 7 is that of a bifurcation in the population of SMEs, between the minority that can implement and exploit integration, and the majority that cannot. The implication is that vendors, as well as the SMEs themselves, have an interest in a support infrastructure that can further integration implementation.