How to scope an IPT and unified communications project for RFP
How to scope an IPT and unified communications project for RFP Published: 12 December 2007 © 2007 SAS Global Communications Limited. Reproduction of this publication in any form without express permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. SAS does not accept liability for errors, omissions or inadequacies in the information or its interpretation. The opinions expressed in this document are based on judgements at the date of publication and are subject to change without notice. All Rights Reserved. Table of contents Introduction ............................................................................................................................ 3 Glossary................................................................................................................................. 3 RFP prerequisites .................................................................................................................. 4 IP infrastructure audit ............................................................................................................. 4 Traffic planning study ............................................................................................................. 5 Project team configuration ..................................................................................................... 6 Architecture options ............................................................................................................... 7 Single site centralised cluster ............................................................................................ 7 Multi-site centralised cluster .............................................................................................. 8 Multi-site decentralised ...................................................................................................... 9 Home and mobile working solutions ...................................................................................... 9 Key components of a successful IPT and unified communications RFP .............................. 11 Global standards .................................................................................................................. 11 IP fundamentals; how will the IP sub-netting work? ........................................................ 11 Manufacturer market penetration; is support readily available? ...................................... 11 Vendor choice; does resource match the business footprint? ......................................... 11 Carrier and communications availability; is the global footprint adequate? ..................... 11 Application standards; are they consistent at all points? ................................................. 11 Standard system configuration; is the interpretation of the architecture consistent? ....... 12 Global SLAs; can they be globally coordinated? ............................................................. 12 PBX interoperability with existing PBX and IT systems ........................................................ 12 Fixed mobile convergence and IPT handsets ...................................................................... 13 Existing infrastructure integration and re-use ....................................................................... 14 Communications consolidation ............................................................................................ 15 Failover and business continuity .......................................................................................... 16 Proof of concept ................................................................................................................... 16 IPT readiness and voice path validation............................................................................... 17 Testing and approval process .............................................................................................. 18 SLAs - infrastructure support ............................................................................................... 19 Extended maintenance services .......................................................................................... 20 Conclusion ........................................................................................................................... 21 About SAS ........................................................................................................................... 22 List of Figures Figure 1-1 IP infrastructure audit - discovery and documentation .......................................... 4 Figure 1-2 Traffic planning study ........................................................................................... 5 Figure 1-3 Single site centralised cluster, with a centralised admin and control .................... 7 Figure 1-4 Multi-site centralised cluster ................................................................................. 8 Figure 1-5 Multi-site decentralised ......................................................................................... 9 Figure 1-6 Home and mobile working solutions ................................................................... 10 Figure 1-7 PBX interoperability with existing PBX and IT systems ...................................... 12 Figure 1-8 Communications consolidation ........................................................................... 15 Figure 1-9 Proof of concept ................................................................................................. 16 Figure 2-1 IPT readiness and voice path validation ............................................................. 17 Figure 2-2 IPT readiness and voice path validation ............................................................. 18 Figure 2-3 Testing and approval process............................................................................. 18 Figure 2-4 SLAs - infrastructure support .............................................................................. 19 Figure 2-5 Extended maintenance services ......................................................................... 20 Published: 12 December 2007 © SAS Global Communications Limited Page 2 of 22 Introduction The technical requirements of legacy PBX systems are not an adequate basis for developing an RFP for IP telephony and unified communications. IP telephony does not stand alone on the network; it has multiple interdependencies and it interfaces with virtually every component within the infrastructure. Ignoring these interdependencies is likely to affect call quality, ease of use and even the availability of the system itself. Companies planning to implement IP telephony and unified communications will need to expand the scope of the project to review areas such as data requirements, LAN and WAN upgrades, cabling and other physical site requirements, applications support and telephone features. This white paper offers a proven process for scoping IP telephony and unified communications projects for an RFP. It also highlights critical areas for review and integration, including areas which product vendors may overlook because they fall outside the boundaries of the vendors’ responsibilities. Glossary IP SLA – IP service level agreement IPT – IP telephony Jitter – Variation in time by which an IP packet is delayed on the network Latency – Time by which an IP packet is delayed on the network MCS – Managed communication services MOS – Mean opinion score Packet loss – Percentage of packets unable to reach their destination QoE – Quality of experience QoS/CoS – Quality of service/Class of service (AF/EF standard) SIP – Session initiation protocol UC – Unified communications UM - Unified messaging VoIP – Voice over IP; analogue traffic converted to IP at the router Published: 12 December 2007 © SAS Global Communications Limited Page 3 of 22 RFP prerequisites IP infrastructure audit The IP infrastructure audit is an essential first stage in the development of an RFP for IP telephony and/or unified communications. The multiple interdependencies and interfaces the system has, with virtually every component within the network infrastructure, cannot be ignored. A comprehensive audit serves to prevent deployment of a poor or inadequate solution and identifies areas that may require upgrading or modifying to support an IP telephony solution. If these issues are not addressed at the commencement of the project they will simply result in unanticipated costs in the future. For these reasons the RFP should be expanded to include data requirements in addition to other requirements which will be more self-evident, such as those relating to the site and the telephony system itself. Figure 1-1 IP infrastructure audit - discovery and documentation WAN service Carrier router PSTN / BRI / PRI Firewall VPN Voice gateway router WAN router Web server Storage device SAN Default gateway Application server Printer Switch gateway Email server Switch WiFi switch Work station WIP phone UM server Call control server Switch gateway IP phone Laptop The components shown in Figure 1-1 are typical of those found within most infrastructures. A comprehensive audit should document all key components, including all IP devices and the way in which they are connected to the network, the structured cabling system into the local area network switch infrastructure (shown in the second row up from bottom), the server infrastructure (third row up) and then connectivity to the outside world. If multiple sites are involved, the audit should include the wide area network connection (top, far left) and voice network connection (top, far right). Other key areas for the audit include the system deployed for wide area network connectivity from any carrier (red circle, top left), Internet connectivity (red circle, top centre) to remote users or third parties, and ISDN or PSTN analogue circuits (red circle, top right) providing connectivity to the outside world. Published: 12 December 2007 © SAS Global Communications Limited Page 4 of 22 This latter area (external connectivity via analogue circuits) can often produce cost savings when traditional analogue basic rate ISDN or primary rate ISDN circuits are managed and routed through a smaller consolidated number of lines and circuits within the IPT and UC solution. In overall terms, a thorough understanding of the current IP infrastructure enables vendors to assess requirements for enhancements, upgrades or modifications to the existing network, to support the new system. At the same time it provides an overview of external carrier connectivity, showing areas that are either fit for purpose or can be modified to reduce costs, contributing to the return on investment for the project. Traffic planning study As part of the audit process, a traffic planning study highlights the different components involved within the network and how traffic routes across it, between sites. A scenario typical of most company networks is illustrated in Figure 1-2 Figure 1-2 Traffic planning study DSL or Fractional T1 PSTN Catalyst switch with Secure LAN features Cisco voice-enabled router Catalyst switch with inline power and Secure LAN features IP WA N Internet PSTN Cisco distributed CallManager platform Dedicated connection DSL or Fractional T1 Teleworker/remote access Gigabit or 10/100 Ethernet Main business location Catalyst switch with Secure LAN features Cisco voice application servers P S T N Corporate servers Desktops/lapto ps with third-party anti-virus software Cisco IP Phone XML apps or IPCC Express agent POTS phones Cisco voice-enabled router with firewall and VPN Branch office DSL or Cable Broadband access modem Laptops/desktops w/Cisco VPN Client, Cisco Secure Agent and PC-based Softphone Fax Catalyst switch with inline power and Secure LAN features Cisco IP Phone XML apps or IPCC Express agent Desktops/laptops with third-party anti-virus software It includes a main business location (at the top), a remote worker (bottom left) with basic broadband Internet connection into head office, and a small branch office (shown bottom right) with a number of users and a private MPLS connection back to head office. With the voice path it is important to understand exactly how traffic will route across the network once it is deployed, not as it currently exists but in the final design for the RFP. The voice path is indicated by the eight red circles in Figure 1-2. In this example, a call is initiated on an IP telephony handset at head office (red circle, top right). The requirement for IP telephony handsets, or whatever device is ultimately selected to deliver the IPT solution to users is, therefore, immediately recognised. Published: 12 December 2007 © SAS Global Communications Limited Page 5 of 22 The call will then route through an edge switch (next red circle), where there will also be a requirement for structured cabling, before it ends up at a core LAN switch, again requiring structured cabling. If the core LAN switch is located in the data centre, other specific considerations may have to be taken into account. Generally voice traffic is separated onto a dedicated VLAN in order to easily prioritise, manage and monitor the voice IP packets. Connectivity to the outside world is then through the wide area network router. One of the key considerations highlighted by the traffic planning study, as summarised in Figure 1-2, is the number of components involved within the voice path before the call is even routed to the outside world; the fewer the better. If the call is then handed off to a third party, it may go through the external PSTN dial connectivity or, as shown in Figure 1-2, across the MPLS wide area network. This places particular and specific operational demands on the MPLS network itself. It will need to have expedited forwarding class of service (EF CoS) applied to ensure that quality of service is maintained on the call whilst it is routed across the wide area network, through to the wide area network router at the branch office. From here, the call will go through another switch and on to a handset (the last two red circles in the sequence). One of the most revealing facets of the traffic planning study is that it shows how a simple call from the main business location through to a branch office impacts numerous areas of the network; all of which need to be analysed. Ensuring that the analysis is effective depends on considering each particular business profile; how calls route within the estate, and which components and devices they route across. This then facilitates an assessment of whether or not the components and devices are fit for purpose as they are, can be upgraded or modified, or need to be replaced, in which case they should be included in the RFP. Project team configuration When carrier connectivity as well as the internal infrastructure, and its constituent components, have been fully understood and comprehensively documented, a project team must be put together. This team will be responsible for the development of the RFP and the review of proposed solutions. It should include, but by no means be limited to, employees of the business. To ensure the broadest mix of expertise it should also include technical personnel from the selected vendors and any other third parties responsible for the applications, network infrastructure and external circuit connectivity. Published: 12 December 2007 © SAS Global Communications Limited Page 6 of 22 If external carrier connectivity is through a major carrier, that carrier should be represented on the project team. This not only ensures that the carrier is aware of any changes proposed, but serves to expedite matters, since the carrier’s representatives can clarify infrastructure compatibility issues as the project develops and help identify related areas that may need to be included within the scope of the RFP. The project team will be responsible for identifying the needs, and soliciting the input, of each department within the business. Whilst it should include representatives from IT, it is imperative that it is not allowed to become the exclusive domain of the IT department; the main focus must be on the needs of the business, not on the technical functionality in isolation. To ensure the highest possible degree of business relevance and value, the requirements of all departments must be explored and accommodated. Finance, for example, may require call logging or billing functionality which is either not available in the current system or simply has to replicate whatever functionality does exist in the current system. Project team configuration should represent a broad spectrum of interests and requirements across the business, in terms of user interface and experience, departmental needs and, from an IT perspective, the infrastructure required to deploy the solution. Architecture options With the team in place, the next stage is to decide which architecture option best fits the business. Factors to be taken into account include the number of remote users and type of office infrastructure; a head office with either no remote sites, a number of small remote offices, or a number of evenly-sized branch offices. Single site centralised cluster Figure 1-3 Single site centralised cluster, with a centralised admin and control CallManager Cluster PSTN V System IPCC IV R/I S N AW /H DS Admin Control ler Agent Signaling/CTI IP Voice TDM Voice I P The first scenario is a single site centralised cluster, as shown in Figure 1-3. Published: 12 December 2007 © SAS Global Communications Limited Page 7 of 22 The ‘agents’ are shown at the bottom; these are the users connecting into the system, through either an IP handset or a softphone running on a desk top. The IP voice traffic will route through the network, centralised at the head office and only having connectivity to the outside world when users specifically activate it, usually by dialling 9 or 0 for an outside line. This is the most basic, straightforward solution. Where multiple offices are involved it is unlikely that such a scenario would prevail within the network. Multi-site centralised cluster Figure 1-4 Multi-site centralised cluster CallManager Cluster cluster PSTN System IPCC central controller V AW/HDS Admin controller PG/ CTI controller Agent IP/ IV R VoIP WAN Signaling/ CTI IP Voice TDM Voice A ge nt I P A ge nt I P The second scenario, the multi-site centralised cluster, is where there may be several small remote sites with no requirement for large amounts of equipment. It can be seen from Figure 1-4, that the set-up at head office is similar to the single site centralised cluster, the key equipment being located at the head office; the call manager cluster can be seen top right, and external connectivity through the PSTN dial network (shown centre) is also through the central site. The key difference, however, is the inclusion of a wide area network component (bottom layer) connecting to routers and agents at a remote site. This option is preferable when a number of smaller branch offices are included in the network since it avoids the necessity for too many components at each remote site. Equipment is concentrated at head office and remote connectivity is made available to remote users. Published: 12 December 2007 © SAS Global Communications Limited Page 8 of 22 Multi-site decentralised Figure 1-5 Multi-site decentralised IPCC Enterprise Central Controller P G IPCC System PG (CCM/IP-IVR) AW/HDS IVR I V R P IPCC System PGG (CCM/IP-IVR) VoIP WAN V V CallManager Cluster 1 Signaling/CTI IP Voice TDM Voice CallManager Cluster 2 PSTN A ge nt I P A ge nt I P The third scenario, multi-site decentralised architecture, is more complicated than the previous two. Two call manager clusters are shown in the example in Figure 1-5; one located at the central site, on the left-hand side, and another set located on the right-hand side, the design of the two sites creating a mirror image. Both sites have PSTN connectivity to the outside world. Wide area network connectivity is present between the two sites. A multi-site decentralised architecture is preferable in a situation where there are similar large offices requiring their own internal infrastructure. It is also offers resilience. Were one site to experience problems with remote connectivity to the PSTN dial network, it would be able to route through the wide area network and out through the other site. Home and mobile working solutions With any of the foregoing architecture options, the needs of different types of remote users coming into the network must be accommodated. Figure 1-6 uses the same diagram featured earlier to illustrate the traffic planning study (Figure 1-2). If remote workers are equipped with softphones, the optimum mode of access will be through WiFi access points coming in through the Internet. Published: 12 December 2007 © SAS Global Communications Limited Page 9 of 22 Figure 1-6 Home and mobile working solutions DSL or Fractional T1 PSTN Catalyst switch with Secure LAN features Cisco voice-enabled router Catalyst switch with inline power and Secure LAN features IP WAN PSTN Internet Cisco distributed CallManager platform Dedicated connection Gigabit or 10/100 Ethernet Main business location Catalyst switch with Secure LAN features Cisco voice application servers PSTN Corporate servers Desktops/lapto ps with third-party anti-virus software Cisco IP Phone XML apps or IPCC Express agent POTS phones Cisco voice-enabled router with firewall and VPN DSL or Fractional T1 Teleworker/remote access Branch office DSL or Cable Broadband access modem Laptops/desktops w/Cisco VPN Client, Cisco Secure Agent and PC-based Softphone Fax Catalyst switch with inline power and Secure LAN features Cisco IP Phone XML apps or IPCC Express agent Desktops/laptops with third-party anti-virus software This arrangement will have its own implication on head office Internet connectivity and how the network is configured for quality of service. Quality of service is not currently available across the Internet; user expectations, therefore, must be carefully managed and consideration needs to be given to how best to support and manage the system. Published: 12 December 2007 © SAS Global Communications Limited Page 10 of 22 Key components of a successful IPT and unified communications RFP Global standards One of the key areas to encompass within the scope of the RFP, when global offices are involved, is that of global standards; how the system will impact all sites within the business. There are basically seven key criteria to consider in the creation of a global standards framework: IP fundamentals; how will the IP sub-netting work? When deployed across global sites, it may be the case that this will roll out using the same network standards established for the head office. However, some remote offices may have IP sub-net conflicts or related complications that will need to be remedied prior to deployment. Concerns might apply to a particular office or a particular region; addressing the IP fundamentals at this early stage will enable them to be highlighted within the RFP to avoid complications at a future time. Manufacturer market penetration; is support readily available? Whatever products are considered, it is critical that the vendors offer support in every country or region in which the business has a presence. A manufacturer may be strong in the UK and Europe, for example, but offer no availability in Asia Pacific or North America. Specific manufacturer selection against this criterion offers the possibility of reducing the sub-set within the RFP by requesting only manufacturers whose support networks match the business footprint. Vendor choice; does resource match the business footprint? Any third parties involved in deploying the solution must have the presence, or at least an engineering resource, to fit with the business footprint, even if locations involved are exclusively UK-based. If different time zones are involved then the support and management offerings must also reflect the business hours. Carrier and communications availability; is the global footprint adequate? Where an MPLS wide area network is deployed to connect to remote sites it must extend to all sites within the business. It is not an acceptable standard solution if only a limited number of sites connect in this way. Application standards; are they consistent at all points? If unified messaging and unified communications are deployed at head office, they should also be deployed at remote sites. For example, it will be important to ensure that Microsoft server systems share the same Active Directory and Exchange organisation to simplify UM and UC deployment. Published: 12 December 2007 © SAS Global Communications Limited Page 11 of 22 Standard system configuration; is the interpretation of the architecture consistent? The system has to be deployed in a uniform fashion throughout the business; this facilitates efficient and cost-effective user-support. Different interpretations of the agreed architecture, in different office locations, will introduce incompatibilities and additional costs at a later date. Global SLAs; can they be globally coordinated? In the case of multiple offices, spread across various territories, a decision has to be taken as to whether or not separate in-country companies will be appointed to support the system. The alternative is a single source; coordination and control through a central help desk. Whatever arrangements are made for management and support, they will need to be included in the SLA. PBX interoperability with existing PBX and IT systems Figure 1-7 PBX interoperability with existing PBX and IT systems Feature / benefit Basic call routing (inbound / outbound) Advanced call handling Attendant console (reception) Advanced call routing (inter-site / in-country breakout) Voicemail Unified messaging (email, fax, IM, SMS) Extension mobility (hot-desking) MS Windows server – Active Directory MS Exchange server MS Mobile 5.0 / 6.0 Blackberry Yes/No Figure 1-7 highlights a number of issues to be clarified with vendors on the topic of interoperability. The examples shown here do not constitute an exhaustive or definitive list, since infrastructures and functionality requirements vary from business to business. One business may require basic IP telephony, whereas another will wish to add unified messaging or unified communications. The areas shown in the table are, however, indicative of the type of concerns that will arise in the development of most RFPs. Where basic call routing is concerned, for example, there is likely to be a transition period between systems where the legacy PBX will run in parallel to the new IPT solution. Basic inbound and outbound call routing will be needed between the two systems. Published: 12 December 2007 © SAS Global Communications Limited Page 12 of 22 In the case of businesses with multiple offices, it may be that one office has already moved onto the new system whilst another has not yet been transferred; in this case it is clearly vital to the business that offices can continue to talk to each other during the migration. Where advanced call handling facilities are currently deployed, can they continue to be used? Other basic features such as voicemail, although simple, have become essential in the daily functioning of business, and the consequences can be damaging to the business in the case of disruption, particularly since roll-out is rarely an instantaneous process. Interoperability assumes notable importance in ensuring a smooth transition, enabling the system to offer all appearances of seamless and uninterrupted functionality. Fixed mobile convergence and IPT handsets Deciding how users (also referred to as agents) will communicate with the system, and how remote users can be integrated, is a significant focus area within an RFP; offering the opportunity for swift adoption within the business through high relevance to the detailed way in which the business may operate, combined with easy-to-understand functionality Investment in handsets often becomes one of the larger cost areas not because of individual component cost but simply due to the number of handsets required. Whilst many multi-functional models are available, offering attractive features such as colour display screens, they tend to carry high individual price tags. Multiplied by the number of agents on the network, this results in a figure which often renders the high-end handset option unfeasible. Handset selection should ultimately be based on essential functionality rather than alluring additional features and attractive design. IP telephony devices range from simple analogue telephones to advanced feature phones; devices that are slightly different from normal handsets, such as conference phones. If conference phones form part of the network requirement, it is likely that they are already present within the existing infrastructure. It is not necessary to replace them with IP-enabled units; which are absolutely identical, with the only difference being that they are IP-enabled. Analogue adaptors can be used to convert these devices, enabling them to work with the IP network. This practice can create significant cost reductions. IP wireless infrastructures also require careful consideration. WiFi-enabled IP telephones are often deployed as replacements to a DECT infrastructure. There are implications on wireless network coverage within the office infrastructure; where a wireless network exists prior to deployment of the new system, it will need to be analysed to ensure that it is fit for purpose with the new system, supports the voice protocols, and offers sufficient radial coverage within the building to support voice as well as the existing data. Another area to consider is video telephony, basically a video-enabled telephony device, and video conferencing integration. Published: 12 December 2007 © SAS Global Communications Limited Page 13 of 22 Since all of these devices are IP-enabled, the process of enhancing them to include video as well as voice is relatively simple and straightforward but does involve an additional overhead in terms of network configuration costs. This is in the areas of both quality of service, where assured forwarding class of service (AF CoS) is required for the video traffic, and the additional bandwidth needed on the network. In terms of mobile usage, softphones offer a cost-saving opportunity. It may even be the case that IP handsets are not actually required if the business is made up of large numbers of mobile or home workers or even desk space users. In such situations, deployment of softphones to the desk tops would suit the working style and needs of both the users and the business. The softphone is simply another application that runs on the PC, using the IP connectivity of the desk top to run across the network, Accommodating the needs of mobile users means assessing their information needs and working style, dictating the requisite functionality. There is still no one device that offers functionality to suit all needs; developments in mobile telephony are extremely fast-paced at this point in time so it may be opportune to set mobile needs aside to be addressed at a later date, whilst remaining aware of market and product developments. Existing infrastructure integration and re-use Having addressed the needs of the business, the existing infrastructure should be reassessed in collaboration with the selected vendor or vendors to discover which components can be re-used. The recent SAS white paper, ‘How to identify if existing network equipment will work with IPT’ (12.11.07) covers this aspect in depth. The re-use of components is primarily a cost-saving exercise but it also reduces the scope of work and amount of change to the network. Starting with the network switch infrastructure; do current switches support the virtual LANs enabling the separation of voice and data traffic? Do the switches support power over Ethernet, meaning that separate power supplies will not have to be run to IP handsets, if deployed? If so, this will enable power to be injected through the systems via the structured cabling system, direct to the phone. If wireless IP handsets are deployed, does the access point infrastructure support the required voice quality? Applications integration should also be considered. If unified messaging is to be deployed, any current issues need also to be discovered at this point; any legacy Active Directory issues will become major disruptions when further devices are added into the mix. Published: 12 December 2007 © SAS Global Communications Limited Page 14 of 22 Adding unified messaging will increase storage requirements in the email environment so capacity and storage must be re-evaluated. Best practice would be to clean up the estate or expand the system before any adverse situation is allowed to arise. The other key area to assess is that of external connectivity - the routing infrastructure particularly through any wide area network. An audit of the external connectivity will ascertain if the routing infrastructure is quality of service enabled to ensure that class of service can be maintained across the external connectivity, guaranteeing uninterrupted quality of experience and quality of service. Communications consolidation The relationship with any vendor involved in delivering an IP telephony, or unified communications, solution will be long-term and ongoing. This applies as much to external connectivity carriers as to other third parties involved in the network infrastructure. The RFP scope should be expanded in order to derive maximum benefit from such relationships. Figure 1-8 Communications consolidation An example of areas to consider within a master services agreement is shown in Figure 18, designed to ensure ongoing support within the UK and into any international territories pertinent to the business and the infrastructure. Support is best provided through a single point of contact (SPOC) both for additions and changes and for in-life product development; particularly for those areas where the pace of development is more rapid than within the industry as whole. Most notably, this includes areas such as mobile communications- PDAs and Blackberrysas well as smart phones. The business is best served by a single contract to cover calls, lines, the wide area network, the Internet, conferencing, mobile working and WiFi. Published: 12 December 2007 © SAS Global Communications Limited Page 15 of 22 A single point of contact is not only the most efficient arrangement, but also offers full transparency in all events. If a single party is responsible for the whole solution, then any issue arising clearly falls within the remit of that party and there are no blurred lines of responsibility arising from the partisan interests of different vendors or manufacturers. Failover and business continuity Business continuity is an absolutely critical area for the RFP. If failover is required between circuits or devices, then system support is an important issue, particularly in the case of a power outage, an occurrence exacerbated within a centralised system. Any uninterruptible power supply or backup generator must have the capacity to supply the system if the power fails. Were a power outage to be of long duration, however, even the UPS might fail; the servers would then have to be shut down in a controlled manner but a traditional phone system would continue working by being injected across a standard analogue signal. It could, for example, have PSTN connectivity, with a small voltage coming through from a carrier. In an IP telephony solution, no power means no phone system, so alternative power supply arrangements must be robust and 100% reliable. Proof of concept Proof of concept is a highly desirable stage for signing off any RFP. It entails creating a miniature version of the proposed IP telephony or unified communications system such as that shown in Figure 1-9 which can be used by the different stakeholders within the project group to test the system. Figure 1-9 Proof of concept WLAN Telephony access security Internet PSTN Switching Mobile users Fixed users Converged Network Published: 12 December 2007 © SAS Global Communications Limited Page 16 of 22 The example system shown includes a basic power over Ethernet switch, with a selection of IP telephony handsets. Softphones might be included, if the final system is to offer wireless access to users with notebooks and handsets. A single access point can also be included, as well as a representative sample of users as indicated on the top right part of the diagram. Connectivity to the outside world then allows a live test of system functionality. Users are also given the chance to try the handsets and familiarise themselves with the functionality. Since these are the agents who will work with the system on a daily basis, their input on the suitability of the functionality can serve to identify development areas for the RFP which may have been overlooked or received lower priority than they may deserve. The proof of concept stage offers two significant benefits. Firstly, it is an opportunity for the vendor to prove that the system functions exactly as it was designed to. Secondly, it offers the system owner the chance to test it and, if necessary, further develop the RFP if additional or different requirements emerge during the proof of concept stage. IPT readiness and voice path validation Prior to implementation of the new system, the voice path needs to be tested for IP telephony and unified communications readiness using the mean opinion score (MOS) test. Figure 2-1 shows results for different voice paths where each was scoring different results for different factors, ranging, at the top, from 4.5 down to 1.0. Figure 2-1 IPT readiness and voice path validation Published: 12 December 2007 © SAS Global Communications Limited Page 17 of 22 The system should score 3.5, or higher, to ensure that it is working effectively, that quality of service is present and that there is no delay or jitter in the voice traffic. Regular MOS testing affords the opportunity to improve and enhance different areas of the network, re-testing until the system is within the 3.5 threshold, as shown in Figure 2-2, the point at which the voice quality is likely to be maintained across the network. Figure 2-2 IPT readiness and voice path validation Testing and approval process Arrangements for signing off the network should be put together at the RFP stage in discussion with the relevant vendors, taking into account the testing and approval processes with which they are accustomed to working. Figure 2-3 summarises the core stages in the process. Figure 2-3 Testing and approval process Testing and approval Project initiation Live operation System design IPT and UC project • • • • Agree a project plan Agree a testing plan Agree acceptance criteria Approval must come from each department • Monitor each system during testing to understand impact on network performance Migration Acceptance test Implementation Published: 12 December 2007 © SAS Global Communications Limited Page 18 of 22 The project plan and testing plan should be agreed with the vendor/s, as should the acceptance criteria to be brought to bear at the sign-off stage. This will ensure that parameters for the project conclusion are clearly identified and clarified between both parties, for the avoidance of all doubt and to expedite project finalisation. Approval must come from each department. Success of the project is not governed purely by the IP infrastructure, but also by user response to, and acceptance of, its functionality; user opinion should be canvassed to ensure that users have the functionality and information required. Monitor each system during testing to understand the impact on network performance. The proof of concept stage and MOS testing of the infrastructure, both require an individual testing and approval phase. SLAs - infrastructure support When the system is live it will require a comprehensive level of support, particularly since it comprises different clusters of devices as shown in Figure 2-4. Included within the infrastructure are a wide area network solution, external carrier connectivity, the network server infrastructure as well as individual desk tops and users. Figure 2-4 SLAs - infrastructure support WAN service Carrier router Fire wall PSTN / BRI / PRI VPN Voice gateway router WAN router Web server Application server SAN Default gateway Application server UM server Email server Switch Printer Switch gateway Work station WiFi switch WIP phone Call control server Switch gateway IP phone Laptop These areas are typically supported by different teams or external third parties, but when IP telephony and unified communications are introduced across the estate a common service level agreement is required to encompass the various different devices and the different infrastructure components. Published: 12 December 2007 © SAS Global Communications Limited Page 19 of 22 Extended maintenance services Whilst the RFP begins with the build, infrastructure design, implementation, provision and install, it should also incorporate two further stages to ensure continuous functionality and longevity of use: management and support. The various elements involved are summarised in Figure 2-5. Figure 2-5 Extended maintenance services A comprehensive extended maintenance service agreement should be put in place to provide reactive support, incident management, preventative maintenance, routine maintenance, moves, adds and changes. The agreement should also cover policy development; continuous evolution and development of the system as new features and functions become available. Further detail on support will be found in the SAS white paper, ‘How to support an IP telephony network’ (10.10.07). Published: 12 December 2007 © SAS Global Communications Limited Page 20 of 22 Conclusion In conclusion, detailed planning is required for an IP telephony and unified communications RFP. This should extend beyond the telephony system itself to encompass the network infrastructure, how the business uses telephony and how it will work with other offices and remote users within the estate. The key points to bear in mind when putting an RFP together are as follows: Project team configuration should be on a cross-company basis. The project team also needs to involve third parties such as carriers and other parties involved in the communications aspect of the network. Selected vendor should be, and will be, a long-term business partner. Selection is, therefore, a process that will have an impact on the business and should be diligently undertaken. Any candidate vendors should have the footprint, the coverage, and the support and management options to support the business at all its locations. The product should be evaluated both for its present functionality and its future road map. This is an area which is developing very fast, particularly in terms of functionality, like presence, and features such as mobile users. It is important that any business moving into IP telephony deployment stays aware of developments into the future. A successful IPT and UC RFP is driven by the business requirement. Technical requirements will come out of the business needs and should clearly never be specified in isolation from them or because of the standalone attractiveness of the system and features it may offer. An RFP must be clear, concise, offering easy evaluation of, and comparison between, different vendors. Endeavouring to interpret and compare different documents in different styles and formats can be an unnecessarily time-consuming process. Establishing unequivocal key metrics to monitor each response clarifies the process and ensures that comparisons are made on a like-for-like basis. Multiple vendors should be evaluated for each manufacturer. If there is a manufacturer of choice, perhaps dictated by the global footprint, multiple vendors should still be compared. Client references from similar project implementations should be requested. Asking for references alone does not always elicit an appropriate response since they may not reflect the type of business, the business footprint or the type of solution that is being proposed. To ensure an accurate and appropriate base for assessment, the references should relate to similar project implementations. Published: 12 December 2007 © SAS Global Communications Limited Page 21 of 22 Proof of concept of the solution is a key stage of any vendor selection. Proof of concept also provides an opportune exit route. Should a vendor fail to deliver against this stage it is unlikely that the same vendor would be successful at the full implementation stage. An alternative approach would be to select more than one vendor to undertake individual proofs of concept to see the difference between solutions on offer. Meetings must be held with the vendor’s implementation and support team. It is an insufficient basis on which to move forward if vendor meetings have only ever been held with the vendor’s sales team. The implementation and support team will provide an understanding of the business, the support offered and what the in-life experience will be like once the system is deployed. About SAS SAS Global Communications is a major provider of managed and professional network services. The company provides consultancy and implementation services to design, build and manage converged IP networks for enterprises of all sizes. Since its inception in 1989, the company has successfully delivered more than 2000 highly commended solutions, to a broad spectrum of clients including many renowned brands, such as Coca Cola Enterprises, The Body Shop International and Millennium and Copthorne Hotels. For more information contact: SAS Global Communications Limited SAS House Blackhouse Road Colgate, Horsham West Sussex RH13 6HS Tel: +44 (0) 1293 851951 Fax: +44 (0) 1293 852200 Email: info@sas.co.uk www.sas.co.uk Published: 12 December 2007 © SAS Global Communications Limited Page 22 of 22
© Copyright 2024