DEV Community: 2iSolutions US

Brownfield, Greenfield or Selective: AI Environment Assessment

2iSolutions US — Mon, 09 Nov 2026 19:58:48 +0000

Why the Migration Path Is the Decision That Matters Most
Your migration path is the first big decision in an S/4HANA program, and it costs the most to reverse. Teams often choose a path early, sometimes in a steering committee meeting with only half the facts on the table. Then, six months later, a custom code problem or a hidden interface dependency exposes the mistake. By that point, budgets are committed, timelines are public and reversing course is painful.

The alternative is to replace the early guess with evidence. With SAP AI Solutions, you can generate a scored inventory, a dependency map and effort figures for every object in your landscape before anyone commits to a direction. An AI landscape assessment grounds the choice in measurable findings instead of opinion.

2iSolutions US has delivered SAP work since 2005, and the pattern repeats from one program to the next: the path decision holds up when evidence drives it. This article explains what an AI landscape assessment delivers, how the three migration paths differ, and how the findings translate into a decision your steering committee can challenge and approve with confidence.

What Does an AI Landscape Assessment Actually Deliver?
An AI landscape assessment scans your SAP system and produces a scored inventory of custom objects, a readiness rating, a dependency map, effort and cost per object, and a recommended migration path. In short, it turns an opinion about your system into measurable findings.

First, a definition. An SAP landscape is the full set of systems, custom code, interfaces, data stores and integrations that your business processes run on. The assessment reads that landscape automatically, so analysts stop sampling and start measuring. Instead of reviewing a handful of programs and extrapolating, you see the whole picture.

Here is what you receive at the end of the assessment:

A scored inventory of custom objects, with each item rated for usage and risk.
A readiness rating with named blockers, not a vague green, amber or red.
Effort and cost per object, so the budget has a source.
A dependency map that shows which objects, interfaces and tables rely on each other.
A recommended path: brownfield, greenfield or selective.
Each of these outputs answers a question that steering committees usually argue about without data. How much custom code do we really have? Which parts of it are still in use? What will it cost to carry forward? What breaks if we move one piece but not another?

Why per-object detail matters
A project-level estimate hides the problem. A single heavily modified pricing routine can cost more than two hundred small reports combined. Because the assessment prices objects individually, you see exactly where the money goes, and you can decide which objects deserve the investment.

Per-object scoring also changes the conversation with the business. Instead of arguing about whether custom code is "a lot," you can point to the specific objects that block the path. The discussion stays on facts, and stakeholders who might otherwise defend their favorite customizations can see the cost attached to each one.

What the output looks like in practice
Picture a manufacturer that has been running ECC for fifteen years. The scan lists every custom program, flags the ones nobody has run in two years, and ties the rest to the interfaces they feed. The report might show that a third of the custom code is dead weight. That finding alone changes the effort figure for every path, because code that nobody uses does not need to be converted, tested or rebuilt.

How Do Brownfield, Greenfield and Selective Paths Differ?
Brownfield converts your existing system to S/4HANA and keeps your history and configuration. Greenfield builds a new system from scratch and migrates only chosen data. Selective, sometimes called hybrid, moves specific company codes, modules or data sets while leaving the rest. Each path suits a different system condition.

Brownfield is a system conversion that carries your current processes, custom code and data into S/4HANA. It is the fastest route when the system is clean. However, it also carries every flaw forward, so a decade of workarounds comes with you.

Greenfield is a new rollout that starts from a clean S/4HANA system. You redesign processes and load only the data you choose. The price is higher effort, longer timelines and heavier change management. In return, you leave accumulated process debt behind.

Selective migration sits between the two. For example, you might convert one business unit and rebuild another, or move a subset of historical data. It gives you control, but it demands precise knowledge of how your objects connect. Without a dependency map, selective migration is where hidden interfaces cause the most damage.

Where each path usually fits
Brownfield suits organizations with stable processes and modest custom code. Greenfield suits companies that want to retire years of process debt or merge several ECC instances. Selective suits groups with mixed conditions, such as a healthy finance core and a tangled logistics layer.

Those are tendencies, not rules. Plenty of firms assumed they were brownfield candidates, then found their custom code or interfaces told a different story. That gap between assumption and reality is exactly what the assessment is designed to close.

How the Assessment Findings Point to a Path
The value of the assessment is that each finding maps to a path decision. You are no longer asking which path sounds right. You are reading what your own system says about which path it can support.

Consider how common findings influence the recommendation:

Low custom code volume and a clean readiness rating point toward brownfield, because there is little to carry forward that could hurt you.
Heavy modification, many unused objects and named blockers point toward greenfield, because converting that code would carry debt into the new system.
Uneven readiness across modules or company codes point toward selective, because some areas are ready to convert while others are not.
A dense dependency map signals risk for any path that splits the system, so selective plans need extra care.
Because effort and cost are priced per object, you can also compare the paths on money, not just on principle. A greenfield rebuild may look expensive until you see how much a brownfield conversion would spend on objects that should never have been migrated. Likewise, a brownfield path may look cheap until the assessment names the handful of blockers that will consume most of the budget.

Connecting the Assessment to Your Target Platform
The path decision does not stand alone. It sits inside a broader architecture choice about where your processes will run and how they will connect. Many organizations are weighing a move toward SAP S/4HANA Cloud, and the assessment helps here too. Custom objects that depend on tightly coupled modifications are harder to carry into a cloud model, so the per-object scoring shows early which items will need rework or replacement.

The same applies to extensibility. Rather than keeping heavy modifications inside the core, many teams plan to rebuild differentiating logic on SAP BTP. The assessment helps you decide which custom objects are worth rebuilding that way and which can simply be retired. Objects with no usage in two years are the obvious candidates for retirement, and removing them early shrinks both the effort and the risk.

Interfaces deserve the same attention. A dependency map that links each custom program to the interfaces it feeds gives you a realistic view of integration work. That is where SAP AI Integration becomes practical: the scan reads connections automatically, so integration effort is estimated from the actual landscape instead of from interviews and memory.

How to Use the Assessment in a Steering Committee
An assessment only helps if it changes how decisions get made. The goal is a steering committee that can challenge the findings and approve a path with open eyes, rather than ratifying a preference that someone arrived with.

A practical approach looks like this:

Run the scan across the full landscape before any path is discussed, so no one anchors on an early opinion.
Review the readiness rating and the named blockers first, since they set the boundaries for what is realistic.
Walk through the per-object effort and cost figures, focusing on the few objects that drive most of the spend.
Use the dependency map to test each path, asking what breaks if a given object or interface moves, stays or is retired.
Compare the recommended path against your business goals, and document why you accept or override it.
This sequence keeps the debate grounded. When someone argues that custom code is manageable, the inventory answers. When someone insists on a full rebuild, the cost per object shows whether that spending is justified. The recommendation becomes a starting point for discussion rather than a verdict, and the committee retains ownership of the final call.

It also protects the program later. If a surprise appears six months in, you can trace it back to a documented decision and a known finding. That makes it easier to adjust scope calmly, instead of reopening the entire path debate under pressure.

Common Mistakes the Assessment Helps You Avoid
Several mistakes recur when teams pick a path without evidence, and an AI landscape assessment addresses each one directly.

The first is assuming the system is cleaner than it is. A decade of workarounds hides in custom code that few people remember writing. Scoring every object for usage and risk brings those workarounds into view.

The second is estimating at the project level. A single large number conceals the pricing routine, or the handful of heavily modified objects, that will dominate the effort. Per-object costing exposes them before the budget is fixed.

The third is overlooking dependencies. A report that looks harmless may feed an interface that a downstream process relies on. The dependency map shows these links, so selective moves do not break something no one knew existed.

The fourth is carrying dead weight forward. If a third of your custom code has not run in two years, converting it wastes time and money. Finding it early shrinks the scope of every path at once.

Each of these mistakes is cheap to prevent at the start and expensive to fix midway. That asymmetry is the strongest argument for assessing before deciding.

FAQ
Q: What does an AI landscape assessment produce?

It produces a scored inventory of custom objects, a readiness rating with named blockers, a dependency map, effort and cost per object, and a recommended migration path of brownfield, greenfield or selective.

Q: Why is per-object pricing better than a project-level estimate?

A project-level estimate hides where the money goes. A single heavily modified pricing routine can cost more than two hundred small reports combined, so pricing objects individually shows exactly which items drive the budget and which can be retired.

Q: Can I still choose a path other than the one recommended?

Yes. The recommendation is a starting point for your steering committee, which can challenge the findings and approve a different path. The advantage is that the decision is made against measurable evidence rather than assumption.

Conclusion
The migration path is the costliest decision to reverse in an S/4HANA program, and an AI landscape assessment replaces early guesses with a scored inventory, a dependency map and effort figures for every object. By reading what your own system says, your team can choose brownfield, greenfield or selective with confidence. As experience since 2005 shows, the path decision holds up when evidence drives it. To explore more, visit 2iSolutions US.

Ready to base your migration path on evidence instead of assumptions? Our certified experts are here to help you assess your landscape and plan your next step. Contact us at info@2isolutionsus.com to get started today.

Rank by Runtime Times Frequency: Find Your Top SAP Fixes

2iSolutions US — Thu, 05 Nov 2026 18:38:41 +0000

The Slow Report Is Rarely the Real Problem
Fixing what feels slow is not the same as fixing what costs the most. A report that takes four minutes once a month annoys one finance manager. A 300-millisecond lookup that fires two million times a day quietly eats your database. Teams chase the first and ignore the second.

This habit is common, and it is expensive. Users complain about the dramatic waits they can see, so those waits land at the top of the backlog. Meanwhile the real drain runs untouched in the background, because no single call looks slow enough to notice. Measurement-led SAP HANA Performance Optimization flips that habit, and 2isolutions US, an SAP partner delivering since 2005, builds its method around the flip.

The idea is simple to state. Stop asking which programs feel slow. Start asking which programs cost the most in total. Those are different lists, and only one of them tells you where to spend your effort.

What Does Ranking by Runtime Times Frequency Actually Mean?
Ranking by runtime times frequency means multiplying how long a piece of code takes by how often it runs, then sorting the results from highest to lowest total cost. The top of that list shows where your system spends its time. Everything below it matters far less.

The concept sounds obvious, yet most teams never apply it. Instead, they fix whatever users complain about loudest, or whatever a developer remembers being slow. Neither approach reflects what the database actually experiences.

Consider two examples. A custom report runs for 240 seconds and executes twice a week. Its weekly cost is 480 seconds. A small pricing routine runs for half a second but fires 800,000 times a day. Its daily cost is 400,000 seconds. The routine costs far more, yet nobody complains about it because each call feels instant.

That gap explains why user complaints make a poor priority list. Users notice latency. They don't notice load. Your database notices only load.

Why Perception Misleads
Human attention locks onto the single long wait. Aggregate cost stays invisible without tooling. As a result, teams spend weeks tuning dramatic but rare slowdowns while the real drain keeps running in the background. The four-minute report gets a project plan. The half-second routine gets nothing, even though it consumes thousands of times more resource.

Fixing this does not require a new philosophy. It requires numbers that capture both dimensions at once: how long each call takes and how many calls happen. Once you have both, the ranking almost builds itself.

Why Does the First Week of Measurement Deliver the Biggest Gain?
The first week delivers the largest gain because cost is never spread evenly across your code. A small group of objects usually accounts for most of the total runtime. Measurement finds that group fast, so early fixes remove the biggest burden before effort starts to taper off.

Think of it as a steep curve. The first few items on a ranked list carry enormous weight. By the thirtieth item, you are polishing code that barely registers in your workload traces.

This is the core argument behind the approach. You don't need months of analysis to find the heavy hitters. A focused week of measurement, ranked correctly, points to the changes that move the numbers.

Teams that skip measurement often work the other way around. They start with a long wish list, assign it by seniority or noise, and burn the first month on low-yield items. Then the budget thins out right when the real problems surface. The order of work matters as much as the quality of the work.

Here is what a measured first week usually produces:

A ranked list of the most expensive programs, functions and SQL statements
Clear evidence of which anti-patterns drive that cost
A baseline runtime for every candidate fix
A defensible order of work that finance and IT leaders can both read
That baseline matters most. Without it, you cannot prove any later improvement. A claim that something feels faster carries little weight in a budget meeting. A recorded before-and-after runtime carries a lot.

How Does the Five-Step Method Work in Practice?
The method has five steps: Measure, Analyse, Rank by runtime times frequency, Rewrite with HANA pushdown, and Prove with row-by-row parity and before and after runtimes. An architect reviews every change before it moves to transport. Each step feeds the next, so nothing gets rewritten without evidence.

Here is the sequence in order:

Measure. Capture real runtimes and call counts from your production-like workload, not from a developer's test run.
Analyse. Trace the expensive objects to the exact statements and loops that cause the cost.
Rank by runtime times frequency. Sort every candidate by total cost, not by how slow it feels.
Rewrite with HANA pushdown. Move the heavy logic into the database, where it runs on the engine built for it.
Prove. Compare output row by row against the original, then record before and after runtimes.
The discipline in this sequence is what separates it from ad hoc tuning. Nothing gets rewritten until measurement says it should. Nothing ships until the output matches the original row for row. And an architect signs off before any change moves to transport.

That last point deserves attention. Performance work carries a risk that is easy to underestimate: a faster program that returns slightly different results is worse than a slow one. Row-by-row parity removes that risk. It gives business owners confidence that the numbers they rely on have not shifted, even though the code underneath has changed completely.

Where Does AI Fit Into This Picture?
Ranking is a data problem, and data problems suit automation. Collecting runtimes and call counts across thousands of objects, tracing them to statements, and sorting by total cost is tedious work for a human team. It is exactly the kind of work that SAP AI Solutions can accelerate, because the inputs are structured and the goal is clear.

The pattern works best when AI handles the heavy lifting of finding and ranking candidates, while experienced architects handle judgment. That division keeps speed high without giving up accountability. The machine surfaces the highest-impact items. The people decide how to rewrite them and confirm that the results hold up.

This is also where SAP AI Integration becomes practical rather than theoretical. Embedding measurement and ranking into the way your team already works means the list of top fixes stays current instead of going stale after a one-off review. Workloads change. New custom code gets added. A ranking that was accurate last quarter may miss the new heavy hitter this quarter.

Looking further ahead, Agentic Ai SAP approaches point toward systems that do more than report. They can propose candidate fixes, run comparisons and prepare evidence for human review. The principle stays the same either way: evidence first, change second, proof last. Automation speeds up the evidence. It does not replace the review.

What Should You Do Differently Starting Now?
You do not need a large program to benefit from this thinking. A few changes in habit make a real difference, even before any tooling arrives.

Stop treating user complaints as your priority list. Treat them as one input among several.
Ask for call counts alongside runtimes. A runtime without a frequency tells you very little.
Record a baseline before touching anything, so every improvement can be proven.
Insist on parity checks for every rewrite, so speed never comes at the cost of correctness.
Work the ranked list from the top, and resist the pull of the long wish list.
These habits cost little to adopt. They also change the conversation between IT and finance. Instead of debating which complaint is most urgent, both sides can read the same ranked list and agree on the order of work. A defensible order reduces friction, and it protects the budget for the items that matter most.

FAQ
Q: What does ranking by runtime times frequency mean?

It means multiplying how long a piece of code takes by how often it runs, then sorting by total cost from highest to lowest. The top of the list shows where your system really spends its time, which is often different from what users complain about.

Q: Why is the first week of measurement so valuable?

Cost is rarely spread evenly. A small group of objects usually accounts for most of the total runtime, and a focused week of measurement finds that group quickly. It also produces a baseline runtime for every candidate fix, which lets you prove later improvements.

Q: How do you make sure a rewrite does not change business results?

The final step of the method is to prove the change. Output is compared row by row against the original, and before and after runtimes are recorded. An architect also reviews every change before it moves to transport.

Conclusion
Fixing what feels slow is not the same as fixing what costs the most, and ranking by runtime times frequency is how you tell the two apart. A measured first week, a five-step method and row-by-row proof turn tuning from guesswork into a defensible plan. Put evidence ahead of opinion, and your highest-impact fixes rise to the top on their own.

Ready to find the fixes that actually move your SAP numbers? Our experts are here to help you measure, rank and prove every improvement. Contact us at info@2isolutionsus.com to get started today.

How AI Automated Testing for SAP Differs From Script Libraries

2iSolutions US — Tue, 03 Nov 2026 18:08:36 +0000

When a Passing Regression Suite Still Breaks Month-End Close
Your regression suite passed, and the release still broke month-end close. QA leads see this more often than most will admit, and it usually traces back to one cause: the script library tested what someone remembered to script. Coverage that depends on human memory will always have gaps, and those gaps tend to sit in the exact places where business processes get complicated.

AI automated testing for SAP starts from a different place. It reads your code and your processes, then builds coverage from what the system actually does. SAP AI Solutions now support much of this analysis, and 2iSolutions US has delivered SAP work since 2005. In that time, the same five steps have kept proving themselves: Map, Generate, Weight, Run, Maintain.

This article walks through each stage, explains how AI-built suites differ from hand-written catalogues, and shows where consultant judgment still matters most.

What Makes AI-Built Tests Different From Script Libraries?
AI-built tests come from analysis of your live code and business processes, not from a hand-written catalogue. A script library records what testers thought to check. An AI-built suite derives coverage from what the system contains, including exception paths that manual scripting often skips.

Script libraries age badly. Someone writes 400 scripts during a project, the team celebrates, and then the first transport changes a screen field. Half the scripts fail for reasons unrelated to quality. Testers spend the next sprint repairing scripts instead of finding defects. The library becomes a maintenance burden rather than a safety net.

AI-built suites flip that economy. Coverage comes from analysis, so it reflects the current system. When the system changes, the suite regenerates the affected tests. Nobody maintains a spreadsheet of test cases that drifted out of date six months ago.

The brief for every engagement is the same. Four deliverables come out of the process:

Coverage built from code and process, including exception paths
A self-maintaining suite
Before-and-after parity evidence
Risk-weighted results
Each deliverable maps to a pain point that script libraries create. Gaps in coverage, constant repair work, unclear proof that a change behaved correctly, and results that treat every failure as equally urgent are all symptoms of the same underlying approach.

Step One: Map the System Before Writing a Single Test
Mapping means analyzing custom code, configuration, and business processes to build a model of what the system does and how its parts connect. Every later step depends on this model, so teams that rush it pay for it during execution.

Consultants start with two inputs. The first is code: custom programs, enhancements, interfaces, and the dependencies between them. The second is process: how orders, invoices, postings, and approvals flow through the business. Neither input alone gives the full picture.

Why Code and Process Both Matter
Code analysis finds what exists. Process analysis finds what matters. A custom report nobody runs deserves little attention, but a pricing enhancement that touches every sales order deserves a lot. Mapping connects the two views so the suite targets real business flows rather than spreading effort evenly across everything.

Exception Paths Come From the Map
Happy paths are easy. A customer orders, the system ships, finance bills. Trouble lives in the exceptions: partial deliveries, credit blocks, reversed postings, and rejected approvals. Because the map reflects actual code branches, it surfaces these paths without anyone having to remember them.

For example, a returns scenario might branch four ways depending on material type and plant. A tester writing from memory covers one or two. A map built from the code lists all four.

Step Two: Generate Coverage From Code and Process
Generation turns the map into executable tests. The system produces test cases, test data needs, and expected results directly from the analyzed code and process model, rather than from a tester's recollection of requirements.

Speed matters here, but breadth matters more. A team that builds scripts by hand covers the flows it knows. Generated coverage includes flows nobody documented, which is where many production defects hide.

Consultants still review what the generator produces. They check that tests reflect business intent, not just code structure. A generated test can confirm that a posting runs without confirming that the posting is correct for your organization's accounting rules. That gap between technical correctness and business correctness is where human expertise earns its place.

Step Three: Weight Tests by Business Risk
Not every test deserves equal attention. Weighting ranks the generated coverage by the business risk it protects, so the results tell you what to worry about first. A failure in a pricing enhancement that touches every sales order carries a different weight than a failure in a rarely used report.

Risk-weighted results change how teams respond to a test run. Instead of a flat list of failures, you get a prioritized view that points toward the defects most likely to hurt the business. That is especially valuable close to a release, when time is short and every decision about what to fix and what to defer carries a cost.

Consultants play a central role in setting these weights. They understand which processes the business cannot afford to interrupt, and they translate that knowledge into priorities the suite can act on. Month-end close, billing runs, and approval flows tend to rank high because a failure there reaches finance and operations directly.

Step Four: Run the Suite and Prove Parity
Running the suite executes the generated tests against the system and compares behavior before and after a change. This produces before-and-after parity evidence, which answers a question that stakeholders ask after every release: did anything that worked yesterday stop working today?

Parity evidence is more persuasive than a pass rate alone. A pass rate tells you how many tests succeeded. Parity evidence shows that the system behaves the same way across the change, flow by flow. For teams preparing a migration or a major update, that proof supports go-live decisions and gives auditors something concrete to review.

This stage matters even more as landscapes evolve. Organizations working toward SAP S/4HANA Cloud need confidence that their existing processes survive the move intact. A suite built from the actual system gives them a way to verify that, rather than hoping the old scripts still apply.

Step Five: Maintain the Suite as the System Changes
Maintenance is where script libraries lose and AI-built suites win. Because coverage derives from analysis of the current system, a change triggers regeneration of the affected tests instead of a manual repair effort.

Consider what that means in practice. A transport changes a screen field. In a script library, scripts break and testers spend days finding and fixing them. In a self-maintaining suite, the analysis picks up the change and updates the relevant tests. The team's time goes toward investigating real defects rather than chasing broken scripts.

Over a long project, this difference compounds. The suite stays current without a dedicated repair effort, and the confidence it gives remains steady instead of eroding with every release.

Where Consultant Judgment Matters Most
Automation handles analysis and generation at a scale no manual team can match, but it does not replace judgment. Three areas stand out:

Reviewing generated tests to confirm they reflect business intent, not just code structure
Setting risk weights that match the real priorities of the business
Interpreting results so that the team acts on what matters first
This is also where emerging approaches fit. Teams exploring SAP AI Integration and Agentic Ai SAP capabilities will find that the same principle applies: automation extends what experts can do, and expert oversight keeps the output tied to business outcomes. The five steps give that oversight a structure to work within.

FAQ
Q: How is an AI-built suite different from a script library?

A script library records what testers thought to check, while an AI-built suite derives coverage from your live code and business processes. That includes exception paths that manual scripting often skips, and it regenerates affected tests when the system changes.

Q: Why does mapping come before generating tests?

Every later step depends on the model that mapping builds. It connects custom code, configuration, and business processes so the generated tests target real business flows. Teams that rush this step pay for it during execution.

Q: Does AI-generated coverage remove the need for consultants?

No. Consultants review generated tests to confirm they reflect business intent, set risk weights, and interpret results. A generated test can show that a posting runs without showing that the posting is correct for your accounting rules.

Conclusion
AI automated testing for SAP replaces memory-based scripting with coverage derived from your actual code and processes, following five steps: Map, Generate, Weight, Run, Maintain. The result is a self-maintaining suite with exception-path coverage, parity evidence, and risk-weighted results. Consultant judgment keeps that coverage tied to real business intent.

Ready to move beyond script libraries and build coverage that reflects how your system really works? Our team is here to help. Contact us at info@2isolutionsus.com to get started today.

ABAP Remediation Workflow: From Scan to Proof

2iSolutions US — Mon, 02 Nov 2026 18:54:19 +0000

Why Remediation Needs to Be Visible
Remediation is often pitched as a black box, and that pitch should worry any architect who has to sign a go-live checklist for SAP S/4HANA Cloud. Code goes in, something comes out, and a vendor tells you it works. There is no break list to challenge, no retirement list to question and no log to show an auditor.

At 2isolutions US, an SAP partner delivering since 2005, we run SAP ABAP code remediation as a five-stage workflow where every stage produces a named artifact and every artifact has an owner. The stages are Scan, Triage, Rewrite, Review and Prove. This article walks through each one, shows what each stage hands over, explains where your architect signs off, and describes what we flag instead of guessing.

Most teams meet this problem during a migration. Years of custom reports, enhancements and interfaces sit in the system, and nobody knows which pieces will break on the new platform. A workflow gives you a sequence instead of a pile.

What Is the ABAP Remediation Workflow?
The ABAP remediation workflow is a five-stage process that finds custom code incompatible with SAP S/4HANA, sorts it by risk, rewrites what must change, reviews every change, and proves behaviour is unchanged. Each stage ends with a deliverable your team can inspect.

The five stages run in this order:

Scan the full repository for breaks.
Triage every object into breaking, degrading, compliant or dead.
Rewrite the code that needs to change.
Review each rewrite with an architect.
Prove behaviour with regression tests.
The order matters. Skipping triage means you rewrite code nobody uses. Skipping proof means you trust your own opinion over evidence. Each stage depends on the one before it, so a weak early stage weakens everything that follows.

Why a visible process beats a black box
A black box gives you a price and a date. A visible workflow gives you a break list, a retirement list, a rewrite set and a review log. You can challenge each one, and you can ask why an object landed in a particular category.

That openness also protects your architect. When an auditor asks why an object changed, the answer sits in a log, not in someone's memory. For a person who signs a go-live checklist, that difference is significant.

How Does the Scan Stage Find Every Break?
The scan stage analyses the entire custom code repository against the target SAP release and lists every object that will fail or behave differently. The artifact is a full-repository break analysis, covering all custom objects rather than a sample.

Sampling is the common shortcut, and it hides risk. A report that nobody remembers can still feed a month-end close. If the scan skips it, you learn about it in production, which is the most expensive place to learn anything.

The break analysis typically records:

Objects that will not activate or run on the target release
Statements that behave differently on HANA
Database access patterns that will slow down
Dependencies on obsolete tables or function modules
Where the architect signs off
The architect confirms scope at the end of the scan. That means agreeing which systems, packages and namespaces the analysis covered. If a package was left out, this is the cheapest moment to add it.

Sign-off here is short, but it matters. Every later number, from effort to retirement, builds on this scope. A gap at this point carries through the entire project.

What a scan misses without human input
Tools read code, but they cannot read intent. A scan will flag a custom function module that reads an obsolete table. However, it will not tell you that the module feeds a customer rebate calculation that the sales team relies on every quarter.

So we pair the tool output with a short workshop. Functional leads walk the flagged list and name the business process behind each cluster. That context changes priorities later, because a breaking object in a rebate run outranks a breaking object in a report nobody opens.

How Does Triage Sort Code Into Four Buckets?
Triage places every scanned object into one of four categories: breaking, degrading, compliant or dead. Breaking code fails on the new platform. Degrading code runs but slowly. Compliant code needs nothing. Dead code has no real usage and can go.

This is where budgets get saved. Dead code costs effort to rewrite and effort to test, yet it delivers nothing. Therefore, retiring it removes work from every later stage. The artifact from this stage is a categorised object list, with the retirement list clearly separated so that your team can review what is proposed for removal.

Each bucket drives a different decision:

Breaking objects go to the rewrite queue first, ordered by the business process they support.
Degrading objects are scheduled after breaking ones, since they still run.
Compliant objects are left alone, which keeps the project focused.
Dead objects are proposed for retirement and confirmed by the people who own the process.
The four-bucket model also keeps conversations concrete. Instead of debating whether a large code base is risky, your team looks at a list and decides what to do with each group. That is a far easier meeting to run, and it produces decisions rather than worry.

What Happens in the Rewrite and Review Stages?
Rewrite is the stage where code that must change is actually changed. The inputs are the breaking and degrading lists from triage, and the output is a rewrite set that your team can compare against the original. Because the earlier stages removed dead and compliant code, the rewrite effort concentrates on the objects that matter.

Review follows immediately. Each rewrite is checked with an architect, and the result is a review log. This is the record that answers the auditor's question about why an object changed. It also gives your architect a place to challenge a rewrite before it moves forward, rather than discovering a disagreement after testing has started.

This is also where we flag instead of guessing. When code intent is unclear, a guess can produce a change that compiles but alters business behaviour. A flag sends the question to the person who knows the process. It is slower for that one object, yet it protects the whole result.

How Does the Prove Stage Remove Doubt?
The final stage is proof. Behaviour is verified with regression tests, so that the rewritten code is shown to do what the original did. Without this step, the project rests on opinion. With it, the project rests on evidence your team can inspect.

This closes the loop that the visible workflow opens. You started with a break list. You end with test evidence tied to that list, and between the two sit the retirement list, the rewrite set and the review log. Every object has a path from first detection to verified behaviour, and every step has an owner.

For teams planning around SAP BTP alongside their core system, the same discipline applies to extensions. Code that moves into a side-by-side model still needs scoping, review and proof, and the workflow gives you a repeatable way to handle it.

Who Does This Work, and How Can Teams Resource It?
Remediation needs people who understand ABAP, HANA behaviour and the business processes behind custom code. Many organisations do not have that capacity free during a migration, because the same people are keeping production running. That is why some teams look at SAP Staff Augmentation to add experienced practitioners without pulling their own architects away from daily work.

Others focus on building internal strength. Structured SAP Skills development helps in-house developers learn the patterns that matter on the new platform, so that future custom code is written compliant from the start. The two approaches combine well: augmented capacity handles the migration peak, while skills development reduces the volume of remediation needed next time.

The workflow supports both models because the artifacts are portable. A break list, a retirement list and a review log mean the same thing no matter who produced them. If you want to see how an SAP partner structures this kind of delivery, you can learn more about 2isolutions US and the work we have done since 2005.

FAQ
Q: Why does triage come before the rewrite stage?

Triage separates breaking, degrading, compliant and dead code. Without it, you rewrite code nobody uses, which costs effort in both rewriting and testing and delivers nothing. Retiring dead code removes work from every later stage.

Q: Where does the architect sign off in the workflow?

The architect confirms scope at the end of the scan, agreeing which systems, packages and namespaces were covered. The architect also reviews each rewrite in the review stage, and the result is recorded in a review log that can answer later audit questions.

Q: Why is a scan not enough on its own?

Tools read code but cannot read intent. A scan can flag a function module reading an obsolete table without knowing it feeds a quarterly customer rebate calculation. A short workshop with functional leads supplies that business context and changes priorities.

Conclusion
The ABAP remediation workflow turns a black box into five inspectable stages: Scan, Triage, Rewrite, Review and Prove. Every stage produces a named artifact with an owner, and your architect signs off where it counts. The result is a go-live checklist backed by evidence rather than a vendor's assurance.

Ready to see what is hiding in your custom code before your move to SAP S/4HANA Cloud? Our team is here to walk you through the workflow and what each stage would hand your architects. Contact us at info@2isolutionsus.com to get started today.

Your SAP Is on HANA but Still Slow: Fixing Custom Code Anti-Patterns

2iSolutions US — Thu, 29 Oct 2026 17:48:20 +0000

Why HANA Does Not Automatically Fix Slow SAP Code
Migrating SAP to HANA often creates expectations of dramatically faster reports, batch jobs, and transactional processing. Yet many teams discover that a Monday morning workload takes just as long after migration as it did before. The reason is simple: the database platform changed, but the custom ABAP logic did not.

HANA is designed to filter, aggregate, and analyze large volumes of data efficiently in memory and through column-based storage. However, inefficient application code can prevent the database from delivering those benefits. Instead of allowing HANA to process data close to the source, legacy programs may retrieve excessive records, perform calculations on the application server, or issue thousands of individual database requests.

Teams with the right SAP Skills can identify these bottlenecks and modernize the code without immediately investing in additional infrastructure. In many cases, a focused code review produces more value than a hardware upgrade.

Three Custom Code Anti-Patterns That Limit Performance

Database Calls Inside Loops A SELECT statement inside a LOOP is one of the most common performance issues in legacy ABAP. The program first reads a list of business objects, such as orders or deliveries, and then executes another database query for every item in that list. A small test dataset may hide the problem, but a production report processing 200,000 records can generate 200,000 database calls.

The issue is not necessarily that each query is slow. The issue is the volume of round-trips between the application server and database. The usual solution is to retrieve related information in one operation through a JOIN, carefully structured FOR ALL ENTRIES statement, or another set-based approach. This can reduce lengthy batch jobs from tens of minutes to only a few minutes.

Full-Table Scans Queries that do not filter effectively may force HANA to examine far more data than the program actually needs. Column-store technology improves analytical processing, but it does not make unrestricted scans free. A report that filters a large table only after retrieving broad datasets will still consume memory, CPU, and network capacity.

Review the fields used in WHERE clauses and confirm that the logic narrows the dataset as early as possible. In some cases, an appropriate secondary index helps. In others, the better answer is to include key fields, eliminate unnecessary selections, or redesign the query so that filtering occurs in the database rather than in ABAP.

Aggregation Performed in ABAP Another common pattern is to transfer thousands or millions of rows to the application server and then calculate totals, counts, averages, or groupings in internal tables. This approach may have been reasonable when custom programs were designed around older databases. On HANA, it wastes one of the platform’s greatest strengths.

Whenever practical, push aggregation, filtering, sorting, and joins down to the database layer. Modern Open SQL, CDS views, and carefully designed database procedures can return a smaller, more useful result set to the application. The ABAP layer then focuses on business logic instead of processing raw data that HANA could handle more efficiently.

A Practical Code Optimization Process
Performance improvements work best when they are measured rather than guessed. A structured review can help teams prioritize the changes with the greatest operational impact:

Use workload monitoring and SQL analysis to identify expensive statements and long-running programs.
Check for SELECT statements inside loops, nested database access, and repeated reads of the same data.
Review execution plans to understand whether queries are filtering effectively or scanning unnecessary records.
Compare database time, application-server time, memory usage, and transferred data volume.
Rewrite one bottleneck at a time, then retest with realistic production-sized datasets.
Document the improved pattern so future custom development does not recreate the same problem.
This process is equally important for organizations adopting SAP HANA Cloud Solutions or moving toward SAP S/4HANA Cloud. Cloud infrastructure can provide elasticity and modern services, but inefficient custom logic can still create avoidable costs and slow user experiences.

What SAP Teams Should Prioritize
Not every custom program requires a complete rewrite. Start with jobs that affect financial close, order fulfillment, inventory planning, customer reporting, or other high-value processes. Prioritizing programs by business impact helps the team show measurable results quickly and builds support for broader modernization.

It is also important to validate functional behavior after every change. A faster query that produces incomplete or duplicated results is not an improvement. Performance testing should therefore include record counts, totals, authorization behavior, edge cases, and comparisons with the original program.

For organizations without sufficient internal capacity, SAP Support can help investigate recurring performance issues, while an experienced development team can refactor custom code and establish sustainable standards for future enhancements.

FAQ
Q: Does moving to HANA eliminate the need to optimize ABAP?

No. HANA accelerates database operations, but inefficient ABAP can still create excessive calls, transfer unnecessary data, and perform expensive processing outside the database.

Q: Should every SELECT inside a LOOP be removed?

Not always, but every instance should be reviewed. If the loop is small or the logic is highly specific, the pattern may be acceptable. For large datasets, a JOIN, bulk read, or other set-based approach is usually more efficient.

Q: Is adding an index always the best solution?

No. An index may help, but it can also increase storage and write overhead. First confirm that the query is logically filtering the right data and that the execution plan supports the proposed change.

Conclusion
HANA provides substantial performance potential, but custom code must be designed to use it. Eliminating database calls inside loops, reducing full-table scans, and pushing aggregation into the database can deliver faster results without immediately expanding infrastructure.

Ready to improve the performance of your SAP environment? Our experts can help identify custom code bottlenecks and create a practical optimization plan. Contact us at info@2isolutionsus.com to get started.

Smart Forms to Adobe Forms: Invoices and Statutory Documents Done Right

2iSolutions US — Wed, 28 Oct 2026 18:43:29 +0000

Why Smart Forms Migration Is More Than a Formatting Exercise
Many Canadian SAP teams treat a move from Smart Forms to Adobe Forms as a visual redesign. In practice, it is a business-critical migration involving invoices, packing slips, credit memos, tax documents, and statutory outputs. A form that appears correct in development can still fail when printed, emailed, translated, or generated for a different legal entity.

For organizations planning an SAP Erp Implementation Services initiative, forms should be managed as a dedicated workstream. Canadian requirements add complexity through GST, HST, QST, bilingual presentation, export documentation, and customer-specific contractual layouts. Each variation must be identified, rebuilt, tested, and approved rather than assumed to inherit the behavior of the original form.

The same principle applies during an SAP S/4HANA Cloud transformation. Output management may involve new technologies, changed data structures, and updated integration points. Treating forms as an afterthought can delay testing and expose the business to incorrect customer or regulatory documents.

Why Canadian Output Documents Require Careful Planning
A standard invoice template rarely reflects every requirement found in a Canadian SAP landscape. GST and HST may need to appear as clearly identified tax amounts, while Quebec transactions may require a QST registration number. Federal government customers can require English and French content in parallel columns, not simply one language placed after the other.

These requirements create variants. One invoice may have separate versions for domestic sales, exports, Quebec transactions, bilingual customers, credit memos, intercompany billing, consolidated billing, and a legacy customer agreement. A mid-market company may have hundreds of forms and thousands of combinations across company codes, plants, sales organizations, languages, and output channels.

Accuracy percentages can also be misleading. If a project migrates 400 forms with 98% accuracy, eight forms still contain defects. If even one of those documents is a tax invoice or a remittance-related output, the issue is operational and potentially regulatory—not merely cosmetic. Comparing every critical document against its approved source is essential.

The Five-Step Migration Method
A reliable migration separates discovery, technical reconstruction, validation, and business approval. The following five steps help teams control scope and reduce late-stage surprises.

Inventory: Catalogue active and inactive Smart Forms, associated programs, output types, business owners, organizational units, languages, and known variants. Inactive objects should not be dismissed automatically because custom programs or legacy interfaces may still call them.
Extract: Capture the form layout and output logic as separate artifacts. Layout determines presentation, while logic controls data selection, conditions, sequencing, and calculations. Document the function modules, BAPIs, custom includes, and interfaces that supply the data.
Rebuild: Recreate the form in the target Adobe Forms environment, preserving required business rules while improving maintainability. This is also the right time to remove obsolete fields, standardize labels, and confirm whether language and tax content are controlled centrally.
Compare: Generate representative outputs for every important combination and compare them with approved Smart Forms results. Test more than the happy path, including partial deliveries, returns, reversals, discounts, multiple tax rates, foreign currencies, long addresses, and missing optional data.
Sign off: Obtain formal approval from business, tax, customer service, and IT stakeholders. Sign-off should identify the exact variants tested, the sample transactions used, and any accepted differences between the old and new outputs.
Testing the Details That Commonly Break
Automated form comparison can identify alignment and text differences, but it cannot determine whether the right tax treatment was applied or whether a legal disclosure is appropriate for a particular transaction. Functional testing therefore needs both technical and business perspectives.

Teams should validate tax labels, registration numbers, totals, rounding, currency symbols, payment terms, bank details, customer references, and document numbering. They should also test output channels independently. A PDF generated for email may behave differently from a printed document, and electronic delivery can expose issues with fonts, page breaks, attachments, or character encoding.

Bilingual testing deserves special attention. French and English text can expand differently, changing line wrapping and table height. Long product descriptions, addresses, and legal clauses may push totals onto another page or create blank pages. Testing should include realistic data rather than short development examples.

Governance, Ownership, and SAP Support
Forms remain easier to manage when each object has an accountable owner. Business teams should own content and regulatory meaning, while technical teams manage development standards, transport controls, integrations, and performance. Tax specialists should confirm Canadian requirements, especially where a form supports multiple jurisdictions or customer classes.

Documentation should include the form purpose, triggering output type, data sources, variant rules, language behavior, approval status, and test evidence. This information becomes valuable after go-live when a customer requests a layout change or a tax rule changes. A structured SAP Support process can then assess the request without reverse-engineering the entire output landscape.

Migration planning should also allow time for defect correction. Forms are often tested late because project teams prioritize core processes first. That approach creates a bottleneck during user acceptance testing, when business users discover that a missing field or incorrect page break affects an entire group of customers. Early inventory and sample generation reduce that risk.

FAQ
Q: How long does a Smart Forms to Adobe Forms migration take?

The timeline depends on the number of forms, variants, interfaces, languages, and approval groups. A small, standardized scope may take weeks, while a mature Canadian SAP landscape with hundreds of outputs requires phased planning, detailed testing, and multiple business sign-offs.

Q: Can all Smart Forms be migrated automatically?

Automation can accelerate inventory, extraction, and portions of reconstruction, but it does not replace functional validation. Tax logic, customer-specific rules, bilingual layouts, and legacy integrations still require expert review and business approval.

Q: What should be tested first?

Start with customer invoices, credit memos, tax-related documents, and outputs used by government or strategically important customers. Then expand testing to packing slips, statements, intercompany documents, and lower-volume variants.

Conclusion
Moving from Smart Forms to Adobe Forms is a controlled business transformation, not simply a change in document design. Canadian organizations can reduce compliance and operational risk by inventorying every variant, separating layout from logic, testing realistic scenarios, and securing formal sign-off.

Planning a forms migration or need help validating Canadian output requirements? Our specialists can help you build a practical roadmap and support your SAP transformation. Contact us at info@2isolutionsus.com to get started.

SAP Agentic AI for S/4HANA: Five Services That Cut Migration Busywork

2iSolutions US — Thu, 22 Oct 2026 19:53:11 +0000

Why Agentic AI Matters in an S/4HANA Migration
Most SAP migration delays are not caused by a single technical failure. They come from thousands of manual tasks spread across spreadsheets, legacy systems, email threads, and approval queues. Data must be profiled, mapped, cleansed, tested, reviewed, and reconciled before it can safely move into the target environment.

Agentic Ai SAP changes how that work gets done. Instead of waiting for a consultant to trigger every next step, an AI agent can monitor conditions, plan actions, execute routine tasks, and escalate exceptions when human judgment is needed. The result is not the removal of people from the migration. It is the removal of repetitive coordination work that prevents specialists from focusing on higher-value decisions.

Unlike traditional automation, which follows a fixed script, an agentic system can respond to variation. If a record does not match the expected format, the agent can identify the pattern, apply an approved correction where the risk is low, and send ambiguous cases to a reviewer with supporting context.

Five Services That Reduce Migration Effort

Automated Data Quality Assessment Before data enters SAP S/4HANA Cloud, it must be assessed for completeness, consistency, duplication, and format compliance. An agentic service connects to source systems, profiles data against the target schema, and produces a prioritized list of issues.

It can categorize findings by migration risk, recommend remediation rules, and automatically correct safe records. High-risk anomalies are routed to the appropriate data owner with the original value, proposed correction, and reason for the recommendation. This approach lets teams focus on exceptions instead of reviewing every record manually.

Intelligent Data Mapping and Transformation Legacy systems rarely use the same field names, code structures, or business definitions as S/4HANA. Mapping those differences manually is slow and creates avoidable errors. An AI agent can compare source and target fields, learn from approved mappings, and suggest transformations based on historical patterns and business rules.

For example, an agent may recognize that several legacy payment terms correspond to one standardized target value. It can propose the mapping, identify records that do not fit the pattern, and maintain an audit trail of every transformation. Human experts still approve critical decisions, but they no longer have to build every mapping from scratch.

Automated Master Data Remediation Customer, vendor, material, and financial master data often contain duplicates, obsolete values, inconsistent naming conventions, and incomplete attributes. These problems become more visible during migration because the target platform requires stronger governance and standardized structures.

An agentic remediation service can detect duplicate entities, compare related records, recommend survivorship rules, and prepare corrections for approval. It can also identify missing dependencies, such as a material without a valid unit of measure or a supplier without the required purchasing data. Low-risk fixes can be applied automatically, while sensitive changes remain subject to review.

Migration Testing and Defect Triage Testing is another area where teams lose time to repetitive work. Testers must compare source and target records, verify business processes, document defects, and determine whether an issue belongs to data, configuration, integration, or user behavior.

An agent can generate test scenarios from migration rules and process requirements, execute repeatable validation checks, and compare results across systems. When a test fails, it can group related defects, identify likely root causes, and route each issue to the right workstream. That shortens the distance between discovering a problem and resolving it.

Cutover Coordination and Post-Migration Monitoring Cutover involves tightly sequenced activities across technical teams, business owners, integration specialists, and support groups. A missed dependency can delay the entire go-live window. Agentic services can monitor task status, validate prerequisites, send reminders, and escalate blocked activities before they threaten the schedule.

After go-live, the same capability can monitor data loads, interfaces, job failures, and reconciliation results. It can distinguish normal fluctuations from conditions that require attention and create a structured handoff for support teams. This gives project leaders better visibility without requiring someone to manually check every dashboard throughout the day.

How SAP Teams Should Govern Agentic Services
Autonomy does not mean unlimited access. Organizations should define clear boundaries before deploying agents across a migration program. Effective governance typically includes:

Approved data sources, target systems, and action permissions.
Rules that specify which corrections may happen automatically.
Human approval for financially material, regulatory, or irreversible changes.
Complete logs covering recommendations, actions, exceptions, and approvals.
Performance measures such as review volume, defect resolution time, and data quality improvement.
This governance model allows teams to gain speed while retaining accountability. It also makes it easier to expand successful use cases from one migration object or business unit to another.

What This Means for RISE with SAP S/4HANA Programs
Organizations adopting RISE with SAP S/4HANA often manage complex transformation timelines while redesigning processes, integrating systems, and preparing users for change. Agentic services can support these efforts by reducing the administrative load across data, testing, and cutover workstreams.

The greatest benefit comes when agents are connected to a broader SAP AI Integration strategy. In that model, migration intelligence does not operate as an isolated tool. It can work with enterprise data, workflow, analytics, and governance capabilities to create a more consistent operating model before, during, and after deployment.

FAQ
Q: Can agentic AI complete an SAP migration without human involvement?

No. It can automate routine analysis, transformation, testing, and coordination, but business owners should approve critical rules and exceptions. Human oversight remains essential for compliance, financial accuracy, and decisions that affect business processes.

Q: Which migration activity should companies automate first?

Data quality assessment is often the best starting point because it produces immediate visibility into migration risk. Once data patterns and approval rules are established, organizations can extend automation to mapping, remediation, testing, and cutover management.

Q: How can organizations measure the value of agentic services?

Track the reduction in manual review hours, unresolved defects, duplicate records, test-cycle duration, and cutover exceptions. These measures show whether agents are improving both project speed and migration quality.

Conclusion
Agentic AI can remove much of the repetitive work that makes SAP migrations slow and difficult to manage. By applying intelligent services to data quality, mapping, remediation, testing, and cutover, organizations can move toward a faster, more controlled S/4HANA transformation while keeping people focused on decisions that require expertise.

Ready to reduce migration busywork and improve your SAP transformation program? Our experts can help you identify practical agentic AI opportunities and build a governed implementation plan. Contact info@2isolutionsus.com to get started.

How SAP AI Helps Finance Teams Close Books Faster

2iSolutions US — Wed, 21 Oct 2026 19:04:57 +0000

Why Finance Close Cycles Remain Slow
Finance teams rarely struggle because their people lack skill or urgency. Close cycles stretch because the process is fragmented across spreadsheets, email, manual journal entries, and disconnected reconciliation tasks. Even organizations with mature SAP environments may spend eight to twelve days finalizing results, while best-in-class teams complete the process in only a few days.

A slow close affects more than the accounting department. When leaders wait nearly two weeks for reliable numbers, budget approvals, hiring decisions, and capital planning all rely on outdated information. The real issue is usually a data and workflow problem, which makes intelligent automation a practical path to improvement.

Where SAP AI Creates the Biggest Impact
SAP AI Solutions bring predictive analytics, pattern recognition, and natural language capabilities directly into finance workflows. Instead of forcing accountants to use a separate AI dashboard, SAP surfaces recommendations and exceptions in the applications where finance work already happens.

Automated Journal Entries and Anomaly Detection
Recurring journals often follow predictable patterns. AI can identify routine entries, recommend or automate their preparation, and direct unusual postings to an accountant for review. The result is less time spent processing standard transactions and more time focused on judgment-based work.

Anomaly detection also helps find unexpected amounts, unusual account activity, or postings outside normal cost-centre patterns before the close is finalized. Early detection reduces the rework that commonly adds several days to the process.

Faster Intercompany Reconciliation
Intercompany differences can bring a close to a standstill. Entities may record the same transaction with different dates, amounts, or classifications, leaving teams to search through files and coordinate across time zones. SAP AI Integration can match related transactions, highlight exceptions, and route discrepancies to the appropriate owner with supporting context.

That visibility changes reconciliation from a manual investigation into an exception-management process. Teams spend less time looking for mismatches and more time resolving the issues that genuinely require expertise.

Making SAP AI Ready for Finance
Technology alone will not shorten a close. Finance and IT leaders should prepare the foundation before expanding AI use:

Standardize the chart of accounts, master data, and intercompany processes.
Review data quality, authorization roles, and transaction histories.
Define which decisions can be automated and which require human approval.
Measure close duration, exception volume, and reconciliation effort before and after deployment.
Organizations moving to SAP S/4HANA Cloud can also use the transition to simplify processes and establish cleaner data structures. A focused SAP Joule Implementation may further help users ask questions in natural language, summarize exceptions, and access relevant finance insights more quickly.

What Finance Leaders Should Expect
The most successful deployments do not attempt to automate every accounting activity at once. They begin with high-volume, rules-based work such as recurring journals, account reconciliations, and variance review. As confidence grows, teams can expand into forecasting, cash management, and close-status monitoring.

Governance remains essential. Finance leaders should maintain approval controls, document AI recommendations, monitor model performance, and ensure that employees understand when human review is required. Used responsibly, AI supports accountants rather than replacing their financial judgment.

FAQ
Q: How quickly can SAP AI improve the close?

The timeline depends on data quality, process complexity, and integration readiness. Many teams begin seeing value in targeted areas such as journal processing and intercompany matching before pursuing broader transformation.

Q: Does SAP AI eliminate the need for finance professionals?

No. It reduces repetitive work and highlights exceptions, allowing finance professionals to focus on analysis, controls, judgment, and business partnering.

Q: What is the first step toward adoption?

Map the current close process, identify the most time-consuming bottlenecks, and assess the quality of the SAP data supporting those activities. This creates a practical roadmap for automation.

Conclusion
SAP AI helps finance teams close faster by automating predictable work, detecting issues earlier, and making intercompany reconciliation more transparent. With the right data, governance, and implementation plan, organizations can turn the close from a quarterly fire drill into a controlled, insight-driven process.

Ready to improve your SAP finance processes? Our experts can help you evaluate automation opportunities and plan a practical AI roadmap. Contact info@2isolutionsus.com to get started.

AI for ECC and On-Premise: What You Get Before Migrating

2iSolutions US — Mon, 19 Oct 2026 19:23:14 +0000

AI Is Available Before Your S/4HANA Migration
Many SAP ECC customers view artificial intelligence as a future-state capability that becomes available only after moving to S/4HANA. That assumption can delay valuable improvements in finance, procurement, supply chain, and data management. In reality, organizations can begin using SAP AI Solutions while keeping their existing ECC core in place.

Through SAP Business Technology Platform (BTP), cloud connectors, APIs, and side-by-side extensions, companies can introduce AI services without immediately replatforming their ERP environment. This approach allows IT and business teams to test practical use cases, measure results, and build internal experience before a larger migration program begins.

What AI Can Deliver in an ECC Environment
AI does not have to be embedded directly inside ECC to create measurable business value. A connected AI layer can work with approved ECC data and return recommendations, classifications, predictions, or exception alerts to the people and processes that need them.

Intelligent document processing: Extract invoice data, validate fields, and route exceptions for accounts payable and procurement.
Predictive planning: Improve demand forecasting, inventory visibility, and replenishment decisions using historical and operational data.
Anomaly detection: Identify unusual financial postings, duplicate transactions, or activity that may require review.
Master data improvement: Detect incomplete, inconsistent, or duplicated customer, vendor, and material records.
Cash application: Support automated matching between incoming payments, bank statements, and open receivables.
Exception management: Highlight purchase order, goods receipt, and invoice discrepancies before they become larger workflow problems.
These capabilities can operate alongside customized ECC processes. Rather than changing the ERP core first, organizations can focus on narrowly defined business outcomes and expand only after the initial use case proves its value.

The BTP Bridge Between ECC and AI
SAP Business Technology Platform provides a practical foundation for SAP AI Integration. It connects on-premise systems with cloud-based data, analytics, automation, and AI services while helping organizations maintain governance over access and information flows.

This side-by-side model is particularly useful for companies with heavily customized ECC environments. Existing ABAP developments and core configurations can remain stable while new AI capabilities are developed at the edge. Teams can apply security controls, define which data is shared, and establish a testing process without placing experimental technology directly into the production ERP system.

The architecture also supports a more measured investment strategy. A company might begin with invoice automation, then add anomaly detection or predictive inventory analysis after it has established data ownership, integration patterns, and performance metrics.

Where the Business Case Is Strongest
Finance and procurement are often the best starting points because they contain repetitive, rules-based activities with clear performance measures. In accounts payable, AI can extract invoice header and line-item data, compare it with purchase orders and receipts, assign a confidence score, and send only exceptions to a specialist. Employees spend less time entering information and more time resolving issues that genuinely require judgment.

Bank reconciliation and cash application offer another strong opportunity. AI can compare payment references, customer information, amounts, and historical patterns to suggest matches. Finance teams retain control over approvals while reducing the manual effort required to clear high-volume transactions.

Supply chain teams can also use predictive models to identify demand trends, potential stockouts, and unusual order patterns. The objective is not to replace planners. It is to give them earlier and more relevant insight so they can act before service levels or working capital are affected.

What Still Requires S/4HANA
ECC-based AI should not be confused with the full set of capabilities available in a modern S/4HANA architecture. Some features depend on embedded data models, real-time transactional analytics, or native user experiences that are designed specifically for S/4HANA.

For example, broad SAP Joule Implementation across business processes, deeply embedded AI in core finance and materials management transactions, and unified real-time insights may require a migration or significant modernization of the underlying landscape. Similarly, advanced Agentic Ai SAP scenarios may depend on standardized processes, clean master data, and integrated applications that are easier to establish in an S/4HANA environment.

That distinction should inform the roadmap, not stop progress. Organizations can use ECC-compatible services to learn where AI produces value while treating migration as the path toward deeper, more embedded capabilities.

A Practical Path Forward
Choose one process with measurable manual effort, such as invoice processing or cash application.
Assess data quality, integration requirements, security, and approval responsibilities.
Build a side-by-side proof of value using BTP and approved ECC interfaces.
Track results such as processing time, exception volume, accuracy, and employee adoption.
Use the findings to prioritize additional use cases and inform the S/4HANA migration business case.
FAQ
Q: Do we need to migrate to S/4HANA before using AI?

No. Many AI use cases can be implemented alongside ECC through BTP, APIs, cloud connectors, and side-by-side extensions. Migration may be required for certain embedded or enterprise-wide capabilities, but it is not a prerequisite for every AI initiative.

Q: Will AI require changes to our ECC core?

Not necessarily. A side-by-side architecture can keep most AI functionality outside the ECC core, reducing disruption and making it easier to test, govern, and scale new capabilities.

Q: How should we choose our first AI use case?

Start with a repetitive process that has accessible data, visible pain points, and clear success metrics. Finance and procurement workflows are often strong candidates because improvements can be measured quickly.

Conclusion
ECC customers do not have to wait for migration to begin building practical AI capability. With the right integration approach, organizations can improve current processes, develop AI expertise, and create a more informed business case for the future S/4HANA transition.

Ready to identify the right AI opportunities in your SAP landscape? Our experts can help you evaluate ECC-compatible use cases and plan a secure path forward. Contact us at info@2isolutionsus.com to get started.

Why Move from Smartforms to Adobe Forms in S/4HANA?

2iSolutions US — Thu, 15 Oct 2026 19:22:26 +0000

Many SAP teams discover the Smartforms challenge during an S/4HANA transformation. A form that worked reliably in the legacy environment may render incorrectly, lose fonts, or fail to generate after the upgrade. What initially appears to be a small technical adjustment can quickly become a critical project issue when invoices, purchase orders, delivery notes, and regulatory documents are affected.

Moving from Smartforms to Adobe Forms is not simply a visual redesign. SAP Interactive Forms by Adobe is the strategic output technology for modern S/4HANA environments. In particular, organizations adopting SAP S/4HANA Cloud cannot rely on Smartforms as their long-term form solution. Planning the transition early helps businesses avoid rushed testing, unexpected consulting costs, and operational disruption at go-live.

For a detailed look at the transition, review this guide to SAP Erp Implementation Services and Adobe Forms planning.

What Adobe Forms Changes Technically
Smartforms relies heavily on ABAP-based processing and traditional SAP form logic. Adobe Forms separates the document layout from the application data and processing logic. The template is designed with Adobe LiveCycle Designer, while the ABAP application supplies the data through a defined interface. Adobe Document Services, commonly called ADS, then processes the template and creates the final PDF output.

This separation provides a more maintainable architecture. Developers can focus on data retrieval and business rules, while form specialists can update the layout without changing core ABAP programs. It also supports more consistent output across print, PDF, email, and digital document channels.

The change can also reduce long-term dependency on a small group of senior ABAP developers. Finance, procurement, and logistics teams frequently request adjustments to logos, labels, tax details, payment instructions, and regulatory wording. With the right governance, trained business analysts or functional specialists can manage many layout changes more efficiently.

The Business Case for Migrating Before Go-Live
Forms are often treated as a late-stage project activity because they do not appear to affect core transaction processing. In reality, they are closely tied to revenue collection, warehouse execution, supplier communication, and legal compliance. A failed form can stop an otherwise successful business process.

Protect the cutover schedule: Completing the migration before go-live gives the project team time to resolve rendering, font, and data-mapping issues.
Reduce emergency costs: Late form remediation often requires premium-rate consultants during a period when project resources are already under pressure.
Support compliance: Invoices and other statutory documents must display accurate tax, company, customer, and payment information.
Improve maintainability: A standardized Adobe Forms framework makes future changes easier to estimate, test, and deploy.
Prepare for cloud adoption: Early migration reduces technical debt for organizations planning a phased move to S/4HANA Cloud.
The financial impact is not limited to IT labor. If invoices cannot be generated, accounts receivable may be delayed. If delivery notes fail, warehouse shipments may be held. If purchase orders are incomplete or unreadable, suppliers may not process them. These indirect costs can exceed the original migration budget by a wide margin.

ADS Configuration and Implementation Risks
Adobe Forms depends on Adobe Document Services, and ADS requires more planning than many teams initially expect. The solution may involve a dedicated Java application server, SSL certificates, trusted RFC communication, network access, and coordinated configuration across development, quality, and production environments.

Common risks include incomplete certificate setup, incorrect RFC destinations, missing fonts, inconsistent server versions, and insufficient authorization. A form may appear to work in development but fail in quality because the environments do not share the same configuration. Conditional sections may also produce blank areas when required data is missing or mapped differently than expected.

Testing should therefore cover both technical rendering and business scenarios. Teams should validate multiple languages, page breaks, long customer names, tax conditions, discounts, logos, barcodes, signatures, attachments, and high-volume processing. They should also test output through every relevant channel, including print, email, archive, and PDF download.

Strong SAP Skills are especially important because the work crosses functional, technical, security, and infrastructure responsibilities. A form developer alone may not identify an authorization problem, while a basis specialist may not recognize a data-mapping defect. Clear ownership and a shared test plan help prevent these gaps.

A Practical Migration Approach
Inventory existing forms: Identify every Smartform, its business owner, transaction, output channel, regulatory purpose, and usage volume.
Prioritize business-critical documents: Start with invoices, delivery documents, purchase orders, and forms required for legal or operational continuity.
Map data and logic: Document the existing fields, conditions, calculations, custom code, and integrations before redesigning the layout.
Build the ADS foundation: Complete server, certificate, RFC, authorization, and transport configuration in a controlled sequence.
Develop and test iteratively: Compare Adobe output with approved business samples and involve process owners early.
Plan cutover and support: Define rollback procedures, production monitoring, issue ownership, and post-go-live response coverage.
Organizations should also avoid treating every form as a one-for-one technical conversion. Some legacy forms contain obsolete fields, duplicate information, or workarounds created for older processes. The migration is an opportunity to simplify documents, improve readability, and align output with current business and compliance requirements.

How to Reduce Project and Operational Risk
The safest programs begin with an assessment rather than immediate development. The assessment should identify the current Smartforms landscape, dependencies on custom ABAP code, ADS readiness, form volume, and the consequences of failure for each document type.

Governance is equally important. Assign a business owner to approve content, a technical owner to manage interfaces and transports, and a testing owner to coordinate scenarios and sign-offs. Maintain version control for templates and establish a formal process for changes after go-live.

Businesses should also include support planning in the original business case. Adobe Forms may be the modern standard, but production issues can still occur because of infrastructure changes, missing fonts, transport errors, or new business requirements. A knowledgeable SAP Support partner can help monitor output, troubleshoot failures, and manage enhancements without delaying core operations.

FAQ
Q: Is Smartforms still supported in SAP S/4HANA?

Support depends on the specific S/4HANA edition, release, and deployment model, but Smartforms is not the preferred strategic technology for new development. Organizations planning cloud adoption should treat Adobe Forms as the target architecture and confirm product-specific capabilities during planning.

Q: Does every Smartform need to be migrated?

Not necessarily. Some forms may be retired, consolidated, or replaced by standard output. However, every active form should be assessed for business criticality, technical compatibility, compliance requirements, and future use before a decision is made.

Q: How early should ADS and form migration begin?

Begin during the design and realization stages, not immediately before cutover. The exact timeline depends on the number and complexity of forms, but early testing gives teams time to resolve infrastructure, content, and integration issues without putting the go-live date at risk.

Conclusion
Moving from Smartforms to Adobe Forms gives S/4HANA programs a more sustainable output architecture and supports the requirements of modern cloud deployments. By treating forms as a business-critical workstream, organizations can reduce cutover risk, improve maintainability, and protect revenue-generating processes.

Ready to assess your Smartforms migration or prepare ADS for S/4HANA? Our experts can help you plan, implement, and support a reliable Adobe Forms environment. Contact us at info@2isolutionsus.com to get started.

Grow with SAP: Why Business AI Changes the Decision

2iSolutions US — Tue, 13 Oct 2026 19:57:02 +0000

Why Business AI Changes the SAP Decision
Enterprise technology investments must do more than replace aging software. They should improve how teams operate, make decisions, and respond to changing market conditions. SAP Business AI addresses that need by embedding intelligent capabilities into the processes and data businesses already use.

For CIOs and IT leaders across the United States and Canada, the timing is especially important. As organizations plan their move from ECC to S/4HANA, they have an opportunity to modernize core operations while building a stronger foundation for automation, analytics, and artificial intelligence.

Business AI is not simply another dashboard or third-party application. It is designed to work within enterprise workflows, helping finance, supply chain, procurement, sales, and human resources teams act on trusted information faster.

Integration Is the Foundation of AI Value
The effectiveness of AI depends on the quality, availability, and context of business data. That makes sap system integration a critical part of any transformation strategy. When SAP and non-SAP applications operate in disconnected silos, AI recommendations may be incomplete or difficult to trust.

A connected architecture allows information to move consistently across financial systems, manufacturing platforms, customer applications, and external providers. It also gives AI the context required to identify patterns and recommend practical next steps.

Successful integration programs typically focus on:

Connecting S/4HANA with legacy systems that remain in operation.
Mapping data flows across SAP modules and third-party applications.
Improving master data governance and record quality.
Supporting real-time events for time-sensitive decisions.
With these capabilities in place, organizations can forecast cash flow concerns, detect supplier risks, improve inventory planning, and reduce manual reconciliation. The technology becomes part of daily operations rather than an isolated experiment.

From Recommendations to Autonomous Action
Traditional analytics explain what happened or predict what may happen next. agentic ai in btp introduces a more active model. AI agents can receive a business objective, break it into multiple tasks, use approved tools and APIs, and report the results with limited human intervention.

For example, a procurement agent could identify a potential shortage, review approved suppliers, compare pricing with contract terms, and prepare a purchase request for review. In finance, an agent could support intercompany reconciliation by identifying discrepancies and routing exceptions to the right team.

SAP Business Technology Platform provides the connectivity, runtime, and governance capabilities needed for this kind of automation. It helps organizations connect enterprise data sources while maintaining security, access controls, and oversight. Human approval can remain part of the process wherever risk or policy requires it.

Making the Transformation Practical
AI adoption should begin with business priorities, not technology alone. Organizations can create stronger results by selecting high-value use cases, validating data readiness, and establishing clear accountability for automated decisions.

A practical roadmap includes assessing the current SAP landscape, defining integration requirements, and identifying processes where faster decisions would produce measurable value. Program management in JIRA can also help teams coordinate workstreams, track dependencies, document issues, and maintain visibility across business and technical stakeholders.

Working with a Certified SAP partner North America organizations can trust may simplify this process. Experienced specialists can align architecture, migration, integration, governance, and adoption plans so that AI initiatives support broader business objectives.

FAQ
Q: Is SAP Business AI only useful after migrating to S/4HANA?

Organizations can begin preparing data, integrations, and use cases before migration. However, S/4HANA provides a stronger modern foundation for activating embedded intelligence and scaling automation.

Q: Does agentic AI remove the need for employees?

No. It is intended to reduce repetitive work and support better decisions. Employees continue to provide judgment, oversight, and approval for sensitive or high-impact activities.

Q: What is the first step toward AI readiness?

Start with an assessment of data quality, system connectivity, security controls, and priority business processes. This reveals where integration improvements can create the fastest return.

Conclusion
SAP Business AI changes the modernization decision by connecting intelligent capabilities directly to the systems and workflows that run the enterprise. With strong integration, disciplined governance, and a practical roadmap, organizations can move from isolated automation projects to faster, more confident operations.

Ready to evaluate how SAP and Business AI can support your growth strategy? Connect with our team at info@2isolutionsus.com to discuss your next step.

What Four Sessions of Live SAP Demonstrations Taught Us

2iSolutions US — Tue, 29 Sep 2026 18:50:03 +0000

Why Live SAP Demonstrations Tell a Different Story
Vendor demonstrations often present SAP capabilities in ideal conditions: clean data, familiar processes, prepared examples, and a specialist who knows exactly which option to select. That format can be useful, but it does not always show how a tool performs inside a complex, highly customized SAP environment.

Our four-session live demonstration series took a more practical approach. The sessions examined real capability areas that affect SAP migration, modernization, testing, and operations. Instead of showing only polished outcomes, the demonstrations exposed where AI-assisted tools performed well, where they needed additional context, and where human expertise remained essential.

The central lesson was consistent across every session: AI can accelerate discovery and generate a valuable first draft, but it should not be treated as an unsupervised replacement for SAP professionals. A structured review gate is required before generated code, test cases, assessments, or forms move into a production environment.

For a deeper look at the demonstrations and their results, read the full overview of SAP Skills revealed through the series.

Session One: AI-Assisted ABAP Code Remediation
The first demonstration focused on custom ABAP code and the work required to prepare legacy developments for SAP S/4HANA. Many SAP estates contain thousands of custom programs, reports, function modules, and enhancements. Reviewing every object manually can take months, especially when teams must identify deprecated functions, incompatible patterns, and dependencies across the landscape.

The AI-assisted tool scanned custom ABAP objects and quickly identified potential remediation opportunities. It highlighted outdated function modules, suggested modern alternatives, and generated revised code. The speed was one of the clearest advantages. A task that might require several days of initial developer analysis could be reduced to minutes for the first pass.

However, speed did not guarantee correctness. In some cases, the suggested code was syntactically valid but did not fully reflect the business logic of the original development. A function may have been used in a particular way because of a process exception, an integration dependency, or a control that was not visible in the code itself.

That distinction matters. Automatically accepting every recommendation could introduce subtle errors into a business-critical system. The better approach is to use AI for analysis and suggestion, then have a qualified ABAP developer validate the output, test the behavior, and approve the change. AI improves productivity, but the review gate protects business continuity.

Session Two: Generating and Validating Automated Tests
The second session examined automated test generation. SAP teams frequently struggle to maintain comprehensive testing because business processes evolve, documentation becomes outdated, and test scripts are often stored in disconnected formats. Creating and updating scripts manually can become a bottleneck during upgrades, migrations, and major releases.

The demonstration used process documentation and existing manual test cases to generate initial automated test scripts. The tool produced a usable draft far faster than a traditional manual approach. It identified transaction steps, expected results, and relevant process conditions, giving the team a practical foundation for further refinement.

Yet the quality of the generated test depended heavily on the quality of the source material. When a process description was ambiguous, the AI interpreted it literally. The resulting script could execute successfully while still missing the real business requirement.

For example, an order-to-cash test validated the core SAP transaction but overlooked a manual approval step used by the business before an order could proceed. From a technical perspective, the test passed. From a process perspective, it was incomplete.

This is why testing requires collaboration between technical and functional experts. A business analyst or process owner must compare each generated scenario with how the business actually operates. The review should confirm:

Whether the test reflects the complete end-to-end process.
Whether approvals, exceptions, and controls are included.
Whether expected results are measurable and meaningful.
Whether the data conditions represent real operating scenarios.
AI can reduce the effort required to create test coverage, but it cannot determine business intent from incomplete documentation. Human review converts a fast draft into a reliable test asset.

Session Three: Landscape Assessment and Discovery
The third session focused on assessing an SAP landscape. Before a migration or transformation begins, organizations need a clear understanding of their systems, custom developments, integrations, data, and operational risks. Traditional assessments often rely on spreadsheets, interviews, and manual analysis. Those methods remain useful, but they can be slow and inconsistent when the environment is large.

The live demonstration showed how automated analysis can organize information from an SAP estate and identify patterns that deserve attention. The tool helped classify custom objects, surface potential compatibility issues, and group findings into areas that could support migration planning.

This type of assessment can help leadership move from broad assumptions to a more evidence-based project plan. It can reveal where technical debt is concentrated, which processes depend on custom code, and which objects may require redesign rather than simple remediation.

Still, an automated assessment is not the same as a final recommendation. A tool may identify a technical dependency without understanding its commercial importance. It may flag an object as unused even though the business relies on it during a periodic activity. It may also identify duplicate developments that appear similar but serve different legal or operational requirements.

The review gate therefore needs input from multiple roles, including architects, developers, functional consultants, security specialists, and business owners. This is one area where strong SAP Competencies make a measurable difference. Technology can organize evidence, but experienced professionals must interpret that evidence in context.

Session Four: Form Migration and Document Output
The fourth demonstration addressed forms, an area that is sometimes underestimated during SAP transformation programs. Forms support invoices, purchase orders, delivery documents, statements, labels, and other communications that customers, suppliers, employees, and regulators may depend on.

Legacy forms can be difficult to migrate because their behavior is not limited to visual design. They may contain conditional logic, language rules, formatting requirements, data mappings, and dependencies on custom developments. A form that looks correct in a preview may still fail when it encounters a different company code, currency, language, tax condition, or business scenario.

The demonstration showed how AI could accelerate the analysis and reconstruction of existing form layouts. It helped identify elements, map patterns, and produce an initial version of a target form. This can reduce repetitive design work and help teams process a large inventory more efficiently.

But visual similarity is not enough. Every migrated form needs functional and business validation. Reviewers should confirm that the right data appears in the right location, calculations remain accurate, legal wording is preserved, and output works across the scenarios that matter to the organization.

Forms also illustrate why a review gate should be treated as part of the delivery model rather than an optional final check. Errors may not appear until a specific document is generated for a particular customer, country, or transaction type. Catching them early protects the project from late rework and operational disruption.

The Common Lesson: AI Needs a Deliberate Review Gate
Although the four sessions addressed different problems, they reached the same conclusion. AI is highly effective at accelerating repetitive analysis, organizing large volumes of information, and producing an initial output. It is less reliable when the task depends on undocumented business rules, exceptions, historical decisions, or organizational context.

A practical review model can include these stages:

Define the source. Confirm that the code, documentation, process data, or form being analyzed is complete enough to support a useful result.
Generate the first output. Use the AI tool to scan, classify, recommend, or draft the required artifact.
Review with the right experts. Assign technical and functional reviewers based on the type of output.
Test against real scenarios. Include exceptions, approvals, integrations, data variations, and compliance requirements.
Approve and monitor. Move the validated result forward with clear ownership and retain evidence of the decision.
This model avoids two common mistakes. The first is rejecting AI because its first output is not perfect. The second is accepting AI output without the controls needed for a production SAP estate. The most effective teams use AI to increase the capacity of their experts, not to remove accountability from the process.

What This Means for SAP Transformation Teams
The demonstrations also showed that technology alone does not determine project success. Teams need clear requirements, accessible system knowledge, appropriate governance, and professionals who can challenge an automated recommendation when it does not fit the business.

Organizations planning a migration or upgrade should identify where AI can create the greatest benefit. Code inventories, test script creation, landscape analysis, and form assessment are strong candidates because they involve significant volumes of structured information. At the same time, each use case should have defined acceptance criteria and named reviewers before the work begins.

That approach makes AI easier to govern and easier to scale. It also produces more realistic project estimates because teams can distinguish between automated preparation and the human effort required for validation, testing, remediation, and approval.

FAQ
Q: Can AI replace SAP developers and functional consultants?

No. AI can automate portions of analysis and generate useful drafts, but SAP experts remain responsible for understanding business context, validating results, testing exceptions, and approving changes.

Q: Why is the review gate necessary if the generated output looks correct?

Looks can be misleading. Code, tests, assessments, and forms may appear technically correct while missing a business rule, approval, dependency, or legal requirement. Review confirms that the output works in the real operating context.

Q: Where should an organization begin with AI-assisted SAP work?

Begin with a focused discovery effort. Select a clearly defined use case, establish success criteria, identify reviewers, and test the approach against representative SAP data and processes before expanding it across the landscape.

Conclusion
The four live demonstrations showed that AI can significantly accelerate SAP code remediation, testing, landscape assessment, and form migration. The strongest results come when automation is paired with expert judgment, realistic scenarios, and a formal review gate that protects quality and business continuity.

AI is not a shortcut around SAP expertise. It is a practical way to help experienced teams analyze more information, produce better first drafts, and spend more time on the decisions that matter.

Ready to evaluate where AI can support your SAP transformation? Our specialists can help you identify practical opportunities and build a controlled path from discovery to delivery. Contact us at info@2isolutionsus.com to get started.