AI strategy, the data beneath it, and the systems to run it
Fractionalytics is a fractional Chief Data Officer practice: data strategy, foundations, remediation and customer analytics for companies moving on AI, whose ambitions have outrun the state of their data.
Companies that already bought the AI keep hitting the same wall: the systems underneath disagree about the basics. That work has always been needed and rarely fundable, because nobody could say what it would cost or what it would return. Both of those just changed.
Most companies I meet are not stuck on AI. They are stuck underneath it.
They ran the pilot, bought the license, or built the agent, and it worked well enough to raise the ambition. Then the next step needed two systems to agree on something basic, and they did not. Nobody inside the building can say how far off the numbers are, or why, because the people who built the mess left and the logic lives in dashboards, spreadsheets and three people's heads.
The money for all of it is already gone. The license gets paid every month whether or not anyone can switch it on, and the pilot that worked is sitting next to the one that cannot ship. Getting that spend to return something is most of what I get hired to do, and it is a different conversation from asking for more budget.
What that looks like in practice
A consumer software company had paid for a marketing platform it could not switch on. Two upstream systems disagreed about who the customers were by more than 300,000 records. The license was being paid monthly and returning nothing. The tool was never the problem.
At a payments company, finance and growth calculated profit per transaction differently, millions apart on a single cost line. A new product showed a profit in one report and a loss in the other, and the leadership team could not fund it or kill it.
A customer count came back 1,600 in one system and 14,000 in another. The fix was three workflows, two reports and four filters. The analysis that had been blocked behind it ran the same week.
Remediation, when something is already broken
Part A. Find out what is actually wrong, and stop. A short, bounded look that ends in a decision rather than a report: what is broken, which of those are costing you something now, and what each would take to fix. If you go on to the build, this comes off the price of it. If you do not, you still own the map.
Part B. Fix the things worth fixing. I own detection, matching, triage and measurement. Your team owns the source-system changes and the business calls about what a number should mean, because those are not mine to make. Weeks rather than months, and the measurement is agreed before the work starts so that "done" is not a matter of opinion.
Part C. Keep it from happening again. The reason this work has historically been thrown away is that nothing captured what was learned. Every definition settled, every rule agreed and every fix made becomes something the business owns and the next AI project stands on, rather than tribal knowledge that leaves when someone does.
Diligence, before you own it
The three parts above are what happens once the company is yours. Diligence asks a different question, for a different person, at the only moment it can be asked: what are you actually buying?
A customer base audit. Cohorts, concentration and payback rebuilt from the event logs or transaction records, with the segments carrying the thesis named. Concentration first, because revenue resting on a few customers is a risk the multiple should price.
A data condition review. Which reported numbers come from a system, and which get rebuilt in a spreadsheet every month. Manual processes pass diligence intact and then set the ceiling on the operating plan, because every initiative built on those numbers inherits the manual step.
An integration cost estimate. Every add-on is a data integration event and the target's definitions will not match yours. That cost is knowable before you close, and it is usually discovered in month four.
This is diagnosis, not remediation. If everything is in decent shape, that is the finding and you can stop.
Fractional CDO, when it is not one thing
Sometimes it is not one broken thing. What I hear is a version of the same sentence: we want to be data-driven and AI-forward, and we are having trouble getting there.
The answer is never one thing either. It is a combination, and which part is binding differs every time.
- Do you have the right people on the bus, and are they in the right seats?
- Does the business trust its data?
- Where are the quick wins?
- Is the tool stack getting in the way?
- What is the company spending on this team, and what is it getting back?
Trust is usually the long one, and you can hear it in the meetings. Finance does not trust what marketing is saying and marketing does not trust what finance is saying, so all they do is argue about the numbers rather than take action and grow their business.
The tool stack question runs the whole gamut, from how the data comes in to whether what comes out is trustworthy enough to point AI at. One company had Snowflake with a pile of views built on top and nothing managing any of it. We rebuilt that layer in dbt.
The last question is the one that rarely gets asked out loud. Some of what a data team returns is intangible, and that is fine, but the ROI equation is still real and it can be improved.
Data is a business discipline much more than it is a technical one.
How you buy it
Three shapes. Which one fits is a question about the work, not about price.
| Shape | When it fits |
|---|---|
| A block of hours | Time and materials. Spot work, and problems nobody has scoped yet. |
| A fixed-scope project | A statement of work, with the measurement agreed before it starts. Right once Part A has told us what we are actually fixing. |
| A fractional CDO basis | When the problem is pervasive enough to need someone embedded with your team over an extended period, rather than a bounded piece handed back at the end. |
Which of the three it is depends on what we are trying to accomplish, and that is a conversation rather than a form.
I sell no software and take no vendor commissions, so when the answer is that a tool you are considering will not do what you need, that is the answer you get. It is the same reason I am useful in the room when two departments are both convinced they are right: I have nothing to defend.
More about how I got here, including the roles, the systems and the education behind it.
Why the economics changed
Data remediation has always been needed and rarely funded, because nobody could size it or say what it returned. Both halves of that moved. The value went up, because clean data is now the difference between an AI initiative that gets believed and one that quietly stops being used. The cost came down, because the archeology, working out what a system does and why it disagrees with its neighbor, is the part that used to take months of expensive people and is now the part that compresses most.
That is an argument about economics, not a payback model. Anyone who hands you one of those before looking at your systems is guessing.
Start with the Ladder Check
The Ladder Check is a short self-assessment on this site that takes about three minutes and ends in a named result rather than a score. One person can answer all six from memory, with no meeting and no data pull, and one of the outcomes is that you are fine and should go spend the money on the AI itself.
Read the argument
I write about where AI ambition meets the state of a company's data. The current series runs through how far up the ladder a company can get before its answers stop agreeing, and what changed in the economics of customer analytics. Before either of those, the more ambitious you get with AI, the faster you hit a wall is the short version of why any of this matters.
For the work rather than the argument, the unsexy data work that actually matters is the full account of a six-month remediation, and look at the stars is where the customer analytics thinking started.