1. Sub-loop Cabinet Information
Gary Jamieson

2. Our proposal allows us to
Why our proposal is efficient and sufficient for both Chorus and our customers
The approach in the Draft STD proposed providing an extremely extensive data set of information in a high availability regulated database
This drives costs in gathering information that may not be required
This also regulates the way in which we can manage and maintain this data
Our proposal allows us to
Meet the needs of our customers at a reasonable cost level
Provide access to all the relevant cabinet information that Chorus has

3. Efficient and sufficient for our customers
To successfully complete their business planning our customers have a number of needs
Our customers require a sufficient level of information
With our proposal each customer is able to obtain as much information as they request
Our customers are able to obtain the specific information to match their business needs
Our customers require information at the appropriate time
All the Chorus information is available to each customer as need it
Our proposal ensures that unused information is not unnecessarily gathered which would add costs
We believe this balances the needs of our customers whilst ensuring minimum cost impact.

4. How our proposal works with a generic business process flow
Throughout our customers planning they are able to access all the information that Chorus has and combine it with their own business information

5. Our Cabinet information
To successfully manage our network and sell our products we require up to date and relevant information
We maintain the information relating to the cabinets at level that is appropriate for our needs to manage the access network
As the Sub-loop product set has been created we have added to the information that we maintain to ensure our customers will be efficiently served.
As the cabinets are rolling out as part of the FTTN deployments we create the as built records that contain the relevant information for Sub-loop Co-location service
For older cabinets the information is held by the teams that maintain these locally and is retrieved as part of an audit.

6. Our information presentation to our customers
To successfully sell our products and meet our customers needs we need to deliver the relevant information in a cost effective and efficient manner
We are committed to moving to a central network inventory as part of our Separation Undertakings which will allow us to migrate the data set relating to Sub-loop to this
We are committed to rolling out improved Web and B2B interfaces as part of our Separation Undertakings to enable us to present increased levels of information for our products. These interfaces are already subject to regulated STD availability Service Level Terms
As part of any product we are continually reviewing the levels of information that are available to our customers to ensure the success of our products

7. Draft STD database proposal in context with our existing products and systems
This slide is to illustrate our position on why the data set of information that forms part of the product is subject to the regulation of STD’s but that it is more efficient that the systems themselves do not.
As the products develop and mature it is expected that increasing levels of information can be provided. We would like to ensure that the systems architecture to do this is as efficient as we can.
For product instances where the data set is defined and additional information is to be shared with our customers we can efficiently distribute it via the appropriate product instances.
For product instances where the system itself is defined it is likely we will be delayed and constrained by the regulatory framework in getting the information efficiently to our customers

8. Observations of other approaches
Provide all the information at a detailed level up front
Risky without a proven need
Costly and time intensive to gather
Difficult to establish an equitable method of pricing to cover the costs of collating
Provide all the information at a detailed level up front in a dedicated database
Difficult to establish an equitable method of compensation to cover the costs of creation
Inflexibility for integration with additional product data
Provide no information until requested
Entirely needs driven
Drives additional unproductive interactions between Chorus and our customers