EPILOG is the "Electronic Procurement and Information System for Logistics - Global". BASF opted for the Internet technology to streamline their negotiation and procurement of long-term freight shipping agreements. The goal of EPILOG is to standardize communication with the core service providers and evaluate responses from carriers more efficiently, providing significant savings in term of process improvements on both sides.
Process
BASF freight procurement activates and posts tenders on the Internet via EPILOG. Pre-selected service providers and carrier companies are informed by e-mail invited to connect to the system. Cariers are given Internet access to query and view the requests for quotations. To access the tender they first have to acknowledge the general terms and conditions. After acknowledgement has been processed, they can review information about the service packages that have been posted to them.
Up until now EPILOG has implemented three major modes of freight procurement: sea box, sea bulk, and road transportation. A typical sea tender consists of several packages, each representing a separate trade lane (for example: Europe to Middle East). Each package contains single lanes describing the shipments that are expected over the next contract period.
01. Service Provider access to EPILOG
The service provider and carrier companies can access the line items and enter a quotation. They can make resource and rate entries in specific templates or download the request for further analysis with a standard spreadsheet (Excel). Bidders can enter and change their offers until the request is closed or the bidding deadline is reached.
During the negotiation period BASF will assign certain lanes and volumes to specific carriers depending on proposals made by the optimization and analysis module.
The freight procurement process comprises the following steps:
- Tender preparation: import of historic contract data from BW and the operational transportation system to EPILOG
- Tender creation: create tender and assign carriers (BSP application)
- Tender publication: create quotation for each carrier and notify them by Email (BSP application)
- Quotation phase: service provider and carrier companies enter and change their quotations (BSP application)
- Negotiation phase: analysis and optimization of carrier selection including ranking and area formation
- Award businesses and publication of awarded businesses
- Confirmation of awarded businesses by carrier companies (BSP application)
- Freight contract creation (BSP application)
- Export of freight contracts from EPILOG to the operational transportation system and BW
Besides the implementation of the freight procurement process, additional BSP applications had to be developed for:
- ‘Carrier Profile Management’ - allowing service providers and carriers to maintain their profile data online (menu link “Business Partner Profile” - screen 01.)
- ‘Logistics Cost Calculations’ - providing sales and marketing personnel with the ability to determine prices that include the transportation expenses (menu link “Sales Price Calculation” - screen 02.).
02. Freight purchasing dept. and sales/marketing personnel access to EPILOG
Infrastructure
Currently, EPILOG runs on a WebAS 6.20 SP40, database ORACLE 9.2. It is accessed and used by the following user groups:
- BASF freight procurement department - 40 users
- Service providers and carriers - 350 users
- Marketing/sales personnel - 400 users
Architecture
During the design process we were facing three major challenges:
- Create a flexible design that allows additional transportation mode to be easily implemented.
‘Sea Box’ and ‘Sea Bulk’ were the first transportation modes for which long-term freight shipping agreements were to be processed using EPILOG. After the first transportation modes had proved to be stable, the ‘road’ transportation mode was to be implemented in a second phase. BASF are currently discussing the extension of EPILOG for air transportation.The design goal was based on implantation of transportation modes by using a common data model, pool of business process classes, and front-end services.
- Keep the number of screens at a minimum and allow screens to be reused across different applications.
The applications covering the tender process, that is ‘Tender/RFQs’, ‘Quotation’ and ‘Freight Agreement’ use a common set of data objects. We wanted to map this property to the visualization layer as well. The patterns defined for object identification and for object detail presentation would be applied across these three implementations. Minor differences in the layout, such as version numbers, that are only available and displayed for ‘Freight Agreement’, should not require the programmer to create a new BSP page or fragment.
- Allow transportation modes to be customized by adding or changing types of tender and freight agreements without having to modify or create application screens and logic.
Each transportation mode has a subset of types. The types determine the key/header fields of a tender, quotation, or freight agreement. See the following screens for examples:
03. Transportation mode ‘Road’ - type ‘Road Bulk’
04. Transportation mode ‚Road’ - type ‚Road Packaged Goods’
05. Transportation mode ‚Sea’ - type ‚Sea Box On-Carriage’
New tender types can be created using the EPILOG customizing. Different numbers and kinds of headerfields can be created for each new tender type. When you are creating a new tender, you select the new type from a dropdown list box. The system then dynamically creates the screen and the header fields. (see screen 06. and 07.)
06. Maintaining types of tenders
07. Select tender type and create new tender
08. Create new tender – header field value selection
Implementation
When we had to close the design phase, the implementation of the WebAS MVC framework was still at an early stage. We therefore decided to adopt the ‘classic’ application class approach and implement all applications to run in statefull mode.
The HTMLB tag library seemed to be a very rich resource of UI controls that fit our needs. It was heavily used and extended where necessary. To comply with point 2) of the architectural challenges we created a pool of page fragments. Providing a common repository, one and the same page fragment could be accessed and included by multiple applications.
Implementing the third point of the architectural challenges required us to consider the following scenarios:
- Handling of screens for which the overall layout is not known at the time of design(see example screens 03. through 0.5) and
- In case layout requirements change, that is items are added or dropped, find a way of implementing these changes without impacting other applications that access the same screen from the page fragment pool.
We introduced two database tables for storing the data of the corresponding page fragment and all possible layout items that will be displayed on the screen. We named this functionality ‘Extended User Interface’ - EUI. At design time the developer creates new records for the page fragment and its layout items.
09. EUI table maintenance view for defining screen layouts
For each layout item, the developer can assign values to attributes. These attributes define certain characteristics of the item, such as visibility, location on the screen, and so forth, or they can directly be mapped to attributes of the corresponding HTMLB tag. An example is shown on screen 10.
10. Layout item definition
During runtime, the records of the corresponding page fragment are read from the EUI tables. Depending on various conditions such as transportation mode, tender type, application, transaction mode, and so forth, the list of layout items is modified. Then, inside the page fragment, the program loops over the list of layout items and depending of their type, the corresponding HTMLB tag is rendered. A small piece of code from a page fragment is shown on screen 11.
11. Dynamic composition of page fragments
Additional functionality
Due to the fact that EPILOG can be run as a standalone application as well as within a heterogeneous system landscape, there are many more features that streamline and improve the freight procurement process. For example, area formation is supported by an IGS connection, and analysis and reporting is achieved through BW integration. These are just two functionalities implemented outside the BSP world. However, since this blog emphasis on BSP technology, three more features are introduced which run in the Web environment.
Reverse auctioning/Ranking of quotations
For the ‘sea’ transportation mode, BASF freight procurement requested a facility to enable carriers to see bidding data relating to their competitor’ quotes. BASF wanted the data to be supplied in real time and the display mode to be configurable.
We have implemented the functionality to display or provide:
- the best (lowest) rate that was offered by a carrier for a certain service
- the rank of the carrier’s quote compared to all the other carriers who are bidding for the same service
- the option for the purchaser overseeing the bidding process each of the features on or off.
12. Real-time ranking
Printing with SAP Smartforms
Across all transportation modes BASF wanted to be able to convert the data of the freight agreement object displayed through BSP into a printable form. This requirement was implemented by creating a smartform object at the time of design. During run time, when the user presses the ‘Print’ button, the following steps are executed:
1) Call function module of generated smartform
2) Convert otf to pdf
3) Set response header accordingly
4) Send response back to client
When the response returns to the client the Adobe Acrobat Reader starts up and displays the object data. You can now either save the file or send the document to your local printer.
13. Freight agreement in EPILOG and PDF format
XML export/import of quotations
Before introducing EPILOG, service providers and carriers widely used spreadsheet applications for maintaining and recording freight rate and resource data. After switching to a web-based application, we still had to support the way business processes were run at the supplier’s side. At an early stage in the development of Epilog we provided a function for downloading quotation data from the browser to Excel. However, as tenders became more complex, especially after the ‘road’ transportation mode was fully implemented (screen 14), BASF needed to maintain data in a two-way fashion (EPILOG <-> Excel).
14. Quotation - transportation mode ‚Road’
The limitations of the web browser regarding navigation between cells in a table lead to inefficiencies from a user perspective. We solved this problem by providing an XML interface for transporting quotation data from EPILOG to Excel and vice versa.
We used functions provided by the iXML library to import data from an export data to EPILOG. Since Excel did not support the import or export of XML formatted files through version 2002 we decided to implement parsing and formatting functionality in a VB macro. See the screen shot below for an example of quotation data imported into Excel with an XML interface.
15. Quotation data in Excel as shown on screen 14.
Summary
SAP’s Web Application Server 6.20, including its major technology feature Business Server Pages (BSP), has provided us with a cutting-edge toolset to develop a scalable, powerful and flexible application that has lead to significant process improvements and cost savings in the area of strategic freight procurement. Derived toolsets like the BSP Extensions and the support of industry standards and formats implemented for example, in the iXML library and PDF conversion modules, has provided us with everything neede to achive system integration and meet customer requirements. It is also thanks to the great development team led by Jean-Philippe Orcel that EPILOG has become an advanced application.
- SAP Managed Tags:
