Insight Matters:
Global Network
Considerations
for eProcurement
and Extranets
Prepared by
James E. deMin
Infonet Services Corporation
eProcurement
Volume 1 www.infonet.com
Introduction
eProcurement is another name for B2B (Business-to-Business) purchasing of goods and
services through extranet trading exchanges, direct ERP-to-ERP and internet connections
with suppliers. According to Fortune magazine, manufacturers spend an average of 55
percent of their revenues on goods and services, and service companies spend more
than 15 percent. The Boston Consulting Group (BCG) predicts that one-fourth of all
B2B purchases will take place online by the end of 2003. MNCs (Multinational
Corporations) are cutting costs and increasing profits by exploiting the power of
eProcurement techniques. Already a well established technique for optimising an
enterprise s supply chain and reducing procurement expenses, eProcurement necessi-
tates three fundamental requirements; (1) re-thinking organisational assumptions
regarding procurement processes, (2) re-engineering MRO (Materials, Repairs and
Operations) business processes, and (3) optimising enterprise applications and the
supporting IT infrastructure to ensure the systems deliver unimpeded around-the-clock
availability and optimum performance.
For suppliers, eProcurement provides functions that include electronic workflow to track
orders through fulfillment and billing, methods for collecting payment (e.g. electronic
invoicing, credit cards, electronic data interchange and electronic funds transfer), etc.
As with buyers, suppliers seeking to undertake an eProcurement initiative must overhaul
their business processes and adopt common procedures that cross industry, geographic
and other boundaries, as well as be able to accommodate security and multi-language
challenges. While the technologies offered by specialised e-Procurement software
vendors (e.g. Ariba, Commerce One, etc.) and more traditional ERP vendors (e.g. SAP,
Oracle and PeopleSoft, etc.) provide a vast array of functional capabilities, these must
now be extended globally to accommodate the demands of integrated logistics chains,
supplier hubs, extended supply chains, etc.
However, for all the importance of eProcurement and the supporting infrastructure, all
too often insufficient attention is paid to the wide area network (WAN). For example,
if pre-deployment and/or upgrade testing of the supporting software is limited to only
the campus LAN environment, the software s true WAN performance only comes to light
as the application begins to be promoted into production and users are being added to a
live system. Also, leading up to production rollout, network managers are often
2
eProcurement
Fragmented logistics Integrated logistics Collaborative
chain chain Strategies
Market Place
Figure 1 - Market Places, Hubs and Extended Supply Chains
provided with very limited requirements (e.g. number of users and "go-live" date) from
which they must size the required network. They are also often not made aware of
software s interfaces with other applications, which drive application-to-application or
"A2A" transactional traffic. When users complain about disconnects or slow response
times, all focus is upon the network. In fact, Gartner, Inc. estimates that more than
80% of application availability and performance problems are being blamed upon the
network. Precious time, valuable resources, and scarce IT funding are then spent
on trial-and-error quick-fixes (e.g. server upgrades, database tuning, etc.) until
performance is improved.
This unfortunate situation can be avoided by understanding more about the network
profiles of enterprise-class applications and what choices are available for optimising
performance over WANs. Most software vendors are now touting their new browser-
based "n-tier designs" where little or no software is resident on the client workstations.
Despite the desktop support advantages of such architectures, remote presentation can
add traffic to the network while making end-user performance more vulnerable to
network delay. Web access, underlying both the HTML and network computing approaches,
rely upon HTTP, as well as XML, which have performance issues over the WAN.
3
eProcurement
eprocurement overview extend as far as its suppliers, customers, and internal
operational lines of business and administrative organisa-
eProcurement is all about cost savings and efficiency, tions. For MNCs this then means even greater levels of
spanning the entire vertical spectrum of industries, from dependency upon their global network and service
chemicals to manufacturing and airlines to agriculture. providers, if the potential opportunities of eProcurement
The reach of an enterprise s eProcurement processes must are to be realised (refer to Figure 2).
Advantages for the distributor Average expected savings
Store management 2 to 8%
Stock management 10 to 40%
Increase in sales 5 to 20%
Reduction in logistics costs 3 to 4%
Advantages for the producer Average expected savings
Reduction in stock 10 to 40%
Acceleration of restocking cycles 12 to 30%
Increase in sales 2 to 10%
Better customer service 5 to 10%
Source: AMR, 2001
Figure 2  Advantages of eProcurement
The objectives of eProcurement include the following: >> To make effective use of human resources in the
>> To improve service levels to buyers, suppliers and users. procurement process.
>> To develop a more integrated approach to procurement >> To reduce off-contract spending by using technology to
across the enterprise s supply chain. increase user awareness of existing contract facilities
>> To minimise the transaction costs associated with and by making it easier to order against them.
procurement through standardisation, streamlining and >> To leverage buying power by using technology to support
automation of the procurement processes within, and identification of opportunities for aggregation and by
where appropriate across agencies and sectors. facilitating the aggregation of user requirements within
>> To promote competition among suppliers while and across lines of business.
maintaining reliable sources of supply. >> Reduce transaction costs by using technology to auto-
>> To optimise inventory levels through the adoption of mate processes, which are currently paper-based, and to
efficient procurement practices. streamline and standardise processes and documentation.
4
eProcurement
The organisational assumptions and business processes In a highly integrated end-to-end eProcurement process
involve internal alignment of control over procurement poli- (refer to Figure 3), the applications of suppliers not only
cies, procedures, and supplier relationships. To achieve fully receive orders without re-entering them, but also respond
leveraged buying volume, an enterprise must put into place: with availability, delivery dates, and status reports.
This requires integrated order-fulfillment and supply
>> Centralised control of supplier relationships, including a chain systems, with robust and properly sized networks.
reduction in the supplier-base, the establishment of corpo- Suppliers must also find the best means of creating and
rate preferred suppliers, and negotiated agreements based maintaining electronic catalogues that suit the buyers
upon volume. needs. This may include catalogues customised for the
>> Predominantly standardised procedures and policies. buyers eProcurement applications, the marketplaces they
>> Supporting software applications linked internally with use, and the supplier s website catalogues. Consequently
operational lines of business and administrative depart- the transactions that must traverse the networkbetween
ments, and externally with suppliers, trading exchanges these geographically disperse parties are extremely complex
(e.g. TradeRanger, Elemica, etc.) and extranet partners. and the amount of data moved can vary significantly from
one application to another. To illustrate this point, consider
the data categories involved in the procurement process
(Refer to Figure 4 on page 6).
Procurement Supply Chain Management Customer Relations
Due
Direct- Diligence
Asset / Excess
Auction /
Spot Purchase
Inventory
Reverse Auction
Sales
Market
Making
Risk Transpor- Shipment
Management tation Tracking
Promotions /
Direct-
Deal Mgmt.
VMI / Co-managed Inventory
Replenishment
POs /
CPFR
Market Data
Releases
Collection
Contract
Returns
Management
MRO /
Buyer
Supplier
Auction /
Shared
Aggregation
Aggregation
Reverse Auction
Product Catalog - Performance Scorecard - Benchmarking - Management Alerts
Interenterprise Data Warehouse - Workflow Mgmt. - Data Transmission - Business Messaging
Discussion - News - Reference Library - Employment - Advertising
Figure 3 - End-to-end eProcurement Process
eProcurement
5
Allocation
Forecasting
Demand
Contract Management Finance Management
>> Customer Records >> A/P Invoicing
>> Price Lists >> Financial Holds
>> Sales Quotes/Sales Orders >> Applied Costing
>> Project Estimating >> WIP Journal to Cost of Sale
>> Sales/Project Invoicing >> Period Details/Period End Control
>> Credit Notes >> Asset Depreciation
>> Integrated Reporting >> Fixed Assets
>> Capacity Forecasting >> Project Costing
>> Contract Management >> Job Cost Analysis
>> SPEC 2000/ANSI X12 Customer EDI >> Detailed and Summary G/L
>> SPEC 2000/ANSIx12 Customer
Materials Management
>> Supplier Records MRO
>> Quote/Purchase Order Processing >> Quotations
>> Material Planning >> Planned Arrivals
>> Stock Status by Stock Type/Warehouse >> Work Scope Details
>> Allocations Control >> Life Control/Full Process Package
>> Consumable Kits >> Project Inspection
>> GRN Generation >> Maintenance Planning
>> Returns Picking/Packing List >> Components
>> Part Master Control (ATA configuration) >> Tooling
>> Multi-Warehouse/Stock Locations >> Material Kitting
>> Serialized/Life Control >> Project Control
>> Bar Coded Stock Control/DCS >> Non-Routine Task Cards
>> Lot Control >> WIP
>> Warranty Generation and Tracking >> Complex Assemblies
>> SPEC 2000/ANSIx12 Supplier EDI >> Rework
>> ATA Chapter  Section
Personnel >> Loaner Exchange
>> Employee Records >> Repair Survey
>> Labor Collection
>> Integrated Reporting Quality
>> Time and Attendance Module >> Receipt Inspection Control
>> Training and Certifications >> Technical Manual Control
>> Authorized Release Certificates
Scheduling & Planning >> Tooling Calibration Tracking
>> Work Center Setup >> Tooling Reporting
>> View/Update WIP
>> Capacity Planning/Forecasting Administration
>> Repetitive Schedules >> User Profiles
>> Permissions
>> Company Setup
>> Security
Figure 4 - eProcurement Data Categories
eProcurement
6
As noted in Figure 4, the data categories involved in >> Ping-Pong Transactions: numerous small packets
exchanged between servers in the enterprise
eProcurement are not only voluminous, but also represent
application s n-tier architecture
complex processes, relationships, interdependencies,
>> Unidirectional Data Transfers: consisting of a large
potential inconsistencies in definitions, units of measure,
number of packets sent between servers or from
language differences, etc. These then result in the need for
the server to the client, and a small number of
the supporting applications software to provide sophisticated
acknowledgement packets sent from the client or
edits/validations, pick-lists, and other system-level func- server to another server
>> Hybrid Transactions: hybrids consisting of ping-pong and
tions, which contribute to extremely large and highly-complex
unidirectional bulkdata transfer transactions
transaction sets. Consequently, eProcurement applications
and their associated transactions are among the most com-
Similarly, the characteristics of these transactions can
plex and challenging from a networkdesign perspective.
vary widely between the individual levels in the enterprise
application s n-tier architectures.
Nature of eprocurement Transaction
eProcurement transactions also have highly complex network
Under most circumstances, these servers (refer to Figure 5)
traffic patterns and size characteristics, influenced by such
will be co-located geographically on a clients local Ethernet
factors as the complexity of the client s business processes,
LAN, which greatly enhances performance and simplifies the
geographic locations of buyers/suppliers, languages, edits,
networkrequirements. One possible exception could be
validations, security, etc.
locating a Web server closer to remote users. The complex
eProcurement processes for which the enterprise application
Typically, these transactions fit into one of the
software is deployed, requires communications with suppli-
following categories:
ers applications almost always located outside of clients
campus LAN environments.
Order-Entry
Data Server Storage
Web Server
Application
0.8 KBS 0.2 KBS
.6 KBS
Server
Requests
Responses
Up to 105 KBS Up to 112 KBS
Up to 6.1 Meg
Up to 112 Turns
Up to 1,017 Turns
Up to 191 Turns
Figure 5 - Example of Transactions Between Servers in n-Tier Architecture
eProcurement
7
To illustrate this point, consider the following example transactions traversing the WAN in this example. It is the
showcasing step-by-step, the completion of an order-entry geographic location of the other application s servers that
transaction initiated in the UK: will control the overall performance of the transactions
supporting the placement of the order.
>> The UK-based buyer s software application must commu-
nicate with a supplier s inventory application based in Applications are typically interfaced with other applica-
the U.S. in order to validate product availability. tions using an Enterprise Application Integration (EAI)
>> The transaction is completed by receipt of a shipping technology such as those offered by Tibco, SeeBeyond
confirmation from a logistics provider based in the U.S. and others. Also, enterprise-class applications are inter-
faced to each other via application servers (refer to Figure
Hence, the eProcurement process necessitates numerous 6). As a result, transactions that were designed and
transactions between several software applications locat- optimised to interface with each application s own Web
ed in different geographies, which must be transacted over server (connected via a LAN) are now being executed over
the WAN infrastructure. The physical location of the initi- the WAN between their respective application servers.
ating users has a minimal impact on the overall number of These transactions are referred to as A2A transactions.
Buyer's
Data Server Storage
Web Server
Order-Entry
.6 KBS 0.8 KBS 0.2 KBS
Requests
Responses
Up to 105 KBS Up to 6.1 Meg Up to 112 KBS
Up to 112 Turns
Up to 191 Turns Up to 1,017 Turns
Supplier s
Data Server Storage
Web Server
Inventory
Application
1.8 KBS 1.2 KBS 0.4 KBS
Server
Requests
Responses
Up to 61 KBS
Up to 1.9 Meg Up to 7.1 Meg
Up to 211 Turns
Up to 291 Turns Up to 1,113 Turns
Figure 6 - Application-to-Application (A2A) Transactions
eProcurement
8
In this simple example, a number of dramatic observations technology) that are not on the campus LAN, A2A
should be made: transactions will generate WAN traffic between the
geographies where the servers are domiciled. This may
>> Request and Response Transactions Can Vary seem obvious, but the physical location of application
Widely in Size  Enterprise-class application software servers for interfaced applications is often overlooked
request transactions can be sub-kilobyte, whereas the during system design activities.
response transactions can be multiple megabytes in size.
This is a result of the great functional richness of the soft- >> Inter-Applications Transactional Characteristics 
ware s transactions, which is achieved by returning large Finally, applications exchange transactions with other
amounts of data and content. Moving this data back applications by executing each other s transaction sets,
upstream to the user s client workstation is achieved by which were designed and optimised by vendors for
numerous round-trips or "turns." These characteristics communicating with their own Web server (co-located on
create some very challenging demands upon the network, the campus LAN), not other vendors application servers
which must accommodate the associated bandwidth and accessed over the WAN. As a result, A2A transactional
latency effects. traffic may have characteristics that represent a vexing
challenge to the network group (refer to Figure 7).
>> Total Number of Transactions is Largely Independent of the
Number of Users  The total number of transactions to Therefore, the first step in sizing and optimising a network
complete an eProcurement process is entirely a function of on behalf of an eProcurement process is to recognise that
process-complexity and not the number of actual system the network is not only influenced by the direct users
users. Complex processes such as eProcurement can gen- accessing the procurement application, but also by the
erate literally hundreds of transactions initiated by only a complexity of the business processes, interfacing applica-
single order-entry transaction, with the majority of transac- tions and the location of their servers. Additionally, as
tions being between applications to applications (A2A). previously noted, the transaction characteristics of software
vendor s n-tier applications can vary widely in terms of sen-
>> Co-location of Servers is Not Always Possible  Since the sitivity to latency and bandwidth, depending upon the
eProcurement process requires the software applications specific vendor s software modules and the data intensity
to exchange data with other applications (often using EAI of the transactions being executed.
Transaction Profile
834 Bytes
Request
1-to-7,711 Ratio
Up to 6,431,215 Bytes
Response
Up to 1,041 Turns
Figure 7 - Profile of a Single Enterprise Application Transaction (Application Server Layer)
eProcurement
9
Latency Sensitive Versus By contrast, bulk data transfer transactions are almost
Bandwidth-Sensitive always bandwidth-sensitive, since they involve a very large
Individual transactions may be latency-sensitive, band- number of data packets. Additional WAN bandwidth will
width-sensitive, or a combination of both. This means that usually enable these packets to traverse the WAN more
the WAN design must exhibit the performance characteris- quickly and improve response time. Therefore, transac-
tics that best matches the individual transaction s unique tions containing large amounts of data such as photos,
needs. With latency-sensitive transactions, small varia- billing history, detail product specifications, etc. can be
tions in network latency, such as an alternate route that optimised by allocating greater bandwidth.
adds up to 25 milliseconds (ms) of incremental latency,
will increase transaction total response time. Transactions Infonet has extensive experience with eProcurement
sensitive to latency are almost always challenging to tune implementations using SAP, Oracle and other applications
over the WAN because traditional tuning methods, such with which these are likely to be interfaced, and having
as bandwidth upgrades and router prioritisation, will not performed in-depth network profiles of numerous
typically improve performance. The root-cause of such off-the-shelf and custom applications can design
latency often lies within the coding of the application s network solutions that are optimised to satisfy client s
internal logic, as well as the information intensity of the eProcurement business requirements. Infonet s
transactions edits, validations and other complex Application-Defined Networking (ADN) approach and solu-
business processes that are transparent to all but the tions portfolio can be used to minimise the complex
system architect. Finally, applications vendors design impacts of latency and bandwidth through solutions
and optimise their software for a local environment such as Asymmetric Committed Information Rate (CIR).
where all servers in the n-tier architecture are co-located, Infonet also offers Class of Service (CoS) features on three
versus diverse locations connected via a WAN. separate global network platforms: Global Frame Relay,
IP VPN Secure and Global ATM. MNCs are increasingly
Ping-pong transactions are always latency sensitive as a implementing CoS features in order to maximise the
result of hundreds of data packets passing across the performance of their enterprise applications. By working
WAN, with user response time slowed while the user waits closely with the client, the ADN methodology enables
for all these packets to be exchanged. To illustrate this Infonet to determine which VPN service (Global Frame
point, consider a billing transaction that requires 500 Relay, IP VPN Secure or Global ATM) is the right
ping-pong transactions across the WAN to execute. solution for their operational environment.
A 25ms increase in latency (due to network issues,
client and server delays, or router delays) will result Estimating Bandwidth
in an additional 6-second delay (i.e. 250 transactions x The bandwidth requirements associated with deployments
25ms/transaction). Therefore, if in the previous example of eProcurement applications can be reliably planned as
the order-to-bill process requires an interface transaction long as basic information is available regarding the appli-
to the billing application, this latency must be considered cation s transaction characteristics and the estimated
in the network design and expectation for end-to-end number of users. Infonet s patent-pending Network
performance for the intended business process. Analysis Program (NAP) methodology is used to measure
and profile enterprise applications, such as Oracle and SAP
eProcurement
10
with the voluminous data captures resulting in very precise buyer physically located in the UK initiates order-entry
transaction characterisations. These can then be used to transactions (server domiciled in the UK), which exchange
model expected performance prior to implementing or transactions with the supplier s SAP inventory application
upgrading the supporting application software. domiciled in the U.S.). Such an example would result in a
ping-pong effect for both application s transactions, with
In estimating bandwidth requirements for ping-pong trans- the variables being as follows:
actions, there are several key variables:
N = 25 active users
N = the number of expected concurrently T = 120,000 milliseconds
active users at a location (2 minutes, which is common)
T = user think-time (the amount of time a user needs K = 100 packets inbound, 120 packets outbound
between successive transaction executions) M = 60 bytes per inbound packet, 200 bytes
K = the number of packets per transaction in any one per outbound packet
direction (plus 48 bytes for the WAN overhead)
M = the number of bytes per packet in any P = 150ms (one-way latency)
one direction
P = one-way network latency Therefore, 43Kbits/sec would be the peak bandwidth
usage between the UK and the U.S. for the SAP inventory
Using these data points the calculation of estimated band- validation. Furthermore, if a 70 percent maximum planned
width in any one direction is as follows: utilisation threshold were to be assumed in engineering
this circuit, the bandwidth required would be 43Kbits/sec
Estimated Bandwidth= divided by 0.7, or approximately 64Kbits/sec.
(8 bits/byte) x (N) x (K) x (M) ÷ (K x P + T) bits/sec
Hence, the end-to-end performance of the eProcurement
The estimated bandwidth requirements for such a transac- process is a function of not only the initiating request tran-
tion between two geographic locations is then derived by sition, but also all of the other transactions included in the
calculating the maximum of the estimated bandwidth in business process workflow rules, such as the validation of
both directions. That is, the time between successive inventory. The network design must adequately address
transactions generated by a single active user is all of these factors in order to yield a predictable and
(K) x (P) + T, because (K) x (P) is the total network latency reliable user-experienced response time.
for the K packets (assuming a one-to-one ping-pong
exchange), and T is the time between transactions. During The bottom line is that in order to accurately estimate the
this time (i.e. K x P + T), the user will have submitted, in bandwidth requirements for eProcurement these interface
the specified direction, K x M x 8 bits of data. Finally, the transactions must also be taken into consideration, as
number of active users (N) is applied to derive the total well as the network profile or application characteristics
estimated bandwidth for the intended user population. (e.g. latency) of the applications with which SAP, Oracle,
etc. is interfaced. The geographic locations of buyers/
Expanding upon the original example, assume that the suppliers and the servers on which their interfaced
eProcurement
11
applications are running must be clearly identified and clients networks and further refines bandwidth require-
the business processes understood. Infonet s ADN ments, based upon unique insights into the performance
methodology incorporates these factors into the design of characteristics of the supporting technologies.
The estimated inbound bandwidth required to support the user-initiated order-entry transactions, then, is approximately
16Kbits/sec, calculated as follows:
(8 bits/byte) x (25 users) x (100 packets) x (108 bytes/packet)
= 16 Kbits/second
(100 packets) x (150 milliseconds) + 120,000 milliseconds
Similarly, the estimated outbound bandwidth is approximately 43Kbits/sec, calculated as follows:
(8 bits/byte) x (25 users) x (120 packets) x (248 bytes/packet)
= 43 Kbits/second
(120 packets) x (150 milliseconds) + 120,000 milliseconds
Order-Entry User
SAP Order-Entry
Supplier
Inventory
Figure 8 - A2A WAN Transaction
eProcurement
12
ransaction
T
A2A
SUMMARY
eProcurement initiatives make tremendous demands of an IT organisation s network
infrastructure. In order to ensure the success of these business-critical processes, it s
crucial that the networking group is involved at an early enough stage, so that they may
plan the deployment of a reliable, scalable, resilient and intelligent infrastructure. This
will help ensure that the eProcurement initiative meets the highest expectations of busi-
ness managers, users, extranet partners, interfaced applications, etc. Infonet Services
Corporation has unique insights into the network performance characteristics of enter-
prise-class software, gained through years of profiling these applications in clients
real-world environments, and designing network solutions to optimise performance.
Networks designed using Infonet s ADN approach represent the best value to multi-
nationals seeking to optimise their eProcurement processes and yield ROI from their
technology investments.
About Infonet
Infonet Services Corporation, known for its quality of service, is a leading provider of
Worldwide Headquarters
managed network communications services for nearly 3,000 multinational enterprises.
Asia-Pacific
391 A Orchard Road
#13-08 Ngee Ann City
Employing a unique consultative approach, Infonet offers integrated solutions
Tower A
Singapore 238873
optimising the complex relationship between enterprise applications and the global
Tel: [phone]
Fax: [phone]
network. Extensive project management capabilities are the foundation for the services
Europe, Middle East & Africa
and solution offerings (broadband, Internet, intranet, multimedia, remote and local
350/358 Avenue Louise
access, provisioning, application and consulting services) positioning Infonet as the
Box 3
B-1050 Brussels, Belgium
ideal single-source partner for multinationals. In particular, Infonet IP VPN solutions
Tel: [phone]
Fax: [phone]
offer multinationals a unique combination of Private and Public IP services as well as
Latin America
a full set of Managed Security Services.
Mardoqueo Fernandez 128
Piso 7
Providencia, Santiago, Chile
Rated "Best in Class" overall in Telemark s survey of Global Managed Data Network
Tel: [phone]
Fax: [phone]
Services, Infonet has also won "Best Customer Care" and "Best Carrier" at the World
North America
Communication Awards. Founded in 1970, Infonet owns and operates The World
2160 East Grand Avenue
El Segundo, California
Network®, accessible from more than 180 countries, and provides local service
90245-1022 usa
support in over 70 countries and territories.
Tel: [phone]
Fax: [phone]
Infonet's stock is traded on the New York and Frankfurt Stock Exchanges under the
An ISO Registered Firm
symbol IN. Additional information about the company is available at www.infonet.com.
Infonet, DialXpress, Global Connect and The World Network are registered trademarks of Infonet Services Corporation. DialXpressway, PerspeXion and Insight Matters are trade-
marks of Infonet Services Corporation. Other product names that may be used herein are for identification purposes only and may be trademarks of their respective companies.
13
Copyright © 2002, Infonet Services Corporation. All rights reserved. 01/03
MP-WP011-01.