How Not to Fail Your Planning Automation Project
Recently, I attended a conference featuring presentations on our Abylon Rapid Planner. I won’t delve into how the presentations went (though they were fantastic), but one story particularly resonated with me. It detailed the reasons behind implementing our solution from our customer’s perspective—a perspective that could also be valuable to you.
As a software company, we developers often miss the direct motivations behind why customers choose us or our products. This story shed light on those motivations in a way that felt like a light bulb moment, prompting me to share some insights from it.
Here’s the gist: a large, international software company had previously attempted to implement a planning solution from another provider, but it failed. The end-users couldn’t adapt to the new system.
You might think, “So what? Doesn’t everyone believe their solution is the best?” I agree to some extent, but this statement stuck with me: How could such a prominent company, which also develops software requiring user adaptation, fail to acclimate its own users to a new system that had presumably already been implemented?
Why would a CFO declare a software implementation a sunk cost (likely his project from the start), only to initiate a new one with a different planning solution?
The answer was simple yet profound: user acceptance.
Why is user acceptance so important?
As a software company themselves, what sets one planning software apart from another regarding user acceptance? In planning processes, users generally don’t have much time to familiarize themselves with a new User Interface (UI). Planning is not a daily task—it often occurs quarterly, semi-annually, or annually, and for the biggest companies, perhaps monthly but never daily.
Each new planning cycle requires users to reacquaint themselves with the software, remembering where everything is located. Without an intuitive UI, this reacclimation becomes a significant hurdle.
Raise your hand if you’ve tried using software specifically “built for planning” but spent your first several attempts just figuring out how to input and save data correctly, ensuring you don’t overwrite necessary information but still place new data correctly.
I’ve been there, and it was far from pleasant.
What are the alternatives? Reverting to Excel files might please end-users familiar with the format, but it burdens controllers who then manually validate, consolidate, collect, and distribute everything. Or, we could insist that end-users adapt to the new UI, which typically results in two scenarios:
- You provide 24/7 support to help end-users navigate the new system.
- You let them figure it out, likely resulting in controllers manually correcting incomplete data later—and possibly reverting to Excel files for familiarity between end-users and controllers.
Consider the costs and efforts wasted when it becomes clear that a solution intended to reduce expenses actually reallocates those expenses to other tasks.
Also, consider the courage required to acknowledge such a setback post-implementation—I believe this must have been incredibly challenging for some.
So, why is our solution different?
We integrate Excel as the front end of our solution, combining the familiar environment of Excel with the robust features of a dedicated planning product.
Common questions might include:
- Can I modify the Excel file as needed?
- How do we prevent an end-user from updating the Excel template used for displaying and saving data?
- Is there a workflow for approving or rejecting plans?
- How are the Excel files or templates distributed to end-users?
- How do we prevent users from altering each other’s data?
These are valid concerns, and addressing them is key to ensuring our solution not only meets but exceeds user expectations without sacrificing controller efficiency.
I’m happy to answer these, or any further questions.
Other popular blogposts about the Rapid Platform and our FP&A solution Abylon Rapid Planner:
Author of the post:
Zsolt Kreisz - Financial Controller in the past, now BI Developer at Abylon Consulting. Linkedin Profile
