Reach Us +44-175-271-2024
All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.

Middle Office Restrictions For E-Commerce Systems

Tadeusz Gospodarek*
Walbrzych School of Management and Entrepreneurship
Corresponding Author: Tadeusz Gospodarek, Walbrzych School of Management and Entrepreneurship, E-mail: tgospo@op.pl
Related article at Pubmed, Scholar Google

Visit for more related articles at Journal of Internet Banking and Commerce

Abstract

E-commerce systems may be considered as 3-layers information logical structure consistent of front office, middle office and back office layers. Front office is the best described layer of the model. It is related to direct information exchange between the client and hardcore part of the organization. The back office related to LAN information exchange and physical realization of front office demands is also well matured. But there is one important problem: all front office applications are stateless type (after cancelling the session, all data are lost), whereas back office applications are real time with necessity of blocking records, generation of online fiscal documents, etc. Any model of a-business defines its own supply chain. A linkage between logical layers and the defined supply chain is forming by modules and functions of the middle office layer. This layer limits full operational ability of the e-commerce systems like, ZenCart. The main problems derive from the computerization and integration of the supply chain. The offered solutions for the middle office layer are usually either too complicated or improper for online integration. Therefore for successful rolling out of computer aided e-commerce system, the optimum structure of the middle office layer design is crucial, because there are the most important conceptual limits.

 

Keywords

information systems, internet, e-commerce

INTRODUCTION

In contrary to traditional selling structure, e-business adds some new elements to a business model. The new aspects are as follows: e-payment service, online information support (price compare services, reviews services, opinions and references, technical support, society communication services, internet viewers, etc.) and virtualization of resources and stocks (the related outsourcing services). Each e-business forms a supply chain1,2 which is always a part of any global supply chain (GSC) and requires precise flow of information, services and merchandises3. This structure introduces new business relations and document flow charts. But at the end each virtual business transaction realized electronically is forming law relations between both sides of any ecommerce act as well as duties to third parties involved into supply chain and physical realization of a delivery to customers. Thus the model of the ecommerce system based on three logical layers may be concerned4,5 (Fig. 1).
1. Front Office ( FO) layer, related to direct contacts with customers supported by CRM and CMS systems and some customer oriented services as RSS, Blogs, Forum, Technical service, etc.
2. Middle Office (MO) layer defined as knowledge, know-how and communication layer of e-business. It may be divided onto two joined tiers:
The external services layer (algorithms of payment services, logistic services and communication services)
The internal services layer (local programs, modules, functions, templates, forms etc.) supporting information exchange LAN-WAN.
3. Back Office (BO) layer of physical realization of the virtual transaction, bookkeeping and financial control.
The FO is the key layer of communication with customers and is characteristic for all ebusiness types. Therefore it is the best described and supported by information systems layer. There are even some de facto standards of ecommerce software on the market e.g. osCommerce6 or ZenCart7. The BO layer is not only very good developed from the process point of view, but it has been also well matured for some years, supported by ERP systems, financial and bookkeeping software, and different control systems. Software solutions are differ sligthly between each other for the territorial localizations, where the ecommerce system operates. In fact, there are de iure standards of bookkeeping e.g. IFRS8 for all countries, financial standards and selling procedures, but each country can use their own regulations and tax rules. The MO layer supply know-how and knowledge for FO and BO users. It offers information services for internal structure of the ecommerce system and gives support for the exchange information with the surroundings. Therefore the structure and functionality of the MO software may be different for each implementation, and strongly depends on the related supply chain structure. Even such standardized open source ecommerce system as ZenCart behaves strong limitation of its functionality due to defined internal business processes. Each extension of MO software functionality requires language localization and extra modules and classes adopted for the external business rules and boundaries, what often limits functionality of communication part of the software systems, resulting too long processing time of the final site generating by PHP or ASP server.
On the FO layer level of e-commerce system, communication with client, maintenance of orders and information about the offered products and services are good resolved on the base level by the standard open source software, as osCommerce and ZenCart. But update of graphical and presentation possibilities require add ons from the third party software or include some external services (e.g. cooliris)9 and use flat html pages, offering multimedia solutions and a server of dynamic pages creation relief. Such solutions are well known on the market and there are no restrictions for their applications, regarding rational border of complication the presentation form to the text content ratio. Suitable suggestions are included in the Norman-Nielsen service 10 . It should taken into account that in the ecommerce systems, business core functionality is not proportional to esthetic of a content presentation, because script language techniques and dynamic creation of pages by servers are based on standardized templates, not oriented on individual requirements directed on multimedia technologies. The most important criterion for standardized systems is the speed of final page generation and minimization of data transfer to client. Also functionality of the site under different browsers is crucial.
Computational support of the BO layer, related mainly to LAN systems is also standardized solution on the market. There is no difference between the virtual and stationary shop support related to physical stock handling (bookkeeping, transactions). Virtual shop uses some MO internal services for automation logistic processes (automatic addressing, labeling, bar code generations, consignee documents edition, etc.). There are no boundaries neither in hardware nor in software level for computerization standard BO processes. In the most logistic questions of typical e-commerce model, the use of Microsoft Office software allows to design an integrated system supporting BO layer hardcore processes. Of course, using specialized stock&selling systems integrated with a bookkeeping systems makes general functionality of the full system better. But in the most cases it is sufficient to use simply stock handling system written with Microsoft Access tool, and the external outsourcing related to bookkeeping services. Then BO layer will offer restricted control functions, but it is usually acceptable.
Problems related to functionality of the BO arising along new external services offered in the surroundings. New forms of e-pay, new systems of merchandise exchange, new delivery services require to introduce suitable modules into the MO layer software of a given ebusiness. This module must joint communication between FO and BO layers and in FO layer, the customer must receive suitable interface for linking to the external service, whereas in the BO, the officer must receive automation processing of delivery, or payment registration. The successful integration of BO layer systems strongly depends on communication modules and services of the MO. Each new external supplier from the defined supply chain offers a module integrating standard e-commerce system (osCommerce, osTicket, ZenCart, etc.) with the offered service. This way the PayPal11 service offers scripts PHP, which allows on linkage the MO and FO layers to the external PayPal banking system. PayPal banking system extends the supply chain onto banking systems of the customer and ecommerce organization, and allows on payment control in BO layer in online mode, using integrated interface. It is one of the most important success of e-business solutions.

Some observed problems

Analyzing the offered on the market ecommerce solutions based on osCommerce and ZenCart standard some problems of interlayer integration and full integration of the system with a given supply chain are observed.
1. The existing of two independent databases in the system, not synchronized and replicated even in quasi-online mode. One database is related to virtual selling and FO layer, and the second one is related to bookkeeping, transaction control and physical delivery of the ordered items. The first database is oriented on presentation of the offered goods and service as well as collection of customers’ orders. In many cases it is not synchronized with the real stock database. One of the most important standards of e-business models is the global supply chain (GSC) model based on fully virtual stock and resources. It means that the customer may order items which are not available in stock at a given time. The ordered merchandises are available in the external stocks, joined with the defined supply chain, and will be delivered after fixed period of time. This model is based on excellent supply chain, what in business practice is false hypothesis. From the customer’s point of view, this type of ecommerce solution is badly evaluated, what suggests that the virtual stock should be represented by defined, fully rotated physical representation of merchandises available online. This way, the optimum solution is to synchronize both of the mentioned databases in quasi-online mode. Full integration is usually too difficult to implement, and its costs are not economically rational. Ecommerce service, in general, is not a critical business solution. So it would better to spend money on good integration of MO layer with GSC.
2. Structural differences between FO and BO databases, derived from the assumed model of e-business. The most acceptable relations of ecommerce and customers requires clear presentation and quick choice of the offered items. For that reason customer interface in FO layer must elastically configure full id code of chosen item from its partial codes of categories characterizing the given product (eg. colour, size, pressure force, etc.). This way in some ecommerce solutions, the FO database of products is forming dynamically as a temporary matrix of category codes (e.g. black, size 5 with pressure force 80 hPa), glued the next (or not) to one-dimensional table of codes. The BO database of stock items is one dimensional, and each record in it is the single code consisting of all category subcodes. Therefore in fully integrated ecommerce system, the MO layer should deliver the module, converting univocally FO and BO stock database for possible synchronization purposes. In less integrated models of ecommerce, the FO database may be not fully integrated with the BO one, based only on stock price criterion (the same price for different size and colour). This way, physical stock database in BO is one dimensional regardless the category characteristics (one stock code for a given style or model regardless its size or colour), whereas FO database is expandable to the detailed code structure (distinguishing style, colour and size). In this model of ecommerce, the customer obtains full information if and only if, the FO database was converted to one dimensional table of useful codes and MO modules were able to convert univocally the set of subcodes matrix. In the ZenCart system such stock code control is not implemented. It is very big disfunction of the MO layer.
3. Synchronization in time the quantity of goods in physical stock and the quantity available for the customer. It is the biggest problem for MO algorithms and functions. There are some rational aspects for dissynchronization of FO and BO databases. One of the main problem is stateless character of the FO computational systems. Any hanging of physical connection cancels current session, and possible block of a record in physical stock database may be not valid. The time split between payment confirmation and physical stock reservation makes difficult to control real states of stock items. Also in the FO selling forms there are no limits on the quantity of the ordered items. Any limitation should derived from the information received from the BO database. Such synchronization requires special algorithms and subroutines in MO layer. As it was mentioned, the ecommerce model based on perfect GSC allows on such dissynchronization, but the prices and delivery time synchronization inside the GSC participants must be hold. In practice these questions are not to easy to resolve. The MO layer must deliver successful algorithms for waiting line procedures related to the placed orders. Therefore MO layer algorithms must offer the following usability functions:
1. Possibility of update of stock states in FO layer, based on information received from the BO layer in quasi-online mode (discrete synchronization of databases).
2. Possibility of item reservation in BO layer, from the FO level in such way, that the ordered position would be “frozen” for the next order until the assumed condition fulfill or physically moved from the stock.
3. Possibility of automatic BO stock control, clarifying erroneous reservations and synchronizing both FO and BO databases.
4. Add on extra module for realization orders regardless the BO database empty states.
Such solution is not available as an ecommerce standard. It requires very precise functional model of the realized e-business processes and difficult synchronization procedures. The presented ecommerce model depends strongly on the local stock&sale system exploiting in LAN, and realizing physically delivery of merchandises to a customer. Therefore all algorithms and modules of MO layer must be tuned individually to the structure of local supply chain, what is a serious restriction in standardization processes of the computer aided ecommerce systems.
4. Information of the local supply chain for a given e-business model. Both layers FO and BO require some external services. The most important are, e-payment, orders to suppliers handling, forwarding to a customer services, communication services, warranty and complaint service, knowledge and technical support online. These services are not standardized and require special computer aided systems. In the most cases successful solutions derive from the physical location of BO, undersigned agreements with suppliers, relations inside the local supply chain and innovations in the surroundings. This makes continuous variations of the existing systems and require high elasticity of the MO layer. So, the SOA12 , 13 architecture of the MO software seems to be the best solution, but is submitting for quick changes and the final structure of the MO software is not exactly predictable, similar to the offered services in the surroundings. It may be noticed that among the epayment services there are a lot of different systems competing each other. The same may be stated about forwarding services. Analyzing the structure of forwarding modules available from UPS, DHL, DPD it may be noticed that there are very difficult algorithms of pricing including a lot parameters, what for the MO functionality is quite complicated.5. Control functions od the system. Law restrictions (e.g. private data protection), tax and custom rules, access rigts etc. are typical aspects of the assumed business model and must be resolved by MO algorithms of the used ecommerce software. The definition of tax payment moment, the methods of cooperation with suppliers and integration with fiscal systems of the BO layer are generating extra problems to resolve by the e-business supporting software. In addition, the mentioned solutions are local type, and even not consistent inside EU or U.S.A. Globalization of the market and ecommerce precedes development of law rules. Therefore information systems must realize complicated non univocally formal and bookkeeping procedures which are real development barriers. For the MO software this changing surroundings makes real problem to resolve. The more global supply chain, and the more wide area of interaction of the ecommerce, the more complicated modules and algorithms of MO layer have to be used.
Logical layered model of ecommerce allows on successful building of dedicated e-business structure operating in the defined local supply chain. The main problems before the supporting software is to describe the structure of external and internal services of the MO layer. This way, reduction of the MO barriers allows to rise a level of the whole system integration. It is one of good examples of the SOA applying in design optimum information systems for e-business purposes.

How to realize successful ecommerce system?

How to realize successful ecommerce system, reducing conceptual problems before the MO layer? First of all, define the conceptual e-business model which may be realized and describe it as two layer system MO and BO. Then define GSC, and chose suitable local supply chain, the most appropriate for a given economic organization. Then set formal relations between the participants of LSC, what will automatically define right logistic processes and pathways. Describe all clearance rules with budgets, suppliers and customers, taking into account law and tax rules. After that fix all law and formal barriers, bounding the suggested model of ecommerce. Make a fine tuning of the conceptual model until it will be univocally and understandable for information analysts.
Since this moment it has been possible to define internal relations between layers FO and BO dedicated to the assumed model of ecommerce. It is necessary to fix the relation between selling department and physical stock, mainly answer the question if it is possible to sell something what is not present in a physical stock. Than the most important question is encoding items in physical stock and virtual database and fix the relation of FO and BO codes. The best solution is univocal relation one to one, but depending on the assumed model, the relation one to more is available. The next step is document circuit implementation into the system, regarding relations customer to FO, customer to BO and FO to BO, assuming bookkeeping rules as primary key.
The above set of rules allows for precise definition of services required from the MO layer and right design of suitable software. It should be noticed, that inside the MO layer, the external services of e-payment (PayPal, e-pay, Western union, etc.) represented by modules add on are included. These software exchange data with FO layer offering suitable interface for the customer and parameterization of payment processes (currency exchange and exchange ratios). It is necessary to import suitable e-payment module from the supply chain to the MO layer and its full integration with the whole ecommerce software system. Another group of necessary external services is forwarding, especially courier services, as DPD, DHL, UPS, USPS, etc. Each service is representing in the ecommerce system as an independent module of MO layer, integrated with a total sum of customer’s order and clearance procedure in BO layer. These external services are elements of the SOA structure of the ecommerce system and may be activated on request after including suitable service into defined local supply chain. At every moment active external services may be replaced by other ones, more appropriate and functional to the e-business model. Some new services may derive in the surroundings at any moment. So the MO layer must be modifiable and highly elastic.
The next group of services required a detailed analysis is information exchange services between all layers of the system. The MO layer offers linkage with a customer until the moment of placing the order. Then MO take control on e-payment procedure, generating suitable communicates to client and inform the BO about receiving payment. Since that moment only BO has been changing information with the customer. Information from FO about the order and its positions (stock indexes) must be transmitted to BO in univocal format for real stock position updates and client identification, or for generation suitable order to suppliers from the related GSC. Also all data received from the FO must be verifiable for fiscal devices. Therefore MO layer transmitter must convert stock indexes before data transfer. The remained functions of the ecommerce software system related to physical realization of business transaction overtake the BO layer. It realizes all clearances and registration procedures inside the defined supply chain. From the above it follows the primary role of MO layer in the structure of any ecommerce system.

Conclusions

The presented above model of e-business shows that the greatest problem of implementing and designing of ecommerce system is suitable structure and functionality of the MO layer. Defining the local supply chain by undersign appropriate agreements for the assuming ebusiness model suitable modules designed for a concrete MO software system related to the offered external services must be available from the suppliers. It is necessary for integration of all layers together with the internal services offered by the MO modules and functions. It also generates suitable forms and templates for the customer of the e-business, related to payment, information exchange and time realization control. It is condition for the customer participation in the external services of the defined GSC.
There exist precise relation between the supply chain structure and design of the software of MO layer, closely related to SOA. It may be stated that only external services offered together with suitable MO module are acceptable by a given e-business supply chain. The quantity of the external services available inside the formed local supply chain is changing along time. Also functionality of the services are changing. Therefore the software of MO layer must be elastic and open architecture type (modular structure and SOA architecture). Communication between FO and BO require MO services and strongly depends on the structure of financial control systems and logistic procedures. Therefore there is no universal solution of MO systems for a given organization and e-business model. All available on the market ecommerce systems require tuning.
Server systems of ASP and PHP type offer the best possibilities for operational properties of the MO software. But their support for graphical and multimedia demands from the FO systems is rather poor, because they offer standard templates and frameworks. Nice presentation should be realized using the external add ons and flat pages linked to operational sides.
As a general hypothesis derived from the presented article, the statement about bounded possibilities of ecommerce system development due to MO functionality and application software may be assumed. On the market, applications based on the os-Commerce framework and ZenCart are the best commercial applications. The future lays before SOA services possible to include into formed local supply chain of a given e-business and their integration with MO layer systems. It is continuous procedure of fine tuning the e-commerce systems which is possible for all elastic solutions.
1 Hau L. Lee and Seungjin Hang, „E-Business and Supply Chain Integration”, Stanford Global Supply Chain Management Forum November 2001, SGSCMF- W2-2001,
2 M. Eric Johnson and Seungjin Whang, “E-business and Supply Chain Management: an Overview and Framework”, Productions and Operations Management, 11, 4, (2002), 413- 423.
3 S.M. Disney, M.M. Naim, A. Potter, “Assessing the impact of e-business on supply chain dynamics”, Int. J. Production Economics, 89, (2004), 109–118.
4 Tadeusz Gospodarek, “Logical Layers of Entrepreneurship”, Proceedings of the The 9th International Entrepreneurship Forum (9th IEF), 16-18 September 2009, Istanbul – article No.40, ISSN 2070-6944.
5 http://en.kioskea.net/contents/entreprise/e-business.php3
6 http://www.oscommerce.com/
7 http://www.zen-cart.com/
8 http://www.iasb.org/IFRSs/IFRs.htm
9 http://www.cooliris.com/
10 http://nngroup.stores.yahoo.net/ecusexreppri1.html
11 https://www.paypal.com/uk/cgi-bin/webscr?cmd=_home&locale.x=en_GB
12 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
13 M. Bell, "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. (2008), Wiley & Sons

Figures at a glance

Figure 1
Figure 1

References






Copyright © 2024 Research and Reviews, All Rights Reserved

www.jffactory.net