iNtegrate 2 Business Process Redesign:
Business Process Recommendations
Procurement
May 31, 2013
Business Process
Recommendations: Introduction
Business Process Recommendations
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.
© 2012 Huron Consulting Group. All Rights Reserved. Proprietary & Confidential.
Draft & Confidential, Not for Distribution.
3
Business Process Recommendations
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.
© 2012 Huron Consulting Group. All Rights Reserved. Proprietary & Confidential.
Draft & Confidential, Not for Distribution.
4
Business Process Recommendations
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.
© 2012 Huron Consulting Group. All Rights Reserved. Proprietary & Confidential.
Draft & Confidential, Not for Distribution.
5
Business Process
Recommendations: Procurement
Procurement BPR: Requisitions
PROCESS OVERVIEW
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.
Draft & Confidential, Not for Distribution.
7
Requisition, Page 1
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?
Yes
6: View Item Details
and Add to
Requisition
Yes
8: Access Forms
Repository to
Determine if PreDefined Form Exists
for Need
A
No
Continue
Shopping
7: Services
Acquisition?
Yes
Form
Search
No
Department
A
11: Continue
Shopping?
9: Access Forms
Repository to
Initiate Free-Form
Requisition
10: Populate Form
and Add to
Requisition
13.1: Funds
Checking Executes
13.2: Funds
Available?
A
No
12: Populate the
Remaining
Requisition
Information
13: Submit the
Requisition for
Processing
Yes
Requisition
Approvals
No
13.3: Budget
Configured for
Warning Only?
Yes
13.5: Requestor
Notified Requisition
Amount Exceeds
Available Balance
No
13:4: Requisition
Returned to
Requestor Due to
Lack of Available
Funds
End of Process
Requisition, Page 2
Form
Search
14: Does
Required Form
Exist?
Yes
16: Populate
Require Fields (e.g.
Suggested Supplier,
Service Dates,
Estimated Costs)
15: Select Form
from Repository
17: Add the Service
Request to the
Requisition
Department
No
18: Continue
Shopping?
No
19: Access Forms
Repository to
Initiate Free-Form
Requisition
20: Populate
Require Fields (e.g.
Description,
Supplier)
21.1: Funds
Checking Executes
21.2: Funds
Available?
21: Submit
Requisition for
Processing
Yes
No
21.3: Budget
Configured for
Warning Only?
Yes
21.5: Requestor
Notified Requisition
Amount Exceeds
Available Balance
No
21:4: Requisition
Returned to
Requestor Due to
Lack of Available
Funds
End of Process
Requisition
Approvals
Yes
Continue
Shopping
Requisition, Page 3
Supervisor / Signature Authority
Yes
Requisition
Approvals
21: Requisition
Requires Spvsr.
Review?
Yes
22: Requisition
Routed to
Appropriate
Supervisor /
Signature Authority
23: Requires
Additiona Spvsr.
Reviews?
No
No
24: Requires
Additional
Reviews?
No
A
Yes
Yes
Additional Approvals
25: Requisition
Routed to
Appropriate
Supplemental
Reviewer
26: Requires
Additional
Reviews?
No
A
26.1: Funds
Checking Executes
26.2: Funds
Available?
No
26:3: Requisition
Returned to
Requestor Due to
Lack of Available
Funds
Yes
Business
Center
Review
A
Requisition, Page 4
Business
Center
Review
27: Receive
Requisition
28: Requires
Signed Contract?
Yes
Contract
Review
A
No
29: Review
Requisition and
Supporting
Documentation
Procurement Administration
A
B
33: Competitive
Exception
Required?
34: Obtain Approval
for Competitive
Exception
Yes
No
C
38: Is the
Supplier Active/
Valid?
30: Invalid
Request?
Yes
31: Can Req.
Proceed with
Corrections?
No
No
B
End of Process
35: Valid
Competitive
Exception?
Yes
No
Yes
Bid
Decision
36: Can RX
Proceed with
Corrections?
No
No
Supplier
Reg.
End of Process
Yes
37: Business Center
Coordinates with
Department to
Correct Underlying
Issue
Yes
32: Work with
Institution /
Department to
Revise Requisition
C
B
Procurement Administration
Requisition, Page 5
Bid
Decision
39: Requires
Bidding Event?
No
Generate
PO
Yes
Competitive Bid
Contract Review
Procurement
Administration
Vendor
42: Negotiate
agreement’s terms
and conditions with
institution
Contract
Review
40: Draft agreement
based on requisition
details using
standard template
41: Send draft
contract to vendor
for review
43: Negotiate
agreement’s terms
and conditions with
sponsor
49: Accept terms
and sign agreement
45: Department
impact?
Authorized Official
Office of
General Counsel
Department
Yes
No
46: Validate the
terms, impact, etc.
44: Aid in contract
review/negotiation/
validation
47: Conduct Final
Review
48: Accept terms
and sign agreement
End Process
Procurement BPR: Requisitions
KEY PROCESS CHANGES
The following table outlines the major process changes (NSHE-wide) incorporated into the recommended process.
Process
Flow Title:
Process
Step(s):
Requisitions (Page 2)
14
Requisitions (Page 2)
15
Requisitions (Page 2)
26
Contract Review
40
Contract Review
43
Contract Review
48
Requisitions (Page 1)
Requisitions (Page 1)
8
11
Explanation and Change Justification:
When users are in need of services, they access a list of forms and select the appropriate one for the current need.
The eProcurement system allows users to add multiple items into a single cart.
A 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.
Users 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).
With the transition to an automated procurement application, signature validation is an automated process and enforced by the
application prior to the requisition progressing through the complete approval process.
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.
Tools and training are developed and widely disseminated and reinforced to allow Procurement Administration to manage and
negotiate the straight-forward, template contracts.
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).
Draft & Confidential, Not for Distribution.
14
Procurement BPR: Requisitions
ALTERNATIVE PROCESS OPTIONS
The following table outlines the alternative process options that are not recommended for implementation.
Process
Step(s):
22
29
Alternative Process
Extensively review requisitions submitted by end users with an active
PCard.
Justification for Non-Recommendation:
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.
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.
Require Purchasing Administration (Central) review of requisitions
below a certain dollar threshold where all line items were selected from
Therefore, we do not recommend subjecting a requisition containing only
the pre-defined list of contracted goods or services.
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.
Draft & Confidential, Not for Distribution.
15
Procurement BPR: Requisitions
POLICY CHANGE REQUIREMENTS
The following table outlines the policy change requirements necessary to facilitate the recommended process.
Policy Level:
Policy Requirement
Type:
Policy Development/Addition/Change Requirement:
Each NSHE institution has a specific set of rules for competitive exceptions, in some cases varying across
institutions.
NSHE
Change/Develop
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.
Each institution should ensure formal policy is in place defining signature authority for all agreement contracts.
Institution/NSHE
Reinforce
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.
Draft & Confidential, Not for Distribution.
16
Procurement BPR: Requisitions
IMPLEMENTATION CHALLENGES
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:
Midwestern Public
University
Ivy League Research
Institution
Current Process:
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 be
processed in a single cart.
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 team
worked with representatives from the department to document the existing supervisor chain. Supervisor data was stored and
maintained in their Oracle ERP system.
Draft & Confidential, Not for Distribution.
17
Procurement BPR: Requisitions
IMPLEMENTATION CHALLENGES
Some recommended process changes may be particularly challenging during the implementation phases.
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.
Draft & Confidential, Not for Distribution.
18
Procurement BPR: Requisitions
TECHNOLOGY REQUIREMENTS
The following table lists the system technology requirements necessary to support the recommended process.
Process
Flow Title:
Process
Step(s):
Requisitions
14
Requisitions
15
Requisitions
Requisitions
16
21
Requisitions
25
Requisitions
27
Contract Review
40
Requisitions
Requisitions
Requisitions
Requisitions
Requisitions
2
8
9
9
11
Technology Requirement:
Provide users access to a listing of goods and services offered by preferred providers reflective of contract prices.
Provide users access to predefined forms for the type of service being acquired (e.g., consulting services, sub-award).
Allow users to view a predefined list of goods and services offered by preferred providers reflective of contract prices
Capture user’s custom requirements on a “blank” form that can be submitted to Purchasing Administration for processing.
Allow users to add multiple items into a single cart.
Provide institutions with the ability to determine what approvals are required. For example, some routine, low risk transactions
might not require additional review.
Allow users to pick from a pre-defined list of services. Selecting a service type will initiate 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).
Allows for end users to attach documents required to support the request.
Notify approvers electronically of a requisition for review.
Automatically route requisitions for approval based on not only the funding source, but also on commodity code and other item
attributes. Examples include EH&S review, commodity specific review (e.g., IT equipment), dollar based thresholds, etc.
Assign workload via workflow to buyers based on attributes such as commodity, department, dollar value, vendor class and
existing “queue” (workload).
Allow standard contract templates (Short Forms) to be build into the ERP solution as eForms for easy drafting and
dissemination.
Draft & Confidential, Not for Distribution.
19
Procurement BPR: Requisitions
REPORTING REQUIREMENTS
The following table lists the reporting requirements and data points that must be captured to support the
recommended process.
Process
Flow Title:
Reporting Requirement:
Requisitions
Requisition Cycle Time Details
• Typically incorporated into service level analysis reviews
Requisitions
Spend Volume Reports
• Aggregate spend across institutions by supplier, commodity,
contract, or other combinations
Data Points/Metrics:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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
Supplier
Contract identifier
Commodity code
Supplier part number
Draft & Confidential, Not for Distribution.
20
Procurement BPR: Purchase/Change Orders
PROCESS OVERVIEW
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)
Draft & Confidential, Not for Distribution.
21
Purchase Orders
Generate
PO
1: Finalize
Requisition
1.1: Funds Checking
Executes
Yes
2: Establish
Encumbrance
Procurement Administration
No
1:3: Requisition
Returned to
Department Due to
Lack of Available
Funds
A
Department
1.2: Funds
Available?
7: Open
Encumbrance
Reporting
8: Year End
Reporting
5: Distribute
Purchase Order to
Supplier
6: System Notifies
Requestor of
Purchase Order
Creation
End of Process
3: PO to Be
Automatically
Distributed?
No
End of Process
4: Generate
Encumbrance (Do
Not Distribute
Order)
Yes
A
Department
Change Orders, Page 1
1: Identify Need for
Change to Existing
Order
3: Initiate a “V2” of
the Existing
Purchase Order
2: Access Order in
System
5: Allowable
Changes?
4: Revise Order
Yes
7: Submit Order for
Review
A
No
A
8: Receive Request
for Change to
Existing Order
9: Valid
Request?
Yes
No
11: Can Request
Proceed with
Corrections?
Yes
12: Work with
Requesting Dept. to
Revise Request
Approvals
No
13: Cancel Change
Request
B
10.2: Funds
Available?
Yes
Change
Request
Review
No
10:3: Requisition
Returned to
Department Due to
Lack of Available
Funds
End of Process
End of Process
10: Approve Change
Request
10.1: Funds
Checking Executes
B
Change Orders, Page 2
Change
Request
Review
14: Review Change
Request
15: Valid
Request?
Yes
16: Finalize Change
Request
16.1: Funds
Checking Executes
A
No
Procurement Administration
18: Can Request
Proceed with
Corrections?
Yes
19: Work with
Requesting
Institution to Revise
Request
No
A
16.2: Funds
Available?
Yes
20: Notify Institution
of Issues. Reject
Change Request
End of Process
16.4: Encumbrance
Updated
16.5: Institutions
Notified of
Modification of
Order
No
16:3: Requisition
Returned to
Department Due to
Lack of Available
Funds
21: Supplier
Requires
Updated Order?
No
End of Process
End of Process
Yes
22: Distribute
Revised Order to
Supplier
End of Process
Procurement BPR: Purchase/Change Orders
KEY PROCESS CHANGES
The following table outlines the major process changes (NSHE-wide) incorporated into the recommended process.
Process
Flow Title:
Process
Step(s):
Purchase Orders
5
Purchase Orders
16.1
Change Orders
3
Change Orders
10
Explanation and Change Justification:
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 communication
methods. 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.
Signature authority is validated within the eProcurement application rather than through manual validation means (e.g.,
signature book).
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 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
Draft & Confidential, Not for Distribution.
25
Procurement BPR: Purchase/Change Orders
ALTERNATIVE PROCESS OPTIONS
The following table outlines the alternative process options that are not recommended for implementation.
Process
Step(s):
Alternative Process
Justification for Non-Recommendation:
Limitations in the reporting capabilities of procurement systems can lead to
organizations building and maintaining shadow systems to track open
encumbrances and associated activity.
All
Utilize “shadow” systems to record and track open encumbrances.
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.
Draft & Confidential, Not for Distribution.
26
Procurement BPR: Purchase/Change Orders
IMPLEMENTATION CHALLENGES/PAIN POINTS
Some recommended process changes may be particularly challenging during the implementation phases.
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.
Recommended Process References
Institution:
Midwestern Research
Institute
Current Process:
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.
Draft & Confidential, Not for Distribution.
27
Procurement BPR: Purchase/Change Orders
TECHNOLOGY REQUIREMENTS
The following table lists the system technology requirements necessary to support the recommended process.
Process
Flow Title:
Process
Step(s):
Purchase Orders
1
Purchase Orders
5
Change Orders
22
Change Orders
22
Change Orders
22
Technology Requirement:
Encumbrances are systematically recorded with the release of a purchase order.
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.
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.
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.
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.
Draft & Confidential, Not for Distribution.
28
Procurement BPR: Purchase/Change Orders
REPORTING REQUIREMENTS
The following table lists the reporting requirements and data points that must be captured to support the
recommended process.
Process
Flow Title:
Purchase Orders
Reporting Requirement:
Open Encumbrance Details
Purchase Orders /
Order Distribution Status
Change Orders
Data Points/Metrics:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Departments
Institution
Associated buyer(s)
PO Number/Identifier
PO Status
Remaining balances
Funding source
Date change order was distributed
Status of distribution (if electronic)
Departments
Institution
Associated buyer(s)
PO Number/Identifier
Order status
Draft & Confidential, Not for Distribution.
29
Procurement BPR: Competitive Bid/RFP
PROCESS OVERVIEW
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.
Draft & Confidential, Not for Distribution.
30
Proponent
Request for Proposal Process, Page 1
Start Process
1: Need Identified
for Goods or
Services
2: Proponent
Organization
Submits Request for
Goods or Services to
Purchasing Center
Procurement Administration
3: Valid
Request?
5: Assign Request to
Purchasing Agent
6: Analyze
Proponent Provided
Requirements
11: Finalize RFP
Document
12: Distribute RFP
Opportunity
Notifications to
Suppliers
4: Work with
Proponent on
Revising Parameters
of Request
7: Work with
Proponent to
Finalize
Specifications and
Scope of Work
8: Assemble RFP
Proposal Evaluation
Committee (PEC)
9: Work with
Proponent to
identify Proposal
Evaluation Criteria
and communicate to
PEC
10: Draft RFP
Document and
Review/Revise with
Proponent and PEC
as Required
Notify
Supplier
Procurement Administration
Proposal Evaluation
Committee
Supplier
Request for Proposal Process, Page 2
Notify
Supplier
16: Evaluate
Proposals based on
RFP Criteria and
Specifications
22: Coordinate
Required Contract
Reviews
13: Supplier
Receives
Notification of RFP
Posting
14: Supplier Is
Notified of
Addendums
15: Supplier
Provides Proposal
18: Support the PEC
by Assisting in
Negotiations with
Downselected
Supplier(s)
19: Identify Most
Qualified Supplier as
Based on RFP
Evaluation Criteria /
Scoring
24: Modify
Encumbrance to
Match Awarded
Amount
24.1: Purchase
Order Required?
17: Conduct Supplier
Presentations /
Interviews as
Required by RFP
Specifications
23: Award Contract
Yes
20: Notify Supplier
of Intent to Award
21: Finalize
Contractual Terms
24.2: Distribute
Purchase Order
End of Process
No
Proponent
Competitive Bid Process, Page 1
Start Process
1: Need Identified
for Goods or
Services
2: Proponent
Organization
Submits Request for
Goods or Services to
Purchasing Center
Procurement Administration
3: Valid
Request?
4: Work with
Proponent on
Revising Parameters
of Request
7: Work with
Proponent to
Finalize
Specifications /
Scope of Work
8: Distribute
Notification of
Bidding Opportunity
to Suppliers
Notify
Supplier
5: Assign Request to
Purchasing Agent
6: Analyze
Proponent Provided
Requirements
Supplier
Competitive Bid Process, Page 2
Notify
Supplier
10: Supplier Is
Notified of
Addendums (if
Generated)
11: Supplier
Provides Bid
Proposal
13: Evaluate Bid
Response(s)
14: Award Bid to
Best Value Supplier
15: Notify Supplier
of Intent to Award
Procurement Administration
12: Receive Bid
9: Supplier Receives
Notification of
Bidding Opportunity
and Related
Specifications
15.1: Did
Supplier Accept
Standard T&Cs?
Yes
No
16: Finalize
Contractual Terms
A
18: Award Contract
19: Generate
Encumbrance for
Awarded Amount
End of Process
17: Coordinate
Required Contract
Reviews
A
Procurement BPR: Competitive Bid/RFP
KEY PROCESS CHANGES
The following table outlines the major process changes (NSHE-wide) incorporated into the recommended process.
Process
Flow Title:
Process
Step(s):
Request for Proposal
9
Request for Proposal
12
Request for Proposal
16
Competitive Bid
8
Competitive Bid
13
Explanation and Change Justification:
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.
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.
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.
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.
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.
Draft & Confidential, Not for Distribution.
35
Procurement BPR: Competitive Bid/RFP
IMPLEMENTATION CHALLENGES
Some recommended process changes may be particularly challenging during the implementation phases.
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.
Draft & Confidential, Not for Distribution.
36
Procurement BPR: Competitive Bid/RFP
TECHNOLOGY REQUIREMENTS
The following table lists the system technology requirements necessary to support the recommended process.
Process
Flow Title:
Process
Step(s):
Competitive Bid
2
Competitive Bid
7
Competitive Bid
8
Competitive Bid
Competitive Bid
Request for Proposal
8
10
2
Request for Proposal
10
Request for Proposal
12
Request for Proposal
Request for Proposal
14
16
Request for Proposal
19
Technology Requirement:
Utilize electronic forms to request goods or services.
Allow for embedded collaboration tools within the solicitation management functionality such as document sharing, clause
libraries, and online editing.
Utilize a supplier registration system to automatically generate bidder lists and distribute notifications alerting suppliers to the
opportunity.
Allow institutions to identify what geographic areas the supplier primarily serves.
Automate the distribution of addendum notifications to prospective suppliers.
Utilize electronic forms to request goods or services.
Allow for embedded collaboration tools within the solicitation management functionality such as document sharing, clause
libraries, and online editing.
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.
Automate the distribution of addendum notifications to prospective suppliers.
Allow institutions to identify what geographic areas the supplier primarily serves.
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.
Draft & Confidential, Not for Distribution.
37
Procurement BPR: Competitive Bid/RFP
REPORTING REQUIREMENTS
The following table lists the reporting requirements and data points that must be captured to support the
recommended process.
Process
Flow Title:
Reporting Requirement:
Request for Proposal /
Supplier Response Status
Competitive Bid
Request for Proposal /
Competitive Bid
Supplier Bid Notification Report
• Suppliers receiving notification of RFP/Competitive Bid
posting
Request for Proposal /
Bid/proposal Scoring Summary
Competitive Bid
Data Points/Metrics:
•
•
•
•
•
•
Supplier name
Date of bid notification
Date of response (if applicable)
Completeness of response
Bid list recipient diversity status
Respondent diversity status
• Supplier name
• Assigned categories
• Supplier name
• Weighted averages of bid scoring categories
• Summary of subjective responses (as appropriate)
Draft & Confidential, Not for Distribution.
38
Procurement BPR: Supplier Registration
PROCESS OVERVIEW
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
Draft & Confidential, Not for Distribution.
39
Supplier Registration
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
10.1: Supplier
Reviews and Accepts
Terms and
Conditions of
Software Use
10.2: Supplier
Reviews and Accepts
NSHE Business
Terms and
Conditions
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
Procurement Administration
Supplier
Start Process
14: Do Tax
Forms Support
Reg. Type?
Yes
15: Ins. Cert.
Equal Indicated
Coverage?
Yes
16: Valid Order
From/Remit To
Locations?
No
No
15: Contact Supplier
to Request Updates
to Account
17: Activate Supplier
Record
18: Notify
Departments as
Required of the
Addition of the
Supplier
End of Process
No
Yes
Procurement BPR: Supplier Registration
KEY PROCESS CHANGES
The following table outlines the major process changes (NSHE-wide) incorporated into the recommended process.
Process
Flow Title:
Process
Step(s):
Supplier Registration
1
Supplier Registration
12
Supplier Registration
13
Explanation and Change Justification:
Responsibility 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.
Registration 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.
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.
Draft & Confidential, Not for Distribution.
41
Procurement BPR: Supplier Registration
ALTERNATIVE PROCESS OPTIONS
The following table outlines the alternative process options that are not recommended for implementation.
Process
Step(s):
Alternative Process
Justification for Non-Recommendation:
Best practice calls for a single system to house both potential suppliers (those
receiving solicitation notifications) as well as validated suppliers.
1
9
Only store validated suppliers and manage bid opportunities outside of
the supplier registration system.
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.
The embedded control lies within the requisition approval flow; requisitions to
Preventing suppliers of services from completing the registration
suppliers that have not yet provided valid insurance certificates are routed for
process without providing insurance information.
review and approval prior to purchase order generation so that the supplier
can be prompted to update their profile as appropriate.
Draft & Confidential, Not for Distribution.
42
Procurement BPR: Supplier Registration
IMPLEMENTATION CHALLENGES
Some recommended process changes may be particularly challenging during the implementation phases.
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.
Recommended Process References
Institution:
West Coast Public
University System
Current Process:
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.
Draft & Confidential, Not for Distribution.
43
Procurement BPR: Supplier Registration
TECHNOLOGY REQUIREMENTS
The following table lists the system technology requirements necessary to support the recommended process.
Process
Flow Title:
Process
Step(s):
Supplier Registration
2
Supplier Registration
5
Supplier Registration
6
Supplier Registration
10
Supplier Registration
17
Technology Requirement:
Allow the supplier registration portal to be accessible via the web and open to all potential suppliers of goods and services to
NSHE institutions. Provide ability to search for and filter on physical supplier location and service areas.
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.
Require suppliers to provide the following address information: physical location, PO receipt location, and remit to location.
Automatically prompt the supplier to populate the appropriate Tax Form (e.g., W9) and all other required forms/information
based on their entity type and attributes (e.g., C Corp, partnership).
Provide institutions ability to search across all vendor records, including those records containing comments generated as a part
of the registration process.
Draft & Confidential, Not for Distribution.
44
Procurement BPR: Supplier Registration
REPORTING REQUIREMENTS
The following table lists the reporting requirements and data points that must be captured to support the
recommended process.
Process
Flow Title:
Reporting Requirement:
Supplier Registration Supplier registration status
Supplier Registration Abandoned registrations
Supplier Registration Suppliers by category
Supplier Registration Duplicate supplier records
Data Points/Metrics:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Supplier name
Corporate Status
TIN
Diversity status
Registration status (e.g., in process, completed, approved)
Insurance coverage
Last updated date
Supplier name
TIN
Corporate Status
Supplier contact information
Missing registration components
Acceptance of terms and conditions
Last updated date
Category (e.g., lawn services, scientific supplies)
Supplier name
Corporate Status
TIN
Diversity status
Supplier contact
Registration date
Registration status
Licensing status
Supplier name
TIN
Draft & Confidential, Not for Distribution.
45
Business Process
Recommendations: NSHE
Feedback
NSHE Feedback: Procurement
ROUND 1: MARCH – APRIL 2013
The following table outlines the NSHE feedback and commentary, as well as Huron response when applicable.
SubProcess/
Institution
Topical
Area
Requisitions UNLV
Requisitions UNLV
Purchase/
Change
Orders
UNLV
Competitive
UNLV
Bid/RFP
Competitive
UNLV
Bid/RFP
Competitive
UNLV
Bid/RFP
Comments/Feedback
Huron Response
PCard purchases are not typically on a requisition. Not sure what the point is The text has been updated to more clearly state what process
here.
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.
The system must be able to assign workload to buyers by commodity;
We have added a Technology Requirement to this end. Other
department; dollar limits, from supervising positions to subordinates, etc.
assignment variables could include vendor class, existing
workload.
What 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.
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.
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
This is more clearly articulated as a requirement via a callout
to the flow chart to better illustrate how the notifications are
content/requirement of request (commodity or service) this needs to tie to
supplier section that allows a search for appropriate suppliers (including their distributed.
diversity status, licensing certificates, bond/insurance limits)
Draft & Confidential, Not for Distribution.
47
NSHE Feedback: Procurement
ROUND 1: MARCH – APRIL 2013
The following table outlines the NSHE feedback and commentary, as well as Huron response when applicable.
SubProcess/
Institution
Topical
Area
Competitive UNLV
Bid/RFP
Competitive UNLV
Bid/RFP
Supplier
UNLV
Registration
Supplier
UNLV
Registration
Supplier
UNLV
Registration
Supplier
UNLV
Registration
Comments/Feedback
Huron Response
A step should be added for how the RFP is advertised, posted to web. Is there A callout has been added to the flows to include this step
a way to automate a pre-form notification from the ERP system to notify to
within Step 12 of the RFP process. The ERP can be
post? Insert step before 12 or include as simultaneously with 12.
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.
Would suggest we list that due to the geography of the state it is important to We have added text and content to address this challenge.
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.
Not all suppliers are notified to register; they may decide without any
We have revised the narrative and flows to better capture this
notification from NSHE.
process variation.
Not sure why we would not accept suppliers without insurance. Insurance
The Alternative Process Option was unclear and has been
requirements are not the same for every procurement situation that a supplier updated to state "Preventing suppliers of services from
may be requested to perform. It would not make sense to have someone
completing the registration process without providing
providing bonding etc. until they are actually awarded a contract/PO to do
insurance information."
business with us. Not one size fits all approach will work.
Why would we not consider sending out notices to suppliers to register in
This (valid) point is an Implementation Decision and should be
UNLV's supplier registration system as we start implementing our new ERP? addressed as a part of the conversion process once a system
We could then use that data to populate our new system. This would help
has been selected.
avoid uploading all of the inaccurate data currently in all of the Advantage
instances.
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.)
Draft & Confidential, Not for Distribution.
48
NSHE Feedback: Procurement
ROUND 2: MAY 2013
The following table outlines the NSHE feedback and commentary, as well as Huron response when applicable.
SubProcess/
Institution
Topical
Area
Supplier
UNLV
Registration
Supplier
UNLV
Registration
Supplier
UNLV
Registration
Supplier
UNLV
Registration
Comments/Feedback
Huron Response
If we intend to use one data base for suppliers the system must allow for the We have updated the comments for step #2 to indicate the
suppliers to note that they only service certain institutions or regions, etc..
requirement to allow institutions to search for and filter on
There will have to be filters to avoid misleading assumptions on suppliers
physical supplier location and service areas.
capabilities.
Conflicts of Interest be covered during the review of the applicant's data before We have added clarifying language that the review would
they are activated and uploaded into the system. This would be considered
occur prior to approval of the registration request.
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..
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 Agreed that Tax Form requirement seems specific in light of a
submission could apply throughout the application process (e.g. insurance
general need for a system that would direct
certificates) . The system could prompt the applicant throughout the
suppliers/institutions to complete all required fields based on
submission if that functionality is available and those rules are set up in the the characteristics of the registration. This specific point was
system.
included to make sure we captured this specific point around
the entity type and its impact on the registration forms.
Draft & Confidential, Not for Distribution.
49
NSHE Feedback: Procurement
ROUND 2: MAY 2013
The following table outlines the NSHE feedback and commentary, as well as Huron response when applicable.
SubProcess/
Institution
Topical
Area
General
UNLV
Competitive
UNLV
Bid/RFP
Comments/Feedback
Huron Response
It does not appear that the issue of contracting/legal review of contracts for
We have added a flow diagram under requisitions specifically
any/all purchases that are outside the norm of standard agreements is
outlining the high-level flow for Contract Review, including
clearly/specifically addressed. This is what is the largest hold up on
associated Policy Change Requirements and Technology
processing time and I did not really see this addressed much in here. Where is Requirements.
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?)
This page indicates specific policy needs to be established, but there already We have further built out the Implementation Slide to talk
is consistent policy in place, it is just that the interpretation varies depending about these challenges and how, aside from communication,
on who is completing the review of the exception request. This can happen NSHE institutions can move towards a consistent
with any policy such as this where some degree of flexibility appropriately
interpretation.
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.
Draft & Confidential, Not for Distribution.
50
NSHE Feedback: Procurement
ROUND 2: MAY 2013
The following table outlines the NSHE feedback and commentary, as well as Huron response when applicable.
SubProcess/
Institution
Topical
Area
Competitive
UNLV
Bid/RFP
Requisitions UNLV
Comments/Feedback
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.
Huron Response
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.
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.
Draft & Confidential, Not for Distribution.
51