BC Bid change requests

Last updated on September 12, 2022

Any changes to BC Bid must be requested through the Change Advisory Board. Requests will be recorded, assessed and actioned through this board.

What is the Change Advisory Board?

A change-advisory board (CAB) delivers support to a change-management team by advising on requested changes and assisting in the assessment and prioritization of changes. It is generally made up of IT and Business representatives that include: a change manager, user managers, technical experts, possibly third parties and customers (if required).

A CAB offers multiple perspectives necessary to ensure proper decision-making. For example, a decision made solely by IT may fail to recognize the concerns of the business. The CAB is tasked with reviewing and prioritizing requested changes, monitoring the change process, and providing managerial feedback.

A CAB is an integral part of a defined change-management process designed to balance the need for change with the need to minimize inherent risks, control costs and impacts of changes. The CAB is responsible for oversight of all changes in the production environment. As such, it has requests coming in from management, customers, users and IT and may involve hardware, software, configuration settings, patches, etc.

Expand All | Collapse All
 

Change Classifications

Most of the BC Bid changes are expected to be either Standard or Normal.

Standard Change

  • Routine or minor change to an existing record
  • Minimal impact to process
  • Low risk/minimal impact
  • Needs to be documented
  • CAB awareness only, approval not required

Normal Change

  • Low to Medium risk
  • Will impact existing processes
  • Needs to be documented and communicated
  • CAB approval required

Major Change

  • Medium to High risk
  • Usually a change to the back-end data (i.e. Entire UNSPSC code set)
  • May include an outage
  • Will impact all users and may impact training material
  • Needs to be documented and communicated
  • CAB approval required

Emergency Change

  • Usually caused by a system outage or security concern
  • Medium to High risk
  • Usually a change to the back-end data or main code
  • Will impact all users
  • Needs to be documented and communicated
  • CAB approval required (perhaps after the fact)
    • Due to the nature of an Emergency Change, full board approval may not be possible. Best efforts will be made to reach as many board members as possible to approve these types of Changes.
 

Types of Changes

  • BC Bid enhancement
  • BC Bid defect
  • Ivalua updates
  • Commodity Code changes
    • New UNSPSC code
    • Changes to existing UNSPSC codes
    • Addition of new UNSPSC code set
  • Template change
  • New BPS organization
  • Landing Page updates
  • BC Procurement Resources updates
  • Request to integrate with BC Bid
  • Ministry name change
  • Policy change
  • Process change for procurement or system
  • Other
 

Requesting Changes

  • Submit requests through the self-service portal or by contacting the Help Desk.
  • The Change Advisory Board will review the request and make a determination.
  • The outcome of your request will be communicated through a list of all planned and completed changes (except for emergency changes) to all buyers and designated Ministry representatives.
  • Ministry representatives and all buyers will be responsible to update any in progress solicitations if a planned change impacts their opportunities.
  • Changes impacting training material or reference documentation including websites and helpdesk scripting will be the responsibility of the PSD Training and Knowledge Management teams.
 

Rejected Changes

Occasionally, the CAB may reject a requested change for reasons including, but not limited to:

  • Inadequate change planning or unit testing
  • Lack of stakeholder acceptance (where applicable)
  • System integration or interoperability concerns
  • Missing or deficient roll-back plans
  • Security implications and risks
  • Timing of the change negatively impacting key business processes
  • Timeframes do not align with resource scheduling (e.g. late-night, weekends, holidays, or during special events)
  • Change not funded