If you’re looking at automating a new system, here’s a cheat sheet to help you avoid common pitfalls.
Here at QueBIT, we have developed hundreds of solutions for our clients. That’s as expected, it’s our
Note: Some of the examples in each of the pitfalls listed below are Planning Analytics and TM1-focused, but the pitfalls themselves apply to almost any planning, analytics, or predictive implementation.
I’ve been involved in dozens of sales cycles, where a client is evaluating alternatives for a planning model, a sales forecast, or an operations dashboard. One thing I’ve noticed is that people put a significant amount of time into evaluating the software options, comparing features, pricing, and technical requirements. That is as expected, after all, you want to get the best product money can buy!
After carefully analyzing the system costs and features, most people don’t put much (or any) time into evaluating the team that will actually implement their solution. This is equally, if not more, important, than the product decision. After all, what good does it do you to have the best product on the market, if it is implemented poorly?
How to Avoid this Pitfall:
Even out-of-the-box solutions need care and feeding to be successful. Change is hard, we all know that, and organizational change, involving many people and processes, is even harder. Getting a new system in place is change, and it is much more likely to succeed if someone is passionate about making it happen.
It is difficult to have business users engage during a development cycle, because they already have full-time jobs! But, without critical input from the business, the solution is likely to fall short and not meet their needs.
How to Avoid this Pitfall:
It is a common mistake to design a solution around the source data—especially if the developers do not have business backgrounds. This is backwards. Data can, and should, be integrated on the back-end so that end-users have a common, seamless experience on the front-end. This applies to everything from the conceptual framework of a model to something as mundane as naming conventions.
Look to the business processes being served, and the desired end result, to drive your approach. For example, make metrics data like headcount, square footage, and units sold readily available alongside financial data, in order to streamline KPI calculations, and to more easily integrate driver-based data directly into your models.
How to Avoid this Pitfall:
So you’re finally getting that new planning system, and you’ll be able to retire your convoluted spreadsheets—kudos! Sometimes, people are so excited about centralizing a process that has been cumbersome and manual, they just want to automate everything about it right away. Keep in mind that making any business process more streamlined and centralized also generally means making some hard choices about calculation methods, naming conventions, and data definitions. Ease your co-workers into this by keeping some flexibility in your model. A model that is overly boxed-in with calculations, for example, could frustrate the forecasters who need to override a particular calculation as business needs evolve.
If you have a well-planned process that is accepted and understood, then go for it! Otherwise, take it slow.
How to Avoid this Pitfall:
People are not computers. Even if your new planning (or sales forecasting or operations analysis) system is the cleanest, simplest, easiest to use web-based application, your adoption will flounder if you don’t pay attention to roll-out. This falls under the same “change is hard” heading as #2, above. The best timing for a system is to roll it out at least a quarter before you really need it, to give users a chance to simply consume reports and perhaps start doing some small things, like entering variance commentary, before they are using the system to generate their plan.
A strongly supported roll-out not only increases adoption significantly, but it helps your organization start to grow your own internal resources, such as power users, that will fuel further growth for your solution.
How to Avoid this Pitfall:
A closing note: Celebrate your victories along the way! Post-project, your new implementation may be live in production, with many happy users, but it will still likely be a work in progress. A healthy implementation is one where change is controlled, but frequent, to ensure that the system stays relevant to the organization’s changing needs. So take the time to pause and recognize how far you’ve come from time to time. It will pay dividends for ongoing usage, and adoption.