Integration
Att integrera Ert schema med Ert studieadministrativa system
Integration med ett obekant externt system är den enskilt vanligaste orsaken till att en schemaläggningsimplementering blir försenad. Det är också den mest undvikbara, om den avgränsas ärligt från början.
Det kanske redan finns en sida för ert system
Den här artikeln är det allmänna resonemanget — vem som äger vad, i vilken riktning data färdas och vilken mekanism som ska användas. Om ni redan vet namnet på systemet ni integrerar med, börja med dess egen sida och kom tillbaka hit för resonemanget: SITS, Banner, Workday Student, PeopleSoft, Ellucian Colleague, Callista och UNIT-e.
Bestäm vilket system som äger vad
Nästan varje integrationsproblem är egentligen ett ägarskapsproblem.
Innan något tekniskt arbete görs bör ni komma överens om vilket system som är auktoritativt för varje sorts data. Vanligtvis äger det studieadministrativa systemet program, kurser och anmälningar; personalavdelningen äger personaluppgifter; fastighetsavdelningen äger salsinventariet; och schemaläggningssystemet äger själva schemat och villkoren bakom det.
Där två system båda tror sig äga något kommer de att glida isär, och avstämningsarbetet landar hos den som klagar minst. Att skriva ned ägarskapskartan innan integrationen börjar är tjugo minuter som sparar månader.
I vilken riktning data flödar
- Inkommande till schemat: program- och kursstruktur, anmälningar och gruppstorlekar, personaluppgifter och institutioner, salsinventarium och kapaciteter.
- Utgående från schemat: själva schemat, till er portal, lärplattform, mobilapp, digital skyltning och kalenderflöden.
- Ibland dubbelriktat: salsbokningar, där ett fastighetssystem och schemat båda skapar reservationer. Detta är det svåraste fallet och värt att undvika om ni kan.
Filer, API:er eller schemalagd synkronisering
Filbaserat utbyte — export och import av Excel, CSV eller XML — är den mest allmänt stödda vägen och fullt tillräckligt där data ändras några gånger per termin. Det brister där aktualitet spelar roll, eftersom schemat bara är så färskt som den senaste export någon kom ihåg att köra.
Ett dokumenterat REST API möjliggör schemalagd synkronisering, så att ändringar sprids utan mänsklig inblandning, och låter era egna system läsa schemadata i realtid i stället för att visa gårdagens kopia.
Direkt databasintegration är snabbast och skörast, och bör bara övervägas där båda systemen ligger under er kontroll och lärosätets policy tillåter det.
Att avgränsa det ärligt
Ställ två frågor till varje tänkbar leverantör: har ni kopplat upp mot just det här systemet tidigare, och hur ser arbetet ut om ni inte har det? En leverantör som svarar vagt på den andra frågan säger något till er.
Ta sedan internt reda på om ert studieadministrativa system faktiskt exponerar ett användbart API eller bara en rapportexport. Svaret är ofta inte det som leverantören av det systemet påstår, och det är mycket bättre att upptäcka under utvärderingen än i månad tre.
Enkel inloggning (SSO) är värd att lösa samtidigt. Shibboleth och jämförbara federerade identitetssystem är vitt spridda inom högre utbildning, och att använda ert eget tar bort en hel klass av administration av inloggningsuppgifter.
Vill ni se hur det fungerar?
Boka en onlinepresentation på 45 minuter, så går vi igenom den mot ert eget lärosätes schemaläggningsproblem.