Every data investment your organization has made rests on an assumption nobody wrote down: that the data will arrive complete, current and on time when the business reaches for it. The business carefully approved important data programs on their merits: a Snowflake migration, a Databricks rollout, the AI roadmap. All of them assume accurate data will show up when it’s needed. And the layer responsible for making that happen almost never gets tested against it.
I regularly sit across the table from data organizations in architecture reviews and discovery sessions, and I’ve watched the same pattern play out at company after company. A transformation feeds the nightly load that finance and analytics both depend on, but it runs on customer data that went stale two days earlier because an upstream sync failed, and nothing tied that failure to the deadline downstream. No alert fires, because someone built the alerting to catch job run failures instead of deadlines that slip. The pipeline run reports green, the executive dashboard reports green and the number that drives a decision is wrong. Nobody finds out until after someone has already acted on it.
The pattern repeats no matter how different the organizations are otherwise. Data infrastructure investment and data delivery reliability get treated as the same thing, and they aren’t. Enterprises pour money into the first and leave the second as an afterthought.
A green pipeline isn’t a business guarantee
Ask most data teams whether a pipeline succeeded, and they’ll check three things: did the job complete, did it throw errors and is the status green. All that tells you is that the process ran. It says nothing about the question the business is actually asking: did the right data show up, complete and current, at the moment a mission-critical application outcome, a strategic report or an agentic AI workflow needed it?
Those two definitions of “done” drift apart constantly. A Snowflake load can finish exactly on schedule, then hand off to an ERP process that opened its window before the load was ready. A dbt model can complete without a single error and still deliver its output an hour after the executive pack was already pulled. Both register as passing jobs, and both are deliveries that failed the business. That’s how you end up with a wall of green and no idea whether the business got what it needed.
Where accountability lands
Nobody measures you on pipeline uptime. They measure you on whether your analytics produce decisions people can trust, whether your AI initiatives survive scrutiny and whether the business believes the numbers you put in front of it. Those outcomes depend on an orchestration layer that executes the entire business process that’s reliable, traceable and measurable against real deadlines, not just functionally in a narrow, technical sense.
When that business process execution breaks behind the scenes, the fallout doesn’t stay inside engineering. It shows up as a figure that moved after leadership already acted on it. Once the business loses confidence in the data, somebody has to account for why. In the reviews I sit in, that reckoning lands on whoever owns the orchestration layer, working backward through four systems to piece together what happened and when. Trust doesn’t come back quickly, either: a long stretch of dependable delivery earns it, and one discrepancy nobody can explain spends it.
AI has made this exposure worse. When a model produces a bad outcome, the reflex is to interrogate the model. But the real culprit is more often a data refresh that ran late or died upstream. Most programs aren’t ready for this: Gartner found that 63% of organizations either lack the right data management practices for AI or aren’t sure they have them. The same research predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data. Without audit trails that show what arrived and when, there’s no way to prove the data was sound. You end up defending a result you can’t fully reconstruct, which is a hard position to be in when the questions come from the board.
The line item that wasn’t on the invoice
The organizations I work with have spent seriously on data platforms, data quality tooling, observability inside those platforms and, lately, on AI and machine learning infrastructure. The money isn’t the issue. What all that spending doesn’t produce is an orchestrated, governed execution layer: something that confirms the pipelines feeding your business services are delivering against real deadlines and required outcomes, not just running without errors.
The gap shows up first in the industries that went farthest down the automation road earliest. In financial services, 61.4% of organizations report that siloed automation environments constrain their AI readiness, according to original research from Redwood Software. These are well-funded organizations whose sophisticated data architecture never accounted for production coordination across the full business process. And where financial services goes, the rest of the data-intensive economy usually follows.
Here’s where I’d push back on how governance gets scoped. Most data governance frameworks orient around data quality dimensions like accuracy, completeness and consistency, and control concerns such as data security, access controls and regulatory compliance under GDPR or HIPAA. All of that matters, yet none of it answers the delivery question: did this data arrive for the process that needed it, at the time it needed it, with a traceable record of the path it took?
Trusted data isn’t only clean, compliant data. It’s data that arrived when the business needed it, and most governance programs have no way to prove that part.
Monitoring pipelines vs. governing delivery
Closing this gap calls for a change in how data delivery is governed, not another tool bolted onto your stack. Treating data workflows as production business services means a few specific things:
Monitoring gets tied to business outcomes rather than job completion, so the question becomes whether the financial close data is ready by the window the ERP depends on, instead of whether the pipeline ran
Dependency visibility runs the length of the chain, so a late or failed step upstream surfaces before the service deadline instead of during the postmortem
Evidence becomes something you can produce on demand: what ran, when, what it depended on and whether it met its SLA, without a two-day expedition across half a dozen disconnected tools and multiple teams
Alerting gets calibrated to business impact rather than technical status, so the signals that reach you are the ones that matter
The distance between “we monitor pipelines” and “we govern data delivery” is an operating chasm most data strategies have left open. It’s the difference between catching a problem in your own systems and hearing about it from the business.
Solve the problem that lives between teams
Delivery governance sits precisely where no single team’s mandate reaches. Between the team that runs the pipelines, the one that builds the applications and the one that schedules, runs and monitors the production process end to end, every technical task has a clear owner. What none of them answers for is whether the business got what it needed, on time and with proof it arrived. That question goes unanswered simply because nobody was assigned to answer it.
Closing it takes an orchestration layer that sits above the individual tools without replacing them. That layer connects the tools you already run (Snowflake, Databricks, Airflow or a managed Airflow service, native schedulers inside ERP and cloud services) and holds the full flow to the deadline the business actually cares about, recording what happened at every handoff. RunMyJobs by Redwood ties these siloed tools together into one governed flow. Airflow keeps orchestrating its pipelines; Snowflake keeps running its loads. What changes is that the delivery across all of these disparate tools finally has an owner and a documented, auditable trail.
When someone asks whether the data was complete and on time, the answer is already on record rather than reconstructed after the fact. Consolidating orchestration this way also means accelerating transformation across the enterprise at the lowest possible total cost of ownership (TCO) instead of adding one more scheduling tool for your team to manage and maintain.
Your board and your AI sponsors weren’t asking whether the pipeline ran. They want to know the data was there, complete, on time, ready when the business-critical decision needed it. That’s not something a data platform can tell you. The answer comes from the orchestration layer that governs how data reaches the business. Most companies haven’t built that layer yet. Until they do, all the governance in the world doesn’t answer the one question the business asked: did the data show up when we needed it?
Most SAP customers know the integration platform landscape is shifting. Cloud-native platforms are replacing legacy enterprise service buses, with leading vendors adding event-driven architectures, AI-assisted development and self-service tooling to meet the demands of increasingly distributed IT landscapes. SAP was named a Leader in the 2026 Gartner® Magic Quadrant™ for Integration Platform as a Service for the sixth consecutive year, reflecting how central cloud integration has become to enterprise modernization.
In SAP environments, that shift has a name most teams recognize well: SAP Integration Suite.
What makes the conversation different for SAP customers is that it comes with a specific deadline. Around 10,000 organizations are still running SAP Process Integration/Process Orchestration (SAP PI/PO), formerly SAP Exchange Infrastructure, an on-premises middleware platform built on SAP NetWeaver AS Java that functions as an enterprise service bus for application-to-application and business-to-business integration across SAP and non-SAP systems.
Mainstream maintenance for SAP PI/PO ends December 31, 2027. Extended maintenance runs through the end of 2030. If you haven’t started evaluating your path forward, the window for a considered transition is getting shorter.
What SAP Integration Suite brings to the table
SAP Integration Suite, part of SAP Business Technology Platform (BTP), is SAP’s cloud-based answer to the integration platform question. It brings together process integration, API management, event-driven messaging and B2B capabilities in a single platform designed for hybrid IT landscapes. For organizations adopting RISE with SAP, moving to SAP Cloud ERP or extending their SAP BTP footprint, SAP Integration Suite increasingly serves as the strategic integration layer.
The transition from SAP PI/PO to SAP Integration Suite is not a simple swap. A mature SAP environment may have hundreds of integration flows built over many years, each carrying dependencies, business logic and operational assumptions specific to how the SAP PI/PO environment was configured. Some of those flows are strong candidates for migration. Others are deeply embedded in critical, cross-system processes that will require careful analysis before anything moves.
The integration migration itself is a known problem. Many teams have frameworks for it. The less obvious question is what governs the end-to-end business process once integration moves across cloud services, external systems and specialized tools.
Integration flows aren’t the same as business process control
SAP Integration Suite is built to connect systems and move data. That is its purpose, and it handles it well. But an integration flow completing successfully doesn’t automatically mean the business process it supports has completed correctly.
Think through a straightforward example. A supplier file arrives, is picked up by a managed file transfer process, validated and handed off to SAP Integration Suite for transformation and routing. The integration flow delivers its payload to SAP S/4HANA, where a business object is updated. A downstream reporting job then needs to run before the operations team can confirm the result before the business day starts.
Each component in that chain has its own execution boundary. The file transfer system knows whether the file arrived and was delivered. The integration platform knows whether the flow executed. The ERP knows whether the object was updated. But nothing in that picture inherently knows whether the sequence completed in the right order, with the right inputs and within the expected window.
The question most migration plans don’t address early enough is who owns the sequence once the integration layer has done its part.
Connecting RunMyJobs across the SAP integration transition
RunMyJobs by Redwood is designed to answer that question across the full SAP integration landscape. It supports customers at both stages of the SAP PI/PO migration journey.
For teams still running SAP PI/PO, RunMyJobs can orchestrate business processes that depend on existing SAP PI/PO integration flows. That means you can stabilize current operations and maintain process governance while migration planning proceeds, rather than treating the two as separate workstreams.
For teams moving to SAP Integration Suite, the RunMyJobs connector for SAP Integration Suite – SAP Cloud Integration enables RunMyJobs to deploy, monitor and manage iFlows as part of broader, end-to-end automation chains. RunMyJobs tracks iFlow execution status, waits for confirmed completion and triggers downstream steps only when the integration layer has finished its work.
That matters because most business processes extend well beyond the integration layer. They continue into ERP background jobs, data pipeline runs, file exchanges with external partners, analytics refreshes and exception handling workflows. SAP Integration Suite orchestrates none of that by design. RunMyJobs does.
The same principle applies beyond SAP-native integration. Many enterprise landscapes run more than one integration platform simultaneously. RunMyJobs includes pre-built connectors for non-SAP platforms, including Boomi and Informatica Cloud, allowing teams to coordinate SAP Integration Suite alongside other integration tools from one central control layer.
Browse Redwood’s connector portfolio to see how RunMyJobs connects across cloud, integration, data and business applications.
Where managed file transfer requires separate attention
One area that surfaces consistently in SAP PI/PO migration conversations is file transfer.
SAP PI/PO handled more than message transformation and routing for many customers. It also covered file-based exchange scenarios, including B2B file exchange with trading partners and suppliers. As those customers move to SAP Integration Suite, some of those file transfer requirements need to find a different home.
From conversations with customers working through this transition, we’re seeing a pattern: SAP Integration Suite is the right platform for process integration and integration flows, but certain managed file transfer (MFT) requirements sit outside its design envelope. Handling files larger than 40 MB and supporting certain B2B server protocols are two areas where customers have encountered design constraints.
JSCAPE by Redwood addresses those scenarios directly. JSCAPE supports secure managed file transfer for SAP landscapes, including large file exchange and B2B protocols that require dedicated file transfer capabilities. Where SAP Integration Suite handles the integration and transformation work, JSCAPE handles the secure movement of files that fall outside those boundaries. RunMyJobs sits across that architecture, governing the sequence without asking any single platform to exceed its scope.
Return to the supplier file example above, now with the specific platforms involved. A typical modernized SAP integration process might run as follows.
A trading partner delivers a large file through JSCAPE
JSCAPE validates the transfer and signals RunMyJobs that the file is ready for processing
RunMyJobs triggers the appropriate iFlow in SAP Integration Suite
Once the iFlow completes, RunMyJobs launches the relevant SAP S/4HANA job, monitors it to confirm completion and triggers whatever reporting or reconciliation step comes next
If the file doesn’t arrive, the chain doesn’t proceed on a fixed schedule. If the integration flow fails, the ERP job doesn’t run on incomplete data. If the SAP job finishes late, the downstream impact is visible across the full process — not buried inside a single system’s log. And it’s even visible in SAP Cloud ALM due to out-of-the-box integration with RunMyJobs.
This is also consistent with the clean core principles that many SAP customers are already pursuing. Instead of custom scripts, local schedulers or manual operational checks embedded in or adjacent to the ERP, process governance runs through an orchestration layer that sits outside the core and spans the full landscape.
Act before the deadline
The SAP PI/PO maintenance timeline gives teams a clear forcing function, but the goal shouldn’t be to reach the last possible moment and swap one integration platform for another.
The more useful frame is: what should your integration strategy look like in a cloud-first SAP landscape? SAP Integration Suite is a strong foundation for cloud-based process integration. JSCAPE addresses MFT requirements that need dedicated handling. RunMyJobs provides the governance layer that makes the whole process observable and controllable from end to end.
Teams still running SAP PI/PO have a meaningful opportunity right now to identify which interfaces belong in SAP Integration Suite, which file-based scenarios need dedicated MFT capabilities and which business processes need enterprise orchestration to hold together across multiple systems.
That planning reduces migration risk. More importantly, it means the architecture that follows is built to be managed, not just migrated.
Legacy automation keeps the lights on. Intelligent automation readies financial services for artificial intelligence (AI).
Financial services firms have automated work for decades. Batch jobs close books. Scripts move files. Robotic process automation (RPA) bots handle repetitive data entry. Business process automation tools route approvals, update records and reduce manual processes that used to slow entire departments.
That investment matters. It also hides a problem.
Many financial institutions now run too much automation in too many places. A bank may schedule core banking jobs in one platform, move payment files through another, use RPA for manual data entry, rely on custom scripts for data collection and add AI tools on top. Each piece may work on its own. The process still breaks when systems need to act together.
According to exclusive Redwood Software research, 80.4% of financial institutions use a centralized automation platform, yet only 18.6% have enterprise-wide orchestration with cross-system visibility. That gap says a lot about where financial services automation stands today. Adoption is high. Coordination is still rare.
The difference between traditional and modern automation platforms goes deeper than the deployment model. Traditional platforms automate known tasks inside defined systems. Modern platforms coordinate processes, data and decisions across hybrid environments with governance, observability and AI-ready controls. That shift is what separates automation that keeps operations running from intelligent automation that can support AI at scale.
Automation modernization is now a board-level priority
Financial services companies are under pressure from every side. Customers expect real-time customer experiences. Regulators expect stronger evidence, faster reporting and better control. Fintech firms keep raising the standard for speed. AI has moved from experiment to investment plan, and executives want to know which processes can support it in production.
The examples show up across the sector. A bank modernizes payments to support instant settlement. An insurer tries to speed claims. An asset manager streamlines financial reporting across markets. A lender wants faster decision-making without adding risk to underwriting. In each case, the business goal is not “more automation.” The goal is operational efficiency, lower risk and faster delivery of new digital services.
Legacy systems make that harder. They keep work moving, but they also preserve technical debt in the daily operating model. Manual processes stay wrapped around brittle scripts. Human error creeps in through handoffs that no dashboard can see. Changes take longer because every upgrade, connector and dependency has to be checked against years of custom work.
What traditional automation platforms were built to do
Traditional automation platforms were not bad tools. They solved the problems they were designed to solve.
Most were built for stable environments where work followed predictable schedules. A nightly batch closes. A file transfer runs at 2 AM. An ERP job starts after another job completes. A report is generated, stored and distributed. In that model, time-based scheduling, job dependencies and script execution were enough.
RPA extended that idea into the user interface. Bots copied data between screens, reduced manual data entry and helped teams move routine work out of inboxes and spreadsheets. Business process automation tools did something similar for approvals, task routing and simple workflow steps.
Those patterns still have a place. Stable, rules-based workloads in low-change environments do not always need a heavy modernization program. Traditional platforms can still run isolated ERP jobs, scheduled data movement and repetitive back-office work.
The problem starts when those same platforms are asked to support cloud services, APIs, AI tools, event-driven workloads and processes that cross a dozen systems. Financial services no longer operate inside neat system boundaries. Automation platforms have to follow the business process and the job schedule.
Where legacy approaches break down in financial services
Legacy systems rarely fail all at once. They slow modernization in layers.
Agent-heavy stacks add infrastructure that has to be patched, monitored and upgraded. Point-to-point integrations depend on custom code that only a few people understand. Scheduling and monitoring often sit in separate tools, so teams see whether a job ran but not whether the full business process was completed. Upgrades become projects. Every change carries operational risk.
Compliance pressure makes the problem harder to ignore. KYC, AML, anti-money laundering controls, SOX, GDPR, transaction monitoring and fraud detection depend on audit trails that span systems. A script that updates one record may be easy to explain. A customer onboarding process that moves across identity verification, sanctions screening, customer data platforms and account provisioning needs end-to-end audit readiness.
Legacy automation also weakens cybersecurity and risk management. Unmonitored scripts, inconsistent access controls and manual handoffs create blind spots. They also make it harder to prove which process ran, which data moved, who changed a workflow and where an exception occurred.
AI raises the stakes. Generative AI, machine learning models, agents and agentic AI all need governed access to systems of record. Without an orchestration layer, firms end up with AI tools that can recommend actions but cannot safely execute them across production systems. The model may be ready. The operating environment is not.
What modern intelligent automation platforms deliver
Modern intelligent automation acts as a governed execution layer across the enterprise. It does not stop at job scheduling. It coordinates work, data and decisions across core platforms, ERPs, CRMs, cloud applications, partner systems and data platforms.
That shift changes the architecture. Event-driven automation replaces rigid batch windows when a process needs to respond to business activity. APIs replace brittle point-to-point scripting where possible. Dependency management shows how one step affects the next. Observability gives operations, application, compliance and business teams a shared view of what is running and where risk is building.
Intelligent process automation adds more context to the work. Machine learning and predictive analytics can detect patterns, forecast SLA risk and recommend next steps. Natural language processing and document processing can extract data from unstructured data sources like contracts, claims, statements and customer messages. That data extraction can then feed automated workflows, data analysis and operational decision-making.
This is where modern automation platforms start to support AI readiness. They manage transactions, data collection and management and process execution as connected work. They also give teams a governed way to add AI agents into business processes without turning every new use case into another silo.
How traditional and modern automation platforms compare
Area
Traditional platforms
Modern platforms
Architecture
On-premises or self-hosted, often agent-heavy
Enterprise-grade SaaS, cloud-ready and built for hybrid operations
Integrations
Point-to-point scripts, custom connectors and tool-specific interfaces
API-first connectivity across ERPs, CRMs, core systems, cloud apps and partner platforms
Visibility
Job status and failure alerts
End-to-end observability across workflows, dependencies and business services
Governance
Tool-level permissions and fragmented logs
Centralized governance, role-based access and consistent audit trails
Scalibility
Scale by adding infrastructure, agents and admin effort
Scale through SaaS architecture, reusable workflows and centralized control
AI readiness
Limited support for AI tools, agents and real-time data flows
Governed orchestration for machine learning, generative AI, AI agents and agentic AI
Upgrades
Long upgrade cycles, manual testing and disruption risk
Managed updates, shorter maintenance windows and less infrastructure overhead
Compliance
Evidence gathered from multiple tools and manual records
Audit readiness built into the process with traceable workflow history
The practical difference is simple. Traditional platforms run tasks. Modern platforms coordinate outcomes.
Why legacy automation limits AI readiness
AI readiness is often discussed as a model problem. In financial services, it is usually an execution problem.
Machine learning can score a transaction for fraud, but the score has limited value if the workflow cannot pull current account data, check sanctions lists, update the case system and route the exception in time. Generative AI can summarize a customer file, but the summary is risky if source data is incomplete or stale. AI agents can act across systems, but only if those actions follow approved rules, access controls and audit trails.
Redwood’s research found that 61.4% of financial institutions say siloed environments constrain AI readiness. That is the real barrier for many firms. Legacy systems and fragmented data flows limit how safely and reliably AI can move from pilot to production.
Modernization gives AI a better foundation: orchestrated data movement, governed automation, real-time monitoring and consistent decision-making controls. It also helps firms bring unstructured data into usable workflows through document processing, natural language processing and data extraction. Without that foundation, AI remains dependent on processes that were never designed to support it.
Financial services use cases where modernization pays off
Client onboarding and identity
Customer onboarding is one of the clearest examples. Banks, insurers and wealth platforms all need KYC, AML, identity verification and customer provisioning to run in sequence. Traditional automation may handle one step. Modern intelligent automation coordinates the full workflow across internal systems, third-party providers and compliance checks.
Intelligent document processing helps here by reducing manual document review and data extraction from onboarding forms, identity files, contracts and account documents. That lowers manual effort and gives risk assessment teams a clearer trail of what happened.
Lending and underwriting
Loan origination and loan processing depend on speed, data quality and controlled decision-making. Banks, non-bank lenders and fintech firms all need underwriting workflows that bring together customer records, credit data, document processing, risk assessment and approval steps.
Traditional automation can schedule tasks around that process. Modern platforms can orchestrate the process itself. That matters when underwriting decisions depend on machine learning models, human review, compliance checks and ERP or core banking updates happening in the right order.
Payments and settlement
Payments modernization is unforgiving. Real-time payments, cross-border flows, ISO 20022 and reconciliation all depend on timing, transaction data and exception handling. A delay in one system can create a backlog in another.
Modern automation platforms help connect payment systems, fraud detection, sanctions screening and reporting workflows so teams can see dependencies before they become production issues. That visibility matters in environments where processing delays carry financial, customer and regulatory consequences.
Fraud detection and financial crime
Fraud detection and financial crime prevention depend on machine learning models, transaction monitoring, sanctions screening, case management and regulatory reporting. The AI model is only one part of the process.
A modern orchestration layer helps the surrounding workflow act on that model’s output. It can trigger a review, route an exception, update a case, collect more data or pause downstream activity. Risk management improves when the process is visible and governed from end to end.
Finance and back-office operations
Accounts payable, financial operations, regulatory reporting and the financial close all depend on accurate data collection across systems. These processes run across ERP platforms, banking systems, data warehouses and reporting tools.
Traditional automation often leaves finance and accounting teams reconciling exceptions manually. Modern intelligent automation can coordinate data movement, approvals, validations and reporting workflows with stronger control over timing, ownership and audit trails.
Customer experience and digital channels
Chatbots, virtual assistants and generative AI are becoming common in digital servicing. They can help answer routine questions, summarize customer history and support faster service. But customer experiences only improve when the underlying workflow can act on the request.
The same applies in asset management and financial markets. Forecasting, portfolio analysis and predictive analytics depend on current data, clean lineage and consistent execution. Modern automation does not replace those models. It gives them a controlled path into the systems that run the business.
The governance and compliance advantage of modern automation platforms
Governance is sometimes treated as a control function. In automation, it is what makes scaling safe.
Modern platforms give teams centralized control over how workflows run, who can change them, which systems they touch and how exceptions are handled. Role-based access, lifecycle management, immutable audit trails and workflow history help teams prove that automation behaved as expected.
That matters across KYC, AML, GDPR, SOX, regulatory reporting, transaction monitoring and cybersecurity. Compliance checks become part of the workflow rather than a manual exercise after the fact. Audit readiness improves because evidence is captured as work runs, not reconstructed later from five different tools. 91.4% of financial institutions agree that automation improves compliance and resilience. That value increases when automation is governed across systems instead of managed in isolated pockets.
What to look for when evaluating a modern automation platform
A modern automation platform should be evaluated by how well it supports the operating model you are moving toward, not only by how many jobs it can schedule. The strongest platforms help reduce total cost of ownership, retire unnecessary technical debt, lower operational risk and support modernization without forcing teams to rebuild every process at once.
Look for a platform with enterprise-grade SaaS architecture, high availability and security certifications. Check API coverage, connector depth and how easily teams can connect ERPs, cloud platforms, data tools, service desks, observability platforms and AI ecosystems. Make sure observability is more than a failure dashboard. Predictive analytics, SLA monitoring and dependency visibility should help teams act before a process misses its business window.
AI readiness should also be part of the evaluation. That means governed support for agents, agentic AI and ecosystem standards such as MCP and A2A. It also means audit trails, cybersecurity controls and access policies that apply to the workflow rather than only the platform interface.
RunMyJobs by Redwood fits this modern profile. It is a unified orchestration control plane that connects applications, processes and data for mission-critical outcomes. The platform supports event-driven automation across systems, processes and data, hybrid orchestration without the infrastructure burden of agents, persona-based observability and predictive SLA monitoring.
RunMyJobs also includes Redwood RangerAI for automation lifecycle support, agentic orchestration and interoperability with MCP and A2A. RunMyJobs is a fully managed SaaS with 99.95% uptime guarantee, SOC 2 Type II, ISO 27001, TX-RAMP, role-based access and audit transparency. It is also the only SAP Endorsed, Premium-certified orchestration and workload automation solution.
Moving from legacy automation to an AI-ready foundation
Replacing every tool at once is rarely the right starting point. It creates risk, slows progress and pulls your teams away from the work that keeps financial services operations stable.
The more practical path is a modern orchestration layer that connects what already works, reduces dependency on fragile custom scripts and gives your teams a controlled way to add new workloads over time. That lets you modernize without turning the program into a rip-and-replace project.
This is the real difference between traditional and modern automation platforms. Traditional platforms help you run tasks. Modern intelligent automation platforms help you run the business processes that depend on those tasks, with the visibility, governance and data coordination AI now requires.
For financial services, that foundation is becoming hard to separate from digital transformation itself. AI readiness, compliance resilience, operational efficiency and modernization all depend on the same thing: automation that can coordinate work across the enterprise, not only execute it inside silos.
It’s 7:14 AM, and Finance has already filed a ticket. The overnight reconciliation report is missing data. You open three tools and work through the list:
✔ The Apache Airflow DAG completed
✔ The Snowflake load finished on schedule
✔ The ERP batch job ran without error
Every status is green. An hour later, after pulling logs and looping in data engineers and the ERP team, the root cause surfaces: a batch window collision. Three days earlier, someone on the data engineering team rescheduled a Snowflake data transformation job without flagging the downstream dependency. By the time the transformation finished, the ERP ingestion window had already opened and run on whatever data happened to be there.
No tool failed. No alert fired. The business simply didn’t get what it needed.
Here’s what should bother you about this: every tool in the chain did its job correctly. The Airflow DAG ran exactly as designed. Snowflake processed its workload on schedule. The ERP batch process completed without error. The failure didn’t happen inside any of these systems. It happened in the space between them — the business process handoff that none of them was built to own.
Who’s accountable for the execution chain from system to system?
This isn’t a tooling failure, and it isn’t a criticism of any individual platform. Airflow is excellent at orchestrating data engineering workflows. Snowflake is excellent at processing analytical workloads. ERP schedulers are excellent at managing batch execution. Each of these tools does exactly what it was designed to do, within its own domain.
But the metric your leadership actually cares about — Did the business get trusted data on time? — isn’t tracked by any of them. There’s no shared dependency model spanning the end-to-end workflow, no common SLA tying the outputs of one system to the inputs of the next and no unified data pipeline monitoring capability that measures data flow against business deadlines rather than technical job completion. Each tool’s definition of “done” stops at its own boundary.
A 2025 IBM Institute for Business Value study of 1,700 chief data officers found that poor data quality often goes unnoticed precisely because its impact doesn’t surface at the point of failure. It appears downstream as an incorrect decision, lost revenue, process delays and compliance exposure, long after the root cause has propagated.
If that finding describes your Monday morning with uncomfortable precision, will you keep treating these episodes as isolated incidents, or will you recognize them as an architectural gap in how the end-to-end business process is governed?
The postmortem cycle you can’t break
By the time Finance files the ticket, the failure has already propagated. The reconciliation report is wrong, the financial close cycle may have started on incomplete data and your team is in recovery mode, conducting root-cause analysis on a problem that occurred hours earlier. Mean time-to-resolution (MTTR) starts from when the business notices, not when the job failed. The time between those milestones is typically measured in hours.
What makes this pattern so persistent is that it never quite presents as a systems failure. It looks like a process coordination issue, easily slipping between the various team-to-team cracks. And it gets addressed in a postmortem, assigned to a working group and recurs two months later with a marginally different trigger: a different rescheduled job, a different batch window, a different team that lacked awareness of the downstream dependency.
You’ve seen this cycle. The postmortem identifies “improved cross-team communication” as the fix. The action item is a shared calendar or a Slack channel. It holds for six weeks. Then someone new joins the data engineering team, a batch window shifts by 30 minutes or a schema change propagates without notification, and nobody updates the tribal knowledge that was holding the chain together.
The structural cause is that no one owns the end-to-end business process that spans these tools. It’s never truly resolved because it’s rarely named as the problem. Instead, it gets filed under “communication,” which is a diplomatic way of saying “we have no dependency model across the business workflow, and we’re substituting human memory for architecture.”
Two chains, same invisible failure
The handoff problem surfaces differently depending on where it hits. Two scenarios illustrate how much ground it covers.
In a B2B edge-to-core flow, a supplier file arrives at the network edge via a secure file transfer gateway. From there, the file requires transformation, schema validation and ingestion into the ERP as part of a larger supply chain or financial process. Each step runs on a different schedule, owned by a different team, with no shared data lineage connecting receipt to posting. When the supplier file lands two hours late, the failure is silent until inventory counts are off, an invoice doesn’t post or a supply chain decision gets made on data that hasn’t fully arrived. IT owns the latency, even though the failure happened in a gap nobody was monitoring.
In a financial close scenario, period-end close depends on outputs from cloud data platforms like Snowflake, Databricks or a cloud data warehouse service, feeding into the ERP’s record-to-report process. When data engineering reschedules a transformation job without flagging the downstream ERP dependency, the batch window executes, the job shows green and Finance pulls the morning pack to find numbers that don’t reconcile. The data freshness issue doesn’t surface until the business is already operating on compromised figures.
In both cases, every individual tool performed correctly within its own domain. The failure resided in the business process that depended on their outputs arriving in the right sequence, at the right time, for the right downstream system.
The reflex that keeps you stuck
When the same failure recurs, the instinct is to add more observability: more alerts, more status feeds, another real-time dashboard layered on top of existing tooling. More signal gets you to the problem faster, but it doesn’t change the fact that the business found the problem first.
Each tool produces comprehensive telemetry about its own execution. What’s missing is visibility across the end-to-end business process that depends on those tools. SLA management is tied to business outcomes rather than individual job completion, and dependency mapping spans the full workflow from data platform outputs through ERP ingestion to downstream business action.
That’s the layer a business service orchestration platform like RunMyJobs by Redwood occupies. It doesn’t replace Airflow, Snowflake, ERP schedulers or any other domain-specific tool. Each continues to do what it does best. RunMyJobs integrates their inputs and outputs into the broader business workflow, applying SLA monitoring, compliance, security and dependency governance across the full chain. It’s the technology-agnostic orchestration layer for the business process that currently has no owner.
Visibility starts where the tools stop
The hybrid application and data technology estate won’t consolidate or become less complex on its own. Innovation demands that new applications be built and new platforms be adopted. With this inevitable expansion comes the open-source data pipeline orchestrator, application-native scheduler, cloud service tooling, ERP batch process and trading partner file transfer workflows. This is the environment today — and for the foreseeable future.
Come back to the 7:14 AM ticket. If you had RunMyJobs running that business service, the ticket would have never happened. Neither would the multi-team incident response, the protracted root-cause analysis and all the finger-pointing and frustration these types of failures create. RunMyJobs would have monitored, identified and automatically remediated the situation, and the business service would have been delivered on time, without error.
Closing this architectural gap requires a strategic decision on application and data orchestration. It means looking at your automation silos and deciding to consolidate mission-critical business application outcomes onto a platform that can accelerate your transformation at the lowest possible total cost of ownership (TCO). That’s not a monitoring upgrade, an amended cross-team communication process or another dashboard that doesn’t address the underlying problem. It’s a different and vastly superior operating model.
SAP landscapes have become considerably more complex than the tools most teams use to automate and optimize how heavy backend workloads run.
A decade ago, background job scheduling was a contained problem. SM36 and SM37 handled ERP processing, local schedulers covered the rest and the architecture those tools were built for was largely self-contained.
That architecture is gone for most enterprises. A single business process now routinely spans SAP S/4HANA, SAP Cloud ERP, SAP Business Technology Platform (BTP), SAP Business Data Cloud (BDC), SAP Analytics Cloud, Databricks, Snowflake, AWS … and the list goes on … before producing a result anyone can act on. Each platform executes reliably within its own boundary. Whether the process completes reliably across all of them is a problem local scheduling can’t solve.
To answer the question, “How does this job impact the entire business chain?” SAP architects must differentiate between simple task scheduling and true enterprise orchestration.
When local scheduling remains the right call
Native scheduling tools are legitimate architectural choices, not placeholders until something better comes along. For isolated, self-contained tasks with no upstream dependencies and no downstream impact — and where advanced or variable calendaring handles any scheduling complexity — they’re often exactly what the job requires.
Across a modern SAP estate, that means:
SM36 and SM37 for standard background processing in SAP S/4HANA and SAP ECC: batch jobs, reports and ABAP programs that live entirely within a single ERP instance and don’t depend on external system state
SAP BTP Job Scheduling Service for Cloud Application Programming (CAP) model applications running on SAP BTP Cloud Foundry: time-based or one-time job execution for CAP services that operate independently within the SAP BTP environment
Application Jobs for RESTful ABAP Programming (RAP) model extensions on SAP S/4HANA: the metadata-driven, Fiori-integrated successor to SM36/SM37 for modern ABAP development, appropriate when the job scope stays within the SAP S/4HANA system boundary
Native scheduling within SAP Integrated Business Planning (IBP), SAP SuccessFactors and SAP Digital Manufacturing: purpose-built schedulers for localized workloads inside those solutions, where cross-system coordination isn’t required
Built-in schedulers in Snowflake and Databricks for internal scripts and transformations that begin and end within those platforms
The common thread is isolation. Each of these tools executes reliably when the task it governs doesn’t depend on the state of another system and doesn’t need to trigger work in one.
Trigger points: When traditional scheduling becomes operational risk
Three conditions reliably signal that native scheduling is no longer sufficient.
The job becomes a link in a cross-system chain. As soon as a task has an upstream dependency outside its own platform or triggers a downstream action in another system, local schedulers start operating on assumptions. For a material requirements planning (MRP) run that depends on an external warehouse feed completing first, a Datasphere refresh that needs to finish before SAP Analytics Cloud models publish or a CAP service on SAP BTP that should only execute after an upstream SAP S/4HANA job confirms success, native schedulers in each of those systems can only confirm that their own job ran. None of them can verify the state of the system that the next step depends on.
You need resource-aware, resilient execution. High-concurrency workloads like SAP Datasphere task chains, Databricks pipeline runs and overnight batch sequences across multiple platforms require load balancing, automated retry logic and intelligent error handling. Without a coordination layer, a single failure can cascade across dependent processes before anyone is notified.
Your roadmap involves eliminating operational blind spots.RISE with SAP and clean core transformations distribute process logic across SAP BTP services, cloud extensions and non-SAP platforms. That distribution improves architectural flexibility and creates a new operational problem: no single view of what’s running, what’s waiting and what failed across the landscape. Each platform reports on itself, but nothing reports on the process.
Governed execution in practice
RunMyJobs by Redwood is designed to take over at the boundary where native scheduling capabilities end. Rather than replacing SM36/SM37, Application Jobs or the SAP BTP Job Scheduling Service, it coordinates them — along with every other system in the landscape — into governed, end-to-end process flows. Workflows execute based on verified event completion and real-time system state, where a downstream process starts because the upstream transformation succeeded, not because a timer reached a predetermined hour.
The difference a dependency makes
Scheduling
Orchestration
Runs isolated tasks
Coordinates end-to-end business processes
Time-based execution
Event-driven, latency-aware execution
Local system visibility
Cross-platform visibility
Static, assumed dependencies
Dynamic, verified dependencies
Reactive troubleshooting
Centralized operational intelligence
RunMyJobs’ out-of-the-box connectors span SAP S/4HANA, SAP BTP, SAP BDC, SAP Datasphere, SAP Analytics Cloud, SAP Cloud ALM, SAP Build Process Automation, Databricks, Snowflake, AWS and ServiceNow, making cross-platform dependency management possible without custom code.
For RISE with SAP and SAP Cloud ERP environments, RunMyJobs connects through its Secure Gateway and agentless architecture, consistent with how SAP Cloud Connector operates. It’s the only workload automation and orchestration platform included in the RISE with SAP reference architecture. With no agents inside the ERP and no custom ABAP, RunMyJobs supports clean core principles from the start.
Coverage extends across the full range of modern SAP development models: Application Jobs, RAP-based extensions, CAP services on SAP BTP, SAP Datasphere pipelines, SAP Integration Suite workflows and AI-driven scenarios involving Joule.
Job requirements decision tree
Build the control layer before you need it
Most teams introduce enterprise orchestration after complexity has already compounded — after the first SLA breach that took half a day to trace, the planning run that produced results on incomplete data or the migration that left three separate scheduling tools running in parallel with no consolidated view across them.
Getting ahead of that inflection point is considerably easier than resolving it afterward. Teams that introduce RunMyJobs early in their RISE with SAP journey retire legacy schedulers, establish governed dependency management and build a control layer that scales with the architecture from the start.
SAP’s native tools still do what they were designed to do, while orchestration governs what happens between them.
Think about programming a destination into a GPS before the roads to get there are fully built. The route looks clear on screen and the technology is working exactly as designed. But somewhere along the way, the path runs out, and you’re left improvising.
That’s a fair comparison to where many manufacturers are in their efforts to achieve autonomous SAP production planning right now. The destination is well defined: AI-driven production scheduling that anticipates disruptions, adjusts in real time and executes across SAP and connected systems without constant manual intervention. Investments and roadmap conversations are happening. SAP Cloud ERP has the capabilities, and the SAP Production Planning (PP) module continues to evolve.
But according to Redwood Software’s “Manufacturing AI and automation outlook 2026,” roughly 98% of manufacturers are exploring or preparing for AI-driven automation, whereas only about 20% consider themselves fully prepared to execute on it.
The destination is there, but the path hasn’t been cleared. Here’s what’s in the way.
1. Production data is still fragmented across systems
SAP production planning is only as accurate as the inputs feeding it. Demand signals, inventory positions, quality results and MES outputs all need to arrive consistently and on time. In most manufacturing environments, those sources still live in separate systems that weren’t intended to share data automatically.
Around 20% of manufacturers identify a lack of integration across ERP, MES and PLM as a direct bottleneck. That number likely understates the problem, because partial integration — where connections exist but data quality or timing is inconsistent — can be just as limiting as no integration at all. Planning in SAP operates on whatever it can see. When visibility is incomplete, the plan reflects that.
2. Manual exception handling breaks the automation loop
Production rarely runs exactly as planned. Equipment fails, suppliers miss windows and quality deviations surface mid-run. Those disruptions need a response, and right now, for most manufacturers, that response is a person.
Only about 40% of manufacturers have automated exception handling. The other 60% rely on teams to identify, triage and act on disruptions, then manually update the systems involved. That process takes time, creates gaps between what happened and what SAP knows about it and makes closed-loop planning effectively impossible.
If exceptions are the moments that matter most in production, automating around them while leaving the exceptions themselves to manual workflows puts a ceiling on how autonomous your planning can get.
3. Planning cycles are batch-driven, not event-driven
Traditional SAP environments run planning jobs on schedules: nightly MRP runs, periodic capacity updates, batch refreshes of demand data. That made sense when the alternative was manual. It doesn’t make as much sense when production conditions are shifting continuously throughout the day.
A schedule change, a material shortage or a machine coming back online are things that happen in real time. Planning tools that update on a cadence can’t reflect them until the next cycle runs. By then, decisions downstream have already been made on outdated information.
Autonomous planning assumes the system responds to events right when they happen. Getting there requires moving from time-based job scheduling to event-driven orchestration, where a change in one system triggers the right response across all the connected ones, immediately.
4. Forecasting inputs are inconsistent and disconnected
Accurate production planning in SAP starts upstream, with the demand forecasts and signals feeding into it. When those inputs come from disconnected sources, arrive on inconsistent schedules or require manual reconciliation before they’re usable, the planning outputs reflect the same uncertainty.
Roughly 24% of manufacturers cite forecasting accuracy as a major supply chain bottleneck. What’s often behind that number isn’t the forecasting model itself, but the data reaching it. Disconnected demand signals, late updates from commercial systems and cross-functional coordination done via email rather than integrated workflows all degrade forecast reliability before any planning algorithm runs.
You can’t optimize what you can’t trust.
5. Skills and ownership of automation are unclear
Autonomous production planning sits at the intersection of SAP configuration, systems integration, process design and operational knowledge. That’s a lot of ground for any one team to cover, and in practice, it tends to fall awkwardly between IT and operations. It’s not owned by either clearly enough to move fast.
About one-third of manufacturers cite a skills gap in advanced automation technologies as a barrier to progress. This points to organizational structure rather than a lack of talent. When automation initiatives require coordination across multiple teams and knowledge domains, momentum slows. People spend cycles on alignment that could go toward execution. The work that needs to be done is clear; who’s accountable for doing it often isn’t.
This is one of the more underestimated barriers. Technical complexity gets a lot of attention, but organizational complexity doesn’t get enough.
6. Change management feels riskier than the status quo
Production-critical processes carry a particular kind of weight. When something touches the line, the tolerance for disruption is low. That’s a reasonable instinct, and it’s also one of the reasons autonomous planning initiatives stall.
Around 22% of manufacturers cite retraining teams and change management as barriers to adopting new automation approaches. Shifting how planning decisions get made, how exceptions get handled and how workflows are structured touches roles and habits that teams have built over years. Even when the destination is clearly better, the path there feels uncertain.
The organizations making progress have found ways to reduce that perceived risk: starting with contained workflows, building confidence incrementally and showing teams how the changes work before asking them to trust them at scale. Incremental adoption isn’t a compromise. It’s often the only path that actually holds.
7. Perceived integration complexity causes teams to stall
SAP production planning doesn’t operate in isolation. It touches finance, procurement, warehouse management, quality systems and shop floor execution. Making planning more autonomous means those connections need to work reliably, not just for the data going into SAP but for the actions coming out of it.
About 24% of manufacturers cite system integration concerns as a primary barrier to automation progress. That’s not surprising when you consider what the integration surface generally looks like, with multiple SAP modules, third-party platforms, cloud environments and on-premises systems, all of which need to stay in sync as planning decisions cascade through them.
The perceived complexity here often leads to underinvestment. Teams assume the integration work will be costly and disruptive, so they defer it. What they’re deferring is the connective tissue that autonomous planning depends on.
Autonomous planning is closer than it seems
These seven challenges share a common thread. None of them is about SAP being insufficient. And none of them is about AI not being ready. They’re about the data pipelines, production processes and connections — the roads — not yet being ready to support autonomous operations end to end.
Organizations that have worked through these gaps by connecting data sources, automating exception responses, replacing scheduled MRP run cycles with event-driven triggers and clarifying ownership of automation are already seeing measurably better resource utilization and operating at higher levels of automation maturity. When infrastructure catches up to ambition, autonomous production planning stops being a future goal and starts being next quarter’s project.
RunMyJobs by Redwood has been providing this kind of deterministic orchestration infrastructure for manufacturers for years — the event-driven workflows, cross-system coordination and purpose-built SAP integrations that make autonomous planning operationally possible. Think of it as the paving crew that’s already been at work: many Redwood customers are already running production environments where planning responds to real conditions rather than scheduled cycles. The roads to autonomous operations are more built out than most teams realize.
The “Manufacturing AI and automation outlook 2026” examines where manufacturers stand across all of these dimensions: where the gaps are, what separates early adopters from those still in early stages and what the path forward looks like for organizations at different points in the journey.
Download the report to see how other manufacturers are approaching the shift to autonomous, AI-driven operations.
