An interview with Andrew Raynes, former Chief Information Officer, Royal Papworth Hospital NHS Foundation Trust and a globally recognised leader in healthcare transformation and digital innovation.
Automation has become a strategic priority across the NHS, yet many organisations still approach it as an IT project or a collection of point solutions. Through our work with more than 70 NHS organisations, we’ve seen that the greatest value comes when automation is treated as an organisational transformation— redesigning end-to-end processes to enable better ways of working.
To explore what successful transformation looks like in practice, we spoke with Andrew Raynes, former Chief Information Officer at Royal Papworth Hospital NHS Foundation Trust. With more than 25 years’ experience in healthcare and the public sector, Andy shares why successful automation depends as much on people, processes and culture as it does on technology—and what NHS leaders need to do to unlock its full potential.
Q&A with Andrew Raynes
Q: Why do many NHS organisations approach automation as an IT deployment rather than a transformation programme?
Andy: There is something about making an improvement through automation/tech but not understanding that difference it will make to sufficiently adapt let alone exploit it. In some organisations, digital is still seen as a cost centre rather than an enabler of change.
For me, successful transformation is about people, processes and technology working together. You can purchase automation software but implementing it at scale fundamentally changes business processes and often the roles of the people involved. That’s where the real challenge – and opportunity – begins.
Automation isn’t simply replacing repetitive tasks. It’s redesigning end-to-end processes, understanding how work changes, bringing people along on that journey, and ensuring technology enables staff to focus on more valuable and meaningful work.
Ultimately, project leaders need to think about all three elements—people, process and technology—and understand how each will be affected by the transformation.
Q: Where do end-to-end automation programmes typically break down?
Andy: There are three common failure points.
First, organisations don’t always have a clear vision of the future state. Without understanding where you’re trying to get to, it’s difficult to design the journey. That’s why defining both the current (“as-is”) and future (“to-be”) processes is so important.
Second is change management. Communication, education and empathy are essential. People need to understand why change is happening, what it means for them, and how they’ll be supported. If you fail to take people with you, the disconnect begins long before technology is implemented.
The third challenge is technology reliability. Even after months of preparation, if the technology fails on day one, confidence disappears almost instantly. Thorough testing and ensuring the solution works from the outset are critical to maintaining trust across the organisation.
Q: How do you see the role of the CIO evolving as organisations embrace automation and AI?
Andy: Increasingly, the CIO’s role is about enabling others to lead change rather than leading every initiative directly.
The people closest to clinical or operational work are often the strongest advocates for new technology because they understand both the challenges and the opportunities. Their peer-to-peer influence is incredibly powerful.
In healthcare, I often describe successful transformation as clinically led, operationally delivered and digitally enabled. Digital provides the tools and expertise, but lasting transformation happens when the business owns the change.
But it is not only the CIO’s role that is evolving. Everyone involved in these new ways of working will need to adapt and take on new roles and responsibilities. Leading this transition effectively—and providing the right support to help people develop new skills and adapt to change—is essential to bringing the wider organisation with you.
Q: How should healthcare organisations be measuring the impact of automation?
Andy: Start by being realistic.
Business cases often assume optimistic benefits, but in reality, outcomes rarely achieve the absolute maximum expected. Setting achievable goals makes success more meaningful and creates opportunities to exceed expectations.
Equally important is shared ownership. Benefits shouldn’t sit solely with digital or transformation teams—they need to be jointly owned by operational leaders and those responsible for delivering the change.
I also think we should move beyond simply talking about benefits and instead focus on value. Value considers both what you’ve invested and what you’ve achieved. Sometimes a lower-cost project delivering 80% of the expected benefits creates more value than an expensive programme delivering only 40%.
Understanding your baseline before the project begins is equally essential. Without knowing your starting point, it’s impossible to accurately measure improvement afterwards.
Q: How can organisations balance patient perspectives with staff experience when redesigning care pathways?
Andy: The answer is inclusion.
Recently, at Royal Papworth, we invited a patient representative into one of our process modelling workshops alongside our clinical administration team. It gave us an entirely different perspective.
Patients ask questions that professionals often don’t think to ask. Seeing the process “under the bonnet” helped them understand the complexity while also highlighting pain points, we’d become accustomed to.
The workshop led directly to practical improvements. For example, changes to telephone routing reduced call waiting by 39% for one clinic.
User groups—whether patients or staff—are incredibly valuable, but only if organisations act on the feedback. Listening is only the first step. Building confidence comes from showing people that their input leads to meaningful change.
Q: What excites you most about AI and intelligent automation in healthcare?
Andy: What motivates me most is seeing technology genuinely make a difference.
There’s nothing more rewarding than hearing someone say, “That really improved how we work” or “That made care better for our patients.”
AI and automation have enormous potential to help an increasingly stretched healthcare workforce by removing administrative burden and allowing skilled professionals to spend more time doing the work that only humans can do.
But alongside that opportunity comes responsibility.
Concerns around data protection and cybersecurity are valid, and open discussion is essential if we are to continue developing proactive safeguards against these risks. As AI adoption grows, we also need to think carefully about ethics, sustainability and environmental impact.
The computational power behind AI is significant, and we all have a responsibility to ensure these technologies are used thoughtfully and for the greatest possible benefit.
The future is incredibly exciting—but it must also be responsible.
Final thoughts
Andrew’s message is clear: the technology is rarely the limiting factor. Organisations achieve the greatest value when leaders create a clear vision, redesign processes, and bring people with them through change.
Luckily, no organisation must navigate transformation alone. Learning from peers can help avoid common pitfalls, accelerate delivery and realise greater value.
Join our free NHS peer community, created exclusively for NHS professionals and partners to explore real-world case studies, practical lessons and proven approaches from organisations delivering automation and transformation at scale.
Other resources:
A research study by Veera Häkkinen (Digital Workforce Healthcare Solution Consultant) about the new roles and responsibilities healthcare professionals are taking on as AI is integrated into care processes. The study explores these roles in the context of the EU AI Act and its requirements and compares different levels of human oversight through practical scenarios: https://trepo.tuni.fi/handle/10024/236238
A case study in transforming breast cancer follow-up at Helsinki University Hospital—sharing measured outcomes and exploring when to use algorithmic automation versus AI for maximum impact and secure control: https://digitalworkforce.com/rpa-news/hus-care-pathway-automation/
None of it is difficult. Somebody has to do all of it.
It is Monday morning. One of your suppliers has sent an email. From next month, the prices they charge you go up by 4.8%, across everything you buy from them.
Nothing about that email is unusual. A supplier has asked for more money for the same goods, and you get some version of it most weeks, from some supplier, in some category. It is not a crisis, nobody escalates it, and it will be handled.
Watch what has to happen before it is.
A supplier asks for a 4.8% price increase
Somebody has to:
Find the contract
Read the indexation clause
Check the correct index
Calculate the increase the contract actually permits
Decide whether to challenge it
Talk to the supplier
Update the agreed price
Make sure future orders use the new one
Weeks later, check that the invoices follow it
Any competent person in your team can do any one of these nine steps. The problem is that somebody has to do all of them, in order, for this supplier, this month.
And this is one email, one supplier, one price change.
Now multiply that by the thousands of suppliers and contracts you are responsible for, and by every purchase, commercial change and exception that arrives across a year.
Nobody in your organisation has ever seen that total, because no system holds a line called hours spent finding things. Your ERP records the order and your contract system records the clause, but neither of them records the forty minutes somebody spent working out which clause applied. So the work stays expensive and invisible at the same time, spread across hundreds of people who each experience it as a small annoyance.
Small annoyances do not get put on a board slide. They get absorbed, which is a polite word for paid for.
Those nine steps happen in six different places
Look at where that work actually took place.
The email arrived in an inbox
The terms were in the contract system
The index was published on somebody else’s website
The agreed price lives in the procurement system
The order and the invoice sit in the ERP
The approval ran through a chain of people, each of whom had to be asked, reminded and asked again
Nobody designed the work that way. Each of those systems was bought by a different function, on a different cycle and against a different set of requirements. Every one of them is good at what it does. Every one of them was a sensible purchase at the time.
What nobody bought was the thing that carries a case from one system to the next. That job went to a person by default, and it has stayed with a person ever since. It is the subject of the last article in this series.
Six systems, five handovers, one person. Each system was bought by a different function against different requirements, and each one is good inside its own edges. The gaps between them were never anybody’s purchase, so a person stands in each one, five times, for every price change that arrives.
You get the same equation every year
You are asked to deliver more value, hold more control and carry more risk, and to do all of it with fewer resources.
If you have worked in procurement or in finance for longer time, you have been handed some version of that every single year. Save more. Control more. Carry more risk, because there is always more risk. Do it with the same team, or with a smaller one.
The risk part is growing fastest in the work. The list of things you are expected to know about a supplier now runs to ownership, sanctions exposure, financial health, certifications, sub-tier dependencies, sustainability and cyber posture. Every one of those requirements arrived with a good reason attached, but none of them arrived with extra people attached.
The brief, drawn as the equation it is. Three terms on top, all of them growing, over a denominator that keeps shrinking. Eighty-six percent of chief procurement officers meet the savings target on the top line. What this series is about is everything the equation leaves no time for.
Here is the part that makes it interesting.
You are meeting the target. Deloitte’s 2025 survey of more than 250 chief procurement officers across 40 countries found that 86% of them met their cost savings targets.
So this is not a story about a function that fails at what it measures. You hit the number you negotiated. You can evidence it. The awkward question is a different one: what happened to everything you never got to?
The constraint is human attention
Your software is fine.
Your process design is fine and your team is good. I have spent a long time inside these functions, and the people in them are rarely the problem.
There is a finite amount of expert attention in your function every week. It is the scarcest resource you have and the most expensive one you buy. The work in front of you asks for more of it than exists.
That is the constraint. Budget, headcount and tooling all sit downstream of it.
Once you name it, a number of things stop being mysterious. Why savings you genuinely negotiated leak away quietly over the following two years. Why the supplier you screened at onboarding is still on the approved list three years later, under different ownership. Why a contract renewed on terms nobody had re-read.
None of that is negligence. It is arithmetic. Every one of those tasks was somebody’s job, and that somebody had a finite week.
You prioritise, you sample, you react
So what does a function do when the work exceeds the attention available to do it?
It does the only rational thing. It prioritises, samples, and reacts.
It puts expert attention on the biggest contracts and the loudest problems. It checks part of the population and assumes the rest behaves the same way. And it waits for something to surface before it goes looking.
Every one of those is a good decision. I would make the same three. Given fixed attention and unbounded work, that is what a competent leader does, and anyone who tells you otherwise has not run a category.
You can watch it happen in the way an approved supplier list ages. Everyone on that list was checked properly on the day they were added, by someone doing a careful job. That check was a photograph of a single afternoon. Since then:
Ownership has changed
Certificates have lapsed
A parent company has been bought by somebody you would not have approved
Nobody decided to stop looking. There was never a week when re-checking a supplier who had caused no trouble was the best use of the time.
But look at what each one costs.
Prioritising means most of your spend receives no expert attention at all. It is not that it was reviewed and cleared. Nobody looked.
Sampling means you judge the health of a whole population from a fraction of it, then report that judgement as though you had checked everything.
Reacting means you find the problem after it has happened, and after it has cost you something.
This is your operating model. It is a good design for the shortage it was built around.
Count the two piles and price the bigger one
Go back to those nine steps and sort them into two piles. Eight of them are retrieval and checking: finding, reading, calculating, transferring, remembering and monitoring. One of them is a decision, which is whether you accept this increase, challenge it or negotiate.
Eight steps of retrieval, one step of judgement. The list above runs in order, which is how the work feels when you are doing it. Sorted into piles it stops being a sequence and becomes a ratio. The eight are drawn the same size because none is harder than another, and none of them is why you recruited the person doing them.
That single question needs judgement, commercial instinct and a relationship with the supplier. It is the part your people are good at and never have enough time for.
You can run this on one process this week. It takes an afternoon and needs no budget. Pick something ordinary, such as a price increase, a supplier onboarding or a contract renewal. Choose one that happens often and that nobody in the room considers difficult.
Then three moves.
Count the retrieval steps. Count every action that involves finding, reading, checking, calculating, transferring or chasing. Be honest about the ones that happen in somebody’s head or in a spreadsheet nobody owns.
Count the steps that need judgement. These are the moments where a person weighs something and decides. In most processes there are far fewer of them than people expect. Naming them out loud is uncomfortable.
Price the first pile. Loaded hourly cost of the people doing it, multiplied by the time it takes, multiplied by how often the process runs in a year.
That last number is what your organisation currently pays for retrieval on one process. It is usually the first time anybody has seen it as a single figure, and usually larger than the room expects.
Two things tend to happen when a team does this properly.
The retrieval pile is longer than anyone guessed. The steps that live in somebody’s head never appear on a process map, so nobody counts them.
The judgement pile contains steps that need no judgement. What they need is a rule an experienced person has applied for years without ever writing it down.
Then ask the only question that really matters about the list. Which of those steps genuinely required a person?
Only one kind of work needs you
When a team answers that question honestly, the list stops being a sequence and starts being four different kinds of work. They are not interchangeable, and each of them has a different answer.
Judgement. Accept, challenge or negotiate. This needs commercial instinct and a relationship with the supplier. It belongs to a person who is accountable for the category. It should stay exactly where it is.
Reading and reasoning. Retrieving the contract, interpreting an indexation clause a lawyer wrote four years ago, checking the published index and assembling the evidence behind a recommendation. This used to require a person for one reason only, which is that reading was human work. AI agents now do this part reliably enough to run it on every case instead of a sample.
Execution in your systems of record. Updating the agreed price, pushing it into future orders, checking that the invoices follow it. This is integration and automation, and most large organisations already own most of the pieces.
Sequencing and evidence. Something has to carry a case across those six systems, decide what happens when a step fails, route the exception to the right person, and keep a durable record of who decided what and on what basis. This is orchestration. Almost nobody owns it.
Only the first row needs a person. The other three were human work because reading, executing and sequencing had nowhere else to live. Judgement is different in kind. It needs commercial instinct and a relationship with the supplier, so it should stay exactly where it sits today.
That last one is where the interesting failure lives. The email arrived at the front of your business, inside a supplier relationship that a named person owns. The consequence landed at the back, as a purchase order, an invoice and a payment in your finance systems. Those nine steps crossed the line between your front office and your back office four times. Each time, a person picked something up and carried it.
Most large organisations have automated pieces on both sides of that line. Very few own the crossing itself, which is where the time goes and where the errors surface.
None of this comes for free. Agents that read contracts have to be governed. They have to be monitored, corrected when they drift, tested against the decisions your best people actually make, and answerable when somebody asks why a recommendation came out the way it did. Capacity you cannot govern is not capacity. It is exposure, and you already have enough of that.
That is the work my colleagues and I do at Digital Workforce. People, AI agents and automation running as one governed flow across the systems a business already owns, from the front office through to the back. We operate it, so somebody is accountable on the day it drifts.
Where does your team spend its attention this week?
Next Monday, that supplier email arrives again. Someone will handle it well. It will take most of a morning.
The pressure your function is under has not changed much in forty years. What has changed, quite recently, is what it costs to pay attention to something, and that is what the rest of this series is about.
The next piece asks an uncomfortable question. Procurement has bought wave after wave of technology since the 1980s, and every one of those waves was worth buying. I would buy all of them again. So why is that same equation still sitting on your desk?
Before then, here is one question to take back to your team. Of all the expert attention your function will spend this week, how much of it will land on an actual decision?
If you want to take it further
On 30 September I am joining Brian Halpin of SS&C Blue Prism for a session on this, starting from a supplier price increase.
If you have run the count on one of your own processes, bring it. The discussion is usually more useful than the slides.
Deloitte’s 2025 Global Chief Procurement Officer Survey establishes that 86% of CPOs met their cost savings targets. The survey covers more than 250 CPOs across 40 countries, and the figure is self-reported. deloitte.com
The 4.8% price increase, the nine steps and the six systems are an illustrative example drawn from a common procurement scenario. They are not a customer figure and not a benchmark.
About the author
Stefan Meller is Principal Account Executive for Enterprise and Public at Digital Workforce.
Ask any automation team where their time goes, and you’re unlikely to get a simple answer. Waiting on a specialist to turn a business process into a working workflow, investigating stopped jobs, trying to figure out why it broke in the first place, answering the same how-to question they answered last week and writing documentation that was meant to be done three sprints ago. Those are just a few you might hear.
We’re talking the automation lifecycle: design, build, document, run, monitor. At every stage, a person has to translate, investigate, explain or configure something before the work can move again. Multiply that by 30 to 50 requests a week, and the backlog can easily grow beyond a manageable level.
AI changes this. Not in a vague “AI will transform everything” way, but in a specific, measurable, this-quarter way.
The AI capabilities inside RunMyJobs by Redwood are designed to enhance the complex automation lifecycle and eliminate productivity leaks: building workflows, handling exceptions, finding answers, writing documentation and more.
Workflow Builder: Describe it, upload it, done
Until now, turning a business process into an automated workflow meant translation. Someone who understands the process had to explain it to someone who understands the platform, usually across several meetings, a ticket and delays. RunMyJobs’ Workflow Builder removes the translation steps entirely.
You have two ways in, and neither requires you to write a line of code.
Prompt it. Type what you want in plain English. “Every night at 11, pull the sales extracts from SAP, validate the file counts, load them into the warehouse and alert the data team if anything fails.” That’s a workflow description, and it’s enough to get started.
It’s not a one-shot prompt machine, either. It’s more of a conversation. Look at what comes back and refine it, add a step, change a schedule, ask it to handle a failure case differently. You shape the workflow the way you’d brief a colleague, iterating until it matches what’s in your head.
Upload a document. This is the one that changes daily life for most teams. Drop in whatever already describes the process, such as a standard operating procedure (SOP), a process description or a runbook. The AI reads it and works out the steps involved in the automation.
Think about what that means. Your organization has years of process knowledge sitting in documents that describe exactly how work should flow. That knowledge used to be inert, but now it can serve as an input. The policy document becomes the workflow.
What happens under the hood matters more than the demo
Plenty of tools can turn a sentence into a flowchart. What makes Workflow Builder useful in a real enterprise is that it builds from your actual environment.
An intent agent parses your description or document and matches it against the real objects you already run: your jobs, your connectors, your partitions, your schedulers. It constructs the job chain and resolves the parameters from what genuinely exists. If it needs something that isn’t there, it doesn’t invent it. Instead, it flags the gap and shows you the closest match. Anything it can’t resolve gets marked as requiring your input.
And here’s the part your IT leadership will care about most: nothing gets created until a human explicitly approves it. The AI drafts, but you decide. Business users get the power to build, and IT keeps the oversight it needs. Best of all, nobody deploys a hallucination to production.
You’re going from policy to production in minutes. The intake queue doesn’t disappear, but it stops being the constraint. And the metric this moves is one your leadership already tracks: time-to-value. How long between someone deciding a process should exist and that process running in production? Today, that’s weeks of tickets and meetings. This makes it a same-day conversation.
Agent Studio: Human-in-the-loop to agent-in-the-loop
Building workflows faster clears the build queue. But the exception queue is still there, and it’s where Agent Studio comes in. Workflow Builder speeds up how workflows are built, and Agent Studio changes what runs inside them.
Even a well-automated workflow has moments that need judgment. A mismatch, an exception, an anomaly. Today, those moments all resolve the same way: the workflow stops, a human gets notified and the work sits in a queue until someone finds time to investigate. The automation itself is fast, but the exception handling is exactly as slow as your busiest person.
That’s the human-in-the-loop model, and for consequential decisions, it’s still the right one. But most of what the human does in that loop isn’t deciding; it’s the pre-work. Pulling the data, tracing where things diverged, figuring out whether this is the usual thing or something new. It’s skilled detective work, and it gets repeated from scratch, every time.
With Agent Studio in RunMyJobs, you build your own AI agents and put them into that loop instead. A custom agent runs as a step inside the workflow, doing the work a human would otherwise have to do before anyone even looks at the problem:
At a minimum, the agent does the analysis. When an exception fires, the agent investigates immediately, in the flow, and hands the human a worked-up case instead of a bare alert. The human still decides, but the hour of digging is already done.
At best, the agent decides, too. For patterns it recognizes, it resolves the exception itself, with a full audit trail, and only escalates the genuinely novel cases.
Judgment doesn’t disappear from the process, but it stops being the bottleneck.
Because these agents run as workflow steps, they inherit everything the workflow already has: the same schedule, the same governance and the same observability, with timeout and cost controls built in. You define the agent’s skills, connect its tools and run it on your preferred AI platform. Your deterministic process keeps running at full speed. The agent handles the moments in between.
The math is simple.
Exceptions get a first pass in seconds instead of hours
Fewer of them ever reach a human
The ones that do arrive with the investigation attached
Watch two numbers in particular: 1) mean time-to-resolution (MTTR), because the investigation now starts the second the exception fires, and 2) SLA attainment, because workflows stop sitting overnight waiting for a human’s first pass.
Product Assistant and Automation Co-pilot: Closing the last two leaks
So, workflows are being built faster, and exceptions are being handled in the flow. That leaves the question queue and the documentation debt, which is where Redwood RangerAI, the AI assistant layer inside RunMyJobs, steps in.
Redwood RangerAI ProductAssistant kills the search-and-escalate cycle. Every automation team has one or two senior people who hold the platform knowledge, and everyone else queues for their attention or digs through documentation that’s a version or two out of date.
Product Assistant effectively puts a senior platform expert in the UI at all times. Junior operators ask questions in plain English and get instant, context-aware guidance for troubleshooting and how-to questions.
The KPI? Time-to-productivity. When every operator has an expert on tap, new hires ramp in days instead of months, and escalation volume drops with them.
Automation Co-pilot takes on the two biggest killers of development velocity: scripting overhead and documentation debt. Developers describe what they need in plain language, and the Co-pilot generates the job scripts. It operates the platform through conversational commands and produces comprehensive technical documentation for any job or workflow in a single click, which means the documentation actually gets written. Anyone who has inherited an undocumented automation estate knows precisely what that’s worth.
Two numbers move here: delivery throughput, because weeks of scripting and documentation compress into hours, and key-person risk, because the knowledge stays with the organization, whether or not the person who built it does.
What you get back
Look at where a typical automation team’s week typically goes: waiting for a specialist to translate a request, answering the same how-to questions, writing scripts that follow well-worn patterns, investigating exceptions that turn out to be the usual thing. And documentation — or, more honestly, feeling guilty not having written it.
The AI capabilities in RunMyJobs take a bite out of every one of those:
Business analysts turn a process description or an SOP into a reviewable workflow draft in minutes, no ticket required
Custom agents do the exception pre-work in the flow, so humans decide instead of dig
Operators get answers in the moment, without escalating or searching
Developers build with prompts and clear the backlog instead of feeding it
Documentation happens in one click instead of never
The compound effect is the real story, and the number that matters most is capacity. Real operational efficiency looks like the same headcount, more delivered, because hours that once went into waiting, digging and re-explaining convert into work that ships. Junior staff start operating like senior staff. Senior staff stop being a bottleneck and start doing the work you hired them to do. The automation backlog — the one every enterprise has and nobody talks about — finally starts shrinking.
None of this removes people from the picture. It removes the queue between people and outcomes. Your team still decides what gets automated and approves what goes live. They just stop paying a translation tax on every single request.
Where you could be headed: Agentic orchestration
This is really about what happens once AI agents stop being a side project and start running inside your production workflows, governed the same way everything else is. If that’s the direction you’re already heading, take a look at how Redwood Software approaches agentic orchestration, making everything above safe to run at scale.
Somewhere in your organization, there is a script. It runs on a cron schedule on an EC2 instance nobody remembers provisioning. It checks an SAP system every five minutes to see whether a job has finished, and when it has, it calls an AWS API to kick off whatever comes next. A contractor wrote it two years ago. It has never been in version control, nobody has reviewed it since and it breaks every time an upstream format changes.
That script exists because of a problem almost every enterprise running AWS has. It sits between the AWS boundary and everything on the other side of it. Multiply that script by every system boundary in your enterprise, and the scope of the problem comes into focus.
Hybrid is the architecture, not a phase
For a decade, the industry narrative said cloud consolidation was the destination and that on-premises systems, ERP estates and private infrastructure were transitional states waiting to be resolved. Reality settled somewhere else.
Gartner forecasts that 90% of organizations will adopt a hybrid cloud approach through 2027. SAP contracts run for decades. Regulated workloads stay on-premises. AWS grows alongside those systems instead of replacing them.
Hybrid is simply the standard operating model of the modern enterprise. Few enterprises seriously considered going all-in on AWS. The real work has always been getting AWS to work alongside the SAP systems, on-premises infrastructure and other platforms already running the business.
The building blocks aren’t the problem
AWS services are excellent at what they do.
Amazon EventBridge is an elegant way to route events between applications
Amazon SQS has been reliable for nearly two decades
Amazon ECS and AWS Fargate made container operations accessible to teams that had no interest in running Kubernetes
AWS Step Functions, AWS Lambda, Amazon Managed Workflows for Apache Airflow (MWAA) and Amazon Aurora are best-in-class building blocks for serverless orchestration and distributed applications, and enterprises are right to build on them
The problem starts the moment a workflow crosses the AWS boundary.
Think of an AWS Batch job that can’t start until an SAP financial close completes, or a goods receipt in SAP that should trigger downstream AWS processing in real time, or a data pipeline that begins with an on-premises extraction and ends in Snowflake. AWS-native orchestration tools like Step Functions and EventBridge Scheduler work well inside the boundary, using a state machine and the Amazon States Language to manage task state, wait states and retry logic across a workflow. But they can’t see an SAP job chain, enforce a dependency on an on-premises process or govern an end-to-end SLA that spans both worlds.
So enterprises bridge that boundary the only way they can: with custom scripts, scheduled polling, Lambda wrappers and manual coordination. A team writes one script to solve a specific handoff. Another team writes a different script for a different handoff six months later. None of it appears on an architecture diagram, and after a few years, the integration layer holding SAP and AWS together is really just a pile of undocumented cron jobs.
The disconnect has a price tag
Deloitte’s 2026 Global Technology Leadership Study estimates that technical debt absorbs 21% to 40% of total IT spending, and the custom integration code accumulating at every system boundary adds to that figure with every new program. Flexera adds another dimension: 29% of cloud spend is wasted on idle or underutilized resources, often because nothing is orchestrating when infrastructure should be running.
The more visceral cost shows up at 9 AM on a Tuesday. A dashboard shows stale data. Was the failure in SAP? In the AWS pipeline? In the handoff between them? SAP logs live in one world, CloudWatch in another and the script connecting them logs to neither. Multiple teams are pulled in, and what should have been a five-minute diagnosis becomes an entire afternoon. Because the trigger was a polling schedule, the failure happened hours before anyone noticed.
Every new AWS service an enterprise adopts adds another boundary, another handoff, another script. The estate keeps growing. The distance between AWS and everything it depends on never closes.
A different model: An orchestration layer above the blocks
With orchestration, it’s a simple division of labor: AWS runs the cloud, and the orchestration layer runs the enterprise.
RunMyJobs by Redwood sits above the AWS execution tier. It doesn’t compete with EventBridge or Step Functions; it extends them to the systems they can’t reach. In this model, an SAP business event doesn’t wait for a polling window. RunMyJobs orchestrates the wider business service and publishes natively to EventBridge or populates application queues in SQS the moment the business event occurs, and the customer’s event-driven and serverless architecture takes it from there.
A container task on ECS, a Batch job and an Airflow DAG on MWAA can also each become governed steps in a chain that started inside SAP and might end with Snowflake, Microsoft PowerBI, Box or ServiceNow, with one dependency map, one SLA policy and one audit trail across the whole thing.
This works because the integration is native at every layer of the AWS stack.
The application layer:Connectors for EventBridge, SQS and SNS make orchestrated workflows first-class participants in event-driven architectures. They publish events, manage queues and fan out notifications using the same primitives AWS applications use to talk to each other.
The compute layer: EC2, ECS and Fargate, Batch and Lambda run as governed execution steps, with IAM roles controlling exactly what each one is allowed to touch. Instances start and stop around workloads, containers run and are monitored to completion and exit codes propagate into the dependency chain.
The data layer: S3, DataSync, Glue, AppFlow, MWAA and Amazon RDS govern the pipeline end to end. They ingest from on-premises and SaaS sources into a data lake or warehouse, trigger transformations, execute SQL and monitor Airflow DAGs as steps in a larger, governed whole.
Walking the chain: One retailer’s overnight run
Here’s what that looks like end to end.
Picture a retailer whose stores send the day’s transactions to SAP Customer Activity Repository overnight, where every cash register and every store is validated and audited. Merchandising needs those numbers on dashboards before the morning trade meeting.
The moment SAP confirms the data is complete, RunMyJobs publishes a “POS data ready” event to EventBridge, and every AWS application subscribed to it, from replenishment to store operations, knows instantly. There is no fixed 2 AM schedule and no guessing. In the same governed chain, RunMyJobs places a message on an SQS queue for each store’s dataset, and processing workers consume them at a pace downstream systems can handle.
A containerized ECS task enriches the audited data. The operational reporting database on RDS is refreshed, started for the load and stopped when idle, because nobody should pay for a database running at 4 AM for no reason. An MWAA pipeline aggregates by store, region and product line. The final datasets land in Snowflake, and the dashboards are live before the meeting starts.
Seven services. One SAP system of record. One dependency chain. If a store’s data never arrives, the team knows right away, rather than when the merchandising director is staring at incomplete numbers.
Nothing in that chain required a polling script or custom middleware at the SAP-to-AWS boundary.
Every migration wave, the same problem
One group experiences this disconnect as an active, funded problem rather than chronic background pain: teams in the middle of a migration to AWS.
Migrations move in waves, sequenced by risk and dependency. Compute and databases typically lift and shift first, and workloads modernize onto containers, serverless and managed pipelines as each one is ready. Every wave that introduces a new AWS service also introduces a new dependency that the old on-premises scheduler can’t reach, which leaves teams with the same choice each time: stop the wave and rebuild the connection back to SAP and on-premises, or move on and leave it broken. Either way, the orchestration layer becomes the migration’s bottleneck rather than the workload move itself, and every custom script written to patch the boundary is more technical debt.
When every AWS service in the migration path already has a native connector, that choice disappears. Each wave goes live with its dependencies already governed. The migration stays on the timeline the business case promised, and the orchestration layer is the one thing that never needs to be re-evaluated at the next wave.
Gut check: What to ask before your next AWS migration wave
1. The last time a workload moved to a new AWS service, what happened to the SAP or on-premises dependencies feeding it? If the answer involved rework, custom scripting or a delay, then every new AWS tier you adopt means re-solving the same orchestration problem.
2. If a critical cross-system process failed overnight, how quickly would you know, and how many tools would you need to open to find out why? If the honest answer is “when someone notices downstream” and “at least three,” the space between your systems has no owner.
3. How much of your engineering capacity goes to maintaining integration glue rather than building anything new? Deloitte’s estimate that technical debt absorbs 21-40% of IT spending holds true for most enterprises, and a meaningful share of it lives in exactly these scripts.
RunMyJobs will change your answer to all three. It’s the SaaS-native orchestration platform with native connectors across the AWS stack, deep SAP integration as the only SAP Endorsed App in workload automation and orchestration and a 99.95% uptime SLA. Every connector works without deploying infrastructure. Get a demo of RunMyJobs for AWS.
