Since its inception 30 years ago, MasterCard International has grown from a US-based credit card system into a leader in the multi-trillion dollar global payments industry, with credit, debit and chip cards as core competencies. In 1997, 23,000 member financial institutions recorded 6.5 billion transactions worth $602 billion through MasterCard.
This global payments industry leader is rolling out an advanced corporate purchasing solution based on Microsoft® BackOffice® technologies: Clarus™ E-Procurement from Clarus Corporation, a software vendor and Microsoft Certified Solution Provider. The sophisticated system has slashed the average time required to fill a purchase order by 70% and cut the cost of processing purchase orders from $125 to $40, even as it delivers valuable reporting data.
MasterCard's corporate procurement process was paper-based and labor-intensive. Looking to cut costs and improve delivery times, while simultaneously enabling buyers to take a more strategic approach to their jobs, the company decided to automate and streamline its procurement process by bringing it online.
Working with Clarus, MasterCard deployed a cutting-edge, Web-based electronic procurement solution powered by Clarus E-Procurement, Microsoft Internet Explorer, and Microsoft BackOffice technologies. The system gives users easy access to a cross-supplier product catalog over the corporate intranet. When the user makes a selection, the system automatically creates requisitions, routes them for approval, and submits them electronically to the relevant supplier. Used now by 750 people, the solution will be rolled out in a controlled manner to 2,300 users across MasterCard's entire enterprise.
Clarus E-Procurement has empowered MasterCard to slash the average time required to fill a purchase order by 70%—down from four days to one—and to cut the cost of processing purchase orders from $125 to $40—a 68% reduction. And there are bigger savings to come: the company was already saving an estimated $10,000 per month on office supplies, computer hardware, and computer software alone during an early pilot phase with just 250 users. Meanwhile, the system is giving MasterCard valuable reporting data enabling it to get maximum value for every dollar it spends.
To provide MasterCard employees with one, easy-to-use system for ordering non-production, maintenance, repair and operations (MRO) goods and services across all approved suppliers that exceeds employee service expectations while ensuring compliance with contracted suppliers and improving business resource management.
Like most large-scale projects, the implementation of Clarus E-Procurement at MasterCard required a phased approach.
A pilot program to prove the concept and the value of the proposed solution took place over a five-week period from project planning through rollout.
The initial implementation had to be a fully functional, standalone system. Integration with other systems was not desirable during this phase of the project as they were in the process of being re-engineered.
This phase of the project included carefully selected requisitioners, buyers and administrators from both the St. Louis and New York sites. The primary focus of the pilot was on office- and computer-related supplies in addition to promotional goods for marketing events.
Activity | Effort | Timeline |
Project Planning | 1 Day | Week 1 |
Infrastructure Enablement | 3 Weeks | Week 2-4 |
Administrator Training | 2 Days | Week 2 |
Supplier Enablement | 3 Days | Week 3-4 |
Software Installation & System Test | 2 Days | Week 4 |
Database Configuration | 5 Days | Week 4 |
User Training & Rollout | 2 Days of 30-minute training sessions in two locations | Week 4-5 |
Feedback | Ongoing | Week 2+ |
The pilot program continued for several months, first using a small base of users to qualify the product’s ability to perform, then qualifying the product from a user-acceptance standpoint.
The first version of Clarus E-Procurement was rolled out at MasterCard’s New York and St. Louis sites starting in August, 1997. These users comprised the majority of administrative personnel and the entire purchasing department. The narrow scope of purchases was also expanded to include all externally procured goods and services.
Over the ensuing eight-month period, MasterCard conducted user orientation sessions and provided support through its Information Technology and Help Desk groups to smooth the transition of 750 users.
The next phase of the project was subject to the addition of feature enhancements to Clarus E-Procurement. These included the ability to:
Suggestions gathered from user feedback were also added to the product.
All requisite enhancements have been added and the product is currently being rolled-out to all MasterCard employees. This phase of the project is scheduled for completion within the first half of 1999.
Clarus E-Procurement will be integrated with MasterCard’s Enterprise Resource Planning (ERP) application—the installation of which is incomplete at this time—during this phase of the project.
Initial deployment of Clarus E-Procurement involved a full-time project manager from MasterCard, with part-time support from various staff members. The project manager has been responsible for the project from mission through customer feedback.
Every successful project needs a champion, and this was no exception. This individual, an employee in the Purchasing organization, promoted solution adoption internally and mobilized the resources needed to deploy the system and accomplish the vision. This included selling the Information Technology (IT) department on the benefits of using the Microsoft technology platform as the infrastructure upon which to deploy the solution.
Additional support was required from key people in the IT, Purchasing, and Finance organizations.
The production rollout required approximately three full-time people over an eight-week period to manage the project and provide connectivity for 750 users.
Support for Clarus E-Procurement beyond production rollout, including Catalog Management, Business Rules Management and User Profile Management, currently requires one half-time employee.
The person responsible for managing the entire system at MasterCard is a Purchasing employee. It’s important to note that this individual is not required to have system programming experience.
The IT department’s involvement has been limited to acceptance of the environment, installation of the hardware and network architecture, and support for the server and desktop environment. No database administrator (DBA) has been involved except to validate the system architecture. This has allowed the IT department to focus on other issues within the organization.
Organizational change and end-user acceptance are typically the primary factors influencing new system deployment and success. However, unlike replacing an ERP system, implementing Clarus E-Procurement involves an entirely new breed of application. It was the first Web-based application at MasterCard, as it has been at many other Fortune 2000 companies.
Mostly casual users, rather than functional users, access this application at MasterCard. Therefore, end-user interaction and acceptance had to be handled differently than rollout of a replacement for an existing functional user application.
With this type of application, acceptance of process change is addressed by creating or modifying for end-users and purchasing professionals, and by communicating and monitoring compliance with those procedures. Additionally, IT requirements are identified and responsibilities assigned.
While this application provides significant benefits to the organization through process change and management information, it requires compliance by end-users to achieve results. Too many changes at once would thwart the effort and reduce the likelihood of success.
The first step toward change is to provide end-users with access to the application. Rollout occurs in a controlled fashion while winning acceptance from key users. User-evangelists are very important to the success of a voluntary-use application. In addition, incentives to use the application must be in place, because individuals are not specifically measured on its use, as they would be with a functional use application.
As Clarus E-Procurement can be modified at any time without programming, no immediate changes to MasterCard’s business rules and procedures were required. As a result, purchasing procedures were left unchanged for the first phase to allow validation of the system, ensure compliance, and reduce end-user hesitancy. Therefore, the only change a user had to endure was to use a new automated system instead of an old, manual, paper-based process. As might be imagined, this was a very welcome improvement.
With information never before available to the Purchasing organization, business rules and procedures can be modified and processes changed at any time as a positive result of the system. This change is a welcome one for those using the old system.
The greatest change resulting from MasterCard’s implementation of Clarus E-Procurement is to the purchasing professional. Though hired as valuable knowledge workers, these individuals have been burdened with extensive paperwork; routinely performing tedious data entry tasks, fulfilling end-users’ information and status requests, handling complaints and manually expediting and following up on orders with suppliers.
Purchasing professionals now can work at a higher, more strategic level—fulfilling the requirement for which they were originally hired. They no longer have to manually enter paper requests into a purchasing system. This task is now performed at the frontline—by the end-user. Nor must they field questions about order status from requisitioners. The system proactively provides this information to the end-user via e-mail. This information is also available to the end-user through the Web-based application.
Purchasing professionals now use the system to obtain information that was unavailable with the old, manual, paper-based systems. Armed with this knowledge, they can better anticipate supplier opportunities and negotiate contracts that are more favorable for MasterCard. They can also provide management with much better and more timely information about the purchasing habits of the entire organization.
Because Clarus E-Procurement uses Microsoft SQL Server™, database administration is minimal and access to information is secure, yet readily available through Clarus E-Procurement’s standard reports, as well as a range of widely available, third-party tools. MasterCard uses Microsoft Access as a reporting tool. With it, purchasing professionals gain insights into the purchasing habits of the organization and Accounts Payable ensures the timeliness of vendor payments.
Clarus E-Procurement frees IT Professionals from the burden of system administration. This is a significant and welcome change.
Often, systems are ruled out due to the burden they place on the IT organization. Clarus E-Procurement follows Microsoft’s “Zero Administration” philosophy by ensuring that the application only depends on its knowledge experts for maintenance. This reduces the burden on the IT organization to manage an application for which they are not experts.
IT has enjoyed benefits from the new system, too. Because MasterCard uses Microsoft Windows NT® Workstation as the standard desktop operating system, the best time to authorize an individual’s use of an application is during initial system configuration. Therefore, the IT department now sets up the user and Microsoft Internet Explorer on the desktop every time a new machine is received. Desktop components used by the application and the user profile are verified upon installation.
Clarus developed a utility that enables administrators to push E-Procurement’s components to the desktop for rapid installation on existing machines.
MasterCard had a number of specific objectives they wanted to accomplish. Before any electronic procurement system would be accepted, it had to:
Be capable of supporting transactions generated by every employee in the organization.
Lower the number of incomplete or incorrect orders that suppliers receive while simultaneously increasing overall order volume by reducing unauthorized buying.
Offer a “user-compelling” experience—so users prefer it to the old, manual paper-based systems. As a result, users will not subvert it by engaging in “maverick” buying practices. And it must do all this without placing an undue burden on the IT organization.
Support seamless integration with an impending ERP implementation as well as existing back-end systems.
Through these objectives, MasterCard’s Purchasing Department made “Customer Delight” their number one priority.
A key requirement in MasterCard’s electronic procurement strategy was to obtain a cost-effective, scalable architecture to meet its enterprise needs. By selecting Clarus E-Procurement, MasterCard made the strategic decision to closely align themselves with Microsoft’s electronic commerce strategy. All Clarus products are created exclusively with native Microsoft technologies. As such, MasterCard’s chosen solution is well suited to take advantage of the rapid advancements being made in Web-based technologies.
The MasterCard implementation plan called for the electronic procurement application to be deployed initially within a small pilot group, with incremental rollout to the entire user community.
When this type of application is implemented across an entire enterprise, user concurrency from 3% to 5% is expected. That is, between 3% and 5% of potential users are expected to access the system at any one time. Currently 750 users, mostly administrative personnel and purchasing professionals, have access to and actively use the system. Given their functional responsibilities, concurrency is significantly higher than 5%. In fact, these users generate about 60% of the total forecasted transaction volume for the enterprise.
The current system runs on a dual processor Pentium 300 server hosting the Microsoft SQL Server 6.5 database, Microsoft Internet Information Server 4.0 and Clarus Enterprise Application Server. As MasterCard’s user base and transaction volume increase, the Clarus n-tier architecture will allow the application components to be distributed across multiple servers, thus providing much higher capacity. Based upon current benchmarks, the Clarus solution is expected to effectively scale to support a user base many times greater than MasterCard’s future requirement.
One of MasterCard’s basic requirements for any electronic procurement solution was (past tense is used when referring to their other requirements… we should keep this consistent) an online, integrated product catalog. Their assumption was that errors created by the old, manual, paper-based processes would be dramatically reduced, and quite possibly eliminated with such a system.
MasterCard’s requirements for catalog access, creation and management were:
In order to satisfy these diverse requirements, Clarus E-Procurement supports a comprehensive, hybrid approach to catalog access, creation and management.
To allow access to product information without going to the Internet, the cross-supplier catalog is situated on MasterCard’s trusted intranet, protected by a firewall. This permits quick, secure access to the information required for decision making.
Finding the right product is very easy. Users can search by partial or complete part numbers, keywords, suppliers or manufacturers. Additionally, any of these keys can be combined to refine the search.
MasterCard’s suppliers do not wish to invest in non-standard solutions. Tier One suppliers want to leverage existing investments in their Web sites, while Tier Two and Tier Three suppliers want to support existing solutions without investing in proprietary technology.
For these reasons, Clarus E-Procurement supports suppliers of varying levels of technical sophistication and offers multiple methods of cross-supplier catalog population:
Basic data entry, directly into the application.
Cross-supplier catalog content in various electronic forms—including CD-ROM, Microsoft Excel, and standard ASCII file formats such as Catalog Interchange Format (CIF).
In early 1999, Clarus E-Procurement is integrating CenterStage from OnDisplay for dynamic catalog content management, thus eliminating any manual or scheduled batch update processes.
A single administrator maintains the catalog through the Clarus Catalog Manager. The application’s graphical user interface (GUI), built with Microsoft Visual Basic®, allows for single item entry and update, as well as catalog updates, with the ability to determine what type of update is performed.
This combination of technologies eases the burden of catalog management on MasterCard while eliminating the need for suppliers to invest in new technology in order to do business with the company—although they can realize significant benefits by doing so.
MasterCard required that the electronic procurement system be maintainable by one, functionally-oriented individual, rather than many IT professionals. They did not want to focus precious IT resources on an application that was not mission critical—even though the ROI more than justified its implementation.
Clarus E-Procurement includes a full suite of tools that address this requirement. Together, the Clarus Enterprise Manager (CEM) and the Clarus Catalog Manager (CCM) permit non-IT professionals to effectively administer, configure, monitor and maintain the system.
Through its GUI, created with Microsoft Visual Basic, an administrator uses CEM to:
CCM creates and maintains cross-supplier catalogs. It provides the functionality to enhance catalog data, so that casual end-users can quickly and easily find the correct products or services. CCM includes import utilities, which facilitate catalog updates from a simple modification, such as a price change on a single product from one supplier, to a full catalog refresh. A rollback feature allows administrators to undo improperly applied changes to the catalog.
While the version of Clarus E-Procurement used during the pilot program had an efficient and functionally rich user interface, end-user feedback led to an improved second-generation product now being implemented at MasterCard. This includes a new user interface that is at once more aesthetically pleasing and more intuitive. Now, instructors spend more time teaching users about process change and less on the product itself. Training sessions last an hour, including a question and answer period, for 20 to 25 people.
In addition to these usability goals, MasterCard wanted to achieve a specific objective: The ability for a casual end-user to create and submit a purchase requisition within 30 seconds. To accomplish this goal, the product offers an event-driven procurement model.
In this model, administrators and end-users can create requisition templates that include all products and services that are appropriate for a given event—new employee hire, etc. Within Clarus E-Procurement, these requisition templates are referred to as hot lists. These can be either public or private. As the names imply, public hot lists are accessible by all users, while private hot lists are just that, accessible by only the creator.
When end-users create requisitions, they use an electronic shopping basket. Another type of requisition template, a stored basket, complete with item quantity, account code distributions and other information, can also be created here. This is done most frequently for routine orders—a bimonthly office supply order, for example. Like hot lists, stored baskets can be either public or private.
Whether hot lists or stored baskets are employed, the majority of MRO purchases are driven by an event, and the use of these templates allows the system to meet MasterCard’s requirement for lightning fast requisition creation and submission.
The E-Procurement client includes common user reports, which requisitioners use to report and track their own expenditures. However, MasterCard’s Purchasing Department generates additional, more complex reports using Microsoft Access and an ODBC connection to the E-Procurement Microsoft SQL Server database. Using various criteria, such as number and dollar total of transactions, by supplier, per month, MasterCard’s Purchasing Department can report and analyze:
Since most common errors relate to the configuration of Clarus E-Procurement, an E-Procurement administrator resolves 99% of troubleshooting issues. Occasionally additional help is required from IT staff or Clarus Customer Service.
If the issue is related to:
Users call the appropriate MasterCard buyer for the commodity/supplier.
For problems with catalog data, the E-Procurement administrator contacts the appropriate supplier(s). For all other issues, they call Clarus Customer Service.
The E-Procurement administrator contacts MasterCard’s IT Department contact for problems with Windows NT Server, Internet Information Server, SQL Server, E-mail, etc. They call Clarus Customer Service application-level issues.
The E-Procurement server generates messages during the workflow process. Key messages indicating status of the workflow are displayed on the server monitor screen. Error messages are also sent via e-mail to internal designees such as the E-Procurement Administrator and IT Administrator. Optionally, these contacts can also be paged.
Automated and routine virus scanning and database backups comprise the bulk of maintenance for the E-Procurement server. Occasional file purges help maintain adequate disk space. Also, the IT administrator routinely checks the server with remote monitoring and administration utilities.
Manual backups complement the automated routines. These are performed before any significant operation is executed, such as importing major catalogs and updating data sets with scripts.
A test server stages the new product upgrades. Future plans include using the test server to prototype and stage changes on same-version product, including enterprise configuration changes, users, suppliers, and routing rules.
Like most Fortune 2000 companies, MasterCard has multiple back-end systems from several vendors. In addition to various internally-developed legacy systems, MasterCard is currently in the process of implementing a commercial ERP system.
MasterCard requires that the electronic procurement solution have the ability to seamlessly integrate with its heterogeneous back-end environment. Moreover, they require that the system provide a level of abstraction and isolation from the back-end systems. That way, the electronic procurement system can continue to function without modification as back-office applications are upgraded.
Clarus E-Procurement satisfies this requirement through a message-based integration strategy that leverages Microsoft Transaction Server (MTS) and Microsoft Message Queue Server (MSMQ). This loosely coupled approach enables MasterCard to affect integration with multiple, heterogeneous back-office systems in near real-time in an extremely cost-effective manner.
MasterCard’s original procurement environment was a combination of Microsoft Access databases and Lotus Notes. The system provided electronic forms-type messages for certain types of purchases, coupled with some basic workflow routing. MasterCard required an integrated solution that included:
And, of course, it all had to work within their existing technical environment.
To accomplish this, the solution was developed using a Microsoft-centric architecture. This was done for several reasons, including Microsoft’s commerce strategy and the development of an industry-leading vision of supplier integration. Microsoft Site Server Commerce Edition with the Commerce Interchange Pipeline (CIP) is key to delivering on this vision today and in the future.
MasterCard sought a partner that would allow it to implement a solution immediately while keeping abreast of industry and technology trends. Implementing support for CIP made possible an integrated and secure communications session between MasterCard and its suppliers. As more of MasterCard’s suppliers take advantage of CIP, they will be able to create near real-time communications sessions over which to transact business—with both parties realizing many benefits in the process.
A key driver of this architecture is the need to satisfy the functional requirements and technology issues—not only for the internal procurement process, but for supplier and back-office integration as well. Since the requirements and technologies differ significantly between these three domains, each is addressed in turn.
Figure 1 illustrates the logical architecture of Clarus E-Procurement as used at MasterCard.
Figure 1: Clarus E-Procurement Logical Architecture At MasterCard
All the MasterCard transaction, profile and catalog index data are maintained in one Microsoft SQL Server database. The schema contains tables for entities such as user, supplier, catalog item, routing rule, order, and report. Purchase order attachments and rich content information (pictures, etc.) are stored in a specified file structure outside the SQL Server database.
MasterCard administrators use two client applications to configure the system:
All end-users interact with the procurement system through Web browsers. Virtually all MasterCard users are on Microsoft Internet Explorer 4.0x. As a result, these users view ActiveX® components served through Active Server Pages. Users with older, or non-Microsoft, browsers view the HTML 3.0 version of the application. Since Clarus E-Procurement takes advantage of the performance and component characteristics of ActiveX, users with Microsoft Internet Explorer 4.0x enjoy a much richer experience.
MasterCard chose to access Clarus E-Procurement via its existing Lotus Notes desktop. Once requested, Clarus E-Procurement:
The organization of ASP’s in the Clarus E-Procurement Application Server mirrors the end-user interface. Figure 2 offers a high-level view of this organization.
Figure 2: High-Level Active Server Pages Organization
All users enter Clarus E-Procurement through Default.asp. This page prompts for user name and password, then starts the session. After querying the database for user information, it sets session variables, and determines the user’s browser type and version. Main.asp is opened as appropriate to the browser type and version (ActiveX or HTML).
Main.asp creates a frameset at the highest level of the browser interface, and houses scripts used throughout the application. The user can set the look of the frames.
Five tabs are always displayed: Catalog, Shopping Basket, Orders, Reports and Preferences. Each represents an ASP or group of pages. When a tab is selected, the functionality available on any given page depends on the user’s authorized role.
When the user submits a requisition, Clarus E-Procurement Workflow routes it to the appropriate approver(s) via e-mail. Once all approvals are received, purchase order(s) are transmitted. Available transmission methods include hardcopy, e-mail, fax, output of an EDI-friendly text file, or Commerce Interchange Pipeline (CIP). Processing intervals for Workfloware configured through Clarus Enterprise Manager.
Components for the application, workflow and database may be deployed on the same or physically separate servers. This provides for scalability, as well as for logical partitioning based on the enterprise’s business requirements. MasterCard currently runs all three components on the same physical server.
Clarus E-Procurement uses the Microsoft Windows NT and SQL Server security models for user access. Users must provide an ID and password to gain access to the network and the application. IIS and SQL Server manage data security.
E-Procurement user profiles indicate functional, access-level authorization. Users may be authorized as a:
MasterCard requires that Clarus E-Procurement support as many as 3,000 users with a 3% to 5% concurrent usage load. About 25% of the organization currently uses the system, with concurrent usage at about 60%.
In February 1998 Clarus performed load simulations using Rational LoadTest 6.1. Testing variables were manipulated to ensure a “lowest common denominator” environment. Specifically:
The test consisted of one “GUI user”, a real user for whom system responsiveness was measured, and a number of “virtual users.” The simulation software only allowed the GUI user to interact with ActiveX controls. The additional virtual users provided an easy means to simulate load with minimal hardware.
The GUI user repetitively performed the following tasks:
The GUI user averaged 45 seconds to complete each cycle in no-load environment.
Virtual users also repetitively performed a sequence of tasks. However, because virtual users could not interact with ActiveX controls, they performed the following tasks:
The GUI user averaged 120 seconds to complete each cycle when the system was stressed under load.
In general, these tests verified acceptable performance at anticipated load levels.
To build the optimal solution that affords MasterCard the opportunity to obtain a rapid return on investment, while maintaining upgrade flexibility, the application uses the following technologies:
Dynamic Web pages, employing ASP, HTML, JavaScript, and VBScript
MasterCard requires end-users, as well as, management reporting. Clarus bundles Seagate Crystal Reports 6.0 with Clarus E-Procurement and includes numerous standard report templates for this purpose. With this technology, reports transmit to the browser, where the Crystal Reports viewer component allows users to search and sort the results.
The following tables list the system configuration for Clarus E-Procurement 3.0 as installed at MasterCard International.
Application Server | |
Operating System | Microsoft Windows NT Server 4.0 (SP3) |
Internet Server | Microsoft Internet Information Server 4.0 with Microsoft FrontPage® Extensions |
Microsoft Remote Data Services 1.51 | |
Reporting | Seagate Crystal Reports 6.0 (runtime version)1 |
Network Protocol | TCP/IP |
E-Mail Client | Lotus Notes 4.6 |
Hardware | HP Kayak 3000 Dual Pentium II 300 MHz Processor 128 MB RAM 4 GB Hard Drive |
Database | Microsoft SQL Server 6.5 (SP4) |
Database Connectivity | Microsoft ODBC Administrator 3.51 |
End-User Workstation | |
Operating System | Microsoft Windows NT Workstation 4.0 |
Web Browser | Microsoft Internet Explorer 4.0x |
Network Protocol | TCP/IP |
E-Mail Client | Lotus Notes 4.6 |
Hardware | Pentium 133 MHz or better processor 32 MB RAM 800 x 600, 256-Color SVGA Video Adapter and Display |
Administrator Workstation | |
Operating System | Windows® 95/98 and Windows NT |
Reporting | Crystal Reports 6.0 |
Database Connectivity | Microsoft ODBC Administrator 3.5 |
Network Protocol | TCP/IP |
Hardware | Pentium 133 MHz or better processor 64 MB RAM 800 x 600, 256-Color SVGA Video Adapter and Display |
System Administrator Responsibilities | |
Windows NT Server Administrator | Prepare and install Clarus E-Procurement server software |
Web Master | Web configuration and maintenance |
Database Administrator | Performance Tuning SQL Server Monitoring Backups |
1 Denotes third party license provided with Clarus E-Procurement.
For MasterCard, and most other Fortune 2000 companies, supplier integration is a key component of an electronic procurement solution. Clarus addresses supplier integration through both catalog and transactional data. In addition, MasterCard requires that Clarus E-Procurement be able to work with any supplier to minimize the cost of business transactions between the buying organization and its suppliers. Since the number and variety of potential MasterCard suppliers is vast, E-Procurement must offer flexible, low-cost solutions for online transactions and catalog management.
The system components associated with delivering supplier integration to MasterCard are illustrated in Figure 3.
Figure 3: Supplier Integration Components
Clarus E-Procurement Workflow is responsible for transmitting purchase orders to suppliers. The available transmission methods are hardcopy, e-mail, fax, EDI, and Microsoft Commerce Interchange Pipeline (CIP). Of these, only EDI and CIP offer application-to-application transaction automation.
Historically, EDI provided the only option for application-to-application integration of business transactions. However, EDI is expensive and labor intensive. To use EDI, both MasterCard and its suppliers would be required to implement translators and establish relationships with Value Added Network providers. Although MasterCard and some of its suppliers are moving in this direction, it is not the most cost-effective or efficient solution for either party given today’s Internet technologies. Microsoft Site Server Commerce Edition with CIP provides the first commerce framework that shows significant promise to reduce the reliance on EDI for automated transactions over the Internet.
Clarus Catalog Manager (CCM) is used by MasterCard’s administrator to create and update catalogs. It uses a fixed-format text file to update the catalog table in the E-Procurement database. To convert the different file formats provided by suppliers into a fixed-format text file usable by CCM, Clarus E-Procurement supports CenterStage from OnDisplay.
As mentioned earlier, MasterCard supports multiple purchase order delivery mechanisms for its suppliers. Hardcopy, fax, e-mail, EDI and CIP are all utilized. The TransmitVia component in the application directs transactions to the correct delivery format as outlined below:
CIP manages the transport and data format details and is easily configured using Microsoft’s graphical Pipeline Editor.
TransmitViaCIP allows administrators to define the data source, fields, field names, and field hierarchical organization. This minimizes transaction costs, because a different purchase order document structure may be defined for each supplier for repeated use.
Figure 4 illustrates one scenario in which applications at separate trading partners exchange data via CIP. In this scenario, Clarus E-Procurement Workflow transmits a purchase order to Supplier A.
Figure 4. Data Exchange Via CIP
Step 1: Workflow’s transmit step creates a Microsoft Commerce Dictionary object, and populates it with purchase order data. The transmit step then invokes the transmit pipeline configuration file for Supplier A (SupplierATrans.pcf) and passes it the populated dictionary object
Step 2: The transmit pipeline configuration file knows what data format, encryption method, and transport protocol to use. It formats the data in XML, encrypts it, and performs an HTTP Post to the EPReceive.asp at Supplier A’s Web site.
Step 3: The receiving ASP creates a Microsoft Commerce Dictionary object invokes the receive pipeline configuration file (EPReceive.pcf), passing it the dictionary object and the incoming data.
Step 4: The receive pipeline configuration file knows what encryption method and data formats were applied to the incoming data. The receive pipeline receives the incoming data, decrypts it, parses the XML, populates the dictionary object with the data and passes the dictionary object back to the ASP script.
Step 5: The ASP script navigates and processes the populated dictionary object as appropriate. In Figure 4, the ASP script updates the supplier’s database.
Figure 5 shows the creation of a transmit pipeline configuration file in Microsoft’s Pipeline Editor. The pipeline consists of a sequence of stages (Map, Add Header, Digitally Sign, Encrypt, Audit and Transport), for which a choice of components are provided. A simple right-mouse click adds a component at any stage.
Figure 5: CIP Editor
Fundamentally, CIP serves to reduce the size and complexity of the application’s architecture by abstracting data transport processing. Note how CIP simplifies the requirements of dealing with multiple suppliers. In Figure 4, if the purchase order is sent to Supplier B instead of Supplier A, Workflow’s transmit step merely invokes SupplierBTrans.pcf instead of SupplierATrans.pcf. The Workflow application knows nothing about the data format, encryption and transport methods employed in either case.
Clarus TransmitViaCIP allows the administrator to define document structure, data source, included fields, field names, and hierarchical field organization. In addition, Clarus E-Procurement provides for file attachments to be transmitted along with the document.
The administrator defines a new document structure, or “schema”, by making entries in database tables. A schema consists of a hierarchical organization of “document objects”, each of which represents a logically related group of data items. For example, document objects in a purchase order schema typically include:
Data required for each document object include:
In addition, “friendly” field names can be specified so that the name transmitted for any given field can differ object schemas.
Three data types are used for document objects:
Because a Dictionary can contain Dictionaries and SimpleLists, and a SimpleList can contain Dictionaries and SimpleLists, it is straightforward to represent arbitrary hierarchical data using them.
The interface to TransmitViaCIP is:
Public Function Process(vDataSource As Variant, _
vDataKey As Variant, _
vCIPSchemaID As Variant, _
vPipelineConfig As Variant) As Boolean
The Boolean return value indicates success or failure of the transmit operation. The parameter meanings are as follows:
The administrator previously used Clarus Enterprise Manager to specify that purchase orders for Supplier A should be transmitted via CIP, and identified the schema ID as well as the transmit pipeline configuration file.
When the transmit step encounters a purchase order for Supplier A, TransmitViaCIP is invoked and the data source, purchase order number, schema ID, and the name of the transmit pipeline configuration file are passed to it. TransmitViaCIP then performs the following tasks:
Clarus E-Procurement imposes no “requirements” on suppliers. However, in order to realize the benefits available by using CIP, suppliers must implement Microsoft Site Server Commerce Edition. Additionally, CIP and the TransmitViaCIP object included free of charge with Clarus E-Procurement must be configured and enabled.
The default installation of Clarus TransmitViaCIP assumes that HTTP Post is employed as the transmit method in the pipeline configuration file. It further assumes that the supplier is running Microsoft Internet Information Server so that received documents can be navigated and processed with ASP scripts that are provided in near-complete form by Clarus.
In this scenario the supplier requires the following components:
Another critical consideration for MasterCard is the ability to support a diverse set of Catalog Management requirements. MasterCard successfully automated its content management process by working with key suppliers to support both direct data entry by administrators and batch file updates. The Clarus Catalog Manager provides an easy-to-use interface to support the content management requirements for an unlimited number of suppliers.
The next version of Clarus E-Procurement supports CenterStage ECat from OnDisplay for automated, proactive catalog content management.
CenterStage ECat was chosen for its ability to easily create and maintain buy-side, cross-supplier catalogs. Its features include:
To initially populate the Clarus E-Procurement cross-supplier catalog, the administrator uses CenterStage ECat to perform an “initializing navigation” of electronic catalogs provided by suppliers. During this process, procurement-relevant fields are identified for a single item in each catalog. This establishes the patterns of data. CenterStage ECat then automatically navigates supplier catalog(s) to initially populate, and subsequently update, Clarus E-Procurement’s cross-supplier catalog. This process is the same for all supported data sources.
Since Clarus Catalog Manager can run in command-line mode using pre-defined catalog update profiles, MasterCard can schedule CenterStage ECat and Clarus Catalog Manager to update catalogs automatically.
Clarus E-Procurement must integrate with a variety of back-end systems at MasterCard. This requirement, which is common to all Clarus E-Procurement customers, led to three architectural design principles:
The Clarus E-Procurement Messaging component that handles both incoming and outgoing messages to affect back-end systems integration is shown in Figure 6.
Figure 6: Back-end Systems Integration Components
The Messaging component creates outgoing messages for any event within Clarus E-Procurement that needs to be communicated outside of the application. Likewise, the Messaging component receives and manages the processing of incoming messages, which are generated by other applications and represent events that need to be communicated to Clarus E-Procurement.
As an example of an outgoing message, Clarus E-Procurement notifies back-end systems whenever Workflow transmits purchase orders to suppliers. This enables, among other things, a purchasing control application to prepare for subsequent invoice matching and payment processing.
As an example of an incoming message, Clarus E-Procurement updates its table of Supplier data in response to messages sent by other applications. This enables an administrator to manage Supplier data in a single back-end system and the data are automatically synchronized in the Clarus E-Procurement database.
The Clarus Publish-and-Subscribe component is a hub through which all messages flow. It enables applications to tap into this flow and retrieve only relevant messages. For example, a purchasing control back-end application “subscribes” to receive information on all purchase orders. Subsequently, the Publish-and-Subscribe component sends a copy of all purchase order messages to the purchasing control application.
The Clarus E-Procurement Messaging component is deployable on the same or physically separate servers as the Application, Messaging, Publish-and-Subscribe, Workflow and database servers. All of these components, as well as the administrator applications, must reside on the same intranet. Future implementations of the Publish-and-Subscribe component will allow applications to connect via the Internet, so that the servers can physically reside anywhere in the world.
In order to avoid an explosion of translations between the business objects at each back-end system, it is highly desirable to have a standardized message set for the exchange of business data between applications. To this end, the Clarus E-Procurement Messaging component employs an OAGIS-compliant message set, with the messages formatted as XML.
The Open Applications Group is a nonprofit consortium of enterprise application software developers. The organization was formed to create common standards for the integration of enterprise business applications. OAG members include: J. D. Edwards, Oracle, PeopleSoft and SAP.
The Open Applications Group Integration Specification (OAGIS) provides a standard set of messages for the exchange of structured business data.
Extensible Markup Language (XML) is a structured data format. XML provides a simple and powerful way of representing arbitrary hierarchical data. The emergence of a standard API for processing XML documents—the Document Object Model, or DOM—and the availability of generic tools for processing XML-formatted documents both convey significant architectural advantages to using XML.
Use of OAGIS and XML together confers a powerful advantage beyond minimizing translations between applications. Use of XML means that message data is highly accessible, and use of OAGIS means that both the business process context of messages and the meaning of data within them are known. As a result, the Publish-and-Subscribe component can discriminate between messages flowing through it with great sophistication. It will also be able to relate messages to business processes occurring within the individual interoperating applications. This is where future inter-application workflow will be implemented.
The movement of messages into and out of the Messaging component is through accomplished by using queuing technology—specifically Microsoft Message Queue Server (MSMQ). Beyond MSMQ, Clarus Fusion provides a powerful range of capabilities for enterprise application integration in messaging environments, with sophisticated XML capabilities.
Message queuing enables loose coupling of applications while guaranteeing the delivery of messages. Rather than procedure calls, with APIs that differ vastly between applications, communication is achieved by through the exchange of messages using agreed upon formats and transports.
The queuing system guarantees messages delivery, even if receiving applications are unavailable at the time messages are generated and sent. Sending applications do not have to wait for responses from receiving applications before continuing processing.
Clarus Fusion handles the interface between Clarus E-Procurement’s internal business objects and the message queue. For incoming messages, Fusion monitors the queue, picks up arriving OAGIS/XML messages and parses the XML. Based on the content of the parsed XML, a script determines the type of OAGIS message and invokes a corresponding workflow. The workflow, in turn, transforms the OAGIS data into the form required by Clarus E-Procurement’s business objects and passes it to the business objects. Since both Clarus Fusion and E-Procurement objects are designed to work with Microsoft Transaction Services (MTS), processing of entire message are handled as a single transaction. The process is similar for outgoing messages.
Because Clarus Fusion provides such a broad range of capabilities, the internal E-Procurement business objects remain optimized for procurement functionality. The E-Procurement business objects do not have to account for details of the external message set (OAGIS) and formats (XML). Instead, all such adaptation is handled by script and configuration files within Fusion.
Figure 7 shows the logical architecture of the Clarus E-Procurement Messaging component. A single representative configuration, relative to other components is shown. Other configurations are possible.
Figure 7: Messaging Component
The Clarus E-Procurement Messaging component interacts with the Publish-and-Subscribe component through the “Incoming” and “Outgoing” queues. These queues are monitored by the Publish-and-Subscribe component and the messages traversing them are OAGIS/XML messages.
Any component of Clarus E-Procurement (i.e. an ASP, Clarus Enterprise Manager, Clarus Catalog Manger, Workflow, etc.) can initiate the creation of an outgoing message by placing a “request” in the Message Requester Queue (MRQ). The request contains the data necessary to initiate the creation of the correct message.
The format of the request is simple XML:
<REQUEST DocType="…" DocKey="…" DataSource="…" … />
Where DocType, DocKey, and DataSource specify the type of document to create, the relevant key value and which database to use, respectively.
In addition, messages are encrypted before they are sent.
The Messaging component employs Clarus Fusion to monitor queues, transfer messages, manage the sequence of processing steps, assemble and handle hierarchical data internally, and translate between internal data formats and OAGIS/XML.
Many OAGIS documents can be handled as hierarchical structures that are built up from simpler business objects, and the message processor orchestrates the operation of individual business objects as necessary to create or process an entire OAGIS document.
The Message Processor may generate a message requests via the Message Requester. This could be the result of business rules associated with normal validation and processing of inbound messages. That is, one business event may trigger another.
Many technical and operational lessons were learned throughout the process of implementing Clarus E-Procurement at MasterCard. The technical lessons are rapidly being addressed in upcoming versions of the product to which MasterCard contributes significant input.
Clarus adopted a Microsoft-centric technical approach early on, while its competitors focused on Java. Microsoft technologies have enabled Clarus E-Procurement to provide a rapid return on investment to MasterCard, and provide value to both MasterCard and its suppliers through the flexibility allowed by the Microsoft platform and support of CIP.
It is essential to create a positive aura around any new application, and MasterCard did an outstanding job of making Clarus E-Procurement available for potential end-users to both see and hear about its value to individuals and the company.
MasterCard implemented Clarus E-Procurement as a completely stand-alone system. This has given MasterCard time to gather data about user habits and processes prior to any business process re-engineering efforts, such as the ERP system implementation scheduled for later in 1999.
MasterCard and Clarus have both been sensitive to the nature of supplier relationships and have found that approaches to catalog management and supplier integration vary greatly from vendor to vendor. Clarus’ approach to catalog management has been a proven success with both MasterCard and its key suppliers.
Although Clarus E-Procurement can be rolled out to a large number of users at once, deployments should be planned in phases within an appropriate time frame. Training is required for end-users, but even more importantly, individuals need time to adapt to the change in process. This is an application that will change the way people do business, and therefore will have more of a social—rather than technical—impact on the individual.
MasterCard’s installation of Clarus E-Procurement was the first implementation of a commercially available Web-based procurement application in the market. The Microsoft infrastructure was critical to the success of the implementation in terms of reliability, scalability and cost of implementation.
Since the initial implementation in June 1997, the system has never failed and has experienced zero downtime—even through three product upgrades. Clarus E-Procurement requires less than half of one person’s time to maintain and administer, and requires the lowest total cost of ownership for any competing solution in the customer segment.
Finally, the availability of Microsoft Site Server Commerce Edition and the Commerce Interchange Pipeline provides Clarus the opportunity to create, and MasterCard to implement, the most compelling electronic procurement solution in the industry. Without the Microsoft technology available in the customer segment, this would not be possible.
Founded in 1991, Atlanta-based Clarus Corporation, (NASDAQ:CLRS), is a leading provider of Web-based applications for managing operational resources together with Financial and Human Resource applications for mid- to large-sized companies. These applications create high lifetime value by delivering sophisticated functionality while substantially reducing the time required for implementation, maintenance and upgrades.
Clarus Corporation
3970 Johns Creek Court
Suwanee, GA 30024
Tel.: 770-291-3900
Fax: 770-291-3999
Web site: HTTP://WWW.CLARUSCORP.COM
The information contained in this document represents the current view of Clarus Corporation on the issues discussed as of the date of publication. Because Clarus must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Clarus, and Clarus cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. CLARUS MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
© 1999-2000 Microsoft Corporation. All rights reserved.
E-Procurement and Business Resource Management are either registered trademarks or trademarks of Clarus Corporation in the United States and/or other countries.
Microsoft, BackOffice, ActiveX, Visual Basic, FrontPage, JScript, Visual FoxPro, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries/regions.
Other product and company names mentioned herein may be the trademarks of their respective owners.
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.