Speaker 1Willkommen beim Podcast AI und Du, Co-Pilot mit Microsoft 365. Eure Hosts sind Adrian und Thorsten. Los geht's.
Speaker 2Hallo und herzlich willkommen zu einer neuen Ausgabe des, meine Güte, wir gehen die Superlativen aus, des Superlativen Podcasts AI und Du. Co-Pilot in Microsoft 365. Wie immer, mein Name ist Thorsten Pickern, bin ich nicht allein hier, denn ich bin ja nur noch der Co-Host, Co-Horst, der Co-Host. Natürlich wird das ganze Projekt hier getragen und mitgenommen und ich werde mitgezogen von meinem lieben Kollegen. Wer ist denn da auf der anderen Seite des virtuellen Studios?
Speaker 1Überraschenderweise der Adrian, verrückt. Adrian, du schon wieder. Ja, Superlativen finde ich großartig.
Speaker 2Schon, ne? Also ich wollte den Co-Pilot mal fragen, wie ich das Intro einabwechselnder mache, aber ich finde, es passt nach wie vor sehr gut. Ja, ja. Adrian, vor ein paar Wochen hatten wir schon mal über Co-Pilot in SharePoint gesprochen, wenn ich mich recht entsinne. Und da hatten wir schon mal so ein Thema, das... Ich weiß gar nicht, letztes Mal hatten wir eher darüber gesprochen, wie der Endanwender Co-Pilot im SharePoint-Umfeld nutzen kann, um sich ein FAQ zu erstellen, um neuerdings Metadaten zu befüllen. Das war damals, glaube ich, noch gar nicht möglich, als wir es gemacht haben oder noch in der sehr frühen Stage irgendwie. Also da war es sehr User-zentrisch, wenig automatisiert. Und wir hatten damals schon geteasert, es gibt noch eine weitere Funktion des Co-Piloten in SharePoint. Und das wollen wir in einer anderen Folge besprechen. Und jetzt Spannungsbogen. Was machen wir denn heute, Adrian? Ich glaube, wir sind bei dieser Folge angekommen.
Speaker 1Und ja, beschäftigen uns mal mit dem Thema Skills in SharePoint. Und ja, ich glaube, der Nachsatz in SharePoint ist wichtig, denn Skills ist ja jetzt auch vielleicht so für den Einstieg auch keine Sache, die jetzt nur in SharePoint existiert. Oder SharePoint ja exklusiv ist, sondern das ist ein Thema, das kennen die, die sich vielleicht auch schon mal mit Cloud beschäftigt haben, kennen das Thema da wahrscheinlich her.
Speaker 2Oder die sich die letzte Folge von unserem Podcast angeheuert haben, wo wir über Cloud gesprochen hatten.
Speaker 1Genau, auch über Co-Work. Und ja, und diese Skills sind tatsächlich die gleichen. Also man kann diese Skills auch im SharePoint verwenden. Man müsste die ein bisschen anpassen. Da wollen wir jetzt nicht so viel tief drauf einsteigen. Aber ganz grundsätzlich sind das tatsächlich die gleichen Skills, von denen wir sprechen. Und ja, aber was heißt das jetzt eigentlich? Also Skills, Fähigkeiten im SharePoint mit Co-Pilot klingt ja so ein bisschen so, als würden wir damit Co-Pilot was Neues beibringen, oder?
Speaker 2So in etwa. Also was wir eben machen können, ist, dass wir Co-Pilot in SharePoint nutzen können, um ein wiederverwendbares Rezept für Co-Pilot in SharePoint zu definieren. In unserer Sprache. Also prüfe alle Dokumente in dieser Dokumentenbibliothek auf Vollständigkeit der Rechnungsdaten. Oder irgendwie sowas in der Richtung. Das können wir dem Co-Pilot mitgeben. Und daraus baut Co-Pilot ja ein Skill. Wo der gespeichert wird, wie der gespeichert wird, gehen wir gleich drauf ein. Und das Schöne an diesem Skill ist, dass wir das dann immer wieder entsprechend aufrufen können. Das heißt, das ist eben nicht ein One-Hit-Wonder, sondern im Best Case können wir das einmal die Woche ausführen. Und bekommen darüber ja Organisation in unserer SharePoint-Dokumentenbibliothek den aktuellsten Stand zu. Eine aktuelle FAQ. Was auch immer wir erreichen wollen. Auch dafür haben wir vielleicht nachher noch ein paar Ideen zu einem Use Case oder zwei, drei Use Cases, die man dort ganz gut einsetzen kann. War das so richtig umschrieben als ich alter SharePoint-Skills, nicht so Deep Dive-Techniker?
Speaker 1Ja, ich glaube, das klingt ziemlich gut. Und wer jetzt schon länger beim Co-Pilot-Game oder beim KI-Game dabei ist, Wer jetzt schon länger beim Co-Pilot-Game oder beim KI-Game dabei ist, und sich das so anhört, der wird sich denken, naja, aber das, was du da gerade beschrieben hast, das könnte ja auch ein Agent sein. Warum muss das jetzt ein Skill sein? Also gerade Stichwort, wiederverwendbare Prompts, haben wir ja sonst auch gerne mal gesagt, okay, dann ist das vielleicht ein Fall für einen ganz einfachen Agent. Also wenn wir nochmal vielleicht so diese uns in Erinnerung rufen, wie man seine Arbeit mit Prompts organisieren kann. Also ja, ich könnte ihn irgendwie in OneNote speichern. Und immer wieder rausholen, wenn ich ihn brauche, also wenn ich einen guten Prompt habe. Ich könnte mir den als Bookmark speichern. Die Möglichkeit haben wir ja auch. Das hätte den Vorteil, dass ich ihn dann halt auch leicht mit Kollegen teilen kann und so halt vielleicht auch noch ein bisschen für anderen Mehrwert entsteht. Oder ich baue halt einen Agent, den ich halt selber verwende oder den ich halt auch mit anderen teilen kann. Und der auch größtenteils jetzt, sag ich mal, auf so einem Prompt basiert. Also ja, natürlich gibt es deutlich komplexere... Aber wenn man dann in das Thema einsteigt, wäre das ja vielleicht so ein erster Ansatz. Ich habe einen Prompt, den ich an meiner Woche ausführe. Warum baue ich mir da nicht einen Agent drauf? Und ja, jetzt kommen wir mit einem Skill um die Ecke. Und man kann natürlich die Frage stellen, warum denn jetzt einen Skill und nicht einen Agent? Und ich glaube so, für mich ist so dieser Unterschied im Sharepoint ist, dass es halt nochmal anders integriert ist. Also bei einem Agent muss ich ja wissen, welchen Agent ich anspreche. Und wenn man sich jetzt halt einen Skill anschaut, dann ist es halt so, dass wenn wir den mithilfe von Copilot erzeugen, dass dann halt Copilot ja auch da drin beschreibt, also aufgrund unserer Anforderungen, was wir denn haben wollen, wofür dieser Skill verwendet werden soll. Und das wiederum kann dazu führen, dass der Copilot-Chat im Sharepoint automatisch erkennt, wann denn jetzt so ein Skill eingesetzt werden sollte. Das bedeutet, man kann den nicht nur explizit ausführen, weil man weiß, wie der Skill heißt. Nehmen wir mal da ein Beispiel mit Rechnung auf Vollständigkeit prüfen. Nehmen wir mal an, der Skill heißt Rechnung prüfen oder formale Rechnung prüfen oder irgendwie sowas in der Richtung. Dann kann ich natürlich sagen, führe auf das Dokument den Skill Rechnung prüfen aus. Und dann wird Copilot den Skill auspacken und das tun, was darin definiert ist. Aber ich könnte genauso gut schreiben. Copilot. In der Dokumentenbibliothek eine neue Rechnung und die muss geprüft werden. Kannst du mir dabei helfen? Und aller Wahrscheinlichkeit nach wird dann halt Copilot erkennen, hey, dafür Rechnung prüfen. Stichwort, habe ich einen Skill und den setze ich doch jetzt mal dafür ein.
Speaker 2Ah, okay. Also ist das dann am Ende des Tages auch wieder eine sehr gute Analogie zu den Skills, die wir aus Coburg oder aus Cloud oder aus Scout, wo wir schon gesprochen haben, kennen. Nämlich in dem Augenblick, wo ich sage, ich will eben eine PowerPoint zum TMXY, lädt eben Coburg, schräger Scout, schräger Cloud, das Skill für PowerPoint nach, um dann entsprechend eine PowerPoint zu bauen, sage ich, erstelle mir eine Word-Datei, dann wird das Skill Word geladen, um die Datei zu erzeugen. Habe ich irgendeinen Customized-Skill, irgendeine Fähigkeit, die eben so im Default nicht da ist und ich umschreibe es, dann will er diese Skill nachladen und das haben wir jetzt im, oder das bekommen wir mit SharePoint-Skills in ähnlicher Natur, dass der User gar nicht wissen muss, da existiert ein Skill, sondern er sagt einfach, ich bitte prüfe die letzten fünf Dokumente auf formale Richtigkeit in Form der Rechnung und dann weiß SharePoint bzw. die Co-Pilot-Integration, Mensch, da hat der Adrian mal einen Skill zugebaut, das wenden wir jetzt an und dann ist es auch formell so geprüft, wie Adrian als Leiter der Buchhaltung das haben möchte.
Speaker 1Ja, genau, also klar, so ein PowerPoint-Skill ist, sicherlich komplexer als jetzt... Das ist ja rein von der Person her oder was passiert. Genau, also nicht, dass er jetzt draußen denkt, dass man halt einfach irgendwie Co-Pilot prompten kann, hey, ich hätte gerne einen Skill, der mir, weiß ich nicht, irgendwelche technischen Zeichnungen in AutoCAD automatisch erstellt. Also ja, sowas wird sicherlich möglich sein, aber das ist jetzt halt noch nicht so die Idee in einem ersten Schritt, sondern da geht es halt wirklich um inhaltliche Prüfung, zum Beispiel von Dokumenten oder was man auch machen kann. Tatsächlich, ja, es geht schon ein Stück darüber hinaus, finde ich auch sehr cool. Wir haben ja Möglichkeiten, in SharePoint-Dokumentenbibliotheken die Formatierung so ein bisschen anzupassen mithilfe von JSON und dass dann halt da bedingte Formatierung eingeführt wird oder so. Und dann könnte man halt auch gleichzeitig dem Skill beibringen, dass er halt, falls das noch nicht der Fall ist in der Dokumentenbibliothek, zum Beispiel ein Conditional Formatting einführt. dass halt unvollständige Rechnungen orange angezeigt werden oder so. Also dass halt eben auch tatsächlich Änderungen an dem Speicherort vorgenommen werden und nicht nur inhaltlich ein Dokument geprüft wird. Also sowas geht natürlich schon. Da verwendet dann halt Copilot im Hintergrund die Fähigkeiten oder die Skills, die sowieso schon da sind. Und das funktioniert natürlich schon und hängt halt davon ab, wie man das promptet, wie man Copilot eben darum bittet, diesen Skill zu erstellen. Und wenn wir jetzt so ein bisschen in die technische Richtung gucken, dann hängt das Ganze natürlich erstmal primär davon ab, dass all diese Informationen natürlich auch in SharePoint vorhanden sein müssen, also die ich verwende. Das ist halt in erster Linie ein Skill für Copilot im SharePoint und nicht irgendwo anders. Und außerdem gilt halt auch so alles, was sowieso für Copilot gilt. Also was Berechtigungen anbelangt, was die ganze Compliance- und Governance-Thematik anbelangt. Wenn wir uns fragen, auf was darf denn dann so ein Skill überhaupt zugreifen? Naja, der darf auf das zugreifen, auf das ich halt auch zugreifen kann, wenn ich mit Copilot in einer SharePoint-Site-Collection interagiere.
Speaker 2Ja, das heißt, ich habe logischerweise keinen Zugriff auf die Dokumente oder Ordner innerhalb einer Site, auf die ich selber keinen Zugriff hätte und habe eben alles im Rahmen meiner M365-Boundaries. Das heißt, das Skill oder der Copilot interagiert in dem Augenblick im Namen meines oder, nutzt meinen User-Kontext, um die entsprechenden Dokumente zu finden. Ja, sehr wichtig.
Speaker 1Genau. Und genau das gilt dann halt eben auch für die Governance, für das Erstellen beispielsweise von Skills. Wenn wir uns anschauen, wo wird denn jetzt so ein Skill gespeichert? Naja, der wird halt in einer Dokumentenbibliothek in der Site-Collection gespeichert. Da meine ich auch im Unterordner Skills. Wie könnte es fast anders sein? Und letztlich könnte man jetzt halt sagen...
Speaker 2Agent Assets taucht hier noch auf. Also Agent Assets als Sound-Ordner, darunter Skills und dann der Skill-Name und dann soll eine Datei skill.md, sprich eine Markdown-Datei, erstellt werden.
Speaker 1Ja, genau. Das ist halt auch spannend, dass halt jetzt auf einmal ist halt auch klar, warum wir auf einmal einen Preview-File... einen File-Händler im Sharepoint bekommen haben, um Markdown-Dateien anzuzeigen. Auch mit Vorschau und so. Ja, hängt auch damit zusammen, weil ich es jetzt nämlich dann auch nutzen kann, um mir halt eben diesen Skill anzugucken. Und wir haben ja eingangs gesagt, der Skill kann einfach erstellt werden, indem ich halt Copilot sage, was er mir für einen Skill erstellen soll. Also es ist wirklich so, kann man sich das vorstellen, indem man Copilot beschreibt, was die Aufgabe ist. Also prüfe, ob in der Rechnung... Rechnungsanschrift, ob da auch ein Land drin steht oder ob da auch irgendeine bestimmte Handelsregisternummer oder ähnliches drinsteht.
Speaker 2Steuer-ID oder weiß der Geier was, ne?
Speaker 1Genau, da gibt man halt einfach Beispiele mit, wie das aussehen soll und auch, wie das grundsätzlich aufgebaut sein sollte. Ja, also irgendwie, ob an den Dokumenten auch immer bitte die Geschäftsbedingungen angehängt sind oder so. Und die heißen entweder Geschäftsbedingungen oder keine Ahnung, ja, vielleicht in... in Übersetzung dann halt die englische, französische, spanische, whatever Entsprechung. Und dann wird halt eben von Copilot diese Skill-Markdown-Datei erstellt. Und die können wir natürlich nachträglich auch bearbeiten.
Speaker 2Sofern wir diesen Präfix, wenn die Doku stimmt, create a skill oder erstelle ein Skill, der verwende. Also es ist nicht staatmäßig immer, sondern du musst halt explizit dem Copilot schon sagen, erzeuge einen Skill, der mir die Rechnung prüft auf folgende Informationen. Hier hast du ein Beispiel, wie es vollständig ausschauen soll und nutze das, um diesen Skill zu erstellen. Ja.
Speaker 1Genau, und das ist halt der eine und wirklich super einfache Weg und der auch schon, ja, obwohl er so einfach ist und ja, schon fast zu einfach erscheint, wirklich gute Ergebnisse liefert. Und aber natürlich kann ich auch hingehen und diese... Ja. ...Dateien quasi als Quellcode erzeugen oder ich lasse sie von Copilot erzeugen und bearbeite sie dann halt im Editor weiter. Und kann sie halt dann so entsprechend optimieren. Das geht halt auch, vorausgesetzt, und da sind wir wieder halt bei den technischen Rahmenbedingungen, die halt jetzt dadurch nicht irgendwie was Besonderes sind, sondern eben sich einfach im Standard von SharePoint bewegen. Ja, ich muss halt Schreibrechte auf diese Dokumenten... ...Dokumentenbibliothek haben. Wenn ich da halt keine Schreibrechte habe, kann ich auch keinen Skill erstellen. Dürfte klar sein. Und das ist vielleicht auch so ein bisschen so die erste Antwort auf die Frage, wie steuert man denn das Ganze? Naja, wer halt in einer Site-Collection Schreibrechte hat, kann auch Skills erstellen. Wer da keine Schreibrechte hat, kann keine Skills erstellen.
Speaker 2Aber das bedeutet, ich muss nicht ein höherwertiges Access-Level haben, wie jetzt Site-Organisator oder Site-Administrator oder... ...irgendwie sowas, sondern in dem Augenblick, wo ich über Schreib-Lese-Berechtigungen verfüge, also Contributor in einer SharePoint-Site bin, oder wenn wir mal den Schulterschluss zu Microsoft Teams machen, wenn ich dort in einem Microsoft-Team ein Mitglied bin, habe ich ja automatisch auch im Backend eine SharePoint-Site dazu, auf der ich Schreib-Lese-Berechtigungen habe. Das ist also ausreichend, damit ich dann einen Skill erstellen kann. Ja, weil es geht. Weil es technisch geht.
Speaker 1Ja, genau. Also genau so ist es. Was man jetzt vielleicht noch einschränkend sagen muss, es kann ja... Also wenn wir mal... Der Rainer. Bleiben wir mal bei dem Beispiel Teams und gehen wir davon aus, dass es wirklich die Standard-Berechtigungen sind, die nun mal erzeugt werden, wenn man ein Team erstellt. Ja, dann genau reicht es halt aus, Mitglied dieses Teams zu sein, um in der zugehörigen SharePoint-Site einen Skill zu erstellen. Was wir auch noch im Hinterkopf behalten sollten, ist, dass wir natürlich eine Co-Pilot-Lizenz... ...Lizenz brauchen, um halt darauf zugreifen zu können. Das ist jetzt erstmal die, ja, hoffentlich offensichtliche, lizenzseitige Voraussetzung. Dann kann man halt Co-Pilot im SharePoint nutzen und kann dann Skills erstellen als Member des Teams, weil man halt mindestens die Bearbeiten-Rechte im SharePoint, in der zugehörigen SharePoint-Team-Site hat. Und wenn man nur Anzeigen-Rechte hat, das wäre jetzt zum Beispiel etwas, was ja so in einem Team gar nicht passieren kann, so im Standard, der kann zwar Skills benutzen, aber nur, wenn die nicht irgendwas bearbeiten. Also wenn irgendwie da ein Skill existiert, der einfach nur mir Grün-Gelb-Rot-Bewertungen für die Vollständigkeit einer Rechnung ausgibt, das aber im Chat als Antwort liefert und nicht irgendwie durch Formatierung oder Umstellen... ...von Eigenschaften oder ähnliches, dann kann ich das halt auch mit nur Anzeigen- oder View-Rechten machen. Es gibt keine, bisher keine separate Admin-Rolle oder so. Was man aber vielleicht sehen muss, und da sind wir wieder bei so, ne, sind so diese Grenzfälle, es kann ja durchaus im SharePoint angepasste Berechtigungen geben für Site-Collections. Und wenn ich da zum Beispiel jetzt Anwendern erlaube, Dokumente in der Dokumentenbibliothek abzulegen, aber nicht... ...dokumentenbibliothek zu bearbeiten und ich aber einen Skill erstellen möchte, der beispielsweise fehlende Metadatenspalten in der Dokumentenbibliothek ergänzt oder Conditional Formatting einführt oder sowas, dann funktioniert das halt genauso wenig, auch wenn ich Bearbeiten-Rechte habe, weil dafür bräuchte ich dann gegebenenfalls mehr Berechtigungen als nur Bearbeiten. Aber, ja.
Speaker 2Was ja hoffentlich nie auf die Idee kommt, solche komische Berechtigungen innerhalb eines SharePoints. Ja, aber genau, kommt trotzdem immer wieder mal vor. Kommt immer wieder vor, ne, ja. Entspricht halt nicht dem Projektalltag, dass wir mit den Standard-Permissions auskommen und so manche SharePoint-Anwender und Administratoren werden da sehr kreativ, ja.
Speaker 1Ja, und das wiederum heißt aber auch, dass diese vielleicht... ...much advanced Fragen, die man da im Hintergrund noch haben könnte, ja, also was halt jetzt irgendwie das Versehen mit Sensitivity-Labels oder Retention-Policies oder auch Auditing anbelangt, das funktioniert natürlich alles trotzdem, weil diese Skills eben Markdown-Dateien in einer SharePoint-Dokumentenbibliothek sind. Und wer sie bearbeitet, erstellt und so weiter, unterliegt halt den ganz normalen Konfigurationen, die man vielleicht auch so schon im Tenant, in seiner SharePoint-Umgebung in place hat. Also im Hinblick auf... ...auditing und Retention und Labeling.
Speaker 2Ist aber auch nochmal eine ganz wichtige Boundary, ne. Das heißt, der Skill arbeitet immer nur innerhalb dieser SharePoint-Site. Er kann jetzt nicht Dokumente, Informationen aus irgendeinem anderen SharePoint-Site bearbeiten, sondern immer nur dort, wo er eben physikalisch gespeichert ist. wurde, kann er entsprechend arbeiten und kann ich ihn dann auch entsprechend nutzen.
Speaker 1Ja, das ist richtig, aber was es halt auch bedeutet ist, wir können ihn halt kopieren. Also wenn wir uns halt an dieses Namensschema und diese Ordnerstruktur, die du ja schon umrissen hast, also wir haben halt diese Agent Assets Dokumentenbibliothek und darin halt dann den Unterordner Skills und darin halt einen Unterordner, der so heißt wie der Skill und also zum Beispiel Rechnungsprüfung und darin gibt es dann halt die Markdown-Datei, die einfach Skill.md heißt und ja, wenn ich halt diese Hierarchie kopiere, also mindestens den Ordner mit dem Skill-Namen und dem Skill darin, dann kann ich das halt auch auf eine andere Site-Collection übertragen und da verwenden.
Speaker 2Verwenden, ja. Sehr gut. Was wir auch noch erwähnt haben wollen, weil wir gerade über Boundaries gesprochen haben und er kann innerhalb der gleichen SharePoint-Site Dokumenten. Dokumente als Informationen verarbeiten, natürlich auch alles andere als Informationen, was eben auch nicht geht, ist, dass wir hier auf Third-Party-Systeme zugreifen können. Also wir können jetzt nicht einen Service Now oder irgendwas anderes anbinden, dafür bräuchten wir wieder klassisch einen Co-Pilot Connector, der das Ganze übernimmt, ist eben nicht die Aufgabe des SharePoint-Skills logischerweise, Daten aus Drittsystemen abzuzapfen und verwendbar zu machen. Anwendungsfälle, Adrian. Ich glaube, technisch haben wir soweit das Thema rund und abgeschlossen, oder? Könnten wir nochmal über Anwendungsfälle sprechen?
Speaker 1Gucken wir nochmal, wo das besonders viel Sinn macht. Also was ich zum Beispiel schon mal hatte, war der Fall, dass es um die Aktualität von Dokumenten geht und jetzt könnte man natürlich sagen, naja, aber wir haben doch geändert Datum und Erstelldatum, das sagt uns ja schon was über die Aktualität. Ich glaube, das Problem ist aber immer, wenn halt Dokumente nicht unbedingt ihren Lebenszyklus im SharePoint begonnen haben, sondern an irgendeiner anderen Stelle, dann stimmt ja nicht unbedingt das Änderungsdatum, ja gut, das Änderungsdatum und das Erstelldatum kann dann halt schon aktuell sein, das kann trotzdem ein 20 Jahre altes Dokument sein, theoretisch. Und wenn man jetzt halt eine bestimmte Aktualität oder Review-Zyklus, das heißt, das kann dann ein 20 Jahre altes Dokument sein, das heißt, das kann dann halt schon ein 20 Jahre altes Dokument sein, theoretisch. Und wenn man dann halt eine bestimmte Aktualität oder Review-Zyklus in der Dokumentenbibliothek einführen möchte und da aber auch Dokumente sammelt, die eben andere Quellen haben und da halt nur irgendwann abgelegt worden sind, dann brauchst du vielleicht irgendwie einen Blick in das Dokument. Und da wäre ja das Beispiel, klar, kann man dann da kurz reingucken und checken, ist das jetzt eine aktuelle Version, aber das ist ja zeitaufwendig. Und dann kann man halt für sowas eben beispielsweise einen Skill nehmen, einen Skill erstellen, der eben die Dokumente inhaltlich prüft, ob die von einem aktuellen Stand sind, jünger als fünf Jahre oder wenn es halt bestimmte Strukturen in dem Dokument gibt, dass man dann halt prüfen lässt, ob da halt ein aktuelles Review-Datum drin steht, was nicht älter als zwölf Monate ist oder so. Da hilft einem dann eben auch der generative Ansatz und es ist vielleicht nicht so einfach, nur in Anführungsstrichen über einen Workflow zu prüfen. Weil es halt vielleicht nicht immer an exakt derselben Stelle steht oder so. Verstehe. Und genau das Gleiche halt auch, wenn man halt so ein Standardformat vielleicht für Dokumentenbibliotheken eines bestimmten Dokumententyps hat, dass man dann vielleicht auch direkt in den Skill halt hinterlegt, dass die Formatierung angepasst wird. Also fand ich halt auch ganz spannend, dass das halt funktioniert und dass dann halt erst geprüft wird, ja passt denn die Anzeige? Die Anpassung oder passt die halt nicht so? Ist die schon vorhanden? Und ja.
Speaker 2Was mir der Co-Pilot auch noch als Beispiel ausgegeben hat, das ist Projektsteuerung und wiederkehrende Status-Updates. Der Fall hier ist, dass wir eben ein Projektteam haben, was Statuslisten im Sharepoint pflegt, wo regelmäßig Dokumente in einer Bibliothek aktualisiert werden, hochgeladen werden und es quasi die Aufgabe ist, die Dokumente in der Bibliothek zu aktualisieren. Und die Aufgabe des Projektleiters ist, dort regelmäßig basierend auf den Ereignissen und Aktualisierung in den Dokumentenbibliotheken auch entsprechend den Status zu pflegen, wo die einzelnen Projektteams oder die einzelnen Abschnitte liegen. Und auch hier könnte man eben sehr gut die Sharepoint-Skills nehmen, indem eben der Project-Tracker-Skill ja regelmäßig überprüft, wer ist denn aktuell noch der Owner dieses Projektbausteins, wer hat die Dokumente zum Schluss aktualisiert, haben wir irgendein Due-Date, was sich aus den Dokumenten ergibt, dann müssen wir die Priorität anpassen, etc. pp. Ja, und das natürlich dann entsprechend auf Grundlage der Informationen, die wir innerhalb dieser Sharepoint-Site an Informationen finden. Ja.
Speaker 1Ja, was vielleicht zum Schluss noch so als Anmerkung bleibt, ist, dass es schon ein recht mächtiges Werkzeug ja ist, ja. Also merkt man glaube ich schon so auch jetzt von den Beispielen, die wir gebracht haben. Das hat ja durchaus Einfluss auf die Art und Weise, wie man im Sharepoint arbeitet, was ja uns vielleicht auch dazu führt, dass auch hier so ein bisschen organisatorische Leitplanken halt notwendig sind, wie man mit dem Thema umgeht, ne. Weil wir haben es ja gesagt, wir können so ein Skill kopieren und vielleicht haben wir so ein Rechnungs-Review-Skill auf der einen Seite und ja, wir müssen uns halt meiner Einschätzung nach, wir müssen uns halt unserer Einschätzung nach so ein bisschen darauf einigen, wie wir damit, also wie wir mit Versionen von Skills arbeiten, ne. Also entweder sagen wir, naja, okay, das gibt es halt für sich genommen in einer Site-Collection und im Zweifel ist halt der Site-Collection-Owner für die Skills verantwortlich und fertig, ja, das wäre so sicherlich die einfachste und aber auch pragmatischste Variante. Die andere Variante ist natürlich, dass das zu Verwirrung führen kann, wenn es einen Rechnungs-Review-Skill gibt. Wo es Skill auf der einen Site-Collection gibt mit dem Namen und auf einer anderen Site-Collection den gleichen Namen, der gleiche Name verwendet wird, der Skill aber etwas anderes tut. Also vielleicht trotzdem Rechnungen-Reviewed, aber nach ganz anderen Kriterien. Und das ist so eine Sache, wo man sich natürlich darüber bewusst sein muss, ne. Also dass ich halt in solche Situationen laufen kann, wenn ich nicht irgendwie organisatorisch zumindest versuche, mal festzulegen, wie denn jetzt Namen für Skills beispielsweise aufgebaut sind oder, ja, also mag ja auch sein, dass man das nicht braucht, diese Eindeutigkeit oder diese Differenziertheit, aber ich könnte mir halt schon vorstellen, dass so in, ja, wenn man übergreifend Skills in SharePoint-Sites nutzen möchte, dass es halt schon ein Thema ist, dass, ja, es irgendwie transparent sein muss, wofür der Skill jetzt verwendet wird und warum, ne. Und, naja, out of the box haben wir da halt noch keine Lösung für, sprich, man muss sich da halt ein bisschen organisatorisch dann, denke ich mal, behelfen und, ja, vielleicht dann auch einen Skill anlegen, der die Anwender darüber informiert, welche Skills es auf der Seite gibt.
Speaker 2Zum Beispiel, ja. Wäre ja alles am Ende des Tages denkbar, dadurch, dass es eben eine klare Struktur gibt, wo diese Skills abgelegt sind, die Markdown-Dateien, wäre es ja durchaus denkbar zu sagen, helfe mir mal, die aktuellen Skills zu finden und dann bekomme ich eben eine Ausgabe der aktuellen Skills. Also, die aktuellen Skills der dazugehörigen SharePoint-Site oder sowas.
Speaker 1Ja, das wäre auf jeden Fall schon mal ein praktischer Ansatz. Wobei, ich muss zugeben, ich habe das noch nicht ausprobiert, also ob jetzt halt Skills wirklich auf die Skill-Assets oder auf die Agent-Assets, so heißt die Bibliothek, zugreifen können. Aber vermutlich schon, ja.
Speaker 2Was mir gerade als Idee gekommen ist, weil so ein zentrales Brand-Center, wie es jetzt auch zum Schluss nochmal aktualisiert wurde, gibt es ja eben nicht in Form von Skills, was du gerade sagtest. Also, angenommen, wenn wir die Anforderungen, Rechnung muss geprüft werden, dann share ich den Skill einfach mal und kopiere ihn in die andere Abteilung, die dann auch den gleichen Skill verwendet. Bei mir als Autor des Ganzen gibt es neue Rechnungen, neues Format, deswegen aktualisiere ich meinen Skill. Wie kommt jetzt dieser aktualisierte Skill in die anderen Teams? Also, ich habe jetzt hier einen neuen Skill, der jetzt auch am Start ist und in Verwendung ist, oder die haben eine Anpassung gemacht, wie führen wir das zusammen und so weiter und so fort. Also, da entsteht ja kein richtiges Nightmare entstehen, so gerade, wo wir drüber reden, ob das dann in echt so passieren wird, weiß ich nicht. Aber auch da kann man ja wieder überlegen über entsprechende PowerShell-Module, Azure Automation etc. pp. Komplett User-Framed gerade, aber Richtung Governance Lifecycle auf jeden Fall. Ein spannendes Thema für ein Community-Projekt, würde ich sagen. Eine SharePoint-Site, wo diese Assets gepflegt werden und von dort aus werden die dann in die entsprechenden Sites, wo es benötigt wird, kopiert. Dann gibt es eben ein Update, dann mache ich das in meiner Agent-Skill-Asset-Site und von dort wird es dann in der Nachtverarbeitung wieder ausgerollt und wird in die anderen Sites kopiert. Also, wenn ihr euch berufen fühlt, befühlt, lieber Adrian und Konsorten, vielleicht könnt ihr mit dieser Idee ja was anfangen und demnächst haben wir ein spannendes Community-Projekt.
Speaker 1Ja, schon. Nur vielleicht eine Sache noch. zur Richtigstellung, also was heißt Richtigstellung, zur Differenzierung. Ich glaube, das ist wichtig. Das kam vielleicht gerade so rüber, als wenn halt Skills auch Skills aufrufen können, wie das bei Agents ja der Fall ist. Das ist halt nicht der Fall. Also uns geht es jetzt halt nur darum, wie kriegt man im Zweifelsfall die Information, welche Skills gibt es gerade alle auf der Seite und was tun die? Also es ist definitiv so, dass ein Skill nicht einen anderen Skill ausführen kann. Da wären wir dann definitiv in dem Themenbereich dafür braucht man einen Agent beziehungsweise halt dann eben natürlich mehrere Agents, die interagieren können. Genau.
Speaker 2Oder halt am Ende des Tages doch wieder nur eine Azure Automation, was mir eben diesen Ordner Agent Skills ausliest und eine Sharepoint-Seite produziert, wo alle Skills eben gelistet werden mit einer kurzen Beschreibung, was sie so tun. Genau. Oder wieder beim Thema wären Co-Pilot and AI ist zwar hammergeil, aber nicht alles ist ein Nagel.
Speaker 1Genau.
Speaker 2Sehr richtig.
Speaker 1Und auch dabei, warum eigentlich eine Markdown-Datei? Kann man sich ja jetzt auch fragen. Warum nicht irgendwas, weiß ich nicht, binäres oder was ganz anderes? Naja, ich glaube, da geht es halt auch darum, also zum einen, wir haben ja schon am Anfang gesagt, das kommt aus der Claude-Ecke und insofern wird da halt was verwendet, was sowieso schon da war, so ganz grundsätzlich. Und auf der anderen Seite hilft uns das im Zweifel auch. Also gerade wenn wir jetzt darüber nachdenken, da irgendwas zu automatisieren, um auszulesen, welche Skills gibt es eigentlich, wie gesagt, auch in dieser Skill-Definition steht drin, wofür der Skill eigentlich da ist. Und da das halt Markdown ist, können wir das Ganze strukturiert auslesen. Das ist halt ein Format, was man, ja, was sowohl Menschen als auch Maschinen lesbar ist, so würde ich das jetzt mal, ja, ist nicht ganz hundertprozentig richtig, aber ich glaube, es wird klar, wo deutlich, worauf ich hinaus möchte. Also wir können es halt uns so anzeigen lassen, dass wir es vernünftig lesen können und wir können halt auch mit beispielsweise einer Azure Function oder so auf die Textdatei zugreifen und den Teil rausziehen, der jetzt für die Beschreibung zuständig ist beispielsweise. Genau. Ja, und ich glaube, damit sind wir auch schon am Ende. Wir wollten ja einfach mal so einen Überblick geben, was kann man als Anwender so mit Skills tun, was braucht man dafür und wobei kann einem das helfen? Ich hoffe, das ist uns gelungen, bis hin zu einem bisschen Ausblick, wohin das Ganze führen kann und was vielleicht noch offene Enden oder lose Enden sind, die zu einer Herausforderung werden könnten, wenn man nicht von vornherein drüber nachdenkt.
Speaker 2So ist es. Ja, sehr gut. Dann sage ich vielen, vielen Dank, Adrian, für deine Zeit und dass wir hier mal wieder einen lustigen Plausch hatten. Ich hoffe, liebe Zuhörerinnen und Zuhörer, ihr konntet was mitnehmen und ihr bleibt uns natürlich treu. Abonniert gerne den Podcast, macht Werbung dafür, wenn ihr sagt, Mensch, meine Kollegin, mein Kollege, für den könnte es auch interessant sein, sich eine halbe Stunde zu Co-Pilot und was gibt es Neues in Microsoft 365 Kosmos oder was gibt es Neues in Bezug auf AI Co-Pilot in Microsoft 365 an Features, an Funktionen, die ich so noch nicht kannte. Teilt es gerne und damit sage ich, vielen Dank fürs Zuhören, auf Wiedersehen und Adrian, hast du auch noch ein paar
Speaker 1Tragen, Schlossworte? Genau, und danke fürs Zuhören und hoffentlich bis zum nächsten Mal. Musik Musik Musik Musik Musik
PodcastTranscript AI