Comparison of Syntactic Media in ERP Systems

Back in 2004, I cut out this Computerworld article about PepsiCo’s struggles in establishing a standard ERP across its business divisions. It inspired me to try to find an explanation for the origin of the trouble such systems seem to present to businesses.

I present it as an example of a real company facing exactly this prospect: to migrate and integrate data from the syntactic medium of one ERP system to that of another.

Problem Description

When a business or organization purchases a “packaged application,” after installing it on their computers and networks, they must configure it to support the needs of the organization. Configuration consists of loading control and tracking codes, and setting options on or off to instruct the application how to behave in the context imposed by the organization. Legacy data may be moved from older systems into the new system’s data structures.

Custom report generation is also a typical activity. Customization includes choosing appropriate coding schemes to support the organization’s requirements. This may include defining or associating organization-specific meaning to otherwise unused attributes of the application.

The design activity undertaken to perform this configuration is one of mapping the existing data to new data structures, and creating appropriate control data to trigger the system’s built-in behaviors in appropriate ways. For this activity, the data structures of the new system work very much like a “paint-by-number” set. Different regions of the syntactic medium  of the application are reserved to act as signs for specific types of symbols.

Under the metaphor presented here, the concepts represented by these signs are like the colors used to fill the numbered spaces on a paint-by-number canvas. While there may be a recommended “color” scheme, the careful artist can substitute or alter the hue or combinations, and still have a recognizable picture. Likewise, so long as the organization understands the side effects and operations triggered by the various settings of the application, variations and alternative configurations may still produce a system that operates and fulfills the operational and representational needs of the organization.

When the artist is not careful to select a replacement color scheme using compatible alternate values (in other words, values which are different from the originally intended ones, but which in relationship to each other mimic the differences of the originals), they may wind up with a completely muddy picture. The artist finds that the paint-by-numbers canvas, now covered in the alternate paint, presents a chaotic, unrecognizable mess.

In the same fashion, the organization that strays too far away from the meanings and concepts the application system was intended to carry will find that the system breaks down.

“PepsiCo Standardizes on SAP” 

 Stacy Cowley, Computerworld, June 14, 2004

Stacy Cowley, a reporter for IDG News Service, reported in the June 14, 2004 issue of Computerworld, about how PepsiCo Inc., parent company of the soft drink manufacturer, had announced it planned to standardize all of its business divisions on the mySAP Business Suite from SAP AG. The following are excerpts from her article.

 PepsiCo decided to move to one ERP system to better integrate its operations and began evaluating vendors several months ago. SAP won the contract because of its extensive history in the consumer goods market, [Mark] Dollins [a PepsiCo Inc. spokesman] said. . . . PepsiCo is tight-lipped about its ERP plan. . . . “All we can say at this point is that we expect it to be a multiyear project,” he said. . . . SAP will displace some of its competitors in PepsiCo’s infrastructure – most notably Oracle Corp., which counts Pepsi-Cola North America, Frito-Lay and Tropicana as users of its ERP applications. . . . PepsiCo has tried to streamline its systems before: In 1999, it created Plano, Texas-based PepsiCo Business Solutions Group as a central IT organization. Five years later, the company still has a fragmented technology infrastructure.

I should follow up on this, at some point, see what finally happened.

The Challenge Faced: Compatibility of Syntactic Media

(Note: the information presented in this section is notional at best, being based on interviews occurring over ten years ago with data professionals familiar with various ERP systems of that time. No claim is made regarding the veracity of the information, nor of the identity of the systems depicted. Relationship to current products should be considered coincidental.)

The data structures of the packaged application are static structures defining a finite set of symbols in a specific syntactic medium. The package expects certain data relationships to exist, its operation contingent on the data being set in certain ways.

A flexible application, such as an Enterprise Resource Planning (ERP) package, will present a set of signs including both structures and pre-defined, abstract behaviors over these structures.

Different packages will permit different levels of variation and extension. The package, however, will present limitations on the variability of representation supported. One package might permit specification of a hierarchy of classifications only to a set number of levels, while another may permit an infinite hierarchy of parent and child relationships. The most sophisticated packages will present a “model” of flexible constructs allowing the organization to define a rich representation within the constraints of the model.

The following figure presents a graphical depiction of the “product dimension”  available in one vendor’s ERP application (from 10+ years ago). This is not a data model, but rather a depiction of the hierarchy of classifications that could be applied to any instance of a “product” as represented in the system.

The term “product” suggests something the organization might sell to others. The terminology used by this ERP system is to consider them as “items”. As depicted here, this “product” model is extensible to some degree, as many of the structures supporting the model permit the organization to add descriptions, codes and other classifiers through business process conventions and data entry rules. The complete specification of this syntactic medium for “products” should be found, more or less, in the documentation provided with the application.

Sample ERP 1: The "Product" Dimension Syntactic Medium

Sample ERP 1: The "Product" Dimension Syntactic Medium

Other ERP applications also provide a syntactic medium for “products.” This next figure depicts the hierarchies and classification structures presented by a second ERP for this concept. The “product” model in this second ERP permits representation of complex, recursive bill of material hierarchies, which the first ERP did not. It also permits the organization to define a fixed, three-tier “product” identification hierarchy.

Sample ERP 2: The "Product" Dimension Syntactic Medium
Sample ERP 2: The “Product” Dimension Syntactic Medium


How to Read the Dimension Diagrams

The diagrams shown in the two figures are called “dimension templates” and depict the possible hierarchies of codes and classifications that might be defined for analyzing “products.” The term “dimension” refers to that similarly termed construct from the “star schema” abstract model used in Business Intelligence applications. To “read” the diagram, begin at the bottom and read up from the perspective of an individual “product.” At each level, new information is available for classification and analysis of the product among its siblings. In a Business Intelligence application, the levels of the “dimension template” correspond to the levels of the roll-up of fact (formulaic) data along the “product dimension.”

For our discussion, however, we use it to depict quickly the structural differences presented by the two ERP applications. Clearly, the two packages present different capabilities and flexibility to represent a company’s “product” dimension. It should be noted, however, that although the two ERP packages use different vocabulary and may permit many different hierarchies to be developed by their respective syntactic media, both abstract models are intended by their vendors to capture exactly these “product” dimensions for their customers. Hence, in practice, both syntactic media may be able to support the many instances of substantially similar sets of  symbols.

The power of these models in their own right, their flexibility and utility within the context of their respective applications, is in their ability to support many different variations of concepts and organizing schemes from one organization to another. However, as should be clear from these two examples, no two applications are likely to provide the same syntactic medium.

Organizations which are very large (perhaps as a result of mergers and acquisitions) may in fact use more than one application in different areas. If we imagine an organization of two or more divisions, where some divisions use ERP 1 and others use ERP 2, then we can immediately imagine some non-trivial problem when these divisions try to consolidate their respective information.  The problem arises, at least in part, out of the significant differences found in their respective syntactic media.

Migration Problem

ERP systems are very large and complex. Setting one up in a “green field” would be challenging enough to accomplish. When a company decides to migrate from one ERP to another, they are faced with several hurdles. An important one, which is not often mentioned directly, is that the data structures between two different ERP products are not always compatible.

In addition, the business will have created over time a unique implementation of one ERP system based on the context defined by the collective accrual of history of the business. What this means is that the existing application will have been customized in unique ways to support the problems and concerns of the business.

In the terminology of this author, the business will have projected the concepts important to their context onto the syntactic medium presented by the ERP. This projection will necessarily by idiosynchratic to the business’ specific context (which, if you’ve been reading this blog you’d realize would not be the same as the context of its competitors).

Presented with a different syntactic medium (a different ERP), the business’ context and concerns have not changed substantially. The problem is that the business must now consciously project their entire context (at least the entire context represented by their existing ERP system) onto the new ERP.

When there are structural differences between the old and the new, as there inevitably will be, figuring out which structures of the new system can be used to capture the data and operate functions of the old system can take a long time.

In our fairly small example above, moving a single layered “Item Catalog Group” classification of ERP1 into the more complex “Bill of Materials” hierarchy of ERP 2 would require the creation of new data. Going the other direction would require the flattening or complete replacement of the “BOM” hierarchy.

With an ERP migration especially, differences in respective syntactic media is at least as important (if not all important) as any other factor in predicting the success or failure of the endeavor.

2 Responses

  1. […] Comparison of Syntactic Media in ERP Systems […]

  2. […] Comparison of Syntactic Media in ERP Systems […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: