Start / Seminare / Microsoft Copilot Studio in der Praxis

Modul

Unternehmenswissen erschließen

Modul 3 von 11 aus dem Seminar Microsoft Copilot Studio in der Praxis

5 Kapitel in diesem Modul-Video · Laufzeit

Für Teams

Die Videos zeigen, wie es geht. Die Schulung sorgt dafür, dass Ihr Team es danach tut.

Ein Video kann niemanden fragen, warum es ausgerechnet in Ihrem Repository nicht funktioniert. Es kann kein Team auf eine gemeinsame Konvention bringen. Und es setzt sich niemand freiwillig drei Tage hin. In der Schulung sind am Ende alle auf demselben Stand, gearbeitet wurde am eigenen Code, und die offenen Fragen sind entschieden — in ein paar Tagen statt irgendwann nebenbei.

Vorgespräch am Telefon · Programm nach Maß · ab 1 Tag (8 Unterrichtseinheiten) · Teilnahmezertifikat

Schulung anfragen So läuft eine Schulung ab

Vertonung mit synthetischer Stimme · Inhalte redaktionell verantwortet · © 2026 HECKER CONSULTING, alle Rechte vorbehalten

Transkript

Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.

Unternehmenswissen erschließen

0:00 Jetzt wird es konkret. Ein Agent antwortet nicht aus dem Nichts, sondern aus dem, was Sie ihm geben — Dokumente, Seiten, Listen. Und damit verschiebt sich die Arbeit an eine Stelle, mit der im Projektplan selten jemand rechnet: in die Pflege der Inhalte. Wer ein aufgeräumtes Intranet hat, ist an diesem Tag schnell fertig.

0:19 Wer drei Fassungen desselben Ablaufplans in vier Ordnern liegen hat, lernt heute, warum der Agent ständig etwas anderes sagt. Schauen wir uns an, welche Quellen es gibt, was Berechtigungen wirklich leisten — und wo die Grenze zum Fachsystem verläuft.

Unternehmenswissen erschließen

0:35 Der zweite Tag beginnt mit den Wissensquellen: welche es gibt, welche Grenzen gelten und wovon die Auswahl abhängt. Danach geht es um Qualität, Aktualität und Berechtigungen — mit einer Überraschung bei verschlüsselten Dateien. Im dritten Kapitel testen wir gezielt das, was ein Agent gerade nicht beantworten kann. Und zum Schluss ziehen wir eine Linie, die sich durch das ganze Seminar zieht: Was gehört in eine Wissensquelle, und was kann nur das Fachsystem beantworten?

Wissensquellen auswählen

1:02 Fangen wir mit dem Überblick an. Fünf Arten von Quellen stehen zur Verfügung, und sie unterscheiden sich in einem Punkt, der später viel Ärger erspart. Der Fachbegriff dafür ist Erdung: Die Antworten des Agenten bekommen Bodenhaftung, weil sie sich auf Ihre Daten stützen statt auf das allgemeine Wissen des Modells. Fünf Quellenarten stehen bereit — öffentliche Websites, in Dataverse hochgeladene Dokumente, SharePoint, Dataverse selbst und Unternehmensdaten über Konnektoren.

1:30 Welche Grenzen dabei gelten, hängt allerdings vom Orchestrierungsmodus ab. Das ist typisch für dieses Produkt: Viele Angaben gelten nicht absolut, sondern je nach Betriebsart. Merken Sie sich diese Abhängigkeit, sie begegnet uns heute noch mehrfach. Statt die Zahlen abzulesen, achten Sie auf die dritte Spalte. Dort steht das eigentlich Wichtige: Bei SharePoint, Dataverse und Konnektoren wird mit der Identität der fragenden Person gearbeitet.

1:56 Der Agent sieht also nur, was diese Person ohnehin sehen dürfte — eine sehr beruhigende Eigenschaft, die man sich aber nicht kaputtkonfigurieren sollte. Bei öffentlichen Websites und hochgeladenen Dokumenten gibt es diesen Schutz nicht, dort zählt allein, was Sie hineingelegt haben. Und die Fußnote zeigt, dass auch Quellen ausgewählt werden: Ab mehr als 25 filtert ein internes Modell vor.

2:19 Hier steckt die eigentliche Botschaft des Kapitels: Die Wahl der Quelle ist keine technische Fingerübung, sondern eine fachliche Entscheidung. Eine SharePoint-Quelle bringt Berechtigungen mit — das ist ein Geschenk. Eine öffentliche Website hängt am Bing-Index, mit allem, was das an Verzögerung bedeutet. Dataverse und Konnektoren liefern strukturierte Daten statt Fließtext, und hochgeladene Dokumente altern still vor sich hin. Sie werden nirgends automatisch erneuert.

2:47 Wer das weiß, legt Verantwortlichkeiten fest, statt sich später zu wundern. Der erste Punkt ist der bequemste und zugleich riskanteste: den ganzen SharePoint anbinden, weil Auswählen Arbeit macht. Der zweite überrascht regelmäßig — Verknüpfungen innerhalb eines Dokuments werden nicht verfolgt. Was verlinkt ist, muss selbst als Quelle registriert sein, sonst existiert es für den Agenten nicht.

3:10 Der dritte ist ein stiller Ausfall: Ein umbenannter Ordner bricht den Quellenlink, und der Agent schweigt plötzlich zu einem Thema, das er gestern konnte. Und der vierte betrifft die Modusabhängigkeit, die wir eben angesprochen haben.

Qualität, Aktualität und Berechtigungen

3:24 Kommen wir zu den Berechtigungen — und zu der Stelle, an der sie an ihre Grenze stoßen. Das ist eine der praktischsten Erkenntnisse dieses Tages. Beim SharePoint-Wissen arbeitet der Agent im Namen der angemeldeten Person. Was diese nicht lesen darf, taucht auch nicht auf — mindestens Leserecht muss bestehen. Sogar Vertraulichkeitsbezeichnungen werden berücksichtigt.

3:47 Klingt lückenlos, hat aber eine Ausnahme, die man kennen muss: Verschlüsselte Dateien bleiben außen vor, auch wenn die Person sie problemlos öffnen könnte. Der Agent kann den Inhalt schlicht nicht heranziehen. Und das Tückische daran: Die Datei wird trotzdem als bereit angezeigt. Diese Kette erklärt eine der verwirrendsten Situationen im Betrieb. Die Datei ist registriert — Haken. Das Recht ist geprüft und vorhanden — Haken.

4:13 Und trotzdem kommt keine Antwort, weil der Schutz den Inhalt verschlüsselt. Für die nutzende Person sieht das exakt aus wie „gibt es nicht". Wenn Sie also im Test auf ein Dokument stoßen, das partout keine Antwort liefert, obwohl alles zu stimmen scheint: Prüfen Sie diesen Weg von hinten. Das spart Stunden. Hier die unbequeme Wahrheit dieses Moduls: Die Qualität Ihrer Dokumente wird zur Qualität Ihres Agenten.

4:39 Zwei Fassungen erzeugen zwei Antworten, und der Agent kann nicht wissen, welche gilt. Ein Dokument ohne Datum macht es unmöglich, das Alter einer Auskunft einzuschätzen. Der letzte Punkt ist organisatorisch der wichtigste: Wer die Quelle pflegt, verantwortet faktisch die Antworten. Das sollte diese Person wissen — und möglichst zugestimmt haben.

5:00 Diese fünf Schritte sind unspektakulär und genau deshalb wirksam. Erst benennen, was wirklich gebraucht wird — nicht alles, was zum Thema existiert. Dann aufräumen, und zwar wirklich entfernen statt umbenennen; eine alte Fassung mit neuem Namen bleibt eine alte Fassung. Danach Verantwortliche und Prüfdatum festlegen. Der vierte Schritt ist der, den fast alle falsch machen: Berechtigungen aus Sicht der Zielgruppe prüfen, nicht aus der eigenen.

5:27 Und zum Schluss Name und Beschreibung — die steuern im generativen Modus, ob die Quelle überhaupt gefragt wird. Der erste Punkt ist der Test mit dem falschen Konto. Ein Maker sieht mehr als die Zielgruppe, und deshalb funktioniert im Test alles wunderbar. Der zweite ist die verschlüsselte Datei von eben. Der dritte betrifft eine Einstellung auf Tenant-Ebene, die einem den Tag verderben kann: Ist die eingeschränkte SharePoint-Suche aktiv, ist die Nutzung von SharePoint blockiert — daran ändert keine noch so gute Konfiguration etwas.

5:58 Und der vierte ist der schleichende: Niemand pflegt, also altert die Quelle unbemerkt.

Generative Antworten gezielt testen

6:03 Jetzt testen wir. Und zwar nicht das, was funktioniert — sondern gezielt das, wovon wir hoffen, dass der Agent es ehrlich zugibt. Eine Einstellung ist hier entscheidend: Darf der Agent aus dem allgemeinen Wissen des Modells antworten, oder nicht? Steht sie auf Nein, passiert etwas Überraschendes. Der Agent gibt eine Antwort aus Ihren Quellen nur dann aus, wenn sie eine Quellenangabe im Text trägt.

6:28 Fehlt die Angabe — was Modelle gelegentlich vergessen —, hält er die fertige, korrekte Antwort zurück und wirkt ahnungslos. Das ist kein Fehler, sondern gewollte Strenge. Man sollte es nur wissen, sonst sucht man an der falschen Stelle. Die Logik dieser fünf Zeilen: Nur die erste prüft, ob der Agent etwas kann. Die übrigen vier prüfen, ob er ehrlich ist. Das ist die eigentliche Qualität eines Wissensagenten.

6:53 Besonders die dritte Zeile lohnt Aufmerksamkeit — legen Sie ihm bewusst zwei widersprüchliche Dokumente vor und sehen Sie zu, welcher Fassung er folgt. Und die Fußnote ist der unangenehme Teil: Dieselbe Frage kann unterschiedlich ausgehen. Ein einzelner Durchlauf ist deshalb noch kein Beweis. Vier Gründe, warum zweimal dieselbe Frage zweimal anders ausgehen kann. Der erste ist der wichtigste: Der Agent nutzt den bisherigen Gesprächsverlauf.

7:20 Eine Folgefrage kann er aus dem Kontext beantworten, ohne eine Quelle aufzurufen — und dann wird die Antwort blockiert, obwohl sie stimmt. Die anderen drei betreffen die Darstellung: In Teams gibt es höchstens zwanzig Quellenangaben, Titel werden gekürzt, und wer die Ausgabe selbst gestaltet, muss die Belege selbst einbauen.

7:38 Sonst verschwinden sie stillschweigend. Der erste Punkt ist menschlich: Man testet, was klappt. Es ist unangenehm, gezielt nach Lücken zu suchen — genau deshalb tut es sonst niemand. Der zweite ist das Einzelergebnis, das als Beweis gilt. Der dritte ist der Zusammenhang aus Modul 2: ein starres Ausgabeformat, das die Quellenangabe unterdrückt.

8:00 Und der vierte ist eine Einstellung, die einfach stehen bleibt — ungegründete Antworten sind erlaubt, aber niemand hat das entschieden. Solche stillen Voreinstellungen sind gefährlicher als falsche Entscheidungen, weil sie nie diskutiert wurden.

Wissensquelle oder Fachsystem

8:15 Zum Abschluss des Kapitels eine Unterscheidung, die simpel klingt und in Projekten trotzdem ständig verwischt wird. Sie entscheidet darüber, ob eine Auskunft heute noch stimmt oder von letztem Jahr ist. Es ist der Unterschied zwischen einem Handbuch und einem Anruf in der Fachabteilung. Das Handbuch sagt Ihnen, wie ein Vorgang abläuft.

8:34 Ob Ihr Vorgang gerade in Prüfung ist, steht dort nicht — und wird dort auch nie stehen. Für solche Auskünfte braucht der Agent ein Werkzeug oder einen Agent Flow, also morgen unser Thema. Und die Entscheidung fällt nicht einmal für den ganzen Agenten, sondern für jede einzelne Frage. Ein Agent kann beides — er muss nur wissen, wann er was benutzt.

8:55 Die Gegenüberstellung zeigt vier Unterschiede, aber achten Sie besonders auf die letzte Zeile — den Beleg. Bei der Wissensquelle ist es die Quellenangabe, bei der Systemabfrage der Rückgabewert. Beides sind Belege, nur verschiedener Art. Und daraus folgt eine praktische Regel: Wenn Sie in einer Antwort nicht erkennen können, welcher der beiden Wege sie erzeugt hat, dann kann es der nutzenden Person erst recht nicht gelingen.

9:20 Machen Sie die Herkunft sichtbar. Der Kern steht im ersten Punkt: Eine veraltete Zahl aus einem Dokument wirkt genauso verbindlich wie eine aktuelle aus dem System. Nichts an der Antwort verrät den Unterschied. Menschen handeln danach — melden an, planen Budgets, geben Auskunft weiter. Und wenn sich das als falsch herausstellt, leidet nicht das Dokument, sondern der Agent.

9:43 Deshalb: Zahlen, die sich ändern, gehören nicht in Dokumente, die der Agent liest. Auch wenn es kurzfristig der bequemere Weg wäre. Der erste Punkt ist genau diese Bequemlichkeit — Zahlen im Dokument, weil eine Schnittstelle aufwendig schien. Der zweite betrifft undatierte Quellen, bei denen niemand den Stand kennt. Der dritte ist ein Missverständnis, das regelmäßig auftritt: Eine SharePoint-Liste ist eine Wissensquelle, keine Datenbank.

10:10 Und daran schließt der vierte an, mit einer konkreten Zahl: Listen mit mehr als 35.000 Zeilen drücken Antwortqualität und Geschwindigkeit. Wer solche Mengen hat, braucht ein Fachsystem, keine Liste.

Übung

10:23 Genug Theorie. Binden wir echtes Material an — und zwar bewusst unaufgeräumtes. Denn ein sauber vorbereiteter Testbestand würde Ihnen genau das verschweigen, worauf es im eigenen Haus ankommt. Im SharePoint-Bereich Weiterbildung der Ankerfeld GmbH liegt genau die Mischung, die man in der Wirklichkeit findet: Formatbeschreibungen, eine Teilnahmerichtlinie, zwei Fassungen eines Ablaufplans und eine Übersicht aus dem Vorjahr.

10:49 Nichts davon ist kaputt, und trotzdem steckt in jeder Datei eine Falle — eine veraltet, zwei widersprechen sich, eine ist unvollständig. Genau damit muss der Lernlotse zurechtkommen. Ein aufgeräumter Testbestand würde Ihnen heute nichts beibringen. Das Lernziel lautet: gegen einen vorbereiteten Erwartungshorizont prüfen, nicht gegen den Eindruck.

11:10 Deshalb steht im Erfolgskriterium, dass zu jeder der zwölf Fragen die erwartete, die tatsächliche und die bewertete Antwort vorliegen muss — samt Ursache jeder Abweichung. Und mindestens drei Fragen müssen unbeantwortbar sein. Die prüfen nämlich das, was Sie im Betrieb am meisten interessieren wird: das Verhalten im Zweifel.

11:30 Beachten Sie die Reihenfolge: Die erwarteten Antworten werden vorher notiert, nicht nachher. Alles andere wäre Selbstbestätigung. Der erste Schritt umfasst Name und Beschreibung der Quelle — nehmen Sie sich dafür wirklich zwei Minuten, das zahlt sich morgen aus. Dann der Katalog mit seinen drei unbeantwortbaren und zwei widersprüchlichen Fragen. Und der letzte Schritt ist der anspruchsvollste: jede Abweichung auf eine Ursache zurückführen.

11:56 Vier kommen infrage — Dokument, Recht, Beschreibung oder fehlendes Fachsystem. Der erste Punkt kostet Sie sofort Qualität: leere Beschreibung, und die Auswahl wird zum Zufall. Der zweite ist der Test mit dem Maker-Konto — dann fallen Berechtigungsfehler schlicht nicht auf. Der dritte ist der halbe Weg: Abweichungen notieren, aber nicht erklären.

12:17 Eine Liste von Fehlern ohne Ursachen hilft niemandem. Und der vierte ist die verschobene Aufräumarbeit — die widersprüchlichen Fassungen bleiben liegen, weil das Aufräumen jemand anderen braucht. Im nächsten Modul bauen wir das Gespräch selbst — Topics, Fragen und Fehlerpfade.

Dieses Modul als Schulung für Ihr Team

Das Video zeigt den Stoff. In der Schulung arbeitet Ihr Team damit — an Ihrem eigenen Code, mit Übungen und mit den Fragen, die ein Video nicht beantwortet. Sie wählen die Module aus Microsoft Copilot Studio in der Praxis, wir bauen daraus ein Programm.

5 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung

Als Team-Schulung anfragenWie eine Schulung abläuft →