Evaluation of TM1 Support Models
Unified Managed Services
A fluid capacity model combining development and support resources.
| Primary Goal |
Total Cost of Ownership optimization |
| Key Paradigms |
Break-fix, Pyramid Staffing, Unified Hybrid |
I've managed enterprise finance models for a decade, and I just realized this about IBM Planning Analytics (TM1) support: we treat it like insurance when we should be treating it like an engine. When your environment breaks during month-end close, the stress is immediate. But the way most finance teams try to solve this structural risk usually falls into two traps—either paying a global consultancy for an army of junior developers you don't need, or signing a break-fix contract that leaves you stranded when you actually want to build something new.
This guide breaks down the true cost of the three dominant TM1 support models in Australia, providing a clear framework for how finance leaders should evaluate their managed services spend and Total Cost of Ownership (TCO).
1. The 3 Archetypes of TM1 Support
Before you lock into a multi-year Service Level Agreement (SLA), you need to understand the structural incentives of the vendor you are hiring. The market generally segments into three archetypes.
Archetype 1: The Ad-Hoc Break-Fix Shop
This model looks the cheapest on paper. You pay a retainer or an hourly rate, and when a TI process fails or a cube crashes, you submit a ticket. They fix it, bill you, and leave.
The Hidden Cost: "Break-fix" strictly means they only fix what is broken. If your finance team wants to optimize a sluggish forecasting cube or develop a new reconciliation workflow, you have to spin up a completely separate statement of work (SOW). This stalls momentum. Worse, because the vendor only engages when things break, they have zero incentive to proactively optimize your environment to prevent future breaks.
Archetype 2: The Global "Pyramid Staffing" Consultancy
This is the default for many enterprise teams. You hire a massive, globally recognized firm. They sell you a massive block of hours, put a senior architect on the pitch deck, and assure you that you have "24/7 global coverage."
The Hidden Cost: Pyramid staffing. To maintain their margins, these firms hand the actual ticket execution to offshore junior developers. You pay a premium for the brand name, but your internal finance team still spends 15 hours a week managing the provider, explaining basic business logic to junior staff, and escalating tickets until they finally reach the senior architect you met in the pitch.
Archetype 3: The Unified Hybrid Subscription
This is the model mature TM1 environments are moving toward. Instead of walling off "support" from "development," the vendor treats both as a single, fluid resource. You subscribe to a predictable capacity block, and the vendor uses senior consultants to proactively manage, fix, and build.
2. Worked Example: The ROI of Unified Support vs. Break-Fix
Fig. 1: Structural cost breakdown contrasting the rigid steps of ad-hoc SOWs against the agility of fluid capacity.
Let's look at a real scenario. A mid-sized retail client has a mature TM1 environment. They experience about 10 routine support issues a month (password resets, minor rule tweaks, data load errors). However, they also have a backlog of development work: they need a new CapEx forecasting dashboard and a faster daily sales load process.
- Under Break-Fix: They pay $2,000/month to resolve the 10 support tickets. For the CapEx dashboard, they wait 3 weeks for an SOW, pay an additional $15,000 project fee, and spend internal hours managing a new project team. Total cost: high. Agility: near zero.
- Under Pyramid Staffing: They pay $10,000/month for a block of 50 hours. The junior team burns 20 hours struggling through the 10 support tickets because they don't understand the client's chart of accounts. The remaining 30 hours are slowly dripped into the CapEx dashboard, but progress is halted constantly for "escalations."
- Under a Unified Subscription: They pay a flat monthly rate for a set capacity (e.g., 20 tickets or 40 hours). A senior developer knocks out the 10 support tickets in 5 hours. Because the capacity is fluid, the senior developer immediately pivots the remaining 35 hours into building the CapEx dashboard. No SOWs. No delays. If hours aren't used, they roll over to the next month.
3. The Keepable Reference: Evaluating Support Models
Use this table to benchmark your current provider against the market standard.
| Feature |
Break-Fix Shops |
Global Consultancies |
Unified Subscriptions (Octane) |
| Predictable Cost |
Low (Spikes with SOWs) |
High (Large monthly retainer) |
High (Fixed monthly capacity) |
| Consultant Seniority |
Variable |
Junior (Pyramid model) |
Senior-Led |
| Development Agility |
Requires new SOWs |
Slowed by escalations |
Fluid (Same subscription) |
| Rollover Hours |
Rarely applicable |
Use it or lose it |
Standard practice |
4. The Ultimate Evaluation Checklist
Before you sign or renew your next managed services contract, force the vendor to answer these five questions on the record:
- "If my system runs perfectly this month, what happens to the support hours I paid for?" (If they say "use it or lose it," you are buying insurance, not support.)
- "Can I use my routine support hours to fund new development work without signing a new SOW?"
- "Who specifically will be answering my tickets on a Tuesday at 2 PM, and how many years of TM1 experience do they have?"
- "Do you offer rollover hours for unused capacity?"
- "Are you proactively monitoring my cube performance, or do you only log in when we raise a ticket?"
5. The Octane Approach: Fluid Capacity
This structural flaw in the market is the exact reason we built the Octane Blue and Octane Black support models.
Instead of forcing finance leaders to guess how many support tickets versus development hours they need, Octane clients subscribe to a single, predictable capacity block. If nothing breaks this month, you can use those exact same tickets to have our senior developers build a new forecasting cube or optimize an existing rule base. If you don't use the capacity, the hours roll over. There are no separate contracts for support and development. It is completely unified.
We do not use pyramid staffing. When you submit a ticket to Octane, it goes directly to a seasoned Planning Analytics developer who actually understands your financial models.
At Octane Software Solutions, we think you should get value out of your TM1 environment whether it is broken or running perfectly. If you are tired of managing your managed service provider, let's look at your current support spend and see if a fluid, unified model fits better.
6. References & External Reading
Leave a comment