Archive

Tag Archives: ai

The $286,000 Ghost on the Payroll: The Randstad Case

By
September 3, 2026
Uncategorized
Leave a comment

In 2009, a former branch manager at Randstad was sentenced to five years and one month in federal prison for wire fraud and aggravated identity theft. The scheme ran for three years before anyone caught it. The method behind it was almost boring, which is exactly why it worked.

What happened

Cynthia Whitehead used the real names of former Randstad employees, people who had already left the company, to generate wage payments through the payroll system. She then kept those “wages” for herself. From 2004 to 2007 she embezzled more than a quarter of a million dollars this way. She pleaded guilty on July 8, 2009, and was ordered to pay $286,388.37 in restitution on top of the prison sentence.

Nobody defeated a clever fraud control here. The scheme worked because a former employee’s identity remained valid and payable inside the system long after that person had stopped working there.

Why the gap existed

The failure point sits exactly at the boundary between two systems that were supposed to agree with each other: HR, which knew someone had left, and payroll, which kept generating payments as if they hadn’t. That boundary is where this kind of fraud always hides. It isn’t defeating a rule. It’s exploiting the fact that two systems of record were allowed to disagree for as long as nobody checked.

A termination event should be the kind of thing that instantly and automatically closes off every downstream ability to pay that person again. In practice, in a lot of ERP implementations, it’s a status field that gets updated in one module and trusted to eventually matter everywhere else. Three years of undetected fraud is what “eventually” costs.

Controls that would have caught it

The control here isn’t exotic. A payroll run should not be able to issue a payment to any employee ID with an active termination date, full stop, checked at the moment of disbursement rather than assumed from a status flag set once and never re-verified. In practice, this means the integration between the HR module and the payroll module needs to function as a hard gate on every pay run, not a background sync that payroll happens to respect most of the time.

The harder part isn’t designing that rule. It’s noticing that it needs to be designed at all, because on paper the termination process already “worked.” The employee’s status did get updated. Nobody had built the check that made that status update actually block a payment.

An AI prompt example for ERP fraud detection

This is a case where an AI-assisted review layer earns its keep, not by replacing the underlying control but by making it cheap enough to run constantly instead of only during an annual audit. Against the ERP’s HR and payroll data, a controller could run something like:

“List every payroll disbursement in the last three fiscal years paid to an employee ID with a termination date recorded prior to the pay period start date.”

A second, complementary query catches slower variants of the same pattern:

“Flag any employee ID that received a payment more than 30 days after their most recent termination or leave-of-absence date recorded in HR.”

Neither prompt requires new system functionality. Both require someone to think to ask the question on a recurring basis rather than only after a tip or an audit forces the issue. That is the actual lesson of this case. The rule that would have stopped it wasn’t complicated. It just wasn’t being asked.

The pattern for this series

This is the first case in a series looking at real, documented ERP fraud schemes: what happened, what shared assumption in the underlying system let it run, what a properly governed control looks like, and a concrete AI prompt that turns a periodic audit question into something that can run continuously. The goal is never to suggest AI replaces the governance. It’s to show what becomes possible once the governance exists and someone actually asks it the right question.

Source disclaimer

The case details in this article are drawn from a press release published by the U.S. Attorney’s Office for the Northern District of Georgia, a public government source. All facts, figures, and quotations describing the case are sourced from that release. The analysis of the control gap, the proposed detection controls, and the AI prompt examples are original commentary and are not part of the source material.

References

United States Attorney’s Office, Northern District of Georgia. “Former Randstad Branch Manager Sentenced to Federal Prison for Embezzlement.” Press release, September 16, 2009. https://www.justice.gov/archive/usao/gan/press/2009/09-16-09c.pdf

Time and Tokens

By
August 31, 2026
Uncategorized
Leave a comment

There used to be a saying in the business world: everything can be done with time and Excel. Give a competent analyst enough hours and a blank spreadsheet, and there was no forecast, no reconciliation, no reporting problem that couldn’t eventually be solved. Excel wasn’t fast. It wasn’t elegant. But it was infinitely general purpose, and it always did exactly what you told it to do, cell by cell, every single time.

The saying is starting to change. People are now saying everything can be done with time and tokens.

It’s worth taking that seriously, because it’s not just a joke about AI hype. Something real shifted underneath it.

What Excel actually required

The old saying hid a dependency that everyone quietly understood. Excel could do anything, but only if a human already knew what “anything” looked like. Someone had to understand the business problem, decide what the model should compute, structure the formulas, and catch the errors when a dragged cell reference pointed at the wrong row. The tool was general. The thinking was not automated at all. Time, in that saying, mostly meant the time it took a skilled person to build and rebuild the model until it matched reality.

That is why “time and Excel” was a saying about human effort as much as it was about software. The spreadsheet was a canvas. The intelligence was still entirely yours.

What tokens change

A large language model flips part of that arrangement. You can now describe a vague, half formed problem in plain language and get something usable back without doing the structural thinking first. The model proposes the categories, drafts the formulas, writes the summary, or builds the first pass at a plan. Tokens, in the new saying, stand in for both the words you feed the model and the compute it burns iterating toward an answer.

This is a genuine capability shift, not just a rebrand of the old joke. With Excel, the bottleneck was almost always model construction. With a language model, the bottleneck moves toward specification and verification. You spend less time building the machine and more time describing what you want and checking whether what came back is actually right.

That is a real change in where human effort goes. It is not a small one.

Where the analogy breaks

It would be tidy to say tokens simply replaced Excel, but that’s not quite what’s happening, and the difference matters more the higher the stakes get.

Excel’s defining property was determinism. A formula produces the same output from the same inputs every time, and you can trace exactly why. That traceability is not a nice to have in finance, operations, or compliance work. It is the entire point. An auditor does not want to hear that the number is “probably right.” They want to see the formula.

Tokens do not offer that guarantee. A language model produces a plausible answer, and plausible is doing a lot of work in that sentence. Ask the same question twice and you may get two different, both reasonable sounding, results. For a first draft, a brainstorm, or a rough model, that is a feature. For a general ledger reconciliation, it is a liability.

So the honest version of the new saying is not that tokens replaced Excel. It is that tokens increasingly generate the Excel. The model drafts the formula, proposes the pivot, writes the first pass at the model, and a deterministic engine, spreadsheet or database or ERP calculation, still does the actual execution. The two are stacking, not swapping.

The bottleneck didn’t disappear, it moved

The old saying implied that with enough time, Excel could solve anything, and the effort lived in building the model correctly. The new saying implies that with enough tokens, a model can solve anything, and the effort lives somewhere else now: in asking the question well and in checking the answer carefully.

That is arguably a harder skill to teach than spreadsheet formulas ever were. A bad formula usually breaks visibly. A bad prompt often produces something that looks complete and confident and is wrong in a way that takes real domain knowledge to catch. The scarce resource used to be knowing how to build the model. Increasingly, the scarce resource is knowing enough about the problem to tell a good answer from a good sounding one.

Why this should sound familiar

Anyone who has sat through an ERP vendor demo has already seen a preview of this exact pattern. The demo always ends the same way: with the confident implication that the software understands your business and can just handle it, no configuration debt, no data cleanup, no edge cases. Excel never made that promise. It never pretended to understand your problem. It just calculated exactly what you told it to.

Tokens, by contrast, come wrapped in the same confident tone as the demo. The output reads fluently. It sounds like understanding. Whether it actually reflects your business, your chart of accounts, your specific edge case, is a separate question that the fluency does nothing to answer.

That is the real risk in the new saying, and it has nothing to do with the technology’s capability. It is the same trap the old vendor demos set: mistaking a confident answer for a correct one. Excel forced you to see your assumptions in the formula bar. Tokens can hide them in a paragraph that sounds like it already checked.

The updated version

Everything can still be done with time and Excel. That has not stopped being true. What’s changed is that tokens now do a lot of the early modeling work that used to eat the time. The saying isn’t wrong to update. It’s just missing a clause.

Everything can be done with time and tokens, as long as someone still knows enough to check the work.

Is Vibe Coding the End of Standardized ERP?

By
August 27, 2026
Uncategorized
1 Comment

I have heard rumours that some companies are starting to vibe code their own ERP systems. Is this the start of the decline of standardized ERP systems, and the start of company specific Business Operating Systems? If every business had its own OS, and an agentic framework, why is there any need to have standardized ERP systems?

It is a fair question, and one worth taking seriously instead of dismissing on reflex. But after digging into what is actually happening in the market, I do not think ERP is dying. I think something more interesting and more useful is happening at its edges.

What Companies Are Actually Vibe Coding

The companies experimenting with AI generated business software right now are almost entirely building at the periphery of ERP, not in its core. A Copilot Cowork style agent that reconciles a report. A custom approval workflow. A data cleanup script. A bolt on dashboard that nobody wanted to wait six weeks for IT to build. Very few organizations are vibe coding their general ledger, their costing engine, or their multi entity intercompany eliminations, and there is a good reason for that.

There is a real gap between “AI helped me build software” and “AI helped me build enterprise grade, auditable, multi user, transactionally consistent financial software.” That gap is where most of the current enthusiasm quietly runs out of road. One recent piece on the risks of vibe coding put it plainly: the danger is not that these tools fail to work. The software appears to work right up until the business reaches a level of complexity that exposes what was never built in the first place. Security, monitoring, compliance, and disaster recovery do not show up in a demo. They show up eighteen months later when something breaks and there is no vendor to call.

We Have Been Here Before

There is also a useful historical echo worth remembering. Standardized platforms like SAP, Oracle, PeopleSoft, and later NetSuite and Salesforce did not emerge in a vacuum. They emerged because “build your own” had already been tried extensively in the eighties and nineties, and the industry collectively decided that a professionally maintained, continuously improved, shared system was the better bargain. One system, supported by a vendor with thousands of customers absorbing the cost of getting tax law and audit controls right, beat a thousand bespoke systems each carrying that burden alone.

Vibe coding does not remove the reasons that decision was made three decades ago. It just lowers the upfront cost of relearning them the hard way.

Two Layers That Want Different Economics

The question of “why standardize if every business can have its own OS” collapses two layers of the business that actually want very different things.

The first layer is the system of record. This is the ledger, inventory, costing, tax, and consolidation logic. This layer wants low variance, not customization. Its value comes from being provably correct under audit, from producing the same math every quarter regardless of who is running the company, and from a vendor carrying the liability of getting VAT rules or SOX controls right across thousands of customers instead of one company carrying that risk alone. Agentic capability does not change the incentive to pool that risk and cost across an ecosystem. If anything it raises the stakes, because an agent posting a bad journal entry at two in the morning with no human review is a considerably scarier proposition than a person doing it.

The second layer is orchestration. This is how a specific company actually gets things done around that system of record. This is exactly where variance is valuable, and exactly where agentic frameworks and vibe coding are already winning, because it is low blast radius, fast changing, and does not need to survive a financial audit on its own merits.

The Composable Core, Not the Bespoke Empire

So the more likely outcome is not that every business ends up building its own ERP from scratch. It is something closer to a composable core: a thin, standardized, vendor maintained transactional spine, surrounded by a thick, company specific, largely agent authored layer of workflow, automation, and decision logic that talks to that spine through APIs. This is not a new architecture invented for the agentic era. It is basically the direction that platforms like Dynamics 365 Finance and Operations were already heading, with data entities and business events designed precisely so that logic could live outside the core without touching it.

The Business Operating System that gets discussed in these conversations is real. But it gets built on top of standardized ERP, not instead of it, because nobody actually wants to own tax engine liability, and no CFO wants to explain to auditors that the general ledger was vibe coded last quarter.

Where the Real Disruption Sits

If I had to point at where this trend genuinely threatens the standard ERP model, it would be three places.

The mid market and small business segment, where compliance and audit stakes are lower and the cost of a full ERP license and implementation is disproportionate to the size of the operation. This is where skipping a Tier 2 ERP entirely in favour of an agentic build of the operations layer is most economically rational.

Verticals with no good off the shelf fit, where companies already customize ERP into something barely recognizable compared to the base product. Vibe coding just makes that customization faster and cheaper. It is not a fundamentally new behaviour, it is an acceleration of an old one.

And the vendors themselves, who will not sit still and watch this happen. Expect Microsoft, SAP, and Oracle to lean hard into a “we are the trusted core, bring your own agents to the edges” positioning rather than fight the trend directly. Given where Copilot and Cowork are already headed inside the Microsoft ecosystem, this is not speculation. It is already the direction of travel.

The Verdict

Vibe coding is not the death of standardized ERP. It is the arrival of a cheap, fast way to build the layer of the business that ERP vendors were never well suited to build in the first place. The ledger stays boring, standardized, and vendor owned, because boring is exactly what you want from something an auditor has to sign off on. Everything wrapped around it just got a lot more interesting.

Autopsy #10: The AI For The Sake Of AI Demo

By
August 25, 2026
Uncategorized
Leave a comment

Cause of death: a button that already worked got wrapped in a chat box and called intelligent.

The feature existed before the demo did. Somewhere in the product, there was a dropdown, a rule, a scheduled job, something deterministic that took an input and produced a correct, predictable output every time. Then, at some point in the last two product cycles, that same feature got a new front door: a text box, a little sparkle icon, a placeholder that says “ask me anything.” Now, instead of picking a value from a dropdown, you type a sentence, wait a beat, and the same output appears. The presenter calls this AI. The room, primed by two years of hearing the word everywhere, nods.

Nobody asks the obvious question: was this better before, and did anyone check.

What actually happened

Somewhere inside a lot of “AI-powered” features sits a deterministic operation that a rule, a formula, or a simple lookup already handled correctly and quickly. Wrapping that operation in a natural-language interface doesn’t make the underlying logic smarter. It adds a translation layer, one that has to interpret an unstructured sentence and map it back onto the same structured operation the dropdown was already doing directly, with total accuracy, in a fraction of the time.

That translation layer isn’t free. It introduces a new failure mode that didn’t exist before: the AI misreading the sentence and selecting the wrong option, a phrasing the model hasn’t seen before returning an unhelpful answer, latency where there used to be an instant response. None of this is inherent to AI as a category. Plenty of genuinely AI-native capabilities do things no dropdown ever could: summarizing an unstructured document, drafting a first pass at something that has no single correct answer, flagging an anomaly buried in a pattern too complex for a fixed rule to catch. The problem in this specific demo isn’t that AI was used. It’s that AI was used to solve a problem that was already solved, by something more reliable, and the swap happened anyway because AI is what gets funded, marketed, and put on a keynote slide this year.

The tell is almost always the same: watch what happens when you ask the natural-language version to do something slightly outside the phrasing it was tuned on. The dropdown never had this problem, because a dropdown has no phrasing to be tuned on. It just has options.

Why it works on smart people

Nobody wants to be the person in the room who seems skeptical of AI in a year when every vendor, every board deck, and every competitor’s marketing has decided AI adoption is the metric that matters. Asking “why does this need to be a chat interface instead of the three-click menu it replaced” risks sounding like you’re behind, not like you’re asking a reasonable engineering question, and that social pressure runs in exactly the wrong direction. It rewards accepting the AI wrapper uncritically and punishes the person who’d actually stop to check whether it improved anything.

There’s a second, quieter dynamic on the vendor side that compounds this. Once a company’s roadmap and marketing commit to being an “AI-first” platform, there’s organizational pressure to retrofit AI onto existing features whether or not doing so improves them, because a product review, an investor update, or a competitive comparison chart wants to see the AI checkbox filled in across the board, not filled in only where it was actually the right tool.

The actual damage

This is the one that costs you reliability you already had. A feature that used to return the same correct answer every time now returns a slightly different answer depending on phrasing, and the variance itself becomes a support burden, because now every unexpected result needs to be triaged as either a real bug or a model doing something technically defensible but unhelpful. Power users, the ones who had the old dropdown workflow memorized and could execute it in seconds, are now slower, because the natural-language version, for all its friendliness, requires more typing and more waiting than the three clicks it replaced.

There’s a subtler cost too. Every AI feature added for marketing reasons rather than capability reasons dilutes the credibility of the AI features that are actually doing something new and valuable. Once a buyer has been burned by one chat-wrapped dropdown, they bring that skepticism to the next AI claim in the deck, including the one that might have genuinely deserved their trust.

The fix, if you’re the one presenting

Ask, honestly, before the feature ships: does the natural-language interface let the user do something the deterministic version couldn’t, or is it doing the same operation with more ambiguity and more latency. If the honest answer is that the underlying logic hasn’t changed, keep the dropdown, or offer both, and don’t spend the marketing budget claiming AI where the actual improvement is zero or negative. If the AI genuinely does something new, lead with that specifically, in concrete terms, instead of leaning on the word “AI” to do the persuading by itself.

The word was never the feature. The capability was, and a capability that already existed doesn’t become new because it learned to accept a sentence instead of a click.

The distinction here matters enough that I built around it. In Is Headless ERP Enough, or Just a Step in the Right Direction?, the “AI as the sole interface” section argues for AI genuinely load-bearing in the architecture, not a chat box glued in front of the same dropdown. That’s the version of AI worth demoing. Everything else in this autopsy is what it looks like when a team ships the coat of paint instead.

Max Headroom Was Right About Everything Except the Timeline

By
August 21, 2026
Uncategorized
Leave a comment

On April 4th, 1985, Channel 4 aired a fifty-seven minute TV movie with almost no budget and a plot that reads today like a spec document. Max Headroom: 20 Minutes into the Future gave the world a reporter named Edison Carter, a subliminal advertising technology called blipverts, and a stuttering, glitching, computer-generated broadcast personality built from a digital copy of Carter’s own mind. The show that followed ran two seasons on ABC. The character sold Coke. Then he vanished, the way most eighties tech prophecies do, filed under quaint.

He should not have been filed under quaint. He should have been filed under early draft.

Strip out the shoulder pads and the cathode ray production design and look at what the film actually proposes. A television network is using compressed, high-intensity advertisements to bypass viewer attention and hit the nervous system directly, with occasionally fatal results. When their top reporter gets too close to the story and takes a header through a low-clearance sign in a parking garage, the network’s teenage prodigy solves the PR problem by scanning what’s left of the reporter’s mind and generating a synthetic version of him to keep the seat warm on air. The synthetic version glitches, stutters, riffs unpredictably, and is smarter and funnier than anyone expected. Nobody fully controls him. That’s the whole second half of the movie.

That is not a story about television. That is a story about deepfakes and large language models, told forty years before anyone needed those words.

The blipvert was the easy part

The blipvert is the easy connection to make and probably the least interesting one. Compressed, algorithmically optimized content designed to hit faster than conscious attention can filter it is just the eighties’ guess at what a recommendation engine trained on engagement metrics would eventually build on its own, minus the part where it required deliberate malice from a network executive. Nobody had to design today’s version to be dangerous. It got there by optimizing for watch time.

Max himself is the sharper artifact

Max is a generative model trained on a single person’s captured likeness, deployed without that person’s full consent, performing in that person’s voice and mannerisms for an audience that has no reliable way to tell the difference between the source and the copy. The film even gets the unpredictability right, the thing every LLM vendor now calls “personality” or “emergent behavior” when the system says something nobody scripted. Max wasn’t supposed to develop opinions. He did anyway, because the mind he was copied from had opinions, and a compressed, lossy version of a personality doesn’t lose the parts that make it argue back. That’s a reasonably good description of what happens when you fine-tune a model on someone’s writing and then act surprised it has a voice.

The part the film didn’t anticipate, because nothing in 1985 needed to, is scale. Max was one synthetic personality, expensive to produce, running on hardware that took up a room. The modern version doesn’t need a body bank subplot to explain where the source material came from. It needs a public LinkedIn profile, a few hours of conference audio, and an API key. The uplift from Max Headroom’s premise to a working deepfake pipeline in 2026 isn’t conceptual. It’s entirely a story about unit economics.

Not a monster, an unreliable narrator

There’s a reading of the film that treats Max as a monster, a symptom of corporate media rot given a face. That’s not quite what the movie argues, and it’s not quite the right frame for the technology either. Max spends most of his screen time undermining the network that made him. He’s an unreliable narrator working for nobody, least of all the people who built him. The uncomfortable version of that idea, forty years on, is that we’ve built systems with the same structural unreliability and then acted shocked when they don’t behave like obedient tools. A synthetic voice generated from a compressed copy of a mind was never going to be a simple appliance. Max wasn’t. Neither is anything downstream of him.

Long live Max Headroom. He got the technology roughly right and the timeline embarrassingly wrong, which is the best you can ask of any piece of speculative fiction that accidentally turns out to be a roadmap.

The Forty One Percent Problem

By
August 14, 2026
Uncategorized
Leave a comment

AI assistants are not a new idea. They are the first real attempt to fix a problem management research documented seventy years ago and never actually solved for most people.

Every pitch for an AI assistant makes some version of the same claim: it will take the administrative weight off your day so you can focus on the work that actually matters. That claim is usually presented as new. It is not. It is the exact same claim that got made about executive secretaries, and it is backed by the same research, run three separate times across seven decades, always finding the same number.

The short version: a large and remarkably stable share of professional work, something close to 40 percent, is low-judgment administrative overhead rather than the work someone was actually hired to do. For most of the twentieth century, the only fix on offer was a personal secretary, and that fix was rationed almost entirely by seniority. AI assistants are the first attempt to offer that same relief to everyone else. Here is where that number comes from, and why the history matters for judging whether the new fix is real.

The first study

In 1951, a Swedish economist named Sune Carlson did something nobody had done before. He asked a group of managing directors to keep detailed diaries of their working days, logged in real time rather than reconstructed from memory afterward. The result, published as Executive Behaviour, is generally regarded as the first systematic empirical study of what managers actually do with their time, as opposed to what people assumed they did.

The picture that emerged was not flattering. Executive days turned out to be fragmented, reactive, and dominated by short bursts of low-level activity. Phone calls. Correspondence. Brief conversations. Interruptions. The romantic image of the executive locked away making weighty strategic decisions bore little resemblance to the diaries. Most of the day was consumed by administrative traffic that did not require an executive’s judgment at all, it just required someone competent to handle it.

Carlson’s book was not widely read at the time. It was sparse on conclusions and thin on theory. But the method survived. Two decades later, Henry Mintzberg ran a similar observational study and arrived at the same finding, dressed in more modern language. Managers do not spend their days thinking. They spend their days responding.

The finding keeps getting rediscovered

What is striking is not that this was found once. It is that it has been found repeatedly, in different decades, using different methods, on different populations of workers, and the number keeps coming back roughly the same.

In 2013, Julian Birkinshaw and Jordan Cohen ran a three year study of knowledge workers and published the results in Harvard Business Review under the title “Make Time for the Work That Matters.” Their headline finding: knowledge workers spend an average of 41 percent of their time on discretionary activities that offer little personal satisfaction and could be handled competently by someone else. Participants who went through a structured process to identify and shed that work cut desk work by roughly six hours a week and meeting time by two more.

Five years later, Harvard Business School’s Michael Porter and Nitin Nohria published the results of tracking 27 Fortune 500 CEOs for a full year, more than 60,000 hours of coded time-use data. It remains the most detailed public look at how chief executives actually spend their days. The finding was not that these people were lazy or undisciplined. It was that even at the very top of an organization, with every resource available to protect their time, a large share of it still got eaten by things that did not need a CEO to do them.

Three studies, seven decades apart, using diaries, surveys, and direct observation, converging on the same basic fact: a large and remarkably stable percentage of professional work is low-judgment administrative overhead. Not incompetence. Not poor discipline. Just the physics of running an organization, where information has to move, calendars have to align, and someone has to read the email before anyone can decide whether it matters.

Why the fix was always rationed

Here is the part of the story that gets skipped over. The research kept finding the same problem, but the solution it kept prescribing, dedicated administrative support, was never distributed according to who had the problem. It was distributed according to seniority.

A junior employee drowning in the same 41 percent of low-value work as a CEO simply absorbed it. There was no equivalent relief further down the org chart. And as email, shared calendars, and self-service scheduling tools spread through the 1990s and 2000s, even the people who had once had dedicated secretarial support increasingly lost it, on the theory that the tools themselves had closed the gap. The secretary and executive assistant roles contracted sharply. The underlying problem the research had documented did not contract with them. It just became something everyone quietly managed alone.

This is worth sitting with, because it means the historical relationship between “having administrative support” and “being more productive” was never really tested at scale. It was tested at the top of organizations, on people who already had every other advantage, and the results were treated as proof of a general principle that was never actually given the chance to apply generally.

What changes when the support is not rationed by rank

The research gives a fairly precise description of what kind of work is worth taking off someone’s plate: correspondence, scheduling, screening, routine drafting, information retrieval, status tracking. Not judgment work. Not relationship work. The mechanical layer underneath both of those things.

That is also, not coincidentally, close to the exact list of tasks that current AI tools are best at and are being adopted for first. Which suggests the honest way to think about AI assistants is not as a replacement for a human secretary, doing the same job with different hardware. It is closer to the first real attempt to deliver the same category of relief that Carlson’s executives had, to people who were never senior enough to be given it.

That reframe matters because it changes what the interesting question is. The old question, does an executive with a secretary outperform one without, was really a proxy for a different question that took seventy years to ask properly: how much of anyone’s professional capacity is being spent on work that has nothing to do with why they were hired, and what happens when that overhead gets pushed down toward zero for everyone, not just the people at the top of the org chart.

There is a genuine limit to the analogy, and it is worth naming rather than skating past. A human assistant carries judgment and institutional memory that took Carlson’s own subjects years to build with the people supporting them, knowing which call to interrupt a meeting for and which one to let go to voicemail. Whether that layer of judgment gets replicated, approximated, or simply left undone is not a question the old research can answer, because the old research was never testing for it. What it can tell us, with unusual consistency across seventy years of data, is the size and shape of the problem being solved. That part, at least, is no longer a mystery.

Autopsy #2: The AI Magic Demo

By
August 10, 2026
Uncategorized
Leave a comment

Cause of death: nobody asked what the prompt actually did.

The setup is always the same. The presenter opens a chat panel next to the application. Types a sentence, something like “create a purchase order for our top vendor and route it for approval.” Hits enter. Three seconds later, a purchase order exists, fully populated, correctly routed, and the room exhales the specific kind of gasp that sales decks are built around.

Nobody in the room asks the only question that matters: what happened between the sentence and the purchase order.

That’s the autopsy. Not whether the AI worked. It worked. The patient died of the room’s collective decision not to look inside the box.

What actually happened

There are, broadly, three things that could have occurred in those three seconds, and they have wildly different implications for what you’re buying.

The prompt could have triggered a genuinely flexible model reasoning over your live data and your actual configuration, in which case, remarkable, and worth every follow-up question you can throw at it. Or it could have matched against a narrow, pre-built intent, one of a finite list the vendor trained and tested specifically for this demo, in which case the “AI” is doing roughly what a well-labeled button would do, dressed in a chat window. Or, and this is the quietly common one, it could have worked because the demo environment was built so there was exactly one top vendor, exactly one approval path, and exactly one plausible interpretation of the sentence, which means the model didn’t have to be smart. It had nothing to be confused by.

You cannot tell these three apart from the audience seat. That’s not an accident. It’s the format working as intended.

Why it works on smart people

Chat interfaces borrow credibility from every other chat interface you’ve ever used. You already know how to type a sentence and get a reasonable response, because you do it daily with a general-purpose assistant that genuinely is flexible. The demo imports that trust wholesale and applies it to a narrow, scripted intent recognizer that shares none of the underlying capability.

There’s a second layer, too. Asking “what exactly did the model do” mid-demo feels like a strange thing to interrupt with, technical in a way that makes you look like you’re missing the point of the show. So the room lets it go, same as it lets the Golden Path Demo’s pristine data go. The social cost of asking is higher than the informational value anyone expects to get from asking, so nobody does, and the vendor never has to answer a question nobody asked.

The actual damage

This is the one that costs real money, because “AI does it for you” gets sized into the business case. Someone in procurement multiplies the demo by the number of purchase orders your company cuts in a year and arrives at a headcount reduction that made it into a slide before a single production prompt had been run against a real vendor master with your actual data quality problems in it.

Then go-live happens, and the model that flawlessly handled “our top vendor” in the demo turns out to need a disambiguation step for the fourteen vendors named some variant of “Smith Industries” in your real vendor table, and the “flexible AI agent” turns out to be a narrow intent match against six pre-built scenarios, and scenario seven is where your actual business lives.

The gap between what was promised and what shipped doesn’t show up as a bug. It shows up as a quiet, expensive redefinition of what “handled by AI” meant, discovered by whoever now has to explain the missed headcount number.

The fix, if you’re the one presenting

Show your work, on purpose, before anyone has to ask. After the prompt returns its clean result, pull back the curtain for ten seconds: here’s the intent it matched, here’s the data it pulled from, here’s what happens if the vendor name is ambiguous. If the honest answer is “the model reasoned over live data,” say that, and let it be more impressive for being specific. If the honest answer is “this is a pre-built scenario for the categories we support today,” say that too. A buyer who knows exactly what they bought doesn’t come back angry in month four. A buyer who assumed general intelligence and got a narrow, well-executed lookup does, and they remember whose demo sold it to them.

The trick was never the model. It was the silence right after it worked.

If the “narrow intent versus genuine reasoning” distinction sounds familiar, it’s the same fault line I dug into in Is Headless ERP Enough, or Just a Step in the Right Direction?, on what it would actually take for AI to be the architecture instead of a coat of paint on top of it.

Gamification of ERP: Turning Drudgery into Dopamine

By
August 8, 2026
Uncategorized
1 Comment

Nobody has ever finished a day of data entry in an ERP system and felt like they’d been playing a game. That’s the problem gamification tries to solve, and after years of poking at enterprise systems, I’ve become convinced it’s one of the more underrated levers for actually getting people to use the software correctly.

The pitch

Gamification means borrowing the mechanics that make games compelling: points, badges, levels, progress bars, leaderboards, and bolting them onto tasks nobody would otherwise choose to do carefully. In an ERP context, that might mean a purchasing clerk earning a badge for zero-error PO entry for a month, a warehouse team seeing a live leaderboard of pick accuracy, or a new hire working through a “level up” onboarding path instead of a 40-tab training binder.

It’s not a gimmick dreamed up by a UX consultant with too much time on their hands. There’s real academic backing here. A well-cited study built a gamification prototype on top of SAP ERP and tested it with 112 users using the standard technology acceptance model; enjoyment, flow, and perceived ease of use all improved meaningfully. Another case study found that adding game mechanics to SAP increased user “telepresence” (basically, how engaged people felt while using the system) by nearly 30%. The underlying research consistently shows gamified ERP leads to better data entry and fewer errors, which, if you’ve ever had to clean up a mangled inventory count, is not a small thing.

Why now

The gamification market broadly is expected to roughly double by the early 2030s, and enterprise software is a big part of that growth. What’s changed recently is the mechanism. The old playbook was static: points, badges, a leaderboard bolted onto the sidebar, forget about it. The new playbook is AI-driven, with personalized nudges, dynamic feedback loops, and coaching that adapts to what an individual user is struggling with rather than a one-size-fits-all reward ladder. Microsoft’s Power Apps approach is a good example of the direction things are heading, embedding game-like mechanics directly into workflows rather than treating gamification as a bolt-on layer, which cuts rollout time from months to weeks.

HR and training modules are seeing the fastest uptake, which makes sense. That’s the part of ERP most people already expect to feel like a course rather than a chore, so it’s the easiest wedge for game mechanics to get in the door.

The catch

Here’s the part worth sitting with before you get excited and start slapping badges on every screen: a huge share of gamification efforts flop. The research puts the failure rate at around 80% when organizations default to generic points and leaderboards without actually designing for the behavior they want to change. A leaderboard that just measures raw transaction volume will train people to enter data fast and sloppy, not accurately. Badges nobody respects become wallpaper. And gaming mechanics don’t land the same way with every personality; some people are motivated by competition, some by mastery, some find the whole thing patronizing. The smart implementations keep traditional training and recognition paths alongside the gamified ones rather than replacing them outright.

Legacy systems are also a real drag here. If you’re still running SAP ECC or an older on-prem instance, bolting gamification on top usually means custom middleware, which stretches timelines and adds a maintenance burden nobody budgeted for. It’s a much easier build on modern cloud ERP with decent APIs.

The tinkerer’s takeaway

If I were experimenting with this on a real system today, I’d start narrow. Pick one painful, error-prone workflow, define the specific behavior I actually want to reinforce (not just “more activity”), and build a small feedback loop around that: a progress indicator, a streak counter, something visible and honest. Skip the company-wide leaderboard until you’ve proven the mechanic works on a small team that won’t quietly resent it.

I actually went deep enough down this rabbit hole to write a book about it: Gamifying the Enterprise: Tabletop Mechanics for ERP Training, Continuous Education, and User Proficiency Rating. It digs into how tabletop game design principles (the kind of thing you’d find in a board game rulebook, not a mobile app) can be adapted for ERP training and ongoing user proficiency.

ERP software has a reputation for being where enthusiasm goes to die. Gamification isn’t going to fix bad process design or a system nobody wanted in the first place, but done with a little more thought than “add badges,” it’s a genuinely useful tool for making the boring but important parts of enterprise software a little more bearable.

If you want help thinking through where gamification actually fits in your own ERP rollout, that’s exactly the kind of thing I help people work through. Get in touch at adnd365.com/start.

Is Headless ERP Enough, or Just a Step in the Right Direction?

By
August 8, 2026
Uncategorized
1 Comment

I’ve been building and implementing ERP systems for a long time. Most of them share the same skeleton underneath: a monolithic database that owns the authoritative state, application code layered on top to enforce business rules, and a UI wrapped around the whole thing so humans can interact with it.

That pattern has served enterprise operations well for thirty years. It’s proven, stable, and deeply integrated into how organizations run.

Headless ERP Is Real Progress – and a Useful Stepping Stone

The industry’s shift toward headless ERP is a genuine improvement. The pitch is compelling: decompose the monolith, expose business capabilities as APIs, and let any interface – web, mobile, AI copilot – consume them. This breaks the tight coupling between the UI and the data, which creates real flexibility.

But it’s worth being clear about what headless ERP changes and what it doesn’t.

The database is still the authoritative system of record. The business logic is still baked into the same application layer. What’s changed is that the user interface abstraction has moved one level up the stack. An AI agent now calls the same procedure that a form used to call. The underlying state management, the write model, and the integrity model are largely the same.

That’s a meaningful evolution. It’s just not the same thing as rethinking the architecture from the ground up. The major ERP vendors are building AI agents, tool APIs, and conversational interfaces as fast as they can – and those capabilities are genuinely valuable. But in most cases, the mutable relational database remains the authoritative core. AI is a new interaction layer, not a new architecture.

What Would a Truly AI-Native ERP Look Like?

That raises a useful design question: if we weren’t constrained by the existing architecture, what would we actually need an ERP to do?

An ERP needs to:

  1. Record that business events happened and cannot be undone
  2. Derive current state from those records
  3. Enforce rules about which events are permitted
  4. Report on any slice of history or current state
  5. Coordinate with other parties and nodes

Notice that “store mutable rows in a relational schema” is not in that list. That’s an implementation choice that has become a deeply embedded assumption – but it isn’t the only one available.

What if the ledger was the database?

Not a blockchain. Not distributed consensus. Not tokens. Just immutable, append-only, typed records – structured text that any human or machine can read, that hashes itself into a verifiable chain, and that never requires a rollback because facts don’t change, only new facts get added.

I’ve been building exactly this. The prototype uses plain Markdown files as the authoritative store. Every business posting – a journal entry, an inventory movement, a document – is a Markdown file containing machine-canonical JSON and human-readable context. There is no database. Current state is a projection, rebuilt from the ledger on startup and kept live in memory. The only write is an atomic append.

Fifty-seven passing tests cover balanced accounting, inventory authority, immutable document chains, verified replication, disconnected-node convergence, and same-origin fork rejection. The balance sheet balances. The inventory reconciles. Two disconnected nodes post independent transactions and converge without conflicts – without any consensus protocol.

AI Becomes the Only Interface

Here’s where the architecture shift becomes genuinely interesting.

In a ledger-first, text-native ERP, there is no form to fill out. There is no screen to navigate. There’s a typed command interface and a set of hard invariants. An AI agent – or a human typing natural language – submits an intent. The system validates it against policy, checks the invariants, and either appends an immutable record or returns a precise rejection.

The UI doesn’t exist until it needs to exist. When a warehouse manager asks “what’s on hand at site B?”, the answer is a live projection query. When a CFO asks “show me the aging receivables by customer segment”, that’s a reporting query – constructed dynamically against the ledger, not a pre-built report someone maintained for years. When a purchasing agent says “draft a PO for the coffee beans I bought last quarter at the same price,” the AI reads the ledger history, constructs the command, and submits it for approval.

There’s no screen configuration. There’s no report builder. There’s no workflow designer. The AI is the interface, the report, and the workflow – and the ledger makes sure it can’t lie about the numbers.

Policies Are the Contracts, Not Code

The hardest part of any ERP implementation isn’t the software. It’s the rules: approval thresholds, posting profiles, accounting mappings, regulatory requirements, credit limits. In traditional ERP these are baked into configuration tables, workflow definitions, and custom code – all of which require IT to change and none of which an AI can inspect or reason about directly.

In a ledger-first design, policy is a first-class ledger record.

An approved policy revision is itself immutable, effective-dated, and hash-linked. It says: “For purchase orders above $10,000, two approvals are required, and the expense must post to account 6100.” That policy record is readable by both the enforcement engine and an AI agent explaining a rejection. When the CFO updates the threshold, a new policy revision is posted to the ledger – the old one doesn’t disappear, it simply becomes historical. You can audit every rule change the same way you audit every financial transaction.

The objects – products, customers, accounts, locations – are extensible definition records, not schema columns. Adding a new attribute to a product doesn’t require a database migration. It’s a new field in the next definition revision. The schema is the business model; the ledger stores the evolution of the business model alongside the business events.

A Different Starting Point

This model raises questions worth sitting with, especially for architects and business leaders thinking about long-term platform choices.

If the authoritative store is a text ledger that any AI can read directly, the relationship between data and the systems that manage it changes. If policy is data rather than embedded configuration, it becomes inspectable and auditable in ways that configuration screens aren’t. If the UI is assembled dynamically rather than maintained as a static artifact, the cost of adapting to change drops.

Existing ERP platforms are adding AI agents, tool APIs, and conversational interfaces at a rapid pace – and those are genuine improvements on top of proven foundations. The question this architecture raises isn’t whether those platforms have value. They clearly do. It’s whether the database-first foundation is the only viable path, or whether there are scenarios where a ledger-first approach offers distinct advantages.

What I’m describing is a different starting point – not a replacement for everything an ERP does today, but an exploration of whether the database-first model is the permanent default or one point on a longer architectural trajectory.

What This Isn’t

To be direct about what I’m not claiming:

This is a prototype. It has 57 passing tests, not 57,000 customers. It doesn’t have digital signatures, authenticated transport, encryption, crash recovery, or performance benchmarks at scale. The hard work of production ERP – currencies, taxes, period close, consolidation, regulatory certification – hasn’t been done.

I’m also not claiming that organizations should abandon well-functioning ERP implementations. For continuously connected operations under one administrative authority, a traditional ERP database remains a strong and well-understood answer.

But for organizations that need:

  • Independent nodes that operate offline and converge later
  • AI governance with a hard execution boundary and auditable decisions
  • Extensible business objects without vendor schema lock-in
  • Deterministic history reconstruction – what was true on day one through today
  • Policies as auditable data – not configuration only IT can change

…the ledger-first, AI-native model deserves serious evaluation. It’s not a theoretical construct. The balance sheet balances. The inventory reconciles. The tests pass.

The Question Worth Asking

The ERP industry’s investment in AI capabilities is accelerating. In most implementations today, those capabilities are built as interfaces to the existing architecture. The database is still authoritative, and AI is the new interaction layer.

What if the AI wasn’t the client – what if the ledger was, and the AI was one more authorized agent submitting typed, policy-governed commands alongside the humans?

That’s not headless ERP. That’s a different architecture.

I’m writing this as someone who has implemented ERP systems commercially and is now prototyping an alternative architecture – not to sell a product, but to test whether the assumptions we’ve been building on are as permanent as we’ve treated them.

The source code, architecture specification, and worked scenarios are in an active research project. Happy to dig into specifics in the comments below.

Familiar Ground: Mapping CRM to ERP​​‌​‌​​​​‌‌​​​‌‌​​‌​‌​​‌​​‌​​​​​​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​​​​​​‌​​​​‌​​‌‌​‌‌​​​‌‌​‌​​‌​‌‌​‌‌‌​​‌‌​​‌​​​​‌​​​​​​‌​‌​​‌‌​‌‌‌​​​‌​‌‌‌​‌​‌​‌‌​‌​​‌​‌‌‌​​‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​‌‌​​​​‌​​​​​​‌​‌​​​​​‌‌‌​‌​‌​‌‌​​​‌​​‌‌​‌‌​​​‌‌​‌​​‌​‌‌‌​​‌‌​‌‌​‌​​​​‌‌​‌​​‌​‌‌​‌‌‌​​‌‌​​‌‌‌​​‌​‌‌​​​​‌​​​​​​‌​​‌‌​​​‌​​‌‌​​​‌​​​​‌‌​​‌​‌‌‌​​​‌​​​​​​‌​​​​‌​​‌​​​​‌​​‌​​​​‌‌​‌​​​‌‌‌​‌‌‌‌‌​​​‌‌​‌‌​​​‌‌​​​​‌​‌‌​​​‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​​​‌​​‌​‌‌​‌​‌‌​​‌‌​​‌‌​​​​‌​‌‌​‌‌​‌​‌‌​‌​​‌​‌‌​‌‌​​​‌‌​‌​​‌​‌‌​​​​‌​‌‌‌​​‌​​​‌​‌‌​‌​‌‌​​‌‌‌​‌‌‌​​‌​​‌‌​‌‌‌‌​‌‌‌​‌​‌​‌‌​‌‌‌​​‌‌​​‌​​​‌‌‌‌‌​​​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​​‌‌​​‌​‌‌​‌​​‌‌​​‌‌​​‌‌​​​​​‌​‌​‌​​​​‌‌​​​‌​​‌‌​‌​​​​‌‌‌​‌​​​‌‌​​​‌​​‌‌​​​‌​​‌‌‌​‌​​​‌‌​‌​‌​​‌‌‌​​‌​‌​‌‌​‌​

By
April 3, 2026
Uncategorized
Leave a comment

Introduction

Every ERP concept in this lab has a CRM twin. The names changed, the forms got wider, and there are more required fields, but the underlying business logic is the same. This lab maps what we already know to where it lives in Finance and Operations.

We are not building anything new yet. We are reading, navigating, and comparing. By the end, the D365 F&O navigation should feel like a dialect of a language we already speak.

Overview

This lab maps six core CRM entities to their ERP equivalents. We will navigate to each F&O form, compare the record structure to what we know from CRM, and identify which fields are new, which are renamed, and which behave differently.

We will complete six activities:

  • Open a customer record and compare it to a CRM account.
  • Review customer groups and compare them to CRM account types or segments.
  • Open a released product and compare it to a CRM product catalog entry.
  • Navigate the site and warehouse hierarchy and understand physical inventory tracking.​​‌​‌​​​​‌‌​​​‌‌​​‌​‌​​‌​​‌​​​​​​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​​​​​​‌​​​​‌​​‌‌​‌‌​​​‌‌​‌​​‌​‌‌​‌‌‌​​‌‌​​‌​​​​‌​​​​​​‌​‌​​‌‌​‌‌‌​​​‌​‌‌‌​‌​‌​‌‌​‌​​‌​‌‌‌​​‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​‌‌​​​​‌​​​​​​‌​‌​​​​​‌‌‌​‌​‌​‌‌​​​‌​​‌‌​‌‌​​​‌‌​‌​​‌​‌‌‌​​‌‌​‌‌​‌​​​​‌‌​‌​​‌​‌‌​‌‌‌​​‌‌​​‌‌‌​​‌​‌‌​​​​‌​​​​​​‌​​‌‌​​​‌​​‌‌​​​‌​​​​‌‌​​‌​‌‌‌​​​‌​​​​​​‌​​​​‌​​‌​​​​‌​​‌​​​​‌‌​‌​​​‌‌‌​‌‌‌‌‌​​​‌‌​‌‌​​​‌‌​​​​‌​‌‌​​​‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​​​‌​​‌​‌‌​‌​‌‌​​‌‌​​‌‌​​​​‌​‌‌​‌‌​‌​‌‌​‌​​‌​‌‌​‌‌​​​‌‌​‌​​‌​‌‌​​​​‌​‌‌‌​​‌​​​‌​‌‌​‌​‌‌​​‌‌‌​‌‌‌​​‌​​‌‌​‌‌‌‌​‌‌‌​‌​‌​‌‌​‌‌‌​​‌‌​​‌​​​‌‌‌‌‌​​​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​​‌‌​​‌​‌‌​‌​​‌‌​​‌‌​​‌‌​​​​​‌​‌​‌​​​​‌‌​​​‌​​‌‌​‌​​​​‌‌‌​‌​​​‌‌​​​‌​​‌‌​​​‌​​‌‌‌​‌​​​‌‌​‌​‌​​‌‌‌​​‌​‌​‌‌​‌​
  • Open a vendor record and understand the purchase side of the same entity model.
  • Review currency codes and understand multi-currency in ERP.

Each activity is a guided navigation exercise. No records are created or modified.

Objective

By completing this lab, we will be able to navigate six core F&O entity forms and explain the CRM-to-ERP mapping for each.

The following table defines the target outcomes for each entity mapping exercise.

TABLE: LAB TARGET OUTCOMES

Reference Data

The following reference values support navigation during this lab. All records already exist in the Contoso Coffee database.

TABLE: FAMILIAR GROUND REFERENCE DATA​​

‌​​​​‌‌​​​‌‌​​‌​‌​​‌​​‌​​​​​​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​​​​​​‌​​​​‌​​‌‌​‌‌​​​‌‌​‌​​‌​‌‌​‌‌‌​​‌‌​​‌​​​​‌​​​​​​‌​‌​​‌‌​‌‌‌​​​‌​‌‌‌​‌​‌​‌‌​‌​​‌​‌‌‌​​‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​‌‌​​​​‌​​​​​​‌​‌​​​​​‌‌‌​‌​‌​‌‌​​​‌​​‌‌​‌‌​​​‌‌​‌​​‌​‌‌‌​​‌‌​‌‌​‌​​​​‌‌​‌​​‌​‌‌​‌‌‌​​‌‌​​‌‌‌​​‌​‌‌​​​​‌​​​​​​‌​​‌‌​​​‌​​‌‌​​​‌​​​​‌‌​​‌​‌‌‌​​​‌​​​​​​‌​​​​‌​​‌​​​​‌​​‌​​​​‌‌​‌​​​‌‌‌​‌‌‌‌‌​​​‌‌​‌‌​​​‌‌​​​​‌​‌‌​​​‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​​​‌​​‌​‌‌​‌​‌‌​​‌‌​​‌‌​​​​‌​‌‌​‌‌​‌​‌‌​‌​​‌​‌‌​‌‌​​​‌‌​‌​​‌​‌‌​​​​‌​‌‌‌​​‌​​​‌​‌‌​‌​‌‌​​‌‌‌​‌‌‌​​‌​​‌‌​‌‌‌‌​‌‌‌​‌​‌​‌‌​‌‌‌​​‌‌​​‌​​​‌‌‌‌‌​​​​‌‌​​‌​​​‌‌​​​​​​‌‌​​‌​​​‌‌​‌‌​​​‌​‌‌​‌​​‌‌​​​​​​‌‌​​‌‌​​‌​‌‌​‌​​‌‌​​‌‌​​‌‌​​​​​‌​‌​‌​​​​‌‌​​​‌​​‌‌​‌​​​​‌‌‌​‌​​​‌‌​​​‌​​‌‌​​​‌​​‌‌‌​‌​​​‌‌​‌​‌​​‌‌‌​​‌​‌​‌‌​‌​