Inhaltsverzeichnis
Diese Seite dient als Übersicht sämtlicher im CRM-Tool abzubildenden Use Cases. Die Anforderungen können von den einzelnen Use Cases abgeleitet werden. Die Use Cases sind entlang Capabilities gruppiert.
Der Use Case Katalog bildet die Basis für
die Maturitätsanalyse resp. zur Identifikation der Gaps
die Machbarkeitsprüfungen sowie andere vertiefte Analysen
die Kostenschätzung der Gaps
die Vorbereitung der Tool Demonstration
die Erfassung der Epics, Features und Stories in Jira
Capability “Mitgliederverwaltung”
[Exkurs] Mitgliederverwaltung
Hinter der Verwaltung von Mitgliedern steht aktuell dieses Datenmodell in Navision:
Das oben dargestellte Datenmodell wurde inzwischen um folgende Entitäten erweitert:
Familie - Felder: Familiennummer, Familienverantwortlicher, Name Verantwortlicher, Strasse Verantwortlicher, PLZ Verantwortlicher, Ort Verantwortlicher, Aktiv, Stammsektion, Gültig von, Gültig bis, Anzahl Erwachsene, Anzahl Kinder
Familienmitglied - Felder: Familiennummer, Familiennummer, Beziehungsstatus, Aktiv, Familienverantwortlicher, Adressabgleich Verantwortlicher, Nachname, Vorname, Strasse, PLZ, Ort, Geburtsdatum, Stammsektion, Beitragsgruppe, Gültig von, Gültig bis
Familie Einrichtung - Felder: Nummernserie Familie, Kategorie Verantwortlicher, Kategorie Partner, Kategorie Kind, Kategorie Jugend, Kategorie Einzel, Höchstalter Kind, Mindestalter Erwachsene
Weiterführende Informationen können hier gefunden werden: 02 TP5 : Spezifikationen - Neue ERP Lösung - Confluence (atlassian.net)
Use Case “MV_1: Mitgliedschaft online beantragen”
Use Case ID | MV_1 |
---|---|
Beschreibung | Eine Person kann unter https://www.sac-cas.ch/de/mitgliedschaft/mitglied-werden/ eine Mitgliedschaft beantragen. Folgende Informationen werden im Anmeldeformular erfasst:
Um eine möglichst hohe Datenualiqualität sicherzustellen, sollen folgende Anforderungen in Betracht gezogen werden:
|
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse |
|
Kostenschätzung |
|
Use Case “MV_2: Mitgliedschaft offline beantragen”
Use Case ID | MV_2 |
---|---|
Beschreibung | Eine Person kann bei einem Hüttenbesuch ein Anmeldeformular in Papierform ausfüllen und diesen bei einem Hütten Mitarbeitenden (z.B. Hüttenchef, Hüttenwart) abgeben. Das Anmeldeformular gelangt via Post zur Geschäftsstelle. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | Keine |
Kostenschätzung | 0 wird ausserhalb von Hitobito gelöst |
Use Case “MV_3: Online Anträge für Neumitgliedschaft bearbeiten”
Use Case ID | MV_3 |
---|---|
Beschreibung | Online Anträge für eine neue Mitgliedschaft sind im CRM-Tool in einer “Puffer”-Liste ersichtlich, d.h. die Personen werden temporär angelegt und sind noch nicht aktiv. Im Antrag sind folgende Informationen vom System abgefüllt:
Nach der Bearbeitung des Antrags ist die Person aktiv. Die Mitgliedschaft ist entweder per sofort oder ab einem Datum in der Zukunft aktiv. Mit der Aktivierung der Mitgliedschaft erhält der/die Antragsteller/In die Jahresrechnung sowie den Mitgliederausweis. Per sofort können wir die Rolle in Hitobito bereits anlegen. Per Datum in der Zukunft benötigt eine aufwändige Erweiterung Spezialfälle:
|
Akteure |
|
Auslöser | |
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse |
|
Kostenschätzung |
|
Use Case “MV_4: Offline Anträge für Neumitgliedschaft bearbeiten”
Use Case ID | MV_4 |
---|---|
Beschreibung | Bei papierbasierten Anträge für eine neue Mitgliedschaft geht der Mitgliederdienst an der Geschäftsstelle gemäss Beschrieb unter https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMitgliedschaft-online-beantragen%E2%80%9D vor. |
Akteure |
|
Auslöser | |
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | Keine |
Kostenschätzung | 0 wird ausserhalb von Hitobito gelöst |
Use Case “MV_5: Nicht-Mitglieder als Person hinzufügen”
Use Case ID | MV_5 |
---|---|
Beschreibung | Der Mitgliederdienst an der Geschäftsstelle oder in der Sektion kann “externe” Kontakte erfassen. Dabei handelt es sich um Kontakte, die keine aktive Mitgliedschaft beim SAC haben, aber im System abgelegt werden müssen. Beispiele sind Kontaktpersonen bei juristischen Personen (z.B. Marketing Agentur, Alpine Rettung Schweiz, Druckerei, Schweizer Bergführerverband, SportXX). Spezialfall:
|
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | Keine |
Offene Punkte |
|
In Scope für Demo | Ja |
Arbeitspakete | Keine |
Kostenschätzung |
|
Use Case “MV_6: Kontakt Stammdaten verwalten”
Use Case ID | MV_6 |
---|---|
Beschreibung | In einem Portal kann ein Mitglied selbständig seine Profilinformationen mutieren. Folgende Werte können mutiert werden:
Folgende Werte werden angezeigt, sind aber nicht editierbar:
Alternativ kann ein Mitglied zwecks Anpassung der Profilinformationen mit dem Mitgliederdienst an der Geschäftsstelle oder in der Sektion Kontakt aufnehmen. In diesem Fall kann die bearbeitende Person im CRM-Tool die Person aufrufen und die Anpassungen direkt vornehmen. Bei Familien muss eine besondere Aufmerksamkeit geschenkt werden:
Zudem kann der Mitgliederdienst an der Geschäftsstelle die Daten externer resp. von nicht-SAC-Mitglieder im CRM-Tool verwalten, siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_5:-Nicht-Mitglieder-als-Person-hinzuf%C3%BCgen%E2%80%9D. Spezialfälle:
Siehe auch Schnittstellenthematik "mySAC Portal" |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
Alternative:
|
Schnittstellen | |
Gap Analyse | Keine |
Kostenschätzung |
|
Use Case “MV_7: Mitglieder von aussen abfragen“
Use Case ID | MV_7 |
---|---|
Beschreibung | Für diverse Applikationen und externe Partner muss die Möglichkeit gegeben sein, Mitglieder abzufragen. Beispiele:
|
Akteure |
|
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_8: Beziehungen zum SAC verwalten”
Use Case ID | MV_8 |
---|---|
Beschreibung | Eine Person hat 1:n Beziehungen zum SAC - z.B. können SAC Mitglieder weitere Beziehungen zum SAC haben, weil sie bspw. gleichzeitig eine Funktion in einer Hütte oder in einer Sektion ausüben. Diese Beziehungen kann der Mitgliederdienst an der Geschäftsstelle oder in der Sektion mittels Zuweisung von Rollen und Tags in der Personenkarte abbilden. Eine Beziehung ist per sofort oder ab einem Datum in der Zukunft gültig. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | Keine |
Kostenschätzung |
|
Use Case “MV_9: Duplikate erkennen und bereinigen”
Use Case ID | MV_9 |
---|---|
Beschreibung | Ein nächtlicher Batch Job soll dazu dienen, Dubletten zu erkennen. Die Prüfungslogik soll eine Gewichtung in Betracht ziehen sowie die kalkulierte Wahrscheinlichkeit, dass es sich um eine Dublette handelt, anzeigen. Zudem soll eine phonetische Suche angewandt werden. Die Prüfungslogik soll folgende Kriterien umfassen:
Erkannte Duplikate sollen in einer Liste ausgegeben werden, auf die der Mitgliederdienst Zugriff hat. Die bearbeitende Person kann ein Eintrag in der Liste öffnen und die Dublette bereinigen - konkret können mehrere Personen in eine Person zusammengeführt werden. Dabei kann bestimmt werden, welche Person beibehalten werden soll und welche Werte von der zu löschenden Person übernommen werden sollen. Falls es sich um keine Dublette handelt, kann dies die bearbeitende Person kennzeichnen, sodass das System dies nicht mehr als Dublette ausgibt. Spezialfälle:
|
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse |
|
Kostenschätzung |
|
Use Case “MV_10: Ungültige Adressen erkennen und bereinigen”
Use Case ID | MV_10 |
---|---|
Beschreibung | Ein Abgleich sämtlicher Adressen mit der Post sollte nächtlich in einem Batch-Job geschehen. Ungültige Adressen sollen in einer Liste ausgegeben werden, auf die der Mitgliederdienst Zugriff hat. Die bearbeitende Person kann ein Eintrag in der Liste öffnen und die Adresse bereinigen. Idealerweise berücksichtigt die Prüfungslogik eine Gewichtung der Adressdaten und kalkuliert die Wahrscheinlichkeit, dass es sich um eine ungültige Adresse handelt. Falls die Adressübereinstimmung nicht 100% beträgt, soll dem User ein Vorschlag angezeigt werden. Der Vorschlag kann der User per Knopfdruck übernehmen. Beispiel: diesjähriger Mahnlauf hat 15’000 Rechnungen generiert. Ein vorgängiger Abgleich der Adressen in Navision mit der Post hat dazu geführt, dass lediglich 65 Retouren stattgefunden haben! Weiterführende Informationen wie der Adressabgleich aktuell in Navision umgesetzt ist, kann hier gefunden werden: /wiki/spaces/ERP/pages/3522854952 |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | Aktuell wird folgender Service der Post verwendet: https://www.post.ch/de/geschaeftsloesungen/adressmanagement/adressen-aktualisieren/adressen-pflegen#preise |
Gap Analyse |
|
Kostenschätzung |
|
Use Case “MV_11: Vereinsmitgliederjahre hochrechnen und anpassen”
Use Case ID | MV_11 |
---|---|
Beschreibung | Das System soll die Vereinsmitgliederjahre jährlich am Tag der Mitgliedschaftsaktivierung automatisch inkrementieren. Im ersten Jahr weist das Mitglied 0 Vereinsmitgliederjahre aus. Mitgliedsjahre werden anhand der Rollen von/bis in Hitobito berechnet Die vom System automatisch kalkulierten Vereinsmitgliederjahre können vom Mitgliederdienst an der GS händisch überschrieben werden. Die manuell angepassten Vereinsmitgliederjahre werden bei der Fakturierung berücksichtigt. Manuelle Korrektur wird mittels erfassen einer Rolle von/bis ergänzt |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf | Hochrechnen:
Anpassung:
|
Schnittstellen | |
Gap Analyse |
|
Kostenschätzung |
|
Use Case “MV_12: Beitragskategorie aktivieren, deaktivieren und wechseln”
Use Case ID | MV_12 |
---|---|
Beschreibung | Folgende Beitragskategorien bietet der SAC an (siehe https://www.sac-cas.ch/de/mitgliedschaft/mitglied-werden/):
Dabei wichtig ist, dass das System in der Lage ist, die Zuordnung einer Beitragsgruppe zu steuern. Es sollte nicht möglich sein ein Erwachsener als Jugendmitglied zu erfassen. Zudem hat eine beliebige Person die Möglichkeit nur ein Zeitschriften-Abo für Die Alpen zu bestellen (siehe https://www.sac-cas.ch/de/die-alpen/abonnieren/abo-bestellen/). Das Angebot umfasst zudem den Online-Zugriff auf alle kostenpflichtigen und exklusiven Artikel sowie Touren-Tipps in allen Sprachen und Ausgaben seit 1864. Der Mitgliederdienst an der Geschäftsstelle oder in der Sektion kann für eine Person eine Beitragskategorie per sofort oder ab einem Datum in der Zukunft aktivieren. Beim Hinzufügen einer neuen Beitragskategorie kann aus einer vordefinierten Liste den Eintrittsgrund ausgewählt werden (z.B. “Weil mich die Bergwelt fasziniert“, “Weil der SAC eine gute Sache ist”, “Wegen den Ausbildungsmöglichkeiten”). Die Beitragskategorie ist für eine Hauptsektion gültig und optional können zusätzliche Mitgliedschaften bei anderen Sektionen aktiviert werden (Stichwort Zusatzsektion). Die Auswahl der Beitragskategorie wird vom System geprüft, d.h. wenn die Auswahl unzulässig ist (z.B. Mitglied im Alter von 60 möchte sich als “Jugend” anmelden), wird dies vom System abgefangen und eine entsprechende Fehlermeldung wird angezeigt. Achtung: Mitgliederdienst Geschäftsstelle darf nicht für alle Sektionen Eintritte vornehmen, siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_15:-Sektion-Stammdaten-verwalten%E2%80%9D! Der Mitgliederdienst an der Geschäftsstelle oder in der Sektion kann für ein Mitglied eine Beitragskategorie per sofort oder ab einem Datum in der Zukunft auflösen. Die Deaktivierung einer Mitgliedschaft in der Hauptsektion führt zu einem Austritt aus SAC. Das Mitglied kann im Portal ebenfalls einen Austritt vornehmen. Bei einem Austritt muss zwingend ein Austrittsgrund aus einer vordefinierten Liste selektiert werden. Achtung: Mitgliederdienst Geschäftsstelle darf nicht für alle Sektionen Austritte vornehmen, siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_15:-Sektion-Stammdaten-verwalten%E2%80%9D! Wenn in einer Familie der Hauptkontakt austritt, muss das System fragen, ob alle Mitglieder austreten. Wenn nicht alle Mitglieder austreten, gilt es folgende Regeln zu beachten:
Wir hatten bei der Konzeption besprochen das ein Mitglied nicht selber/automatisiert austreten kann. Vorschlag: Das wird künftig immer noch via Mailformular und dem MV manuell gemacht. (Anpassen der Rollen in Hitobito) Ein Wechsel der Beitragskategorie ist möglich. Ein Wechsel wird entweder vom Mitgliederdienst an der Geschäftsstelle oder in der Sektion manuell veranlasst oder automatisch vom System vorgenommen, wenn ein Mitglied der Kategorie “Frei Kind” oder “Jugend” das 18. resp. das 23. Lebensjahr erreicht (siehe auch https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_21:-Mitglieder-mit-einem-bevorstehenden-Beitragskategoriewechsel-informieren%E2%80%9C). Bei einem Wechsel wird ein Wechselgrund erfasst. Ein Wechsel der Beitragskategorie erfolgt bei folgenden Fällen automatisch:
Ein Wechsel der Beitragskategorie wird bei der Fakturierung berücksichtigt. Eine Mutationshistorie ist gegeben. Generell gibt es 150 verschiedene Ausprägungen von folgenden Geschäftsfällen:
→ Siehe: https://saccas.atlassian.net/wiki/download/attachments/936640554/OMSMO_Deck_FälleMatrix.xlsx?version=1&modificationDate=1550825869072&cacheVersion=1&api=v2 Spezialfälle:
|
Akteure |
|
Auslöser |
|
Vorbedingungen | Keine |
Standardablauf | TODO |
Schnittstellen | |
Gap Analyse |
|
Kostenschätzung |
|
Use Case “MV_13: Mitgliederausweis senden”
Use Case ID | MV_13 |
---|---|
Beschreibung | Aktuell wird der Mitgliederausweis einerseits mit der Jahresrechnung und andererseits bei Anfrage eines Mitglied individuell nachgesendet (z.B. bei Verlust). Bei der Jahresrechnung (siehe TODO) wird der Mitgliederausweis am Ende angehängt. Der Druck findet extern statt - hierzu stellt die Geschäftsstelle alle Jahresrechnungen der Druckerei im PDF-Format zu. Eine sprachliche Unterscheidung (de, fr, it) der im Ausweis angezeigten Überschriften ist gegeben, d.h. die hinterlegte Sprache beim Kontakt wird beim Druck berücksichtigt. Der auf dem Ausweis auszuweisenden Sektionsnamen kann von der offiziellen Bezeichnung abweichen. Bei erfolgreicher Zustellung des Ausweises, soll dies in der Personenkarte gekennzeichnet sein. Bei der individuellen Nachsendung und beim wöchentlichen Mini-Inkasso findet der Druck intern statt. Die Digitalisierung des Ausweises ist ein Thema beim SAC. Der digitale Ausweis soll schrittweise eingeführt werden. In einem ersten Schritt sollen folgende Informationen auf dem Ausweis nicht mehr ersichtlich sein: Vereinsmitgliederjahre, Hauptsektion, Zusatzsektionen. Mit dieser Anpassung ist der SAC nicht mehr gezwungen jährlich einen Ausweis zuzustellen. Stattdessen soll ein QR Code auf dem Ausweis abgebildet werden. Beim Scannen des QR Codes können die ausgeblendeten Informationen (Vereinsmitgliederjahre, Hauptsektion, Zusatzsektionen) sowie der Mitgliedschaftsstatus in Echtzeit abgefragt werden. Puzzle hat eine ähnliche Umsetzung für den Schweizerischen Kanu-Verband vorgenommen, siehe https://onedrive.live.com/?authkey=%21ABDP8%5FIYas2Mk9o&id=2F74E54DF28604D9%21106&cid=2F74E54DF28604D9&parId=root&parQt=sharedby&parCid=6277AAD522C1FD4B&o=OneUp. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf | Mitgliederausweis mit Jahresrechnung
Individuelle Nachsendung
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_14: Zentralverband Stammdaten verwalten“
Use Case ID | MV_14 |
---|---|
Beschreibung | Der Mitgliederdienst an der Geschäftsstelle kann die Stammdaten des Zentralverbands mutieren. Folgende Angaben können erfasst und angepasst werden:
Die Ansätze sind immer für ein Jahr lang gültig. Die erfassten Werte werden bei der Fakturierung berücksichtigt. Eine Historie der Beitragsanpassungen ist gegeben. Ein erfasster Beitrag kann erst ab einem Datum in der Zukunft gültig sein, aber immer ab Jahresbeginn. |
Akteure |
|
Auslöser |
|
Vorbedingungen | Keine |
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_15: Sektion Stammdaten verwalten”
Use Case ID | MV_15 |
---|---|
Beschreibung | Die Sektionsstammdaten können vom Mitgliederdienst an der Geschäftsstelle in einer Maske erfasst werden. Folgende Informationen können erfasst werden:
Die Ansätze sind immer für ein Jahr lang gültig. Die erfassten Werte werden bei der Fakturierung berücksichtigt. Eine Historie der Beitragsanpassungen ist gegeben. Ein erfasster Beitrag kann erst ab einem Datum in der Zukunft gültig sein, aber immer ab Jahresbeginn. Falls eine Sektion aufgelöst wird (siehe z.B. Fall Sektion Raimeux) kann der Mitgliederdienst an der Geschäftsstelle eine Sektion deaktivieren resp. auf inaktiv setzen. Falls die Sektion zum Zeitpunkt der Deaktivierung aktive Mitglieder ausweist, wird dies dem User mitgeteilt. Eine Sektion kann Ortsgruppen (Untersektionen) umfassen - z.B. Sektion SAC Pilatus hat als Ortsgruppen Surental, Napf, Hochdorf und Rigi + Sektion CAS Diablerets hat als Ortsgruppen Château-d’Oex, Morges, Payerne und Vallorbe. Dies kann im System ebenfalls abgebildet werden. Die Sektionsstammdaten können vom Mitgliederdienst an der Geschäftsstelle oder in der Sektion angepasst werden. Eine Mutationshistorie ist gegeben. Die der Geschäftsstelle per Post zugestellten Sektionsstammdatenblätter können gescannt und im Tool abgelegt werden, sodass der physische Ordner abgeschafft werden kann. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf | Neue Sektion
Sektion wird aufgelöst
Anpassung in einer Sektion
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_16: Sektionen im Webauftritt publizieren“
Use Case ID | MV_16 |
---|---|
Beschreibung | Auf https://www.sac-cas.ch/de/der-sac/sektionen/ sind alle Sektionen und Untersektionen resp. Ortsgruppen publiziert. Aktuell dient Navision als Datenquelle. Die Daten gelangen via FTP an Typo3. Berechnung der Anzahl Mitglieder anhand Anzahl aktiver/Relevanter Rollen, evtl. Feld auf Gruppe/Layer cachen |
Akteure | Keine |
Auslöser | TODO |
Vorbedingungen |
|
Standardablauf | TODO |
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_17: Ehrenmitglieder und begünstige Mitglieder verwalten”
Use Case ID | MV_17 |
---|---|
Beschreibung | Der Mitgliederdienst an der Geschäftsstelle oder in der Sektion kann ein Mitglied zum Ehrenmitglied ernennen oder die Ehrenmitgliedschaft entziehen. Es ist auch möglich einem Mitglied eine begünstigte Mitgliedschaft zuzuweisen oder zu entziehen. Ehrenmitglieder und begünstigte Mitglieder sind nicht in allen Sektionen zulässig. Ein Ehrenmitglied oder ein begünstigtes Mitglied hat Anspruch auf eine Reduktion. Die Reduktion kann auf dem ZV-Beitrag, auf den Sektionsanteil oder auf beiden Posten erlassen werden. Diese Regelungen sind in den Stammdaten erfasst, siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CSektionsstammdaten-verwalten%E2%80%9D. Die daraus resultierende Reduktion wird in der Fakturierung berücksichtigt. Eine Historie ist sichergestellt. Ein Mitglied kann eine Ehrenmitgliedschaft bei einer Sektion haben (siehe z.B. https://www.sac-interlaken.ch/index.php/sektion/ehrenmitglieder) und bei einer anderen nicht. Ein Mitglied kann aber auch für den gesamten SAC als Ehrenmitglied ernannt werden (siehe https://www.sac-cas.ch/de/die-alpen/die-ehrenmitglieder-des-sac-10286/). Personen, die sich um den SAC und seine Zwecke oder um die Sektion ausserordentliche Verdienste erworben haben, können auf Vorschlag des Vorstandes durch die Hauptversammlung mit zwei Dritteln der anwesenden Stimmen zu Ehrenmitgliedern der Sektion ernannt werden. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_18: Ehrenmitglieder im Webauftritt publizieren“
Use Case ID | MV_18 |
---|---|
Beschreibung | Ehrenmitglieder wird auf den Webseiten der Sektionen sowie auf der SAC Webseite publiziert. Aktuell wird aus Navision eine Liste der Ehrenmitglieder gezogen und manuell importiert. Einige Beispiele: |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_19: Mitglieder mit Mahnstufe 2 kontaktieren”
Use Case ID | MV_19 |
---|---|
Beschreibung | Einige Sektionen kontaktieren ihre Mitglieder, die in der Mahnstufe 2 registriert sind, mit der Bitte um Begleichung der Rechnung. Hintergrund: bei nicht Begleichung, wird das Mitglied im nächsten resp. im 3. Mahnlauf automatisch vom System ausgetreten (siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9C3.-Mahnlauf---Mitglied-austreten-und-Rechnung-stornieren%E2%80%9C). Daher muss es für den Mitgliederdienst an der Geschäftsstelle und in der Sektion möglich sein, alle Mitglieder in der 2. Mahnstufe zu identifizieren - u.A. müssen die Kontaktinformationen und der Saldo ersichtlich sein. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_20: Mitglieder mit fehlenden Informationen kontaktieren“
Use Case ID | MV_20 |
---|---|
Beschreibung | Die Sektionen geben sich Mühe die Datenqualität deren Mitglieder Aufrecht zu erhalten. Mitglieder mit z.B. fehlenden E-Mail Adressen werden angefragt. Daher muss es für den Mitgliederdienst an der Geschäftsstelle und in der Sektion möglich sein, alle Mitglieder mit fehlenden Informationen zu identifizieren und zu kontaktieren. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_21: Mitglieder mit einem bevorstehenden Wechsel der Beitragskategorie informieren“
Use Case ID | MV_21 |
---|---|
Beschreibung | Aktuell informiert die Geschäftsstelle Ende des Jahres Mitglieder, für die einen automatischen Wechsel ihrer Beitragskategorie bevorsteht (weil ein Mitglied der Kategorie “Frei Kind” resp. “Jugend” das 18. resp. das 23. Lebensjahr erreicht). Entweder muss es für den Mitgliederdienst an der Geschäftsstelle möglich sein, betroffene Mitglieder zu identifizieren oder das System ist in der Lage automatisch eine E-Mail resp. ein Brief an die betroffenen Mitgliedern zuzustellen. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_22: Mitglieder mit Jubilare ehren”
Use Case ID | MV_22 |
---|---|
Beschreibung | Einige Sektionen ehren ihre Jubilarinnen und Jubilare bspw. in einer Hauptversammlung und/oder in ihrem Webauftritt (siehe https://www.sac-brandis.ch/news/ehrung-der.html oder https://sac-niesen.ch/60-jahre-sac-niesen/). Aktuell ehren nicht alle Sektionen ihre Mitglieder bei Jubiläen - dito bei der Ausstellung von Urkunden (Diplome) und Abzeichen (gilt auch für die nachfolgenden Aussagen). Der Zeitpunkt der Gratulation weicht ebenfalls von Sektion zu Sektion ab - z.B. gratuliert eine Sektion das Mitglied vor und die andere Sektion nach Vollendung von 50 Vereinsmitgliederjahren (gratuliert wird auch bei 25, 40 und 60 Vereinsmitgliederjahren). Die Erhebung der Mitglieder mit einem Jubiläum findet heute manuell statt: Mitgliederliste filtern auf Vereinsmitgliederjahre oder Eintrittsdatum) und zusammen mit ihren Kontaktdaten nach Excel exportieren. Bei Abzeichen und Urkunden wird manueller Aufwand bei Bestellung und Zustellung geleistet. Spezialfall: |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_23: Mitgliederstatistik ziehen“
Use Case ID | MV_23 |
---|---|
Beschreibung | Die Mitgliederstatistik ist ein heute oft benutztes Mittel vom Mitgliederdienst Geschäftsstelle und Mitgliederdienst Sektion. Aktuell kann in der Mitgliederstatistik ein von und bis Datum eingegeben werden, sodass der Zeitraum flexibel angepasst werden kann. Die statistischen Zahlen werden zwecks Veröffentlichung im Jahresbericht (siehe z.B. https://www.sac-cas.ch/de/die-alpen/jahresbericht-2018-2613/ oder https://sac-uto.ch/fileadmin/user_upload/documents/Jahresberichte/SAC_Uto_Jahresbericht_2022_-_mit_Revisionsbericht.pdf) oder im Webauftritt benutzt (siehe z.B. https://www.sac-cas.ch/de/der-sac/sektionen/sac-uto/). Folgende Kennzahlen werden in der Statistik ausgewiesen:
Die Statistik wird aktuell im Excel-Format ausgegeben - folgende Register werden angezeigt:
Beispiel: Spezialfälle:
→ Generell ist die Herausforderung Folgende: ein Austritt aus SAC ist nicht gleichzusetzen mit einem Austritt aus einer Sektion! Dito für Eintritte! Annahme: Auswertung findet nicht in Hitobito statt, sondern in einem BI Tool wie bspw. Power BI. Hitobito muss die Daten via API bereitstellen. |
Akteure |
|
Auslöser |
|
Vorbedingungen | Keine |
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_24: Hauptsektion wechseln“
Use Case ID | MV_24 |
---|---|
Beschreibung | Mitgliederdienst Geschäftsstelle kann auf Anfrage des Mitglieds die Hauptsektion ändern. Die Anpassungen werden bei der Fakturierung berücksichtigt. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_25: Zusatzsektion an- & abmelden“
Use Case ID | MV_25 |
---|---|
Beschreibung | Mitgliederdienst Geschäftsstelle kann auf Anfrage des Mitglieds die Zusatzsektion ändern. Die Anpassungen werden bei der Fakturierung berücksichtigt. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_26: Wiedereintritt vornehmen“
Use Case ID | MV_26 |
---|---|
Beschreibung | Mitgliederdienst Geschäftsstelle und Mitgliederdienst Sektion kann Wiedereintritte vornehmen, sodass Daten vom inaktiv gesetzten Kontakt auf die neue Mitgliedschaft übertragen und weitergeführt werden (z.B. Vereinsmitgliederjahre). Bei der Bearbeitung einer Neuanmeldung muss das System demnach in der Lage sein, solche Fälle zu identifizieren (siehe auch https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_9:-Duplikate-erkennen-und-bereinigen%E2%80%9D). Es gibt Mitglieder, die jedes Jahr ab Oktober eintreten und Ende des Jahres wieder austreten ohne die Rechnung jemals zu begleichen. Damit profitieren sie ein Jahr lang kostenlos vom SAC Angebot (u.A. erhalten sie den physischen Mitgliederausweis). Solche Fälle müssen verhindert werden, entweder indem der Mitgliederausweis erst nach Begleichung der offenen Rechnung zugestellt wird oder indem solche Mitglieder gekennzeichnet werden, sodass dies bei einer Wiederanmeldung ersichtlich ist. Heute werden solche Mitglieder auf einer Black List geführt, die sogenannte Sperrliste. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_27: SAC Abzeichen zustellen“
Use Case ID | MV_27 |
---|---|
Beschreibung | Aktuell gibt es 3 SAC Abzeichen, siehe - SCS-215Getting issue details... STATUS :
Nicht alle Sektionen stellen ihren Mitgliedern Abzeichen zu - dies vermutlich aus finanziellen Gründen (z.B. wird dies bei SAC Zermatt gemacht, bei SAC Uto nicht). Lieferung findet durch einen externen Partner, https://www.b-bern.ch/, statt. Bestellung wird vom Mitgliederdienst Geschäftsstelle manuell gemacht, mittels einer Vorlage namentlich “Lieferschein” - siehe: Spezialfall: |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MV_28: SAC Urkunde zustellen“
Use Case ID | MV_28 |
---|---|
Beschreibung | Die SAC Urkunde resp. das SAC Diplom wird Mitgliedern bei Erreichen von 50 Vereinsmitgliederjahren zugestellt. Es handelt sich hierbei um eine papierbasierte Urkunde, die auf das Mitglied personalisiert und vom SAC Präsidenten (Stefan Goerre) unterschrieben ist. Nicht alle Sektionen stellen ihren Mitgliedern eine Urkunde zu - vermutlich aus finanziellen Gründen (CHF 10/Diplom). Ein externer Partner, https://www.bubenberg.ch/, macht ein Vordruck - die Personalisierung sowie Post Zustellung findet intern statt. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
OFFEN
Use Case “MV_29: Mitglied Erstfakturierung vornehmen“
Bei Neueintritt
Spezielle Reduktionen bei unterjährigem Eintritt zu berücksichtigen!
Schnittstellenthematik "Buchhaltungssoftware"
Mit MV klären, ob Wochenversand und Mini Inkasso als Use Cases gelistet sein müssen
Kostenschätzung:
Bei Neuregistrierung automatisch eine Zahlungsaufforderung erstellen (Betrag wird in MV_35 berechnet)
Nach Bezahlung der Erstfakturierung automatisch Mitgliedschafts-Rolle erstellen
Anbindung von RaiseNow oder Payrexx als Zahlungskanal für Zahlungsaufforderungen
Use Case “MV_30: Mitglied Erstfakturierung aufheben“
Schnittstellenthematik "Buchhaltungssoftware"
Kostenschätzung:
Zahlungsaufforderung manuell löschen können
Use Case “MV_31: Mitglied Korrekturfakturierung vornehmen“
Schnittstellenthematik "Buchhaltungssoftware"
Mit MV klären ob es zwischen Korrekturfaktura und Erneuerungsfaktura ein Unterschied gibt, oder ob es sich um dasselbe handelt
Kostenschätzung:
Anforderungen unklar, Zahlungsaufforderung manuell bearbeiten können
Use Case “MV_32: Mitglied Jahresrechnung zustellen“
Thema Jahresinkasso; Möglichkeit Rechnungen zum Druck an externen Partner, Baumann AG, im csv Format zuzustellen
Auch Nuller-Rechnungen müssen generiert, zugestellt und abgebucht werden!
Schnittstellenthematik "Buchhaltungssoftware"
Kostenschätzung:
Für gefilterte Liste von Personen eine Zahlungsaufforderung für die Jahresrechnung erstellen
Erstellte Zahlungsaufforderungen soweit möglich via E-Mail versenden
Einzelne Zahlungsaufforderung manuell als PDF exportieren
Alle automatisch erstellten Zahlungsaufforderungen ohne Empfänger-E-Mail als PDF exportieren
Use Case “MV_33: Mitglied mahnen“
1. und 2. Mahnlauf
3. Mahnlauf: siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_29:-Dritter-Mahnlauf---Mitglied-austreten-und-Rechnung-stornieren%E2%80%9C zwei Etappen - zuerst Mitgliedschaft auflösen, Rechnung beibehalten und danach Rechnung stornieren
Kostenschätzung:
Zahlungsaufforderungen nach Bezahlungsstatus und Fälligkeitsdatum filtern
Liste von Zahlungsaufforderungen als CSV/Excel exportieren
Use Case “MV_34: Mitglied Rechnung stornieren“
Manuell vs. automatisch (https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_29:-Dritter-Mahnlauf---Mitglied-austreten-und-Rechnung-stornieren%E2%80%9C )
Kostenschätzung:
(Zahlungsaufforderung manuell löschen können ist bereits in MV_30)
Use Case “MV_35: Mitglied Vorauszahlungen gutschreiben“
Thema Gutschrift als Reduktion in der nächsten Rechnung, wenn Mitglied z.B. fälschlicherweise doppelt einzahlt
Kostenschätzung:
(Kein Thema mehr mit dem Zahlungsaufforderungs-System)
Use Case “MV_35: Fakturaelemente berechnen“
Thema Reduktion, Preiskalkulation (siehe 150 Ausprägungen unter /wiki/spaces/ERP/pages/936640554 “SAC Mitgliedschaft - OMSMO - Matrix der Fällen“)
Business Logik in Hitobito oder in einer Middleware auslagern
Kriterien, die die Kalkulation beeinflussen: Eintrittsdatum, Beitragskategorie, Ehrenmitglied, Begünstigt, Anzahl Vereinsmitgliederjahre, Geschenkmitgliedschaft, Vorauszahlung, unterj. Eintritt, Alter, Gratis-Abo, Zusatz Zeitschriften, Zusatz Sektionen
Kostenschätzung:
Separat betriebenes Business-Logik-Modul: Setup GIT, Basis-Projekt, Entwicklungsumgebung, BuildChain, Deployment auf Integration und Produktion, Reporting Framework, Monitoring, API-Zugang zur Haupt-Applikation
Berechnung und Bezeichnungen für Zentralverbands-Beitrag für 6 Varianten der Hauptsektions-Mitgliedschaft
Use Case “MV_36: Mitglied Debitorensperre einrichten“
Bei automatischer Storno 3. Mahnlauf oder wenn Mitglied auf Streichliste registriert ist
Use Case “MV_37: Mitglied Mahnsperre einrichten“
Sodass Mitglied nicht erneut gemahnt wird
Use Case “MV_38: Mitglied beim 3. Mahnlauf automatisch austreten & Rechnung stornieren“
zwei Etappen - zuerst Mitgliedschaft auflösen, Rechnung beibehalten und danach Rechnung stornieren
Use Case “MV_39: Mitglied bei Anruf automatisch aufrufen”
Anhand Telefonnummer Mitglied erkennen und dem MV im Tool automatisch anzeigen
Mit MV klären, wie kritisch diese Anforderung ist + mit Puzzle klären, ob technisch umsetzbar
Use Case “MV_40: Listen”
Schnittstellenthematik "Mitgliederdaten-Uebertrag"
Mithilfe von MV verstehen, was die Use Cases folgender Listen sind:
Kontakt Liste
Mitglied Liste
Mitglieder mit Sektionswechsel, Beitragskategoriewechsel
Use Case “Statistik prüfen”???
Use Case “Geldeinflüsse prognostizieren”???
Ansatz Mitgliederfakturierung
Use Case “Jahresrechnung prüfen”???
Use Case “Eingenommene Sektionsbeiträge verifizieren“???
SAC Sektionen
Use Case “Event mit Sektionen organisieren”???
Use Case “Empfängerliste für Kommunikationen erstellen“
Alle Sektionsfunktionäre
Registrierte Mahnungen
zur Auskunftsbereitschaft bei Kontaktaufnahme eines Mitglieds / Anfrage zur Mahnung
zum Drucken aller registrierten Mahnungen
zum Exportieren aller registrierten Mahnung, damit diese an eine Druckerei zwecks Druck übergeben werden können
Alle Mitgliedereinnahmen
zur Verifikation des vom Zentralverband überwiesenem Betrags an die Sektion
zur Verifikation der Geldausflüsse an die Sektionen
Alle Sektionsposten
für die Dienstleistungsabrechnung
zur Verifikation des vom Zentralverband geforderten Betrags aufgrund Nutzung von Dienstleistungen des Zentralverbands
zur Verifikation der Geldeinflüsse durch erbrachte Dienstleistungen für die Sektionen
Alle Geschenkmitgliedschaften
Capability “Tourenleiterverwaltung”
[Exkurs] Tourenleiter-Portal
Die Sektionen arbeiten heutzutage mit einem Tourenleiterportal um neue Tourenleiter in ihrer Sektion einzutragen, bestehende Tourenleiterdaten ihrer Sektion zu bearbeiten und Auswertungen ihrer Sektion zu generieren. Bestimmte Funktionäre wie Tourenchefs, Präsidenten erhalten einen geschützten Zugang mit definierter Zugangsberechtigung welche zentral im Verwaltungstool verwaltet wird. Die Einträge und die Pflege der Daten erfolgen über ein Formular, der die Daten in Navision schickt. Der Verantwortliche auf der Geschäftsstelle prüft die eingetragenen Daten und aktualisiert automatisch (mit einem Klick) die Daten im System. Ein entsprechendes Portal muss den Sektionen zur Verfügung stehen. Das Portal muss mehrsprachig sein.
Use Case “TL_1: Tourenleiter erfassen & verwalten”
Use Case ID | TL_1 |
---|---|
Beschreibung | Mitglieder der Sektion können, mit Ausnahme der nach Reglement bestimmten alpinen Tourenleiter mit Fortbildungspflicht, vom Tourenchef als Tourenleiter erfasst, mutiert oder gelöscht werden. Der Tourenchef hat demnach Zugriff auf die Mitglieder, die aktuell eine aktive Mitgliedschaft bei der Sektion haben (entweder als Hauptstamm oder als Zusatzsektion). Zudem kann eine Liste aller Tourenleiter mit ihren Adressdaten gezogen, gefiltert und heruntergeladen werden. Aktuell ist diese Liste wie folgt aufgebaut: → Siehe auch https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CFunktion%C3%A4re-erfassen-und-verwalten%E2%80%9D. Navision Anleitung: 5. Neuen Tourenleiter erstellen. Sonderfall: In der Datenbank werden auch Nichtmitglieder mit der Qualifikation SAC Tourenleiter erfasst.
|
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_2: Adressdaten erfassen & verwalten”
Use Case ID | TL_2 |
---|---|
Beschreibung | Tourenchefs müssen befähigt sein, die Adressdaten eines Tourenleiters oder eines Mitglieds zu erfassen, mutieren und zu löschen. Mithilfe einer Export-Funktion können die Adressdaten heruntergeladen werden (z.B. Excel). TODOTODO Verarbeitung erfasster/mutierter Daten für die Tourenleiterdatenbank |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_3: Tourenleiterstatus erfassen & verwalten”
Use Case ID | TL_3 |
---|---|
Beschreibung | Verfügt ein Tourenleiter über eine Qualifikation, die bis zum heutigen Datum gültig ist, kann dieser vom Tourenchef auf den Status “Aktiv” gesetzt werden. Damit kann er/sie Touren in einer Sektion leiten. Umgekehrt, kann der Tourenchef den Status eines aktiven Tourenleiters auf “inaktiv” setzen. Anleitung Navision: 6. Einen Tourenleiter aktiv / inaktiv setzen. |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_4: Ausbildungskurse erfassen & verwalten”
Use Case ID | TL_4 |
---|---|
Beschreibung | Tourenchefs müssen befähigt sein, Ausbildungskurse resp. die Fortbildungsstunden der Tourenleitenden einzusehen, zu erfassen, mutieren und zu löschen. Hier wird eine Stapelverarbeitung (gleicher Eintrag für mehrere Tourenleiter der Sektion) beim Erfassen von "extern" (nicht von der Geschäftsstelle organisierten Kursen) besuchten Kursen (z.B. in der Sektion, bei Bergsportschulen, J+S oder anderen Alpen-Vereinen) angeboten. Aktuell gibt es eine Liste in Navision, die die Fortbildungsstunden ausweist (u.A. werden folgende Informationen aufgelistet: Kontakt Nummer, Name, Anzahl Fortbildungsstunden). Die Liste dient insbesondere der Kursadministration zur Kontrolle der Verlängerungen von Qualifikationen. Dabei hat der User diverse Filtermöglichkeiten in der Liste: Anleitung Navision: 8. Absolvierte Kurse (Ausbildungshistory) |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_5: Qualifikationen erfassen & verwalten”
Use Case ID | TL_5 |
---|---|
Beschreibung | Tourenchefs müssen befähigt sein, Qualifikationen der Tourenleitenden einzusehen, zu erfassen, mutieren und zu löschen. Aktuell ist die Kontaktkarte eines Tourenleiters in Navision wie folgt aufgebaut: Gültigkeitsfristen und Verlängerungen der Ausweise/Qualifikationen werden automatisch berechnet. Das System muss demnach erkennen können, wenn Teilnehmer eine Mindestdauer der Qualifikationen erfüllt haben und verlängert dann die bestehende Qualifikation automatisch. Dies geschieht über die erfassten Weiterbildungstage in den Kursen. Nachfolgend einige Erläuterungen zu den Qualifikationen:
Anleitung Navision: 7. Qualifikationen |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_6: Bemerkungen erfassen & verwalten”
Use Case ID | TL_6 |
---|---|
Beschreibung | Der Tourenchef muss befähigt sein, für Tourenleitende Bemerkungen in einem Freitextfeld zu erfassen, mutieren und zu löschen. Aktuell erscheint eine Erfassungsmaske in Navision, wenn auf der Kontaktkarte des Tourenleiters auf den Button “Bemerkungen” geklickt wird (siehe Screenshot unten). Dort hat der User die Möglichkeit, neue Bemerkungen zu erfassen oder bestehende Bemerkungen zu verwalten. Eine Bemerkung wird standardmässig einem Thema zugeordnet, weil Bemerkungen nicht nur im Kontext von Tourenleiter relevant sind. Es soll auch die Möglichkeit geben, Bemerkungen entlang von diversen Filterkriterien zu suchen und zu exportieren. Aktuell sieht die Umsetzung in Navision wie folgt aus: |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_7: Subventionsantrag bearbeiten”
Use Case ID | TL_7 |
---|---|
Beschreibung | Der Tourenchef muss im Zuge des Kursanmeldungsprozesses befähigt sein, Anträge für Subventionsbeiträge zu bearbeiten. Wenn ein neuer Antrag gestellt wird, soll der Tourenchef darüber informiert werden (z.B. E-Mail, Nachricht im Portal). Die Einwilligung/Ablehnung wird direkt/halbautomatisch in das Verwaltungstool der Kursverwaltung eingepflegt.) |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_8: Tourenchef benachrichtigen”
Use Case ID | TL_8 |
---|---|
Beschreibung | Der Tourenchef soll bei folgenden Fällen benachrichtigt werden (z.B. via E-Mail, SMS oder direkt im Portal):
|
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_9: Tourenleiter benachrichtigen”
Use Case ID | TL_9 |
---|---|
Beschreibung | Ablaufende Ausbildung → Reminder an Kontakt Tourenleiter mit ablaufenden Qualifikationen kontaktieren Abgelaufen vs. sistiert? |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_10: Tourenleiter suchen”
Use Case ID | TL_10 |
---|---|
Beschreibung | Das Tool soll berechtigten Usern die Möglichkeit geben nach Tourenleitern zu suchen. Die Suche soll entlang diversen Filterkriterien möglich sein. In der Liste sollten u.A. folgende Attribute ausgegeben werden:
Diese Liste dient ad-hoc Reporting Bedürfnisse sowie wiederkehrenden Anfragen - nachfolgend ein paar Beispiele:
Anleitung Navision: 11. Filtermöglichkeiten und 13. Formeln für Filterbedingungen. |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_11: Funktionäre erfassen & verwalten”
Use Case ID | TL_11 |
---|---|
Beschreibung | Funktionäre in den Sektionen sollen befähigt sein, ihre Funktionäre zu verwalten (bestehende Funktionäre mutieren/löschen und bestehende Mitglieder zu einem neuen Funktionär ernennen). Heute geschieht dies in Navision anhand der Verteilercodes. Nachfolgend einige Beispiele von solchen Funktionären:
Der Portalzugang respektive die Zugangsberechtigungen bei solchen Mutationen laufen automatisch. D.h. der neue Funktionär erhält vom System die Zugangsdaten mit den hinterlegten Berechtigungen und für den ausscheidenden Funktionär wird der Zugang entsprechend gesperrt. Berechtigte Personen müssen befähigt sein, eine Liste der Funktionäre zu ziehen und zu exportieren (wichtige Infos in der Ausgabe: Kontakt Nummer, Name, Adresse, Telefon, Geburtsdatum, E-Mail, Sektion, Funktion). Solche Listen dienen z.B. als Empfängerliste für Kommunikationen. |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_12: Stammblatt erstellen & zustellen”
Use Case ID | TL_12 |
---|---|
Beschreibung | Berechtigte Personen müssen befähigt sein, Stammblätter der Tourenleiter zu ziehen und zuzustellen. Aktuell kann ein Tourenchef im Tourenleiterportal über ein Button (“Stammblatt”) ein Stammblatt erzeugen lassen: Dabei kann der User in einem Selektionsfenster das Mitglied selektieren und gewisse Elemente ein-/ausblenden (z.B. Qualifikationen, Ausbildungen, Bemerkungen): Das Stammblatt ist derzeit wie folgt aufgebaut: Anleitung Navision: https://saccas.atlassian.net/wiki/spaces/DOC/pages/3642916865/4.+Aktionen+Wizard+Stammblatt+Tourenleiter+bersicht#Stammblatt-erstellen TODOTODOTODO Standard-Reports |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Use Case “TL_13: Termine erfassen, verwalten & publizieren”
Use Case ID | TL_13 |
---|---|
Beschreibung | Geschäftsstelle sowie Sektionen sind befähigt Termine zu erfassen und zu verwalten. Auf Wunsch können Termine in einem Terminkalender mit allen resp. mit anderen Rollen geteilt werden. |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung | TODO |
Capability “Hüttenverwaltung”
[Exkurs] Hüttenportal
Das Hüttenportal wird von Hüttenwarten, Hüttenpartner, Hüttenchefs, Sektionspräsidenten sowie Mitarbeitenden an der Geschäftsstelle bedient.
Folgende Use Cases werden damit abgedeckt:
Stammdatenpflege (eingeschränkt auf ein paar Attribute)
Jährliche Erfassung von Umsatzzahlen und Übernachtungsstatistiken
Bestellung von Militär-/Materialtransporte
Aktuell dient Navision als Master-System für die Stammdatenpflege der Hütten. Mittels einer ODATA-Schnittstelle werden alle Hütten und deren Stammdaten an das Hüttenportal weitergereicht. Einige Attribute können im Hüttenportal angepasst werden (z.B. Öffnungszeiten, Anzahl Schlafplätze, Hüttenattribute) und einige Attribute werden nur im Lese-Modus angezeigt (z.B. Hüttenname). Bei Mutationen werden die neuen Werte mittels der ODATA-Schnittstelle zurück nach Navision geschrieben. Zudem hat Navision aktuell die Rolle, die Beziehungen der Hütten abzubilden. Eine Hütte kann eine Beziehung zu einer Sektion haben sowie zu Personen (z.B. Hüttenwart, Hüttenchef, Hüttenobmann). Die Beziehungen dienen insbesondere der Autorisierung und Authentifizierung via WSO2.
Die jährlich erfassten Umsatzzahlen und Übernachtungsstatistiken dienen der Geschäftsstelle zur Berechnung des Hüttenfonds und auch der Weiterverrechnung von Kosten an die Sektionen. Die Erfassung erfolgt meist direkt von den Hüttenwarten, wobei ein Approval Flow sicherstellt, dass ein Visum seitens Hüttenchef und/oder Sektionspräsident gegeben ist. Erst mit dem Visum werden die Daten an die Geschäftsstelle weitergereicht; ab dem Moment können die Werte nicht mehr mutiert werden (die Geschäftsstelle hat die Möglichkeit das Formular zur Bearbeitung wieder freizuschalten). Damit die Daten jährlich erfasst werden können, eröffnet die Geschäftsstelle ein neues Jahr im Hüttenportal und informiert die Personen via E-Mail.
Im Hüttenportal können mittels eines Anmeldeformulars Militärflüge zwecks Materialtransporte bestellt werden. Auch hier ist ein Approval Flow, wie oben beschrieben, vorgesehen. Die Flüge werden dem SAC gratis angeboten, sprich keine Kosten werden der Sektion weiterverrechnet. Die Geschäftsstelle sammelt auf jährlicher Basis die Bestellungen und leitet diese an die Luftwaffe weiter.
Das von Garaio entwickelte Hüttenportal benutzt für das Frontend die Low-Code Lösung von Microsoft namentlich Power Apps resp. Power Portal und für das Backend die Datenbank-Lösung von Microsoft namentlich Dataverse.
Das Hüttenportal ist im ständigen Ausbau. Derzeit ist unklar welches System in Zukunft Master für die Stammdatenpflege sein wird. Es gibt unterschiedliche Meinungen dazu; die Mehrheit jedoch wünscht das Hüttenportal und nicht Hitobito als Master-System zu zu haben. Dies insbesondere, weil Business Logik im Hüttenportal enthalten ist und weil Hitobito ein CRM- und kein Ressourcen-Management-Tool ist. Puzzle schlägt vor, dass Hitobito die Hütten zwar abbildet, dies aber rein um die Beziehungen zwecks Autorisierung und Authentifizierung im Hüttenportal und OHRS vorzunehmen. Es wird davon abgeraten, die Stammdaten in Hitobito zu pflegen. Dieser Vorschlag wird bei den nachfolgenden Use Cases, insbesondere zugunsten Schätzung, als Annahme getroffen. Dieser Vorschlag wird bei den nachfolgenden Use Cases, insbesondere zugunsten Schätzung, als Annahme getroffen.
Weiterführende Informationen können hier gefunden werden: 02 TP1 : Spezifikationen - Neue ERP Lösung - Confluence (atlassian.net)
Use Case “HV_1: Hütte erfassen”
Use Case ID | HV_1 |
---|---|
Beschreibung | Aktuell kann die Geschäftsstelle in Navision diverse Stammdaten zu einer Hütte erfassen. Grundsätzlich gilt es zwischen drei Hüttenkategorien zu unterscheiden:
Folgende Informationen können aktuell in Navision erfasst werden:
Annahme: Zukünftiges Mastersystem ist das Hüttenportal. In Hitobito sollten die Hütten in minimalistischer Form abgebildet werden. Dies insbesondere um die Beziehungen abzubilden (Hütte ↔︎ Sektion und Hütte ↔︎ Person). Die Abbildung der Beziehungen ist zentral für Autorisierungsthemen, denn die heutige Annahme ist, dass WSO2 mit dem IDS von Hitobito ersetzt werden soll. Davon soll auch das Hüttenportal profitieren. |
Akteure |
|
Auslöser |
|
Vorbedingungen | - |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “HV_2: Hütte Stammdaten verwalten”
Use Case ID | HV_2 |
---|---|
Beschreibung | |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “HV_3: Hütten im Webauftritt publizieren“
Use Case ID | HV_3 |
---|---|
Beschreibung | Annahme: Hüttenportal ist zukünftig verantwortlich für den Datenübertrag an Typo3 zwecks Publikation der Hütten unter https://www.sac-cas.ch/de/huetten-und-touren/sac-tourenportal/?type=hut |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “HV_4: Hüttenbeziehungen verwalten“
Use Case ID | HV_4 |
---|---|
Beschreibung | u.A. zwecks Autorisierung via WSO2 Beziehungen:
Funktionen:
|
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “HV_5: Hüttenfunktionäre kontaktieren“
Use Case ID | HV_5 |
---|---|
Beschreibung | Es soll möglich sein, eine Liste aller Hütten mit deren Funktionären zu exportieren. Die Liste dient zur Kontaktaufnahme z.B. zwecks Einladung zu Tagungen. |
Akteure |
|
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Capability “Athletenverwaltung”
[Exkurs] Athletenverwaltung
…
Weiterführende Informationen können hier gefunden werden: 02 TP4 : Spezifikationen - Neue ERP Lösung - Confluence (atlassian.net)
Use Case “AV_1: Athleten erfassen”
Use Case ID | AV_1 |
---|---|
Beschreibung | Annahme: Use Case bereits abgedeckt in https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_5:-Nicht-Mitglieder-als-Person-hinzuf%C3%BCgen%E2%80%9D |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “AV_2: Athleten Stammdaten verwalten”
Use Case ID | AV_2 |
---|---|
Beschreibung | Annahme: Use Case bereits abgedeckt in https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_5:-Nicht-Mitglieder-als-Person-hinzuf%C3%BCgen%E2%80%9D |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “AV_3: Athleten im Webauftritt publizieren”
Use Case ID | AV_3 |
---|---|
Beschreibung | siehe https://www.sac-cas.ch/de/leistungssport/sportklettern/elite-nationalmannschaft/ |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Capability “Marketing / Redaktion / Verlag”
[Exkurs] Fundraising
Aktuell werden Spenden beim SAC über zwei Kanäle gesammelt:
Spendenaufruf im Webauftritt
Unter https://www.sac-cas.ch/de/der-sac/spenden/ gibt es die Möglichkeit für ein Thema zu spenden: Spenden für SAC-Hütten, Spenden für den Naturschutz, Allgemeine Spende, Ereignisspende, Trauerspende, Erbschaft und Legat. Dabei muss der Spender ein Formular ausfüllen. Die Zahlung erfolgt via Kreditkarte (Visa oder MasterCard), Twint oder PostFinance.
Spendenaufruf über Directmarketing-Partner Küba
Der SAC stellt Küba regelmässig Mitgliederlisten zur Verfügung (siehe /wiki/spaces/ERP/pages/3537436673 ). Diese Listen importiert Küba in ihre Spenderdatenbank. Bei der Spenderdatenbank handelt es sich um die von Küba entwickelte Lösung DONMAN (kurz für Donation Manager). Die Spenderdatenbank umfasst nicht nur Kontakte, die der SAC der Küba mitteilt, sondern weitere Kontakte, die ein Opt-In für Spendenaufrufe gegeben haben. Diese Kontakte sind in Navision nicht erfasst. Zudem validiert Küba sämtliche Adressen, die in der Spenderdatenbank erfasst sind. Ausgewählte Mitarbeitende beim SAC haben Zugriff auf die Spenderdatenbank – weil Küba eine Lizenz mit uns teilt (Gentleman Agreement). Küba leitet die Kontakte, die man anschreiben möchte, weiter an Baumann AG. Baumer AG wiederum druckt und verschickt die Briefe.
Die heutige Lösung ist einerseits papierbasiert und andererseits für den Spender zeitaufwändig einen Beitrag zu spenden. In Zukunft möchte der SAC eine Fundraising-Software im Einsatz haben, die ihnen digitale Spendenaufrufe in unterschiedlichsten Kanälen ermöglicht (z.B. E-Mail, Twint). Der Prozess für den Spender soll schlanker gestaltet sein, sodass der Zeitaufwand für den Spender auf ein Minimum reduziert ist. Es gibt in der NPO-Welt nicht viele Fundraising-Anbieter, gemäss Internetrecherchen hat RaiseNow eine Monopolstellung. Spannenderweise bietet RaiseNow nicht nur Features rund um Fundraising an, sondern auch Dienstleistungen mit der sie die Zahlungsabwicklung von Organisationen vereinfachen (siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3884875777/Zahlungsdienstleister+im+berblick#Empfehlung-/-Fazit ). Gemäss RaiseNow kann eine Organisation nur dann von ihrem NPO-Angebot profitieren, wenn die Organisation den Zewo-Gütesiegel besitzt (siehe https://zewo.ch/de/). In Rücksprache mit der Fundraising-Abteilung wurde bestätigt, dass der SAC dieses Zertifikat nicht besitzt. Der Gütesiegel sei teuer und weil der SAC den Jahresabschluss nach Swiss GAAP FER abschliesst, hielten sie den Siegel für nicht notwendig. Diese Diskussion muss vorerst wieder aufgenommen werden.
Weiterführende Informationen können hier gefunden werden: 02 TP2 : Spezifikationen - Neue ERP Lösung - Confluence (atlassian.net)
Use Case “MR_1: Autoren & Übersetzer erfassen”
Use Case ID | MR_1 |
---|---|
Beschreibung | Annahme: Use Case bereits abgedeckt in https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_5:-Nicht-Mitglieder-als-Person-hinzuf%C3%BCgen%E2%80%9D |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Offene Punkte | |
In Scope für Demo | |
Arbeitspakete | |
Kostenschätzung | 0 |
Use Case “MR_2: Autoren & Übersetzer Stammdaten verwalten”
Use Case ID | MR_2 |
---|---|
Beschreibung | Annahme: Use Case bereits abgedeckt in https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_5:-Nicht-Mitglieder-als-Person-hinzuf%C3%BCgen%E2%80%9D |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “MR_3: Honorare der Autoren & Übersetzer abrechnen“
Use Case ID | MR_3 |
---|---|
Beschreibung | Annahme: Anforderung an das HR Modul, ERP-System - keine Aufwände in Hitobito |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “MR_4: Zeitschriften Abonnement verwalten”
Use Case ID | MR_4 |
---|---|
Beschreibung | Ein Mitglied erhält standardmässig ein Zeitschriften-Abonnement bestehend aus
Standardmässig werden die Zeitschriften per Post zugestellt. Es können auch nicht-SAC-Mitglieder ein Zeitschriften-Abonnement gegen Aufpreis einlösen. Der Mitgliederdienst an der Geschäftsstelle oder in der Sektion kann eine bestehende Zeitschrift im Abonnement per sofort oder ab einem Datum in der Zukunft deaktivieren. Sie haben auch die Möglichkeit zusätzliche Zeitschriften im Abonnement hinzuzufügen (z.B. Die Alpen in einer anderen Sprache oder ein Bulletin einer “fremden” Sektion). Anpassungen im Abonnement werden bei der Fakturierung berücksichtigt. Ebenfalls können sie den Zustellungskanal pro Zeitschrift konfigurieren. Das Mitglied kann im Portal (siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CProfilinformationen-eines-Mitglieds-mutieren%E2%80%9D) die abonnierten Zeitschriften sehen und konfigurieren, wie die einzelnen Zeitschriften zugestellt werden sollen (physisch oder elektronisch). |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MR_5: Zeitschrift Die Alpen senden“
Use Case ID | MR_5 |
---|---|
Beschreibung | Beim Massenversand der Bergsportzeitschrift Die Alpen kommt eine Empfängerliste zum Einsatz, die der Mitgliederdienst generiert, exportiert und der Druckerei bereitstellt (der Massenversand findet extern statt). Jährlich gibt es 6 Ausgaben. Bei der Person ist hinterlegt, ob die Zeitschrift elektronisch oder per Post zugestellt werden soll. Empfänger der Zeitschrift sind nicht zwingend SAC Mitglieder, sondern können lediglich Abonnenten sein, siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CZeitschriften-Abonnement-verwalten%E2%80%9D und https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CBeitragskategorie-aktivieren,-deaktivieren-und-wechseln%E2%80%9D. Spezialfall:
|
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MR_6: Zeitschrift Sektionsbulletin senden“
Use Case ID | MR_6 |
---|---|
Beschreibung | Bulletinlisten kommen beim Versand des Bulletins (Clubnachrichten) in einer Sektion zum Zuge. Dabei erzeugt der Mitliederdienst an der Geschäftsstelle oder in der Sektion die Liste und benutzt diese in einem weiteren Schritt zur Erzeugung und zum Druck der Etiketten. Das Format der Etikette von Sektion zu Sektion abweichen. Dieser Use Case kommt dann vor, wenn die Dienstleistung der Geschäftsstelle nicht in Anspruch genommen wird. Es können auch Mitglieder in anderen Sektionen das Sektionsbulletin erhalten. Manche Sektionen bieten eine elektronische Zustellung ihrer Clubnachrichten an. Spezialfall:
|
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf |
|
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MR_7: Etikette drucken”
Use Case ID | MR_7 |
---|---|
Beschreibung | Etiketten dienen der individuellen Nachsendung von Zeitschriften (Die Alpen). Dabei erstellt der Mitgliederdienst an der Geschäftsstelle bei einer Kundenanfrage die Etikette, druckt und benutzt diese als Empfänger Etikette (für den Massenversand ist ein anderer Prozess vorgesehen, siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMassenversand-Die-Alpen%E2%80%9C). Etiketten kommen auch bei den Sektionsbulletins (Clubnachrichten) zum Zuge. Als Dienstleistung bietet die Geschäftsstelle an, die Etiketten für eine Sektion zu erstellen, zu drucken und der Sektion per Post zuzustellen. Etwa ein fünftel der Sektionen macht von dieser Dienstleistung Gebrauch - die restlichen Sektionen drucken ihre Etiketten selbständig aus. Dazu machen sie von der Bulletinliste Gebrauch, siehe https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CBulletinliste-erstellen%E2%80%9C. Das Format der Etiketten kann von Sektion zu Sektion abweichen. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf | Individuelle Nachsendung:
Dienstleistung für Sektion:
|
Schnittstellen | |
Gap Analyse | Keine |
Kostenschätzung |
|
Use Case “MR_8: Spende Kampagne starten”
Use Case ID | MR_8 |
---|---|
Beschreibung | Annahme: Spendenaufrufe werden nicht in Hitobito gemacht, sondern in RaiseNow - keine Aufwände in Hitobito. Fundraising Kampagnen sind in der Verantwortung der Marketing Abteilung. Die Ausführung findet vom externen Partner Künzler Bachmann AG (Küba) statt. Auf dem Kontakt muss ersichtlich sein, ob ein Opt-In für Spendenaktionen gegeben ist. Dieser Use Case ist hier abgedeckt: https://saccas.atlassian.net/wiki/spaces/DIGISAC/pages/3868098614/Use+Case+Katalog#Use-Case-%E2%80%9CMV_7:-Mitglieder-von-aussen-abfragen%E2%80%9C |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “MR_9: Ein- und Austrittsgründe auswerten”
Use Case ID | MR_9 |
---|---|
Beschreibung | Annahme: Auswertung findet nicht in Hitobito statt, sondern in einem BI Tool wie bspw. Power BI. Hitobito muss die Daten via API bereitstellen. |
Akteure | TODO |
Auslöser | TODO |
Vorbedingungen | TODO |
Standardablauf | TODO |
Schnittstellen | |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MR_10: Newsletter senden”
Use Case ID | MR_10 |
---|---|
Beschreibung | Aktuell wird MailChimp für das Versenden von Newslettern verwendet (z.B. SAC Inside, Navision Newsletter). Der Prozess dahinter ist manuell und eine in-house entwickelte Komponente, “MonkeyCurator”, kommt zum Einsatz. Abo in Hitobito mit Mailchimp oder anderem Anbieter Synchronisation (Mailchimp bereits vorhanden) |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung |
|
Use Case “MR_11: FAN Accounts verwalten”
Use Case ID | MR_11 |
---|---|
Beschreibung | Beim SAC haben nicht-SAC Mitglieder die Möglichkeit kostenlos ein SAC Login anzulegen. Mit dem können sie im Vergleich zu einem SAC-Mitglied eingeschränkt von den SAC Angeboten profitieren (z.B. SAC Tourenportal). Diese FAN Personen werden aktuell nicht in Navision geführt, nur in WSO2. Die FAN Accounts möchte man im neuen CRM-Tool abgebildet bekommen. Es soll zudem die Möglichkeit geben, ein FAN zu einem SAC-Mitglied zu konvertieren. Wenn FAN Personen eine SAC Mitgliedschaft beantragen, wissen sie nicht immer, dass sie bereits ein SAC Login besitzen. Daher hat die Dublettenprüfung in diesem Kontext einen hohen Wert. Neuer Gruppentyp auf Top-Layer für FAN Accounts wie z.B. SAC-Tourenportal-Abonnenten. Evtl. lässt sich dieses Konzept gleich noch weiter ausbauen um auch die Nicht-Mitlieder Abonnenten von ‘Die Alpen’ abzudecken usw. abzudecken. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf | TODO |
Schnittstellen | TODO |
Gap Analyse | TODO |
Kostenschätzung |
|
Capability “Bereichsübergreifend”
[Exkurs] …
….
Weiterführende Informationen können hier gefunden werden: 02 TP9 : Spezifikationen "Übergreifende Themen" - Neue ERP Lösung - Confluence (atlassian.net), 02 TP8 : Spezifikationen - Neue ERP Lösung - Confluence (atlassian.net), 02 TP7 : Spezifikationen - Neue ERP Lösung - Confluence (atlassian.net)
Use Case “BÜ_1: Listen individuell konfigurieren”
Use Case ID | BÜ_1 |
---|---|
Beschreibung | Liste_Generell_Aufruf: Verschiedene vordefinierte Listen sollten direkt im Tool aufrufbar sein. Alternativ, wird der User beim Aufruf einer parametrisierten URL-Adresse ausserhalb des Tools direkt zur Liste im Tool weitergeleitet. Bereits Standard-Feature von Hitobito Liste_Generell_Anzeige: Listen auf verschiedene Granularitätsstufen sollten angezeigt werden. Was ist damit gemeint? Man kann bereits in Hitobito auf verschiedenen Ebenen Filtern. Liste_Generell_Drilldown: Der User kann auf einzelne Zeilen, die in der Liste angezeigt werden, abtauchen (Detailansicht). Bei Personen-Listen landet man beim Klick auf der Detailseite der Person Liste_Generell_Schnellsuche: Der User hat in der Listenansicht über ein Suchfeld die Möglichkeit nach einem Wert zu suchen (Schnellsuche). Jede Liste kann in ein CSV/XLSX Exportiert werden und man kann die Filtermöglichkeit von Excel nutzen. Direkt auf der Liste bietet das Hitobito heute nicht. Braucht es das? was sind die Use Cases? Personen/Gruppen/Events usw. können über die Globale Suche gesucht werden. Liste_Generell_Detailsuche: Der User hat in der Listenansicht die Möglichkeit auf jede angezeigte Spalte zu filtern (Detailsuche). Dabei werden dem User verschiedene Operanden angeboten wie z.B. grösser/kleiner (gleich), zwischen, beinhaltet Zeichen (nicht), startet/endet mit. Eine kombinierte Suche/Filterung ist auch möglich, z.B. wo (Vorname like ‘%tefa%' UND Nachname like ‘Syke%’) ODER Geburtsdatum zwischen ‘1990-06-03’ and ‘1990-06-05’. Dies kann über die Filter-Funktion von Hitobito gemacht werden. Deckt das diese Anforderung bereits ab? Liste_Generell_Export: Der User kann die Liste in der angezeigten Struktur nach Excel oder PDF exportieren. Dabei wird die exakte Liste, die dem User angezeigt wird, exportiert (d.h. wenn gefiltert, dürfen auch nur diese exportiert werden). Bereits Standard-Feature von Hitobito Liste_Generell_Individualisierung: Jede Liste ist individuell anpassbar, d.h. Spalten können ein-/ausgeblendet und dessen Reihenfolge bestimmt werden. Die individuelle Listenkonfiguration wird gespeichert, sodass dieselbe Struktur wieder angezeigt wird, wenn das System neu gestartet wird. Viele Felder können ein-/ausgeblendet werden und der letzte Zustand der gewählten Spalten wird auch gespeichert. Reihenfolge lässt sich heute nicht beinflussen. Liste_Generell_Sortierung: Die Werte in jeder Liste sind sortierbar. Für einige Felder ist eine Sortierung verfügbar, braucht es da mehr? |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “BÜ_2: Startseite individuell konfigurieren”
Use Case ID | BÜ_2 |
---|---|
Beschreibung | Startseite_Schnellzugriffe_Individualisierung: Der User kann auf der Startseite Schnellzugriffe / Shortcuts individuell einrichten. Diese dienen zur Listenanzeige (z.B. Kursanmeldungen, Neueintritte) oder zum Schnellaufruf einer Funktion (z.B. Kontakterfassung, Postabgleich, Wechsel Beitragskategorie). Hier gibt es standardmässig nicht in Hitobito. Die Idee ist das mein grundsätzlich aus dem Gruppen-Tree oder auf der Globalen Suche startet. Wie wichtig ist dieses Feature? Startseite_Suchfeld_GlobaleSuche: Der User kann auf der Startseite nach folgenden Kriterien suchen - eine Kombination von Suchkriterien ist möglich:
Das Ergebnis wird in Form einer Liste zurückgegeben. Die Globale Suche von Hitobito bietet hier schon viel, wir sehen hier mal kleinere Anpassungen vor (z.b. Suchen nach SAC spezifischen Feldern) Startseite_Kennzahlen_Board: In einem “Widget” in Form von Kacheln werden dem User abhängig von seiner Rolle die wichtigsten Zahlen angezeigt (z.B. Neueintritte & Austritte in den letzten 12 Monaten, Totalanzahl Mitglieder). |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “BÜ_3: Tool mehrfach aufrufen”
Use Case ID | BÜ_3 |
---|---|
Beschreibung | Tool mehrfach aufrufbar / Tab-Modus;Benutzerfreundlichkeit - um mehrere Sichten gleichzeitig offen zu haben z.B. 2 zeigen untersch. Listen an, 1 Fenster “Mitgliederkarte”, 1 Fenster exportiert gerade ein Monsterfile Keine Sperrungen - Jeder kann jederzeit arbeiten und niemand ist weder von einem System veranlassten oder von einem User ausgeführten Verarbeitung blockiert (z.B. bei einem Mahnlauf) Performance |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “BÜ_4: Rollen & Berechtigungen verwalten und zuweisen”
Use Case ID | BÜ_4 |
---|---|
Beschreibung | |
Akteure | |
Auslöser | |
Vorbedingungen | |
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “BÜ_5: User autorisieren und authentifizieren”
Use Case ID | BÜ_5 |
---|---|
Beschreibung | Aktuell benutzen folgende Applikationen zwecks Autorisierung und Authentifizierung den WSO2 Identity Server den WSO2 Identity Server:
Hitobito offeriert ebenfalls ein OpenID Authentifizierungsprotokoll. Es wird gewünscht, dass WSO2 damit ersetzt wird.Hitobito offeriert ebenfalls ein OpenID Authentifizierungsprotokoll. Es wird gewünscht, dass WSO2 damit ersetzt wird. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Use Case “BÜ_6: User imitieren”
Use Case ID | BÜ_6 |
---|---|
Beschreibung | Zwecks IT Support soll das Tool die Möglichkeit anbieten, einen User zu imitieren. |
Akteure |
|
Auslöser |
|
Vorbedingungen |
|
Standardablauf | |
Schnittstellen | |
Gap Analyse | |
Kostenschätzung |
|
Add Comment