OSS automation: The value, hype, and everything in between
Service providers are constantly bombarded with software companies in the operational-support-system (OSS) market that claim automation will solve all their provisioning, inventory management, and billing problems. There are countless vendors claiming they can reduce costs and cut manual processes drastically.
These companies can sometimes run together and blur. Their products seem interchangeable and without distinctive feature sets. Slick marketing can also make it difficult to even understand what they really do. They claim to reduce return on investment and automate processes with flow-through, touch-free service activation.
Because of the downturn in the economy, many of these vendors have scaled down their marketing and are more focused on what they can offer today. That's a positive trend in the market. Service providers are now better able to look beyond the hype and find value in OSS systems in a time when money for capital expenditures is hard to come by.
The good news is that with major innovations in the OSS market, companies can now deliver valuable products. The key for a successful automated OSS implementation is for service providers to know what the result should be. For example, are they looking for faster service delivery, quicker fault resolutions, or real-time billing?
To execute any successful business process—manual or automated—planning for an intended result is essential. This planning and setting of expectations will prevent budget overruns, time delays in implementations, and a possible disappointing outcome. There also will likely be several vendors involved in the implementation. One vendor cannot do everything. Because of the number of vendors involved in a medium-to-large network, there is almost always inherent integration challenges and roadblocks to real time response in the network.
The ability to achieve a near-real time OSS solution begins with choosing pre-integrated OSS vendors. Many vendors have chosen to partner and integrate their products at various levels. An example could be in pairing a provisioning product with a performance management or service-level-agreement (SLA) product, providing not only the ability to automate provisioning, but also to track performance and SLAs at the point of provisioning. That ties two major components in OSS together for a more streamlined, real time view of the network. Coupling products in this way can enable a faster integration time and better interaction between OSS products.
Even with pre-integration, there are still challenges with any automation process. Although many software-marketing pitches allude to "plug and play" and easy integration, IT departments will still need to take a very active role in implementation and support. No software solution or package will eliminate the need for IT planning and requirements management and common practices.
There are some practical considerations when choosing an overall OSS solution and strategy that can help step service providers through the process. It is very important to continue to refer back to the original goals through this sometimes long and stressful process to make sure that in the end the project is ultimately successful. In reality, there will probably never be an "end," but capability and business milestones can be realized periodically to confirm a successful implementation. Here are some important areas to consider when looking for an automated solution:
·Understand what is trying to be achieved. To achieve a successful result, it is necessary to set specific goals for implementation and make sure that each OSS vendor understands these goals and agrees that they can be achieved. From a high level, these goals appear very similar to what every service provider looks for. But when drilling down to specific business processes—how each organization handles paperwork, customer orders, fault resolution, and billing—those goals can be quite different among service providers. Different companies have different organizational structures. Their business models could also be quite different. The goal for OSS implementation should closely tie into the individual business mode for the service provider. That also keeps the expectations reasonable and not overly zealous. A key factor in the failure of new "e-solution" implementations is lack of a reasonable scope for the project. By defining the scope based on the business model, there is less chance of inaccurate project planning.
·Research the OSS market. Service providers should do their homework to familiarize themselves with OSS providers. That can sometimes be difficult, because vendor brochures and Websites are not always accurate representations of what the "real" product does. That will require time spent with each vendor and referenced case studies of successful multivendor OSS implementations. There could also be some value in spending up-front money to buy independent research to determine how successful a particular vendor has been in the past, their financial stability, and who makes up their current customer base. That gives the service provider an unbiased look at the market rather than filtered references given by the OSS vendor.
·Communicate current business processes. Service providers should make sure that each OSS vendor they work with truly understands their business processes and where handoffs occur. For the OSS vendor to get a feeling of where there are bottlenecks and possible opportunities for automation, the vendor must understand how orders are currently processed, faults are resolved, and customers are billed. Form committees that involve all organizations affected by the implementation, including IT personnel. At every step in the process, the relevant parties should be involved and provide feedback, pointing out possible shortfalls or risks. That ensures there are no black holes where something important might slip through.
·Realize that automation is not the only answer. Avoid any OSS vendor that says automating processes will solve all problems and that a particular product is truly off the shelf. There could be business processes that are not better handled by automation. That depends on the organization and the synergies between people and departments. There are also major staffing impacts to automation. Service providers should feel comfortable with changes in their staff numbers or shifts in future staff positioning. If there are union issues, for example, it may not be possible to replace these staff members with an automation software package because of union agreements.
·Partner with your OSS vendors through implementation. There must also be an understanding that no OSS system is perfect. These systems are in a constant state of evolution. An OSS solution can never truly be finished, because technologies and service offerings change. To win market share, service providers must continually update their ways of bringing new services to market and acquiring and keeping customers. Instead of buying software from OSS vendors and moving on, customers and service providers should build lasting relationships resembling partnerships, with the common goal being success of the service provider. That success will be top priority for the OSS vendor because of the potential business case it provides as a reference to other potential clients.
Considering these key points will not only ensure the expected outcome, but it will also ultimately ensure the service provider can actually deliver to the end customer. Although there are many challenges—and a great deal of time and money invested—it is possible to deploy an effective automated OSS solution. By doing their homework internally as well as externally, service providers can look forward to a more streamlined approach to their business and generating more revenue well into the future.
Chad Leedy is product manager for the service management business unit at Efficient Networks Inc. (Dallas), a wholly owned subsidiary of Siemens Corp. (Boca Raton, FL). He can be reached via the company's Website, www.efficient.com.