Case Study: Automating Social Media Content Creation with ChatGPT 4.0

Legacy vs. modern financial services automation platforms: Building a foundation for AI-readiness and modernization

Article

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.

Tool sprawl makes the cost visible. Redwood’s research found that 54.8% of financial institutions operate across five or more automation environments. Another 52.8% report high maintenance costs for scripts and legacy tools. Those numbers explain why modernization has become a business issue, not only an IT concern.

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.

That friction shows up when 65.1% of financial institutions say legacy automation platforms limit their ability to modernize.

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

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.

Download “State of AI and data pipeline automation in financial services 2026” to see where financial institutions stand today and what it takes to move from automated processes to AI-ready orchestration.

Green status, wrong data: The pipeline monitoring gap IT Ops needs to close

Article

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.”

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.

This is where most IT Ops leaders get trapped. You’re optimizing for faster reaction when the real leverage is in eliminating the category of failure entirely. The absence in most hybrid environments isn’t signal, but scope. 

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. 

See how RunMyJobs connects hybrid data pipelines into a single governed execution layer.

Scheduling in modern SAP landscapes: SAP BTP Job Scheduling Service, Application Jobs and when to orchestrate 

Article

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.

1. 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.
2. 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.
3. 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

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.

Get a demo of RunMyJobs, and explore its full range of SAP connectors to see how enterprise orchestration extends across SAP S/4HANA, SAP BTP, SAP BDC and your broader cloud landscape. 

7 reasons autonomous SAP production planning feels out of reach — and why it isn’t

Article

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.