Forecasting
- Q. Why do I have to forecast so far in advance?
- Q. Why do I have to forecast RFS dates for some orders and order submission dates for others and similar order types?
Q. Why do I have to forecast so far in advance?
A. At Chorus, we want to be able to meet the demands of our customers. To enable us to do this, we must have visibility of what work volume will be required in both the near and longer term, to ensure we can manage our resources effectively & efficiently.
Q. Why do I have to forecast RFS dates for some orders and order submission dates for others and similar order types?
A. For the UCLL service, there are three forecast types that an Access Seeker must provide:
- BAU Forecasts
- Bulk Transfer Forecasts; and
- Exception to BAU Forecasts.
BAU (business as usual) forecasts provide the expected ongoing, everyday demand for UCLL Service. For Chorus, the work begins as soon as the order is submitted & we need to plan resource from this point. Hence, this forecast is required based on when the orders will be submitted.
A bulk transfer is the transfer, in a coordinated manner of 20 or more
MPFs, or end users, onto services based on the UCLL Service supplied to the
Access Seeker. As this work needs to be
synchronised and resources coordinated, the key requirement for this forecast
is when the Access Seeker wants the work to be done - and hence this forecast
is based on the RFS date.
Exception to BAU demand is where resource is required in a particular
area as there has been a surge in demand driven by a one-off market event and
it requires a rapid response. As the key
requirement here is for additional capacity to complete the jumpering activity
then, as with Bulk Transfers, the forecast is based on when the Access Seekers
foresees that this work will need to be carried out and needs to be provided
based on RFS date.
For the Co-location
service, the 24 month rolling forecast provided should be based on the RFS date
- the date on which the Access Seeker's build can commence. By providing based on RFS date, it enables
Chorus to ‘work backwards' and plan the required build to ensure that the
Co-location service is available to the Access Seeker when they require it, and
that their build can commence as planned.
