SAP IBP and the hidden dependency behind every reliable plan

Article

I’ve sat in enough SAP Integrated Business Planning (IBP) rollout conversations to notice a pattern: almost everyone talks about the planning model, and almost no one talks about what feeds it. That may be fine, until a forecast comes back looking wrong and nobody knows why.

SAP IBP has earned a strong position with SAP customers for good reason. It brings demand planning, inventory optimization, response and supply planning and sales and operations planning into a cloud platform built for modern supply chain volatility. Customer feedback reflects that momentum. SAP recently highlighted SAP IBP’s top customer choice status across major software review platforms. For many SAP-centric enterprises, SAP IBP is becoming the supply chain planning system where teams make decisions they can’t afford to get wrong.

But SAP IBP doesn’t create reliable plans from the platform alone. It depends on accurate, timely data arriving in the right sequence. 

Only as strong as your weakest handoff

A demand planning run is only useful if the master data behind it is current. A replenishment recommendation is only reliable if the latest inventory levels, sales activity and supplier performance data made it into the planning model. And a demand forecasting simulation only helps if the upstream data movement completed before the simulation started.

When a planning result in SAP IBP looks off, the problem may have started somewhere else entirely — in SAP S/4HANA, SAP Cloud Integration for data services, a warehouse system, a supplier feed or a non-SAP application that missed its window. Modern supply chain planning depends less on whether individual systems can execute and more on whether their dependencies stay aligned.

That sounds obvious, but it’s exactly where many supply chain planning processes become fragile. Teams tend to focus on the planning application because that’s where the business outcome appears. But the data movement, dependency handling and monitoring supporting it often receive less attention.

In production planning, every delay matters, and the underlying cause is the same whether the trigger is SAP IBP or the shop-floor data pipelines feeding SAP production planning. A late data load can translate directly into excess inventory, the wrong replenishment signal or a planning cycle that finishes after operations needed to act. For supply chain planners, the cost is a missed window to respond to something that would’ve been fixable an hour earlier.

The gold-standard engine behind SAP IBP forecasts

SAP IBP is designed to support sales and operations planning (S&OP), demand forecasting, inventory optimization, response planning and supply planning in a single cloud-based environment. It helps supply chain planners sense demand variability, run scenario planning and align operational plans with financial planning expectations. SAP IBP uses machine learning and predictive analytics to power this, running what-if simulations and flagging disruptions before they compound. To do any of that well, SAP IBP needs high-quality time-series and master data from across the enterprise.

SAP Cloud Integration for data services (SAP CI-DS) is the required engine for that data movement. It connects on-premises systems, cloud applications and SAP IBP across a hybrid IT landscape, so planning processes work from current data rather than yesterday’s snapshot. In many cases, SAP CI-DS is the operational bridge between where supply chain data lives and where planning decisions are made.

When SAP CI-DS tasks run cleanly, the process looks uneventful. Data arrives, planning templates execute, reports refresh and business users get what they expect.

When something goes wrong, the symptoms usually surface later and somewhere else, as a forecast that looks inconsistent because a data load only partially completed or a planning simulation that starts before the required master data is available. The individual task failure often isn’t the whole story. 

This isn’t unique to SAP IBP. Recent Redwood Software research found that 8 in 10 manufacturers have automated less than half of their critical data transfers, and more than a quarter still move sensitive documents by hand. Whatever the planning system, the pattern holds: missed or incomplete data movement affects inventory management, procurement, distribution planning and production schedules downstream. If the plan overstates demand, then safety stock, carrying costs and holding costs rise. If it understates demand, stockouts, lead times and customer satisfaction become the problem. Either way, supply chain performance suffers because the system acted on incomplete or late data.

Success in each system ≠ success across the chain

SAP IBP and SAP CI-DS both execute their own work well within their own boundaries. For isolated tasks, native scheduling may be enough. The limit shows up when those tasks become links in a larger supply chain planning process:

A green status in each tool doesn’t necessarily add up to a trustworthy plan. If one step runs late, partially completes or advances before the required data is ready, the result can still look successful while reflecting the wrong business state. That’s a hard failure mode to catch.

Orchestration is what turns a set of completed tasks into a reliable process. Instead of trusting the clock or a local success message, a modern orchestration platform waits for proof that the process is ready to move forward.

How RunMyJobs supports SAP supply chain planning

SAP IBP and SAP CI-DS are immensely powerful on their own. RunMyJobs by Redwood extracts their full potential by connecting them to the wider enterprise workflows they support. With out-of-the-box connectors for both, you can coordinate planning templates, data movement tasks, monitoring, retries and downstream processes from a central control plane. RunMyJobs’ role as a control plane isn’t limited to SAP; it extends the same coordination to cloud applications, legacy tools and everything else in your landscape, giving your team one place to watch the whole chain instead of piecing it together across systems.

That visibility works best when it’s continuous rather than periodic. RunMyJobs monitors execution in real time and flags SLA risk before a deadline is missed, so a delayed data load or a bottleneck surfaces while there’s still time to act on it, not after a planning cycle has already run on incomplete data.  

• For SAP IBP, RunMyJobs can retrieve available job scheduling templates, import templates as single jobs or step-by-step chains and submit SAP IBP jobs as part of larger workflows 
• For SAP CI-DS, RunMyJobs can import existing tasks, execute them, track status through completion or termination and retrieve execution status and logs for centralized monitoring

The planning chain moves because the previous step finished, not because the schedule assumes it should have. That’s especially useful when supply chain planning has to respond to real-time data during demand spikes, supplier delays, inventory exceptions and production capacity constraints. RunMyJobs can trigger the right planning workflow when the business event occurs, stop the process if a dependency fails and alert teams before a late-running cycle affects replenishment or production schedules.

Treat the pipeline as part of the plan

SAP IBP gives supply chain teams a strong foundation for modern planning. SAP CI-DS provides the required data movement into SAP IBP. Together, they’re central to many SAP supply chain architectures. But the process around them still needs orchestration.

If SAP CI-DS data loads, SAP IBP planning templates, ERP jobs, analytics refreshes and downstream exception workflows are scheduled separately, the planning chain depends on assumptions. If they’re orchestrated together, each step runs based on verified completion and business context.

That’s the difference between a supply chain planning process that usually works and one you can depend on when volatility increases.

Explore the full set of SAP connectors for RunMyJobs, including SAP IBP and SAP Cloud Integration for data services. Or get a demo to see how Redwood can help you orchestrate end-to-end supply chain planning across your SAP and non-SAP landscape.

The AWS workloads RunMyJobs doesn’t know about yet

Article

I’ve spent nearly three decades working with Redwood Software customers on the jobs, schedulers, scripts and workflows that run large enterprises. What used to be scheduler environments are now hybrid automation estates spanning cloud services, enterprise applications, data platforms and on-premises systems. No two look the same, but the pattern is familiar.

If you already trust RunMyJobs by Redwood with your mission-critical work, you have a foundation many teams are still trying to build. Maybe RunMyJobs runs your SAP processes. Maybe it coordinates your finance workflows, overnight dependencies or reporting chains. Whatever the mix, your most important work already runs through a reliable, governed orchestration layer. The opportunity before you now is to extend that model to the workflows still operating outside it.

In many estates I see, AWS workloads arrive through a different path. For example, a Lambda function solves a specific problem. An AWS Glue job becomes part of a data pipeline. An Amazon S3 bucket turns into a handoff point. A Step Functions workflow grows from a team-level solution into part of a larger business process. Nobody plans these parallel automation models on a whiteboard. They accumulate as practical answers to real needs. 

Those AWS services belong in your estate, but the question is whether they should still be operating outside the orchestration model you already trust.

The edges of your coverage

When I talk with customers about AWS, I usually start with a simple exercise: draw the edge of your current RunMyJobs coverage. Not the whole architecture, nor every service inventory — and not the ideal future state. Just the practical boundary between the workflows RunMyJobs already governs and the ones that still operate elsewhere.

That boundary is revealing.

On one side, you have the processes that already inherit the RunMyJobs operating model: dependency logic, calendars, role-based access, approvals, audit history and service-level visibility. On the other side are the workflows that have grown up around AWS, data platforms or SaaS applications on their own timelines. They’re usually perfectly reasonable workflows, but they’re running on a fixed schedule, polling script, local trigger or point integration. Hence, orchestration sprawl happens unintentionally.

I see this most often around processes that cross boundaries: AWS into SAP, AWS into an on-premises application, AWS into a data platform, etc. Each environment has its own logs and controls, but the business process doesn’t stop to respect those boundaries. Hidden risk lives right there.

The next best candidate for moving to RunMyJobs is the workflow that works most days, until it doesn’t.

What’s running on trust?

Look first for workflows that still depend on:

• Fixed schedules that assume upstream work finished on time
• Polling scripts that check whether a file, job or message is ready
• Manual handoffs between AWS and non-AWS systems
• Data pipelines where every technical step can succeed, while the business result is late or stale

Those are examples of the AWS workloads RunMyJobs may not know about yet. Some may look small, but if they connect to a business process, they carry operational weight. If they still rely on informal coordination, they carry costs, too.

A bill nobody can quite explain

The cost conversation often starts in AWS, with an instance running longer than expected, a development environment staying up or a batch host waiting most of the day for a few hours of work. FinOps teams can usually identify those patterns. The harder question is what depends on them. No one wants to stop the instance that might still be holding up month-end close or retire the polling script no one fully owns.

That’s why cost optimization is often blocked by uncertainty, not lack of visibility into the bill. When more AWS and hybrid workflows are managed through RunMyJobs, you can see how work starts, waits, runs and completes across the full process. That turns cost from something your team can explain into something your team can act on.

2 versions of the same workflow

AWS-native services are strong building blocks. Step Functions, EventBridge, Lambda, Glue, Managed Workflows for Apache Airflow (MWAA) and other AWS services help teams build scalable, event-driven processes inside AWS. They should keep doing that work.

But what happens when the business process crosses the AWS boundary?

Curious whether a specific AWS service is already covered? See the full list of AWS connectors RunMyJobs supports today.  

The part AI can’t do for you

I get asked about AI in this context more often now: “We’re already putting AI agents on this, so does it matter that some of it still runs outside RunMyJobs?” My answer goes something like: an agent deciding what should happen is not the same as the work safely getting done.

An agent may recommend restarting a failed step, refreshing a data pipeline, triggering a reforecast or escalating an approval. But that action still has to move through the same governed, auditable business processes you already operate. If a workflow sits outside RunMyJobs today, AI doesn’t make it safer by touching it. The handoff still needs ownership, access control, dependency context and an audit trail.

So, coverage matters here too. With capabilities like Model Context Protocol (MCP) support, RunMyJobs can expose existing workflows to AI agents through governed access, rather than giving agents raw access to production systems. Your production workflows remain controlled, governed and scoped to the same permissions and process logic you already trust.

Bridging the decades: 50 years of enterprise technology, one orchestration layer and costs you can finally act on

Article

Somewhere in your IT estate tonight, a workload will run that is older than some of the engineers maintaining it. It may close the books, move inventory, trigger replenishment, process settlements or feed a dashboard before the business day starts. It’s survived multiple technology waves because it works. It does what the business needs it to do.

Somewhere else, maybe in the same chain, an AWS Lambda function will fire, or an Azure Data Factory job will transform data. A container task will run. A data platform will load the result into a report that someone depends on tomorrow morning.

Nothing about that combination is unusual anymore. The systems that have carried your business for years now run alongside cloud services built for a different era of speed and scale. Neither is inherently fragile, but the connections between them often become costly points of failure as integration and workflow complexity grow. 

No one gets to modernize in a vacuum

Your modernization program is already changing the shape of the business. Applications and workloads are moving to the cloud. SaaS platforms are expanding across functions. Data pipelines are being rebuilt for speed, scale and AI readiness. But modernization doesn’t arrive as a clean cutover. You prioritize the areas with the clearest business value first, while the systems that already run the business keep running.

That is what makes hybrid cloud environments difficult. You’re not replacing one world with another. You’re running decades of technology at the same time across cloud services, enterprise applications, data platforms, on-premises infrastructure and private cloud environments. Every new wave has to connect to what came before it. 

Ask anyone who has run a postmortem on a cross-environment failure, and they’ll recognize the typical way this shows up: a legacy batch process completed, an AWS service did what it was supposed to do and both teams have logs that prove their side behaved correctly. Yet, the business process still broke. All the evidence stops at the edge of each system.

That also means the failure lives in a place that doesn’t cleanly belong to anyone. The script holding together the on-prem side and the cloud side may have been written three years ago and never put under version control. It’s both load-bearing and invisible.

Over time, taking the shortest path available on any given day allows your hybrid estate to grow both systems and handoffs simultaneously. You already know what this costs because you’ve probably lived the 2 AM version, when someone is trying to remember who knows what a particular script was supposed to do.

“The job ran” and “the business got what it needed” have never been the same claim, but tooling fragmentation forced you to treat them as if they were. Cloud migration may change where the work runs, but it doesn’t automatically change how it’s coordinated.

The economics of old habits

Cloud changed the cost model faster than most operating models could follow.

In the data center, a lot of habits were rational. Fixed schedules gave you predictability, and extra capacity reduced risk. A server left running overnight didn’t create a new hourly charge, and polling every five minutes was cheap enough to ignore. Move those same patterns into a metered cloud environment, and you’re paying for 20 hours of polling rather than the four hours of true work. For readiness rather than action.

That isn’t getting better on its own. Flexera found that wasted cloud spend rose to 29% in 2026, the first increase in five years. That tracks with the arrival of AI workloads, according to the study.

But cloud cost conversations often get stuck. FinOps can point to all the candidates for waste, and the list is rarely a surprise:

• Instances that run long after the workload ends
• Environments sized for old peak assumptions
• File watchers and polling jobs that could be event-driven
• Scripts that exist only to bridge one system to another
• Batch hosts no one wants to shut down 

The hardest part is proving what happens if you change any of them. You can’t safely stop an instance, retire a script or replace a polling loop if you don’t know which business processes depend on it.

In one recent conversation I had with a senior engineer at a large enterprise assembled through several acquisitions, they described it like this: “Jenkins here, Cron there, an Azure Automation instance nobody fully owns, SAP schedulers running in parallel, Step Functions and Airflow layered in as our data pipelines grew. Each tool has its own team, its own visibility and its own blind spot at the edge. Rather than creating a new version of this problem, AI is raising the cost of the one that’s already there.”

The way out is not simply to squeeze every workload harder. It’s to change how work starts, waits and stops, and that means solving orchestration tooling sprawl instead of compressing individual runtimes.

Not just another migration

The pain usually shows up when you realize you have many places to schedule work, but no single place to understand the full process. Your instinct could be to just migrate again. Move to a new tool, consolidate, rehost, standardize. And those steps could be necessary, but another migration won’t automatically rebuild the connective layer between systems. If your measure of success is whether every job runs the same way somewhere else, you may have improved the platform while preserving the operating model that created the problem.

Better questions are outcome-based:

• Which polling loops can you retire?
• Which always-on hosts can start and stop around real workload demand?
• Which manual handoffs can become governed workflows?
• Which scripts can be replaced instead of recreated?
• Which failures can now surface before the business notices?
• Which business processes can be monitored end to end, not system by system?

A modern orchestration layer doesn’t ask cloud services, enterprise applications, data platforms and on-premises systems to behave as if they were one technology stack. It gives you one place to coordinate the work between them. The older process can stay. The newer cloud service can stay. But the handoff becomes visible, governed and auditable, with role-based access for who can touch it, an immutable trail of what ran and why and an SLA that predicts a chain trending late while there’s still time to act on it.

That matters now for cost and reliability. And it will matter even more as AI continues to move from pilots to everyday use.

Agents decide, but something else has to execute

The line between cloud modernization and AI readiness is getting thinner and thinner. Most enterprises aren’t building models from scratch. They’re layering agents onto cloud services, managed models and AI-enabled applications and asking those agents to do more than answer questions. Increasingly, they need to trigger workflows, remediate failures and escalate approvals.

But an agent that decides isn’t the same thing as work that gets done. A recommendation to release an order, correct a billing run or kick off a fulfillment path still has to travel through the same deterministic, auditable execution layer as everything else in your hybrid estate. 

That’s the part almost nobody has built well, and it’s the same problem as the cost story above, not a separate one. If a handoff is invisible to IT Ops today, it doesn’t become safe or governed just because an AI agent is the one initiating it. The value doesn’t come from the AI alone, but from the blend of judgment and execution and the space between them is where the real work is.

Make decades of tech governable

As you know, forcing every new service into one architectural pattern simply won’t work. The systems running your business have earned their place, and the newer services you’re adopting are there for good reasons: speed, scale, elasticity, AI readiness. You can’t operate in such complexity on trust alone.

Cost is often the first place this becomes visible. Handoffs that were once absorbed as operational noise now show up as workloads you can’t safely optimize, instances you can’t confidently stop, scripts you can’t retire and business processes whose true cost you can’t explain. The more your hybrid estate grows, the more expensive those unknowns become. 

More running in the cloud doesn’t mean more modern. What truly supports modernization in the long run is having a modern application and data workflow orchestration platform. It must deliver a governed operating model for each new service, pipeline or AI-enabled workflow to inherit — the same role-based access, audit trail and SLA visibility, applied consistently instead of rebuilt per tool.

Redwood brings old and new together under one orchestration layer. See how you could be managing hybrid cloud workflows across cloud services, enterprise applications, data platforms and on-prem systems with end-to-end visibility and control.