BSI is a simple and automatic method of enabling Business Systems to interoperate. Among the many applications for BSI are: Data Warehousing, Electronic Commerce (both EDI automatic interoperation and Web Commerce), Business System Integration and large scale systems development projects. It can also provide a sound foundation for Workflow Management Systems.
Traditional EDI (trad-edi) methods such as EDIFACT and X12 have been adopted very slowly by a minute proportion of the world's business community over the past 30 years. Those few organisations that have adopted it are predominantly the large corporations and governments. Despite many claims for vast financial benefits, closer examination reveals very few of those enthusiasts have benefited financially or organisationally from having adopted trad-edi.
BSI is free of the problems that are inhibiting the adoption of trad-edi and achieving benefit from it. Thus it offers to all Enterprises, large and small, the ability to do business electronically, beneficially and profitably.
Some of the benefits of BSI over trad-edi are:
To understand the principles of BSI, consider the purchasing and supply activities using paper or fax to transmit the purchase orders from a customer to a supplier.
The customer's Business System generates Purchase Orders either on paper by using a printer or by sending a document format directly to a fax server. Exactly the same form goes to every supplier - there is no attempt to produce specialised form layouts for each of the different suppliers.
Any supplier receives purchase orders of all shapes and sizes from each customer - each with its own data pattern and layout. These orders are manually keyed using a customer orders (Sales) application program into the supplier's Business System where a sequence of other business processes is triggered (e.g. Picking lists, Invoices etc).
When transferring the customers orders from paper to the business system, the Order Entry application program prompts on a screen for the data it uses. The operator searches for each piece of information of the paper form and keys it against the prompt on the screen.
There will rarely be a perfect match between the information on the paper form received from the customer and the information requested by the supplier's application program. If the customers order form contains data that is not used by the supplier's order entry program, there will be no prompt, so the operator simply ignores it. If the supplier's program requests information not contained on the customers order, the operator keys a null entry (i.e. a blank entry).
The Business Systems Engineer who designs a customer order entry program has to decide what to do when a null entry is keyed. If the information is critical (e.g. no product specified in an order), there is no way that particular line item can be processed, so the line is bypassed and the customer must be consulted. When designing such an application program, the objective is to supply as much of each order as is possible, since most suppliers don't like to risk losing sales. So for every possible entry, one or more business rules are included in the application program defining how to handle a null entry by the operator. For example, if no delivery address is specified, the goods are delivered to an address held on the customer's entry in the supplier's database. So customers with only one location usually don't specify separate delivery addresses on a purchase order.
The more information keyed from the customer's order form into the supplier's computer, the higher the potential for introducing transcription errors and the longer it takes to key each order. Both of these increase the processing cost of the order to the supplier, so expert application designers encourage operators to key only critical data or unusual situations, keying null entries whenever possible. This minimises both the cost and delays of data entry and the cost of detecting and correcting errors that might otherwise be introduced.
In most cases, paper-based interoperation works satisfactorily and most organisations which operate Business Systems use it.
The example above for paper-based interoperation of the Customer's Purchase Order printing program and the supplier's order entry program needs the following modifications to use EDI instead of paper:
The only problem with this model is that the designer of the customer's program to produce the file of orders is unlikely to design the interchange file to exactly the same format as the designer of the Supplier's Order Entry program. So some method is needed to automate the actions of the manual operator who located each piece of information on the customer's paper order form and keyed it against the screen prompts by the supplier's program, with null entries when the customer did not supply a particular piece of data.
If a Specification of the file produced by the customer's program and also the Specification of the file required by the supplier's order entry program are both provided to a "reformatting" program, that program would be able to extract the information requested by the supplier's program from the customer's file and pass it to the supplier's program in the appropriate sequence, just as the human operator did with paper forms. Where the customer does not supplier data used by the supplier's program, a null entry results. Where the customer supplies data not used by the supplier's program, it is not extracted from the incoming file.
So this is the principle of BSI:
The interoperation is looked after by BSI Server software:
So, when a business application package is produced, the Install diskette contains, the application programs, the Specifications for all Interchange files for interoperation with other Business Systems and the BSI Server software. The Installation process writes all of these onto the hard disk.
When the customer's Business System produces purchase orders, it hands the order files to the BSI Server which sends each of them to the designated supplier. On receipt of the information the supplier's BSI server calls up the right application program to process it and extracts the data used by the supplier's program from the incoming customer's file. This is done in a totally automatic way and all the technical processes associated with the interoperation of the customer and supplier application programs are firmly under the hood. Neither user has to cope with any of the EDI workings. There are no upfront agreements as to what data will be interchanged in what format before starting to do business electronically. The whole process has been reduced to the simplicity and transparency of the technology in a fax machine and operates in a totally open environment.
If an application program is changed, there is absolutely no effect on any of the remote business systems and the change can be introduced unilaterally, unannounced and fully automatically. The Update Diskette contains the revised application program and the revised Specification. When installed on the users computer, both obsolete versions are overwritten on the hard disk.
The ability to introduce changes unilaterally, unannounced and automatically is a very powerful tool when implementing large systems involving interoperation of two or more Business Systems. BSI enables the components to be phased in one at a time and each interoperating remote Business System to brought on line at just the right point in time.
Trying to implement large systems all at once is rarely successful and having to co-ordinate dependent changeovers at each stage of the implementation (as needed if trad-edi is used) is always an expense, is often difficult and disruptive to the business and can become impractical. Also, specifications tend to change during the subsequent implementations which can effect components already operating. The automatic, unilateral cut-in of changes offered by BSI once again, makes a difficult situation much easier, less disruptive and less expensive to handle.
Traditional methods for EDI (trad-edi) such as X12 and EDIFACT have been adopted extremely slowly by the business community world-wide. After more than thirty years it has been estimated there are scarcely more than 100,000 organisations using it throughout the world. For the majority of those, one trading partner is receiving the interchange on fax or printing it onto hardcopy and rekeying, thereby introducing considerable cost, but little, if any, benefit (and it is no longer EDI since human intervention is involved).
By way of contrast, in just a few short years, Windows technology has been adopted by an estimated 80 million users world wide.
Comparing BSI with trad-edi reveals many factors contributing to the impracticality of trad-edi and some of the reasons for its failure to be widely adopted.
Trad-edi is based on the (invalid) assumption that if all organisations, no matter what their business or their size, were to format the data for a particular business transaction in exactly the same way, anyone would be able to do business with everyone else with a minimum of difficulty. So thousands of "standards setters" around the world meet at national and international forums to define these "standard" interchange structures. A problem is that the result of this massive exercise is not implementable. This is because the components of the "standard" cover every conceivable transaction and it is not possible to determine exactly which of the qualifier and codeset values apply to any given transaction.
Just to make matters considerably more complex, trad-edi does not use business-oriented language, but uses a system of dispersed semantics (a specialise EDI language) where it might take up to 5 different data elements in trad-edi language (EDIFACT) to represent one unit of business data. This translation and "untranslation" process used by trad-edi causes many highly significant problems for the users.
To overcome this setback, each industry group in each locality meets to determine how this "standard" can be implemented in their industry. The result is an Implementation Guideline for that industry in that locality. This action also reveals another problem: different industries and different sizes of industries within any particular group have widely varying data requirements for any given transaction.
Even the Implementation Guidelines fall down when organisations try and implement them:
The net effect of this rather comical situation with trad-edi is that the "standards" are first destandardised to local industry "guidelines" and then disintegrate even further into one-on-one specifically tailored proprietary structures between each disparate pair of trading partners.
Therefore a medium sized wholesaler with 6,000 customers needs to go through this agreement process 6,000 times before being able to enter into an electronic trading arrangement with all customers. This, alone, would be considered impractical for a large percentage of businesses.
On the other hand, BSI is implementable in just one way that must be used identically by everybody:
Because the application software producer must adhere to these standards for BSI to work, the end users do not need to meet and arrive at any kind of up front agreement on the interchange structure before trading electronically.
With trad-edi, the application programs at each end often have to be re-engineered in order to make available the data agreed to in the interchange structure. This may have to be done several times as different (larger) trading partners mandate different data. This is euphemistically termed "business process re-engineering" and is often quoted as a "benefit" of trad-edi. Whereas in some cases it does result in improvement to very substandard (usually also old or in-house-built) Business Systems, in many cases it is a cost directly attributable to providing the data "mandated" in the interchange agreement between the parties.
The problem is further exacerbated by trad-edi frameworks not following valid business procedures and rules. This can result in business systems "re-engineered" to operate with trad-edi not functioning properly subsequently. Because of the need for this re-engineering and consequent problems, the disruption to the business while implementing and settling in trad-edi is often quite inhibiting.
With BSI, there is minimal change required to the application, limited to writing the data to be transferred to a sequential file instead of to a printer and reading from a sequential file instead of a keyboard. BSI uses whatever data the application program is already using. This avoids the extensive, costly and difficult "re-engineering" often required to implement trad-edi. Consequently, the disruption to the organisation during implementation of BSI is almost nil.
Trad-edi does not use true standards, so before any pair of organisations can commence trading electronically, they must decide and agree the exact nature of the interchange structure that will be used between them. So trad-edi operates in a closed (proprietary) environment. This results in smaller organisations having different implementations for most of their trading partners making the operation of trad-edi complex, expensive and largely impractical for them.
With BSI, true standardisation is used, so it operates in an open environment. The information interchanged is determined by whatever the sending application already does and there is no need to alter it. Therefore, prior agreements between the trading partners on interchange structures are completely unnecessary and irrelevant. BSI is as easily and inexpensively usable by the small enterprise as it is by the large.
With trad-edi, as each new trading partner commences electronic trading, a new interchange structure is often needed. The translation software has to be setup to convert the sequential file produced by the application program into the dispersed "edi language" agreed upfront between the trading partners. In large organisations with in-house computer professionals, this is just difficult. For smaller organisations with no in-house Information Systems Department it is not only difficult, but means hiring expensive staff and then extensive training at high expense followed by implementation problems as each new interchange structure is "debugged". The alternative is to hire expensive external EDI consultants for each new structure. This often significantly increases the cost of doing business for the smaller organisations which can have a different structure mandated by each new trading partner.
With trad-edi, the process is more prone to operational problems and consequent business disruption because it is very complex and there are many things to go wrong. Remote support is always difficult, not entirely practical and expensive with trad-edi.
With BSI, the Specifications are produced by the programmers who write or modify the application program and are done only once. Users are not involved at all when new BSI trading partners commence electronic trading - the whole process is fully automated. BSI is much simpler than trad-edi and there is less that can go wrong, so the operating costs and complexities are lower. Remote support is simple, practical and inexpensive with BSI.
With trad-edi, if a correction or change has to be made in an interchange structure both trading partners must co-ordinate the implementation to cut over at the same time. Where a trading community shares an implementation, it can become impractical to co-ordinate the change. So the more successfully trad-edi works, the worse of a classical legacy system it becomes.
When changes are made to the interchange structure with BSI, the change is implemented unilaterally, unannounced and fully automatically. BSI never exhibits any legacy symptoms and leaves the users totally free and unconstrained to concentrate their efforts on doing business rather than driving the EDI.
BSI is a universal solution for the interoperation of business systems. Not only is it a practical replacement for trad-edi, but it is also a very useful infrastructure tool for many routine business problems such as:
It also forms a practical and effective foundation for the new-age business systems which will be based on Workflow Management rather than Management Information.
On the other hand, trad-edi is barely practical for EDI with no viable applications envisaged outside this narrow domain. Long term, its future is at best uncertain.
With trad-edi, excessive technical demands are placed on the end users, primarily in being able to arrive at an upfront agreement on the data structures to be interchanged and also in setting up the EDI translators to implement the agreed interchange for each new trading partner. Both these tasks are quite demanding in terms of computer technology, but the task is in an area where it must be accomplished by sales and purchasing personnel. This makes it quite impractical for use by SMEs and there can never be widespread adoption among any but the largest organisations and those with a high degree of in house expertise in computer technology.
SMEs are predominantly reliant on packaged business software. Such off-the-shelf products are rare and usually of limited functionality. There is very little incentive for software producers to meet this challenge using trad-edi:
With BSI, the picture is quite different. Here, all the technically exacting work is done by the programmers, who have the skills to address it. In addition, the technical work required is simpler. Everything that is required by BSI can be placed on the Installation medium with the application programs and installed on the users machine as part of the routine installation procedure (often just by typing a:\install). From that point on, BSI is invisible to the end users. If error reports are received, they can be emailed directly to a third party support organisation. So BSI is very inexpensive to adopt. The support is simple, inexpensive and can easily be contracted to a third party.
Software companies are involved in only a very short learning exercise (normally around an hour), training the programmers to handle BSI is also easy and short (an hour or two at most) and the product does not need expensive translators or heavy support costs. So BSI is very worthwhile building into software packages to gain a marketing edge through the products being enabled for Electronic Commerce. This makes it a simple and small decision for software companies to incorporate BSI into their products and therefore has a great potential to make product available on the shelves and this in turn enables the SMEs to adopt Electronic Commerce.