UC Best-in-Class Approval Rules 10s2 Configurable Approval Rules and Conversion Program © 2011 Ariba, Inc. All rights reserved. Leslie Martensen, Sr. Solutions

UC

Best-in-Class Approval Rules10s2 Configurable Approval Rules and Conversion Program

© 2011 Ariba, Inc. All rights reserved.

• Leslie Martensen, Sr. Solutions Manager, Ariba• Dan Gercak, Sr. Manager, On-Demand Downstream Deployment, Ariba

Agenda• Configurable Approval Rules

Overview Concepts Approval Process Other Rules Managing Approval Rules

• Approval Rule Conversion Process Introductions Roles and Responsibilities Conversion Process Assumptions Timeline Next Steps

© 2011 Ariba, Inc. All rights reserved. 2

Configurable Approval Rules


Features

Browser-based configuration of approval rules Robust management of approval processes Support for simple and complex rules Ability for customers to migrate to new rules on their own schedule

Benefits

Additional self-service configuration capabilities for customersAbility to change processes as organizations and policies evolve

Commodity-based requisition rules for P2P and P2O Serial and parallel approvals in Contract Management

Commodity-based requisition rules for P2P and P2O Serial and parallel approvals in Contract Management

Examples

Description

Ability for customer administrators to configure approval rules in On Demand

3



• Browser-based configuration of approval rules Customer and functional

administrators can configure rules from the Manage drop-down menu

WYSIWYG graphical building of flows and rules

No coding required

4



• Robust management of approval processes Centralized management of all approval processes Create, edit, copy, activate and delete approval processes Version control Check-in/Check-out capabilities

5


• Support for simple and complex rules Serial and parallel flows Robust set of fields available for rules Out-of-the-box “system-defined” conditions for faster rule building Look up approvers or groups based on the state of multiple fields

(Approval Lookup Table Rules) Ability to remove duplicate approvers or the requester based on conditions

(Filter Rules) Add management hierarchy as needed (Chain Rules) Rules that dictate the ability or action based on the editing of an approvable

(Edit Rules) Support for collaborative requisition approval for P2P, P2O and

Services Procurement Support for adding groups, individual users or lists


Configurable Approval RulesTechnical - Agenda

• Concepts• Approval Process• Other Rules• Managing Approval Rules


Configurable Approval RulesConcepts• Approvable

An object or document that can be approved Examples: Requisitions, eForms, Invoice Exceptions

• Approver The user that is given the right to approve or deny an approvable Example: An executive is required to approve all requisitions that

are over $5,000.• Watcher

A user that is given visibility to the approvable during the approval process (“as an FYI”)

This user cannot approve or deny Example: IT has requisitioned a new laptop for Sarah, who is watching

the progress of approvals.



• Concepts• Approval Process

Concepts Conditions Actions Lookup Table Rules

• Other Rules• Managing Approval Rules


Configurable Approval RulesApproval Process

• What is an Approval Process? The set of rules that govern the approval flow for

each approvable Each approvable can only have one active

Approval Process


Configurable Approval RulesApproval Process – Process Diagram


An Approval Process is set of one or more

interconnected “nodes”

Supports both serial and parallel nodes

The approval rule(s) for each node are edited here…

Configurable Approval RulesApproval Process – Rule Editor


Conditions determine if a rule for a node is active or “fired”

If the conditions are met, these are the available Actions: Add

Approvers, Groups or a Lookup Table

Think of it as an IF-THEN statement:

IF Condition, THEN Action

Configurable Approval RulesApproval Process – Conditions

• What is a condition? A condition is an evaluation that determines if an Action needs to be taken

for a node Conditions can reference fields in the approvable or other system-defined

conditions (see below) Each evaluation/condition results in either True or False Complex combination of conditions can be created

• Concepts System-Defined Condition – out-of-the-box conditions that facilitate building

rules (i.e. Requester Has a Manager, Any Line Item With Commodity Code) Compound Condition – Modifies the condition(s) behind it

– All of the following must be true (AND)– None of the following is true (NAND)– Any of the following are true (OR)


Configurable Approval RulesApproval Process – Condition Example


Compound Condition – All of the following conditions must be true to be true overall

Compound Condition – None of these two child

conditions can be true for this compound condition to

evaluate as true

System-Defined Condition

Conditions can compare fields

Conditions can compare fields with values

14

Configurable Approval RulesApproval Process – Additional Notes on Conditions


• Conceptually, conditions are evaluated from right-to-left

• The compound condition “All Are True” with no child conditions evaluates as True

• Fields available for conditions are limited to the header level. For more complex requirements (e.g., rules on requisition line level), we suggest using Approval Lookup Table Rules

15

Configurable Approval RulesApproval Process – Actions


• What are Actions? Actions add Approvers and Watchers to the Approval Process flow

• What Actions are available? Adding individual approvers/watchers Adding groups Adding approvers and groups through the use of a

lookup table16

Configurable Approval RulesApproval Process – Actions (Approvers and Groups)


Select what type of Approver or Group. These are system-defined.

Selecting Add Group….

17

Configurable Approval RulesApproval Process – Actions (Approvers and Groups)


Select which group to add to the Approval Process

18

Configurable Approval RulesApproval Process – Conditions and Actions


Demonstration

19

Configurable Approval RulesApproval Process – Lookup Table Rules


• What are Lookup Table Rules? Lookup Table rules provide a powerful approach to determine approvers based on a

complex set of conditions

20



Select which fields to evaluate (can include line level fields)

Multiple operation options available for each field

• First determine which fields to evaluate

21



Automatically creates table headers

Determine what approvers and/or groups to add

• Then determine what action(s) to take

Export the column headers, fill out the values and then upload

22



CommodityCode Amount IsNotCatalog Group Tooltip Required

30 10000 TRUE IT Manager TRUE

30 20000 TRUE IT Manager TRUE

31 5000 FALSE Purchasing Manager

TRUE

31 15000 FALSE Purchasing Manager

TRUE

CSV File Format

23

Configurable Approval RulesApproval Process - Actions


Demonstration

24


• Line item amounts are aggregated for Lookup Table Rules (different from previous behavior) Example

– Approval rules state that office supplies > $50 requires approval by Purchasing Manager

– Requisition with five lines of ink cartridges (different colors), each $29.99.

– Old way: no lines are > $50, so the rule doesn’t trigger– New way: total for ink is $149.95, so Purchasing Manager

must approve



• Concepts• Approval Process• Other Rules

Filter Rules Edit Rules Chain Rules

• Manage Approval Rules


Configurable Approval RulesFilter Rules

• What are Filter Rules? Remove approvers/watchers from the Approval Process Facilitate auto-approvals


System-defined actions

27

Configurable Approval RulesEdit Rules

• What are Edit Rules? Make the approval editable based on specified conditions


System-defined actions

Condition Builder

28

Configurable Approval RulesApproval Process – Chain Rules

• What are Chain Rules? Chain rules are secondary rules used to help generate

additional approvers for each node Used to add approvers up a management hierarchy


Configurable Approval RulesApproval Process – Chain Rules


When chaining a rule, a secondary tab for a Chain Rule appears

Note that you can only add Approvers and Groups. No Table

Rules for Chain Rules

Like the Base Rule, you can use the Condition Builder

30

Configurable Approval RulesApproval Process – Other Rules


Demonstration

32

Yes

Yes

Yes

Configurable Approval RulesHow do all these rules work together?


Condition True?

Step 1: For each node in the graph:

Add Approvers/ Groups

Is there a Chain Rule?

Chain Condition

True?

Add Additional Approvers/Groups

Node Finished

No No

No

Step 2: Evaluate Filter Rules

Edit Rules stand alone, as they determine the ability to edit post-submission (and the result of editing the approvable) rather than determining who can

approve/watch


• Concepts• Approval Process• Other Rules• Manage Approval Rules

Version Control Testing Administrators


Configurable Approval RulesManaging Approval Rules (Version Control)

• Approval processes can be in one of three states: Active – In use Checked In – Latest version of the approval rule, but not

being used Draft – Either being created or edited




• Editing an Active or Checked-in Approval Process will create a new Draft

• Checking in a Draft will replace the previous version

• Note that any time you “edit,” you are creating a draft of the next version



• History Tab will give a full list of all rule changes • History tab will allow you to revert to an old

approval process

Configurable Approval RulesImpact on Customers

• Live customers will continue to use their current rules built by Ariba GSO

Customers can call GSO for help Customers can migrate on their own Legacy Rules will be End of Life 18 months after 10s2 GA

• New customers will only be able to use the new Configurable Approval Rules feature

The legacy best-practices Javascript-based rules will no longer be supported


UC

Approval Rule Conversion Process


Agenda

• Introductions• Roles and Responsibilities• Conversion Process• Assumptions • Timeline • Next Steps


Introduction• A new Approval Rule Engine was introduced in 10s2, and all rules need

to be converted to this new format. This includes Out of the Box rules and custom rules. The document is a tool to help manage expectations, clarify responsibilities and provide an objective basis for assessing conversion service effectiveness.

• A Kick Off document has been created to support Ariba’s offering to manage and convert customers’ current production Approval Rules to the new configurable Approval Rule Engine.

• The intended audience for this service is customers who have deployed Ariba On-Demand P2P (single instance or FPC), Invoice Pro, Services Procurement, and/or Procurement Content.

• This offering is at no cost to the customer. The only anticipated costs during this effort is if the customer requests on-site support – in these situations, the customer will be required to pay for travel expenses.


Ariba Roles and Responsibilities


Role Responsibilities

Conversion Lead

Point of contact for conversion initiative Provides recommendation to customer for conversion plan Responsible for internal Ariba project tasks Participates in the development of the Approval Rule Inventory Facilitates testing sessions and verification sessions in Test and

Production Coordinates the wrap-up tasks Provides periodic status updates to customer's leadership Escalates issues to Customer and within Ariba

Conversion Analyst

Participates in the development of the Approval Rule Inventory Determines the compatibility of the Test environment Assists in the synching of the Test environment to match Production Converts the Approval Rules in the Test environment Participates in the review and verification of the Test environment Converts the Approval Rules in the Production environment Participates in the review and verification of the Production

environment Assists in the wrap-up tasks

Point of Contact

Manages conversion (issue tracking, status updates, project plan, etc.) Manages Customer communication Coordinates activities of Customer resources Ensures participation of all required Customer resources Provides timely resolution of any escalated issues Reviews and verifies the conversion process stages

Functional / Technical Participation

Participates in assessment of the current Approval Rules Tests and verifies the revised new Approval Rules in the Test and the

Production environments Participate in issue resolution as required.

As required, the Ariba team will engage with/request for additional Ariba resources as required during the project. This may include specific subject matter experts and technical support.

Ariba estimates approximately eight hours per week of customer participation for the duration of the project. This will fluctuate between several personnel participation to part-time activity.

Conversion Project Phases and Tasks


Project plan guiding Ariba and customer from beginning to end. Issue Resolution process defined and managed.

Project Management

Conversion/Verification Activities in Prod

Conversion/Verification Activities in Test

Review of Production Approval Rules

Agreement on the Conversion Process

Review the current Approval Rules in Production and develop an Inventory of these rules. Based on this review, adjust the Project Plan.

Convert the current Approval Rules to the new structure. Customer verifies behavior and approves. Conduct Wrap-Up activities.

Assess the Test environment and perform tasks to synch this environment with Production. Convert the current Approval Rules to the new structure. Customer verifies behavior and approves move to Production. Manage and resolve issues as they arise.

Obtain Agreement to start this project. Review and establish Project Plan and assign resources from Ariba and customer

Agreement on the Conversion

Process

Conversion / Verification

Activities in Test

Conversion / Verification

Activities in Prod

Review of Production

Approval Rules

Project Management

Assumptions


• This process will not start until Ariba obtains agreement from the Customer on the project. At that point, an Ariba Conversion Lead and Conversion Analyst will be assigned.

• There will be several key drivers in this project # of approval rules in place in Production. Since this is a conversion effort of rules,

the number will drive effort. Current status of the Customer Test environment. Unless there is a compelling

reason, the Customer’s test environment will be utilized to convert the approval rules prior to Production. There will be an effort to synchronize this with Production. This does not mean all Production data needs to be ported to Test, but the data and structures used in the approval rules needs to be in place.

Customer understanding of the current approval rules. A solid understanding of the current rules will be attained during the Review of Production Approval Rules phase, but Customer knowledge of “end result” and any specific scenarios would be beneficial.

44

Assumptions


• A review of the Test environment will occur before the sync process in the Conversion/Verification Activities in Test phase

Ariba will work with the customer to determine if there are any components (master data, approval rules, other configuration) in Test that are more up to date than in Production.

This could be based on efforts to test new items before moving to Production.

In these cases, Ariba and the customer will agree to what gets moved from Production to Test, as well as what will need to be moved to Production after this phase is completed.

• Proposed timeline for this effort is four to six weeks.

• Ariba has in place a focused team to support this initiative.

45

Documentation and Training


• DocumentationAriba Contract Management Release Guide

Ariba Procurement Release Guide

Ariba Invoice Release Guide

• Training

• Configurable Approval Rules Pre-recordConfigurable Approval Rules

https://knowledge.ariba.com/AC_web_page/1,5180,110809,00.html

46

Questions



“Safe Harbor” and Confidential Information Statement

This information reflects the status of Ariba solution planning as of January 2011. All such information is the Confidential Information of Ariba (per the contract between our companies), and must not be further disclosed, as stated in the confidentiality clause of that contract. This presentation contains only intended guidance and is not binding upon Ariba to any particular course of business, product strategy, and/or development. Its content is subject to change without notice. Ariba assumes no responsibility for errors or omissions in this document. Ariba shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

UC

Best-in-Class Approval Rules10s2 Configurable Approval Rules and Conversion Program

• Leslie Martensen, Sr. Solutions Manager, Ariba• Dan Gercak, Sr. Manager, On-Demand Downstream Deployment, Ariba


Documents

UC Best-in-Class Approval Rules 10s2 Configurable Approval Rules and Conversion Program © 2011 Ariba, Inc. All rights reserved. Leslie Martensen, Sr. Solutions