*************************************************** NOTICE *************************************************** This document was converted from WordPerfect to ASCII Text format. Content from the original version of the document such as headers, footers, footnotes, endnotes, graphics, and page numbers will not show up in this text version. All text attributes such as bold, itallic, underlining, etc. from the original document will not show up in this text version. Features of the orginal document layout such as columns, tables, line and letter spacing, pagination, and margins will not be preserved in the text version. If you need the complete document, download the WordPerfect version or Adobe Acrobat version, if available. *************************************************** FEDERAL COMMUNICATIONS COMMISSION In Re: ) ) COMMON CARRIER BUREAU ) OPERATIONS SUPPORT ) SYSTEMS FORUM ) Volume: 1 Pages: 1 through 150 Place: Washington, D.C. Date: May 28, 1997 Before the FEDERAL COMMUNICATIONS COMMISSION Washington, D.C. 20554 In Re: ) ) COMMON CARRIER BUREAU ) OPERATIONS SUPPORT ) SYSTEMS FORUM ) Room 856 FCC Building 2000 L Street, N.W. Washington, D.C. Wednesday, May 28, 1997 The parties met, pursuant to notice, at 9:06 a.m. PARTICIPANTS: REGINA KEENEY, FCC RICHARD WELCH, FCC KALPAK GUDE, FCC SUSAN MILLER VP/General Manager, ATIS GLEN SIRLES, Moderator, Ordering and Billing Forum, SBC DIANNE MOORE, Assistant Moderator, Ordering and Billing Forum, MCI DON RUSSELL, Chief Telecommunications Task Force, Department of Justice KATHERYN C. BROWN, Associate Administrator, Office of Policy Analysis & Development, NTIA VINCE MAJKOWSKI, Commissioner, Colorado Public Utilities Commission JOHN LENAHAN, Assistant General Counsel, Ameritech PARTICIPANTS: (Continued) KEVIN SNYDER, Assistant Vice President, GTE ANNE K. BINGAMAN, Senior Vice President, President, Local Telecommunications Division, LCI International DON LYNCH, Senior Vice President of Finance and Local Markets, MCI Telecommunications STUART MILLER, Vice President, NYNEX ROBERT VAN FOSSEN, Senior Director - Systems Planning & Development, US West CAROL BUSSING, Assistant Vice President, Systems Integration/Planning, Sprint DAVID WHITE, Vice President, Quality and Information Systems, ACSI MARK SIKORA, Senior Business Consultant, Telecommunications Industry, GE Information Services PAUL KANE, Teleport Communications Group DAVE MARLIN, LCI DAVID TERRESKI, Associated Communications ANNE COLIFER, US One I N D E X VOIR WITNESSES: DIRECT CROSS REDIRECT RECROSS DIRE None. Hearing Began: 9:06 a.m. Hearing Ended: 1:02 p.m. P R O C E E D I N G S MS. KEENEY: Good morning, and welcome to the FCC's Common Carrier Bureau Operations Support Systems Forum. I give you a lot of credit for being here. You could be at a caf‚ sipping litchi, talking about the who the next FCC chairman will be, or whether all the Bell companies will merge with all of the IXCs. But instead, you are here at the FCC CCB OSF two-day forum. I congratulate you. (Laughter.) As you know, Operation Support Systems are extremely important to competition. They are the systems' databases and information that local exchange carriers use to provide telecommunication services to their customers. New entrants need access to OSS functions if they are to become true competitors. In the Commission's local competition order, the Commission required incumbent LEC to provide nondiscriminatory access to unbundled network elements, and resale without discriminatory conditions. Included in this obligation is the requirement that incumbent LEC provide nondiscriminatory access to their OSF functions for pre- ordering, ordering, provisioning, maintenance and repair and billing. The Commission said that this access must be under the same terms and conditions that the incumbents provides to themselves or to their customers. The development of meaningful local competition depends on such nondiscriminatory access. This forum is designed to provide information about the advances that are being made in the provision of OSS and to identify what additional steps, if any, are needed to ensure access. We will be hearing from a number of distinguished panelists, including representatives from different parts of the industry who will share with us, among other things, the progress of the development of industry standards for OSS. We are also fortunate to have with us both federal and state representatives. I haven't found all of them yet, but I think they are here. They may be in those cafes, though. I am not really sure. The states have been in the forefront identifying and resolving issues concerning OSS, and these discussions will no doubt be enriched by their experiences. Thank you very much for coming, and I look forward to a productive dialogue. I would now like to introduce Richard Welch, who is the Chief of our Policy Division, and he will be moderating the panels. Thanks, Richard. MR. WELCH: Thanks, Gina. Welcome everybody. We appreciate the large turnout. We have a lot of people who have come to participate in this forum over the next few days from all parts of the country, and we appreciate their efforts in taking time out of their busy schedule. The purpose of the forum is to shine a spotlight on operational support systems and the importance of that to the emergence of local competition. And our goal of this forum is to try to get below the surface, and explore a lot of the issues, technical issues, practical issues, that face incumbents and new competitors as we try to work together to implement the competition that the Telecom Act was meant to provide. We have a number of panels set up over the next two days and presentations. We have tried to come up with a broad variety of speakers on these panels. We have representatives of incumbent local exchange carriers, both independents and Bell operating companies. We have a variety of new competitors trying to enter the local market under various types of competition, unbundled elements for resell, various other avenues. We have vendors who will be participating. We have federal and state government representatives who will be involved in this. So we have a wide variety of people that will be participating. And the goal is to try to get the perspectives of all these people, try to get a better understanding of what the issues are and the problems are, and try to move this process along a bit. A few housekeeping details before we get started. I'll go very quickly over the schedule that we will have in the next couple of days just to remind everybody. We are going to start out with a presentation by ATIS, the Alliance for Telecommunications Industry Solutions, to give us an update about the efforts to develop industry standards in this area. Then we will take a quick break. We will come back with our first major panel, which will be an overview of OSS functions, what is nondiscriminatory access and the role of national standards. That panel will be an hour and 45 minutes. We will take a short break and come back at noon and have another panel on pre-ordering issues, and this is a series of panels that we will have on more specific issues on OSS. And then tomorrow we will come back with three panels. The first one will start at 9:00 in the morning. It will involve ordering and provisioning issues. We will take a break and then have a panel on billing issues, and then our last panel will be on repair and maintenance. The format of these panels will be basically people, the speakers will be giving an opportunity for a short opening statement. I emphasize "short" because time is going to be precious on these, and we have a time keeper over here who is going to be trying to keep everyone honest. The Bureau will pose some questions to the panelists to try to get some -- stimulate some discussion going, and if we have time toward the end of these panels,, we will open it up to questions from the floor. I would encourage everybody to try to focus on facts and what is actually happening out there in the market, to try to get at these issues. We are trying to keep this on a factual type basis; try to explore this. We would like, as much as we can, to stay away from rhetoric and hurling accusations at each other. So I would ask everyone's cooperation in this effort to try to keep this on track. The final point I would make is basically Operational Support Systems is an issue that stems from Section 251 of the Act, the local competition provisions. And the point of this forum is to explore this issue within the context of that rulemaking, which continues today. We have a number of petitions for RECON, and I heard something about a court case that's still pending involving the 251 rules. So there will be a video tape of all these presentations made, and actually entered in the docket in Docket 96-98. So the focus is going to be on the local competition rules and that docket. I should mention that there is another aspect of the Act, Section 271, involving the entrants by Bell Operating Companies into the long distance market, and that also can present issues about OSS, but the purpose of this forum is not to explore that context. We have a couple of pending applications before us. I am sure others are planning to file as well. The point of this forum is not to discuss the merits of those pending applications. I would urge everyone please to try to stay away from that. If anyone does not stay from it, and they make a presentation on the merits involving one of those applications, we are going to have to include something about that in docket in that ongoing adjudication. So I would encourage everybody's cooperation on that. And then real briefly before we get to the ATIS presentation, I was at home last night trying to think about how to kick this off, and it occurred to me that what happened over the weekend might be relevant here. My wife and I are baseball fans, and, in particular, minor league baseball fans. And so over Memorial Day Weekend we decided to take the kids and jump in the minivan and drive to the Eastern Shore of Maryland to Salisbury, Maryland, to see the Delmarva Shorebirds play. The Delmarva Shorebirds are the single affiliate of the Baltimore Orioles, who, I might add, I might digress for those Yankee fans in the audience, Baltimore Orioles are now in first place by eight games over the Yankees. (Laughter.) But I do digress. Anyway, the Delmarva Shorebirds, that single A baseball is comprised of young kinds who are basically in their early twenties who are trying to make it to the major leagues. And some of them, only a handful of them will make it. A lot of them, frankly, are not that good, and they make a lot of mistakes. So we started watching this ball game in Salisbury Saturday night, and the Shorebirds proceed to commit five errors in the first three innings of the game. They committed four errors in the third inning, and the poor kid playing shortstop committed three of those errors, and promptly found a seat on the bench when the manager took him out. And as a result of those errors, the opposing team scored nine runs in the third inning. And so the Shorebirds were immediately down by this huge margin. They were ever able to recover. They were never able to get back in the game, and ultimately they lost 11 to 1. Now, you probably are wondering what the heck does this have anything to do with OSS. This was kind of a strange logic here, but this is what happens to you when you work at the FCC for a year and a half implementing the Telecom Act. You start seeing everything through the prism of the Act, and it's -- as Ross Perot says, "It's kind of sad," but that's the way. (Laughter.) So, anyway, this minor league baseball game may teach us something about local competition and operational support systems. If you think about a new entrant trying to enter the market, who does not have a redundant network of its own, it has to rely on the incumbent for certain things. It's either going to be reselling their services or it's going to need access to unbundled network elements. It needs something from the incumbent in order to compete with the incumbent, and presumably to try to take away business from the incumbent. In order to do that, there has to be communication between the incumbent and the new entrant. There has to be a flow of information back and forth between these two parties to make this work. And if anything happens in that flow of information, it can cause a lot of problems. If you think about what a new entrant is trying to do, they are trying to go around to potential subscribers and persuade them that I have a better service, I provide you something different than incumbent at a competitive price. Give me your hard-earned money and come with me. But if in the process of this communication back and forth between the two parties dozens of things can go wrong. You know, orders can get lost, orders can get delayed, service cannot be turned up promptly. You know, calls for repairs may go unanswered or take delay. And when that happens it reflects on the new entrant. From the perspective of the new customer, they are looking at the new entrant and thinking that the new entrant is committing errors and dropping the ball. And if all this happens early on in the first three innings of the ball game, the new entrant is basically never going to be able to recover and never going to be able to get back in the ball game. So that's sort of a tortured way of looking at it, but in a sort of weird way minor league baseball is a microcosm of local competition in OSS. (Laughter.) My wife would be appalled if I told -- if she heard me tell that story today. So, anyway, we shall now proceed. Enough with minor league baseball. Let's proceed with our first presentation of the day, which will be from ATIS, and I would like to introduce the three folks who will be making this presentation. We have Susan Miller, who is Vice President and General Counsel of ATIS. We have Glen Sirles, who is moderator of the Ordering and Billing Forum, also with SBC Corp. And we also have Dianne Moore, who is Assistant Moderator of the Ordering and Billing Forum, for MCI. And they are here to give us a presentation about their work. MS. MILLER: Good morning. I am Susan Miller. What we thought we would try to do today is give you a picture of the context in which the work is occurring in the Alliance for Telecommunications Industry Solution, ATIS for short, sponsored Order and Billing Forum. And then what we also thought we would do is actually take a look at the work that's going on. So we will start by giving a very brief overview of ATIS, an overview of the Order and Billing Forum, including the mission, the history, the structure and the process, and then we will get into the role of the OBF in addressing issues for access to -- for access to Operation Support Systems for local competition. We will also look at the specific OBF committee involvement, and then we will give you a summary of the work that has occurred, is in progress, and is projected for the future. The purpose of ATIS is provide an opportunity for timely resolution of international and national telecommunications issues. ATIS achieves this purpose by initiating and maintaining open industry forums to address technical and operational issues. In support of the forums, ATIS provides an information source to its members and to the participants of the ATIS committees. And, finally, our ultimate goal is to promote industry progress with minimal regulatory and legislative intervention. ATIS itself sponsors nine industry committees and forums, and we also provide administrative support to those committees and forums. The committees and forums, of which the Ordering and Billing Forum is one of them, is open to all interested parties or any materially affected parties. You do not need to be a member of ATIS to participate in the committees and forums. To date, these nine what I will call parent committees and forums have over 2,000 industry participants and over 300 companies are represented there. Membership in ATIS itself is open to the North American telecommunication service providers with the plant investment in transport and/or switching equipment, as well as the Caribbean World Zone I telecommunication service providers, as well as resellers, manufacturers, and enhanced service providers. The ATIS committees, like the Ordering and Billing Forum, are led by industry volunteers, and we seek volunteers from the industry, from different industry segments so that we can ensure balanced representation for each of the committees in the leadership role. One of the most critical elements of being an ATIS-sponsored committee is that we insist upon due process. And for us, due process requires that certain fundamental principles be incorporated into the operating procedures for each of the ATIS-sponsored committees. We insist upon open meetings. We insist upon issues being industry-wide in scope. That is, issues that are subject to negotiations between companies one on one are not appropriate for discussion in ATIS forums. We do not discuss cost, price or anti-trust sensitive matters. We provide advance notification of meetings. We publish our agendas in advance. We provide recordkeeping of all of our proceedings, and the committees' output are consensus resolution. We provide advanced notice of those consensus resolutions before they go into a final closure stage. And most importantly, these consensus resolutions are for voluntary implementation. That is, they are nonbinding, and there is an expectation by participants that there will be good faith discussions of all of the resolutions and timely implementation. But we do recognize that implementation is really a business decision. What I thought I would do is try to point out where the focus of our discussion is going to occur today. This is really a pretty intricate overview of the ATIS committees. On the left-hand side you will see the nine parent committees which I referred to. We are actually going to be focusing our work today, and Glen and Dianne are going to spend their time almost exclusively in talking about the Ordering and Billing Forum which resides under the auspices of the Carrier Liaison Committee. However, there will also be references to the Network Interconnection/Interoperability Forum, another ATIS- sponsored group that does repair and maintenance issues, and we will also make reference to liaisons from the Ordering and Billing Forum to the Electronic Data Interchange Committee, as well as the Electronic Communications Implementation Committee. These are sub-tending committees under the Telecommunications Industry Forum. So most of the work is occurring in these groups, but the thrust of it is being handled by the OBS. So now I will turn it over to Glen and Dianne who will launch into the OBF process and specific work that the OBF is doing with respect to OSS access. MR. SIRLES: Thanks, Susan. We thought it was important to highlight the OBF mission statement for you this morning. Essentially, it is to provide a forum for customers and providers in the telecommunications industry; to identify, discuss, resolve national issues which affect ordering, billing, provisioning and the exchange of information; about access services, other connectivity and related matters. The key word there is "other connectivity." We made a change back in 1995 to expand the scope of the OBF. Traditionally, we had been founded for access services being established in 1985. But by consensus we expanded our mission and scope as we realized that there were changes taking place in the industry that were going to require the process of forum activity in order to resolve the issues that were being presented to the industry. The first local competition issues were introduced at that time, in May of '95. And important key here is that we had very little regulatory direction at that time. A lot of things were still unknown. A good many of the companies had to formulate policy before they could actually begin discussing issues, and get the process moving. But the process has moved and it's moved quickly, and it's moving even more quickly as we speak. The last thing I would like to point out is throughout our history the OBF has resolved over 1,300 issues between customers and providers in the telecommunications industry. We do have a history of resolving issues between ourselves. There are six standing committees in the OBF, most of which are involved in local competition issues. Within the structure, we have the Billing Committee, the Ordering and Provisioning Committee, Message Processing, Subscription, Telecommunications Services Ordering Request Committee and the SMS/800 Number Administration Committee. SMS/800 Administration is the only committee not currently discussing local competition issues. The reason being that their process is already designed to handle both inter and intra 800 and toll free service. Dianne. MS. MOORE: In understanding with regard to standard resolutions that we have to go through to get a consensus. Susan talked about there is no voting, but there is a large number. We talked about -- there is 475 people we are trying to get consensus from, and we have membership here representing a significant portion of the industry's companies. Meeting frequency, you need to understand in terms of how we can move, how quickly we can move or not move on some of these standard resolution. The only requirements that we really have is that there are four quarterly meetings through the year for a week long when all the committees come together. However, each committee's work is dictated by its workload, and we have been in a situation for the last year where committees have been meeting week long sessions once a month in some committees. So they will move as quickly as need be based on the workload, and the workload right now is being driven by the local issues in almost all of the committees that we are dealing with except, as Glen indicated, SMS. This workload will come into effect where we talk about our attempts to expedite the process and get to some resolutions and some guidelines for local OSS as quickly as we can. Throughout our presentation we are going to talk about the output of the OBF, and what we do in terms of the guidelines and the standards for OSS. We need to understand output for us is that we deal with business issues between companies: how you need to conduct business exchange between companies. When we talk about interface outputs, interface specifications that we come up, it revolves around the business data needed, the usage rules, when and how to use data, when something needs to be exchanged. It can deal with the format of the data for electronic exchange, but we don't deal with the electronic protocols. So when we say interfaces, it's not the protocol interface. I just want to make sure of that. In terms of how we get to resolution, as Susan mentioned, as part of being an open forum, trying to get industry representation in here, we have tried to move expeditiously, yet fairly. So we have two stages of closure. When you get to a resolution, it's called initial closure, and people can review this. It's published in the industry, and it does go final to a quarterly meeting. And the best case scenario an issue can be introduced at OBF and be in final closure in 42 days. That's if you hit every milestone exactly right and get agreement the first time through. That's your best case. More typically, it will take several meetings and a couple of different quarterly sessions to make closure. We do recommend formally to our members and our guidelines that companies begin the implementation considerations at the stage of initial closure. We did a study a few years ago about the occurrence of initial closure to final closure and found that in over 80 percent of the issues it moves straight through with no changes, and there is low risk of starting your implementation work at initial closure, and that is what we recommend. Again, this is a step we need to help expedite what we are trying to do here. You are going to see some stuff here, we want to make sure it's clear that there has been a massive amount of work. We have participants here who have other responsibilities and they are doing, I think, a yeoman job in getting some of the stuff done, but we're going to show you some of the stuff now. The process we are talking about in relation to what this forum is to do, we don't deal with repair and maintenance. We deal with the pre-ordering, ordering provisioning and the billing. both LEC to LEC and user billing. And this is how our committees that Glen showed you a few minutes ago would map to those OSS processes. MR. SIRLES: As Susan mentioned, the Network Interconnection and Interoperability Forum, or the NIIF, deals with the repair and maintenance issues. We are not going to discuss those issues in the forum this morning, but we did want you to know that within the ATIS structure those issues are being dealt with. We are going to talk about, however, the Telecommunications Industry Forum, or TCIF, particularly two components of it; the Electronic Data Interchange Committee, and the Electronic Implementation Committee. We have within OBF established liaisons with those groups in order to assist us in local ordering guidelines and interface standards. Particularly, we have created a formal liaison with the EDI group for handling our local service request forms and the mechanization of those forms through the electronic data interchange process. The way the liaison works the OBF committees are responsible for the business process flows, the interface guidelines and informational requirements. Particularly, we have created the Local Service Ordering Guidelines, Volumes I and Volume II, Version 2 was released March of '97. Within that binder are contained the local service request forms. We brought a copy of that with us this morning just to show you. The binder really doesn't really mean much, but in effect within this binder every blue tab is a type of service, and everyone of these tabs contains the forms necessary to order the basic services required for local competition. These forms in this volume have been referred to the Electronic Data Interchange Committee. They have included within their Version VII the information that was in our Release 1 of the local service request. It is out for ballot now. The ballots should be final in June of '97. LSR Version 2 should be included in EDI Version 7.1, which should be out for ballot in September of '97. It's also important to realize that the Electronic Communications Implementation Committee suggest platforms to the OBF that can be used for the electronic communications. We are finalizing our formal liaison with that group that will allow us to exchange information back and forth with them in a quick and efficient manner. The way the liaison process works is essentially we have designated individuals that attend each other's committee meetings. The OBF works an issue to closure, and then refers that issue to the Electronic Data Interchange Committee. Questions flow back and forth between the groups as the EDI group models the data. Once that process is finished the guideline is balloted by EDI. What is important to realize here is that we have created a process that is interactive back and forth while the issue process is taking place. We did that for the sake of time, for the sake of clarity. It helps us get there faster, and get a product out the door that is reliable once we have completed the process. But it is also important to note that within OBF many local competition issues touched existing processes, and we did not necessarily have to create new processes to develop guidelines. Work and support of many other areas fall into this area. Much guideline work is already completed and is stand-alone. The work we did for the access service request modifications that allow the ordering of interconnection trunks is a good example of this. Also, where other non-OBF groups were needed, we used existing relationship to facilitate the updates. Good example of this are the things we did in billing, our relationships that already existed with Bell Corp's technical review groups for billing. So within the process we have used our existing structure that we had in place to accommodate the needed guidelines on top of the local service ordering process. MS. MOORE: We're going talk about the content of the work and what this actually means, the things Glen talked about, the local service requests and so forth, what does it mean in terms of a business sense. The order we are going to go in is the order of the panels that the FCC set up, which is a bit unfortunate from my point of view, and the pre-ordering in some ways we have done probably the least in this area. Ordering was deemed to be a higher priority. That's where a lot of the initial work went into of the committee that does this work. So you will notice the first pre-ordering issue was introduced in May of '96. They are working on the requirements, information requirements between companies, so you can do pre-ordering. There is expectations. This committee is meeting monthly, and this is a high priority for their meetings. They had it in May. There will be another meeting in a week and a half. There is a strong probability or possibility that they could actually be putting the pre-ordering issues into final closure at the August quarterly meeting, okay. But what this would mean is that they have then the data requirements, the data elements, the business interface specifications created. This is not for this session going to be the electronic interface specifications. When you look at what we have done with ordering work, this is where there has been a tremendous amount of work across the committee. We are going to divide this into a couple different slides to talk about this. Their first issue was in May of '95, and in the area of resale, ordering for resale services they have put several issues into final closure. When we talk about the different local service request forms that Glen was showing, the Version 1 forms would give you the basis for basic resale ordering. The Version 2 forms bring in some other features such as the ISDN. Centrex, you will notice here, just went to initial closure in April. What you get from these forms that the OBF has created is the data requirements, the usage rules about when and how to exchange data, what you need to do with the other companies. That gives you the forms in the binder Glen was holding up. That would allow you to do ordering in a paper format in a manual environment. Okay, that does not get you to automated. When you talk about what the EDI committee is doing, as Glen mentioned, with their Version 7.0 and 7.1, that is where they have done the data formatting for local service ordering, and that gets you to where you can do some electronic exchange between companies. There is close working going on between members in the OBM and the EDI, as Glen mentioned, to make sure the work gets interpreted with a clean pass the first time through, if we can. Other ordering work on unbundled network elements. Again, there is some work done early in the Version 1 that talks about loops. There is some other work going on with ports that comes into Version 2, and there are open issues still involving loop. Again, these are for the forms. When you see SR version and the data formats, the EDI version. Aside from unbundling and the resale, this committee has also dealt with directory listing requirements, how to order directory listing requirements. And this information has been encaptured with the local service request Version 2, and is targeted -- it's not completed yet by EDI, but is targeted for their Version 7.1. It is also important to notice that interconnection trunks are being handled versus the ASR, the access servicer request forms. For access service request the OBF does the information forms, as Glen showed you, for the basic information. We also do the data formatting through a subcommittee. So that is not then farmed out to another group or liaisoned with another group, but that is actually handled by the committee at OBF. They have also worked on a number of portability issues with interim and long term, completed both of those in different versions, respectively. Along with ordering, one important feature is the customer account record exchange or the CARE exchange of information, and Glen will talk about this one. MR. SIRLES: We did think it was important as we talked about ordering to point out that ordering is broader than just the local service request. It's broader than resale. It's broader than unbundled network elements. Some of the first things that we did deal with in the forum was the primary inter-exchange carrier process, or the PIC change process. That process is handled by an industry standard interface known as the Customer Account Record Exchange, and that document had to be modified to accommodate the PIC change process in an unbundled and resold environment. We feel that the Subscription Committee has established the foundation that accomplishes that in the local competition environment. The first issue was accepted in July of '95, and all of the changes that have been completed to date, which do establish a good foundation for that are included in the revisions to Issue 8 of the CARE document, which have been released throughout '96 and into '97. The topics covered include the responsibilities to notify inter-exchange carriers of end user moves, and the information exchanged on resold lines. To highlight a few of these for you, essentially the incumbent, LEC, has a role in the migration to another facility's base provider, and that role is to provide the inter-exchange carrier who is serving that end user information about that migration and the fact that the end user has changed facility-based providers. Within the resold environment, such things as whether or not to include information on list service products from the incumbent LEC related to resold lines was discussed and resolved. Other areas that examined the switch provider's role in the PIC change process for a resold line have been discussed and resolved. Now, I want to hook back, since we are trying to follow the order that the Commission has laid out here, we put CARE within ordering because it's important to realize that that is part of the ordering process. But we did want to move on down the agenda into provisioning. However, you must realize this hooks back to the local service request form. Because as we talk about provisioning, we are talking about a firm order confirmation, a delay notice, a completion notice, and an error ID. These are the issues that have been identified within provisioning that the OBF has dealt with. We have placed one of those into final closure. That's the firm order note confirmation. It was closed October of '96. It was included in our LSR Version 1 and EDI Release Version 7. The other three areas are still open and currently being discussed by the OBF. It's important to note, as Dianne mentioned earlier, that we did tackle ordering first. We put pre-order and we put provisioning behind ordering in the order of importance. And so while these issues are active and we're getting to them, we have concentrated more on ordering in the local service request than we have on these areas. However, we're getting there. MS. MOORE: As it turns out, the same committee within our structure works all three of those areas, so they have had to work with juggling and prioritization quite heavily. In the billing area, there is two components we want to talk about, we have done work with. One is the end user billing and one is the carrier-to-carrier billing. The data exchange between the companies and end user billing is critical to make sure that a competitive local exchange carrier coming into the marketplace gets information sufficient for it to be able to bill its customers and collect its revenues. That's always near and dear to our hearts. So, we are dealing here with how you need to aggregate the information between carriers. You are going to see some acronym type things such as Revenue Accounting Office, RAO, but that is a basic structural component of the usage record exchanges that help the companies identify what they have and how to handle it within their systems. So we had to go through for the incumbent local exchange carriers, the competitive local exchange carriers, how to pass the information in a manner that could be recognized and then match the correct end user customer account. They have also worked with a number of portability in this committee, this session, that impacts them quite a bit. And guidelines for when NPA-NXX is shared in the resale environment, other needs for how to handle more company codes as they need to, port a number of information, and things of that nature. There is still work being done in this committee. Current work includes working on some message processing requirements for resale, some database queries, the number of portabilities so we can make sure we are getting the right information here, and some billing validation database and automated message accounting support, again in the number of portability arena. In the billing arena for carrier-to-carrier billing, there have been several issues and a lot of pre- work has been done here, a lot of work has been done here that's gone to actual final closure. Again, this is one of the areas where we are being proactive in trying to get certain things set in place for exchange of information between companies without having all this happening at this point. I mean, no bill has actually occurred, and we recognize that -- or some of these services -- and we recognize that when it happens we probably need to rework some of this when we get to the details and see how it physically is going to work. We have anticipated how things might work and come up with these resolutions. The billing side and the LEC-to-LEC billing, we have dealt with things such as the interconnection point billing, which is an important way of getting a facility's base competitive local exchange carrier to be able to get information with the incumbent LEC when they are having a facility that's involved in the same service. They again did resale issues, and unbundled element issues. They have got most of these to final closure. You notice the long-term local number portability just went to initial closure in April. So we will go to final closure in the August time frame. They are still working with the local switching and unbundled elements issues. Again, the structure that we have here is that you see they closed at OBF. This is your final closure date. Remember, I said you can start implementation work at the initial closure date with pretty safe assurance that that's going to be your resolution. Within the Billing Committee there is a formal tie to the Bell Corp. Technical Review Group that works in the Carrier Access Billing System, the CAB system, and those groups have been working very expeditiously and parallel to move these things to a data format standard so you can do this electronically and exchange of this information. We have referenced here which CABS version numbers. There are two CABS versions a year, which CABS version numbers were mapped to the OBF issues, so you can tell when you would be able to get this electronically. Now, realize that there were other billing formats discussed in the committee besides CABS. We only had the formal liaison with that group. It's expected that if a company used a different billing system, that the requirements, the data and business requirements and resolutions would still need to be accommodated to whatever billing system is being used. MR. SIRLES: In conclusion, we realize we presented you with a lot of information this morning, much of which you probably couldn't see from the back of the room, so hopefully you will be able to see it later on. What we wanted to show you were several things. The industry guideline development process is an evolutionary one. We have been working on this since '95. Steam has picked up throughout the process. We are moving at a very rapid pace now through as many issues as we can possibly turn out. We do think significant work has been done in establishing a foundation for the OSS guidelines. Virtually everything the OBF deals with does relate directly to OSS. The committees have been and are continuing to work at an accelerated pace. We have changed many of our basic rules to allow not only committees to work faster, but to work smarter. We have established the liaisons that are necessary to have the interdependencies between the forums so that we can move the work along as quickly as possible. We do feel and understand that we have a responsibility to the industry to move quickly, yet be thorough because if we are not thorough we don't turn out a usable product, and we all end up with rework, which is what we are trying to protect and prevent. We take our job very seriously at the OBF. We do feel we provide a valuable service. We have been providing it for years. We feel we are right in the middle of everything that needs to be dealt with now in terms of issues, and very proud of the job that we are doing. If any of you out there are not part of this process and as a result of our comments feel you ought to be, please talk to us because there is room for you and we need your opinions and we need your thought. If you need additional information on what we have presented here this morning, ATIS does have a Web site you can contact, www.atis.org. You will find information on all the ATIS committees. You will find very detailed information on the ordering and billing forum, as well as all of our issues and resolution statements, and all of our documents. So, please use the Web site or contact any of us. We have a few minutes. If anyone has any questions of a general nature, we will be happy to take those. If not, we thank you very much. (Applause.) MR. WELCH: That's concludes the first portion of the program. I want to thank the folks from ATIS for coming. Susan, Glen, Dianne, thank you very much for coming to Washington and giving us that presentation. We will get started with the first panel at 10:00, so we will take a short break for 10 minutes, and we will get started right at 10:00. If I could ask the panelists on the first panel please to gather up front here in the next couple of minutes, that would be helpful. (Whereupon, a recess was taken.) MR. WELCH: The next panel will be focusing on the critical elements of access to OSS function. We have a distinguished group of panelists here. I will introduce them from left to right. First, over here on the far left is Anne Bingaman. Anne is with LCI. She is Senior Vice President for the Local Telecommunications Division. Seated next to Anne is Don Lunch. Don is with MCI, a lot of "CI's" here on the panel. Don is Senior Vice President of Finance and Local Markets at MCI. Sitting next to Don is Kevin Snyder. Kevin is with GTE where he is Assistant Vice President and Process Team leader, and we are glad to have him here today. Sitting next to Kevin is John Lenahan, from Ameritech. John is Assistant General Counsel at Ameritech. Seated next to John is Commissioner Vince Majkowski from the Colorado Commission. We welcome him today. Seated next to Commissioner Majkowski is Katheryn Brown from NTIA, the National Telecommunications and Information Administration. And seated next to Katheryn on the far end on the right is Don Russell from the Department of Justice. Don is head of the Telecom Division. We will follow the standard format for this panel and all the panels where each panelist will deliver some brief opening remarks. We ask that each one of the panelists try to confine that to roughly three minutes because we have, obviously, a lot of ground to cover here. And if you would please keep your eye on Susan, the timekeeper here, she will let you know when the time is getting ready to expire. So I suggest that we go from left to right, and why don't we start with Anne Bingaman. Anne, please. MS. BINGAMAN: Okay. Thank you very much, Richard. It is an honor to be here today, and think the Commission has done an outstanding thing convening these forums. I think my message is that this is a start. It is an excellent start. The Commission needs to involve itself heavily in performance standards and set those performance standards to help the industry, help consumers, help competition, and get this thing off the ground and blasting forward as Congress intended, and I think we all want. I would say just a few things really. In the resale environment there is not a -- ILEC I am aware of, and an incumbent LEC, which has adequate OSS to meet resale. And I say that as a company which is dealing with four incumbent LECs right now, trying to deal with a fifth, Bell Atlantic. We have six months of experience under our belt, a big back office. There are problems in billing, usage, USOC codes, free-from CRSs, CSRs, with Ameritech. We have problems with PacBell with dropped orders. They can only get to 5,000 by the end of fourth quarter '97, 5,000 orders a day, they have told us. Bell Atlantic has refused to sign a resale agreement with us, seeking a confidentiality order for all OSS performance standards, so that anything we told you or the Department of justice would have to be under seal. I have refused to do that. There is statistics I could give you briefly. There are reams of statistics on these kinds of things. But to give you a little bit of feel for -- on just one measure. Orders pending, waiting notice of a due date, in PacBell we have LCI of late last week had 21 orders pending, two for one to three days; one, four to five days; four, six to 10 days; five, 11 to 15 days; and nine orders, 15 days and over. Ameritech, 21 orders one to three days; 22, four to five days; six, six to 10 days. Bell South, 93 orders pending waiting for an installment date; 13, one to three days; 26, four to five days; four, six to 10 days; 45, 11 to 15. This is to give you an idea, OSS and the simplest issues is not there for any of these RBOCs, and I impugn no bad faith whatsoever in this. It is a matter of complexity. This is something people have not done before. And the problem is we need the Commission to step and set performance standards. The resale environment is one thing. The all- important UNE or network platform environment upon which so much of the Commission's policy decisions, its access charge orders depends is basically nonexistent. LCI has worked this winter to try to negotiate moving sales offices and then customers to the UNE environment. NYNEX, we met with March 28th, and they told us, frankly, first, it was going to be more expensive than resale; and, second, well, gee, it would be good cause they hadn't done this with anybody and they need to work the bugs out. and we said, "Great, we will be glad to do it." So the test is ongoing with NYNEX. It's a matter of two months old, but it is in its infancy, and in no way scaleable to commercial operations. Ameritech, we exchanged -- have had several meetings, exchanged letters with, a strong desire to get the UNE platform there because fully half of our business is in the Ameritech region. We need to be able to complete through the platform in the Ameritech region. I thought we were posturing for litigation, frankly. I had gotten quite discouraged, long series of letters back and forth with us and their lawyers, and meetings and people saying they didn't understand. And then the sun broke last Thursday when Neil Cox took the initiative to set up a meeting, to come to town and see me. And I said to him very straight, "Neil, I am very happy about this." I said, "They profess not to know what we want." He said, "No, no, no. We know what you want. We're doing it with AT&T. The problem is we only have one engineering team. We can't conduct more than one test at once." And I said, " Well, let us participate in that test then, because we need the experience. We are trying to get the back office experience to do this." Bell South -- Bell Atlantic, we don't have an agreement with for the reasons I've stated, refusal to sign this onerous confidentiality order, but PacBell and Bell South have had workshops in the last two months, and it's pretty clear they are brand new to this. So the message from here is the Commission is doing the right things focusing on this. You are fulfilling your historic responsibilities. We need you. The industry needs you. The ILECs needs you. The CLECs and the consuming public, to get in and set the performance standards that will drive this and make it work. MR. WELCH: Thanks, Anne. To continue the baseball metaphor, I guess you are asking the FCC to step up to the plate here. Don Lynch from MCI. MR. LYNCH: And we will do as well. Good morning. I am Don Lynch, Senior Vice President of local service operations for MCI. I am pleased to be here today to have the opportunity to share with you some of MCI's concerns as we work to bring competition to local telephone service. As you know, MCI is committed to become a major competitive player in the local markets. We are spending great sums of money, $1.7 billion this year -- through this year, to bring on local facilities. But our strategy also includes the use of resale and unbundled network elements. In those elements that we lease or buy from local encumbrance must function seamlessly with our own network to ensure that our customers receive the kind of quality and service that they have come to expect from MCI. That is why Operation Support Systems are critically important to our efforts. OSS consists of all the computerized and automated systems, together with the associated business processes that ensure carriers can satisfy customer needs and expectations. If OSS systems do not work and interact properly, customers can lose service completely, lose features, receive inaccurate bills, and in some cases even multiple bills. Unfortunately, in many local markets we are encountering non-operational support systems at worst, or barely operational support systems at best. The incumbent local exchange carriers have developed OSS systems that adequately serve their own customers but fail to work with ours for a number of reasons. The OSS systems the ILEC provide are not robust. They often fail to meet company standards or have any adequate performance measurements associated with them. They cannot accommodate high volume commercial use for all functions. For an example, Ameritech systems focus primarily on resale, plain old telephone service pots. There is little proof that Ameritech can successfully process orders for ISDN, private lines, Centrex unbundled network elements, or frame relay. In addition, the use of proprietary interfaces by ILEC serves as a barrier to entry by driving up costs and impeding efficiency. The use of proprietary interfaces require CLEC to develop multiple interfaces for different ILEC to train the representatives on multiple interfaces, and then we are forced to establish the ability to switch between these multiple interfaces. Moreover, ILEC claims of the readiness of their OSS is based upon their view that technical readiness equals operational readiness. Those claims are also based upon the view that readiness for one function translates to readiness for other functions. As a customer service VP for PacBell recently explained, you can do all the testing that you want, but the theoretical world does not translate one for one into the real world. Many difficult problems are encountered that cannot be accounted for ahead of time. Worse yet, there are no recognized measures -- there is no recognized method of measuring OSS performance day to day how are we doing. When MCI buys a product from other vendors, let's use switches for example, we expect those products to work to a certain standard agreed upon with the manufacturer. If the switches fail to meet those standards, MCI can take its business elsewhere. As monopoly providers, vendors, the ILECs have been able to resist negotiating performance standards. The Local Competitors Users Group, LCUG, has developed standards to measure quality. The ILEC should conform to those standards across all business processes within enforceable penalties if they fail to meet those standards. Another critical concern is that systems must be capable of processing large volumes or orders, transactions. Problems with PacBell's OSS have grown in tandem with the volume of orders. As a result, both MCI and ATT have had to scale back their market entry plans in the State of California. Customers deserve the ability to choose local carriers and to change those carriers in a simple, transparent way. They should not lose dial tone, directory assistant listings, or get features they don't want just because the LEC systems are in adequate. Most importantly, local competition cannot flourish without adequate OSS systems. The LEC must be compelled to build and maintain systems that have sufficient capacity and provide parity to all competitors. Only then can consumers -- only then are consumers certain to receive the benefits of real competition, better products, and service at lower price. Thank you. MR. WELCH: Thank you, Don. Next, we will hear from Kevin Snyder of GTE. Kevin? MR. SNYDER: Good morning. I have been involved at GTE in helping to coordinate GTE's compliance to the order. Last August the FCC issued its interconnection order which required the incumbent local exchange companies to provide competitive local exchange companies with nondiscriminatory access to their operation support systems. GTE moved rapidly after receiving the FCC order to fulfill our legal and our business requirements and put in place the capability to receive and process orders from the CLIC on January 1, 1997. We continue to enhance our OSS capabilities for a number of reasons: One, to improve our internal productivity; second, to address expected increases in order volumes; to adopt the national standards; and to serve the needs of our new business customers. To respond to the FCC order, GTE developed the S Secure Integrated Gateway System, or SIGS, which allows two- way electronic communication between the CLEC and GTE's data processing systems. By using SIGS, CLICs have access to the same information and on the same basis as do our own retail representatives. The SIGS application makes doing business with GTE easy and inexpensive. All that is required by the CLEC is a personal computer, a WEB browsers, and a digital certification for security purposes. SIGS addresses all the pre-ordering repair functions ordered by the FCC. For orienting and provisioning processes, GTE utilizes an existing data transmission method widely used within the telecom industry. GTE utilizes Network Data Mover, or NDM, to allow CLEC to electronically submit orders to GTE and for us to electronically communicate back any errors or jeopardies and also service activation information. Later in the year, GTE will incorporate ordering and provisioning into our SIGS platform, utilizing the EDI Version 7 release. Systems and electronic processes are only part of the puzzle. We also moved quickly in '96 to open the National Open Market Center to process CLEC orders. We also revisited procedures and trained all impacted front-line personnel on the new wholesale activity. We have conducted workshops, four of them, across the United States, with over 200 participants representing 60 CLECs. We have also conducted one-on-one meetings and demonstrations of SIGS with CLECS upon request. Currently we have five CLECs using the SIGS platform. Our operational performance during the start up period has been good. Our statistics show that over 95 percent of the committed due dates are being met, and provisioning intervals at parity with our retail channels. GTE, like many ILECs, face challenges in developing our OSS capabilities. Among those challenges were the development of new processes, changing old Legacy systems, the lack of industry standards, little or no forecast of activity, diverse customers with differing needs, and a very short development cycle. In conclusion, I would like to say that we were ready on January 1st and are ready now to process the orders of the new market entrants. We have developed processes that reflect our corporate philosophy of being easy to do business with. And finally, we continue to move aggressively to provide new enhancements to adjust industry standards and to meet the business needs of our new customers. Thank you. MR. WELCH: Thank you, Kevin. Next, John Lenahan from Ameritech. MR. LENAHAN; Thank you, Richard. The purpose of this panel is to answer the question of what is nondiscriminatory access to OSS mean, and I thought I would give you Ameritech's view of what the legal requirements as spelled out in the first report in order, and as supplemented by the second order on reconsideration, set the legal standard, and then briefly describe to you the things that Ameritech has done to meet that standard. The legal standard is pretty clear. The ILEC has an obligation to provide equivalent access to the electronic OSS information and functions that it provides to itself, its customers or other carriers. This access must permit the CLEC to perform these functions in substantially the same time and manner that the ILEC performs for itself. Ideally, the access should be through interfaces that are consistent with national standards, but the FCC is very clear that if national standards don't exist, that compliance is not required. And the ILEC is required to make modifications to its systems to facilitate this access. So that's the legal standard. What as Ameritech done since the order in 9698 to meet that standard? Basically, we have done four different things. First, we have implemented and defined specifications for each of the OSS functions. This has been done through an iterative process. As the presentation demonstrated this morning, it is an evolutionary process. We have published technical specs. We have published user guides. We have published so-called business rules. Like GTE, we have conducted one-on-one training sessions. We have an entire group dedicated to helping the CLEC implement our OSS interfaces. And we have implemented a change in management process in recognition of the fact that the technical and business information that is needed will change, and it needs to be updated. Most of this documentation is available on our home page. It's about 4,005 pages of technical specs and user information. The second thing we have done is ensure that the five OSS interfaces in each of the subfunctions are in fact operationally ready, and we have done this through a series of comprehensive internal testing, carrier-to-carrier testing, and in most cases commercial use, which in the last month or two has increased dramatically. And we believe all of that demonstrates that the CLECs have reasonable assurance of obtaining access to the information or functions that's required at the demand level that they need. That leads me to the third thing that we have done. We are very conscious of the fact that our interfaces have to be sized to meet the anticipated demand. And we have an internal policy and numerous procedures to forecast anticipated demand, and our position is that we have our -- that our OSSs at any given time have adequate capacity to meet current demand, plus forecasted demand for a six-month period, and we have implemented a process that enables us on an ongoing basis to project demand and stay basically six months ahead of the curve. The final thing that we have done is implement a series of OSSs measurements and reports to track our performance, and basically we measure three things: cycle time or response time; reliability or accuracy of the information provided; and availability of the overall system itself. Most of our major interconnection agreements cover these performance measurements in the contract, and we are clearly committed to tracking and reporting these things on an ongoing basis. So basically the for things we have done to implement our requirement, we have published the specs. We have ensured that the specs are operational. We have adequate capacity, and we track our performance. Thank you. MR. WELCH: Thank you, John. Next, we will hear from Commissioner Vince Majkowski from Colorado. Commissioner? COMMISSIONER MAJKOWSKI: Thank you, Richard. Before I begin, I have got to give the typical disclaimer. The views that I am about to express are my views and do not represent that of the Colorado Commission. This subject has been very, very fascinating, from the information as to electronic interface versus manual interface. I want to begin by saying since 1995, exactly the 24th of May 1995, Governor Rohmer signed into law House Bill 1335, which directed the Colorado Public Utilities Commission to open up the local loop to competition by 1 July 1996. Up until now we have been in the process of doing that, and also, based upon the 8 February signing of the Telecommunications Act, those items and federal direction as it relates to both interconnection and unbundling of network elements and resale. We have proceeded, since we only have three minutes, to go into a number of hearings. We have put out interconnection rules on unbundled elements loops, rules relating to resale. What we didn't anticipate from a regulatory point of view was the complexity of operating support systems. I want to just quickly show one chart, and I was told not to, but I think it will add to my comments. Well, I won't. I guess they moved that. Well, that's funny when you are sitting here. The points that we have had during our hearings is naturally we by our current rules support nondiscriminatory access to unbundled network elements which include the Operating Support Systems. The problems that we have faced during our hearings and through the workshops that we have had is how far does this go today based upon the technologies, and how much and who pays for what parts of this automation to ensure that there is this transparency for pre-ordering, ordering, maintenance and repair, as well as billing procedures. The discussions that we have had within our Commission have evolved around these particular points. There is also, we have found, a misunderstanding upon both parties, the CLECs as well as the ILEC. And in our case that's US West, and I know there will be a later panel in which US West will speak. But what I want to point out is the system that we have available today is similar to what was discussed, a PC with a Web browser interface that allows the CLECs to get into the provisioning of -- the pre-ordering functions of the existing ILEC, in our case, US West. They can go in there, they can get that information. However, when it comes to ordering, maintenance and repair and billing, these issues will require manual interfaces, and that also I should point out, has to do with the pre-ordering. As long as the order is filed correctly and the information is correct, then it can be done -- that information can be provided electronically. But as far as the other interfaces, it's manual. It's manual today, and we have been discussing with the incumbent as to the time lines that they feel they will be able to modify those software applications to allow this electronic interface. We are looking at possibly a year from this past month. Also, when we deal in the realities of what is the impact, to date, as of Thursday of last week, the competitive local access providers process within the State of Colorado five orders. Throughout US West's territory, we have no more than 200. So we are in what I view as a learning process. We support the automated interface. We want to see transparency from a state commission point of view. We are moving both the incumbent toward that goal, but we are also trying to identify from the competitive local access providers what are the exact requirements. And then naturally when you talk just and reasonable, who pays for these modifications to these softwares. A final note, we are proponents of national standards, our Commission, and with that I look forward to the question and answer period. Thank you very much. MR. WELCH: Thank you, Commissioner. Finally, we have two representatives from the Executive Branch of the government, and first we will start with Katheryn Brown from NTIA. Katheryn? MS. BROWN: Thank you, Richard. Thank you for the invitation to be here. NTIA, as you know, on behalf of the administration has consistently advocated practices and policies for robust competition in all of our markets. Our vision is that consumers will have choice limited only by the constraints of the market to a vast array of telecommunication services from multiple competitors. Significant process has been made over these last 18 months to set the rules of the road, but without operating systems in place that actually accomplish the kind of interconnection contemplated by the Act, consumers will lose, competitors will use, and I think incumbent companies will lose as their customers become impatient with the market's inability to deliver the services they want. I offer three observations today which I think perhaps form a framework for the way we ought to look at this from a policy point of view. First, the mark of real competition is that consumers are able to change their providers with minimal effort. This means that consumers can choose a new provider with no delay, or minimal delay, with no loss of service, with no loss of billing, and with minimal confusion. And I would suggest to the industry that these standards should be set by the marketplace, by the consumer, and not decided amongst and between folks in a room who think that's what consumers want. There is a vast array of consumer literature that talks about what consumers expect in a competitive marketplace, and I think it's well that all of us take a look at that. And when we are thinking about the standards we need to meet think about what the consumer standard is. Secondly, optimally the relationship between the carriers should be a contractual one. We have to move gradually away from a regulatory prescriptive approach to a contractual approach. These contracts are supply contracts, and our effort should be to ensure that we create an environment that mirrors the commercial environment that any other supply contract looks like. This we need to do with all three kinds of interconnection that are contemplated by the Act. There should be contract language that covers not only the service that is being provided -- my fear is that is much too narrow a focus. We know that there should be nondiscriminatory access to all elements. That's taken for granted. What we need is a contract that covers the relationship of the parties. This should include performance standards. What do the parties expect of each other? And what clearly are the performance standards that one would expect under the contract? There should be service quality standards included, and there should be clear enforceable -- a provision for enforceability of the contract. Commercial entities have found a way to resolve their own conflicts, and have placed value on the loss of time, the loss of service that occurs when the contract is not fulfilled. These should be part of the contracts between the carriers and parties who are then serving consumers. What then, three, is the role of government. The role of government right now is to ensure that the incentives are in place for the parties to reach contractual agreement expeditiously, and to be able to deliver to consumers the promise of this Act. There are a number of things on the record right now, it seems to me, that are incentives for this kind of behavior. First, it is entirely reasonable, in my view, that state and federal regulators would require an interconnection agreement to include the kinds of elements that I just described. Without them the agreement doesn't work. Secondly, it is entirely reasonable, in my view, for regulators to think about these kind of agreements with respect to all kinds of interconnection, whether it be a resale kind of relationship or an unbundled element kind of relationship. It's reasonable also to conclude that the operating systems need to be, if not detailed in the contractual language, at least contemplated and that some process for determining what those systems are and what the parties can agree on is in the contract with some date certain. NTIA has suggested that in the access charge regime that the marketplace approach works only if there is a market, and we have suggested that if these operating systems are not up and not reasonable, that the Commission should go back and look at access charge levels. Inter-ladder, it seems to me, becomes open then to the LECs once these systems are in place, and the market is in fact operating and customers have a choice. We further know that pricing flexibility is a available or should be available once there is a competitive marketplace. These incentives are already in place under the Act and should be embraced by regulators, both on the federal and state level, to ensure that the parties agree to a win/win situation so that they can do business together. Where those incentives are not apparent it seems to me we need further discussion as to what the proper incentives are to induce the parties to act reasonably and in accordance with the Act. Bottom line, however, the law requires, requires interconnection, and puts a duty on carriers to ensure that the systems are open. If the parties cannot agree in a reasonable amount of time to the kinds of systems necessary to ensure that consumers have real choice, then it is incumbent upon the state and federal regulators to step in. It is my view, however, that we will be better off if the industry itself can come to consensus, and if the environment is set properly so that it ends up a win/win for the industry and a win for consumer. Thank you. MR. WELCH: Thank you, Katheryn. And, finally, Don Russell, from the Department of Justice. MR. RUSSELL: Thank you, Richard. Since I am the last speaker, I will try to maybe sum up a couple of themes that I have heard through all of these opening comments by the other panelists, and also make a third point, which I think is implicit in what a lot of people are saying. The first theme which I think comes through loud and clear is that consumers in this country want and demand very high quality competitively priced telephone service and they won't tolerate anything less. And in order to get that from the new competitors that are coming into the marketplace, those competitors will have to have high quality, workable access to the electronic systems of the incumbents, and have workable interfaces to coordinate their activities and the activities of the incumbents that they are working with. It is absolutely clear that competition is to work on a significant scale, these interfaces have to be fully developed and working, and they have to work right, and they have to be affordable to all, and the consumers of this country simply won't tolerate anything less than that. The second issue that I think is apparently from almost all the remarks we have heard this morning is the complexity of accomplishing this. The systems that are in place now are systems that were developed over many years time by the incumbents. They were developed with very large investments over many, many years by the incumbents. They work extremely well for the incumbents' own purposes, but it's going to be very difficult and costly and time consuming, to some extent, to make those systems available to the new competitors that are entering the marketplace and to make sure that adequate interfaces are developed and implemented to deal with the new competitive environment. I think those two themes we have heard from all different perspectives this morning. There is a third implication, I think, that comes out of that, which is that we should be thinking about these issues not as simply a one time issue, or a yes or a no issue, but more as an ongoing process that the industry will be going through. I don't think the law requires absolute perfection in terms of the interfaces that are developed. I don't think that's possible in this world. On the other hand, I think it's important for everybody to realize that the law also probably is not ever going to reach the point where it says you have done enough if you are the incumbent or if you are the competitor, and you don't have to do anything more. The networks that are involved here, the interfaces between the companies are complicated today, but they will continue to evolve over a long period of time. The kinds of business dealings between the new entrants and the incumbents will change over time. The technology will change over time, and the consumer demands in the marketplace will be changing as well. And I think what that means is that in dealing with OSS issues, in dealing with the interfaces between incumbents and the new entrants that are competing against them, there will have to be a continuing process by which these issues are worked out, either with or without oversight by the FCC, with or without private contractual arrangements through the industry standard-setting bodies that we have heard from. But one way or another this process is going to continue for quite a long time, and I think we will have to continue to strive to making these systems work. There has been, from our perspective, a tremendous amount of progress that has been made over the last year or so under the Telecommunications Act. There is also, I think in many ways a tremendous road ahead of us, a long way to go. MR. WELCH: Thank you, Don. Okay, now, we will move into the next phase, which is some questions and answers, and hopefully we will generate some wild debate among the panelists. I want to thank everybody for keeping their remarks brief. We are staying remarkably on time here. The first area that we wanted to explore is the role of government, the federal government in particular, in this area of OSS. And Katheryn stole my thunder a little bit with my first question. She has offered some views on how she thinks this would develop. So I'm going to ask her a couple more specific questions along those lines, and then maybe we can hear from some of the other panelists on the proper role of the federal government and the FCC specifically. Katheryn, you mentioned that basically the position of NTIA is that consumer demand should drive this process to the extent possible. The first question is how do we as regulators or people in the federal government know what that demand is? Is there a role for the government to be setting technical standards for these types of systems now? And should the government be setting any type of performance standards now, at least until competition develops? That is sort of three questions there all at once. MS. BROWN: Well, I should allow the industry to talk about it because what I just suggested was that the industry ought to step up to this issue, and ought to say what is required for its customers. I think that there is information out there. We in the regulatory field when I was in New York clearly had a lot of information about what customers demanded with respect to their company. Delay times, we knew what billing was required, we knew what customers wanted with respect to customer services, we knew what they wanted with respect to technical service. We know what customers want. And I believe the companies know what customers want. And I think we have to work from that point backwards. Do we need technical standards? Absolutely. Do we need standards, bodies to start talking about what they are? Absolutely. But we need performance standards that talk about outcomes, and that, in my view, should be what the companies together are negotiating. And my point is that government should be there to ensure that the negotiate those standards. They each and both have high need to push as far as they both can go. And the best solution will be one that they both can live with that will deliver to customers. The trick, however, is when it is as complicated as this chart that the Commissioner wanted to show but wasn't able to show, is who can decide all of those individual details. And it seems to me that the parties are in the best place to make those decisions, but they have to do so expeditiously, and regulators have to demand that it be done and done thoroughly. MR. WELCH: You mentioned the preference is to ensure that incentives are in place to get these into the contractual arrangements, and the states in the first instance are at the front line in working through the negotiated contracts and the arbitrations. And so I think it would be useful to hear from the Commissioner about how you are dealing with this in Colorado, and specifically, and maybe more generally, in the states. COMMISSIONER MAJKOWSKI: As I started my comments off, we have been working this issue since '95, before the Telecommunications Act. And the way we tried to approach this and I will bring it up to the complexity issue that I talked about in our not understanding that as it relates to OSS. But when we started out to open up the local loop to competition, we tried to touch on the easiest issues first, so we touched on what we felt was local numbering portability, E-911 access. Then we went into certification of new entrants, transfer of those certifications cause they meant money, and then what happens if someone wants to abandon, who maintains responsibility for keeping the customer connected to the public switch network. From there we moved on to interconnection resale, unbundling, unbundling elements, and the Colorado High Cost Fund. With the Act as it came down, we were trying to get the parties working together, all parties -- wireline, wireless, competitive local access providers as well as the CABS -- into the ball game so that we could get this mutually agreed upon consensus building as to how we would have -- what rules within the State of Colorado would allow competition to take place on the first of July. It also involved rates, and as specified, in Colorado we had, in '96, House Bill 1010, which directed us to put in rates in being. We did that by 1 July '96. US West put the tariffs in. Everything was in place except for the fact that the incentives that Ms. Brown talks about still weren't there. We went through the arbitration interconnection agreements. We laid out standards. We laid out performance. We had to pull the standards and performance out of the interconnection agreements and address those separately because we couldn't get consensus on the part of the parties. To which after awhile it became where -- in fact, in the case of AT&T and MCI and US West, where we did a ballpark to use your beginning comments, and picked and choose between the interconnection agreements as it relates to the entire programs, as well as quality of service. You need quality of service standards. You need performance standards. You need to have within those contracts, which I agree with, which are arbitrated interconnection agreements, the ability to have the parties go to court. The Colorado Commission did not want to be part of that ball game. We wanted to be outside of it. In fact, we started out with the arbitration of the interconnection agreements. We told the parties that we would prefer that they negotiate those agreements prior to coming to us. But should they do that we will meet the requirements of the law and finalize them, and we have done that. So I agree with the liability question, or the enforcement question, but when it comes to the OSS the reason why we didn't anticipate that was because of how do you look at this complex thing of operating support systems, and you have system management systems, and you had third party data systems. All of these issues you had to have open to the competitor so that they could compete, have access to that information. You want it on a real time basis. It's not there today, and it needs to be worked. And that's where, in regards to the national standards, my thoughts and comments would be you have got various RBOCs using the Legacy, Bell Corps. loose end structure of their operating systems, and they have evolved with proprietary information and networks in those systems which each one of them has. And so if you are going to do this on a national scale and you're going to have competitive local access providers be able to complete on a national scale, they shouldn't have to do it seven different times. That's it. MR. WELCH: Maybe we could hear from the incumbents here for a second on this issue of incentives and the proper role of government in terms of performance and technical standards. John, do you have any thoughts on that? MR. LENAHAN: Sure. I think there is probably one thing that Ameritech and LCI and MCI have in common, probably a couple more than one things. But one thing that we have in common is we both want to serve our customer and make the customer happy. And the key to performance and incentives, what I would call post-entry incentives, is that there is a mechanism to measure the performance we are providing to CLEC and compare it to the performance we provide to our customers, because at the bottom line that's going to be, I think, the most relevant measure as to whether or not the CLEC is getting nondiscriminatory service. So I think there is a role for some minimum levels of service quality that the government or the state or federal regulators can help, but the real, I think, relevant measure of performance is a parity measurement which compares the CLEC and the ILEC on an apple to apple basis if that's possible. So, in my opinion, the contracts that the government needs to approve, the state commissions need to approve, the most productive role for government in that case is to ensure that the contracts have adequate performance measurements, and adequate performance reporting obligations so that the parties can determine whether they believe they are getting nondiscriminatory service relative to the ILEC retail business and relative to the service the ILEC is providing other competitive carriers. MR. WELCH: Maybe we could hear from a couple of new entrants. What has been the experience thus far in actually negotiating and arbitrating these contracts in terms of getting these types of performance or technical standards actually written into these contractual agreements? Don, do you have any thoughts on that? MR. LYNCH: I have got a number of things I would like to respond do. First off, I think a good start is starting with the contracts. Clearly, we would like to have an environment where you have commercial negotiations between the parties to come up with a contract that's good for both parties, both the incumbent as with the new entrant. The fundamental problem you have you're starting off with a monopoly company and trying to have negotiations with, which basically says if you don't want it this way, you don't need to do it at all. And then from three you may get to a commission, and a commission then has to try and to split the baby and you end up not in a commercial environment that you would normally like. That also flows over in terms of setting the standards. In every agreement that MCI has been trying to get -- by the way, I am the guy who is supposed to get them -- in every agreement that we have been trying to get we have consistently asked for standards of performance from which we can measure the incumbent and the incumbent's ability to provide services to us in which we in turn can serve our customers. In most cases those performance standards have been extremely difficult to negotiate. When they have been arbitrated, they end up in state -- the state forums. They get ordered down to the point that they are meaningless. The last -- the further comment is that some folks here have suggested that we want to maintain parity with the RBOC. Clearly, that's the case. We want parity. But that's not necessarily good in all cases. In some RBOC territories they have been fined recently for not providing service to their own customers, and we certainly don't want our local customers to be subject to that types of problems. So to start off with, ideally in a commercial world, absolutely you want those kinds of terms and conditions in the agreement. From a practical standpoint given our starting point, it's near to impossible to actually happen. To take a step further in terms of the systems. For an incumbent, or rather, a new entrant trying to get into the business right now each of the RBOCs have come at this issue in somewhat of a different way. We have talked about GUI interfaces with PCs. That does not -- that cannot operate in a robust telecommunications market. All we need to do is take a look in the long distance market and see the robustness of it. We have millions of customers that decide that they want to change long distance carriers, and that happens in some cases or most cases less than 24 hours. Here, today, in the local market, it takes multiplies of days and sometimes weeks to get our transactions through. So we have enough standards sitting out there in terms of a free competitive market, whether it be in the long distance, and by the way, that also goes through the maintenance systems, it goes through the billing systems. You have a model out there, and that's one of the things that I would think that we need to replicate. At this point in time I don't think we want any federal or any -- any regulatory body coming in and setting the standard per se. However, I would also say that I think the FCC and the state regulators have a stake in this as well as we do, and what I would mean by that is certainly helping us along the way, similarly to what was done in implementing 800 portability, in terms of an ongoing involvement, making certain that people were focused on the end result, and using good offices to push this process along, I think, can become very, very helpful with that. Anne, I am sure you have got something to say. MS. BINGAMAN: Yes, I do. First, as to the comments of Ameritech about parity being the goal, I endorse that wholeheartedly. Let me echo Don's point that we are dealing here with entrenched incumbents who have it all. Now, Ameritech today, I think, would have people in the audience agree more incentive than most to be cooperative, to help, to do everything they could to get this thing on the road. And let me just tell you what's actually happening out there. Our bills are three to seven days late, daily usage feeds. Our monthly usage feeds are anywhere from a month to two weeks late. They are improving slowly. What this means is it is not close to parity. They get theirs within 24 hours. We get our three to seven days or a month late, and you're billing an installation. The customer doesn't know why, they have no idea. They think we are incompetent. We don't have the bills. That's number one. Number two, a simple thing, although it is hellaciously complicated but simple to cure, but Ameritech has met with basic indifference to our pleas to for God's sake help us with USOC codes. Now, let me just tell you what UOSC codes are. They are basically Greek. They are strings of letters, and I brought some here for you just to give you guys a little bit -- this is one page of one customer order, and these are USOC codes, and the read, "NALSA/DAD /6TLI/." If you miss one letter in this entire page, your order is rejected. These things are crucially important. USOC codes were invented by Bell Corps. There are 10,000 of them. They differ for residential and business consumers. PacBell will not give us USOC codes. Ameritech, which wants parity, we have begged them to give us the same USOC codes they have. For awhile they had them on a Web. They took down the Web site for a month. They don't give us the changes. We are in a world of hurt here, folks, on a basic thing about how do you order this. This is complicated stuff, and there is no English language conversion to it. Let me give you another real simple example. Free form customer service records come from Ameritech and every other RBOC electronically. Well, now, that sounds good. It's electronic. Well, you know what free form is as opposed to fixed format. Fixed format is what they use for themselves in billing. It's in fields. You know, computer fields so that this field has this bit of information, the next field has that bit. It's readable by your own computer. You can write a routine. A free form customer service record, which is the number one thing you need to find out what this customer we're trying to sell to have and what is it. It comes in this blop of lines, 80 lines on a page free form. We have to write sophisticated parsing routines to try to figure out, okay, is this the part of this that's the order. Is it somewhere else in this line? And it's -- by the way, CSRs differ by region in Ameritech. Their CSRs aren't uniform. You know, parity is great, and I am all for parity, but we have been begging them for six months to help us with this USOC thing, to give us fixed field, fixed format. We are nowhere. And I am not trying to touch every single problem here, but I am trying to say to you dealing with an incumbent monopolist who has it all in complex computer systems, when you are struggling to get into business and you are trying desperately to just sell the line and not be in lawsuits is tough. Let me give you a second example. Bell Atlantic, we have no deal today with Bell Atlantic. You know why? I have been telling them since February we want to get in Bell Atlantic. It's the second biggest region for us. We are crazy to get there. I have written Jim Young. I have begged him. He said, "No problem." Okay, it's comes down to this. We got a deal on the simple resale and Bell South, to their credit, we did this in six hours with them; with Bell Atlantic, three months of negotiating a simple resale contract. Okay, we are down to they want confidentiality on all performance standards. They want me to have to ask their permission to give the FCC or the DOJ my views on performance standards so that they can then seek a confidentiality order and put it under seal. Well, now, what does that do the agencies, you know, who are passing on the adequacy of their performance? It leaves you in a box. You are blinded. I have refused to sign that. I have offered to sign the contract subject to my right to challenge that, and I haven't heard back from them. So this idea that Kathy Brown, who his a dear friend and I respect her greatly, but the theory that we can negotiate in a normal business setting with monopolists when we are facing desperate need to get in business and sell, the imperatives of that, plus the huge size of them versus you, plus the relative importance of these things, what happens is it just doesn't work. This is not a normal commercial setting. And I just -- to pretend, to pretend it is and to pretend that this is just too business people trying to do business, let's face facts here. These people have a monopoly. They are business people. They want to hang onto it. I don't blame them. That's the nature of the world. You know, that's the thing you are dealing with. We are trying to get in and we want to get business. Their incentive is not to make it easy for us to take their customers. Their incentive is to do as little as possible to get past the hurtles which will get them into long distance, and then, you know, we will see where we are. The reason performance standards are so crucial to be set by government is because we have heard the gentleman from Colorado. You are aware of the Wisconsin staff, long hearings on OSS, and a staff order denying Ameritech's application. Illinois, the same. New York had a technical conference on NYNEX. NYNEX agreed they had problems. Georgia PSC found OSS problems. What is going on right now in the states is what I really call a fire storm that is raging out there as people struggle to grapple with these incredibly complex issues for the first time. And you have staffs in state commissions who are doing a conscientious job working at it, but they need help. I mean, I think the commissioner from Colorado said it exactly, and that would be my view too. The industry needs help from the FCC. Contract negotiations will not do it. MR. WELCH: There has been a lot of talk about parity. Let's explore the standards of parity and nondiscrimination a little bit more. And, Don, I am ultimately going to throw this question at you, so heads up. John Lenahan in his opening remarks set out the legal standards in the interconnection order, and just to refresh everybody's memory, they were nondiscrimination which the order described -- defined as being at least in equal in quality to that which an incumbent provides itself, its affiliates or its customers. And then there was further elaboration on the meaning of "just" and "reasonable terms and conditions." The Commission's orders defined that as providing an efficient competitor with a meaningful opportunity to compete. And then the order also stated that incumbent LECs may have to modify their existing systems in order to meet the nondiscrimination and just and reasonable terms and conditions. Don, how should those standards which were in the order be applied to a particular incumbent LEC efforts today or on an ongoing basis to determine whether they are in compliance with 251? And what, in practical terms, should be important in determining whether incumbents are in compliance with their statutory obligations in terms of things such as testing, or capacity, or actual usage. And maybe after you comment on that we can get some reaction from some other folks on the panel. MR. RUSSELL: Well, on the first question that you asked, you know, I think many people this morning have talked about parity, really, I think, focusing on the first part of the FCC's requirement, but I haven't heard any references until you mentioned it to the second part of that, which is providing an efficient competitor with the meaningful opportunity to compete. And I think this is a very important piece of that requirement. It's particularly important when you are dealing with unbundled network elements or with other facilities or services that are being provided to competitors for the first time, and which the incumbents do not provide to their affiliates or to their own retail customers. And because of that fact, of course, it's impossible to have a direct apples to apples comparison. You don't have a baseline to say, well, the incumbent provides unbundled loops to its own operations in a day and a half, since they don't provide them bundled loops at all. And that's why I think the second piece of this definition, providing a meaningful opportunity to compete to an efficient competitor, is critically important here, and I think it goes back to the concepts that several people have expressed already. You really have to look to what it is the customers want, the end users want, what really matters in the marketplace, and judge whether the new entrants are getting sufficient access in order to meet that standard. What are some of the practical issues that you have in looking at this? Well, one thing that I think almost everybody would agree with is that the interfaces that we are talking about will have many, many problems in them up until the point where you have actually gone through extensive internal testing by the incumbent, carrier-to-carrier testing, and some degree of actual commercial use. These are very complex system. You can't expect them to be perfect on the drawing board, and you have virtual -- a virtual guarantee that there will be problems of some kind, whether they are large or small, whether they are many or few. There will certainly be imperfections when these systems are first designed. And from our standpoint, I think there is sort of a hierarchy of what is the best demonstration of parity and operability. At a minimum, I think you need very extensive internal testing. Better than the internal testing is the carrier-to-carrier testing, and best of all, of course, is some actual commercial usage so that you can see how it operates in the real world. MR. WELCH: Don, did you have something that you wanted to add there? MR. LYNCH: Yes. A number of comments have said we need to develop what the customer wants. Well, I can tell you what -- I'm not quite sure what the customer wants, but I can tell you what they don't want. They don't want a new entrant who goes into the market and they choose, for example, MCI, in that transition to have their service disconnected for a few days. They don't want to have multiple bills show up at their door step, one from MCI and one from the local incumbent. If they have things like call waiting and et cetera, they want that service, and they don't want it disconnected. So I think we have a fairly good understanding as a new entrant into the market. We must be able to provide similar service at a level in some cases better than the incumbent because remember we are trying to break into this market. So I think we have got a fairly good idea of what the customer really wants, and that's service from end to end. Now, in terms of what we are discussing today, remember, most of the discussion has been centered on things like resale, at least to this point in time that has been thought of as the creme de la creme. Well, from a new competitor, a new entrant's view, resale is not competition, because if you think about it for a minute, how can there be competition if the incumbent is not at any real economic risk. What we need to get to is things like unbundled loops and things like platform. And then sitting behind those, remember we have got all the other systems that need to be discussed relative to the billing, relative to maintenance. Nowhere have we discussed maintenance today in terms of an MCI has now garnered a local customer and their service breaks. They call MCI and say to us, "It's broken." Somehow we need to get to the incumbent LEC in a very efficient manner that says, "The service is broken. When is it going to get fixed?" You as consumers I think would expect that. So this issue again is much further than simply resale. It's all the various OSS systems that have to come into interplay to make it work. And again, from a customer view it's real simple. They want a service that works, and right now, frankly, it's not working. Thank you. MR. WELCH: I want to direct sort of a follow-up question to Kevin Snyder and John Lenahan about this. If they could elaborate in a little more detail what they are doing internally in their companies to ensure that in fact they are providing parity in the case of services or functions that you actually provide to yourself or to your affiliates. And in those situations, such as unbundled network elements where you probably have not been providing that to yourself, what steps do you take in order to provide new entrants a meaningful opportunity to compete? How do you measure these types of things internally? What sort of procedures do you put in place to ensure this happens? Kevin? MR. SNYDER: Yes. One of the things we have done is to develop new reporting systems which will allow us to actually measure these things. Many, as you've mentioned, are new to the business. In California, in particular, in our contract with AT&T there, we were successful in negotiating measures of quality into that contract who show direct comparisons of our performance at the retail level against the performance given to AT&T and their customers on the wholesale side of the business. So those are some of the things that we are doing. MR. WELCH: John? MR. LENAHAN: We have also negotiated performance standards in our major interconnection agreements. And, for example, with respect to unbundled loops, which we have provided thousands and thousands, over 20,000 unbundled loops throughout the region, since we don't provide unbundled loops to ourself, our contracts have a standard interval for installation of typically five days, and a commitment that either 90 or 80 percent of the orders that we receive that request the five days have to be met. MR. WELCH: So that is a contractual obligation? MR. LENAHAN: That is a contractual obligation with liquidated damages for breach in most cases, and, of course, the carrier can enforce the contract in a court or file a complaint with the Commission or the state commission. In terms of parity, just focusing on unbundled loops, because for resale we do have pretty good parity measurements because resale, we have a retail track record that we compare our wholesale track record to in terms of installation, timeliness, due dates, MAT -- I mean, time to repair, trouble reports. Unbundled loops, we have agreed with some of the CLECs that are truly facility-based providers, Brooks and CCI, in particular, that we will compare our installation and our repair on what we call Code 3 and 4s, which is a facility visit that requires work in the feeder or the distribution as being most comparable to the type of installation work associated with an unbundled loop. So we have agreed to that. We have also agreed to, where the carriers wants, especially in the case of the smaller carriers that only serve a portion of a state, to give them geographic performance so that -- and in the case of Brooks, we break out our Ameritech Michigan performance in the Grand Rapids area, which pretty much dovetails Brooks service area. So to answer your question in terms of parity for the unbundled loops, we have come up with a close comparison to our retail operation, and we have -- where the CLEC doesn't operate state-wide, agreed to a geographic split. MR. WELCH: Okay. I wanted to explore a slightly different issue now, and that is the issue of capacity and scaleability, which is a word that you hear throwing around a lot. Obviously, a lot of these systems are just getting up and running. Competition is just beginning to develop, and not a lot of customers have switched yet. But the plan under the Act, and what everybody is striving for here is that this will pick up and accelerate. And as this acceleration takes place, and new competitors are coming to incumbents and asking for more and more loops or more and more resale of services, how can we ensure that these systems are able to meet this increased demand, this acceleration? So what I would like to do is ask some questions of the incumbents first, and then perhaps some of the new entrants about how to address this issue. John, why don't we start with you. What -- you have actually mentioned this a little bit in your opening remarks, so maybe you could elaborate on it a little bit. What factors at Ameritech do you base your plans for scaleability and capacity on? You know, do you look at demand, forecasts that are provided to you from new entrants? Are these internal predictions that Ameritech develops themselves? Do they come in any respect from state commission regulation or direction? What percentage of these predicted levels of activity have you built your systems to accommodate? How do you go about this internally trying to predict the future and make sure that your systems will continue to grow and be able to meet the demands of the future? MR. LENAHAN: Okay, why don't I address the -- basically, we have -- we have addressed capacity in two ways. The first way is from a system's point of view. We have put into place an interface that is scaleable and that can be increased as the demand warrants it. And we have outsourced that particular IT processing to IBM, and they have, I think everyone would agree, sufficient supply to meet projected demand. So from a hardware point of view, and these are basically mini-computers. They are fairly easy to supplement where we need new gas, or where there is more gas in the pipeline. The procedure for projecting what the demand will be essentially is a combination of our internal estimates based on actual use, and we, like any other business, trend what we provide, and so we trend what we are providing to the CLECs, both unbundled network elements and resale. But more important, for the longest time we have sent letters to each of the competitive carriers that have interfaced with us or indicated an interest to interface with our OSS, and asked them to provide us with a six-month rolling demand forecast. Once a month we ask them to give us what is your demand for the next six months. In some cases, we have -- I will tell you -- in most cases in the beginning we got a "go pound sand" type of a response, "It's none of your business what our capacity or projected demand is going to be." We have negotiated into our major agreements a contractual obligation for the CLEC to provide us with capacity forecast, and they have started to do that. So we take that demand forecast, compare it to what we actually are seeing in the business, and on an ongoing basis determine whether or not, based on that projected demand we have adequate capacity internally. We have since we started doing this increased capacity to meet our internal standard of being six months ahead of projected demand. In addition, as the filings that we have made before the Commission and state commissions, we retained a IT firm to take a look at our entire OSS interfaces, and, in particular, we asked them to focus on our ability to meet the capacity that we forecast. So it's an ongoing process of evaluating what we see, asking carriers to provide us with their own projection, and then communicating that to the hardware suppliers essentially. MR. WELCH: So if I understood you correctly, John, you said in a number of your agreements there is actually a contractual obligation on the competing provider to provide you with demand forecasts? MR. LENAHAN: Right. MR. WELCH: Kevin, how - I'm sorry. Go ahead. MR. LENAHAN: Which is pretty -- I mean, in a commercial setting the supplier has an interest in understanding how much is going to be required, and the purchaser should have a complementary interest in making sure that their forecasted needs are known to the supplier so there is no gap in supply. So we, you know, haven't found it to be universally though agreed upon with the CLECs that they intend to share forecast demand. But in those cases where we have a contract obligation the obligation is being met. MR. WELCH: Kevin, how are you doing at GTE to grapple with this issue about projecting demand in the future and making sure you have scaleability in your system? MR. SNYDER: Yes, Richard, similar to Ameritech most of our contract with the CLECs do contain provisions for the CLEC to communicate forecasts to us, and those forecasts come to us through the account managers assigned to those CLECs. I think one of the concerns there has been on the CLEC part that the information will make its way to the retail side of the ILEC business, and we have been very careful to avoid that, and we sign confidentiality agreements and do a lot of things to prevent that. We also do internal forecasts as well to validate that information, and then we utilize that information to make operational changes in our business. Our systems are scaleable, as Ameritech's are. We also continue to automate many functions so that we get more volume out of those particular systems. And, you know, any system that's developed there is going to be some fall out that occurs in that system, so you have always got human labor and human capital involved. And so we have been very aggressive in terms of trying to stay ahead of the volume, and hiring and training people to handle that volume, building new centers to handle the CLEC orders and things like that. MR. WELCH: And, Anne and Don, I wonder if I could sort of follow up on this same topic of scaleability with you. In your dealings with the incumbent LECs in striking these agreements, are you making specific demands for certain level of capacity in your negotiations, or writing that into the contract? Are you providing the incumbent with demand projections of what you see for yourself in the future? And if you are not providing such sort of forecasts, how do you see the incumbent being able to build for scaleability in the absence of such sort of projections? MR. LYNCH: Well, the first issue in forecasting any kind of demand is a understanding of what are the products and how they are going to be delivered and in what format. Again, go back to the example. Resale, that's a fairly simple thing to do. However, in dealing with unbundled elements and network platform, that's a far more complex thing to do. So I guess we are kind of in a situation in some cases which comes first, the chicken or the egg. I can't tell you what I am going to sell until I know I have a process in place that can handle huge volume, and I think I would speak for ATT and MCI, or LCI, for that matter. We expect to sell a lot. But, again, until we understand how the system sits behind it and how we can process, I am very reticent to give them volume commitments. A good example of what perhaps we are dealing with is unbundled loops. And again in Ameritech's case unbundled loops are delivered by an ASR, which is a non-standard process versus what the first discussion point was. So there is a non-standard process there that makes it more confusing. For a new entrant now, we get to go to -- including GET -- eight embedded carriers. And if we have a little bit different process or a non-standard process in each case, it makes our life a heck of a lot more complex. The other things concerning here in terms of scaleability and volumes is how much is it a manual process. Again, it was commented earlier. We know that in a lot of cases we may be transmitting orders to an embedded LEC, and then for some reason those orders will fall out because of an error, and then you have got rooms full of thousands of people trying to correct those errors. This is not a through system that's in place right now. We need to have a system that's in, that has all the edits in it to prevent these manual problems falling out, and that's part of the capacity issue, as well. And, frankly, I think that from a new entrant side, I think that we're scared to death that the embedded LECs can't deal with the kinds of volumes we are talking about. Clearly, PacBell is a clear example. In PacBell, MCI has about 20,000 orders. We have got a backlog now out there of a couple thousand orders, and we stopped selling a couple months ago. And so the issue that we have, again, is sort of which comes first, the chicken or the egg, is that can a new entrant turn up the sales pressure only to be disappointed. Again, we feel as though we are going to have one shot at the market. And again, out of the box, if we can't deliver what the customer wants with relatively little risk of being able to deliver it, we are going to be in trouble. So, Anne? MR. WELCH: Anne, how is LCI handing this in terms of demand forecasts and working with incumbent on scaleability? MS. BINGAMAN: We have no problem giving people demand forecasts. We are obviously much smaller than AT&T and MCI. We do have substantial residential customers, well over 1.5 million, whom we would like to serve. Many of them, they are nationwide actually. We have got them in all states of the union. We are not offering residential resale at this point because -- for the same reason MCI said. We are terribly concerned. It would destroy that end of our long distance business if there were widespread dissatisfaction. People would get the idea we couldn't deliver and it would hurt us badly. So the orders we project are business orders and they are much smaller in numbers. And so on the resale side, the scaleability problems you see, frankly, you can go across the board. PacBell sent out a letter about a month ago saying they would, by second quarter '97, could process 2500 orders a day; by third quarter, some number; by end of fourth quarter '97, five to six thousand orders a day. It was an industry-wide letter and they said make your projections accordingly. So PacBell is not close to being scaled up and they don't really purport to be, although they do have a 271 application filed that's being heard in front of the PUC. So that is the factual situation. PacBell has dropped customers of ours, cut them off. We have a terrible time getting them. They have been understaffed. I think that's been publicly known. They have struggled with it. We have had the statistics I gave you on orders waiting for a due date, and this is not installation, this is orders that we have sent and we're waiting back to hear when they will be installed, and I gave you these numbers. Bell South, we have 93 orders waiting; 45 of them 11 to 15 days. PacBell, we have 21 orders waiting; 14 of them 11 to 15 days or older. Ameritech, 49 waiting; 21 in the one to three day, 22, four to five days. So I think there are -- you can see scaleability problems. This is not installation date. This is simply waiting to tell you when you will get an installation date so you can tell the customer. Scaleability on the UNE side of things is far more important and really in a desperate situation. This needs the Commission's action. The Commission has put all its eggs in the UNE unbundled platform -- UNE combined network platform basket. I really think that's fair to say, and I don't have a problem with that. In fact, I applaud the Commission's policy, theoretical and practical considerations in doing that. But the Commission should be aware when you're talking about scaleability in the UNE world, which is the way we are to avoid access charges, put yourself in the shoes of LCI. We are a $1.1 billion company. Clearly, the access charge order says either get facilities based or go to UNE. We cannot put in several hundred switches around the country overnight. Even you couldn't order them. UNEs have to work for us, and they have to work in a scaleable way. We are the first test customer with NYNEX ongoing in a very slow test. It is not remotely scaleable. And you should ask the other people up here, and ask NYNEX who else they are testing this with. Ameritech, we were told -- I was told Thursday they can't conduct more than one test at a time because they don't have the people to do it. There is no, no, no scaleability on the UNE side, and I think, to me, that is as a policy matter, as a practical money matter, we have no way to avoid access charges without UNEs. We will be competing against competitors who don't pay access charges for originating and possibly terminating in region. Our only way to avoid it is to step in and we can't do it right now. MR. WELCH: Don Russell, is this something that the Department of Justice has given some thought to? What is your perspective on the issue of projecting demand and scaleability? MR. RUSSELL: Well, clearly, scaleability is important, and the factor that we look to is really the ability to handle the volumes that are anticipated as the market becomes more and more competitive. We want to see a situation in which the competitor's ability to sign up customers is a function of the quality of the service that they offer, and the price that they offer, and how good they are in the marketplace, and not have a situation where the entrants are constrained because even though customers would like to have their service,the orders can't be processed fast enough. Obviously, in order to have that kind of scaleability, in order to get rid of those constraints, the incumbents need to have a certain amount of information about what the anticipated volumes will be. I think it's reasonable for them to ask those kinds of questions, and I think it's reasonable for the entrants to give them those kind of reasonable demand projections. But at the end of the day what we want to see is to have these systems scaleable so that whatever the marketplace dictates as the outcome is what you see in real life. MR. WELCH: Okay. We have about 15 minute remaining, and it might be appropriate at this point to see if anyone in the audience has some questions that they would like to put to our panelists. We have a portable microphone here, and if you have a question I would ask that you use the microphone, state your name and who you are with. Please try to keep your question as succinct as possible. And if you are directing it to anybody in particular on the panel, please say so. MR. KANE: Good morning. My name is Paul Kane. I am with Teleport Communications Group. The question I have pertains to the distinction between OSS as an unbundled element, and the simple interface between OSS of a CLEC and an incumbent local exchange carrier. The first report defined OSS as a different, a separate unbundled element. Yet the discussion here today seems to focusing mostly on interfaces between CLEC OSS and ILEC OSS, and the implications for cost recovery, et cetera, are very different under those two different definitions. I wonder if each of the panelists could comment on their perspectives on OSS as an unbundled element and OSS as an interface issue. MR. LYNCH: I'm not steeped in the order than perhaps you have. I mean, clearly we are talking about here is the interfaces between companies so we can compete. I did catch one thing though that I found was curious in your question is who pays for this? Well, if you are in a competitive market, which supposedly we are getting to, it would seem to me each company needs to bear its own cost. No one compensates MCI for building systems to get into competition. No on, I think, is going to compensate LCI or Sprint, or ATT for that matter. It's the cost of doing business. So, again, if you start off with the assumption that this is a competitive market or about to be a competitive market, I think the embedded companies need to absorb the cost, as we are on the competitive side in terms of whether it's the unbundled -- if it's an unbundled element or interface, I'm not sure I know the answer to that question. MR. WELCH: Anybody else on the panel want to take a crack at that question? COMMISSIONER MAJKOWSKI: Let me just comment. I don't know if I will answer the question, but I think your point is well taken. It's one of the reasons why I talked about the complexity. The panelists that preceded us and the ones that will follow us are going to cover the pre- ordering provisioning, new service ordering, repair service ordering and billing. In Colorado, what we have tried to do and have viewed those as they are, in fact, unbundled network elements which should be available to the competitive local exchange providers, and it is our intention that it would be an electronic interface. Right along with that, there is a cost associated with being able to provide that. That determine has not yet been made, but it is a question which we believe is deserving of discussion, and have attempted to look into that. From the comments that were made by MCI, there may be a difference of opinion between the ILECs and the CLECs, and that is what a state commission is supposed to take a look at, so we are. But these interface aspects are each considered unbundled network elements, and they should be equal service that the incumbent is providing to itself or anyone of its affiliates. It should be available and provided to the competitive local access providers because that's -- outside of local numbering portability, at least from this commissioner's point of view, if you don't have the telephone number to go with you, and you don't have the ability to provision, to order, to maintain and repair, and to do in fact disaster recover, as well as billing, you are not going to enhance competition, and that's what we are trying to do in Colorado, enhance competition amongst the providers. MR. WELCH: Anyone else on the panel want to respond? MR. SNYDER: I would like to respond. The treatment of OSS as an unbundled element is part of GET's appeal of the order, and I don't intend this morning to discuss the merits of our argument there. But in terms of who supports the costs, clearly we would feel that the people who are going to benefit from competition should bear the cost of that, and not necessarily agree that the incumbent should bear all of their cost. MR. LENAHAN: Cost recovery wasn't really part of the panel, but to the extent OSS is considered a network element, it's pretty clear under the statute that access to a network element is upon request and at cost under the standards in 252(d). So if it is a network element, then the cost recovery issue maybe has been clarified, and it's the requester who pays the cost. MR. WELCH: What -- just to follow up on that, John. What if you make modifications to your network to respond to requests from competitors, but those modifications are also beneficial to your own company. Is there any sort of apportionment of those costs to yourself or should they all go to the new competitor? MR. LENAHAN: Well, with so many state commissioners in the room, and one right next to me, I'm going to pass on that one. (Laughter.) MS. BINGAMAN: I think you've made a real assumption here. We are using the unbundled elements. Therefore, we pay the whole cost. But the whole reason these elements are unbundled is because Section 251 of the Act imposes that as a duty on the incumbent. And in the case of the RBOCs, 271 follows. So it's not as if there is no one legal duty, and, two, advantage in doing this. And I think the assumption that you go through arduous cost proceedings on every elements of OSS, I think is a problem. Let me mention something here. I gave to Neil Cox everything I have said to you today last Thursday in a long letter, so there is no surprises here. I am not coming out of the box with anything that Ameritech did not have in writing from me in a 12-page letter with attachments. I want to state that as a matter of fairness, I mean. Secondly, what he said to me in that same conversation as we were debating somewhat hotly this whole UNE issue, he said, "Well," he says, "UNE is actually not going to be economic because now we have got to completely redo the system under the FCC's access charge order and we are going to have -- it's going to cost a lot more than resale." And I said, "How's that?" He said, "Well," and went into a complicated explanation I cannot tell you I followed. But I should mention -- (Laughter.) It didn't seem worth it. I figured reams of testimony in state commissions all over the Midwest would deal with this at some point, and I didn't need to right then. But I should tell you this cost issue for unbundled elements and OSS is really important, and I don't think the fascial answer that, "Oh, you are using them, therefore it's all your problem," again, finding costs is a difficult thing when you are dealing with an RBOC or GTE. That's the fact. So I think the cost issue is important, and I don't accept the premise that competitors pay for the whole ball of wax. MR. WELCH: Are there any other members of the audience who would like to pose a question to the panelists? If you would please step to the microphone and state your name and ask your question. MR. MARLIN: Dave Marlin, LCI. This is for Mr. Lenahan. On about the weekend of the 16th of this month you all moved in some software, new software that was supposed to enhance the extraction of daily usage files. I was not aware of that update. I'm not sure of any other CLEC that was aware of the update. And the update didn't go well. It delayed the delivery of the daily usage files for several days. Also, it missed some switch files that were later delivered, I think it was over a week later. I am wondering, are we viewed -- you know, I perceive that not as a friendly act. You know, that wasn't friendly at all. I wasn't aware of it. I wasn't included in any of the testing of it. And I am wondering in the area of change management are the CLECs going to be, you know, part of that change management process? MR. LENAHAN: Well, I don't know the facts on the software upgrade. I assume the software upgrade was not intended as hostile act but to improve the processing capability of our systems. And with respect to change management, the intent of change management is to advise the CLECs of changes that will affect their interfaces, or the rules or the business rules that they need to know in order to successfully interface with the company. So I can look into the facts and get back to you. You know, this is the first time I have heard about the software upgrade. But to the extent it was an upgrade that affected your interface, our intent would be to give you advance notice so that you know about it. MR. LYNCH: Can I make a comment -- can I make an associated comment here? I don't know about this particular instance and I really don't care. But I think one of the things that is important here is that up until at least this point in time a number of the RBOCs, as they have designed their systems, have said here is the documentation, all 4,000 pages of it, and sort of take it or you don't. But this is the way it's going to be. One of the things I think that's going to become very important over the next little while is that there is strong cooperation from whether it be the provider of those services and the purchaser of those services, and that really has not been the case to this point in time. We have gone -- NYNEX puts out lots of documentation, and sort of the environment "Like it or lump it." And I think it's important for the embedded LECs to begin to have these discussions that meets our needs as new incumbents, and I suspect a piece of that is going to be dealing with the capacity issues that we spoke about earlier. I think, for example, the comment that the gentleman raised, those are the kinds of dangers that we haves if we don't have this communication going. MR. WELCH: I think we have time for maybe one more question. MR. TERRESKI: I am David Terreski from Associated Communications. I just want to make a point on the cost discussion, and I want you to think for a moment of what occurred about pains for these OSS systems. From the perspective of a new entrant, and who does not yet rate on this size or scale. What we just heard is that there are separate thoughts, and that they want a new entrant to pay for the OSS system, all of which are different. And the differences among them constitute entrance barrier because it is an enormous cost for a new entrant to try to deal with eight different kinds of systems, unbundled elements, on resale and the like. And not only do we have to try to develop our own systems to pay for dealing with them, but they also want us to pay for their development of systems which themselves constitute entry barrier. That really is a problem, and I would encourage that the FCC bear that in mind when they consider any of these cost issues. MR. WELCH: Does anyone on the panel want to respond to that? MR. LYNCH: He is absolutely right. (Laughter.) MS. BINGAMAN: Me too. MR. LYNCH: No, I mean, again, part of the issue here too, again, if we are supposed to be developing into a competitive market here, any competitor or any provider of services in most cases bear their own costs. I mean, again, as in your case, no one is going to pay for MCI to develop systems. There is no trough out there that we can go to. We have to bear that in our margins. And I think, as you outline, it's certainly very reasonable and I think it's something for the FCC to definitely consider. Anne wants to say something. (Laughter.) MS. BINGAMAN: I understand this because -- here is the point. If there were one national interface system, the dream day that we are all working toward that the Commission's order after December said would be useful and would open the market nationally, and it will. There are 200 small members of COMTEL who operate in many different states who have to interface. The desirability of that is obvious. What you would see if you work toward that immediately, and the Commission drove this, it would drive competition because software developers would see a huge market. You would get people in writing software, writing the best software, selling it cheaply. You wouldn't have to go through what we are right now, this torturous, and it's true, eight across different systems that in fact sometimes they change by state. The USOCs change. There is all sort of internal variations as well. So a national system would generate an independent third party vendor group of software that I think itself would drive the price down and really open the market, and you would have real competition because OSS would be widely available at a cheap price. MR. WELCH: Okay. Well, we are just about out of time. I would like to thank your panelists, Ann Bingaman, Don Lynch, Kevin Snyder, John Lenahan, Commissioner Majkowski, Katheryn Brown and Don Russell. Thank you very much. (Applause.) MR. WELCH: We will take a short break, 15 minutes. We will resume promptly at noon with our next panel on pre-ordering. (Whereupon, a recess was taken.) MR. WELCH: Could we please get started? Could everyone take their seats? We will get started with the next panel. Our next panel will be on the topic of pre- ordering. We are, after having this sort of general panel, the next four panels that we will have today, and then three tomorrow will explore in more detail some of the more specific aspects of OSS, and, again, this panel will be on pre-ordering. We have five people on this panel, and I'm not sure if I have got them in order here, but I will go right to left this time to confuse everybody. On the far right hand of the table we have Stuart Miller from NYNEX. Stuart is Assistant Vice President for Access Systems. To his right is Robert van Fossen from US West. Bob is a Senior Director of Systems Planning and Development. To Bob's right is Carol Bussing from Sprint. She is Assistant Vice President for Systems Integration and Planning. Next to Carol is David White who is with ACSI, Vice President of Quality and Information Systems; and then to the far left we have Mark Sikora who is from GE Information Services. GE brings good things to life, I believe, is the -- including OSS, right? Okay, we will proceed on the same format that we did before, except we will reverse order and go from Stuart across, and everyone will have three minutes to make brief opening remarks, and then we will have some questions from the Bureau, and then hopefully some time for some questions from the audience. So, Stuart, if you could kick things off, please. MR. MILLER: Thank you. Since October 1996, NYNEX has offered the CLEC electronic interfaces to NYNEX Operating Support System functions, including without limitation the pre-ordering functions. To facilitate the support to CLECs, NYNEX has established a strategy which was first to rapidly deploy basic capabilities and functionalities. Secondly, we wanted to provision a low cost entry for small competitors who would want to get into the market quickly. Thirdly, we realized we were going to have to provide multiple alternative interfaces, mainly because of the lack of existence of standards and because of the different ways in which many of the competitors would want to interface with us. And we would definitely therefore have to commit to grandfathering our own interfaces where national standards ultimately came along. To give you some scale of reference, we currently have 19 resellers and three unbundling companies actively using these electronic interfaces. To date, from October to the beginning of May, about 22,000 CSRs had retrieved through the interface directly without any human hand touching these CSRs. That's for resale. In addition, another 8,500 for unbundled elements related CSRs were retrieved with direct flow-through, and all of those were through electronic interface. To facilitate our process, NYNEX has trained 180 people from 31 companies on how to interface with our systems. This year we trained -- that was in 1996. This year we trained another 130 resale students. We have trained 63 students from eight companies on how to interface with us to order unbundled elements. It's our intent to ensure the competing CLECs are given sufficient access to function. There are no material restraints on the CLEC's ability to perform pre-ordering, ordering, provisioning, maintenance repair and billing for both resold and unbundled elements in substantially the same time and manner that NYNEX does for itself. I would like to concentrate on the pre-order functionalities that NYNEX offers to CLECs. I want to stress one point, and that is that these functionalities provide a CLEC representative with the opportunity to perform equivalent work of equivalent quality and with equivalent effort required by a NYNEX retail representative. That pre-order data is resident, of course, in NYNEX's in place Legacy systems. The first five functionalities for pre-order are common to both resellers and purchasers of UNE; that is, customer service records via CRISP billing, validation of a customer's address, the assignment and reservation of a telephone number, due date availability, and product and service availability. And these functionalities use the same data as NYNEX's retail representatives. In addition, we have four new functionalities that are being offered specifically to meet the needs of purchasers of unbundled elements: channel facility assignments, silly code validation, loop qualification for ISD lines, and CSRs which may be maintained on the CAB system for FCC type services. For resale activities, all pre-order transactions are conducted exclusively across the electronic interface. Pre-order transactions for UNEs, however, have been somewhat slower to come through one of the electronic bases, although we now have assurances from many customers, from many CLECs, that is, that electronic transmission will soon be the case. As you might expect, our interfaces typically provide a mediated access to ROSS suite. It's our position that mediated access provides the best architecture for the wide variance of CLEC requirements and rapid modification of those requirements. We believe that our early production experience will lead us to improve these services as we go forward. NYNEX provides access to most of its OSS pre-order functions via its Direct Customer Access System, DCAS. This gateway permits wholesalers to use either an application-to- application interface, or a Web/graphic user interface, or WEB/GUI. The AP to AP interface supports all interactions, including large-scale commercial transactions. The Web/GUI is a user to system electronic interface option intended for smaller-scale carriers who seek quick market entry combined with low investment and an easy solution. While wholesalers must interface with NYNEX to access the information they require, how they choose to interface is dependent on their own evaluation of their business requirements. I would just like to finally list some issues which I think are pertinent to this particular discussion. First, the practices adopted by retail CLECs in servicing their customers will vary. Their marketing practices, their phone contact techniques, their cold canvassing procedures, and mass marketing efforts will demand various degrees of electronic sophistication and various protocols between their sales forces and their customers. NYNEX cannot anticipate what these practices may demand, and therefore we have adopted a flexible strategy that can accommodate an evolving environment. The second issue is that such an environment -- in such an environment nondiscriminatory access does become difficult to define. It can no longer exist at the system transaction level, but now must take place at the business transaction level. For example, a system transaction might be defined as retrieving one page of a CRS or customer service record, whereas a business transaction could be defined as the set of system transactions which combined to accomplish the definition and completion of a retail customer service order. The third issue in a commercial environment I am not going to dwell upon. It was addressed by the first panel, which is the issue of the relationship between supplier and customer in terms of forecasting the capacity of volume that is going to be submitted. Definitely there are sizing implications in that. And last, but certainly not least, is the complex issue of the interface specifications themselves. How does an industry establish standards for a multiplicity of interfaces involving a myriad of customers operating regionally in demographically different environments? We heard in the earlier panel about the difficulties that the CLECs have in interfacing in up to eight different interface specs. The reverse can also, of course, be true in the other sense. That if the CLECs have their own specific requirements for interfacing, then the incumbent LECs also have to provide those interfaces. So clearly the demand for national standards is a very important issue. And that's it, Richard. Thank you. MR. WELCH: Thank you, Stuart. Of all the acronyms that we have to deal with in the telephone word, GUI is clearly one of my favorites. It just doesn't get much better than that. (Laughter.) We will now hear from another incumbent, Bob van Fossen from US West. Bob. MR. VAN FOSSEN: Thank you very much, Richard. The subject of this panel today is pre-ordering and the activities and safeguards necessary to ensure nondiscriminatory access to operation systems in this area. For US West, the pre-ordering functions consist of a customer record retrieval, address verification, service availability verification, facility availability verification, telephone number assignment, and appointment reservation; all facilitated through electronic flow- through. US West Communications has invested a significant amount of effort since the release of the FCC first order last August in defining and implementing pre-order transactions for both its interconnection mediated access gateway and in the creation of specifications for an EDI gateway. What we have found are some fundamental misconceptions about how the pre-order transactions are thought of in relation to the ordering process, and some problems that could arise as a result of these misconceptions. The line between pre-ordering tasks and ordering tasks for the purposes of resale or unbundling is very thin. The idea that pre-ordering is a set of tasks separate and distinct from ordering is inaccurate. The concept of independence stems from the adaptation of telephony ordering and pre-ordering processes to the EDI model and way that do not always maintain the integrity of the original business model. Rather, I would offer that the pre-ordering and order transactions are co-dependent in quality, such that the quality and timeliness of order fulfillment, or the provisioning of service for the end customer, is critically dependent on the quality of the pre-ordering transactions and vice-versa. Let's take the example of the pre-order transaction to validate the service address for the customer. Addresses are widely recognized to be very difficult to match. The customer service representative, together with the aid of the customer, select from multiple similar definitions of addresses to identify the proper location of the customer. Collectively, the industry would be overwhelmed with system issues if we were -- if there were to be inaccurate communication between the ILEC and the CLEC on a customer address as part of the order. The use of the pre-order address validation transaction can prevent this type of problem. Conversely, the quality of several pre-order transactions are also dependent on timely knowledge about what is being ordered. Let's use another example. In this case, the capability to accurately estimate the work effort required to install a service. As companies continue to work on the efficiency of the field technician, jobs are scheduled in higher and higher levels of granularity, with almost no buffer time in between tasks. The job of scheduling the calendar is no longer hit or miss in the fashion of red, yellow and green lights. Complex software has been developed instead based on information contained in the service order to determine the length of the job and the next available appointment. Any scheduling conducted without ordering information is at best a guess. This kind of uninformed scheduling could result in missed appointments or in customers' appointments being pushed to a later date when in fact they could have been worked in a smaller interval. This quality co-dependency needs to be accounted for in our gateway systems designs and our work on national standard for pre-ordering. Digressing for just a moment I would like to make a point about the national standards in this areas of pre- ordering. The standards work on pre-ordering, as we have heard this morning, needs to be worked aggressively as order has been to date. The work on ordering via an LSR request has nearly flown through the standards process with a speed previously unheard of in recent times. The pre-ordering transactions, on the other hand, have taken a second priority and are not scheduled to be issued until about the third quarter of this year. While I'm not challenging the relative priority of the ordering versus the pre-ordering, we do have to work these two subjects together in parallel. In the meantime, LECS and CLECs are forced to develop proprietary solutions which will eventually cause rework as the standards are developed. Without diminishing in any way the importance of the quality of access to operation systems, it is clear that in the end nondiscriminatory treatment will be measured in terms of the service that is provided to the end customer. As we go forward, choices that are made in how pre-ordering transactions are conducted will have a significant impact on the quality of service to that customer. MR. WELCH: Thank you. Next, we will hear from Carol Bussing from Sprint. Carol. MS. BUSSING: Thank you. I appreciate the time to talk to you about the first process in the customer life cycle, which is called pre-ordering. As a CLEC, we need the tools and access to data that makes the customer's first experience with Sprint at least as good as that with the ILEC. The whole purpose here is about the customer. Accessibility and timeliness of all customer information is critical to providing the level of service expected by those customers. In order to achieve a competitive environment and to satisfy requirements of the Telecom Act, Sprint requires systems parity. The primary area in which the ILEC can concurrently respond quickly to their retail customers include, which have already been named by my two partners on the right, but I will do it again just so you don't forget them. Number one, validation of a customer street address; two, services that are available at the customer service address; three, the ability to have the customer choose and assign a working telephone number -- minor detail; and any information of customer service or history. Having to call the customer back due to the lack of available information is unacceptable to the customer and to the ILEC competitors. In the area of OSS, there is a key business function called pre-order. This is a process that needs to be as real time is possible, because you have the customer on the phone. This process involves the compilation of data needed in preparation for service order. As per the FCC's order in Docket 9698, these interfaces should be electronic, machine to machine, and should not rely on having human intervention in the transfer of that data. Pre-ordering is a process whereby local service providers and network providers exchange information regarding retail services, unbundled network elements and combinations of those network elements. To meet the FCC order, the ILECs have developed in most cases, (a), your favorite, GUI, graphical user interface in front of their Legacy or Retail systems. As depicted in this chart over here, you will see that none of these systems are alike. No two are alike. All have different names, and there is significant training and expenses to CLECs in this kind of environment. As a interim measure, Sprint has reluctantly had to accept these tools to get into market. Most GUI tools are not robust, and require phone calls to the ILEC that impact the level of service that we can provide our customers. The CSR's critical information, Sprint needs access real time while the customer is on the line. The ILEC today in most cases do not provide online access to that customer service record information, nor is the information consistent ILEC to ILEC. I think this was visually demonstrated yesterday if you were in the USTA demos from GET, Ameritech, Bell Atlantic and NYNEX. For example, when Sprint cannot get the necessary information on the customer's record, we have to call the ILEX, get the information, and turn around the call the customer back to close the order. The ILEC does not have this restraint when it deals with the customer. Also, system response times are of significant concern when you are live and online with that customer. The GUI tools are on a different hardware and software platform, and they have different kind of activity requirements. There has not been enough volume generated to stress those GUIs in those applications to ensure that adequate response times can be met. You cannot sit there and talk to the customer about the weather for more than five to eight seconds. In order to reach systems parity Sprint must have real time availability to the information resident in the ILEC's OSS infrastructure. We have got to get to the data. Only with direct excess to this information can we build the necessary and parallel processes to achieve equitable customer care treatment. For example, the end-to-end protocol response time for all online transactions should be five seconds or less for at least 90 percent of those requests. What is it that we need? We need electronic bonding. In order to develop the electronic bonding solution, it is key to have industry standards, so I totally concur with the both of you there. Standards are key to the equitable and real time exchange of data between CLEC and ILEC. That is when local completion will be a reality. Thank you all very much for your time and your attention. MR. WELCH: Thank you, Carol. I just want to acknowledge several people have made the comment that it's hard to divorce pre-ordering from ordering, and I think we at the FCC completely agree with that. And just to dispel any confusion, the fact that they are on separate days is only because want to let everybody get out of here at 1:00 and go to lunch, not because we think that they are separate topics that can be completely divorced. Next, we will hear from David White from ACSI. David. MR. WHITE: ACSI is a relatively new competitor in the local exchange environment. We have entered business into the Bell South region with resale services, and into several southern and eastern regions through our retail businesses where we provide our own switches. Our experience to date has been very negative. We feel we are at a definite competitive disadvantage in numerous respects because of the lack of a direct interface and the lack of parity to the incumbent LEC Exchange Service Systems. Some of the problems that we have experienced, and we are not for the record directly interconnected to any of these, and we have not to date used any of the new LEC systems that are on the board. We are being driven to that reluctantly, accepting their imperfections because the manual processing is not an acceptable alternative. We are currently seeing delays of up to 10 days for receipt of DLRs which force us to turn customers to service without knowing the line levels. So we end up with immediately maintenance problems. We see delays of six to seven days routinely for firm order confirmations, and I do have statistics to back up any of these items I am throwing out here. We have had numerous instances of disconnects of remotely call forwarded circuits after the time they were call forwarded and became one of our customers. We have lost customers to such outages. Customers cannot afford to be out of service for even one day, and we have lost some back to the incumbent LEC. We have seen a continuing lack of standardized intervals that are published by any of the incumbent LECS. So I am on the same bandwagon here as all of the other speakers today. We need to see some standards. Now, what I would suggest here is that it may not be possible to standardize installation intervals, but it certainly is possible to support the performance of existing intervals. That doesn't happen today and that's not a feature that's available in any of these systems. In a similar manner, these operational support systems that are being offered today do not allow a competitive local exchange carrier or an IXC to manage their data. You cannot go in by carrier by say "Show me all of my pending orders. Show me by back logs. Show me the intervals between the firm order confirmation date and the point the order was entered." That puts us at a significant disadvantage when we are thinking in terms of parity. Parity for an incumbent LEC means they have that access to that data. We are at a disadvantage. We cannot manage our process as they can manage their process. We have heard considerable discussion today also about the cost of access to the systems and who should bear it. I personally think it's very unusual for any sales organization to want to charge their customers for accepting an order from them. I think the Commission has made provisions for passing those cost on, not to the 200 or so carriers that might exist in the United States, but to the end users through the actual pricing of the services, and I would suggest that that kind of price flow-through should be considered and should not be an impediment to all of us as carriers working together to get these interfaces working. I think it's in our mutual interest to do so. As you may have noticed in the introduction, part of my title is vice president of quality, the other is information systems. And as of Friday, it's also network operations for our company, which is truly my background. The point here is that we have heard the issue of complexity, how complex these systems are. It was discussed several times here. As an IS professional, I take some exception to that. The solutions being delivered here are inadequate. The solutions being delivered here are really the quickest possible front-end to the existing systems that do the work. And what we have experienced in several different cases of testing these interfaces with the incumbent LEC is they are exactly that. For example, if you happen to enter an order through this system, you will be able to go in and check that order on a circuit-by-circuit basis. However, if you have a complex order that doesn't fit the model that this system provides you to enter through, you cannot go through this interface and look at the status of that order if it's entered behind the system. I find that highly unusual. It means half of our orders are in these systems and half of these orders are not in these systems. That's unacceptable. We need to see all of our orders, they should be apparent to us from the native system not through a front-end to the native system. Okay, what ACSI is asking the Commission to do is certainly pursue the standardization, but don't delay the issuance of performance standards for the sake of waiting for a standardized interface to these systems. Thank you. MR. WELCH: Thank you, David. And last, we will hear from Mark Sikora from GE. MR. SIKORA: For the past 20 years major companies throughout the world have been streamlining their business processes by using electronic commerce to exchange crucial business information. As a result of the Telecommunications Act of 1996, ILECs must provide CLECs electronic access to information to support the business processes associated with pre-ordering, ordering, maintenance and repair, billing, and other business functions without detailed specifications of the technology to be used to transfer this information. ATIS, special interest groups, ANSI subcommittees, vendors, and consultants have been left to sort through the state of the art in electronic commerce technology available in today's market to evolve standards and methods of interconnection. This is not a new dilemma for business to solve. On the contrary, it is incumbent upon the leaders in the electronic commerce and telecommunications industry to find our own solution to this 20-year-old problem. We must temper our solution with both the requirements inherent in our industry's business processes, as well as the limitations of available technology. Moreover, we must implement solutions which are practical and serve the time frames dictated by our business leaders, customers and regulators. Electronic commerce is the result of electronic bonding of trading partners to form a trading community. In order of these partners to trade electronically, they must first establish business relationships and technical relationships. During this discussion, we will concentrate on the technical considerations of electronic trading relationships. Globally, GE Information Services has over 40,000 customers using its electronic commerce services and is considered to be the world's leading supplier of these services. We have been a first-hand witness to the challenges associates with establishing and maintaining electronic trading communities for the past 25 years. One important lesson we offer for consideration is no matter how well a hub or a spoke partner plans its external communications, or how closely they adhere to ANSI guidelines, there will always be trading partners who require special treatment. It is our experience that even the most commonly used and well-defined electronic business documents are often negotiated for each trading partner in a community. Therefore, in order to be successful in an electronic commerce initiative each trading partner must be flexible in its implementation to accommodate variances and data formats, data representations and networking. Another important lesson we have learned is that a new standard is likely to be a standard that will change. Both LECs and CLECS will be making substantial investments in OSS interconnection systems and processes. Some of the largest non-DOD systems in the world, the provisioning systems of telecommunications companies, will undergo significant change to accommodate interconnection. We must prepare for changes in newly defined standards by buffering core internal business systems from changing external communication environments. Finally, we should be cognizant of and educate our business leaders that electronic commerce program require ongoing investment and hardware, software, communications and human resources. It is impractical to expect that once the first successful test transaction goes through that the summit has been reached. It is, instead, more likely that the journey has just begun. It's essential that we separate the business passion from the essence of the technological challenges we must address to implement interconnection. Quite simply, our challenge is to formulate electronic representation of a business transaction from the sender's proprietary system, net work it to the receiver system, trigger a response from the receiver system, and provide some sort of acknowledgement, a response to the sender, all without human intervention. We must also consider that both the CLEC and ILEC will use the transaction contents to update their private Legacy systems. Our technical challenge is further complicated by the necessity to accommodate various communication protocols, data formats and data contents. Finally, we have to admit to ourselves that technology giants will be trading electronically on a peer-to-peer basis with organizations which have limited technical resources and budgets. It's also important to note here that each ILEC wants to use a single interface to communication with multiple CLECs, and vice-versa. As a result of the significant marketing investment GEIS has made in this industry, it's become clear to us that there are two distinct camps which have evolved. These camps have evolved due to their position concerning interface format and application integration philosophy, and that is ECLite versus non-ECLite. Those who support ECLite claim that the only way for true electronic bonding to occur is to bind the applications using ECLite's various layers and services. The non-ECLite camp says that it can satisfy the requirements of legislation and regulatory agencies by implementing alternative interfaces like EDI over TCP/IP, and to date they have done so. It's the strategy of GE to provide flexible electronic gateway solutions to the telecommunications industry. If implemented properly, a gateway will blur the distinction between the two camps, allowing both CLEC and ILEC to focus on single feeds to and from Legacy system. This strategy puts the burden of messaging where it belongs, on the software suppliers. GE is busily working to address these challenges. The needs of the pre-order business function dictate that the gateway must at least be event driven to facilitate nearly real time transaction speed. Other interconnection business processes have less severe restrictions on messaging speed, while others require batch processing during predefined windows of time. An effective gateway must also be able to definitely handle a variety of external data formats, protocols and speed. As the word "gateway" implied, an effective solution must be scaleable to the size of the trading community, as well as the needs of the internal systems. One example I care to share with you is that trading partners relationships defined in the gateway should be able to receive and translate between EDI and ECLite as well as respond via EDI proprietary format, E-mail and even fax. In summary, we at GEIS believe that the telecommunications industry is in an exciting time. We are delighted to be involved with it. Given the resources of the General Electric Company, our experience in electronic commerce market, and our experience in the telecommunications industry, we believe we can fill the role as a provider of a flexible gateway solution and systems integrator for OSS interconnection applications. We applaud each responsible organization in this industry for making bold new moves into unchartered waters as the introduction of competition into local service takes its first few steps. Congratulations. Best Wishes, and we will see you in the winner's circle. Thank you. MR. WELCH: Thank you, Mark. Now we will move to the next phase, the question and answer phase, and we will ask some questions. We will direct these questions to specific people on the panel, but we encourage back and forth. If any of you want to respond, please just give us a signal. And actually, Mark, I would like to start off with you if I could. We are fortunate to have a representative from a vendor on this particular panel. Mark, could you tell us from the perspective of GE about some of the advantages or disadvantages of different approaches to providing new entrants access to pre-ordering? For example, Web pages or other uses of HTML or EDI or other application-to-application interfaces. What are some of your perspectives on that? MR. SIKORA: Well, what we have seen is that there is a tremendous split in the marketplace ECLite versus non- ECLite. And as we saw yesterday, we saw a lot of front-end systems to Legacy systems. I believe that one will truly start to exploit and own data when they build gateways, so they can talk one way to the external world and keep their own internal systems buffered. I think we can make life easier for the ILECs, if they are able to do the same. And what that also does is it buffers these core systems and internal systems from standards changes. So it's my belief that a gateway solution is a way to dispassionately conduct these electronic communications and maintain investments in Legacy systems, and that's especially true when you look at what the ILECs had to start out with as the source of all their data, which is a bunch of despaired Bell Corp. systems. MR. WELCH: Does anyone on the panel want to add anything to that? MS. BUSSING: Yes, I would like to, please. I think beyond just the interfaces are the tools that are provided. There is a key underlining issue here, and that is getting access to the data. It is not consistent across the ILECS today on what access of information they will allow us to have. Due date information on new installs, for example, not allowed to get that from PacBell. As you get a new customer installed, you have to call them. They will not give that information through the tools. You have to call them to get a due date to be able to tell the customer when they can have service. There is a multitude of examples like that. I think one of the things we need support of from the Commission, from the FCC, is to help us make sure that it is equal across all of the ILECs to provide the same information and open information as to me, as the agent of the customer, to be able to provide the level of service that we need to provide in a competitive environment. MR. WELCH: Yes, Bob. MR. VAN FOSSEN: I believe there is a split in the marketplace, but I am not sure it's so cleanly defined as ECLite versus others. What we have seen is a marketplace where you have got the larger carriers who are very much interested in doing the systems development associated with an application to application type gateway, and EDI type gateway, if you will, the larger carriers. In the marketplace, however, there are also a number of smaller carriers who don't necessarily have the resources or would choose to invest their capital in a way that they would use to have an app to app, and a user-to- application type interface very much meets their market needs. They don't necessary have the nationwide demands that a larger carrier might have. I expect there will be a permanent bifurcation of the market and will not have a single type of interface to an ILEC. You will have a user-to-systems type interface that might be very well met by Web type technology, and you will have a gateway-to-gateway type interface which will for the foreseeable future be based on our OPF/EDI directions. MR. WELCH: Stuart? MR. MILLER: Well, I want to join in what Rob is saying, but I think also to add that there is a time factor obviously at work here, and that is that because of the phasing and timing of the various orders that came out many of us have had to put in place interacts and protocols that clearly do not conform to national standards because the national standards don't exist, and clearly it's difficult for a CLEC to look at -- they say a 9X app-to-app interface for pre-ordering and say should I develop for this interface when I know there is a national standard coming down, and that's a very difficult decision for them to make. I think that's understood. But nevertheless, we have those interfaces in place, and they can be used should a CLEC choose to adopt that. And so there is a whole timing factor at work here. The advantages of an Internet or a Web/GUI kind of interface offering is clearly that it can be updated and enhanced a lot more quickly than other types of interface. It does have some disadvantages. It is by nature asynchronous as opposed to synchronous in nature. It does not provide the full capability that I think in volume as I think is supported by us that some people would want to adopt, but nevertheless it can provide the service and the service interval to the customer can be seen to be the same way. And we are certainly improving and enhancing response times for those kinds of transactions through that interface. MR. WELCH: Okay. I would like to introduce from my staff Kalput Gude, who is sitting next to me. Kalpak has been instrument in helping organize this forum, and he's going to present a couple questions to the panel. Kalpak? MR. GUDE: The first question I would like to ask is to Carol. If you could describe your experience at Sprint in obtaining access to the pre-ordering functions that you listed earlier. Also, for which pre-ordering activities is real time access necessary to meaningfully compete in the marketplace? Also, which types of interfaces have you experienced the most success with, and why? MS. BUSSING: Okay, three questions there. Let me give you a couple examples of trying to get access to these tools and bring them internal to Sprint and to our integrated national service center to be able to support us in the marketplace. There are, as you can see on the board, a variety of tools. I think it's key to understand that we have not had readily accessibility to these tools. A lot of the tools have been under development up until, and still continue to be under development as the ILECs are trying to get them in place to support competition. We have examples where, and I mentioned the one earlier with PacBell, where we can't get due date information. We have issues with GTE where we cannot get the customer service record information. This is over the tool SIGS, which is their product. It's very difficult when you have a customer on the phone and you don't know what their as-is services are, and I will tell you today with customers who are adding lines left and right for teenagers and doing all the different things they are doing with data and things in the home, that it is key for us to be able to see that customer information so that we can make sure that if they want all those services to be moved over and add services we have the view into that to be able to make sure the customer is protected and taken care of. I think that telephone number assignment, there are certain pieces of information. And when I mentioned the four area -- validation of customer street address, you have to have that information real time with the customer on the line to validate that. Services that are available, the customer service address is key information also to have real time with the customer. You can get a block of numbers or you can get downloads on number assignments and also the one area where we need real time is on customer service history, but you can bring some of that data down each day into some databases that we might have housed inside of Sprint, for example, where you could just refresh that data and have that available. It's not the most opportune way to do things. I think there is going to be a lot of movement, a lot of dynamic activities going on. And the more access we have to get to the customer information, when we have the customer on the phone is our preference. Your last question, if you will just remind me? Was it any good experiences, I believe? MR. GUDE: Yes, which specific interfaces have you had better experiences with and what? MS. BUSSING: Well, let me try to answer it this way. Because we have had to accept these tools, I wouldn't say I have any good experiences with the products. Where I would like to go is we really need to move, and Rob mentioned it, is electronic bonding, and we know that one size does not fit all. There is a variety of things that we in the long distance division have had to do over the years to support a variety of customer needs with many, many media methods, electronic interfaces for customers, and we are in the same environment in this competitive area. To have to negotiate with our partners, the ILECS, depending on what size company you are and what kind of transaction volume you are going to have to support to make sure we build the right method, to make sure we have a very competitive environment and not to forget protecting the customer. That is the key thing here is this whole open competition, is about the customer. And today these tools do not provide me the equal level playing field, if you will, to be able to provide the same service that the ILECs can provide today. I hope that answers what you asked. MR. GUDE: Any other panelist like to comment on that? MR. MILLER: I think there is one thing that clearly both sides can benefit from experience. I mean, this is one thing we are finding, that in having offers to electronic interfaces we have found all kinds of problems when we first offered them, and we worked with those problems and were able to fix them. And the only way, of course, you can really proceed and enhance things is by getting experience. In our case, we offered an app-to-app interface, for example, for pre-ordering transactions, but only one CLEC has chosen to build a system that will interface with that, and they had problems with it. We worked it and it's working pretty well right now. So I think the -- and yet we have no experience, no real experience with any of the major competitors right now, and I think we welcome that kind of experience because it is going to enable the systems to clear the bugs out of them, which are going to exist -- this is the nature of computer systems -- and get on with them that way, and I think that's what we are all anxious to do. MR. GUDE: Let me change the subject slightly, and ask Stuart. What safeguards have incumbents put in place to assure nondiscriminatory access to incumbent network personnel for the assignment of due dates? Also, what steps have you proposed to deal with potential privacy violations resulting from multiple carriers access to CPNI? MR. MILLER: Well, first of all, you are asking specifically about due date availability, for example, and our due date availability system in our Legacy OSS systems is used by both our retail reps and directly by CLECs coming in to check due date availability for the services that they are offering. The same system is being offered. The transaction that a CLEC will execute goes through the electronic interface, passes, flows through directly to our due date management system, and the response is provided directly back to the CLEC, and there is no actual human intervention in that for most of the common services, the POTS services and so on and so forth. Where there are expanded or complex services in our own bureaus we have people in place who will be looking at that kind of due date availability for complex services. That same bureau is used by our retail reps and will be directly accessed. There is a manual process in place directly accessed by the CLEC representatives to accomplish a due date availability that would be in parity with that which is offered to our own retail customers. In terms of the privacy of CPNI and other data, we have had to put modifications into our systems, quite extensive modifications to flag the data and who has rights to see it and who owns it. As I mentioned in my opening statement, we have a mediated access which provides the necessary checks to ensure that the CLEC has the availability only get to their own records, and our own reps do not have availability to get at their records. MR. GUDE: Turning to a familiar topic that we talked about on the last panel, but I think it is applicable here, and that's the issue of forecasting demand and scaleability in this context. I guess I would like to start off with you, Rob, and ask you how much capacity for use by new entrants have you built into your pre-ordering systems both in terms of the computers and services reps? And what plans do you have to accommodate increase in use by those competitors in the future? MR. VAN FOSSEN: US West does not necessarily sit on one of the marketplaces that was in the first tier, I think, of eligibility by the larger carriers. And so unlike some of my panelist partners, we haven't been inundated with the volumes of orders, as Commissioner Majkowski was saying earlier. However, we have been applying capacity to both the gateway solution as well as the core embedded operation systems. The electronic gateway access provides direct electronic access to the embedded operation systems. And so when one examines the problem of capacities you can't just simply look at a gateway and say is there enough gateway, but you have to look at the operation systems itself and make sure there is sufficient opportunity in the transaction flow on the back end systems. What we have looked at is our high water mark for our own busy order periods, and in attempting to develop forecast for what to grow beyond that, we suffered much of the difficulties that were discussed on some of the previous panel. And without going down that path, I think what we have found is that the forecasts are for all of us at best guesses, and in some cases in some areas you can find that the market forecasts and the transaction volume forecasts will exceed the total capacity of the marketplace inside three years, so that the entire collective market will be transferred out of the ILEC to every single CLEC collectively. So instead of using forecast data, instead of relying solely on forecast data I should say, we have also looked to the experience in the interchange marketplace for both market penetration and market churn, and used some of those estimates in order to develop some computing capacity estimates as to what's going to happen to our marketplace and our gateways. And our assumptions are that over the next three to five years that we will see on the order of a 30 percent steady state kind of churn rate coincident with what is seen in the interchange carrier marketplace, and have been putting in place both the existing capital improvements as well as the planned capital improvements to meet that market growth. The other key is to develop the software necessary to flow through as much of the transaction as possible. Correcting a statement made earlier, it is true that in US West, as in many of the other ILECs, the ordering process of translating an OBF form to a US West service order is in fact mostly a manual process. However, the pre- ordering transactions, the maintenance, repair and provisioning transactions, as well as the billing transactions, are all fully mechanized. But to say that we weren't interested in mechanizing that order processing would be a fallacy. We have every interest and are starting with the conversion as-is process to develop software to enable flow-through of those orders to remove the human hands from the process, and to get the manual steps out of the process to improve the capacity of the ordering. MR. WELCH: David, from the perspective of a new entrant trying to work with the incumbent on these types of systems, how do you internally at ACSI work with the incumbents to forecast and develop models that you are expected to man on their system and the resources? MR. WHITE: Well, strictly speaking, we don't. MR. WELCH: Okay. MR. WHITE: We don't forecast our demands. We have a competitor outlook on the market, and to forecast demand in an uncertain market where we cannot depend upon their systems having the capacity to handle the volumes that we throw at them, we find it kind of pointless, and we would rather divert our attentions toward actually marketing the services. We entered the Bell South region, for example, in resale services on March 1st. Within three weeks, we had over 4,000 orders. Of those 4,000, 3700 were back-logged. So it was very clear to us they couldn't handle the capacity. Could we have forecasted that? Very unlikely. MR. WELCH: Carol, how are you all working with that at Sprint? MS. BUSSING: Thank you. I would like to make a couple points on capacity and scaleability. I would like to retract back to a statement that was made earlier on Ameritech, for example, on system scaleability and reports that are available. One of the things that we, once we got the documentation in writing a proprietary front-end to be able to do pre-ordering with Ameritech, we kept asking for those measurements and for those reports so that we could understand the kind of volume before I invested in developing a proprietary interface for Ameritech, to ensure that it could handle the volumes if I incur the cost to develop something, as you can see, one is different from all the other eight options that we had there, and those reports could not be provided. So I am anxious to see if there are some reports showing the measures and trends of how capacity can be handled through the interfaces, because right now there is not enough volume, I believe, from many of the national carriers because of the fact of some of the ways we are having to go to market, a very constrained view, to be able to prove out these interfaces. One of the other things too that Sprint does is we step back and we do provide forecasts. But forecasting is a two-way partnership. I will tell you today that there has been significant investments in the systems, but in the local business today you are lucky if about 70 percent of the orders are done automatically or systematically. And on the business side you are lucky if 20 to 40 percent of the orders are done systematically. Some of the things that I have been trying to position with our partners is to say you have to tell me what your constraints are also, so that we can ensure we are still taking care of the customer. If they have constraints and cannot handle more than 100 ICNs a day, then it would be great to know that. So it's a two-way deal. I think that we owe the ILECs forecasts, to have them understand what types of volumes we would like to have in the marketplace or in their territories, but I think out of a responsibility to protect the customer they also owe us back what their constraints are. If automation is not there yet, yes, you intend to do it over time and it takes times, and we encourage you to do that, but what is the balance back so that we can manage it together. MR. GUDE: Stuart, you mentioned early on the likelihood that dual systems will develop in the future. How is it that you foresee these dual systems developing? Through the marketplace? Over time? Or through some assistance through standard-setting organizations? And how long are we likely to have to wait for this dual system to evolve? MR. MILLER: Well, the dual systems I was referring to really were those that would enable smaller competitors to get into the business rapidly, and those that would also enable the larger competitors to provide and generate the volumes, deal with the volumes that they are going to generate, and clearly, they are separate issues. And also let's not forget that that the FCC order requires us not to discriminate between those two groups of competitors, as well as with ourselves, which is a very difficult task to undertake when the nature of those systems are dramatically different, because the investment required, admitted by a large competitor, to provide an app to app or electronic binding interface is sizeable, which a small competitor would not be able to undertake. How do I see these developing in the future? Well, clearly, this is the national standards issue. As far as a Web/GUI nor Internet-based system is concerned, I think in reality there will be differences, as Carol pointed out, between the various ILECs who offer these capabilities. That it would be nice to be able to come up with some standardization towards that. I think it's relatively easier to accomplish if there could be agreements among the various participants to do that because the implementation time and cost and complexity is a lot less. In terms of the app-to-app interfaces, clearly there is a synergy that must exist between the national standards bodies and whatever role the FCC can play in that, and the marketplace as it develops. I think we are all experiencing some early birth pains, perhaps, of trying to bring about similarity between the major competitors who want to enter this business and the different interface requirements that they have, and the national standards forums. I would not like to predict right now how the outcome is going to occur -- is going to come, because I think in trying to mediate between the various large carriers and also play the participatory role in national standards is a very complex thing for everybody. So I think any catalytic role that FCC or some other body could take would be definitely advantageous. MS. BUSSING: Can I just add a comment? Do you mind? There is a position that the LCUF, Local Competition Users Forum, has taken on pre-order, and we worked very hard over the last couple of months to put together a pre-order requirement that is very much along the lines of what's being addressed in the issues throughout the industry standards. But that process is moving a little slow. For AT&T, Sprint, LCI and World Com, and MCI, to be able to go into business in this environment is just not, it's just not appropriate. So we have to drive and build something more on an electronic app to app on the front-end. What we really need to see happen is that the ILEC partner up and also give it the kind of attention that we are trying to give it to be able to move us forward in a competitive environment, and I'm not so sure we have everybody focusing. And I think part of it is because of what they have had to do to meet the immediate order and they have put a lot of energy and time and they have a lot of resources focused to this effort with the GUIs, we have got to get that turned around and get it focused on what I believe is really going to open up competition and get the next level of interfaces built, but it's going to have to be a very focused priority, and hopefully pushed, and it would be nice if it was a time bound position from the FCC to help us get that rolling. MR. WELCH: Yes, Rob. MR. VAN FOSSEN: I think it should be understood that no ILEC, and certainly US West has no interest in maintaining multiple interfaces that are functionally different. I think Mark was making the point earlier that the back-end view to the OS is should be as common as possible in order to provide functions on an nondiscriminatory basis as Stu was saying earlier, but also on a cost basis. I don't think you are going to see the marketplace diverging to where the functions that are available from an EDI gateway are markedly different from the functions that are available on a user-to-application basis. You will see different technologies, different access methods used in order to obtain access to those functions, but the cost drivers alone, aside from the market drivers, will keep the functions in common. MR. WELCH: Okay, we have about five minutes left so we have time for a couple questions from the audience. If anyone would like to pose a question to the panelists on the topic of pre-ordering. So if you could please state your name and direct your question to a specific person. MR. BLANK: Yes, hello. I am Larry Blank, staff economist with the Nevada Public Service Commission. I have two quick questions. First, on the issue of CLEC demand forecasting to the two ILEC represented here, I am curious what penalty d you propose when a CLEC submits a demand forecast which is in error? It seems to me that the accuracy of those forecasts is directly dependent on your performance, and therefore it seems silly to me to penalize a CLEC because the ILEC is performing poorly. Secondly, to Ms. Bussing, since my agency regulates -- let me back up. Your company owns the largest ILEC regulated by my agency, so I am curious as to how Sprint's ILEC operations have lived up to the performance standards that you have suggested here? Thank you. MR. RUSSELL: Yes, I will answer the first question very briefly first by saying that I don't really want to get in here into a business discussion about what penalties might be appropriate for inaccurate forecasting. I think we recognize that we would like to get almost anything right now, and there are a variety of validation checks that will perform, because what we are using them for right now is to be able to place the right capacity into operation, and we recognize that the businesses are unknown, churn factors are unknown, et cetera, et cetera. There is a lot of indecision about that. But I don't want to get into the issues of penalties right now. MR. VAN FOSSEN: In our experience, in US West, we have not been successful at the contractual level in negotiating binding forecasts. We are at the same point of any data that you can share will be better than no data at all. The forecasts, in fact, are considered nonbinding but are informatory in giving us at least the best heads up that can be made available in the marketplace. MS. BUSSING: In answering the question of Sprint's CLEC and ILEC business, the way I would like to position that is our local division is doing exactly what I think everybody else is doing, which is trying to provide tools to allow MCI, AT&T and everyone to get into the market. Internally, we are seeing an enormous amount of time in looking at electronic bonding together so that as we build that for the CLEC role, we will also have that for the ILEC role and provide that for competition. I don't know if that will completely answer your question, but, you know, they are taking the steps -- one tune won't answer all. I think we have identified that a lot of these GUI applications, which is one of the things our local division is also going to provide, they are in the process of testing. The will be providing an application for smaller CLECs, and this may fit for a long time for smaller CLECs. We have talked about EDI TCP/IP, which is another tier of protocol I think that can be supported for a certain volume of business in a batch mode. And then you have got to get into something that is truly real time, five second or less electronic bonding, which is exactly what the national carriers need. MR. WELCH: I think we have time for maybe one more question from the audience if anyone has one. MS. COLIFER: I am Anne Colifer with US One. I would like to ask the panelists whether they believe the proper data sets of information are being made available through these pre-ordering interface, or are there data elements that you need that are not being available either as a matter of policy or as a matter of just business practice by the incumbents. For example, one of the problems that we have encountered is that we have requested the identification of the location of the network interface device as part of the pre-ordering so that when a technician is dispatched to the home or to the apartment you know where that is located, and we have had difficulty getting that from some of the incumbents. Are there other kinds of data elements that you think are critical to a successful order process that aren't being made available? MS. BUSSING: Yes, I think I mentioned a few of those. Consistent customer service information, I think is key in making sure that we have a good, full understanding of that customer's service today. Due date information, I know that as we are all uncovering what we are going to need to do in sure of UNE and combinations of those, that there will be more and more of those things that come up and that needs to be uniform, that we can get that information equally across from all the incumbents. MR. VAN FOSSEN: As the requestee of pre-order transactions, we have seen dependencies in information that's normally contained in an order, such as the services ordered, that are absolutely critical for doing a good job on due date scheduling another aspects of pre-order in terms of facility availability, for example, that aren't necessarily thought of when the pre-order transaction is independent and happening significantly in advance of the order, whereas what we would like to see is something that is much more synergistic between the pre-order and the ordering process to represent that co-dependency. MR. WELCH: Okay, I think that concludes this panel. I would like to thank our panelists, Mark Sikora, David White, Carol Bussing, Robert van Fossen and Stuart Miller, for being on the panel. (Applause.) Thank you all. We will reconvene tomorrow at 9:00 with three panels tomorrow. Thank you. (Whereupon, at 1:02 p.m., the forum was recessed, to reconvene at 9:00 a.m., on Thursday, May 29, 1997.) // // // // // // // // // // // // // // // // // // REPORTER'S CERTIFICATE FCC DOCKET NO.: N/A CASE TITLE: Common Carrier Bureau Operations Support Systems Forum HEARING DATE: May 28, 1997 LOCATION: Washington, D.C. I hereby certify that the proceedings and evidence are contained fully and accurately on the tapes and notes reported by me at the hearing in the above case before the Federal Communications Commission. Date: _05/28/97_ _____________________________ Official Reporter Heritage Reporting Corporation 1220 "L" Street, N.W. Washington, D.C. 20005 Peter Knight Shonerd TRANSCRIBER'S CERTIFICATE I hereby certify that the proceedings and evidence were fully and accurately transcribed from the tapes and notes provided by the above named reporter in the above case before the Federal Communications Commission. Date: _06/04/97_ ______________________________ Official Transcriber Heritage Reporting Corporation Joyce F. Boe PROOFREADER'S CERTIFICATE I hereby certify that the transcript of the proceedings and evidence in the above referenced case that was held before the Federal Communications Commission was proofread on the date specified below. Date: _06/09/97_ ______________________________ Official Proofreader Heritage Reporting Corporation Don R. Jennings