SAP BTP · Enterprise AI · 16 years

The demo always works.
Production is the job.

I put AI, automation, and custom software into production inside SAP. The thing standing in the way is almost never the technology. It's scope nobody bounded, access nobody granted, and logic nobody ever wrote down.

See what moved Get in touch

The gap

Most AI people
have never opened SAP.

And most SAP people met AI for the first time last year. I've worked in the overlap since 2019, when I first put conversational AI in front of SAP backends, and right now I'm taking an AI agent from proof of concept toward production for a client in Mexico. From that seat, here is where enterprise AI actually stops.

01

Scope

Nobody bounded it.

Requests arrive without limit, the team absorbs them quietly, and the date does the rest.
  • Constraints
  • Priorities
  • Estimates
02

Access

Nobody granted it.

Half a program can vanish into approvals before anyone touches a system.
  • Policy
  • Systems
  • Real data
03

Logic

Nobody wrote it down.

The rules still exist, but only inside systems no one has documented in a decade.
  • Reverse-engineering
  • Transformation
  • Validation
See how I work Get in touch

What moved

Every number here
is time.

Architecture earns its keep when something gets faster, cheaper, or possible. A director feels elapsed time before he feels anything else.

Stellantis · Computer vision01
6→1

Six weeks to one.

Image-based callout recognition converting spare-parts catalogs from the European standard to the American one. Running in production at a global automaker.

Delivery Hero SE · SAP BTP02
20+ → 2

Approval days, compressed.

$200M+ of capital spend made visible across 40+ countries, and 30+ more business cases cleared every month.

Gentera · Mobile03
14,000+

Into the field, daily.

An offline-first platform carried by more than 14,000 field agents, built to keep working with no signal at all. It roughly tripled what a rep could get through in a day.

40+countries served
$200M+capital spend visible
3×field throughput
Full résumé Two examples

Built & shipped

Not demos.
Certified, sold, run for real.

The real test of "production" is whether it cleared a bar someone else set, and whether anyone but me can verify it. Two of these you can open right now.

In practice · a clean build

A clean brief,
done right.

Most work isn't a rescue. Delivery Hero needed to approve capital fast enough to keep acquiring companies, and the job was simply to build it well: a reusable approval framework on SAP BTP, with the rules handed to the functional teams so they could change them without a developer.

Approvals went from over twenty days to two, dozens more business cases cleared every month, and the framework became the template for the company's other workflows. No drama, just a thing designed to last. It won SAP's Innovation Award that year.

  1. 01
    Design for reuse

    One framework, built so the next workflow is configuration rather than a new project.

  2. 02
    Hand over the controls

    Business Rules put approval logic in the functional teams' hands, not the developers'.

  3. 03
    Make it verifiable

    Status apps so initiators and approvers always know where a request stands.

In practice · when the org is the obstacle

Three months of six,
gone before day one.

A global automotive program at Stellantis, a quarter behind before I touched a system, because reaching the systems took three months. Until then I was reasoning about a data transformation from spreadsheets people emailed me. This is worth saying plainly: large organizations often work like this, and it isn't anyone's fault. The VPN takes a quarter, the rules live in a system nobody has documented in a decade, the access sits behind six approvals. Your company might run exactly this way. Mine did on this project.

The job is to find the way through it anyway. When access cleared, I went through the systems directly, including the network traffic behind their own web apps, compared data across source, intermediate and downstream until the transformation rules were clear, then defined the core logic and handed the team something real to build. It shipped on the date originally committed. If your environment looks like this, I've navigated it before, and I can help you navigate it too.

  1. 01
    Expect the friction

    Access, policy, and undocumented logic are the real timeline. Plan for them instead of being surprised.

  2. 02
    Derive the rules

    Read the systems directly instead of waiting for documentation that no longer exists.

  3. 03
    Hold the date

    Persistence, not heroics: keep moving through the friction until the committed date is met.

In practice · when it's slipping

Eight months in.
Ten weeks behind.

A California university's platform, and the delay was not technical. The program had no mechanism for pricing a new request, so every one got absorbed quietly and the arithmetic took care of the rest, the ordinary failure mode of a program under pressure. I spent my first week saying almost nothing, watching for the pattern.

Then I said one thing out loud: “We can do that. But we're already executing this sprint, so either it costs more, or something else gets de-prioritized.” Not a refusal, a price tag handed back to the people who get to decide. The program started moving that week, and reached production. Four years on it's still running.

  1. 01
    Watch

    A week in the room before changing anything. The pattern was scope, not skill.

  2. 02
    Name owners

    Split into teams. Short technical interviews against what people were actually delivering. The team got smaller, then it got right.

  3. 03
    Go down

    Corrected the architecture, learned the GCP services the team was already using, and coded features myself to find what was broken.

How I work

Three things
I don't flex on.

A clean build, an organization in the way, a program slipping: the three above ran on the same three things. Not a methodology I bring in, just how I work by default.

  1. 01
    Objectives, not hours

    I'm accountable for what reaches production, not for time logged against a plan.

  2. 02
    Try it, then read the result

    I learn by shipping and adjusting. That's how I picked up the cloud services one of these projects was already built on, and how I'm working through SAP's AI stack now.

  3. 03
    Hands up early

    I trust people to own their commitments and to say so the moment they're stuck. Do that, and nobody needs an excuse at delivery.

In other words

Said by people
who worked with me.

The same few things come back, from a client COO, a director who reported to me, and a teammate on the automotive program.

“Calm and methodical, backed by extensive full-stack and cloud knowledge. A great communicator and team player.”
Phil CoadyManaging Partner & COO, SPOSEA · managed Edgar directly
“He never approaches technology for technology's sake. He translates complexity into clear execution, and stays calm under pressure.”
Stephanie WuWorked with Edgar on the automotive transformation program
“One of the best leads I've worked with. Interested in his colleagues' growth, not just the bottom line.”
Sainath AllumallaDirector of IT · reported to Edgar directly
“Complete expertise in new and cloud technologies. Responsible, committed, high-quality deliverables.”
José Eduardo Franco LunaSAP Basis architect · worked alongside Edgar
More on LinkedIn

Where I work

I've run distributed teams
from Mexico since 2017.

None of this is new. I've been delivering remotely for US and European companies since 2017: two stretches with a US firm either side of a Dutch contract, a US logistics engagement, and a year on the ground in Germany before that. Further back, a multi-region SAP migration across North America, Europe and Asia in 2014. Today I direct delivery across India, the United States, Mexico and Argentina, on US business hours.

2017delivering remotely since
4countries in my teams
3languages · ES, EN C1, DE B1
About Edgar Get in touch

About Edgar

I go to the source.

16 years across SAP platforms, cloud, and AI: Deloitte, Delivery Hero, CEMEX, Santander, Grupo Bimbo, and now global client engagements from Cogent. An executive conversation in the morning, a network trace or a failing function in the afternoon.

What I actually do on a program rarely fits in a status report: understand the business problem, imagine the solution, set a hard date, and keep everything moving toward it, coordinating whatever needs coordinating and trusting the people around me to own their part. I write plenty of code with AI now, which only makes the second half matter more: someone still has to know whether the thing is actually right.

I've been early to this before, from document OCR at 80-million scale in 2008 to offline-first mobile in 2015, SAP through Node.js years ahead of CAP, and chatbots against SAP backends in 2019. AI agents are the current one, and I have one moving toward production now.

Read my résumé Follow my thinking
in

LinkedIn

Enterprise systems,
thinking out loud.

Open profile ↗
“The tool matters. The decision about where, why, and how to use it matters more.”
  • SAP BTP
  • Enterprise AI
  • Architecture
  • Delivery

Let's talk

The best conversations
start with a real problem.

A role you're trying to fill, a program that has to reach production, or an AI mandate with nobody yet to own it inside SAP. Tell me what it needs to do and what's in the way. I work with teams across the US and Europe from Mexico, on their business hours.

Email Edgar Connect on LinkedIn