QueBIT routinely works with clients that have either selected a poor-performing planning software tool, or who are suffering from the poor implementation of a good planning software tool. Both of these scenarios-- bad software and a bad implementation-- can dramatically hinder the cross-functional planning process and make improvement efforts less impactful and responsive. The challenge for a given client often then comes in recognizing which scenario applies to the situation at hand. Is this client underperforming because their software isn't a good fit? Or is it really about how the software is set up inside that particular company?
Separating out these two scenarios is an important part of requirements gathering and defining the current vs. future state in the planning process. Understanding the pain points that stakeholders have today can help avoid those challenges in the future and result in a more successful project. Clients often can't or don't distinguish between these two states, either, due to lack of separation (they are too close to the system) and lack of experience with systems and data. That's where QueBIT's expertise can help!
The list below outlines what QueBIT has recognized as key factors in identifying root issues to resolve. This isn't an exhaustive list, but rather a set of areas to explore that can indicate where the real problems lie. QueBIT's Point of View (POV) is based on hundreds of successful system implementations.
Manual Data Manipulation
- Status Quo: Manual data manipulation required before or after a plan, budget, or forecast is updated. This is often because of a lack of integration, multiple systems, and disparate data sources that aren't automated.
- Verdict: Bad Implementation
- QueBIT POV: The focus of planning is making decisions based on the best forward-looking view the company can put together. Too often, the focus becomes piecing data together and re-mapping data that comes from various systems then having a power user add it all up. Manual data manipulation doesn't have to be a major component of the plan-- integration between source systems, data warehouses, and planning systems is easier and simpler than ever. Do the work upfront to eliminate manual data work-- it slows down planning, introduces risk of errors, and makes changes more difficult. The ideal implementation will automate the inbound and outbound data related to planning.
It Is Still Hard to Make a Decision
- Status Quo: The planning software doesn’t help users make a business decision. Users need significant additional data, outside schedules, and experience to make a business decision around financial and operational forecasts.
- Verdict: Bad Software
- QueBIT POV: Planning software should guide users to making a decision of some sort: a consensus plan, an earnings target, a set of assumptions related to operations or market conditions. Too often we see clients who spend time compiling and creating forecasts in their planning systems only to export that information to a reporting system and decisions are made offline or after some additional analysis in Excel. The planning systems we implement allow users to build from the bottom up and from the top-down at the detailed level, but they also include dashboards, summaries, and key metrics. Users need all of this working together to make business decisions. Without it, a client may have bad software.
The Tool is Overly Complex to Maintain
- Status Quo: The planning system is complex, costly, or slow to update and maintain. It is difficult to make changes and often times requires an obscure technical skillset to make basic changes.
- Verdict: Tie, could be either
- QueBIT POV: This can be both or either! A complex system can be bad or good. But maintenance and enhancements to a planning system should be relatively straightforward. In the best case most development after implementation can be done by power users or a Center of Excellence (COE), without the need for developers. Complex scripting languages or the need for obscure tools can also make a system overly complex to maintain, and currently finding employees with the right skillsets can be difficult.
User Adoption Lags behind Expectations
- Status Quo: Stakeholders are tied to their old processes or tools, or have tried the new system to just revert to Excel for planning and collaboration.
- Verdict: Bad Implementation
- QueBIT POV: Getting users to adopt a new system should mean getting them to adopt new business processes too. Stakeholders have to be identified and involved in the process. End users need to be heavily involved in the User Acceptance Testing (UAT) process. If the implementers skipped any of these steps, the project is likely to have lower user adoption because the people who should be using it aren't invested. It is human nature for people to support what they create-- even if the end users didn't develop the system they need to feel like they helped create it or else they won't support it.
Performance and Scale is a Problem
- Status Quo: Performance is poor, with reports or the User Interface (UI) taking too long to generate or the system can't support the level of detail needed
- Verdict: Tie
- QueBIT POV: This is a common challenge, and one that can be difficult for end users to fully appreciate. Getting a planning system to scale can be a highly technical effort, so determining if a poor implementation of the system is to blame can be difficult. However, in the end, it doesn't matter. A planning system should scale to the level of detail and volume required to support the business. QueBIT's default approach is to build systems at the lowest level of detail possible (where transactions happen) which is frequently the SKU or item level. End users may provide input at a higher, aggregate level, such as a product category, but the detail is always there. Getting a system to support such a design is important to get right.
If any of these conditions sound like your daily planning system challenges, please reach out to discuss more with a QueBIT expert at info@quebit.com.
