Visio Corporation’s Technical Deployment of Concur Technologies’ CompanyStore

August 1999

White Paper

By Concur Technologies and Microsoft Corporation

Version: Release 1.0

Business Problem

Visio Corporation, founded in 1990, develops, and markets drawing and diagramming software. The company pioneered the business-drawing category in PC software, bringing powerful computer graphics to the desktops of mainstream computer users.

Visio prides itself on maintaining cutting-edge internal systems. Explosive growth requires its operational process and supporting systems to support this growth in a cost-effective manner while maintaining adequate, though not restrictive, accounting controls.

Leading a global company with rapid growth plans, Visio's management recognized the need for centralized processes and systems to support the company through its explosive growth. "We sell through many channels and in many languages," stated Ed Leary, Controller, "so we need to get down to the lowest level of detail and disseminate information to as many people as is appropriate," he observed. With that in mind, Visio selected SAP's product to meet their financial management and reporting needs.

Neal Myrick, Director of Worldwide Information Technology and Facilities for Visio, is responsible for all the internal systems and technologies for the corporation worldwide. This includes LANs, WANs, phone systems, SAP, Onyx Customer Center, servers, and desktops. In addition, Myrick's facilities group handles office space worldwide, from San Diego to Chicago, and from Dublin, Ireland to Sydney, Australia. Myrick and his team were responsible for rolling out SAP worldwide. With support from Hewlett-Packard, Myrick's team integrated five modules in a record 84 days.

After the SAP implementation, Visio purchasing professionals used SAP R/3 purchasing functionality to support the existing paper-based purchasing process, such as purchase order creation and goods receipt. The process of getting information to and from the purchasing department was paper-based and inefficient; many employees were reluctant to use the formally defined purchasing process. This meant that some employees were not taking advantage of special Visio pricing discounts negotiated by purchasing managers.

Visio was looking for a system that they could use to distribute the purchasing process to the end user community while still enabling them to leverage their investments in SAP R/3 and the corporate Intranet. Most importantly, Visio was looking for a system that would enable them to do this without increasing their head count. "We are big on Intranet-based applications," stated Myrick. "We wanted to find and license a user friendly, Intranet-based system that could be seamlessly integrated with SAP," he remarked.

“Our vision was to roll the product out worldwide, minimize training and reduce the amount of resources required to support end users," he concluded.

Such a system would have to be able to be accessed by any desktop in the organization, both domestically and internationally. The system needed to work extremely well over low bandwidth networks to support remote sales offices with dial up connections. The system would also need to run on a variety of desktop operating systems and browser versions since Visio had no wish to embark on upgrading and standardizing on browser versions for this project.

Since the system would go to a large user community, employees would have to be able to use the system with little or no training. The user interface needed to be extremely user friendly. The system would need to be able to handle multiple currencies, multiple languages, and multiple business processes to support Visio’s global business.

The system needed to integrate seamlessly into the existing IT infrastructure, providing connectivity between the Corporate WAN, the Internet, Exchange, and SAP R/3.

Myrick's team also required that the software be able to route orders for approval and that it be able to automate the signature authority tree and check the progress of POs without requiring significant manual labor.

A majority of the operating expenses associated with Visio’s business activities is incurred in marketing related activities. Leary wanted a purchasing system that would allow the budget managers to track commitments, receipt and payment of invoices in order for Visio to effectively manage this transaction stream.

The general goals and direction of the proposed system are outlined in the table below.

Proposed Process and Solution

After extensive evaluation Visio decided to install a commercially available software package, CompanyStore™, produced by Concur technologies in Redmond, Washington. CompanyStore is part of the Concur employee-facing suite of applications that enable connectivity between the employee, the enterprise, and the emerging electronic commerce infrastructure provided on the Internet. CompanyStore enables employees to purchase goods and services directly from corporate approved vendors via the Internet.

The CompanyStore system has an extremely user-friendly interface implemented using HTML and DHTML. The system uses no Java™ or ActiveX™ controls on the client so no software need be installed on the client's computers accessing the system. This supported Visio’s requirement of easy and rapid deployment.

Users of the new Visio purchasing environment point their Web browser at a server in Seattle running the CompanyStore application. They are able to select pre-approved goods and services published by the Visio purchasing department. Once a user selects the items they wish to purchase, they create an order. This order is routed around Visio according to pre-defined business rules that the purchasing department has configured in the CompanyStore system. The CompanyStore system allows for the dynamic creation of content and business rules.

Once a user creates and submits an order using the Web interface, the CompanyStore system routes the order for approval. Approval notifications are executed using Microsoft® Exchange. A manager receives an e-mail with an embedded hyperlink. The manager clicks on the hyperlink and is taken to an approval page in his/her Web browser.

Sample Visio Procurement Business Process

Once the order is approved, the CompanyStore integration server sends the order to the appropriate destination. If the order needs to go directly to the supplier, CompanyStore sends the order to the supplier using e-mail, EDI, or FAX.

In some cases, the order needs to go to purchasing for processing before the order can be sent to the Supplier. Purchasing needs to perform functions such as the generation of asset information and the correction of account coding information. In these cases the CompanyStore system automatically loads information into the Visio SAP R/3 Materials Management module for processing by purchasing.

ROI

Over $1million savings the first year

Visio achieved over $1 million in savings in the first year alone through CompanyStore. These savings are derived from the following areas:

Quantified

• Decrease in requisition processing costs.
  
  
• Decrease in maverick spending.

Other

• Decrease in the time to process payables.
  
  
• Decrease in time spent by budget managers gathering financial data.
  
  
• Increased time for purchasing managers to focus on strategic activities.

Decreased requisition processing cost provides $743,000 annual savings

Prior to installing CompanyStore, Visio spent an average of 70 man minutes to process a single requisition. The elapsed time could be a long as 10 days. This cost Visio an average of $49.00 per requisition.

Requisition Process Prior to CompanyStore

Requisition Process with CompanyStore

With CompanyStore, there are significantly fewer steps, decreasing the average cost of processing a requisition to $5.45.

Visio processes over 17,060 requisitions/year, giving the company a savings of (49-.5.45)*17,060 = $743,000 in requisition processing costs alone.

Decreased maverick spending

Because the paper-based process was so cumbersome and time-consuming, it was often easier for Visio employees to buy “outside the system” from non-contracted vendors. Also, it was not clear to most employees who the contracted vendors were. Therefore, much of Visio’s MRO expenditure went to vendors with whom Visio did not have contract pricing. Visio estimates they were able to re-direct half of their maverick spending to contracted vendors and saved $225,000 the first year.

Decrease in the time to process payables

Prior to CompanyStore, a high percentage of requisitions submitted to Visio vendors contained incorrect cost-coding information causing the vendor invoices to also be incorrectly coded. The accounts payable department spent a significant amount of time re-coding invoices. With CompanyStore automatically capturing the correct cost-center information on the requisition, a much lower percentage of invoices sent to Visio were incorrectly coded.

Decrease in time spent by budget managers gathering financial data

Before the installation of CompanyStore, it was very time-consuming for budget managers to retrieve financial reports. They spent much of their time pulling together and analyzing spreadsheets. The reporting capabilities of CompanyStore allows managers to quickly obtain financial data.

Increased time for purchasing managers to focus on strategic activities

Prior to CompanyStore, the purchasing department processed virtually every requisition. With CompanyStore, the purchasing department processes less than 15% of all requisitions which frees their time to focus on higher level, more strategic initiatives. Additionally, the reporting capabilities in CompanyStore provide purchasing managers the necessary information for vendor evaluation and negotiation.

Project Overview

Approach

A phased implementation based on Concur Technologies Implementation Methodology was adopted for the project. The project kick off was in December. Key stakeholders from the appropriate groups were formed into a SWAT team and briefed on the goals of the project. The goals included bringing Visio’s top five MRO vendors onto the system by March the following year. These vendors accounted for approximately 80% of Visio’s MRO transactions.

The customer environment and system development phases of the project ran through January and February. Installation of the development, test, and production environments was completed in late February. Throughout March, intensive user acceptance testing and business process refinements were undertaken. The initial rollout was completed by the end of March.

Functional Scope

The functional scope of the project was outlined as follows:

High-level functional scope

Organizational Scope

A project team was put together to install the new purchasing system and processes. Key organizational groups affected by the project were identified, together with key players from both Visio and Concur Technologies. Key user groups and organizations included the following:

General End User—this could be a domestic or international employee. The general end user uses this tool to create and track requisitions. Requirement to provide an easy and fast mechanism.

Administrative Assistants—the ‘power users’. They traditionally manage requisitioning for their group. Requirement to provide an easy and fast way to do this.

Corporate Procurement—This group processes/manages transactions from the two groups above. This group currently processes approximately 500 transactions per day. Requirement to reduce the turnaround time on a transaction while retaining accuracy of the data.

Visio Corporate and International—the initial geographic groups affected.

Roles and Responsibilities

Concur/Visio Project Headcount Requirements

Timelines

Visio had stringent guidelines for return on investment for software projects. The software they installed would need to be implemented quickly and not require large consulting efforts. The CompanyStore product was implemented over a four-month period. Timelines and milestones for the project are outlined in the table below.

Key Milestones

Application Architecture

Logical Architecture

The CompanyStore system architecture has three major components:

Employee—Employees who have a PC will typically have a Web browser and e-mail software on this computer. Employees access the CompanyStore system using this existing software installed on their PCs. Employees leverage the existing password and network connectivity options provided by this software to connect to the CompanyStore system.

BackOffice—The CompanyStore system resides within the corporation's back-office environment. The system consists of a presentation layer that provides a user interface to the Employee Desktop. This presentation layer talks through a suite of business objects to the data store layer that houses all CompanyStore-specific data. The CompanyStore system provides:

• Business services that allow a corporation to define and distribute its business rules.
  
  
• Business intelligence services that allow corporations to view the transactional data within the system in order to improve processes.
  
  
• Security services that control system access.
  
  
• Content services that allow the publication of content to users of the system.
  
  
• An integration layer that allows the CompanyStore system to interface to the existing IT infrastructure. This includes connectivity to EDI, e-mail, ERP, and directory system.

Outside world—The CompanyStore system can talk to the outside world via public and private networks. This enables CompanyStore to plug in services provided by other corporations. Online ordering, shipping, payment, and taxation systems may be plugged into the CompanyStore system.

CompanyStore Logical Architecture

Physical Architecture

Visio had standardized on Microsoft’s product architecture to support both its front and back office needs. CompanyStore supported Visio’s requirements for an application that could integrate rapidly into their existing environment without the requirement for additional support or training.

Top-level Application Architecture

Microsoft® Internet Explorer was the prevalent Internet technology on the Visio corporate WAN, with some employees using Netscape Navigator®. There was no plan to convert these users to Microsoft Internet Explorer. CompanyStore employed only HTML and DHTML technology that is supported by both Microsoft Internet Explorer and Navigator.

At the presentation level an IIS 4.0 server running active server pages was installed to serve HTML to the clients. These active server pages called business COM objects implemented in C++.

The business object layer communicates with the Microsoft® SQL Server™ data layer via ODBC.

Integration to external environments is achieved through use of the CompanyStore integration server. The integration server includes third party components, such as SAP Automation, and Microsoft® Site Server 3.0 Commerce Edition to integrate with external systems (see Integration).

Visio CompanyStore Physical Architecture

Since Visio was looking for a system that was easy to use and required little to no training, usability was a high priority. If the application was hard to use, employees were less likely to use the system, thus preventing the company from achieving the strategic advantages it intended to gain by deploying the software in the first place.

Achieving the right balance between usability and ease of deployment was a challenge because Visio had not standardized on a specific browser version or browser vendor. DHTML provides many design tools with which to increase the usability within a browser-based application. Unfortunately, many of these DHTML features are not compatible with all browser versions.

Some of the important usability design constraints are outlined in the table below.

Design Constraints

The CompanyStore system had an HTML-only front end and thus did not suffer from the installation complexities surrounding Client-side Java, ActiveX and Plug-in based applications. Use of DHTML was limited to implementations that were common between both Microsoft Internet Explorer and Netscape Navigator. Code was required within the CompanyStore system to detect earlier browser versions and disable the use of unsupported DHTML features.

Sample Screenshot of a CompanyStore HTML-only Transaction

Business Object Layer

The business object layer is comprised of a series of in-process COM subsystems implemented in C++ using the Active Template Library (ATL). Each subsystem resides in its own DLL. The procurement Requisition object is an example of a business object in the Order subsystem.

The base interface for all business objects is the Dataset object. The Dataset object is a COM interface which provides a data abstraction layer for almost all business objects in the system. This layer consists of a collection of properties for a given instance of an object. Each property within an object has a unique, numeric identifier. This identifier can be used to retrieve or set the value of the property in any given Dataset object.

One major benefit of this layer is that it allows for objects to be loosely coupled. For example, in order for a report object to get information about a user object, the report object is not dependent on the method or column names of the user object; the report simply needs to know the numeric identifiers for the desired data. If two different objects have common values, one object can be assigned to the other and only the like values will be copied. Using the same sample as above, a user object can be assigned to a report object resulting in the common values being copied.

An important part of implementing the system was enabling the CompanyStore system to be customized to support Visio-specific business rules.

CompanyStore/Rules is the system of customizing CompanyStore behavior by writing Microsoft® Visual Basic® Scripting Edition (VBScript) code that executes when events occur on CompanyStore COM objects.

When an employee submits an order, it triggers multiple events. For an employee using CompanyStore/Web, even the process of creating the order triggers events. For example, when a user first submits an order the OnSubmit event of the Order object is triggered. If script code is written in the order OnSubmit event procedure, that code executes. The code may force a resubmittal of the order, perhaps because the order amount is too high. In that case, the order OnResubmit event is also triggered and any script code written in its procedure executes.

If the order is successfully submitted—if nothing in the OnSubmit event procedure re-directs it—it is typically routed to an approving manager. The Order object routes the order by calling a method of the CompanyStoreWorkflow object. This triggers the workflow OnGetNextUser event. Code can be written in the procedure for that event to examine the order and, if its order amount is below a certain threshold, automatically approve it and send it to accounting. When the Order object calls on the CompanyStoreWorkflow object to route the order, script code executes and the order is automatically approved.

Customization of CompanyStore

Example

This script is a Sub Procedure that constructs an e-mail message to the specified user and posts it to the CompanyStore/Server Database. The CompanyStore/Order sub-system then sends the message:

Private Sub SendMessage(pUser)
Dim oMessage ' As Message
' Create the message object
Set oMessage = CreateCompanyStoreObjectLocal("CompanyStore.Message", pUser.Duid)
' Set properties of the message
oMessage.FromEmpID = CompanyStoreUser_Server
oMessage.ToEmpID = pUser.ID
oMessage.Subject = "CompanyStore Document - Notification Message"
oMessage.Body = "This message is being sent from the CompanyStore system administator."
' Send it
oMessage.Send
Set oMessage = Nothing
End Sub

Data

In addition to this Dataset abstraction layer, the Dataset also provides general methods for being stored and retrieved from a persistent store. Storage is completely transparent to the user of the object.

The Dataset provides a number of database services including generation of database optimized SQL, transaction commit and rollback, database connection pooling, and support for an unlimited number of site defined custom values. In addition to the base services, the Dataset layer supports dynamic stored procedure generation on SQL Server and Sybase®. Running a self-tuning utility, the application is able to optimize the most costly database operations.

Dataset also provides the ability to serialize the objects in a textual format with metadata (numeric identifier and value for that identifier). The format is called OTL (Object Transfer Language). OTL provides the capability of sending CompanyStore COM objects across the network to different environments, such as Java.

Supplier Integration

Visio wished to conduct business with a wide variety of suppliers. Each of these suppliers has varying degrees of technical sophistication. Visio wished to move into the world of electronic commerce but they did not necessarily want to exclude members of their supplier base who did not have the means or resources to make that leap with them.

To enable Visio to make this transition while preserving all their existing vendor relationships, it was determined that CompanyStore provided a wide range of choices for supplier participation and ensured that Visio’s partners were not burdened with proprietary software or data formats.

Technically unsophisticated suppliers did not need to make an investment in new technology to work with the Visio buying organization. By simply supplying their catalog on a Microsoft Excel spreadsheet and supplying the CompanyStore administrator with either a fax or an e-mail alias, small suppliers were able to participate on the CompanyStore platform. Technically advanced suppliers were able to take advantage of CompanyStore EDI capabilities.

CompanyStore Provides a Range of Supplier Connectivity Options

Cataloging

Several decision criteria drive the appropriate catalog strategy for a buying organization.

After careful analysis, Visio decided to implement an internal catalog approach. The major factors influencing this decision included the following:

• There were five vendors coming on-line. This meant that headcount resources would not be required to support catalog maintenance.
  
  
• All Vendors had the ability to provide electronic catalogs in a format that could be simply read into the CompanyStore system.
  
  
• The data did not need to be updated frequently; therefore, catalog administration was less of a burden.
  
  
• Visio could control the system more tightly with this approach.

CompanyStore supports a system of internal catalogs “out of the box.” Administration tools provide utilities to import catalog data from a wide variety of sources. Once a catalog has been imported, scheduled incremental updates are automated, keeping each vendor’s catalog up to date. The system has the ability to apply custom business rules to a catalog at the time it is loaded, and then take action if an exception to the rule occurs.

For example, a rule may be “Notify the office supply buyer, if the price of a part increases by more than five percent.” During a catalog update, if a price changes by more than five percent, an e-mail message is generated, and the appropriate party is notified. Rules of this type are written in VBScript, and can be enforced on any field related to the catalog sub-system. This allows significant flexibility in loading parts into the production catalog.

The process of loading a catalog consists of three distinct steps:

1. Mapping data from an input catalog into CompanyStore.
   
   
2. Loading data from the input file into the catalog staging area.   
   
   
3. Publishing the data for the end user to see.

From a catalog management perspective, the first step is the most difficult but it allows CompanyStore the flexibility to import such a wide variety of data.

The mapping process is accomplished through the CompanyStore Catalog Load Wizard. This tool walks the administrator through the process of relating data from an input file into CompanyStore. While this process may take a fairly technical person to accomplish, it need only take place once per catalog. As catalog updates from vendors become available, these new catalogs can be loaded directly into the staging area, without having to re-map any of the fields.

Once an input catalog has been mapped into the database, a system administrator can load the input file directly into the catalog staging area. The staging area is a central location from which new data can be viewed and edited through the CompanyStore Administration tool. Once in this central facility, administrators can make any changes to the data prior to publishing it. The final step occurs when production data is updated. This step can be triggered from within the administration tool, or scheduled to occur during low system loads.

Functional Highlights of Internal Cataloging Approach

• Suppliers provide their catalogs in either a standard (e.g. SPSC) format or a proprietary format (e.g. normalized MDB file).
  
  
• Reusable MAP files are generated via the CompanyStore Load Wizard.
  
  
• The catalog is loaded into a staging area where user-defined rules (VBScript) are applied and exception-based events are fired.
  
  
• New catalogs and/or incremental updates are scheduled and applied.

Data is maintained in-house.

Visio Internal Catalog Approach

Order Placement

Another electronic touch point between Visio’s CompanyStore instance and Visio’s supplier base is order placement and order confirmation. CompanyStore allows for order placement via EDI, e-mail, FAX or Flat File.

CompanyStore Microsoft Site Server 3.0 Commerce Edition Integration

At Concur we are first and foremost business application builders. Where possible we leverage the infrastructure provided by today’s technology leaders. No business application developer today would entertain the thought of building their own RDBMS system and likewise no vendor should consider building a proprietary suite of Internet application integration tools. The integration of Microsoft Site Server Commerce Edition is one example of an area where Concur leverages the expertise of today’s Internet infrastructure builders. Concur developers work closely with the Microsoft product groups to define and enrich future versions of Site Server Commerce Edition and integrating these changes into future releases of the product.

Site Server Commerce Edition

Microsoft Site Server Commerce Edition is a comprehensive Internet commerce server, optimized for Microsoft® Windows NT® operating system with Internet Information Server (IIS), that enables businesses to cost-effectively engage and transact with customers and partners online. Based on strong integration with Windows NT Server, it allows businesses to transact online with secure and scalable order capture, management, and routing while integrating more easily into existing inventory, accounting, and EDI systems.

Using Site Server Commerce Edition has these benefits:

• Engage customers and partners through the creation of cost-effective commerce sites and applications, targeted online advertising and marketing, and personalized promotions.
  
  
• Transact online with secure and scaleable order capture, management, and routing, integrating more easily into existing systems.
  
  
• Analyze to understand customer and partner purchase and usage data, and factor in the changes to maximize the return on investment in your commerce site or application.

Commerce Interchange Pipeline (CIP)

To communicate information to and from suppliers CompanyStore leverages Commerce Interchange Pipeline (CIP) technology included with Microsoft Site Server Commerce Edition.

The Commerce Interchange Pipeline is a system in Microsoft Site Server Commerce Edition that enables application-to-application interchange of structured business data using the Internet or existing EDI systems. It enhances the existing Order Processing Pipeline provided in previous versions of Microsoft Site Server.

Commerce Interchange Pipeline enables applications, typically located in separate enterprises, to  exchange business data in XML or EDI. CIP exposes a set of COM interfaces for applications to use. The CIP is:

• Data format independent—including support for XML and EDI.
  
  
• An XML wrapped COM Binary object.
  
  
• Transport Protocol Independent (SMTP, HTTP, DCOM & EDI VANs with planned future support for the Microsoft Message Queue and FTP).

The Commerce Interchange Pipeline provides a simple system for trading partners (businesses) to communicate business information and to build applications to exchange business data. The Commerce Interchange Pipeline:

• Enables Electronic Document Interchange (EDI) transmissions over the Internet.
  
  
• Provides COM interfaces for custom development and third-party applications.
  
  
• Provides the infrastructure for deploying corporate purchasing, supply chain purchasing, or any business data that needs to be exchanged between two business partners.

What Happens

If a supplier wishes to receive orders from a CompanyStore system to a Commerce Server at their site, CompanyStore will be configured to communicate to the supplier using this mechanism. A transmit pipeline (CompanyStoreTransmit.pcf) is employed by CompanyStore to send all supplier orders from the CompanyStore system. The CompanyStore Integration server invokes the CompanyStoreTransmit.pcf pipeline when orders are ready for shipment to the vendor.

An example of such a process is as follows. An order object is passed into the CIP working_data. This object is mapped into the appropriate message format using the Make PO object. The result is then passed to the SENDSMTP object for transmission to the Vendor.

Sample CIP Transmit Pipeline

If a customer needs increased security they may add components to the ‘Digitally sign’ and ‘Encrypt’ steps of the CompanyStoreTransmit.pcf.

Customers may also plug in their own pipelines based on their specific requirements. In this way organizations may conduct EDI over the Internet, XML document exchange, and other types of business document exchange over the Internet. An example of a CompanyStore system set up to communicate EDI messages over the Internet is shown in the figure below.

CompanyStore using Site Server and CIP

More information on the full capabilities of Microsoft Site Server Commerce Edition is available at http://www.microsoft.com/siteserver/commerce/.

SAP R/3 Integration

A major functional requirement for Visio was connectivity into the SAP R/3 system. Visio had made a huge investment in R/3 and wished to keep these business processes intact.

From a functional perspective, Visio required that certain purchase requisitions flow into the R/3 system instead of directly to the suppliers. These requisitions were converted to POs and then fed back to end-users. Instead of all receipt occurring at the loading dock, Visio required that end users be able to receive data directly  at their desktop. The data flow diagram below shows the major integration points between R/3 and the CompanyStore system required by the Visio implementation.

Data Flow Diagram of Information between CompanyStore and SAP R/3

To support the SAP integration requirements the CStoERP component of CompanyStore integration server architecture was used.

CompanyStore CStoERP/SAP Integration Architecture

CStoERP/SAP is the CompanyStore bi-directional transactional link to the SAP system. CStoERP/SAP uses the SAP BAPI interface. CStoERP/SAP implements this using SAP Automation.

SAP Automation is a set of technologies allowing a system to communicate with R/3 using BAPI COM and DCOM support. This is a certified interface into the SAP system and supported directly by SAP. As SAP BAPI support in certain versions of the R/3 system is incomplete, CStoERP/SAP uses a combination of SAP BAPI and custom calls to undertake some functions. These custom calls are implemented as ABAB/4 remote function calls (RFC).

CStoERP/SAP is a Microsoft®Visual Basic® service that is instantiated from the CompanyStore batch environment.

CStoERP/SAP Sample Code

Function CreateERPRequisition() As Boolean
Dim boRequirement As Object
Dim sReqObjectName As String
Dim oReturn As Object
Dim nNewStatus As Integer
Dim sMessage As String
CreateERPRequisition = False
sReqObjectName = "PurchaseReqItem"
Set boRequirement = oBAPICtrl.GetSAPObject(sReqObjectName)
Set oRequirementItems = oBAPICtrl.DimAs(boRequirement, "CreateFromData", "RequirementItems")
For i = 1 To UBound(Item)
 'RequirementItems
 oRequirementItems.Rows.Add
oRequirementItems.Value(i, "CREATED_BY") = R3_USER
 oRequirementItems.Value(i, "TRACKINGNO") = Order.OrderReferenceID
 oRequirementItems.Value(i, "C_AMT_BAPI") = CCur(Item(i).Cost)
Next
CreateERPRequisition = boRequirement.CreateFromData(RequirementItems:=oRequirementItems)
If CreateERPRequisition Then
sMessage = "Req created: " & CStr(boRequirement.Number)
End If
End Function

All SAPI BAPI components are in the SAP Business Object repository, and can be viewed from within the SAP R/3 system. The screen below shows the Methods available on the Purchase Requisition object within the Business Object repository.

SAP R/3 Business Object Repository – Purchase Requisition Object

Security

Since Visio distributed the purchasing function to the end user community it was important that a robust security structure be put in place. Visio decided to use CompanyStore NTLM integration components to provide secure access to the system. This would also mean that users would not be required to explicitly login to the CompanyStore system; access rights would be granted by way of a users network sign on.

Using NTML-based security had the added advantage that Visio system support staff would not be required to administer the user logins to another application. In order to enable the use of NTLM security customization to the CompanyStore COM, security sub-system were required.

CompanyStore can be customized to require that network credentials be used to log on to CompanyStore. This allows for leverage of other features of network authentication, including imposing rules on CompanyStore passwords. CompanyStore functionality is structured as a set of COM (Component Object Model) objects organized into various subsystems. The Users subsystem includes UserManager and User objects. A UserManager object has various methods related to the management of User objects. In particular, it has a Login method. The Security subsystem includes an Authentication object. It has one method, Verify.

CompanyStore User Login

Concur customizes this behavior by replacing the Authenticate object. A defining characteristic of COM is that a programmer never needs to know how methods are implemented within an object. A new version of Authenticate can be written with a completely different Verify method. As long as the method has the same name and accepts the same arguments, no other component of the system needs to be changed.

With a customized Authenticate object in place, the Authenticate Verify method does not simply compare the logon password to the stored CompanyStore password, but it  submits the logon credentials to Windows for authentication.

Using Windows NT for authentication does raise an important credential issue: CompanyStore requires unique user identifications, but Windows NT does not. In an enterprise with multiple Windows NT domains, there may be duplicate user identifications. In that case, CompanyStore stores sufficient data in each employee record to satisfy both CompanyStore and Windows NT.

For example, a user can log onto CompanyStore using CompanyStore user identification and a network password. The Authenticate object can use the CompanyStore user identification to retrieve that users network identification and his/her network domain, which it then passes, with the network password it receives from the logon dialog, to Windows NT for authentication.

Such customization provided Visio with the level of authentication security needed to meet its business needs.

Scalability

Part of Visio’s ideas for an automated procurement system included evaluating the ability of CompanyStore to scale to large numbers of users and transactions in a network friendly manner. CompanyStore was evaluated on three fronts: Transaction volumes, concurrent usage, and network bandwidth utilization. Below is a discussion of the various factors considered in the performance and scalability planning process.

Transaction Volumes

Procurement “transactions” are quite different from standard accounting transactions. A CompanyStore Web-based transaction is defined as the storage and retrieval of a transaction with an average HTTP response time of less than three seconds per page. For benchmark purposes a procurement transaction is defined as header information and ten entries (line items). In accounting transactional terms this equates to ten separate transactions.

In Concur’s performance lab in Redmond, the following results were observed for the configuration shown below:

Sample Benchmark Results

With optimized hardware and additional Web servers, greater transaction volumes may be achieved within the specified performance standard.

Benchmark Test Configuration

Concurrent Users

The number of concurrent users is the major factor that determines the number of servers required to run CompanyStore.

The number of users on the network is directly related to the number of transactions generated. In actual practice, transactions are not submitted at a constant level throughout the day. Procurement systems typically experience two peak periods of network traffic centered on mid-morning and mid-afternoon. The number of transactions submitted concurrently during these peak periods is the number that affects network requirements.

The peak constant in the following formula reflects experience with customers who have a large number of CompanyStore users. It reliably estimates the peak load in high-usage systems. The annual business hours in the formula are based on 8 hours per day, 5 days per week, 52 weeks per year. This formula is used to estimate the peak hourly concurrent transactions:

(N transactions per year) ÷ (3680 business hours per year) x (280% peak constant)

For example, with 40,000 transactions per year then: 40,000 ÷ 3680 x 2.8 = 53.85

This estimates nearly 55 users simultaneously submitting transactions during the peak hour.

Network Load

The table below summarizes the CompanyStore lab and field experience regarding the data transfer volume.

Average Data Transfer

This data was used to calculate the network bandwidth required by CompanyStore during the peak concurrent usage.

When running CompanyStore on multiple Web servers, it is important to balance the HTTP load across all the servers. This avoids performance degradation due to an overloaded server when other available servers are idle. Concur does not certify or recommend a specific brand of load-balancing software. Products that address load balancing with ASP include 3DNS™ from F5® Labs (www.f5.com), Web Server Director from RND Networks (www.rndnetworks.com), and LocalDirector from Cisco Systems™ (www.cisco.com).

Hardware Sizing

The servers and network connectivity required to optimize CompanyStore performance are directly related to the annual number of transactions.

CompanyStore Sizing Worksheet

Up to 10,000 transactions annually: Use a single server meeting the Database Server specification to run the CompanyStore database, Web, and e-mail services.

10,000 to 40,000 transactions annually: Use two servers. Use a server meeting the Database Server specification to run the CompanyStore database service. Use a server meeting the Web Server specification to run the CompanyStore Web and e-mail services.

More than 40,000 transactions annually: Use multiple servers. Use a server meeting the Database Server specification to run the CompanyStore database service. Use a server meeting the E-mail Server specification to run the CompanyStore e-mail service. Use servers meeting the Web Server specification to run the CompanyStore Web service. One Web Server computer is needed for every 60 peak concurrent users.

Hardware Sizing

For a Web Server, CompanyStore runs optimally on single-processor servers. However, a server able to upgrade to two processors allows for future enhancements to Web server and OS software.

Acceptable Web performance is defined in terms of the end-user experience. Acceptable performance is receiving a page-refresh or other response in less than three seconds on average. We recommend one Web Server for every 60 peak concurrent users based on our field experience and testing—this is the ratio that results in a sub-three-second response.

These network considerations also increase the performance of CompanyStore:

• When using multiple Web Servers (for more than 40,000 transactions annually), use a multi-processor Database Server. Database Servers scale very well with multiple processors.
  
  
• When using separate servers at all (for more than 10,000 transactions per year), use dedicated network connections between the Database Server and the Web Servers. The network connection should have the capacity of 100BaseT Ethernet.

Selected Hardware and Software Environment

Based on the calculations Visio made the decision to run the CompanyStore system on a single high-end dedicated server.

• Dell PowerEdge 2200 Intel Pentium 266 single processor
  
  
• 512 MB random access memory (RAM)
  
  
• 10G hard disk space

Software required for the Visio CompanyStore implementation

Configuration

One of Visio’s major business objectives is to continue to grow the business at a rapid pace. In order to achieve this, new headcount needs to be added to revenue generating departments such as Sales rather than administrative and support departments, such as IT. A major metric used in software selection at Visio is the operational staff required to support a particular system.

CompanyStore was designed as a system that could be configured by business users. A Visual Basic application employing configuration Wizards allows the purchasing department to change business rules, refresh reference data, and monitor system usage—all without the help of IT.

Wizard-based Administration Tools Ease System Administration Tasks

Lessons Learned

DO

• Insist upon executive sponsorship. It is the most important ingredient to a successful project. Business process decisions at the highest level of the company may need to be made and the executive sponsor will be instrumental in getting rapid changes.
  
  
• Listen carefully to the customer. Electronic commerce means many things to many different people and no two environments are identical. A thorough business analysis phase is compulsory.
  
  
• Consider carefully whether to buy or build an application. Many commercially available electronic commerce products exist on the market today and can save a lot of time and dramatically reduce the risks associated with the project.
  
  
• Use a phased implementation approach. Don’t go for the big bang. Pick low hanging fruit, get some wins, and then leverage this success into other areas.
  
  
• Make it easy for employees and suppliers to participate. Without buy-in from these groups, implementation will be an uphill battle.
  
  
• Look closely at integration. Many of the major components of electronic commerce solutions already exist in many companies today. A good electronic commerce solution is not an island but rather a seamless integration of several systems (e-mail/ERP/Network/EDI).
  
  
• Understand the different approaches to cataloging and choose the one that is right for your customer.

DON’T

• Underestimate the importance of usability. An application that is hard to use will be a very lonely one indeed.
  
  
• Use fat Java or Active X controls. They slow down the application, create a negative user impression, and present major installation headaches for IT.
  
  
• Forget about international requirements. With Internet technology the cost of distance is a thing of the past. Consider closely the option of running single, centralized instances rather than several departmental instances.
  
  
• Forget to perform detailed scalability studies and adequate load testing. Employee-facing applications typically have much heavier usage patterns than traditional client/server solutions.
  
  
• Assume that everyone in the organization is using a certain browser version.
  
  
• Do too much customization of packaged application software. This can make upgrades extremely complicated. Some lateral thinking can sometimes avoid many months of custom application development.
  
  
• Don’t forget that what goes in should come out. Many systems are like the ‘Roach Motel’. The data goes in but never comes out. Good reporting and business intelligence tools are essential components of a world class electronic commerce solution.
  
  
• Don't forget to be careful of the use of DHTML in your interface components. Certain DHTML elements are not common across both Netscape and Microsoft browser platforms. Not all DHTML elements work on pre 4.0 browsers.

Conclusions

Early adopters of electronic procurement systems, such as Concur Technologies’ CompanyStore, can obtain substantial cost savings. These cost savings, however, can only be obtained if a system is implemented that:

• Smoothly integrates all relationships between buyers and vendors.
  
  
• Fits the organization’s unique business needs.
  
  
• Can be implemented quickly and cost-effectively.
  
  
• Integrates with other critical business systems.
  
  
• Conforms to industry standards.
  
  
• Scales easily for optimal price-performance and ease of administration.

Most companies moving to Intranet-based technologies are sold on the concept of a powerful and leading edge solution. Most become disappointed. Projects end up costing more and taking much longer to implement than planned. Once implemented, these systems are costly to maintain and costly to modify when new business processes are introduced.

Companies using the Concur Technologies’ CompanyStore Intranet-based product, however, have experienced a high degree of success. Implementations have been cost-effective and timely. Most importantly, users are pleased with the product and the benefits they are deriving from it. Much of this success is due to the architecture that Concur Technologies' CompanyStore employs.

© 1999-2000 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only.

MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, ActiveX, Internet Explorer Logo, Microsoft Press, Visual Basic, Visual InterDev, Visual SourceSafe, Windows, Windows NT and the Windows Logo,  are either registered trademarks of Microsoft Corporation in the United States and/or other countries/regions.

The example companies organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

Other product or company names may be the trademarks of their respective owners.