Next week I will be receiving RFP submissions for IP telephony systems from eight system suppliers who have agreed to participate in my annual tutorial at VoiceCon Orlando (March 30 - April 2, 2009). The 2009 TEQConsult Group RFP document will be available for download late next month and I hope that all customers planning to attend the tutorial will read it prior to the conference. The document is also available to No Jitter readers not planning to attend, who can also download the document. (But take note that the value of the RFP tutorial, including the highly detailed vendor responses, is many times the conference fee and associated travel costs.)I promote the upcoming tutorial to make a case that customers still need to prepare an RFP document as an integral part of the purchase decision process for their next enterprise communications system, because I continue to hear that the shift towards a software-centric solution reduces the value of hardware components. If most systems have an open design that can deploy customer-provided third party servers and media gateways, some people argue, why waste time and energy on an RFP? Customers should select a system provider who can best satisfy their organizational and communications needs through application software solutions, or so I often hear.
Despite today's focus on software at the expense of hardware, the physical elements of an IP telephony system are still important and vary from system supplier offer to system supplier offer. The hardware design still determines capacity parameters, especially those ports requiring media gateway interfaces and the number of customer sites a single system can support via distributed media gateways. The hardware design is also an important determinant of remote survivability capabilities (operation and capacity), because local processing functions must be retained in case of network connection problems to the hosted data center. No IP telephony system today supports local survivability using an off-the-shelf OEM server. Other redundancy and resiliency capabilities are also determined by the architecture design, as is the system cost.
Another important hardware component are desktop telephone instruments. The faceplate layout, the number of programmable line/feature keys, the type and size display screen, and integrated interface ports, e.g. Gigabit Ethernet, vary between models and vendor portfolios. No two customers appear to have the exact same telephone instrument requirements, based on my experience. Specifying unique needs in an RFP is still an important requirement.
Software has probably assumed a more critical role than system hardware for today's evolving enterprise communications systems, but specifying the detailed hardware design requirements is still important, and this demands a formal document such as the RFP.
