Markt van Leveranciers 17 november

BVE Platform

Het BVE Platform organiseert weer een markt van leveranciers en ik neem het berichtje even letterlijk over:

De volgende Markt van Leveranciers die het BVE-Platform organiseert staat gepland op 17 november 2009. Uiteraard doen we ook dit onder de vlag van SAMBO~ICT. Het is de bedoeling om de verschillende markten dit jaar te combineren, dus niet te kiezen voor alleen kernregistratie of presentieregistratie, maar breder: kernregistratie, onderwijslogistiek, begeleiding en presentieregistratie.
De plannen hiervoor zijn nog niet geheel uitgekristalliseerd. We melden u de datum vast, zodat u de dag in uw agenda kunt reserveren. – BVE-Bericht juli 2009

Onderwijscalculator handleiding

Ik heb me de laatste tijd meer verdiept in de Onderwijscalculator. (Gebouwd door Wisdom, verconsulteert door Artefaction en als opdrachtgever MBO2010)

Tijdens het leren omgaan met het systeem, kreeg ik de behoefte het op te schrijven en bij deze, om het te delen. De handleiding is wel geschreven met functioneel beheerders (in de calculator de rol “Schoolbeheerder”) in het achterhoofd, maar met een beetje aanpassing is het voor anderen waarschijnlijk ook bruikbaar. Er was natuurlijk al een handleiding op de site zelf, maar nog eentje kan geen kwaad ;).

Hier het document in DOC en voor de zekerkheid om opmaak te behouden, in PDF.

CVI Conferentie: De leefwereld van de leerling

CVI WEb Conferentei 2010

Vanochtend via de post binnen gekomen, dus direct gekeken. Prik de datum alvast maar in je agenda voor 14 en 15 april 2010, in Veldhoven. Thema voor de CVI Conferentie is “De leefwereld van de leerling”. De conferentie-blog is hier te vinden, maar nu op moment van schrijven, nog niet in de lucht.

Ik wens Wilfred Rubens veel succes met het voorzitterschap van de programmacommissie!

Tag voorstel: #cvi10

Tweedehands informatie

Eenmaal aan het denken over risico’s bedacht ik er nog eentje.

In mijn idee is er sprake van tweedehands informatie als de registratie van informatie op een andere plek en tijd plaatsvindt dan het ontstaan ervan. Bijvoorbeeld vanwege onderstaande scenario:

Uit een bepaalde onderwijsactiviteit volgt de noodzaak om informatie vast te leggen. Aangezien de applicatie op die werkplek niet voorhanden is, wordt deze op papier “analoog” vastgelegd. Er wordt nu verwacht dat op een ander moment deze papieren informatie overgebracht wordt in een registratiesysteem. Indien dit door medewerkers uit het primaire proces moet worden gedaan, dan leidt dit tot weerstand vanwege het “administratieve karakter” en de werkdruk van “het erbij doen”, naast de “gewone” werkzaamheden. Liever koopt men dan een ondersteunende dienst in die dit uitvoert (administratieve krachten).

In de praktijk leidt dit tot :

  • Incomplete of foute informatie. O.a. vanwege niet inleveren of kwijtraken van de papieren informatie en fouten bij het overnemen.
  • Een verplaatsing van de administratieve last, niet een vermindering en dus geen efficiency voordelen. Èn papieren èn digitale administratie kost nu eenmaal meer tijd dan alleen een digitale.

Daarnaast vergt het vastleggen van handelingsafspraken, verslagen van coachgesprekken en items voor het begeleidingsdossier een denkproces. Één en ander moet onder woorden worden gebracht. Voor veel collega’s is dit denkproces en tekstschrijven makkelijker uit te voeren met pen en papier, i.p.v. met scherm en toetsenbord.

Mogelijke oplossingen (uit het makkelijker- gezegd- dan- gedaan-rijtje):

  • De applicatie naar de werkplek brengen op een dusdanige manier dat deze “alomtegenwoordig” is. Deze werkplek is, bij toegenomen flexibel onderwijs in het kader van CGO, niet altijd een docentenwerkruimte of werkplek in een klaslokaal.
  • In de keuze van het systeem het bedieningsgemak, voor mensen zonder administratieve achtergrond, zwaar laten wegen.

Informatie-estafette

Estafette

Ik was bezig om procesrisico’s in kaart te brengen voor een applicatie die zowel functionaliteit kent voor administratieve processen als voor onderwijsprocessen. Één van de risico’s noem ik de “Gebroken-Informatie-Estafette”. Het gaat ongeveer zo:

Een proces staat vrijwel nooit op zichzelf maar dient meestal als input voor het volgende proces. Een aantal operationele processen kent zijn startpunt in het primair proces, vindt zijn weg in ondersteunende  diensten en eindigt daar. Of doorkruist meerdere “afdelingen” en komt weer terug in het primaire proces. Bij elke stap in het proces wordt informatie toegevoegd aan de ontvangen informatie. Vervolgens wordt deze weer doorgegeven.
Het lijkt logisch om voor een proces een proces-eigenaar aan te wijzen. Dit i.v.m. verantwoordelijkheid en sturing. Voor deelprocessen werkt dat, maar voor processen die over meerdere entiteiten of afdelingen lopen is dit moeilijker.

Voorbeelden hiervan zijn de aansluiting van de volgende onderwijslogistieke deel-processen:

  • “Aanmelding” >  “Inschrijving” > “Intake” > “Plaatsing” > “Planning van onderwijsaanbod”
  • “Toetsing” > “Examinering” > “Diplomering” > “Uitschrijving” > “Melden”
  • “Zorgbegeleiding” > “Trajectbegeleiding” > “Uitschrijving” > “Melden”

Het stokje van informatie, die in deze estafette van deelprocessen doorgegeven  moet worden, valt soms aan de kant, wordt terug- of verdergegooid…

Mogelijke tegenmaatregelen:

  • Actoren uit de deelprocessen in hetzelfde systeem laten werken. Zodat de doorgave van informatie niet afhankelijk is van flankerende administratie en eigen “lijstjes”.
  • In de keuze van het systeem, de mogelijke ondersteuning van “Workflow” zwaar laten wegen. Hiermee wordt het mogelijk op basis van de uitkomst van het ene deelproces acties uit te zetten voor actoren uit een ander deelproces.

Weet iemand nog andere mogelijke tegenmaatregelen?

Een verzoek om functionaliteit is een verzoek om informatie

Dit ligt het meest voor de hand met database gebaseerde applicaties. Maar generieker klopt het ook. Het viel me op aan hoe de vraag gesteld wordt, vòòr articulatie dan.

Een willekeurig persoon vraagt: “Ik wil gewoon in pakket X … kunnen”. Waarbij … de gewenste functionaliteit voorstelt.

Een andere willekeurig persoon vraagt: “Ik wil gewoon weten hoeveel … “. Waarbij … de gewenste informatie voorstelt.

Als iemand zegt, dat hij in Paint een foto zo willen kunnen spiegelen, wat natuurlijk kan, dan is dat een verzoek om functionaliteit. Tegelijk is het een verzoek om informatie: geef me de kleurwaardes op coördinaat x,y en wissel vervolgens de waarde van x en y om. In dit voorbeeld een beetje gechargeerd, maar het geldt nog meer voor informatie opgesloten in administratieve systemen en sociale sites.

Dit is voor mij de reden dat het logisch is om in een organisatie Functioneel Beheer onder Informatiemangement te plaatsen. Naast alle redenen die frameworks als ITIL en BiSL bepleiten.

Overigens is er nog iets tricky aan bovenstaande vragen: Ze beginnen allemaal met “gewoon”. De vraagsteller kan dit zo noemen om allerlei redenen. Hij/zij vindt zijn vraag een logisch verzoek of een makkelijk verzoek.

Na articulatie blijkt vaak dat zijn vraag niet logisch is, als het probleem dat het moet oplossen er niet mee opgelost kan worden. Of je krijgt inzicht (van data naar kennis) in iets, maar je kunt het niet gebruiken voor je eigen probleem. Of het lijkt makkelijk, maar het blijkt eisen te stellen aan het registratieproces van de data.

Doet me denken aan de Office-functionaliteit: “Waarom is Office zo groot? Ik gebruik maar 20% van de functionaliteit.” Klopt! Maar ieder individu gebruikt een verschillende 20%…

Zo is het met informatiebehoefte ook. Een nieuw element binnen de informatievoorziening zal altijd maar voor een beperkte groep zinvol zijn. Een “gewone” vraag voor de een is een “exotische” vraag voor de ander.

Is dit te tackelen? Jazeker, veel BI wordt opgehangen aan Balanced Score Carding. Zodat je elementen uit de bestuurlijke agenda (wat willen we?), koppelt aan succesfactoren (welke succesen dragen bij aan onze doelen?) en prestatie-indicatoren (waaraan zie je dat je succes hebt?). Deze laatsten zouden kunnen worden opgelevert vanuit de systemen.

Vooralsnog kanaliseer je hier informatiebehoefte mee op strategisch/tactisch niveau. Op operationeel niveau zou het ook mogelijk moeten zijn om informatiebehoeften te hangen aan bovenstaande hiërarchie. Echter: strategisch en operationeel niveau zijn nog al eens 2 compleet verschillende werelden…

SMS via je ELO

Ik kreeg vandaag een telefoontje van een SMS leverancier. Of we interesse hebben in SMS-en vanuit de ELO. In het verleden hebben we dit alles bekeken om zo mededelingen of nieuwe cijfers te sms-en. Maar ik vind het niks (meer). Soms merk je dat de werkelijkheid alles inhaalt.

Mijn eerste reactie was: “boven de 10 cent per sms is praten we niet eens”. Toen bleek het 11 cent te zijn….
Ik heb de beleving dat Telecom carriers zelf 3 cent per sms kwijt zijn…
Maar afgezien van geld, we zijn er al eerder mee bezig geweest:

  • Er zijn verschillende sms building blocks die opzich niets kosten, je betaalt alleen per sms.
  • We hebben rond de tafel gezeten met een beginnend bedrijfje, die zelf afhaakten omdat “sms toch gaat verdwijnen en mobiel internet steeds meer toeneemt”.
  • We zijn al een tijd op zoek naar een mogelijkheid om dagroostering goed te communiceren. In onze leerfabrieken is het niet meer te doen om met papier rond te rennen en deze op te hangen op 4 plekken in elk gebouw.
    Maar: geen communicatie==>geen dagroostering==>geen goede aanwezigheidsregistratie==>veel $%^@# met accountant.

Mijn 2 kwartjes:
Als er vanuit het onderwijsproces behoefte bestaat om laagdrempelig, anytime, anywhere, mobiel berichten door te geven, dan zouden we de mogelijkheid kunnen onderzoeken, maar ik vind het een echte 2005 oplossing. Had toen leuk geweest, maar geef het nog een jaar en de mobiele breedband beschikbaarheid onder studenten is nog hoger. Of ben ik te optimistisch?
Of liever gezegd: mededelingen van 140 karakters zullen wel blijven bestaan, maar dan via http ipv sms.

Daarnaast: stel dat 100 courses in onze Blackboard omgeving 1 sms per week genereren, gedurende een jaar van 38 weken, aan 1000 studenten. Dan levert dat 100x38x1000=3.800.000 sms-jes op, of grofweg 400.000 euro.
Dat zou dan zijn als er 1 mededeling ge-sms’t wordt. Dan hebben we het nog niet eens over het sms-en van gradebook cijfers. Dan loopt je aantal in de miljoen sms of 100 kilo-euro per maand. Zijn er instellingen die dat betalen?

Google Fusion Tables

fusiontables_logo

Deze keer geen uitgebreid vergelijkend functionaliteitsonderzoek, maar korte eerste impressie van deze nieuwe dienst uit de Labs stal. Alpha versie nog. Samengevat: je kunt hele grote platte tabellen inlezen en hierop filteren en aggregeren. De uitkomst hiervan kan vervolgens als tabel of allerlei grafieken getoond worden. Gedeeltelijk lijkt het dan op een draaitabel maken in Excel.

Het openingsscherm heeft wel iets weg van Google Docs en toont direct het voordeel van tabelletjes in de cloud: delen met anderen.

googlefusiontablesscreen

Een ander voordeel toont het import scherm, van bijvoorbeeld een excel-bestand. Het mag tot 100 MB, oftwel groot dus (Je moet flink wat operationele info hebben wil je met platte tabellen zover komen).

De overeenkomst met Google Spreadsheets roept gelijk de vraag op: waarom iets aparts met tabellen? Daarom enkele verschillen:

  • Het creëren van “Views”: wat er van de tabel getoond wordt kun je instellen door kolommen aan/uit te zetten.
  • Elke kolom kan gefilterd worden op alle waardes van de kolommen.
  • Aggregeren: je kunt instellen wat je geaggregeerd wilt hebben en waarmee. Bijvoorbeeld:

Ik heb een spreadsheet gebruikt met prognoses ILT tellingen per school, team, leerweg en niveau. Ook levert dit naar studententarief geplande formatie op. De info zelf laat ik even weg ;), maar hieronder zie je het aggregatie scherm:

googlefusionaggregate

De termen die vermeld zijn, zijn de kolomtitels. Van elke kolom kan een aggregatie gemaakt, met de waarde van elke andere kolom. Hierboven is dat: Per entiteit (school) en team de som van het aantal leerlingen van de prognose. Er wordt dus geaggregeerd op alle “onderliggende getallen”. De tabel vermeld namelijk het aantal per leerweg en niveau. Deze worden ‘opgeraapt’ en per team getoond.

Conclusie: voor Alpha versie niet slecht, uiteindelijk zou deze functionaliteit van mij “gewoon” onderdeel mogen zijn van Google Spreadsheets.

Invoering Participatie module bij AOC Friesland

Op de gebruikersdag EduArte werd door Gerus Cornelissen (AOC Friesland) kort geschetst hoe bij hen de invoering van het aan/afwezigheidregistratiesysteem verloopt. Enkele impressies:

  • Ze hebben voor elke locatie  een week de tijd genomen om te testen. Mijn indruk van de ervaringen is dat je dan niet alleen het systeem test, maar ook de organisatie die het gebruikt … en dat is zeker zo belangrijk.
  • De administratieve last wordt wisselend belegd: in sommige lokalen bevinden zich pc’s en voert de docent zelf in, elders worden briefjes verzameld en door één persoon verwerkt. 
  • De koppeling naar het rooster is een handmatige: csv bestanden uit Untis worden geïmporteerd in EduArte. Dit wordt door roosteraars zo vaak als nodig is gedaan en wordt niet als lastig ervaren.
  • Niet alleen de planning, maar ook de realisatie van het rooster komt in EduArte terecht, doordat na roosterwijzigingen (ook achteraf) de import opnieuw wordt uitgevoerd.
  • De ‘waardering’ van afwezigheid hangt sterk af van de specifieke schoolafspraken. Een instelling moet dus wel helder definiëren wat men verstaat onder ‘ongeoorloofd’ etc.