RFAssurance Knowledge Share

Case Studies, Software Features, Announcements and more...

The Engineering Cost of Tools

on January 6, 2014

The wireless industry has embraced the need of tools for every aspect of an engineers job tasks. There is tool to run designs, visualize the customer issues, adjust parameters, recommend changes, and just about anything else an engineer my do. Most of these tools were created to fill a need whether through creating efficiency, incorporating a knowledge set, or expanding a capacity. Every tool has costs and typically creates some sort of savings, but what is the long term cost. Not in term of support, maintenance, continued development; rather, in terms of engineering know-how. How often do engineers plug inputs into the tool, crunch the output, and send out the report. Only later do we figure out the output from the tool is actually incorrect. Over time engineers no longer understand the fundamentals of what a tool is doing, so in turn they don’t understand the output versus the expected.

It is this loss in fundamental understanding that actually may cause harm to the networks the tools are efficiently engineering, as well as a long term tool path based on misinformation. In no way should tools be discouraged in engineering, rather the opposite. More tools for comparison and understanding should be made available to engineering teams. Further, the time to look at tools and understand them to ensure the outcomes meet the expectations. SON tools appear the largest detractor in these approaches. SON tends to be another word for “black box” in which changes to a network are automated and continual. Evaluation and understanding of the changes rarely occurs. Impacts are measured by KPIs which may or may not even be representing the customer experience.

With today’s complex networks, engineering teams have less time available to research and evaluate tools. In the “do more with less” approach for engineer teams, time available and need for efficiency is vital to the success of these networks. Organizations should consider focusing engineers in regards to tools and ensure the proper continual feed-back loops are implemented rather than relying on corporate based teams that are not directly accountable to the market metrics and daily activities as most tools are now evaluated. Suggested means may include:

  1. Field implementation and weekly/monthly market team feedback.
  2. Allow for market level tool introduction and utilization. One tool isn’t right for every market/region.
  3. Continual tool training with tool SMEs to answer technical descriptions rather than typical tool operational questions.
  4. Allow access to datasets for in-house tool development. Allowing for understanding and efficient customized approaches to direct problems faced.
  5. Utilize tool usage based metrics and then support tool vendors in facing end users rather than corporate buyers.

The goal of tools should always be to reduce costs, increase efficiency, and improve networks. This goal should not come at a long term cost of engineering knowledge. If engineers continue to slow in understanding what tools do, the risk is the network experience on the customer as well as organizational reliance on tools which due to wireless tool specifics will actually increase costs to vendors. If knowledge in the organization is being lost over time due to tools, new means of educating the end user will be required to regain it.

The Engineering Cost of Tools

Related Posts

Take a look at these posts