integrate 2 business process redesign: business process ... · pdf fileintegrate 2 business...

iNtegrate 2 Business Process Redesign:Business Process Recommendations

ProcurementMay 31, 2013

Business Process Recommendations: Introduction

Draft & Confidential, Not for Distribution.

Business Process Recommendations

3© 2012 Huron Consulting Group. All Rights Reserved. Proprietary & Confidential.

SUB-PROCESS RECOMMENDATION CONTENTS

Recommendations for a redesigned workflow and supporting materials for each of the sub-processes reviewed as part of the iNtegrate 2 BPR project are detailed in the following section. Each sub-process section includes the following:

• Process Overview: A summary narrative of key process steps within the sub-process.• Recommended Future State Process Flow: Detailed process flow of the Future State process steps.• Key Process Changes: For those steps within the Future States that represent primary changes (for one or more

NSHE institutions), an explanation, and justification as necessary, for the process change is highlighted• Alternative Process Options: Process Options not recommended in the future state flow are highlighted along

with a justification of why this option is NOT recommended or incorporated in the process.• Policy Change Requirements: Instances when either institutional or NSHE policy need to be developed or revised

in order to facilitate the recommended process are noted, including recommendations for policy content.• Implementation Challenges: When elements of the recommended future state process were questioned during

workshops or noted as significant areas where implementation would be difficult, further discussion and justification is provided along with examples of institutions also utilizing the recommended process.

• The examples provided are individual institutions utilizing these recommended practices. NSHE represents a diverse set of 8 institutions and the system office presenting limitations in identifying a comparable system or organization that has broadly implemented “best practice” or recommended processes.

• Technology Requirements: Elements of a required technology to enable the process are listed by process step.• Reporting Requirements: Reports, metrics and data points required to monitor and control the process are listed.• NSHE Feedback: Index of comments/feedback provided by NSHE institutions and the Huron response, as needed.




POINTS TO CONSIDER

Each sub-process section incorporates some fundamental concepts that should be understood in order to fully consider the recommendations and supporting content.

• Recommendations versus Current State:• These process recommendations represent Huron’s recommendations for a future state business process

and are not intended to comment on the current state processes across NSHE.• Some process elements may already be the practice of some or all NSHE institutions.

• Business Process Swimlanes (horizontal bands):• The business process focuses on the process steps and the work accomplished in these steps and not

the process owners/work locations. Therefore, the developed flows include general swim-lanes that are not role/location specific, such as Accounts Payable Administration, Travel Administration, Research Administration, etc.

• Flows do include required roles like Vendor, faculty/employee/Investigator, etc. but they do not highlight Administrative Assistant, Vice President of X, etc. The recommended process steps can be applied universally and the steps can be aligned in whatever roles/units are appropriate by institution.




POINTS TO CONSIDER

Each sub-process section incorporates some fundamental concepts that should be understood in order to fully consider the recommendations and supporting content.

• Existing Supplemental Systems:• Some NSHE institutions have implemented different “systems” or technologies that are supplemental to

the Human Resources or Finance Administration Systems. These process flows assume the existing technologies are integrated into the Future State Business Process.

• Out of Scope Systems:• Some process flows incorporate Non-Human Resource/Finance Systems that are out of scope for

iNtegrate 2 (i.e. a Pre-Award “tracking system”). However, in order to be in line with best practice elements, these out-of-scope technologies were incorporated into the recommended processes.

Business Process Recommendations: Procurement


PROCESS OVERVIEW

Procurement BPR: Requisitions

7

Requisitions represents the sub-process by which end users request goods or services be procured for either themselves or their department/organization and the subsequent review and approval process.

• An individual identifies a need for goods or services, either for their use or on behalf of their department/organization (Purchasing Unit).

• The Purchasing Unit executes a search for the goods and services in the eProcurement system and either selects the desired item(s) from the normalized list of items/services or completes a form to request goods or services with custom specifications.

• The eProcurement system validates funding availability upon submission of the requisition.

• The request is routed to the appropriate Purchasing Unit reviewers for review and approval; the request is then routed to Purchasing Administrator for final review and approval (if required based on the type of request submitted)

• The Purchasing Administrator determines what, if any, solicitation requirements exist for the request and takes the appropriate steps.

• After all appropriate procurement processes are complete, the requisition is fully approved.

Requisition, Page 1De

part

men

t

1: Identify Need for Goods or Services

2: Execute Keyword Search for Required Goods or Services

3: Procurement Application Returns

Search Results

4: Desired Goods or Services in

Results?

7: Services Acquisition?

No

Yes6: View Item Details

and Add to Requisition

A

9: Access Forms Repository to

Initiate Free-Form Requisition

No


Determine if Pre-Defined Form Exists

for Need

Yes

10: Populate Form and Add to Requisition

AA 11: Continue Shopping?

No

12: Populate the Remaining Requisition Information

13: Submit the Requisition for

Processing

End of Process

13.1: Funds Checking Executes

13.2: Funds Available?

13.3: Budget Configured for Warning Only?

No

Requisition ApprovalsYes

13.5: Requestor Notified Requisition

Amount Exceeds Available Balance

Yes

13:4: Requisition Returned to

Requestor Due to Lack of Available

Funds

No

Form Search

Continue Shopping Yes

Requisition, Page 2De

part

men

t

14: Does Required Form

Exist?

15: Select Form from RepositoryYes


Initiate Free-Form Requisition

20: Populate Require Fields (e.g.

Description, Supplier)

No

16: Populate Require Fields (e.g. Suggested Supplier,

Service Dates, Estimated Costs)

17: Add the Service Request to the

Requisition

18: Continue Shopping?

21: Submit Requisition for

Processing

No

Form Search

Continue ShoppingYes

End of Process



21.3: Budget Configured for Warning Only?

Requisition Approvals

21.5: Requestor Notified Requisition

Amount Exceeds Available Balance



Funds

Yes

No

Yes

No

Requisition, Page 3Su

perv

isor /

Sig

natu

re A

utho

rity

Addi

tiona

l App

rova

ls

22: Requisition Routed to

Appropriate Supervisor /

Signature Authority

21: Requisition Requires Spvsr.

Review?

23: Requires Additiona Spvsr.

Reviews?

24: Requires Additional Reviews?

No

No

25: Requisition Routed to

Appropriate Supplemental

Reviewer

Yes

Yes

No

26: Requires Additional Reviews?

Yes

Yes

Requisition Approvals

Business Center Review

A



No

Yes



Funds


A

No

A

Requisition, Page 4Pr

ocur

emen

t Adm

inist

ratio

n

27: Receive Requisition

28: Requires Signed Contract?

Contract ReviewYes

29: Review Requisition and

Supporting Documentation

No

30: Invalid Request?

31: Can Req. Proceed with Corrections?

End of Process

No

32: Work with Institution /

Department to Revise Requisition

YesYes B

B33: Competitive

Exception Required?

B

No

34: Obtain Approval for Competitive

ExceptionYes

No

35: Valid Competitive Exception?

36: Can RXProceed with Corrections?

End of Process

No

37: Business Center Coordinates with Department to

Correct Underlying Issue

Yes

No

CYes

C38: Is the

Supplier Active/Valid?

Supplier Reg.

No

Yes



Bid Decision

A

A

Requisition, Page 5Pr

ocur

emen

t Adm

inist

ratio

n 39: Requires Bidding Event? Yes

Compet-itive Bid

No

Bid Decision

Generate PO

Contract ReviewDe

part

men

tO

ffice

of

Gen

eral

Cou

nsel

Vend

orAu

thor

ized

Offi

cial

Proc

urem

ent

Adm

inist

ratio

n

41: Send draft contract to vendor

for review

43: Negotiate agreement’s terms and conditions with

sponsor

48: Accept terms and sign agreement

End Process

No

40: Draft agreement based on requisition

details using standard template

42: Negotiate agreement’s terms and conditions with

institution

49: Accept terms and sign agreement

45: Department impact?

Yes

46: Validate the terms, impact, etc.

Contract Review

44: Aid in contract review/negotiation/

validation

47: Conduct Final Review


KEY PROCESS CHANGES


14

The following table outlines the major process changes (NSHE-wide) incorporated into the recommended process.

Process Flow Title:

Process Step(s): Explanation and Change Justification:

Requisitions (Page 1) 8 When users are in need of services, they access a list of forms and select the appropriate one for the current need.Requisitions (Page 1) 11 The eProcurement system allows users to add multiple items into a single cart.

Requisitions (Page 2) 14A forms repository is formalized which includes standard contract forms. Standard contract forms are developed and loaded into the general repository so a purchasing department can easily access and use the forms, which are submitted with the requisitions.

Requisitions (Page 2) 15Users pick from a pre-defined list of services. Selecting a service type initiates the appropriate custom form that will display the fields applicable to the service request (e.g., service start date, service end date, insurance requirements, sources of information).

Requisitions (Page 2) 26 With the transition to an automated procurement application, signature validation is an automated process and enforced by theapplication prior to the requisition progressing through the complete approval process.

Contract Review 40 Pre-approved contacting forms (e.g., “short form”) are readily available in the ERP via eForms, making it easier for NSHE institutions to leverage existing forms and decrease contracting timelines.

Contract Review 43 Tools and training are developed and widely disseminated and reinforced to allow Procurement Administration to manage and negotiate the straight-forward, template contracts.

Contract Review 48 A consistent set of guidelines is established for signatory authority and used to determine who must sing each agreement/contract depending on contract attributes (dollars, time, unit).


ALTERNATIVE PROCESS OPTIONS


15

The following table outlines the alternative process options that are not recommended for implementation.

Process Step(s): Alternative Process Justification for Non-Recommendation:

22 Extensively review requisitions submitted by end users with an active PCard.

While the PCard will remain a valued and highly utilized procurement vehicle even with the implementation of an eProcurement system, requiring additional reviews and approvals for a requisition submitted by a user that has an active PCard could provide a disincentive to using the system.

Given that end users with active PCards have already been granted the autonomy to procure goods and services with their PCard without prior authorization, consideration should be given to designing workflow rules that reflect that autonomy.

29Require Purchasing Administration (Central) review of requisitions below a certain dollar threshold where all line items were selected from the pre-defined list of contracted goods or services.

By negotiating contracts with defined terms and conditions and pricing and making the items available to end users in the eProcurement system via a list of predefined goods and services, NSHE/Purchasing Administration is removing much of the variability associated with a requisition.

Therefore, we do not recommend subjecting a requisition containing only goods or services selected from that same list of predefined goods or services to further review by the Purchasing Administration (Central) provided the requisition total is below a certain threshold.


POLICY CHANGE REQUIREMENTS


16

The following table outlines the policy change requirements necessary to facilitate the recommended process.

Policy Level: Policy Requirement Type: Policy Development/Addition/Change Requirement:

NSHE Change/Develop

Each NSHE institution has a specific set of rules for competitive exceptions, in some cases varying across institutions.

NSHE should develop consistent policy, at the System level, to be followed by all institutions, outlining what constitutes a valid competitive exception. Policy development should include validation and perspective from all institutions, and their legal representation, to ensure a consistent application of existing competitive exception rules.

Change management, with a focus on communication and training, will help with policy implementation, specifically allowing for consistent interpretations of policy across individuals and institutions.

Institution/NSHE Reinforce

Each institution should ensure formal policy is in place defining signature authority for all agreement contracts.

Signature authority varies across institutions, which can result in less sub-optimal contract review / signature processes. Implementing a standardize signature authority policy will not only aid the contract review process, but also streamline the implementation of the associated rules in the future state ERP.

We recommend as escalation scheme where depending on dollar value, timeframe, and unit committing funds, signatory authority can be leveraged to the appropriate level within the institution.


IMPLEMENTATION CHALLENGES


17

Some recommended process changes may be particularly challenging during the implementation phases.

Implementation Challenge Area: Data Acquisition for Workflow• Currently signature authority, where required, is obtained via manual workflows. Capturing the supervisor chain or owners of funding sources and

storing the data in a procurement system presents data acquisition considerations that will have to be addressed by NSHE institutions should intradepartmental workflows be captured within the procurement application.

• Consensus will need to be gained amount NSHE institutions to determine if goods or services from multiple suppliers can be processed in a single cart.

Recommended Process References

Institution: Current Process:

Midwestern PublicUniversity

The University maintains signature authority for funding sources as a part of their organization setup within their ERP (currently Banner). This information is synchronized with their eProcurement system to drive departmental workflows. Any changes made to the “ownership” of the funding source within the ERP are immediately reflected within the procurement system, allowing for a single point of maintenance for this information. The university also allows goods or services from multiple suppliers to beprocessed in a single cart.

Ivy League Research Institution

This university, characterized by having a highly decentralized procurement process, collected supervisor chain information as a part of the deployment process. Prior to activating an organization’s access to the eProcurement system, the deployment teamworked with representatives from the department to document the existing supervisor chain. Supervisor data was stored and maintained in their Oracle ERP system.




18


Implementation Challenge Area: Varying interpretations of valid competitive exceptions• There are well defined rules for what constitutes a valid competitive exception and our recommendation is that these rules be integrated into a

consistent, NSHE-wide policy. • However, even with consistent policy, differing interpretations can occur across institutions and even across different individuals within institutions. As

noted by NSHE, these varying interpretations can also be the result of institutions being pressured to accept exception, even when this represents a less “obvious” interpretation of exceptions.

• In order for consistent policy to be effective, and meet the goals of our recommendation, consistent interpretation is also a critical process element.• Close communication between the institutions and NSHE can help ensure even more consistent application of existing competitive exception rules. In

addition, all institutions should have a formal process for documenting the exception request, review of the request and end result.• This formal documentation process and a clear policy should empower institutions to only approve exception requests when they truly fit the criteria and

if additional validation is required, such as precedents previously set within NSHE, institutions can coordinate to support each other in this effort.


TECHNOLOGY REQUIREMENTS


19

The following table lists the system technology requirements necessary to support the recommended process.

Process Flow Title:

Process Step(s): Technology Requirement:

Requisitions 2 Provide users access to a listing of goods and services offered by preferred providers reflective of contract prices.Requisitions 8 Provide users access to predefined forms for the type of service being acquired (e.g., consulting services, sub-award).Requisitions 9 Allow users to view a predefined list of goods and services offered by preferred providers reflective of contract pricesRequisitions 9 Capture user’s custom requirements on a “blank” form that can be submitted to Purchasing Administration for processing.Requisitions 11 Allow users to add multiple items into a single cart.

Requisitions 14 Provide institutions with the ability to determine what approvals are required. For example, some routine, low risk transactionsmight not require additional review.

Requisitions 15Allow users to pick from a pre-defined list of services. Selecting a service type will initiate the appropriate custom form that will display the fieldsapplicable to the service request (e.g., service start date, service end date, insurance requirements, sources of information).

Requisitions 16 Allows for end users to attach documents required to support the request.Requisitions 21 Notify approvers electronically of a requisition for review.

Requisitions 25 Automatically route requisitions for approval based on not only the funding source, but also on commodity code and other itemattributes. Examples include EH&S review, commodity specific review (e.g., IT equipment), dollar based thresholds, etc.

Requisitions 27 Assign workload via workflow to buyers based on attributes such as commodity, department, dollar value, vendor class and existing “queue” (workload).

Contract Review 40 Allow standard contract templates (Short Forms) to be build into the ERP solution as eForms for easy drafting and dissemination.


REPORTING REQUIREMENTS


20

The following table lists the reporting requirements and data points that must be captured to support the recommended process.

Process Flow Title: Reporting Requirement: Data Points/Metrics:

Requisitions Requisition Cycle Time Details• Typically incorporated into service level analysis reviews

• Requestor• Requesting business unit• Requesting department• Workflow step count• Elapsed time between workflow steps• Approver name• Initiation date• Approval date• Approval names• Required by/need date

RequisitionsSpend Volume Reports

• Aggregate spend across institutions by supplier, commodity, contract, or other combinations

• Supplier• Contract identifier• Commodity code• Supplier part number


PROCESS OVERVIEW

Procurement BPR: Purchase/Change Orders

21

Purchase/Change Orders represents the sub-process in which a Purchase Order is generated to formally establish an encumbrance and document the commitment in place between the institution to acquire goods or services.

• Processing of the requisition is finalized

• A determination is made if distribution of the purchase order to the supplier is required, and if so, by what mechanism (e.g., electronic distribution, email, fax)

• Modifications are requested to the open encumbrance to reflect changes to the existing agreement (e.g., change in quantity, cancelation of remaining open balance)

• The change order request is reviewed by institution and Purchasing Administration representatives

• The change order is finalized and the encumbrance is updated to reflect the new amount

• A determination is made if distribution of the change order to the supplier is required, and if so, by what mechanism (e.g., electronic distribution, email, fax, verbal communication)

Purchase OrdersPr

ocur

emen

t Adm

inist

ratio

nDe

part

men

t

1: Finalize Requisition

5: Distribute Purchase Order to

Supplier End of Process

2: Establish Encumbrance

7: Open Encumbrance

Reporting

8: Year End Reporting

Generate PO



No


Department Due to Lack of Available

Funds

Yes3: PO to Be

Automatically Distributed?

6: System Notifies Requestor of

Purchase Order Creation

AYes

4: Generate Encumbrance (Do

Not Distribute Order)

No

A

End of Process

Change Orders, Page 1De

part

men

tAp

prov

als

1: Identify Need for Change to Existing

Order

8: Receive Request for Change to Existing Order

9: Valid Request?

No

Yes

11: Can RequestProceed with Corrections?

End of Process

No

12: Work with Requesting Dept. to

Revise RequestYes

10: Approve Change RequestA

3: Initiate a “V2” of the Existing

Purchase Order

2: Access Order in System 4: Revise Order 5: Allowable

Changes?

No

7: Submit Order for ReviewYes A

13: Cancel Change Request

Change Request Review





Funds

End of Process

B

B

No

Yes

Change Orders, Page 2Pr

ocur

emen

t Adm

inist

ratio

n

14: Review Change Request

15: Valid Request? Yes

18: Can RequestProceed with Corrections?

No

No

19: Work with Requesting

Institution to Revise Request

Yes

16: Finalize Change Request

16.5: Institutions Notified of

Modification of Order

20: Notify Institution of Issues. Reject Change Request

21: Supplier Requires

Updated Order?

22: Distribute Revised Order to

SupplierYes

End of Process

End of Process

No

Change Request Review





Funds

A

A

No

16.4: Encumbrance UpdatedYes

End of Process

End of Process


KEY PROCESS CHANGES


25


Process Flow Title:


Purchase Orders 5

One of the primary benefits of many leading eProcurement applications is the ability to electronically route purchase orders to a subset of suppliers, eliminating the need to manually print and fax documentation. This distribution option usually only applies to suppliers that with the technological capability to accept and process orders via EDI, XML, or other electronic communicationmethods. In addition, eProcurement applications can also be configured to automatically fax or email purchase orders directly to suppliers when this fulfillment related information is known and stored in the vendor record.

Purchase Orders 16.1 Signature authority is validated within the eProcurement application rather than through manual validation means (e.g., signature book).

Change Orders 3 The issuing department requests a new version of the order that is electronically reviewed by both the institution's Finance Office as well as the Procurement Administration(as required).

Change Orders 10Change order requests are approved electronically utilizing electronic workflow. Signature authority for change orders, where required, is obtained via manual workflows and capturing the supervisor chain or owners of funding sources and storing the data in a procurement system




26



All Utilize “shadow” systems to record and track open encumbrances.

Limitations in the reporting capabilities of procurement systems can lead to organizations building and maintaining shadow systems to track open encumbrances and associated activity.

Institutions should be incented to utilize the selected software and reporting capabilities need to be robust enough to provide quick and efficient access to data.


IMPLEMENTATION CHALLENGES/PAIN POINTS


27


Implementation Challenge Area: Manually Maintaining Change Order Workflow• Similar to the point raised in regards to the requisition process, signature authority for change orders is obtained via manual workflows and stored and

maintained in the procurement system • This presents data acquisition and technical configuration considerations, specifically the challenge will be designing and maintaining a second

approval flow for change orders from requisitions. Consideration should be given when designing workflows and the associated queues to capture not only the required approvers for requisitions, but also those for change orders.



Midwestern Research Institute

While this institution has not yet fully addressed the challenge presented by change order workflows from a systematic perspective, they have implemented online forms to streamline the change order process. In the case where an existing encumbrance needs to be changed, an online form is submitted, detailing the request. The form is routed for approvals and terminates with the purchasing department, who is responsible for reviewing and implementing the requested changes. As data was being gathered to support the unique routing of change order requests, this institution leveraged their existing workflow rules to route the form and will transition to custom routings once the data collection effort is complete.




28


Process Flow Title:


Purchase Orders 1 Encumbrances are systematically recorded with the release of a purchase order.

Purchase Orders 5 Allow for the automatic routing for purchase orders to suppliers that have provided fax/email/automated fulfillment information;however Purchasing Administration can elect to not automatically distribute the order as appropriate.

Change Orders 22 Allow for the automatic routing for change orders to suppliers that have provided fax/email/automated fulfillment information; however Purchasing Administration can elect to not automatically distribute the order as appropriate.

Change Orders 22 Allow for signature authority (for change orders) to be obtained via manual workflows. Capture the supervisor chain or owners of funding sources and store the data in within the procurement system.

Change Orders 22 Allow for configuration of the procurement application to be able to accommodate unique approval chains for requisitions and subsequent change orders, as approving parties on the two transactions can differ.




29



Purchase Orders Open Encumbrance Details

• Departments• Institution• Associated buyer(s)• PO Number/Identifier• PO Status• Remaining balances • Funding source

Purchase Orders / Change Orders Order Distribution Status

• Date change order was distributed• Status of distribution (if electronic)• Departments• Institution• Associated buyer(s)• PO Number/Identifier• Order status


PROCESS OVERVIEW

Procurement BPR: Competitive Bid/RFP

30

A Competitive Bid / Request for Proposal represents the sub-process in which a Purchasing Unit coordinates with Purchasing Administration to solicit, collect and review competitive bids and proposals.

• An institution identifies a need for goods or services, either for their use or on behalf of their department/organization.

• A purchasing agent is assigned to support the acquisition of goods or services.

• Suppliers are notified of the opportunity to offer their goods or services to the institution.

• Supplier proposals/bids are evaluated by the institution and Purchasing Administration.

• An intent to award is made to the selected supplier.

• A contract between the supplier and institution is negotiated.

• The goods or services are obtained.

Request for Proposal Process, Page 1Pr

opon

ent

Proc

urem

ent A

dmin

istr

atio

n

Start Process1: Need Identified

for Goods or Services

2: Proponent Organization

Submits Request for Goods or Services to

Purchasing Center

3: Valid Request?

4: Work with Proponent on

Revising Parameters of Request

5: Assign Request to Purchasing Agent

6: Analyze Proponent Provided

Requirements

7: Work with Proponent to

Finalize Specifications and

Scope of Work

8: Assemble RFP Proposal Evaluation

Committee (PEC)


identify Proposal Evaluation Criteria

and communicate to PEC

10: Draft RFP Document and

Review/Revise with Proponent and PEC

as Required

11: Finalize RFP Document

12: Distribute RFP Opportunity

Notifications to Suppliers

Notify Supplier

Request for Proposal Process, Page 2Su

pplie

rPr

opos

al E

valu

atio

n Co

mm

ittee

Proc

urem

ent A

dmin

istr

atio

n

16: Evaluate Proposals based on

RFP Criteria and Specifications

13: Supplier Receives

Notification of RFP Posting

14: Supplier Is Notified of

Addendums

15: Supplier Provides Proposal

17: Conduct Supplier Presentations / Interviews as

Required by RFP Specifications

18: Support the PEC by Assisting in

Negotiations with Downselected

Supplier(s)

19: Identify Most Qualified Supplier as

Based on RFP Evaluation Criteria /

Scoring

20: Notify Supplier of Intent to Award

21: Finalize Contractual Terms

22: Coordinate Required Contract

Reviews23: Award Contract End of Process

24: Modify Encumbrance to Match Awarded

Amount

24.1: Purchase Order Required?

24.2: Distribute Purchase OrderYes

No

Notify Supplier

Competitive Bid Process, Page 1Pr

opon

ent

Proc

urem

ent A

dmin

istr

atio

n

Start Process1: Need Identified

for Goods or Services

2: Proponent Organization

Submits Request for Goods or Services to

Purchasing Center

3: Valid Request?

4: Work with Proponent on

Revising Parameters of Request

5: Assign Request to Purchasing Agent

6: Analyze Proponent Provided

Requirements


Finalize Specifications / Scope of Work

8: Distribute Notification of

Bidding Opportunity to Suppliers

Notify Supplier

Competitive Bid Process, Page 2Su

pplie

rPr

ocur

emen

t Adm

inis

trat

ion

9: Supplier Receives Notification of

Bidding Opportunity and Related

Specifications

10: Supplier Is Notified of

Addendums (if Generated)

11: Supplier Provides Bid

Proposal

12: Receive Bid 13: Evaluate Bid Response(s)

14: Award Bid to Best Value Supplier

15: Notify Supplier of Intent to Award

16: Finalize Contractual Terms

17: Coordinate Required Contract

Reviews

18: Award Contract End of Process19: Generate

Encumbrance for Awarded Amount

15.1: Did Supplier Accept Standard T&Cs?

No

AYes

A

Notify Supplier


KEY PROCESS CHANGES


35


Process Flow Title:


Request for Proposal 9 Proponent works with Procurement Administration to establish the Proposal Evaluation Criteria (PEC) and then Procurement Administration assists in communicating this criteria to the committee and ensuring understanding.

Request for Proposal 12 Data stored in the supplier registration system is leveraged to generate bid notifications for suppliers who have registered to be notified of opportunities for the commodity or service areas associated with the solicitation.

Request for Proposal 16

Institutions and Purchasing Administration evaluate supplier proposals accordingly based on regions of service , especially for those suppliers who are limited in scope to one of the two regions. The geographic realities of the state also provides an opportunity to work with other close by entities (e.g., municipalities, independent school districts) on bidding opportunities; incorporating these entities into a more highly automated solicitation management system could prove challenging.

Competitive Bid 8 Data stored in the supplier registration system is leveraged to generate bid notifications for suppliers who have registered to be notified of opportunities for the commodity or service areas associated with the solicitation.

Competitive Bid 13

Institutions and Purchasing Administration evaluate supplier proposals accordingly based on regions of service , especially for those suppliers who are limited in scope to one of the two regions. The geographic realities of the state also provides an opportunity to work with other close by entities (e.g., municipalities, independent school districts) on bidding opportunities; incorporating these entities into a more highly automated solicitation management system could prove challenging.




36


Implementation Challenge Area: Geographic Distribution of Suppliers• Given that Nevada’s population is predominantly located in the northern and southern regions of the state, the sources of supply share this same

geographic distribution. Systems used to support the competitive bid and request for proposal processes will need to be able to allow institutions to identify what region the supplier primarily serves. This will allow institutions and Purchasing Administration to evaluate supplier proposals accordingly, especially for those suppliers who are limited in scope to one of the two regions.

• The geographic realities of the state also provides an opportunity to work with other close by entities (e.g., municipalities, independent school districts) on bidding opportunities; incorporating these entities into a more highly automated solicitation management system could prove challenging.




37


Process Flow Title:


Competitive Bid 2 Utilize electronic forms to request goods or services.

Competitive Bid 7 Allow for embedded collaboration tools within the solicitation management functionality such as document sharing, clause libraries, and online editing.

Competitive Bid 8 Utilize a supplier registration system to automatically generate bidder lists and distribute notifications alerting suppliers to the opportunity.

Competitive Bid 8 Allow institutions to identify what geographic areas the supplier primarily serves.Competitive Bid 10 Automate the distribution of addendum notifications to prospective suppliers.

Request for Proposal 2 Utilize electronic forms to request goods or services.

Request for Proposal 10 Allow for embedded collaboration tools within the solicitation management functionality such as document sharing, clause libraries, and online editing.

Request for Proposal 12 Utilize a supplier registration system to automatically generate bidder lists and distribute notifications alerting suppliers to the opportunity. All for configuration to automatically post the RFP notification at a certain date/time.

Request for Proposal 14 Automate the distribution of addendum notifications to prospective suppliers.Request for Proposal 16 Allow institutions to identify what geographic areas the supplier primarily serves.

Request for Proposal 19 Aid the evaluation of RFP responses (via solicitation management functionality), e.g., automate the scoring process, apply weighted averages to scoring criteria, provide tabulation summaries.




38



Request for Proposal / Competitive Bid Supplier Response Status

• Supplier name• Date of bid notification• Date of response (if applicable)• Completeness of response• Bid list recipient diversity status• Respondent diversity status

Request for Proposal / Competitive Bid

Supplier Bid Notification Report• Suppliers receiving notification of RFP/Competitive Bid

posting

• Supplier name• Assigned categories

Request for Proposal / Competitive Bid Bid/proposal Scoring Summary

• Supplier name• Weighted averages of bid scoring categories• Summary of subjective responses (as appropriate)


PROCESS OVERVIEW

Procurement BPR: Supplier Registration

39

Supplier registration represents the sub-process in which suppliers and vendors are registered and entered into the electronic procurement system.

• An NSHE institution identifies the need to do business with a selected supplier OR a supplier expresses interest in doing business with an institution

• The supplier accesses the online vendor portal and initiates the registration process

• The supplier completes the registration process, accepts the required terms and conditions, uploaded the appropriate certifications, etc.

• Purchasing Administration is notified of the registration request and reviews the supplier provided information

• The supplier is activated an available to receive purchase orders, solicitations, etc. from NSHE institutions

Supplier RegistrationSu

pplie

rPr

ocur

emen

t Adm

inist

ratio

n

No

Start Process

1: Supplier Receives Request to Register

as a Supplier of NSHE Institutions

2: Supplier Accesses Registration Portal

3: Supplier Initiates Registration Process

4: Supplier Provides High Level Company

Information

5: Supplier Indicates if there are any

Existing Conflicts of Interest

6: Supplier Provides Company Address

Information

7: Supplier Provides Contact Information

for Addresses

8: Supplier Indicates if their Insurance

Meets NSHE /Institution

Requirements

9: Supplier has Ability to Add

Insurance Information and

Certificates

10: Supplier Uploads Tax Form

Appropriate for the Entity’s Registration Type and all other

required information

11: Supplier Attests to Accuracy of

Information and Completes Form

A

A

12: Business Center is Notified of New

Registration Request/Update

13: Request is Reviewed for

Accuracy

14: Do Tax Forms Support

Reg. Type?

15: Contact Supplier to Request Updates

to Account

No

15: Ins. Cert. Equal Indicated

Coverage?Yes Yes

No

16: Valid Order From/Remit To

Locations?

17: Activate Supplier Record

Yes

18: Notify Departments as Required of the Addition of the

Supplier

End of Process

10.1: Supplier Reviews and Accepts

Terms and Conditions of Software Use

10.2: Supplier Reviews and Accepts

NSHE Business Terms and Conditions


KEY PROCESS CHANGES


41


Process Flow Title:


Supplier Registration 1Responsibility for managing supplier information is transitioned to the supplier (from NSHE institution). This is a key change for institutions (outside of UNLV who has an SR system currently in place). Interactions with suppliers are that of requesting action on the supplier’s part, as opposed to requesting information.

Supplier Registration 12Registration of suppliers is currently initiated at both Business Center locations. With the adoption of a centralized registration system, a centralized supplier registration team will be needed to support the end to end process for Purchasing Administration.

Supplier Registration 13 While the adoption of a centralized vendor registration system will automate much of the registration process, the human element will still play a critical roll in the overall process, especially in the review and approval of supplier registration requests.




42



1 Only store validated suppliers and manage bid opportunities outside of the supplier registration system.

Best practice calls for a single system to house both potential suppliers (those receiving solicitation notifications) as well as validated suppliers.

Supplier record attributes will allow for institutions to separate potential suppliers from validated suppliers for reporting purposes while still having a single view of the entire supply chain within a single vendor file.

9 Preventing suppliers of services from completing the registration process without providing insurance information.

The embedded control lies within the requisition approval flow; requisitions to suppliers that have not yet provided valid insurance certificates are routed for review and approval prior to purchase order generation so that the supplier can be prompted to update their profile as appropriate.




43


Implementation Challenge Area: Converting to a centralized vendor registration process• A full compliment of supplier data must be available and current in the online supplier registration system. • Given the large volume of suppliers with Advantage and UNLV’s existing online supplier registration system, it will be a challenge to replicate those

records in the new system considering the burden for updating and maintaining information will be shifted to the supplier. • During the Implementation Phase, NSHE will make a conversion decision to either pre-seeding the registration system with minimal data so that when

suppliers access the system they have a starting point or to scrub the existing vendor record and convert all existing records using as much clean data as possible. Suppliers accessing the system will then validate the existing record and make updates where needed.

• With the move to a centralized supplier registration system, the terms and conditions presented to suppliers as a part of the registration process will be standardized across NSHE. NSHE will need to perform a review and reconciliation process of the terms and conditions currently employed by the three purchasing locations.



West Coast Public University System

Currently manages a central supplier registration system for solicitation opportunities. They will soon be expanding the utilization of the system to include all trade vendors utilized by the ten System campuses. University pre-populated the supplier registration system with minimal data (e.g., name, email) and requested participating suppliers provide the remaining pieces of information.




44


Process Flow Title:


Supplier Registration 2 Allow the supplier registration portal to be accessible via the web and open to all potential suppliers of goods and services toNSHE institutions. Provide ability to search for and filter on physical supplier location and service areas.

Supplier Registration 5 Allow for the acknowledgement of a potential conflict of interest via the online form, and depending on the information provided, route the application request to the Purchasing Administrator for further review prior to the request being fully approved.

Supplier Registration 6 Require suppliers to provide the following address information: physical location, PO receipt location, and remit to location.

Supplier Registration 10 Automatically prompt the supplier to populate the appropriate Tax Form (e.g., W9) and all other required forms/informationbased on their entity type and attributes (e.g., C Corp, partnership).

Supplier Registration 17 Provide institutions ability to search across all vendor records, including those records containing comments generated as a part of the registration process.




45



Supplier Registration Supplier registration status

• Supplier name• Corporate Status• TIN• Diversity status• Registration status (e.g., in process, completed, approved)• Insurance coverage• Last updated date

Supplier Registration Abandoned registrations

• Supplier name• TIN• Corporate Status• Supplier contact information• Missing registration components• Acceptance of terms and conditions• Last updated date

Supplier Registration Suppliers by category

• Category (e.g., lawn services, scientific supplies)• Supplier name• Corporate Status• TIN• Diversity status• Supplier contact• Registration date• Registration status• Licensing status

Supplier Registration Duplicate supplier records • Supplier name• TIN

Business Process Recommendations: NSHE

Feedback


ROUND 1: MARCH – APRIL 2013

NSHE Feedback: Procurement

47

The following table outlines the NSHE feedback and commentary, as well as Huron response when applicable.Sub-

Process/Topical

Area

Institution Comments/Feedback Huron Response

Requisitions UNLV

PCard purchases are not typically on a requisition. Not sure what the point is here.

The text has been updated to more clearly state what process we are trying not to encourage. The goal was to encourage NSHE/institutions to incent the use of an eProcurement system (where appropriate) by streamlining the approval process for active PCard holders and didn't capture that sentiment in my original text.

Requisitions UNLVThe system must be able to assign workload to buyers by commodity; department; dollar limits, from supervising positions to subordinates, etc.

We have added a Technology Requirement to this end. Other assignment variables could include vendor class, existing workload.

Purchase/ Change Orders

UNLVWhat is V2 (just a term for request for modification to PO?) We modified the step to display: "3: Modify the PO by Initiating

a “V2” of the Existing Order" referencing a Version 2.

Competitive Bid/RFP UNLV

Is the vehicle to submit requests a requisition so we can determine if there is adequate funding and approval to start the process?

In regards to the form, yes, either a requisition or a customized solicitation form would be submitted. Regarding the question about funding, there was a good debate at the workshops around this point. We agreed to reflect the funding decision point in the process after contract signing.

Competitive Bid/RFP UNLV The Proposal Evaluation Committee does not set the evaluation criteria. This

is establish as part of step 7.


There should be a step for selecting a supplier (bidders) list based on content/requirement of request (commodity or service) this needs to tie to supplier section that allows a search for appropriate suppliers (including their diversity status, licensing certificates, bond/insurance limits)

This is more clearly articulated as a requirement via a callout to the flow chart to better illustrate how the notifications are distributed.


ROUND 1: MARCH – APRIL 2013


48


Process/Topical

Area


Competitive Bid/RFP

UNLV A step should be added for how the RFP is advertised, posted to web. Is there a way to automate a pre-form notification from the ERP system to notify to post? Insert step before 12 or include as simultaneously with 12.

A callout has been added to the flows to include this step within Step 12 of the RFP process. The ERP can be configured to automatically post the RFP notification at a certain date/time, and there are commercial systems that can accommodate this requirement. This has been added as a Technology Requirement.

Competitive Bid/RFP

UNLV Would suggest we list that due to the geography of the state it is important to consider that the purchasing centers often work with other public agencies that are in the same proximity (such as CCSD and Clark County in the South) for better pricing and available supplier base. We often participate or tie on to their solicitations or they with ours.

We have added text and content to address this challenge.

Supplier Registration UNLV Not all suppliers are notified to register; they may decide without any

notification from NSHE.We have revised the narrative and flows to better capture this process variation.

Supplier Registration UNLV

Not sure why we would not accept suppliers without insurance. Insurance requirements are not the same for every procurement situation that a supplier may be requested to perform. It would not make sense to have someone providing bonding etc. until they are actually awarded a contract/PO to do business with us. Not one size fits all approach will work.

The Alternative Process Option was unclear and has been updated to state "Preventing suppliers of services from completing the registration process without providing insurance information."


Why would we not consider sending out notices to suppliers to register in UNLV's supplier registration system as we start implementing our new ERP? We could then use that data to populate our new system. This would help avoid uploading all of the inaccurate data currently in all of the Advantage instances.

This (valid) point is an Implementation Decision and should be addressed as a part of the conversion process once a system has been selected.

Supplier Registration UNLV We are not sure the first Alternative Process Option is a good idea. (But it is

better than a data dump of "garbage " from Advantage.)


ROUND 2: MAY 2013


49


Process/Topical

Area



If we intend to use one data base for suppliers the system must allow for the suppliers to note that they only service certain institutions or regions, etc.. There will have to be filters to avoid misleading assumptions on suppliers capabilities.

We have updated the comments for step #2 to indicate the requirement to allow institutions to search for and filter on physical supplier location and service areas.


Conflicts of Interest be covered during the review of the applicant's data before they are activated and uploaded into the system. This would be considered having the supplier's application in a "pending review" type status. This validation would be part of the other validations to be done such as checking insurance certificates, etc..

We have added clarifying language that the review would occur prior to approval of the registration request.


Each individual item to be submitted to NSHE doesn't need to be listed as separate process points (if they do then there are several missing). We just need to list that information needs to be submitted by supplier, reviewed/accepted by system administrator, and then accepted/approved as a supplier in the system.


Not sure why Tax Forms would be listed only for this data point. Information submission could apply throughout the application process (e.g. insurance certificates) . The system could prompt the applicant throughout the submission if that functionality is available and those rules are set up in the system.

Agreed that Tax Form requirement seems specific in light of a general need for a system that would direct suppliers/institutions to complete all required fields based on the characteristics of the registration. This specific point was included to make sure we captured this specific point around the entity type and its impact on the registration forms.


ROUND 2: MAY 2013


50


Process/Topical

Area


General UNLV

It does not appear that the issue of contracting/legal review of contracts for any/all purchases that are outside the norm of standard agreements is clearly/specifically addressed. This is what is the largest hold up on processing time and I did not really see this addressed much in here. Where is it specifically addressed? Why would there not be specific recommendations on use of standard contracts and bringing general risk factors into how much time is needed for formal agreement review? (Page 6. (slide titled ‘Requisition, Page 4’) there is a connector in the first row to a process ‘Contract Review’, but there is no corresponding process flow or other recommendations/discussion points documented?)

We have added a flow diagram under requisitions specifically outlining the high-level flow for Contract Review, including associated Policy Change Requirements and Technology Requirements.


This page indicates specific policy needs to be established, but there already is consistent policy in place, it is just that the interpretation varies depending on who is completing the review of the exception request. This can happen with any policy such as this where some degree of flexibility appropriately exists within the policy. Page 13 (implementation challenges) summarizes this point, but suggests the answer is closer communication between the institutions and NSHE. I think the issue with competitive exceptions with some of the institutions is not communication but that they feel pressured to accepting exception and not all institutions have a formal process for documenting the request and review process.

We have further built out the Implementation Slide to talk about these challenges and how, aside from communication, NSHE institutions can move towards a consistent interpretation.


ROUND 2: MAY 2013


51


Process/Topical

Area



Contract review can be time consuming. The amount of review and the time taken for executing contracts often over shadows the actual risk assessment for contract driven procurements. General Counsel's, Purchasing's and individual Department's views of particular terms and conditions contained in contracts are often times in conflict. This conflict can negatively impact the processing times for documents required for services in particular.

We have added a Key Process Change under Contract Review that specifically speaks to the need for tools and training (that are widely disseminated) to ensure Procurement Administration(across the institutions and NSHE) are consistently managing contracts and balancing risk with review time in a manner that is consistent with NSHE/institutional priorities.

Requisitions UNLV

Requisition Step 14/15 should indicate that forms repository would need to include standard contract forms. With the transition to automation consideration should be given to developing and loading standard form contracts in the requisition form repository for use by the departments. These forms could be available and submitted with the requisitions. We have updated the materials accordingly.

integrate 2 business process redesign: business process ... · pdf fileintegrate 2 business...

Documents