Sapura Cosmetics

Every crime has a scene.

Sapura Cosmetics is the fictional company at the heart of SAP SOAP. Every book is set there. It was built on one product, the flagship sapwood soap bar, and the sap-sweet scent that started it all can still be found in many homes. Fictional homes, naturally.

Behind the brand runs SAP S/4HANA. Behind that run people: deadlines, spreadsheets, workarounds and the occasional silence in a meeting that says more than the minutes.

When fiction imitates life

The events are real. The company and the people are not.

Sapura Cosmetics does not exist. Neither does any other company in the books. The characters are invented too. If you think you recognise your project manager, you have met the type, not the person.

What happens in the books did happen. The spreadsheet that quietly ran the business. The workaround that outlived the project. The one person who quietly became the system. Isard was there, taking notes.

But names, companies and timelines have been changed, merged and disguised, so no real client, colleague or project can be identified. No real customer data and no real numbers.

SAP is real, and so is its software. SAP has nothing to do with these books and has not endorsed them.

The protagonists

Three detectives, one company, a different case each. None of them carries a badge. All of them carry a notebook.

Alex, the project manager

Alex runs the S/4HANA project at Sapura. She used to believe structure would save her: the perfectly formatted status report, colour-coded and on time. She has since learned that you can colour-code a crisis all you like. It is still on fire.

Her case in Death by Spreadsheet starts on a Tuesday in week two of acceptance testing. In front of the whole room, the business reports product data with missing fields, wrong units and duplicates. Someone has already escalated it, and it wasn’t her. Then the CEO looks down the table and gives her one week to find the root cause and a plan to fix it. One week. The corporate unit of impossible.

Her ticket system says nothing is on fire. Everyone else says the building is burning. Somewhere between the two sits a spreadsheet that everybody trusts and nobody owns.

Alex is sarcastic under pressure and tired under the sarcasm. She still turns up at the kitchen table on a Sunday with a fresh pack of sticky notes, and she ends every chapter with her Captain’s Log, because if nobody else keeps a record, she will.

You will recognise her if you have ever said “Understood” in a meeting while thinking the exact opposite. Follow Alex into Death by Spreadsheet →

Amy, the functional consultant

Amy is the contractor who arrives early on a first day. Not to impress. To watch. She sits with her back to the wall, phone face down, and lets the room show her what it thinks is normal before she questions any of it.

The brief in Death by Workaround is thin: four weeks, one deliverable, findings and recommendations. Stabilise the system. Not fix it. In the interviews one question kept coming back as if it were harmless: can you read code? She said yes and nothing more, and filed it as a throwaway comment.

On her first morning she overhears the problem before anyone explains it. A batch job failed overnight. Sales orders with no production orders behind them. Key deliveries at risk. The third time in six weeks. Everyone waits for Max, and Max fixes it. Amy’s challenge is not the failure. It is getting anyone to ask why the whole company depends on one person, with no mandate, no budget and no authority to change a thing.

She has seen enough projects to know that a rule nobody enforces is just a slogan on a poster. So she speaks less, listens harder, and lets the other person talk first.

You will recognise her if you have ever been hired to solve a problem that nobody would name in the interview. Follow Amy into Death by Workaround →

Priya, the business analyst

Priya keeps everything in the system, and she trusts what the system tells her. Her Jira board has a better social life than most of her colleagues. If it is not in a ticket, as far as she is concerned, it did not happen.

Priya also has a secret, shared with just one colleague. It is how she solves tickets twice as fast as the team average. She keeps it under the radar, and nobody really notices. Until it bites her, hard.

Her case in Death by Email starts with a summons to the CFO’s office. Frank, the company’s VAT specialist, is on holiday, and somebody has to cover his work while he is away. Priya quietly inherits his queue: fourteen open tickets, the oldest more than four months stale, and email threads eleven forwards deep. Not one of them carries a ticket number. Everything important was apparently decided at the coffee machine, and the coffee machine does not keep minutes.

Her challenge is not the backlog. It is becoming an overnight expert, with Frank’s emails as her only source. Frank cannot be reached. And the clock is ticking.

You will recognise her if you have ever inherited someone’s inbox instead of a handover. Her case is under investigation: Death by Email →

The supporting cast

Every detective needs someone who knows how things really work. Sapura has two of them, and they could not be more different.

Max, the developer

Max has been writing ABAP since forever, as he puts it, since before you could code objects. Glasses low on his nose, one shoulder carried a little higher than the other, as if he stores the tension there. He answers without looking up. He is always mid-fix.

He is proud of his code and cares how it looks. The developer equivalent of ironing your shirt: nobody notices, but he knows. He does not like reading other people’s code. When he gets the chance, he rewrites it.

Ask him a question and he turns teacher. “Don’t try to calculate it first. See it.” He will explain object-oriented ABAP using the coffee machine, then watch to see if you keep up.

Four years ago there were three developers. Now it is just Max. When the system fails overnight, he is the one on the phone, and he fixes it, usually within a day. He likes to be in control. Nobody planned it this way, least of all him.

You will recognise him if you have ever been the only one who knows how it works, or if you have ever relied on that person and hoped they never go on holiday. Meet Max in Death by Workaround →

Eugene, the BRF+ expert

Eugene is the person you call when a plan needs a second opinion from someone with nothing to prove. Never panics, never postures. He weighs logic like currency and only speaks when he has something worth spending.

Alex knew him before she joined Sapura. In Death by Spreadsheet, when she needs a second opinion on whether her idea floats or sinks, she rings him. Eugene has a habit of answering with three letters and a plus sign.

In Death by Workaround he turns up again, on a team night out, sliding an onion ring onto his finger before he eats it. He watches people more than he watches the room. Days later he asks Amy for a drink at the pub. He might have something useful to share. In private.

In Death by Email, his desk is empty. His influence is not.

BRF+ is SAP’s Business Rule Framework, and unlike Eugene, it is real. It lets you capture business decisions as rules that people can read, test and change without rewriting code. In Death by Spreadsheet, it is the second opinion. In Death by Workaround, it levels up to the first opinion. In Death by Email, it becomes the lasting opinion: the legacy Eugene leaves behind. What he does with it, you will have to read.

Eugene is the quiet expert every project has and few projects listen to. He does not sell. He waits until someone asks the right question, then points at a tool that was in the system all along.

You will recognise him if you have ever known the answer and waited for the meeting to catch up. Ask him where to begin, and he will give you the same advice as the BRF.plus website: solve any problem, start small. See what BRF+ does outside a novel at BRF.plus →