Typical Business Goal:

Primary success scenario: A Client wants to be 100% sure that the invoices that are transmitted to customers are received by those customers.

In order to achieve this goal, the criteria can be broken down into two critical components:

Successful Transmission of Invoices – Ensure that every invoice is actually delivered to the customer along with the necessary attachments.

Accurate Data on the Invoice – Client wants to be sure that the invoice is correct when it is sent to the customer.

Background

In the upstream oil and gas industry the API PIDX standard has emerged as the de facto standard for electronic procurement. Techstone has developed a robust framework that facilitates the automation and monitoring of electronic procurement (Invoice, Purchase Order, Order Response, etc.) using the PIDX standard. The goal of the framework is to address the two major issues in electronic procurement which are:

Visibility into the process

Rapid deployment of trading partner integrations

The visibility is addressed within the framework by providing automated alerts that are escalated to appropriate personnel. This is a huge advantage over canned reports that users must proactively monitor to discover issues. Visibility is also gained by providing real-time monitoring of the active processes. A combination of read-only as well as functional views of the active processes can be viewed by both functional and technical personnel that expedites the ability to troubleshoot and resolve issues.

The other major advantage of the framework is to enable a quick response to the needs of the business by providing the rapid deployment of new integrations for customers and updating existing customer integrations. Another added benefit of the framework is to provide an ability to modify and resend invoices and reducing the turnaround time of time critical documents, such as invoices.

eInvoice Issues

In order for a Client to implement a solution to resolve their primary objective of successfully transmitting invoices to their customers they must overcome a number of challenges. These challenges include:

Invoice Conformance

Taxes

Third party Invoices

Charges and Discounts

Externalize trading Partner requirements

Flexibility of the PIDX Standard

Multiple Transaction Routing Protocols

Non standard requirements for each customer

Direct and Hub based integrations

Attachment Handling

Special data and process specific requirements

Complexity of solution

Point to Point solutions are costly

Lack of code reuse is costly

Long development cycles to implement each solution from ground up

Gaps between the business and technology teams

Complexity of PIDX

PIDX CONFORMANCE

In the PIDX community the majority of issues surrounding the electronic exchange of business messages stems from conformance. While the individual xml schemas that define the PIDX Business Messages are a vast improvement over their predecessors, continuity of usage continues to vary greatly across the community. Each integration implemented will invariably have its own unique mappings or business requirements.

EXTERNALIZED REQUIREMENTS

Another major contributor of issues that is encountered in the PIDX arena is the propensity for trading partners to push internal processing logic into the transport layer. The way that SAP and Oracle EBS handle, for example, credit lines in an invoice differs. And to enforce internal processing rules from your backend system into the PIDX Business messages will only further the issue of conformance.

FLEXIBILE STANDARDS

Other issues are caused by the flexibility of the PIDX standard. Currently there are two Transaction Routing Protocols defined in the standards, AS2 and RosettaNet. Both are valid to use and are very different, while most use RosettaNet some have adopted AS2.

DIRECT VS. HUB INTEGRATIONS

A PIDX Invoice for example will differ in its mappings depending on the supplier, even if the integration is using a third party exchange, like DO2 or Oildex. While it is true that third party exchanges increase the uniformity of the process, the issues of charges, taxes, discounts, credits, and contract validation can still vary in the mappings.

Development of Architecture

HIGH COMPLEXITY

Due to the significant amount of variability in the requirements for implementing a PIDX solution, careful thought must be given to design. Solutions tend to be become overly complex and ultimately unmanageable and or significantly increase the cost of maintenance over time. Other side effects of not have a properly design architecture are increased implementation times, i.e., costs or the inflexibility of the architecture to adapt to new or changing requirements.

LONG DELVELOPMENT CYCLES

The reason and purpose for implementing an electronic procurement system cannot be over shadowed by the cost or duration of the implementation. The requirement gathering and analysis followed by the connectivity testing, data mappings, and implementation and testing of integrations is a time consuming processes. It is important to have a well organized plan and road map to ensure timely delivery of new functionality.

FUNCTIONAL AND TECHNICAL GAPS

The functional side of the project is focused on business issues like tracking spend, Days Sales Outstanding and cash flow analysis. The technical side of the project is responsible for implementing solutions that facilitate visibility or timing of the availability of the data that is required by the functional side. Ensuring the strategic objectives of the business are going to be met is often times lost in translation to the technical team who is almost always concerned with the just the technology part of the solution. So often, times gaps are created which become difficult to overcome if the architecture is not built to account for it.

Solution - TechStone Framework

The focus is delivering both functional and technical expertise in the area of electronic procurement using the PIDX standards. Techstone’s enterprise framework provides a consolidated procurement implementation for all PIDX integrations and accelerates the trading partner integration process by delivering an enterprise on-boarding process and plan.

This solution provides the ability to abstract out the trading partner specifics from the core PIDX processes. This enables a Client to blue print integration templates which can be replicated for new trading partners and greatly reduces complexity, lowers cost and significantly accelerates implementation time.

By engaging a Client from both the technical and functional perspectives TechStone is able to deliver a fully integrated solution tying together the data and process management of multiple procurement initiatives with the single technical implementation.

Components of TechStone Framework

Project Approach

Iterative Process based on RUP methodology

Rapid Development

Blend of functional and technical

Extensible Framework

Four Layers of Abstraction

Business Process

Transport Delivery

Message Business

Customer Specifics

Canonical Driven Architecture

Segmented internal and external Interfaces

Segmented internal and Data Models

Event Driven Processing

Every transaction is event driven

Event process is centralized and easily extended

Integration Design Patterns (Blue Prints)

Integrations are blue printed to allow for rapid deployment

Conformance of integration across Architecture

Experienced Team

Over 7 years of delivering PIDX related Solutions

Over 10 years of experience in Integration Solutions

Partners with both Oracle and webMethods

Integration of Framework into Business Practices

In order to meet a Client’s total strategic objectives, Techstone’s solutions are designed to facilitate the functional integration of the framework into business processes and to mitigate project risk and specifically target these problem areas. Techstone follows a customized project methodology based on the Rational Unified Process enhanced with best practices, project experience, and vendor specific implementation knowledge.

Maintenance of Electronic Invoicing Implementations

Due to the usual necessity of re-on-boarding existing electronic invoicing customers, a process is defined that will allow a Client personnel, on a repetitive basis, to quickly identify the different requirements for each customer and create the necessary invoice output.

The electronic invoicing process is reviewed in detail to assure all data elements and functions can be carried out by a Client.

Deliverables:

Documented Business Process – Obtaining and documenting all aspects of a given customers requirements and translating into the invoice process.

Monitor Performance of eInvoice Process – Creation of document containing check lists, status definitions, customer specific information such as project costing data, reviewer/approver identification, purchase order and contract information etc.

Analysis and Resolve Data Errors – Definition and documentation of process

Quality Control Plan – A set of internal tests to assure outgoing invoices adhere to the correct format for a given customer.

Test Plan – A repetitive test plan including both pass and fail situations that can be re-run at any given time with the customer on involved test systems.

Routine Maintenance and Support Process – Creation of process document containing appropriate action diagrams, contact information, dispute resolution process etc.

Milestones:

Completion of Business Process Document

Completion of Performance Monitoring Process Document

Completion of Data Analysis and Resolution Document

Completion of Quality Control Plan Document

Completion of Test Plan Document

Completion of Routine Maintenance and Support Document

Enablement of New eInvoicing Implementations

A functional and technical process is created to document and allow for repetitive and easy implementations. The functional elements are; customer request prioritization, on-boarding meetings, documentation of requirements using use cases and data mappings, testing, developing training material for operations personnel and potentially performing the training function. In addition, technical information such as transmit document definition, RosettaNet information, AS2 information, invoice response information and handling is documented.

Deliverables:

Creation of Project Plan – A documented process for each new implementation is generated to include the necessary parties, stakeholders, timeline and deliverables

Functional Business Process Agreement – Creation of the functional aspect of an on-boarding process to be shared with the customer

Technical Infrastructure Agreement – Document describing the required customer fields and their content as well as document transmission method and responses.

Test Plan – Creation of test plan acceptable to both a Client and the customer.

Maintenance Plan – Creation of ongoing maintenance plan for easy identification of appropriate personnel depending on issue.

Milestones:

Completion of Project Plan Template

Completion of Functional Business Process Agreement Template

Completion of Technical Infrastructure Agreement Template

Completion of Test Plan Template

Completion of Maintenance Plan Template

Customer Catalog Maintenance

Clients usually have a general price schedule for each item and negotiated discounts for their customers. In addition, several potential customers such as Chevron, Marathon and ConocoPhillips require catalogs either directly or via OFS-Portal. More customers will be requiring electronic contracts in the near future as rate validation on a line item level is a growing request.

This phase establishes a process around the customer catalog maintenance with a functional system that allows for easy maintenance and alerts for expiration dates etc.

Deliverables:

Preparation of Customer Catalog – Development of business process and associated document for repetitive and easy process with identification of catalog owner.

Technical Publication of Customer Catalog – Definition and documentation of the technical aspects of uploading and managing catalogs for customers on either OFS-Portal or direct.

Functional Definition of Maintenance Process – Creation of functional system for maintaining customer catalogs, communication process, expiration dates, catalog owner and other aspects of this process.

Milestones:

Completion of documentation describing the catalog preparation process.

Completion of documentation describing the technical publication process.

Completion of documentation describing the maintenance process for customer catalogs.

Electronic Invoice Program Management

It is important to measure the improvement that is expected by bringing the electronic invoice solution in-house. For this purpose, a performance reporting process is implemented. The process covers areas such as activity diagrams for the document types involved such as purchase orders, catalogs and invoices.

Additionally, a process model illustrating the data flow through the system is created.

Training for the invoice hub and the field operations is created and communicated either directly or via other entities.

Deliverables

Performance Reports – Development of Invoice, Purchase Order and Catalog Activity diagrams.

Process Model – The process model is documented.

Training Material – All necessary training material is developed and demonstrated either directly or via train-the-trainer model.

Milestones:

Completion of the performance reports

Completion of process model

Completion of training material

Monitoring of Industry Standards

As it is necessary to stay on top of any developments in the industry that may lead to improved business productivity and customer satisfaction, it is important to be involved with the various industry standards that exist within the upstream Oil and Gas sector. Participation in the PIDX XML standards as well as the OFS-Portal standard is necessary.

Benefits of Techstone Framework

EXTENSIBLE FRAMEWORK

Having an extensible framework that allows abstraction at multiple layers to properly contain implementation differences as to not affect other areas of the architecture and promotes code reuse is essential in meeting a Client’s goals. Having separation between the business process layer, transport layer, business message layer and customer specific business requirement layer enables integrations to be assembled based on design patterns rather than individually creating each integration. The building block effect of creating components that have common interfaces that can be constructed in a number of different ways without compromising the integrity of the architecture or causing any undue complexities is the best solution. The result is a highly extensible and scalable solution that will not directly correlate maintenance costs to number of integration deployed.

CANONICAL DRIVEN ARCHITECTURE

A canonical driven architecture is used to decouple the interfaces between a Client’s back office systems and the business messages used to transport information to and from trading partners. Decoupling the data model into internal and external allows the creation of a data model for a specific backend and allows the freedom to use any external data model (Business message) required by trading partners.

EVENT DRIVEN (DATA DRIVEN) ARCHITECTURE

The use of an event driven architecture is a cornerstone of any integration solution. By design this architecture is focused on unpredictable and asynchronous environments. The extremely loosely coupled nature of event driven architectures makes them very effective for integration and middleware solutions by enabling composition of services or actions based on data or state of the business process.

INTEGRATION DESIGN PATTERNS

Design patterns are reusable solutions to commonly reoccurring problems. The PIDX standards by design create a set of commonly reoccurring problems. Through experience these patterns can be enhanced to create a blue print of several common integrations in the PIDX arena. Within each of the business process, Invoice, Purchase Order and Field Ticket design patterns can be created to allow for rapid implementation and deployment of integrations to new trading partners with high level of code reuse. This results in common processing, reduces complexity which translates into less maintenance costs. Implementations that could take weeks to design and implement can be reduced to hours.

EXPERIENCED TEAM

Having an experienced team with large base knowledge in the oil and gas industry, PIDX, webMethods and Oracle is the key enabler to an effective and efficient implementer of PIDX and integration solutions.

Advantages of the Techstone Framework

Provides extensible and reusable architecture for any PIDX Business Process

Reduces trading partner integrations time by providing Design Patterns (Blue Print) for any PIDX Business Process

Reduces one-off trading partner implementations by providing a Many-to-One translation layer to accommodate trading partner specific data requirements and mappings

Provides single internal interface per business message type to the ERP facilitating monitoring and performance metrics.

Provides a simple, repeatable process for all trading partners

Reduces supplier on-boarding effort

Mitigates risk for trading partner specific requirements

Provides standardized implementation request to the implementation team