# KnowHow Academy > Lernpfade für Procurement Admins, Procurement User und Fachbereiche: Module mit Dauer, Voraussetzungen und Reihenfolge — statt Kurskatalog. Alle Lektionen der KnowHow Academy hintereinander, zuerst Deutsch, dann Englisch, je Sprache in der Reihenfolge der Lernpfade. Jede Lektion beginnt mit ihrem Frontmatter. All lessons of the KnowHow Academy in sequence, German first, then English, each in learning-path order. Every lesson starts with its frontmatter. --- title: "Überblick über e-Request" description: "Wofür die Plattform da ist, wer damit arbeitet und wie eine Beschaffung von der Anfrage bis zum Vertrag läuft." lang: "de" url: "https://academy.knowhow.io/learning/product-overview" persona: ["procurement-admin", "procurement-user", "department-user"] level: "beginner" estimated_time: 10 --- # Überblick über e-Request Wofür die Plattform da ist, wer damit arbeitet und wie eine Beschaffung von der Anfrage bis zum Vertrag läuft. - Teil von: [Procurement Admin](https://academy.knowhow.io/personas/procurement-admin) (Modul 1 von 8), [Procurement User](https://academy.knowhow.io/personas/procurement-user) (Modul 1 von 7), [Fachbereich](https://academy.knowhow.io/personas/department-user) (Modul 1 von 3) - Dauer: 10 Min. - Niveau: Einstieg - Vorher lesen: Keine Voraussetzungen - Als Nächstes: [Organisation einrichten](https://academy.knowhow.io/learning/setup-organization.md) Bevor Sie irgendetwas konfigurieren oder erfassen, lohnt sich ein Blick auf den Ablauf als Ganzes. ## Die Beteiligten - **Fachbereich** meldet einen Bedarf an und verfolgt ihn. - **Einkauf** führt die Beschaffung durch: Ausschreibung, Fragerunde, Bewertung, Zuschlag. - **Admin** richtet die Organisation ein, verwaltet Rollen und Zugänge und pflegt Kategorien, Kriterien und Vorlagen. - **Lieferanten** arbeiten in einem eigenen Portal — sie sehen Ihre interne Sicht nie. Diese drei Rollen gibt es im Produkt genau so. Sie sind kein Organigramm-Vorschlag, sondern das Berechtigungsmodell. ## Der Ablauf 1. **Bedarf** entsteht im Fachbereich. 2. **Ausschreibung** wird erfasst, mit Dokumenten, und intern freigegeben. 3. **Lieferanten einladen** — der Einkauf lädt ein, es gibt keine offene Selbstregistrierung. 4. **Fragerunde**: Fragen werden gesammelt, beantwortet, freigegeben und **allen** Eingeladenen gemeinsam publiziert. 5. **Angebote** werden im Lieferantenportal erstellt und eingereicht. 6. **Bewertung** nach vorher festgelegten, gewichteten Kriterien. 7. **Zuschlag** und, wenn das Vertragsmodul im Einsatz ist, der Vertrag. ## Der Ablauf ist bewusst fix Das ist der Punkt, an dem sich e-Request von einem Werkzeugkasten unterscheidet: **Die Schritte sind fest verdrahtet.** Sie können sie nicht umbauen, und das ist die Absicht — ein Verfahren, das jedes Mal gleich läuft, ist genau das, was eine Revision zwei Jahre später nachvollziehen kann. Anpassbar sind Rollen, Rechte, Felder, Kriterien und Vorlagen. Was in welcher Reihenfolge passiert, nicht. Wer damit rechnet, den Ablauf an eine bestehende Sonderlösung anzupassen, sollte das früh wissen — deshalb steht es hier und nicht in einer Fussnote. ## Was protokolliert wird Über die Geschäftsobjekte hinweg wird umfassend protokolliert, und jede Ausschreibung hat ihre eigene Protokollansicht. Das ist der zweite Grund, warum der feste Ablauf ein Vorteil ist: Nachvollziehbarkeit entsteht nicht durch Disziplin, sondern durch die Software. ## Was Sie als Nächstes lesen Je nach Rolle: Als **Admin** richten Sie zuerst die Organisation ein. Als **Einkauf** beginnen Sie bei der Ausschreibung. Als **Fachbereich** reicht der Weg vom Bedarf bis zur Statusverfolgung. --- title: "Organisation einrichten" description: "Abteilungen, Berechtigungsstufen und den Kategorienbaum so anlegen, dass die Pflege später keine Sonderfälle kennt." lang: "de" url: "https://academy.knowhow.io/learning/setup-organization" persona: ["procurement-admin"] level: "intermediate" estimated_time: 20 prerequisites: ["product-overview"] --- # Organisation einrichten Abteilungen, Berechtigungsstufen und den Kategorienbaum so anlegen, dass die Pflege später keine Sonderfälle kennt. - Teil von: [Procurement Admin](https://academy.knowhow.io/personas/procurement-admin) (Modul 2 von 8) - Dauer: 20 Min. - Niveau: Fortgeschritten - Vorher lesen: [Überblick über e-Request](https://academy.knowhow.io/learning/product-overview.md) - Als Nächstes: [Rollen und Rechte](https://academy.knowhow.io/learning/rollen-und-rechte.md) Die Struktur entscheidet, wie einfach Berechtigungen später zu pflegen sind. Es lohnt sich, hier langsam zu sein. ## Abteilungen und Berechtigungsstufen Abteilungen bilden Ihre Organisation ab. Pro Abteilung gibt es drei Stufen: - **Mitglied** — arbeitet in der Abteilung mit - **Leser** — sieht mit, ohne zu handeln - **Leitung** — verantwortet die Abteilung Legen Sie nur an, was Sie auch pflegen wollen. Jede zusätzliche Abteilung ist eine weitere Liste, die bei jedem Stellenwechsel nachgeführt werden will. ## Der Kategorienbaum Kategorien ordnen Ihre Beschaffungen — und sie lassen sich der **CPV-2008**-Systematik zuordnen. Wenn Sie im öffentlichen Umfeld beschaffen, ist das der Punkt, an dem sich Ihre interne Struktur mit der amtlichen verbinden lässt. Fangen Sie grob an. Ein Baum mit vierzig Ästen, von denen dreissig nie benutzt werden, macht die Auswahl für alle anderen mühsamer. ## Zwei Fehler, die später weh tun - **Zu feine Struktur.** Jede Einheit, die Sie anlegen, wollen Sie später auch pflegen. - **Personen statt Rollen.** Wer Rechte an Personen hängt, baut sie bei jedem Stellenwechsel neu. ## Was hier nicht hingehört Der **Ablauf** einer Beschaffung. Der ist fest verdrahtet und nicht Teil der Einrichtung — siehe **Was konfigurierbar ist, und was nicht**. Wer die Organisationsstruktur benutzt, um einen Sonderablauf nachzubilden, baut etwas, das die Software nicht kennt. Fertig, wenn Sie die Struktur einer Kollegin in zwei Minuten erklären können. --- title: "Rollen und Rechte" description: "Die drei Rollen, was der Fachbereich sieht — und was er bewusst nicht sieht." lang: "de" url: "https://academy.knowhow.io/learning/rollen-und-rechte" persona: ["procurement-admin"] level: "intermediate" estimated_time: 15 prerequisites: ["setup-organization"] --- # Rollen und Rechte Die drei Rollen, was der Fachbereich sieht — und was er bewusst nicht sieht. - Teil von: [Procurement Admin](https://academy.knowhow.io/personas/procurement-admin) (Modul 3 von 8) - Dauer: 15 Min. - Niveau: Fortgeschritten - Vorher lesen: [Organisation einrichten](https://academy.knowhow.io/learning/setup-organization.md) - Als Nächstes: [Anmeldung und SSO](https://academy.knowhow.io/learning/anmeldung-und-sso.md) Es gibt drei Rollen: **Admin**, **Einkauf** und **Fachbereich**. Sie sind fest im Produkt angelegt; Sie ordnen Personen zu, Sie erfinden keine vierte. ## Wer was tut - **Admin** — Organisation, Rollen, Zugänge, Kategorien, Kriterien, Vorlagen, Branding, Systemeinstellungen. - **Einkauf** — führt Beschaffungen: Ausschreibung, Lieferanteneinladung, Fragerunde, Bewertung, Zuschlag. - **Fachbereich** — meldet Bedarf an und verfolgt ihn. ## Was der Fachbereich sieht — und was nicht Diese Grenze wird am häufigsten falsch erwartet, deshalb ausführlich: Ein Fachbereich sieht **alle Lieferanten**, einschliesslich ihrer Zustände und Kontaktdaten. Das ist Absicht: Wer einen Bedarf formuliert, soll wissen, mit wem das Haus überhaupt arbeitet. Nicht sichtbar sind: - **Preise und Angebotsdetails fremder Ausschreibungen** - **Qualifikationsdaten** der Lieferanten Ebenfalls nicht vorhanden: ein direktes Kontaktformular zum Lieferanten. Der Kontakt läuft über den Einkauf, und zwar nicht aus Bequemlichkeit, sondern weil ein laufendes Verfahren sonst ausserhalb des Verfahrens beeinflusst würde. ## Wenn Ihnen das zu grob ist Die Berechtigung ist rollen- und abteilungsbasiert. Einen feineren Schnitt — etwa „diese Person sieht nur diese eine Kategorie" — gibt es nicht. Planen Sie damit, statt darauf zu warten. Das gilt auch für die Schnittstellen: Ein API-Schlüssel sieht **mandantenweit alles**, es gibt keinen Abteilungsschnitt. Wer einen Service-Account ausstellt, vergibt damit Lesezugriff auf den ganzen Mandanten. ## Rollenwechsel Rollen gehören an Funktionen, nicht an Personen. Wer eine Zuordnung ändert, ändert sie an einer Stelle — das ist der ganze Vorteil, und er geht verloren, sobald Ausnahmen gepflegt werden. **Ein Sonderfall:** Läuft Ihre Instanz mit SSO, besitzt nicht die Anwendung die Rolle, sondern Ihr Identity Provider. Was Sie hier sehen, ist dann eine Anzeige, keine Verwaltung — siehe **Anmeldung und SSO**. --- title: "Anmeldung und SSO" description: "Zwei Anmeldemodi, die sich gegenseitig ausschliessen — und was Ihr Identity Provider damit zu tun hat." lang: "de" url: "https://academy.knowhow.io/learning/anmeldung-und-sso" persona: ["procurement-admin"] level: "advanced" estimated_time: 20 prerequisites: ["rollen-und-rechte"] --- # Anmeldung und SSO Zwei Anmeldemodi, die sich gegenseitig ausschliessen — und was Ihr Identity Provider damit zu tun hat. - Teil von: [Procurement Admin](https://academy.knowhow.io/personas/procurement-admin) (Modul 4 von 8) - Dauer: 20 Min. - Niveau: Vertiefung - Vorher lesen: [Rollen und Rechte](https://academy.knowhow.io/learning/rollen-und-rechte.md) - Als Nächstes: [Was konfigurierbar ist, und was nicht](https://academy.knowhow.io/learning/was-konfigurierbar-ist.md) Eine Instanz läuft entweder mit **SSO** oder mit **Benutzerverwaltung in der Anwendung**. Nicht beides, und es gibt keinen Rückfallweg von einem in den anderen. Diese Entscheidung fällt vor dem Betrieb. Sie nachträglich zu drehen ist kein Schalter. ## Der Normalfall: SSO e-Request spricht **OIDC gegen Keycloak**. Wer kein eigenes Identity-Management betreibt, bekommt eine verwaltete Keycloak-Instanz dazu. **Wichtig:** Bei aktivem SSO besitzt Keycloak die Rolle. Die Anwendung zeigt sie an, sie verwaltet sie nicht. Wer Rollen ändern will, tut das dann im Identity Provider — und wer das nicht weiss, sucht die Einstellung in der falschen Oberfläche. ## Wenn Sie Entra ID oder AD FS einsetzen Diese sprechen SAML. **e-Request selbst implementiert kein SAML.** Ihr SAML-Identity-Provider wird über Keycloak als föderierter Provider angebunden — das Brokering übernimmt Keycloak, nicht die Anwendung. Das funktioniert und ist der vorgesehene Weg. Es ist aber eine **Leistung**, kein Häkchen: Die Anbindung gehört in die Planung und in das Angebot. Rechnen Sie nicht damit, dass sie „schon dabei" ist. ## Der andere Modus: Benutzerverwaltung in der Anwendung Eine Instanz kann auch ganz ohne Identity Provider laufen: Einladung per Mail, Passwort, Sperre gegen automatisiertes Durchprobieren. Rollen liegen dann in der Anwendung. ## Die Lieferantenseite ist davon nicht betroffen Lieferanten melden sich **immer** mit Benutzername und Passwort an — unabhängig davon, welchen Modus Ihre Einkaufsseite fährt. Es gibt kein SSO auf der Lieferantenseite, und das ist keine Lücke, sondern eine Entscheidung: Ein Lieferant arbeitet für viele Auftraggeber, und ein eigenes Konto pro Portal ist der Weg, der überall funktioniert. Versprechen Sie einem Lieferanten also nie eine Anmeldung über sein Firmenkonto. ## Zugänge beenden Zugänge werden **deaktiviert, nicht gelöscht** — auf beiden Seiten. Wer einmal gehandelt hat, bleibt im Protokoll nachvollziehbar; aus dem Betrieb ist die Person sofort draussen. Siehe **Benutzer und Zugänge**. --- title: "Was konfigurierbar ist, und was nicht" description: "Der Ablauf steht fest — Vorlagen, Kriterien, Kategorien und Branding nicht. Wo die Grenze verläuft." lang: "de" url: "https://academy.knowhow.io/learning/was-konfigurierbar-ist" persona: ["procurement-admin"] level: "intermediate" estimated_time: 20 prerequisites: ["setup-organization"] --- # Was konfigurierbar ist, und was nicht Der Ablauf steht fest — Vorlagen, Kriterien, Kategorien und Branding nicht. Wo die Grenze verläuft. - Teil von: [Procurement Admin](https://academy.knowhow.io/personas/procurement-admin) (Modul 5 von 8) - Dauer: 20 Min. - Niveau: Fortgeschritten - Vorher lesen: [Organisation einrichten](https://academy.knowhow.io/learning/setup-organization.md) - Als Nächstes: [Benutzer und Zugänge](https://academy.knowhow.io/learning/user-management.md) Die häufigste Erwartung an eine Beschaffungsplattform ist, dass sie sich an den eigenen Ablauf anpassen lässt. Bei e-Request ist es umgekehrt, und zwar absichtlich. ## Fest verdrahtet **Der Ablauf.** Ausschreibung, interne Freigabe, Einladung, Fragerunde, Angebote, Bewertung, Zuschlag — in dieser Reihenfolge, immer. Das ist keine offene Baustelle. Es ist der Compliance-Nutzen: Ein Verfahren, das jedes Mal gleich läuft, lässt sich zwei Jahre später nachvollziehen. Ein konfigurierbarer Ablauf könnte das nicht, weil dann jede Ausschreibung ihre eigene Geschichte hätte. Wenn Ihr Haus einen Sonderablauf hat, ist das eine Entscheidung, die vor der Einführung gehört — nicht eine Einstellung, die man sucht. ## Was Sie selbst einstellen - **Kategorien** samt CPV-Zuordnung - **Bewertungskriterien** für Angebote und Lieferanten, mit Gewichtung - **E-Mail-Vorlagen** — es sind rund dreissig, in Deutsch und Englisch, mit Vorschau und Testversand - **Branding** — Ihr Erscheinungsbild im Portal - **Rollen und Rechte**, Abteilungen und Berechtigungsstufen - **Felder**, soweit das Produkt sie vorsieht Für all das brauchen Sie niemanden von uns. ## Der Testversand ist die wichtigste Kleinigkeit E-Mail-Vorlagen sind der Teil, den Ihre Lieferanten zuerst sehen — oft bevor sie die Plattform überhaupt betreten. Nutzen Sie Vorschau und Testversand, bevor eine Vorlage produktiv geht. Eine Einladung mit einem Platzhalter darin ist der erste Eindruck, den Sie nicht zurückholen. Deutsch und Englisch sind vollständig gepflegt. Die Oberfläche gibt es in mehr Sprachen; die Vorlagen in diesen beiden. ## Was es nicht gibt Damit niemand danach sucht: - **Keine Vorlagen für Ausschreibungen.** Stattdessen **duplizieren** Sie eine bestehende — das ist die Antwort auf „haben Sie Vorlagen?" und in der Praxis die bessere, weil eine Kopie mit echten Inhalten startet. - **Keine Branchenpakete.** Das Produkt ist generisch und wird über Kategorien und Kriterien auf Sie zugeschnitten. - **Keine frei konfigurierbaren Freigabestufen.** Die interne Freigabe existiert, mit dokumentierter Rückweisung — sie ist ein Schritt, keine Kette, die Sie bauen. ## Tarifgrenzen Es gibt eine Seite mit Lizenz- und Grenzwerten — Benutzer, Lieferanten. Sie **zeigt** an, sie erzwingt nichts. Wer eine Grenze überschreitet, wird nicht ausgesperrt. Behandeln Sie die Zahlen als Information für Ihre Planung, nicht als Sicherung. --- title: "Benutzer und Zugänge" description: "Zugänge vergeben, Austritte sauber abwickeln — und was ein Service-Account tatsächlich darf." lang: "de" url: "https://academy.knowhow.io/learning/user-management" persona: ["procurement-admin"] level: "intermediate" estimated_time: 15 prerequisites: ["anmeldung-und-sso"] --- # Benutzer und Zugänge Zugänge vergeben, Austritte sauber abwickeln — und was ein Service-Account tatsächlich darf. - Teil von: [Procurement Admin](https://academy.knowhow.io/personas/procurement-admin) (Modul 6 von 8) - Dauer: 15 Min. - Niveau: Fortgeschritten - Vorher lesen: [Anmeldung und SSO](https://academy.knowhow.io/learning/anmeldung-und-sso.md) - Als Nächstes: [Lieferanten verwalten](https://academy.knowhow.io/learning/lieferanten-verwalten.md) Benutzerverwaltung ist wenig Arbeit — solange sie regelmässig gemacht wird. ## Wiederkehrende Aufgaben - Neue Mitarbeitende aufnehmen und einer Rolle zuordnen - Rollenwechsel nachführen - Austritte deaktivieren Läuft Ihre Instanz mit SSO, passiert das Anlegen und Zuordnen in Ihrem Identity Provider. Die Liste hier ist dann eine Kontrollansicht, keine Verwaltung. ## Deaktivieren, nicht löschen Zugänge werden deaktiviert. Ein Konto verschwindet nie aus dem Protokoll, nur aus dem Betrieb — sonst wäre jede Nachvollziehbarkeit an dem Tag weg, an dem jemand das Haus verlässt. Das gilt für Ihre Leute und für Lieferantenzugänge gleichermassen. ## Die Quartalsrunde Setzen Sie sich einen wiederkehrenden Termin — einmal im Quartal genügt — und gehen Sie die Liste der aktiven Zugänge durch. Zehn Minuten, und die grosse Aufräumaktion findet nie statt. ## Service-Accounts Für Schnittstellen gibt es Service-Accounts mit API-Schlüsseln: ausstellen, rotieren, widerrufen. Zwei Dinge, die man ungefragt wissen sollte: - **Ein Schlüssel sieht mandantenweit alles.** Es gibt keinen Abteilungsschnitt. Wer einen Service-Account ausstellt, vergibt Zugriff auf den ganzen Mandanten, nicht auf einen Ausschnitt. - Derselbe Schlüssel trägt REST-API **und** MCP-Anschluss. Wer eines von beiden freischaltet, hat beides freigeschaltet, sofern lizenziert. Rotieren Sie Schlüssel bei personellen Wechseln mit. Ein Service-Account gehört keiner Person, aber jemand kennt ihn. ## Support-Zugriff Ein System-Administrator kann sich im Supportfall als Benutzer anmelden. Das ist ein starkes Werkzeug und im Protokoll sichtbar. Wenn Ihre interne Richtlinie das regeln muss, regeln Sie es, bevor der erste Supportfall eintritt — nicht danach. --- title: "Lieferanten verwalten" description: "Der Onboarding-Trichter, Nachbesserung statt Ablehnung — und warum eine Ablehnung nicht das Unternehmen meint." lang: "de" url: "https://academy.knowhow.io/learning/lieferanten-verwalten" persona: ["procurement-admin", "procurement-user"] level: "intermediate" estimated_time: 20 prerequisites: ["product-overview"] --- # Lieferanten verwalten Der Onboarding-Trichter, Nachbesserung statt Ablehnung — und warum eine Ablehnung nicht das Unternehmen meint. - Teil von: [Procurement Admin](https://academy.knowhow.io/personas/procurement-admin) (Modul 7 von 8), [Procurement User](https://academy.knowhow.io/personas/procurement-user) (Modul 7 von 7) - Dauer: 20 Min. - Niveau: Fortgeschritten - Vorher lesen: [Überblick über e-Request](https://academy.knowhow.io/learning/product-overview.md) - Als Nächstes: [Protokoll, Export und Schnittstellen](https://academy.knowhow.io/learning/protokoll-und-export.md) Der vorgesehene Weg ist einfach: **Der Einkauf lädt ein, der Lieferant füllt aus.** Es gibt keine offene Selbstregistrierung. ## Der Trichter Das Onboarding ist ein Trichter mit Mails in jedem Schritt. Der Lieferant sieht jederzeit, ob der Ball bei ihm liegt — und das ist der Punkt, der Ihnen Rückfragen erspart. Für unbekannte Lieferanten gibt es ein **Zugangsanfrage-Formular** mit Spamschutz. Es legt kein Konto an, sondern löst eine Mail an den Einkauf aus. Es lässt sich abschalten, wenn Sie den Kanal nicht wollen. Bei Schweizer Unternehmen können Stammdaten über die UID aus dem öffentlichen Handelsregister übernommen werden. Für Instanzen ohne ausgehendes Netz ist die Suche einzeln abschaltbar. ## Nachbesserung statt Ablehnung Der wichtigste Zustand im Trichter: Sie geben eine Registrierung **mit Pflichtbegründung** zurück. Der Lieferant sieht, dass er am Zug ist, und er sieht wofür — nicht denselben Zustand wie am ersten Tag. Das ist kein Detail. Es ist der Unterschied zwischen einem Lieferanten, der nachbessert, und einem, der anruft. ## Endgültige Ablehnung — und Wiederaufnahme Davon getrennt gibt es die endgültige Ablehnung als eigenen, abschliessenden Zustand. Sie bedeutet „passt nicht", nicht „bitte nachbessern", und sie ist aus jedem Zustand des Trichters erreichbar. Eine Ablehnung lässt sich später **wieder aufnehmen**. Der Lieferant startet dann erneut als Entwurf. Der Gedanke dahinter: Abgelehnt wurde die Qualifikation, nicht die Firma — Umstände ändern sich. ## Sperren, archivieren, reaktivieren Sperren und Entsperren, Archivieren und Reaktivieren stehen zur Verfügung. Eine Reaktivierung führt dorthin zurück, wo der Lieferant war, und nicht pauschal nach „freigegeben" — wer einmal im Trichter stecken geblieben ist, steckt danach an derselben Stelle. ## Hauptkontakt und Stellvertretung Ein Lieferant hat einen Hauptkontakt und optional eine Stellvertretung. Fachlich dürfen beide dasselbe; verwalten darf nur der Hauptkontakt. Die Stellvertretung kann mit oder ohne eigenen Zugang geführt werden. Weisen Sie darauf hin, wenn Sie einladen. Es ist die günstigste Massnahme gegen die häufigste Ausrede — „die Kollegin war in den Ferien". ## Was es hier nicht gibt - **Keine Lieferantenbewertung und keine Lieferanten-Analytics.** Das SRM-Modul ist in Entwicklung und nicht eingeschaltet. Wenn das für Sie zentral ist, sagen Sie es uns — es wird als Nachfrage gemessen, nicht geschätzt. - **Kein Screening** gegen Sanktions-, PEP- oder ESG-Listen und keine namentliche Abdeckung von Lieferkettenregulatorik. Was das Produkt tut, ist Angaben und Nachweise **strukturiert erheben**. Ob Sie damit konform sind, entscheidet Ihre Rechtsabteilung, nicht die Software. - **Kein offener Marktplatz.** Ihre Lieferantendaten bleiben in Ihrer Instanz. --- title: "Protokoll, Export und Schnittstellen" description: "Was nachvollziehbar ist, was Sie herausbekommen — und was es an Integration nicht gibt." lang: "de" url: "https://academy.knowhow.io/learning/protokoll-und-export" persona: ["procurement-admin"] level: "advanced" estimated_time: 20 prerequisites: ["user-management"] --- # Protokoll, Export und Schnittstellen Was nachvollziehbar ist, was Sie herausbekommen — und was es an Integration nicht gibt. - Teil von: [Procurement Admin](https://academy.knowhow.io/personas/procurement-admin) (Modul 8 von 8) - Dauer: 20 Min. - Niveau: Vertiefung - Vorher lesen: [Benutzer und Zugänge](https://academy.knowhow.io/learning/user-management.md) Drei Fragen, die in jeder Einführung kommen: Was ist nachvollziehbar? Wie komme ich an meine Daten? Und wie hängt das an unseren übrigen Systemen? ## Protokoll Über die Geschäftsobjekte hinweg wird umfassend protokolliert, und jede Ausschreibung hat zusätzlich ihre eigene Protokollansicht — das ist die, die im Ernstfall gebraucht wird. Zwei Einschränkungen, die Sie kennen sollten, bevor jemand anderes sie findet: - Protokolliert wird über die Geschäftsobjekte, nicht über jeden Klick. - Aktionen des System-Administrators sind herausgefiltert. Es ist also ein **umfassendes Activity Log über alle Geschäftsobjekte** — und bewusst nicht mehr als das. Wenn Ihre Revision eine wirklich vollständige Aufzeichnung jeder Aktion verlangt, ist das eine Anforderung, die Sie vor der Einführung klären sollten, nicht danach. ## Export **CSV und XLS von Listen** — Ausschreibungen, Lieferanten. Kostenlos, in jedem Tarif. Was das nicht ist: ein Berichtswesen. Es gibt keinen Berichtsexport und kein PDF. Wer eine Auswertung braucht, exportiert die Liste und wertet sie dort aus, wo Ihr Haus ohnehin auswertet. Auf dem Dashboard gibt es Kennzahlkacheln und einen Aktivitäts-Feed. Die Kacheln sind **Zählungen** — Mengen und Durchlaufzeiten. Eine Einsparungsberechnung gibt es nicht, in keiner Form. ## Webhooks Kostenlos, mit Signatur, für `offer.submitted`, `contract.signed` und `supplier.approved`. Formate generisch, dazu Slack und Mattermost. Aus den Einstellungen lässt sich ein Webhook testweise auslösen — tun Sie das, bevor Sie sich auf ihn verlassen. ## REST-API und MCP Beide **kostenpflichtig** und beide verfügbar: - **REST-API** (`/api/v1`): lesend und schreibend für Ausschreibungen, Lieferanten und Kategorien. **Angebote bleiben lesend** — ein Angebot entsteht im Lieferantenportal und nirgends sonst. - **MCP-Anschluss**: acht **nur lesende** Werkzeuge über Ausschreibungen, Angebote, Lieferanten und Fragerunden, auf denselben Schlüsseln und denselben Berechtigungen. Der MCP-Anschluss ist der Punkt, an dem Sie Ihre eigene KI andocken können. Wir liefern die Schnittstelle, nicht das Modell — welches Sie einsetzen, entscheiden Sie. **In e-Request selbst steckt keine KI**, und wir behaupten es bewusst nicht. Beide müssen in der Lizenz stehen. Und noch einmal, weil es der teuerste Irrtum ist: ein Schlüssel sieht mandantenweit alles. ## Was es an Integration nicht gibt Es gibt **keine fertige Anbindung an SAP, Ariba, Oracle oder Salesforce**. Kein ERP-Konnektor, in keinem Tarif, auch nicht als Option. Was es gibt, ist die REST-API, sind Webhooks und ist der Export. Wenn eine ERP-Anbindung für Sie Bedingung ist, ist das ein Projekt auf Ihrer Seite oder bei einem Integrator — planen Sie es als solches. --- title: "Bedarf melden" description: "Eine Anfrage so erfassen, dass die Beschaffung nicht nachfragen muss." lang: "de" url: "https://academy.knowhow.io/learning/creating-requests" persona: ["procurement-user", "department-user"] level: "beginner" estimated_time: 15 prerequisites: ["product-overview"] --- # Bedarf melden Eine Anfrage so erfassen, dass die Beschaffung nicht nachfragen muss. - Teil von: [Procurement User](https://academy.knowhow.io/personas/procurement-user) (Modul 2 von 7), [Fachbereich](https://academy.knowhow.io/personas/department-user) (Modul 2 von 3) - Dauer: 15 Min. - Niveau: Einstieg - Vorher lesen: [Überblick über e-Request](https://academy.knowhow.io/learning/product-overview.md) - Als Nächstes: [Ausschreibung erstellen](https://academy.knowhow.io/learning/ausschreibung-erstellen.md) Die meisten Verzögerungen entstehen nicht in der Beschaffung, sondern davor: bei einer Anfrage, die noch Rückfragen auslöst. ## Was in eine gute Anfrage gehört - Was genau benötigt wird — und wofür - Bis wann - Welche Anforderungen nicht verhandelbar sind, und welche Wünsche sind - Wer fachlich Auskunft geben kann, mit erreichbarer Nummer Die Trennung zwischen „nicht verhandelbar" und „wünschenswert" ist die wertvollste Zeile in Ihrer Anfrage. Aus ihr entstehen später die Zuschlagskriterien und deren Gewichtung — wenn Sie sie nicht liefern, rät der Einkauf. ## Die richtige Kategorie Ordnen Sie Ihren Bedarf einer Kategorie zu. Das ist keine Formalie: Über die Kategorie findet der Einkauf, wer dafür überhaupt in Frage kommt, und später findet man Ihre Beschaffung darüber wieder. ## Realistisch terminieren Zwischen Ihrer Anfrage und einem unterschriebenen Vertrag liegen mehrere Schritte, die nicht in Ihrer Hand sind: interne Freigabe, Einladung, eine Fragerunde mit Frist, die Einreichung selbst, dann die Bewertung. Nennen Sie deshalb das Datum, an dem Sie die Leistung **brauchen**, nicht das Datum, an dem Sie sie gern hätten. Und nennen Sie es früh — die Fragerunde lässt sich nicht abkürzen, ohne die Vergleichbarkeit der Angebote zu verlieren. ## Faustregel Wenn jemand aus einer anderen Abteilung Ihre Anfrage liest und keine Rückfrage stellen muss, ist sie vollständig. --- title: "Ausschreibung erstellen" description: "Vom Bedarf zur publizierten Ausschreibung — Erfassung, interne Freigabe und Einladung." lang: "de" url: "https://academy.knowhow.io/learning/ausschreibung-erstellen" persona: ["procurement-user"] level: "intermediate" estimated_time: 25 prerequisites: ["creating-requests"] --- # Ausschreibung erstellen Vom Bedarf zur publizierten Ausschreibung — Erfassung, interne Freigabe und Einladung. - Teil von: [Procurement User](https://academy.knowhow.io/personas/procurement-user) (Modul 3 von 7) - Dauer: 25 Min. - Niveau: Fortgeschritten - Vorher lesen: [Bedarf melden](https://academy.knowhow.io/learning/creating-requests.md) - Als Nächstes: [Fragerunde führen](https://academy.knowhow.io/learning/fragerunde-fuehren.md) Die Ausschreibung ist der Punkt, an dem aus einem Bedarf ein Verfahren wird. Was hier unklar bleibt, kostet Sie in der Fragerunde Zeit und in der Bewertung Vergleichbarkeit. ## Erfassen Ein mehrstufiger Assistent führt durch die Anlage; Dokumente hängen Sie direkt an. Upload und Löschung werden protokolliert — auch das Entfernen einer Datei bleibt sichtbar. Für eine Korrektur brauchen Sie nicht das ganze Formular: Einzelne Felder lassen sich direkt in der Ansicht bearbeiten. ## Duplizieren statt Vorlagen Es gibt **keine Vorlagen**. Stattdessen duplizieren Sie eine bestehende Ausschreibung. Das klingt nach weniger, ist in der Praxis aber mehr: Eine Kopie startet mit echten, bereits einmal bewährten Inhalten statt mit einem Gerüst aus Platzhaltern. Legen Sie sich für wiederkehrende Beschaffungen bewusst eine „gute" Ausschreibung an, die Sie jedes Mal kopieren. ## Interne Freigabe Vor der Publikation steht die interne Freigabe. Eine Rückweisung wird **mit Begründung dokumentiert** — das ist kein Formalismus, sondern der Moment, den eine Revision später am häufigsten ansieht. Rechnen Sie die Freigabe in Ihren Zeitplan ein. Sie ist der häufigste Grund, warum eine Ausschreibung später rausgeht als geplant. ## Lieferanten einladen Sie laden ein — es gibt keine offene Selbstregistrierung, bei der sich jemand von sich aus auf Ihre Ausschreibung bewirbt. Eingeladene lassen sich auch nachträglich hinzufügen oder entfernen. Wenn Ihr Haus das Zugangsanfrage-Formular aktiviert hat, können unbekannte Lieferanten sich melden. Das legt **kein Konto** an; es löst eine Nachricht an den Einkauf aus, und Sie entscheiden. ## Wenn sich etwas ändert Eine Änderungsmitteilung an alle Eingeladenen wird **manuell ausgelöst** — sie passiert nicht von selbst, wenn Sie ein Dokument austauschen. Machen Sie es sich zur Regel: Jede Änderung nach der Publikation wird mitgeteilt. Ein Lieferant, der auf dem alten Stand kalkuliert, reicht ein Angebot ein, das Sie nicht brauchen können — und beide Seiten haben die Arbeit umsonst gemacht. ## Übersicht behalten Filter und Suche gehen über alle Ausschreibungen. Abgeschlossene sind standardmässig ausgeblendet, was die Liste kurz hält; wer sie sucht, blendet sie ein. --- title: "Fragerunde führen" description: "Fragen sammeln, freigeben und allen gemeinsam beantworten — der Schritt, der Gleichbehandlung zur Funktion macht." lang: "de" url: "https://academy.knowhow.io/learning/fragerunde-fuehren" persona: ["procurement-user"] level: "intermediate" estimated_time: 15 prerequisites: ["ausschreibung-erstellen"] --- # Fragerunde führen Fragen sammeln, freigeben und allen gemeinsam beantworten — der Schritt, der Gleichbehandlung zur Funktion macht. - Teil von: [Procurement User](https://academy.knowhow.io/personas/procurement-user) (Modul 4 von 7) - Dauer: 15 Min. - Niveau: Fortgeschritten - Vorher lesen: [Ausschreibung erstellen](https://academy.knowhow.io/learning/ausschreibung-erstellen.md) - Als Nächstes: [Angebote bewerten](https://academy.knowhow.io/learning/evaluating-offers.md) Die Fragerunde ist der Teil des Verfahrens, in dem Gleichbehandlung keine Absicht mehr ist, sondern ein Mechanismus. ## Wie es abläuft Eingeladene Lieferanten stellen Fragen. Sie beantworten sie, geben die Antworten frei und publizieren sie **gesammelt an alle** Eingeladenen — auf Knopfdruck, gleichzeitig. Die Frage selbst wird dabei sichtbar, wer sie gestellt hat nicht. ## Warum das mehr ist als Bequemlichkeit Der klassische Fehler im Beschaffungsalltag ist die Antwort per Mail an einen Anbieter. Sie ist schnell, sie fühlt sich hilfreich an — und sie verschafft einem Anbieter einen Wissensvorsprung, den niemand mehr nachvollziehen kann. Hier ist der Weg über die Fragerunde der bequemere. Das ist die eigentliche Leistung: Fairness kostet keine Disziplin. ## Was Sie steuern - **Freigabe vor Publikation.** Sie entscheiden, was rausgeht — eine Frage, die Betriebsgeheimnisse des Fragenden enthielte, wird umformuliert und nicht wortwörtlich publiziert. - **Sammelpublikation.** Mehrere Fragen zusammen beantworten spart Ihnen Zeit und den Anbietern Verwirrung. - **Zeitpunkt.** Die Fragerunde endet vor der Einreichungsfrist, sonst kalkuliert jemand auf einer Antwort, die er nicht mehr einarbeiten kann. ## Was in die Fragerunde gehört — und was nicht Alles, was die Ausschreibung betrifft, gehört hinein. Anliegen, die nur einen Anbieter betreffen — ein Zugangsproblem etwa — gehören in den direkten Kontakt. Wenn eine Frage zeigt, dass Ihre Unterlagen unklar sind, ist die Antwort selten die beste Lösung: Dann ist eine **Änderungsmitteilung** an alle die sauberere, weil sie den Text korrigiert statt ihn zu kommentieren. ## Für die nächste Ausschreibung Wiederkehrende Fragen sind die beste verfügbare Rückmeldung zur Qualität Ihrer Unterlagen. Was dreimal gefragt wurde, gehört beim nächsten Mal in den Text — und weil Sie ohnehin duplizieren, ist die Verbesserung dauerhaft. --- title: "Angebote bewerten" description: "Kriterien gewichten, unabhängig bewerten und die Entscheidung nachvollziehbar dokumentieren." lang: "de" url: "https://academy.knowhow.io/learning/evaluating-offers" persona: ["procurement-user"] level: "advanced" estimated_time: 25 prerequisites: ["fragerunde-fuehren"] --- # Angebote bewerten Kriterien gewichten, unabhängig bewerten und die Entscheidung nachvollziehbar dokumentieren. - Teil von: [Procurement User](https://academy.knowhow.io/personas/procurement-user) (Modul 5 von 7) - Dauer: 25 Min. - Niveau: Vertiefung - Vorher lesen: [Fragerunde führen](https://academy.knowhow.io/learning/fragerunde-fuehren.md) - Als Nächstes: [Zuschlag und Vertrag](https://academy.knowhow.io/learning/zuschlag-und-vertrag.md) Die Bewertung ist der Schritt, bei dem sich rächt, was in der Ausschreibung unklar formuliert war. Sie ist auch der Schritt, den eine Revision zuerst ansieht. Die Angebotsbewertung ist eine **kostenpflichtige Erweiterung**. Wenn die folgenden Funktionen bei Ihnen fehlen, liegt es daran und nicht an einer Einstellung. ## Kriterien und Gewichtung Kriterien werden mit einer Gewichtung in Prozent hinterlegt. Als Typen gibt es Zahl, Preis, Freitext und Auswahlliste. Für den Preis stehen zwei Formeln zur Verfügung: **linear** und **degressiv** mit einem Cutoff bei 20 Prozent. Das ist deutlich mehr als „billigster Preis gewinnt", und es lohnt sich, die Wirkung einmal an alten Zahlen durchzuspielen, bevor Sie sich für eine entscheiden. Sie können mehrere benannte Bewertungsstrategien führen; zwei Standardstrategien werden automatisch angelegt. ## Jede Person bewertet für sich Das ist die Funktion, mit der niemand rechnet: Es gibt **Bewertungsrunden pro Person**. Mehrere bewerten unabhängig voneinander, danach gibt es eine Vergleichsansicht. Der Unterschied zur Tabellenkalkulation im Netzlaufwerk ist nicht die Bequemlichkeit, sondern dass niemand die Bewertung der anderen sieht, bevor er seine eigene abgegeben hat. Diskutiert wird danach — über Abweichungen, nicht darüber, wer zuletzt gespeichert hat. ## Entscheiden Shortlist, Gewinnervorschlag, Bestätigung, Widerruf: vier Schritte, und die Trennung zwischen Vorschlag und Bestätigung ist das Vier-Augen-Prinzip. Ein Widerruf ist vorgesehen und dokumentiert. Interne Notizen an Angeboten bleiben **intern**. Der Lieferant sieht sie nie — was für ihn bestimmt ist, geht als Nachricht oder als Begründung raus. Nicht jede Auswertung endet mit einem Gewinner. Schliessen Sie ohne Zuschlag ab, bekommen alle Teilnehmer eine Mail. Muss ein Verfahren vorzeitig enden — der Bedarf fällt weg, die Unterlagen waren falsch —, **ziehen Sie die Ausschreibung zurück**. Das geht nach der Publikation jederzeit, auch nach Ende der Angebotsfrist, und nur für den Einkauf. Den Grund halten Sie intern fest; die Lieferanten erfahren ihn nicht, bekommen aber sofort eine Mail. Der Schritt lässt sich nicht rückgängig machen, nicht eingereichte Angebotsentwürfe werden gelöscht, und ein Neustart ist eine Kopie der Ausschreibung. Danach zeigt jede abgeschlossene Ausschreibung ihr Ergebnis: mit Zuschlag, ohne Zuschlag oder abgebrochen. ## Was es nicht gibt - **Keine Nebeneinander-Ansicht von Szenarien.** Mehrere Gewichtungsmodelle sind möglich, eine Gegenüberstellung in einem Bild ist es nicht. - **Keine Einsparungsberechnung.** Die Kacheln auf dem Dashboard zählen, sie rechnen nicht. - **Keine Fallakte über mehrere Ablehnungsrunden** auf der Lieferantenseite: Der Grund der letzten Runde ist dokumentiert, die Historie darüber nicht. Und wer abgelehnt hat, sieht ein Lieferant nie. ## Womit Sie sich Arbeit sparen Legen Sie die Kriterien **vor** der Publikation fest und schreiben Sie sie in die Ausschreibung. Kriterien, die erst beim Vergleich entstehen, sind schwer zu begründen — und genau danach wird gefragt, wenn ein unterlegener Anbieter nachhakt. --- title: "Zuschlag und Vertrag" description: "Vom bestätigten Gewinner zum unterzeichneten Vertrag — und was die Unterschrift im Portal rechtlich ist." lang: "de" url: "https://academy.knowhow.io/learning/zuschlag-und-vertrag" persona: ["procurement-user"] level: "advanced" estimated_time: 20 prerequisites: ["evaluating-offers"] --- # Zuschlag und Vertrag Vom bestätigten Gewinner zum unterzeichneten Vertrag — und was die Unterschrift im Portal rechtlich ist. - Teil von: [Procurement User](https://academy.knowhow.io/personas/procurement-user) (Modul 6 von 7) - Dauer: 20 Min. - Niveau: Vertiefung - Vorher lesen: [Angebote bewerten](https://academy.knowhow.io/learning/evaluating-offers.md) - Als Nächstes: [Lieferanten verwalten](https://academy.knowhow.io/learning/lieferanten-verwalten.md) Nach der Bestätigung des Gewinners informieren Sie die Anbieter. Was danach passiert, hängt davon ab, ob Ihr Haus das Vertragsmodul einsetzt — es ist **kostenpflichtig** und nicht überall im Einsatz. ## Vom Angebot zum Vertrag Aus einem gewonnenen Angebot entsteht ein Vertrag. Es geht auch ohne Ausschreibung: Bestandsverträge, die nur überwacht werden sollen, lassen sich direkt anlegen. Wo ein Vertrag steht, zeigt die Vertragsseite. Wichtiger ist, was Sie von dort aus tun können: die Unterschrift anfordern, eine offene Anfrage zurückziehen, nach einer Ablehnung erneut anfordern — und später kündigen. ## Die Unterschrift Sie fordern die Unterschrift an, der Lieferant bestätigt **im Portal**. Die Bestätigung erfolgt per Klick und wird mit Zeitstempel protokolliert. **Das ist keine qualifizierte elektronische Signatur** nach ZertES oder eIDAS. Für die meisten Beschaffungen ist das genau richtig. Wenn für einen Vertrag eine qualifizierte Signatur verlangt ist, klären Sie das mit Ihrer Rechtsabteilung, bevor Sie die Anfrage stellen — es ist eine vertragliche Frage, keine technische. Lehnt der Lieferant ab, ist das ein regulärer Schritt: Sie passen an und fordern erneut an. Merken Sie nach dem Versand, dass am Vertrag noch etwas nicht stimmt, ziehen Sie die Anfrage zurück. Der Lieferant bekommt eine Mail. Erneut versenden lässt sich der Vertrag erst, nachdem Sie ihn auf den Entwurf zurückgesetzt und angepasst haben. ## Kündigen Einen unterzeichneten Vertrag können Sie in e-Request kündigen. Das Wirksamkeitsdatum ist Pflicht; einen Kommentar und das Kündigungsschreiben können Sie mitgeben. Der Lieferant bekommt eine Mail, der Vertrag wird inaktiv und fällt aus der Fristenüberwachung. Kündigen kann auch der Lieferant, aus seinem Portal — dann bekommen Sie die Mail. **e-Request erfasst die Kündigung, es spricht sie nicht aus.** Rechtswirksam wird sie wie bisher über Ihr Kündigungsschreiben und die Fristen im Vertrag. ## Fristen und Lieferungen Zum Vertrag gehören Vertragsnummer, Vertragswert und Verlängerungsoption. Die Fristenüberwachung erinnert und führt eine Liste auf dem Dashboard. **Die Erinnerungen sind intern.** Der Lieferant wird nicht erinnert — wer das erwartet, wartet auf etwas, das nicht kommt. Für Lieferungen lassen sich Soll- und Ist-Datum, eine Bemerkung und die Abnahme festhalten: noch offen, abgenommen, unter Vorbehalt abgenommen oder verweigert. ## Was Sie einem Anbieter sagen können Und was nicht: Der Grund der letzten Ablehnungsrunde ist für den Lieferanten sichtbar. Wer intern entschieden hat, sieht er nie, und eine Historie über mehrere Runden gibt es nicht. Interne Notizen bleiben intern — auch die am Angebot. Was den Anbieter erreichen soll, geht als Nachricht raus. ## Wenn Ihr Haus das Modul nicht hat Dann endet e-Request beim Zuschlag, und der Vertrag läuft auf Ihrem üblichen Weg. Das ist kein Sonderfall; sagen Sie es Ihren Lieferanten nur, damit niemand auf eine Unterschriftsanfrage im Portal wartet. --- title: "Status verfolgen" description: "Wo Ihre Anfrage steht, was Sie sehen dürfen — und was Ihnen bewusst nicht angezeigt wird." lang: "de" url: "https://academy.knowhow.io/learning/tracking-status" persona: ["department-user"] level: "beginner" estimated_time: 15 prerequisites: ["creating-requests"] --- # Status verfolgen Wo Ihre Anfrage steht, was Sie sehen dürfen — und was Ihnen bewusst nicht angezeigt wird. - Teil von: [Fachbereich](https://academy.knowhow.io/personas/department-user) (Modul 3 von 3) - Dauer: 15 Min. - Niveau: Einstieg - Vorher lesen: [Bedarf melden](https://academy.knowhow.io/learning/creating-requests.md) Nach dem Absenden ist die häufigste Frage: „Und jetzt?" ## Wo Sie nachsehen - **Aufgabenliste und Kalenderansicht** — was von Ihnen erwartet wird und wann. - **Aktivitäts-Feed** auf dem Dashboard — was zuletzt passiert ist. - **Globale Suche** — über alles, wozu Sie berechtigt sind. Die Kennzahlkacheln auf dem Dashboard sind **Zählungen**: Mengen und Durchlaufzeiten. Sie sind keine Auswertung und schon gar keine Einsparungsrechnung — eine solche gibt es im Produkt nicht. ## Wer ist am Zug Jede Anfrage hat zu jedem Zeitpunkt genau eine zuständige Stelle. Wenn Sie wissen, welche das ist, wissen Sie auch, wen Sie ansprechen. Zwischen Einladung und Einreichung liegt der Ball beim Lieferanten, und dort kann ihn niemand beschleunigen: Die Fristen sind gesetzt, und sie zu verkürzen würde die Vergleichbarkeit der Angebote zerstören. ## Was Sie sehen — und was nicht Das überrascht regelmässig, deshalb ausdrücklich: Sie sehen **alle Lieferanten**, samt Zuständen und Kontaktdaten. Wer einen Bedarf formuliert, soll wissen, mit wem das Haus arbeitet. Sie sehen **nicht**: - Preise und Angebotsdetails fremder Ausschreibungen - Qualifikationsdaten der Lieferanten Und es gibt **kein direktes Kontaktformular zum Lieferanten**. Das ist keine Bequemlichkeitslücke: Ein laufendes Verfahren darf nicht ausserhalb des Verfahrens beeinflusst werden. Wenn Sie fachlich etwas klären müssen, geht das über den Einkauf und, wo es alle betrifft, über die Fragerunde — dort bekommen alle Anbieter dieselbe Antwort. ## Wie eine Ausschreibung endet Eine abgeschlossene Ausschreibung zeigt ihr Ergebnis: _Abgeschlossen mit Zuschlag_, _Beendet ohne Zuschlag_ oder _Abgebrochen_. Abgebrochen heisst, der Einkauf hat sie zurückgezogen. Das kann nur er, und es lässt sich nicht rückgängig machen — ein Neustart ist eine Kopie. Fällt Ihr Bedarf weg, sagen Sie es deshalb dem Einkauf, statt die Ausschreibung auslaufen zu lassen. Die Lieferanten bekommen dann eine klare Mail statt einer Absage, die keine ist. ## Wann nachfragen sinnvoll ist Nicht bei jedem Schritt — aber dann, wenn ein Termin näher rückt, den Sie zugesagt haben. Ein kurzer Hinweis mit Datum ist wirksamer als eine allgemeine Nachfrage. ## Mobil Die Oberfläche ist für Mobilgeräte ausgelegt; eine eigene App gibt es nicht. Für einen Blick auf den Status reicht das Telefon, für das Erfassen eines Bedarfs ist ein Rechner die bessere Wahl. --- title: "An overview of e-Request" description: "What the platform is for, who works in it, and how a procurement runs from request to contract." lang: "en" url: "https://academy.knowhow.io/en/learning/product-overview" persona: ["procurement-admin", "procurement-user", "department-user"] level: "beginner" estimated_time: 10 --- # An overview of e-Request What the platform is for, who works in it, and how a procurement runs from request to contract. - Part of: [Procurement Admin](https://academy.knowhow.io/en/personas/procurement-admin) (Module 1 of 8), [Procurement User](https://academy.knowhow.io/en/personas/procurement-user) (Module 1 of 7), [Department User](https://academy.knowhow.io/en/personas/department-user) (Module 1 of 3) - Duration: 10 min - Level: Getting started - Read first: No prerequisites - Next up: [Set up the organisation](https://academy.knowhow.io/en/learning/setup-organization.md) Before you configure or enter anything, it is worth looking at the process as a whole. ## Who is involved - **Department** raises a need and follows it. - **Procurement** runs the purchase: tender, question round, evaluation, award. - **Admin** sets up the organisation, manages roles and access, and maintains categories, criteria and templates. - **Suppliers** work in a portal of their own — they never see your internal view. These three roles exist in the product exactly as listed. They are not a suggested org chart; they are the permission model. ## The process 1. A **need** arises in a department. 2. A **tender** is created, with documents, and approved internally. 3. **Suppliers are invited** — procurement invites, there is no open self-registration. 4. **Question round**: questions are collected, answered, approved and published to **all** invitees together. 5. **Offers** are created and submitted in the supplier portal. 6. **Evaluation** against criteria weighted in advance. 7. **Award** and, where the contract module is in use, the contract. ## The process is fixed on purpose This is where e-Request differs from a toolkit: **the steps are hard-wired.** You cannot rearrange them, and that is the intent — a procedure that runs the same way every time is exactly what an audit can follow two years later. What you can adapt is roles, rights, fields, criteria and templates. Not what happens in which order. Anyone expecting to bend the process around an existing special case should know that early, which is why it is here and not in a footnote. ## What is logged Activity is logged comprehensively across the business objects, and every tender has its own log view. That is the second reason the fixed process pays: traceability comes from the software rather than from discipline. ## What to read next Depending on your role: as an **admin**, start by setting up the organisation. As **procurement**, start at the tender. As a **department**, the path from raising a need to tracking it is enough. --- title: "Set up the organisation" description: "Departments, permission levels and the category tree, arranged so that maintaining them later has no special cases." lang: "en" url: "https://academy.knowhow.io/en/learning/setup-organization" persona: ["procurement-admin"] level: "intermediate" estimated_time: 20 prerequisites: ["product-overview"] --- # Set up the organisation Departments, permission levels and the category tree, arranged so that maintaining them later has no special cases. - Part of: [Procurement Admin](https://academy.knowhow.io/en/personas/procurement-admin) (Module 2 of 8) - Duration: 20 min - Level: Intermediate - Read first: [An overview of e-Request](https://academy.knowhow.io/en/learning/product-overview.md) - Next up: [Roles and permissions](https://academy.knowhow.io/en/learning/rollen-und-rechte.md) The structure decides how easy permissions are to maintain later. It is worth being slow here. ## Departments and permission levels Departments mirror your organisation. Each one has three levels: - **Member** — works in the department - **Reader** — sees along, without acting - **Lead** — is accountable for the department Only create what you are willing to maintain. Every extra department is another list that wants updating whenever someone changes job. ## The category tree Categories organise your purchases — and they can be mapped to the **CPV-2008** classification. If you buy in the public sector, this is where your internal structure connects to the official one. Start coarse. A tree with forty branches, thirty of which are never used, only makes the choice harder for everyone else. ## Two mistakes that hurt later - **Too fine a structure.** Every unit you create is one you will also have to maintain. - **People instead of roles.** Rights hung on individuals get rebuilt at every staff change. ## What does not belong here The **process** of a procurement. It is hard-wired and not part of setup — see **What is configurable, and what is not**. Using the organisation structure to reproduce a special process builds something the software does not know about. Done when you can explain the structure to a colleague in two minutes. --- title: "Roles and permissions" description: "The three roles, what a department sees — and what it deliberately does not." lang: "en" url: "https://academy.knowhow.io/en/learning/rollen-und-rechte" persona: ["procurement-admin"] level: "intermediate" estimated_time: 15 prerequisites: ["setup-organization"] --- # Roles and permissions The three roles, what a department sees — and what it deliberately does not. - Part of: [Procurement Admin](https://academy.knowhow.io/en/personas/procurement-admin) (Module 3 of 8) - Duration: 15 min - Level: Intermediate - Read first: [Set up the organisation](https://academy.knowhow.io/en/learning/setup-organization.md) - Next up: [Sign-in and SSO](https://academy.knowhow.io/en/learning/anmeldung-und-sso.md) There are three roles: **Admin**, **Procurement** and **Department**. They are built into the product; you assign people to them, you do not invent a fourth. ## Who does what - **Admin** — organisation, roles, access, categories, criteria, templates, branding, system settings. - **Procurement** — runs purchases: tender, supplier invitations, question round, evaluation, award. - **Department** — raises needs and tracks them. ## What a department sees, and what it does not This boundary is the one most often misjudged, so in full: A department sees **every supplier**, including their states and contact details. That is deliberate: whoever formulates a need should know who the organisation actually works with. Not visible: - **Prices and offer details from other tenders** - Suppliers' **qualification data** Also absent: a direct contact form to a supplier. Contact runs through procurement — not out of convenience, but because a running procedure must not be influenced outside the procedure. ## If that is too coarse for you Permissions are role- and department-based. There is no finer cut — nothing like "this person sees only this one category". Plan around that rather than waiting for it. The same holds for the interfaces: an API key sees **everything across the tenant**, with no departmental slice. Issuing a service account grants read access to the whole tenant. ## Role changes Roles belong to functions, not to people. Changing an assignment is a single edit — that is the entire benefit, and it disappears as soon as exceptions get maintained. **One special case:** if your instance runs with SSO, the application does not own the role, your identity provider does. What you see here is then a display, not an administration surface — see **Sign-in and SSO**. --- title: "Sign-in and SSO" description: "Two sign-in modes that exclude each other — and what your identity provider has to do with it." lang: "en" url: "https://academy.knowhow.io/en/learning/anmeldung-und-sso" persona: ["procurement-admin"] level: "advanced" estimated_time: 20 prerequisites: ["rollen-und-rechte"] --- # Sign-in and SSO Two sign-in modes that exclude each other — and what your identity provider has to do with it. - Part of: [Procurement Admin](https://academy.knowhow.io/en/personas/procurement-admin) (Module 4 of 8) - Duration: 20 min - Level: In depth - Read first: [Roles and permissions](https://academy.knowhow.io/en/learning/rollen-und-rechte.md) - Next up: [What is configurable, and what is not](https://academy.knowhow.io/en/learning/was-konfigurierbar-ist.md) An instance runs either with **SSO** or with **user management inside the application**. Not both, and there is no fallback from one to the other. That decision is made before you go live. Reversing it afterwards is not a switch. ## The normal case: SSO e-Request speaks **OIDC against Keycloak**. If you do not run identity management of your own, a managed Keycloak instance comes with it. **Important:** with SSO active, Keycloak owns the role. The application displays it, it does not manage it. Changing roles then happens in the identity provider — and anyone who does not know that will look for the setting in the wrong interface. ## If you use Entra ID or AD FS Those speak SAML. **e-Request itself implements no SAML.** Your SAML identity provider is connected through Keycloak as a federated provider — Keycloak does the brokering, not the application. This works and is the intended route. But it is a **service**, not a checkbox: the connection belongs in the planning and in the quote. Do not assume it is "included". ## The other mode: user management in the application An instance can also run with no identity provider at all: invitation by email, password, and a lockout against automated guessing. Roles then live in the application. ## The supplier side is unaffected Suppliers **always** sign in with a username and password, whatever mode your buying side runs. There is no SSO on the supplier side, and that is a decision rather than a gap: a supplier works for many buyers, and an account per portal is the approach that works everywhere. So never promise a supplier they can sign in with their company account. ## Ending access Access is **deactivated, not deleted** — on both sides. Anyone who has acted stays traceable in the log while being out of day-to-day operation immediately. See **Users and access**. --- title: "What is configurable, and what is not" description: "The process is fixed — templates, criteria, categories and branding are not. Where the line runs." lang: "en" url: "https://academy.knowhow.io/en/learning/was-konfigurierbar-ist" persona: ["procurement-admin"] level: "intermediate" estimated_time: 20 prerequisites: ["setup-organization"] --- # What is configurable, and what is not The process is fixed — templates, criteria, categories and branding are not. Where the line runs. - Part of: [Procurement Admin](https://academy.knowhow.io/en/personas/procurement-admin) (Module 5 of 8) - Duration: 20 min - Level: Intermediate - Read first: [Set up the organisation](https://academy.knowhow.io/en/learning/setup-organization.md) - Next up: [Users and access](https://academy.knowhow.io/en/learning/user-management.md) The most common expectation of a procurement platform is that it adapts to your process. With e-Request it is the other way round, deliberately. ## Hard-wired **The process.** Tender, internal approval, invitation, question round, offers, evaluation, award — in that order, every time. This is not an open building site. It is the compliance benefit: a procedure that runs the same way every time can be followed two years later. A configurable process could not, because then every tender would have its own history. If your organisation has a special process, that is a decision to take before rollout — not a setting to hunt for. ## What you set yourself - **Categories**, including their CPV mapping - **Evaluation criteria** for offers and suppliers, with weighting - **Email templates** — around thirty of them, in German and English, with preview and test send - **Branding** — your appearance in the portal - **Roles and permissions**, departments and permission levels - **Fields**, as far as the product provides for them None of this needs anyone from us. ## The test send is the important small thing Email templates are what your suppliers see first — often before they ever enter the platform. Use the preview and the test send before a template goes live. An invitation with a placeholder still in it is a first impression you cannot take back. German and English are fully maintained. The interface exists in more languages; the templates in these two. ## What does not exist So that nobody goes looking: - **No tender templates.** Instead you **duplicate** an existing tender — that is the answer to "do you have templates?", and in practice the better one, because a copy starts from real content. - **No industry packages.** The product is generic and is tailored to you through categories and criteria. - **No freely configurable approval stages.** Internal approval exists, with documented rejection — it is one step, not a chain you assemble. ## Plan limits There is a page showing licence and limit values — users, suppliers. It **displays**; it does not enforce. Nobody is locked out for crossing a limit. Treat the numbers as information for your planning, not as a safeguard. --- title: "Users and access" description: "Granting access, handling departures cleanly — and what a service account is actually allowed to do." lang: "en" url: "https://academy.knowhow.io/en/learning/user-management" persona: ["procurement-admin"] level: "intermediate" estimated_time: 15 prerequisites: ["anmeldung-und-sso"] --- # Users and access Granting access, handling departures cleanly — and what a service account is actually allowed to do. - Part of: [Procurement Admin](https://academy.knowhow.io/en/personas/procurement-admin) (Module 6 of 8) - Duration: 15 min - Level: Intermediate - Read first: [Sign-in and SSO](https://academy.knowhow.io/en/learning/anmeldung-und-sso.md) - Next up: [Manage suppliers](https://academy.knowhow.io/en/learning/lieferanten-verwalten.md) User management is little work — as long as it is done regularly. ## Recurring tasks - Take on new staff and assign them a role - Follow up role changes - Deactivate departures If your instance runs with SSO, creating and assigning happens in your identity provider. The list here is then a review view, not an administration surface. ## Deactivate, do not delete Access is deactivated. An account never disappears from the log, only from operation — otherwise all traceability would vanish the day someone leaves. That applies to your own people and to supplier access alike. ## The quarterly pass Put a recurring appointment in the calendar — once a quarter is enough — and walk the list of active accounts. Ten minutes, and the big clean-up never happens. ## Service accounts Interfaces use service accounts with API keys: issue, rotate, revoke. Two things worth knowing without being asked: - **A key sees everything across the tenant.** There is no departmental slice. Issuing a service account grants access to the whole tenant, not to a section of it. - The same key carries both the REST API **and** the MCP connection. Enabling one enables both, where licensed. Rotate keys when staff change. A service account belongs to nobody, but somebody knows it. ## Support access A system administrator can sign in as a user in a support case. It is a powerful tool and it is visible in the log. If your internal policy needs to govern that, govern it before the first support case rather than after. --- title: "Manage suppliers" description: "The onboarding funnel, returning instead of rejecting — and why a rejection is not about the company." lang: "en" url: "https://academy.knowhow.io/en/learning/lieferanten-verwalten" persona: ["procurement-admin", "procurement-user"] level: "intermediate" estimated_time: 20 prerequisites: ["product-overview"] --- # Manage suppliers The onboarding funnel, returning instead of rejecting — and why a rejection is not about the company. - Part of: [Procurement Admin](https://academy.knowhow.io/en/personas/procurement-admin) (Module 7 of 8), [Procurement User](https://academy.knowhow.io/en/personas/procurement-user) (Module 7 of 7) - Duration: 20 min - Level: Intermediate - Read first: [An overview of e-Request](https://academy.knowhow.io/en/learning/product-overview.md) - Next up: [Logging, export and interfaces](https://academy.knowhow.io/en/learning/protokoll-und-export.md) The intended route is simple: **procurement invites, the supplier fills in.** There is no open self-registration. ## The funnel Onboarding is a funnel with an email at every step. The supplier can always see whether the ball is in their court — and that is the part that saves you follow-up calls. For unknown suppliers there is an **access request form** with spam protection. It creates no account; it sends an email to procurement. It can be switched off if you do not want the channel. For Swiss companies, master data can be pulled from the public commercial register via the UID. For instances without outbound network access the lookup can be disabled individually. ## Return for correction instead of rejection The most important state in the funnel: you return a registration **with a mandatory reason**. The supplier sees that they are up, and what for — not the same state as on day one. That is not a detail. It is the difference between a supplier who fixes it and one who phones. ## Final rejection — and reinstatement Separately there is final rejection as a distinct, closing state. It means "not a fit", not "please fix this", and it is reachable from any state in the funnel. A rejection can be **reopened** later. The supplier then starts again as a draft. The thinking: what was rejected is the qualification, not the company — circumstances change. ## Block, archive, reactivate Blocking and unblocking, archiving and reactivating are available. Reactivation returns the supplier to where they were rather than blanket-approving them — someone who once got stuck in the funnel is stuck at the same point afterwards. ## Main contact and deputy A supplier has a main contact and, optionally, a deputy. Both can do the same day-to-day work; only the main contact can administer. The deputy can be recorded with or without their own login. Point this out when you invite. It is the cheapest countermeasure against the most common excuse — "my colleague was on holiday". ## What is not here - **No supplier scoring and no supplier analytics.** The SRM module is in development and not switched on. If that is central for you, tell us — demand is measured, not guessed. - **No screening** against sanctions, PEP or ESG lists, and no coverage of supply-chain regulation by name. What the product does is capture details and evidence **in a structured way**. Whether that makes you compliant is your legal team's call, not the software's. - **No open marketplace.** Your supplier data stays in your instance. --- title: "Logging, export and interfaces" description: "What is traceable, how you get your data out — and which integrations do not exist." lang: "en" url: "https://academy.knowhow.io/en/learning/protokoll-und-export" persona: ["procurement-admin"] level: "advanced" estimated_time: 20 prerequisites: ["user-management"] --- # Logging, export and interfaces What is traceable, how you get your data out — and which integrations do not exist. - Part of: [Procurement Admin](https://academy.knowhow.io/en/personas/procurement-admin) (Module 8 of 8) - Duration: 20 min - Level: In depth - Read first: [Users and access](https://academy.knowhow.io/en/learning/user-management.md) Three questions come up in every rollout: what is traceable, how do I get at my data, and how does this hang together with our other systems? ## Logging Activity is logged comprehensively across the business objects, and every tender additionally has its own log view — the one that gets used when it matters. Two limits you should know before somebody else finds them: - Logging covers the business objects, not every click. - System-administrator actions are filtered out. So it is a **comprehensive activity log across all business objects** — and deliberately no more than that. If your audit function requires a genuinely complete record of every action, that is a requirement to settle before rollout rather than after. ## Export **CSV and XLS of lists** — tenders, suppliers. Free, in every plan. What it is not: a reporting system. There is no report export and no PDF. If you need analysis, export the list and analyse it where your organisation already does. The dashboard has metric tiles and an activity feed. The tiles are **counts** — volumes and cycle times. There is no savings calculation, in any form. ## Webhooks Free, signed, for `offer.submitted`, `contract.signed` and `supplier.approved`. Generic formats plus Slack and Mattermost. A webhook can be fired as a test from the settings — do that before you rely on it. ## REST API and MCP Both **paid**, both available: - **REST API** (`/api/v1`): read and write for tenders, suppliers and categories. **Offers stay read-only** — an offer is created in the supplier portal and nowhere else. - **MCP connection**: eight **read-only** tools across tenders, offers, suppliers and question rounds, on the same keys and the same permissions. The MCP connection is where you attach your own AI. We supply the interface, not the model — which one you use is your decision. **There is no AI inside e-Request**, and we deliberately do not claim otherwise. Both must be in the licence. And once more, because it is the most expensive misunderstanding: one key sees everything across the tenant. ## Which integrations do not exist There is **no ready-made connector for SAP, Ariba, Oracle or Salesforce**. No ERP connector, in any plan, not even as an option. What exists is the REST API, webhooks and the export. If an ERP connection is a condition for you, it is a project on your side or with an integrator — plan it as one. --- title: "Raise a need" description: "Capture a request so that procurement does not have to come back with questions." lang: "en" url: "https://academy.knowhow.io/en/learning/creating-requests" persona: ["procurement-user", "department-user"] level: "beginner" estimated_time: 15 prerequisites: ["product-overview"] --- # Raise a need Capture a request so that procurement does not have to come back with questions. - Part of: [Procurement User](https://academy.knowhow.io/en/personas/procurement-user) (Module 2 of 7), [Department User](https://academy.knowhow.io/en/personas/department-user) (Module 2 of 3) - Duration: 15 min - Level: Getting started - Read first: [An overview of e-Request](https://academy.knowhow.io/en/learning/product-overview.md) - Next up: [Create a tender](https://academy.knowhow.io/en/learning/ausschreibung-erstellen.md) Most delays do not arise in procurement but before it: in a request that still triggers questions. ## What belongs in a good request - What exactly is needed — and what for - By when - Which requirements are non-negotiable, and which are wishes - Who can answer technical questions, with a number that is answered The split between "non-negotiable" and "desirable" is the most valuable line in your request. The award criteria and their weighting come out of it — if you do not supply it, procurement guesses. ## The right category Assign your need to a category. That is not a formality: the category is how procurement finds who is even eligible, and how your purchase gets found again later. ## Setting a realistic date Between your request and a signed contract sit several steps outside your control: internal approval, invitation, a question round with a deadline, submission itself, then evaluation. So give the date you **need** the goods or service, not the date you would like them. And give it early — the question round cannot be shortened without losing the comparability of the offers. ## Rule of thumb If somebody from another department can read your request without asking a question, it is complete. --- title: "Create a tender" description: "From a need to a published tender — capture, internal approval and invitation." lang: "en" url: "https://academy.knowhow.io/en/learning/ausschreibung-erstellen" persona: ["procurement-user"] level: "intermediate" estimated_time: 25 prerequisites: ["creating-requests"] --- # Create a tender From a need to a published tender — capture, internal approval and invitation. - Part of: [Procurement User](https://academy.knowhow.io/en/personas/procurement-user) (Module 3 of 7) - Duration: 25 min - Level: Intermediate - Read first: [Raise a need](https://academy.knowhow.io/en/learning/creating-requests.md) - Next up: [Run the question round](https://academy.knowhow.io/en/learning/fragerunde-fuehren.md) The tender is where a need turns into a procedure. Whatever stays unclear here costs you time in the question round and comparability in the evaluation. ## Capture A multi-step assistant walks through creation; documents are attached directly. Uploads and deletions are logged — removing a file stays visible too. You do not need the whole form for a correction: individual fields can be edited directly in the view. ## Duplicate instead of templates There are **no templates**. Instead you duplicate an existing tender. That sounds like less and is more in practice: a copy starts from real content that has already worked once, rather than from a scaffold of placeholders. For recurring purchases, deliberately keep one "good" tender and copy it each time. ## Internal approval Publication is preceded by internal approval. A rejection is **documented with a reason** — not a formality, but the moment an audit looks at most often. Budget time for it. It is the most common reason a tender goes out later than planned. ## Inviting suppliers You invite — there is no open self-registration through which somebody applies to your tender unasked. Invitees can also be added or removed afterwards. If your organisation has enabled the access request form, unknown suppliers can get in touch. It creates **no account**; it sends a message to procurement, and you decide. ## When something changes A change notification to all invitees is **triggered manually** — it does not happen by itself when you swap a document. Make it a rule: every change after publication gets announced. A supplier pricing an outdated version submits an offer you cannot use, and both sides did the work for nothing. ## Keeping an overview Filters and search span all tenders. Completed ones are hidden by default, which keeps the list short; anyone looking for them can show them. --- title: "Run the question round" description: "Collect, approve and answer questions for everyone at once — the step that turns equal treatment into a function." lang: "en" url: "https://academy.knowhow.io/en/learning/fragerunde-fuehren" persona: ["procurement-user"] level: "intermediate" estimated_time: 15 prerequisites: ["ausschreibung-erstellen"] --- # Run the question round Collect, approve and answer questions for everyone at once — the step that turns equal treatment into a function. - Part of: [Procurement User](https://academy.knowhow.io/en/personas/procurement-user) (Module 4 of 7) - Duration: 15 min - Level: Intermediate - Read first: [Create a tender](https://academy.knowhow.io/en/learning/ausschreibung-erstellen.md) - Next up: [Evaluate offers](https://academy.knowhow.io/en/learning/evaluating-offers.md) The question round is the part of the procedure where equal treatment stops being an intention and becomes a mechanism. ## How it works Invited suppliers ask questions. You answer them, approve the answers and publish them **to all** invitees together, at the press of a button. The question itself becomes visible; who asked it does not. ## Why that is more than convenience The classic mistake in day-to-day procurement is answering one bidder by email. It is quick, it feels helpful — and it hands that bidder an information advantage nobody can reconstruct afterwards. Here the question round is the more convenient route. That is the real achievement: fairness costs no discipline. ## What you control - **Approval before publication.** You decide what goes out — a question that would reveal the asker's business details gets rephrased rather than published verbatim. - **Collective publication.** Answering several questions together saves you time and saves bidders confusion. - **Timing.** The question round closes before the submission deadline, otherwise somebody is pricing against an answer they can no longer incorporate. ## What belongs in it, and what does not Anything concerning the tender belongs in it. Matters affecting only one bidder — an access problem, say — belong in direct contact. If a question shows your documents are unclear, the answer is rarely the best fix: a **change notification** to everyone is cleaner, because it corrects the text instead of commenting on it. ## For the next tender Recurring questions are the best feedback you will get on the quality of your documents. Whatever was asked three times belongs in the text next time — and since you duplicate anyway, the improvement sticks. --- title: "Evaluate offers" description: "Weight the criteria, score independently and document the decision so it can be followed later." lang: "en" url: "https://academy.knowhow.io/en/learning/evaluating-offers" persona: ["procurement-user"] level: "advanced" estimated_time: 25 prerequisites: ["fragerunde-fuehren"] --- # Evaluate offers Weight the criteria, score independently and document the decision so it can be followed later. - Part of: [Procurement User](https://academy.knowhow.io/en/personas/procurement-user) (Module 5 of 7) - Duration: 25 min - Level: In depth - Read first: [Run the question round](https://academy.knowhow.io/en/learning/fragerunde-fuehren.md) - Next up: [Award and contract](https://academy.knowhow.io/en/learning/zuschlag-und-vertrag.md) Evaluation is the step where anything vague in the tender comes back at you. It is also the step an audit looks at first. Offer evaluation is a **paid extension**. If the functions below are missing for you, that is why — not a setting. ## Criteria and weighting Criteria carry a weighting in per cent. The available types are number, price, free text and picklist. For price there are two formulas: **linear** and **degressive**, with a cutoff at 20 per cent. That is considerably more than "cheapest wins", and it is worth running both against old figures once before committing to one. You can keep several named evaluation strategies; two standard ones are created automatically. ## Everyone scores on their own This is the function nobody expects: there are **evaluation rounds per person**. Several people score independently, and a comparison view follows. The difference from a spreadsheet on a shared drive is not convenience — it is that nobody sees anyone else's score before submitting their own. The discussion happens afterwards, about the differences, rather than about who saved last. ## Deciding Shortlist, winner proposal, confirmation, withdrawal: four steps, and the split between proposal and confirmation is the four-eyes principle. Withdrawal is provided for, and documented. Internal notes on offers stay **internal**. The supplier never sees them — anything meant for them goes out as a message or as a stated reason. Not every evaluation ends with a winner. If you close without an award, every participant receives an email. If a procedure has to end early — the need has gone, the documents were wrong — **withdraw the tender**. That is possible at any time after publication, including after the offer deadline, and only for procurement. You record the reason internally; suppliers are not told it, but they receive an email straight away. The step cannot be undone, draft offers that were never submitted are deleted, and starting again means copying the tender. Every closed tender then shows its outcome: closed with award, closed without award, or cancelled. ## What does not exist - **No side-by-side scenario view.** Several weighting models are possible; comparing them in one picture is not. - **No savings calculation.** The dashboard tiles count; they do not compute. - **No case file across several rejection rounds** on the supplier side: the latest round's reason is documented, the history behind it is not. And a supplier never sees who rejected. ## Where you save yourself work Fix the criteria **before** publication and write them into the tender. Criteria that appear during comparison are hard to justify — and justification is exactly what an unsuccessful bidder asks for. --- title: "Award and contract" description: "From confirmed winner to signed contract — and what the portal signature is, legally." lang: "en" url: "https://academy.knowhow.io/en/learning/zuschlag-und-vertrag" persona: ["procurement-user"] level: "advanced" estimated_time: 20 prerequisites: ["evaluating-offers"] --- # Award and contract From confirmed winner to signed contract — and what the portal signature is, legally. - Part of: [Procurement User](https://academy.knowhow.io/en/personas/procurement-user) (Module 6 of 7) - Duration: 20 min - Level: In depth - Read first: [Evaluate offers](https://academy.knowhow.io/en/learning/evaluating-offers.md) - Next up: [Manage suppliers](https://academy.knowhow.io/en/learning/lieferanten-verwalten.md) Once the winner is confirmed you inform the bidders. What happens next depends on whether your organisation uses the contract module — it is **paid** and not in use everywhere. ## From offer to contract A contract arises from a winning offer. It also works without a tender: existing contracts that only need monitoring can be created directly. The contract page shows where a contract stands. What matters more is what you can do from there: request the signature, withdraw an open request, request again after a decline — and, later, terminate. ## The signature You request the signature and the supplier confirms **in the portal**. Confirmation is a click and is logged with a timestamp. **This is not a qualified electronic signature** under ZertES or eIDAS. For most procurements that is exactly right. Where a qualified signature is required, settle it with your legal team before sending the request — it is a contractual question, not a technical one. If the supplier declines, that is a normal step: you amend and request again. If you notice after sending that something in the contract is still wrong, withdraw the request. The supplier receives an email. The contract can only be sent again once you have reset it to draft and amended it. ## Terminating You can terminate a signed contract in e-Request. The effective date is required; you can add a comment and the termination letter. The supplier receives an email, and the contract becomes inactive and drops out of deadline monitoring. The supplier can terminate too, from their portal — then you receive the email. **e-Request records the termination; it does not serve it.** It takes legal effect as before, through your termination letter and the notice periods in the contract. ## Deadlines and deliveries A contract carries a contract number, a value and a renewal option. Deadline monitoring sends reminders and keeps a list on the dashboard. **Those reminders are internal.** The supplier is not reminded — anyone expecting that is waiting for something that will not come. For deliveries you can record the target and actual date, a remark, and the acceptance: pending, accepted, accepted with reservations, or rejected. ## What you can tell a bidder And what you cannot: the reason from the latest rejection round is visible to the supplier. Who decided internally is never visible, and there is no history across several rounds. Internal notes stay internal, including those on the offer. Anything meant to reach the bidder goes out as a message. ## If your organisation does not have the module Then e-Request ends at the award and the contract runs your usual way. That is not an edge case; just tell your suppliers, so nobody waits for a signature request in the portal. --- title: "Track the status" description: "Where your request stands, what you are allowed to see — and what is deliberately not shown to you." lang: "en" url: "https://academy.knowhow.io/en/learning/tracking-status" persona: ["department-user"] level: "beginner" estimated_time: 15 prerequisites: ["creating-requests"] --- # Track the status Where your request stands, what you are allowed to see — and what is deliberately not shown to you. - Part of: [Department User](https://academy.knowhow.io/en/personas/department-user) (Module 3 of 3) - Duration: 15 min - Level: Getting started - Read first: [Raise a need](https://academy.knowhow.io/en/learning/creating-requests.md) After submitting, the most common question is: "and now?" ## Where to look - **Task list and calendar view** — what is expected of you, and when. - **Activity feed** on the dashboard — what happened most recently. - **Global search** — across everything you are entitled to see. The metric tiles on the dashboard are **counts**: volumes and cycle times. They are not an analysis and certainly not a savings calculation — the product has none. ## Whose turn it is Every request has exactly one responsible party at any moment. Knowing which one tells you who to approach. Between invitation and submission the ball is with the supplier, and nobody can speed that up: the deadlines are set, and shortening them would destroy the comparability of the offers. ## What you see, and what you do not This regularly surprises people, so explicitly: You see **every supplier**, with their states and contact details. Whoever formulates a need should know who the organisation works with. You do **not** see: - Prices and offer details from other tenders - Suppliers' qualification data And there is **no direct contact form to a supplier**. That is not a convenience gap: a running procedure must not be influenced outside the procedure. If you need to clarify something technical, it goes through procurement — and where it concerns everyone, through the question round, so that every bidder gets the same answer. ## How a tender ends A closed tender shows its outcome: _Closed with award_, _Closed without award_ or _Cancelled_. Cancelled means procurement withdrew it. Only procurement can do that, and it cannot be undone — starting again means copying the tender. So if your need goes away, tell procurement rather than letting the tender run out. Suppliers then receive a clear email instead of a rejection that is not really one. ## When chasing makes sense Not at every step — but when a date you have promised is approaching. A short note with a date works better than a general enquiry. ## On mobile The interface works on mobile devices; there is no separate app. For a look at the status your phone is enough; for entering a need, a computer is the better choice.