Machine learning in plain terms

#The 60-second version

Traditional software follows rules that a person writes: "if lead time is under five days, flag the delivery as at risk". Machine learning turns this around. You show the computer many past examples where you already know the answer, and it works out the rules itself.

The result is called a model. You give it a new case, and it returns a prediction, often with a score for how likely that prediction is.

Three ideas carry most of the weight:

• It learns from examples with known answers. Past deliveries marked "late" or "on time" teach it what late looks like. No examples with answers, no learning.
• It is judged on cases it hasn't seen. A model that only does well on the examples it learned from has memorized, not learned. Teams always hold some examples back to test it.
• It must beat a simple starting point. If 90% of deliveries are on time, a "model" that always says "on time" is 90% right and useless. That simple starting point is the baseline.

#Why it matters to the business

Many SAP processes are full of rules that people wrote years ago: credit limits, tolerance checks, planning parameters. Rules are clear and auditable, but they miss patterns nobody wrote down. A planner may know that heavy orders from one plant slip more often. No rule in the system says so.

Take the running example of this unit: late outbound deliveries in order-to-cash. Every late delivery can mean a penalty, an expedited freight bill or an unhappy customer. If a model can flag the risky 10% of deliveries a few days early, planners can act on those and ignore the rest.

The value depends on three questions a leader can ask without any maths:

The main risks are also simple. A model trained on old patterns can be wrong when the business changes: a new carrier, a new plant, a strike. And a model that looked great in a demo may have been tested on the same data it learned from, which proves nothing.

#How SAP does it

SAP offers machine learning at three levels. As of September 2026:

• Built into S/4HANA ("embedded"). Some predictions run inside S/4HANA itself, using machine learning libraries in the SAP HANA database. SAP describes a predictive delivery delays capability for S/4HANA that does exactly the kind of job this unit teaches. Customers manage these scenarios, and create their own, with a framework called Intelligent Scenario Lifecycle Management (ISLM).
• Beside S/4HANA ("side-by-side"). Heavier jobs, such as reading images or text, run on SAP Business Technology Platform (BTP), in services such as SAP AI Core, and send results back.
• A pre-trained model for business tables. SAP offers SAP-RPT-1, a model built for predictions on table-shaped business data. SAP says it predicts from example rows you send with the request, without a separate training step. SAP lists it as generally available through SAP AI Core.

The SAP Business AI landscape topic shows where these pieces sit. This topic is about the idea underneath all three: learning from examples.

#Rules, learning, or both: a decision guide

In practice, most good designs mix the two. The model ranks cases by risk, and a person or a firm rule decides what happens next.

#Questions to ask

• What exactly is the model predicting, and which past field or event records the right answer?
• How many past examples do we have, and over what time span?
• What is the baseline: the current rule, or simply guessing the most common answer? How much better is the model?
• Was it tested on data it never saw during training? Was that test data from a later period, as it would be in real use?
• Who acts on the prediction, and what do they do differently?
• How will we notice when the model gets worse, and who retrains it?
• Is this a standard SAP scenario we already license, or a custom build?

#Common misconceptions

• "Machine learning means the system keeps learning on its own." Most business models learn once, from a fixed set of examples, and stay the same until someone retrains them.
• "More complex models are always better." A very complex model can memorize its examples and do worse on new ones. This is called overfitting.
• "95% accuracy is great." Not if 95% of cases have the same answer. Always compare with the baseline.
• "ML replaces the rules we have." Usually it sits beside them. Rules handle what is known; the model handles what is fuzzy.
• "Generative AI made classic ML obsolete." Predicting a yes/no or a number from table data is still classic ML's home ground. SAP-RPT-1 is itself a model aimed at this job.

#Key terms

• Model: the learned logic that turns inputs into a prediction.
• Training: the step where the model learns from past examples.
• Feature: one input column the model uses, such as lead time or weight.
• Label: the known answer in past examples, such as "late".
• Test set: examples held back to check the model on cases it hasn't seen.
• Baseline: the simplest honest comparison, such as always guessing the most common answer.
• Overfitting: doing well on training examples but badly on new ones.
• Inference: using a trained model to predict for a new case.

#Check yourself

#Mental model: a function you fit, not a program you write

In ordinary programming you write a function by hand: inputs go in, your logic runs, an answer comes out. In machine learning you choose a family of functions (for example, "trees of yes/no questions, at most three deep") and let an algorithm pick the member of that family that best matches past examples.

flowchart LR
  subgraph Rules
    A[Inputs] --> B[Logic you wrote] --> C[Answer]
  end
  subgraph Learning
    D[Past inputs + known answers] --> E[Training algorithm] --> F[Model]
    G[New inputs] --> F --> H[Prediction]
  end

Everything else in this unit hangs off that picture:

• The features are the inputs. The label is the known answer. Together, many rows of them are the training data.
• Training searches the family for the function that fits the training data best. The next topic in this unit, on gradient descent, shows how that search works for one family.
• The fitted function is only useful if it also works on rows it never saw. That property is called generalization, and it is the whole game.

#How it works

#Kinds of learning

This course spends most of Unit 2 on supervised classification, because most business predictions are "which of these outcomes will happen?". SAP uses the same split: SAP Learning's material on SAP-RPT-1 describes classification examples such as cost centers or payment terms, and regression examples such as prices and quantities.

#Why you must hold data back

scikit-learn's own documentation calls training and testing on the same data "a methodological mistake". A model that simply repeated the labels it had seen would score perfectly and predict nothing. That is overfitting. The fix is to split the data before training:

flowchart LR
  D[All labelled rows] --> S{Split}
  S -->|75%| T[Training set]
  S -->|25%| X[Test set]
  T --> M[Train model]
  M --> E[Score on test set]
  X --> E

The test set plays the role of the future. You never let the model learn from it. If you use it to pick between many models, it slowly stops being "unseen", so larger projects add a third validation set or use k-fold cross-validation, where the training data is split into k parts and each part takes a turn as the check. The classification topic later in this unit uses this.

#The baseline

Before trusting any score, compute what a trivial predictor gets. scikit-learn provides dummy estimators for this purpose. DummyClassifier(strategy="most_frequent") always predicts the most common label. If your model can't beat it clearly, the model has learned nothing useful, whatever its accuracy says.

This is the same idea as the FDE's "move metric M from X to Y" in What an SAP forward deployed engineer does. The baseline is X.

#Model families and model complexity

A decision tree is a good first family because you can read it. It asks a series of yes/no questions ("is lead time at most 8.5 days?") and ends in an answer. scikit-learn describes trees as a white-box model: you can explain any prediction by following the questions.

Trees also show overfitting clearly. Each extra level of questions lets the tree carve the training data more finely. With no limit, it can put every training row in its own box and score 100% on training data. The scikit-learn documentation warns that over-complex trees "do not generalize the data well" and recommends limiting size with max_depth, starting at 3.

You will see all three rows appear in the script below.

#Build it yourself: rules versus learning on late deliveries

You will compare three ways to flag late deliveries on made-up SAP-shaped data: always guessing, a rule a planner might write, and a decision tree that learns from examples. Then you will make the tree bigger and watch it overfit. It takes one script and about 30 minutes.

Before you start: complete Set up your computer for this course and Set up for Unit 2: data science tools. They give you the orchestrate-course folder, its .venv, and numpy, pandas and scikit-learn. This walkthrough doesn't repeat those steps.

flowchart LR
  G[Make 2,000 made-up deliveries] --> S[Split: learn 75% / test 25%]
  S --> B[Baseline: always 'late']
  S --> R[Rule: lead time up to 5 days]
  S --> T[Learned tree, depth 3]
  B & R & T --> C[Compare accuracy on test rows]
  T --> O[Bigger trees: watch overfitting]
  T --> P[Score two new deliveries]

#What you need

• The course folder and .venv from the two setup topics.
• About 30 minutes. No accounts, no internet after setup, no cost.
• All data is made up. Nothing is sent anywhere.

#Step 1: Open the course folder and turn on the environment

1. Open VS Code, choose File > Open Folder and open orchestrate-course.

2. Open a terminal: Terminal > New Terminal.

3. Turn on the virtual environment if the prompt doesn't start with (.venv):

   • Windows (PowerShell):

     Copy

     .venv\Scripts\Activate.ps1

   • macOS / Linux:

     Copy

     source .venv/bin/activate

4. Go into the Unit 2 folder:

   Copy

   cd unit02

   If it doesn't exist yet, finish Step 5 of the Unit 2 setup topic first.

#Step 2: Save the script

1. In VS Code's file list, right-click unit02, choose New File and name it rules_vs_learning.py.
2. Paste the code below and save (Ctrl+S, or Cmd+S on Mac).

"""Rules versus learning: three ways to flag late deliveries, on made-up SAP-shaped data.

How to run (from the unit02 folder, with the course .venv turned on):
    python rules_vs_learning.py                 # 2,000 made-up deliveries
    python rules_vs_learning.py --rows 300      # fewer rows: watch overfitting get worse
    python rules_vs_learning.py --csv my_deliveries.csv   # use your own sample file

All data is made up. Nothing is sent anywhere.
"""
import argparse
from pathlib import Path

import numpy as np
import pandas as pd
from sklearn.dummy import DummyClassifier
from sklearn.model_selection import train_test_split
from sklearn.tree import DecisionTreeClassifier, export_text

HERE = Path(__file__).parent
PLANTS = ["1010", "1020", "1710"]           # made-up plant codes
CARRIERS = ["ROAD", "RAIL", "EXPRESS"]      # made-up shipping types


def make_deliveries(rows: int, seed: int = 42) -> pd.DataFrame:
    """Same generator as hello_data.py: made-up deliveries with a 'Late' flag."""
    rng = np.random.default_rng(seed)
    df = pd.DataFrame({
        "Delivery": [str(80000000 + i) for i in range(rows)],
        "Plant": rng.choice(PLANTS, size=rows),
        "ShippingType": rng.choice(CARRIERS, size=rows, p=[0.6, 0.3, 0.1]),
        "Items": rng.integers(1, 12, size=rows),
        "WeightKg": rng.gamma(2.0, 150.0, size=rows).round(1),
        "LeadTimeDays": rng.integers(1, 15, size=rows),
    })
    risk = (
        0.25 * df["Items"]
        + 0.004 * df["WeightKg"]
        - 0.35 * df["LeadTimeDays"]
        + np.where(df["Plant"] == "1710", 1.0, 0.0)
        + np.where(df["ShippingType"] == "EXPRESS", -1.5, 0.0)
        + rng.normal(0, 1.0, size=rows)
    )
    df["Late"] = (risk > 0).astype(int)
    return df


def hand_written_rule(df: pd.DataFrame) -> pd.Series:
    """What a planner might write from experience: short lead time means late."""
    return (df["LeadTimeDays"] <= 5).astype(int)


def main() -> None:
    parser = argparse.ArgumentParser(description="Compare a rule, a baseline and learned models.")
    parser.add_argument("--rows", type=int, default=2000, help="how many made-up deliveries")
    parser.add_argument("--csv", help="read deliveries from this CSV instead of making them")
    args = parser.parse_args()

    if args.csv:
        if not (HERE / args.csv).exists():
            parser.error(f"can't find {args.csv} next to this script; run the script that makes it first")
        df = pd.read_csv(HERE / args.csv, dtype={"Delivery": str, "Plant": str, "Customer": str})
    else:
        df = make_deliveries(args.rows)

    # Features (the inputs) and the label (the answer we want to predict).
    label = df["Late"]
    inputs = df.drop(columns=["Delivery", "Late"])
    features = pd.get_dummies(inputs, dtype=int)  # text columns become 0/1 columns

    # Hold back a quarter of the rows as a test set the model never sees in training.
    x_train, x_test, y_train, y_test, _, raw_test = train_test_split(
        features, label, inputs, test_size=0.25, random_state=0, stratify=label
    )
    print(f"{len(df)} deliveries: {len(x_train)} to learn from, {len(x_test)} held back for testing")
    print(f"Share late overall: {label.mean():.2f}\n")

    # 1. Baseline: always predict the most common answer.
    baseline = DummyClassifier(strategy="most_frequent").fit(x_train, y_train)
    base_acc = baseline.score(x_test, y_test)

    # 2. Rules: a person writes the logic.
    rule_acc = (hand_written_rule(raw_test) == y_test).mean()

    # 3. Learning: the computer finds the logic from labelled examples.
    tree = DecisionTreeClassifier(max_depth=3, random_state=0).fit(x_train, y_train)
    tree_acc = tree.score(x_test, y_test)

    always = "late" if baseline.predict(x_test[:1])[0] == 1 else "on time"
    print("Accuracy on the held-back deliveries")
    print(f"  {'Baseline (always ' + repr(always) + ')':<42}{base_acc:.2f}")
    print(f"  {'Hand-written rule (lead time <= 5 days)':<42}{rule_acc:.2f}")
    print(f"  {'Learned decision tree (depth 3)':<42}{tree_acc:.2f}")

    print("\nThe rules the tree learned (read top to bottom):")
    print(export_text(tree, feature_names=list(features.columns), decimals=1))

    # 4. Overfitting: a bigger tree memorises the training rows.
    print("Tree depth vs accuracy (train = rows it learned from, test = held back)")
    print("  depth     train   test")
    for depth in [1, 2, 3, 5, 8, 12, None]:
        model = DecisionTreeClassifier(max_depth=depth, random_state=0).fit(x_train, y_train)
        name = "no limit" if depth is None else str(depth)
        print(f"  {name:<10}{model.score(x_train, y_train):.2f}    {model.score(x_test, y_test):.2f}")

    # 5. Inference: use the learned model on deliveries it has never seen.
    new = pd.DataFrame({
        "Plant": ["1710", "1010"], "ShippingType": ["ROAD", "EXPRESS"],
        "Items": [9, 2], "WeightKg": [620.0, 80.0], "LeadTimeDays": [3, 12],
    })
    new_features = pd.get_dummies(new, dtype=int).reindex(columns=features.columns, fill_value=0)
    chance = tree.predict_proba(new_features)[:, 1]
    print("\nTwo new deliveries, scored by the depth-3 tree")
    for (_, row), p in zip(new.iterrows(), chance):
        print(f"  Plant {row.Plant}, {row.ShippingType + ',':<8} {row.Items:>2} items, "
              f"{row.WeightKg:>5.0f} kg, {row.LeadTimeDays:>2} days lead time -> chance late {p:.2f}")


if __name__ == "__main__":
    main()

#Step 3: Run it

In the terminal, still inside unit02, run:

python rules_vs_learning.py

What success looks like (the tree printout is shortened here; yours shows all of it):

2000 deliveries: 1500 to learn from, 500 held back for testing
Share late overall: 0.53

Accuracy on the held-back deliveries
  Baseline (always 'late')                  0.53
  Hand-written rule (lead time <= 5 days)   0.68
  Learned decision tree (depth 3)           0.76

The rules the tree learned (read top to bottom):
|--- LeadTimeDays <= 8.5
|   |--- Items <= 3.5
|   |   |--- WeightKg <= 423.6
|   |   |   |--- class: 0
|   |   |--- WeightKg >  423.6
|   |   |   |--- class: 1
...

Tree depth vs accuracy (train = rows it learned from, test = held back)
  depth     train   test
  1         0.76    0.74
  2         0.77    0.76
  3         0.81    0.76
  5         0.84    0.80
  8         0.92    0.82
  12        0.98    0.79
  no limit  1.00    0.80

Two new deliveries, scored by the depth-3 tree
  Plant 1710, ROAD,     9 items,   620 kg,  3 days lead time -> chance late 0.95
  Plant 1010, EXPRESS,  2 items,    80 kg, 12 days lead time -> chance late 0.05

Your numbers should match, because the data comes from a fixed random seed. A different last decimal is fine; library versions can cause that.

#Step 4: Read the results

Take the output one block at a time.

1. Baseline, 0.53. Just over half the made-up deliveries are late, so "always late" is right 53% of the time. Anything worth using must beat this clearly.
2. Rule, 0.68. The planner's rule is much better than guessing. Rules are not stupid; they capture real knowledge.
3. Tree, 0.76. The learned tree beats the rule. Read its printout: the first question it learned is "lead time at most 8.5 days?". The planner's instinct about lead time was right, but the data puts the line at a different place, and the tree adds weight and item count.
4. Some branches end in the same class on both sides. That is normal. The tree splits where it makes the groups purer, even if both groups still lean the same way.
5. Depth table. Training accuracy climbs steadily to 1.00. Test accuracy rises, peaks around depth 8, then slips. The gap between the two columns is the overfitting you read about. The "no limit" tree is perfect on data it has seen and worse than depth 8 on data it hasn't.
6. Two new deliveries. This is inference. A heavy, many-item delivery from plant 1710 with three days' lead time gets 0.95. A small express delivery with twelve days gets 0.05. The number is the share of late deliveries in the training rows that ended in the same leaf of the tree, so treat it as a rough score, not a calibrated probability. The classification topic later in this unit deals with that.

#Step 5: Watch overfitting get worse with less data

Run it again with far fewer deliveries:

python rules_vs_learning.py --rows 300

Look at the depth table near the end:

Tree depth vs accuracy (train = rows it learned from, test = held back)
  depth     train   test
  1         0.76    0.75
  2         0.78    0.76
  3         0.82    0.75
  5         0.89    0.67
  8         0.98    0.71
  12        1.00    0.71
  no limit  1.00    0.71

With only 225 rows to learn from, the bigger trees memorize almost at once, and their test scores fall well below the small trees. This is why small datasets call for simple models, and why "how many examples do we have?" is the first question in the foundational layer.

#Step 6 (optional): Use your own sample data

If you did the exercise in the Unit 2 setup topic, you have my_deliveries.csv with an extra Customer column. Run:

python rules_vs_learning.py --csv my_deliveries.csv

If the customer you made "more often late" matters, it appears in the tree printout as a column such as Customer_17100003. You didn't tell the model about that customer; it found it in the examples.

#Step 7: Save your work in Git

From the course folder:

cd ..
git add unit02/rules_vs_learning.py
git commit -m "Compare rules and a learned tree on sample deliveries"

#What each part of the script does

#If something goes wrong

#Where this shows up in SAP

Unit 2 is a maths-and-mechanics unit, so this section is shorter. The point is that everything you just did has an SAP counterpart.

#Embedded: inside S/4HANA

SAP Learning describes embedded machine learning as running in the same stack as S/4HANA, using two SAP HANA libraries: the Automated Predictive Library (APL), aimed at business analysts, and the Predictive Analysis Library (PAL), with algorithms for data scientists. The model trains and predicts inside the database, next to the data.

These scenarios are run through Intelligent Scenario Lifecycle Management (ISLM). SAP's ISLM topic page names two Fiori apps: Intelligent Scenarios, to see and create custom scenarios, and Intelligent Scenario Management, to manage both custom and SAP-shipped ones. That is where the same lifecycle you practised (train, check, use for prediction) is run in a live system. SAP also describes a predictive delivery delays capability for S/4HANA, which is this topic's running example in product form.

#Side-by-side: on SAP BTP

For work that needs heavier models, such as images, sentiment or deep learning, SAP Learning describes a side-by-side setup: the model runs on SAP BTP, for example in SAP AI Core, and S/4HANA calls it. ISLM can also manage side-by-side scenarios. Unit 3 sets up BTP; AI Core access comes in Unit 5.

#Pre-trained for tables: SAP-RPT-1

As of September 2026, SAP offers SAP-RPT-1, which it describes as a relational pretrained model for predictions on structured business data. According to SAP's product page and SAP Learning:

• It handles classification and regression, the same two supervised tasks in the table above.
• It uses in-context learning: you send example rows with known answers along with the rows to predict, and it returns predictions without a separate training step.
• It is offered in small and large versions through SAP AI Core, with a free playground for trying it, and an open-source variant for non-commercial research.
• SAP's Architecture Center lists it as generally available, deployed through SAP AI Core; commercial use needs AI Core's extended plan.

That changes who trains the model, not the rules of the game. You still need labelled examples, a held-back test set and a baseline to know whether its predictions help. The classification and late-delivery topics later in this unit give you the tools to judge any of these options on equal terms.

#Production concerns

• Time-based testing. Test on the latest period, not random rows. Deliveries from next month are what the model will face.
• Leakage. Never use a column that is only known after the fact. A goods-issue date that is later than planned already tells you the delivery was late. A model with such a feature looks brilliant in testing and is useless in real use.
• Drift. Carriers, plants and customers change. Track the model's accuracy on new data every month and compare with the baseline. Plan who retrains it.
• Authorizations. Training data pulled from S/4HANA must respect the same access rules as the source. Extracting delivery data for a notebook is still extracting customer data.
• Explainability. A planner will ask "why is this one flagged?". Simple models such as small trees can answer directly; complex ones need extra tooling to explain their answers.
• Clean core. Custom models should live beside S/4HANA or in the standard ISLM framework, not in modified standard code.

#Pitfalls

• Scoring on training data. The "no limit" tree scored 1.00 there. That number means nothing.
• Skipping the baseline. Accuracy without a baseline hides useless models, especially when one answer dominates.
• Tuning on the test set. If you try twenty depths and keep the best test score, the test set is no longer unseen. Use a validation set or cross-validation for choices.
• Treating codes as numbers. Plant 1710 is not "bigger" than plant 1010. Turn codes into one-hot columns, as the script does.
• Trusting the score as a probability. A tree's leaf share is a rough score. Calibration comes later in this unit.
• Believing the tree's rule is the truth. It is the pattern in these examples. With other examples, the split points move.

#Exercise: find the right size of tree

You will add a validation check to choose the tree depth without touching the test set, then write down what you found. The output feeds the late-delivery prediction topic at the end of this unit.

1. Copy rules_vs_learning.py to choose_depth.py in unit02.

2. At the top, add this import below the other sklearn imports:

   Copy

   from sklearn.model_selection import cross_val_score

3. In the depth loop, after model = ..., add a line that computes the average 5-fold cross-validation accuracy on the training rows only:

   Copy

       cv = cross_val_score(DecisionTreeClassifier(max_depth=depth, random_state=0), x_train, y_train, cv=5).mean()

4. Change the print line in the loop so it also shows cv, for example f" {name:<10}{model.score(x_train, y_train):.2f} {cv:.2f} {model.score(x_test, y_test):.2f}", and add cv to the header line.

5. Run python choose_depth.py and python choose_depth.py --rows 300.

6. For each run, pick the depth with the best cv column; if two tie, pick the smaller tree. Then look at its test score.

7. Create unit02/notes_ml_plain_terms.md and write four lines: the baseline accuracy, the rule accuracy, the depth you chose and why, and that depth's test accuracy, for each run.

8. Save your work:

   Copy

   git add unit02/choose_depth.py unit02/notes_ml_plain_terms.md
   git commit -m "Choose tree depth with cross-validation"

Done when: choose_depth.py prints a table with train, cv and test columns for both runs; your notes name a depth chosen from the cv column, not the test column; and git log shows the commit.

#Check yourself