Document bestandsbeheer
Bijlage 10: Notulen in beheername sessie
Santosh Mes woensdag 17 juni 2009
Bijlage 10: Notulen in beheername sessie
Datum: 25 mei 2009
Plaats: Vergaderzaal BG Goudsbloemvallei 12, CTAC
Aanwezigen: Hans Slaghuis, Muhammed Erol, Remy van de Kamp, Santosh Mes, Erik Westerlaken, Jos van der Sterren
Onderwerp: In beheername QlikView applicatie CTAC holding hours
Hans wil de aanwezigen eerst op de hoogte brengen van de voortgang met de huidige applicatie.
Hij geeft hiervoor een demo van de uren applicatie. Omdat Hans is ingelogd zien we alleen de uren van Professional Services. Er is eerst een uren applicatie gebouwd, dit is uitgebreid met de chargeability, de URVE en de URVI en als laatste is ook de completness er bij toegevoegd.
Hieraan kan worden afgelezen hoeveel uur er nog niet geboekt is. Dit laatste is een belangrijke issue binnen PS maar ook zeker op holding niveau. Hans geeft aan dat EIM vrij hoog scoort in de completeness.
Deze applicatie is de eerste applicatie die gebouwd is. Hier hebben op dit moment 50 mensen toegang tot. 25 mensen hebben er daadwerkelijk ook gebruik van gemaakt. De applicatie is vrijdag 15 mei uitgerold binnen CTAC. Morgen is er ook een inloopsessie over het gebruik waarbij de gebruikers van QlikView kunnen komen met vragen en opmerkingen over QlikView.
Na deze applicatie is men van plan een applicatie voor SalesSupport te ontwikkelen. In deze applicatie, wordt projectdata gekoppeld aan order data en sales orders. Dit geeft projectleiders inzicht in de bestede projecturen en zal uiteindelijk gaan dienen om het proeffacturatie proces te vervangen.
Elke applicatie wordt gebouwd rond een bepaalde functie. Dit omdat het er geen andere doorsnede gemaakt kan worden binnen de gegevens binnen 1 applicatie. Het is wel de bedoeling om gegevens die meerdere malen gebruikt wordt, maar één keer te laden. Hier ligt meteen wel een belangrijk beheeraspect. Want het kan voorkomen dat gegevens zowel in een applicatie die in beheer is genomen wordt gebruikt als in een applicatie die in ontwikkeling is. Hier moeten duidelijke afspraken over gemaakt worden op het moment dat er aanpassingen plaats vinden.
Op hoog niveau zal een data model gemaakt en beheerd moet worden. Dit model gaat boven beheer en ontwikkeling. QlikView heeft hier zelf geen tools voor, hiervoor moet dus worden nagedacht worden hoe dit opgebouwd en beheerd worden.
Deze week start Muhammed ook met een finance applicatie, hier zal samen met Hanneke bekeken worden welke overzichten er gemaakt moeten worden. Het is de bedoeling van deze applicatie om bestaande rapporten te vervangen. De bedoeling van QlikView is dat gebruikers meer zelf kunnen veranderen aan de rapporten.
In de huidige applicatie heeft Wim Donckers laten zien dat dit werkt. Dit is wel een uitdaging voor het beheer. De gebruikers hebben veel vrijheden maar het mag geen jan boel worden van applicaties en definities. Echter is het ook niet wenselijk om vaste selecties voor te definiëren.
Hier haal je de kracht van QlikView mee weg.
Er zijn 2 belangrijke issues voor het beheer. Dit zijn de volgende issues: a. Het faciliteren van het beheer tussen de gebruikersorganisatie en de beheerorganisatie en b. hoe houden we het algemene QlikView model intact met verschillende stakeholders. (ontwikkelaars, IT beheerders, professionele gebruikers en analyzers)
Bijlage 10:Notulen in beheername sessie XCVIII
Santosh Mes woensdag 17 juni 2009
Een belangrijke vraag is ook hoe ga je om met een applicatie die in productie is maar ook nog een stuk aan ontwikkeld wordt? Hier is een mappenstructuur voor ontwikkeld die voor gedefinieerd is. De bron van de gegens is op dit moment productie gegevens, maar het is meer wenselijk om hier de QaS voor te gebruiken. Het belangrijkste hierbij is de perfomance voor de productie omgeving. Op dit moment wordt productie gebruikt, dit is makkelijker met testen. Bij de eerste opzet en echte ontwikkelingen wordt nog de QaS gebruikt. Hierbij moet de klant zorgen voor goede toepasbare testdata. En pas in de testfase moet er gebruikt gemaakt worden van productiedata.
Een vraag is ook of de bestaande rapporten van BW blijven bestaan of wordt alles overgezet naar QlikView? Voor de sales support applicatie is het de bedoeling dat alles overgezet gaat worden naar QlikView en het gebruik anders gaat worden. Op dit moment is het een hele klus om de huidge rapporten te maken en straks moet alles in 1x klaar gezet worden. Op deze manier verloopt het proces sneller.
Ook Managed Services staat op het programma voor QlikView, echter heeft Jan-Willem dit op de lange baan geschoven, ook bij het middenkader bij Managed Services is de behoefte er ook nog niet.
Belangrijk is het overdagen van de kennis. Deze kennis moet scherp gehouden worden en dat hier wat mee wordt gedaan. De bedoeling van vandaag is kijken wat er nodig is voor de in beheername en hierbij speelt de documentatie een grote rol. Ook voor de genoemde 2 punten, het faciliteren van de gebruikersorganisatie en het behouden van één algemeen model moet er samen gekeken worden en besproken worden hoe dit opgepakt gaat worden en gaat werken.
Een vraag is ook of de licenties geregeld worden, op dit moment kunnen de mensen van beheer nog niet in de applicatie omdat de licenties nog niet aanwezig zijn. Hans geeft aan dat dit deze week wordt opgelost.
De vraag is ook waarom BW rapporten weg gaan en is in de toekomst BW nog wel nodig? En als dit wel nodig is, gaat het geen spaghetti opleveren van systemen wanneer er naast BW ook gebruik gemaakt gaat worden van andere systemen c.q. bestanden. Jos is voorstander van 1 model waarbij duidelijk wordt aangegeven welke systemen wordt gebruikt.
Op dit moment wordt uit praktisch oogpunt meerdere bronnen ingezet. In BW zit al veel logica en dit is erg uitgebreid. Als je BW uit gaat zetten gooi je heel veel weg wat wel nagebouwd moet worden in QlikView. Het is nu om een goede balans te vinden tussen de flexibiliteit die QlikView bied en een goed model wat onderhoudbaar is. Dit is afhankelijk van de programmeur ook.
Bij de documentatie moet nog een flowchart worden opgenomen met meer details over de bronsystemen. Ook is het handig om algemene beschrijvingen en organisatie stukken in een algemeen document te beschrijven. Per applicatie wordt er documentatie gemaakt met technische gedetaileerde gegevens. Hier moeten ook uitzonderingen instaan op extractie, bijvoorbeeld JOINS en andere expressies die tijdens het laden gebeuren. Deze afspraken moeten ook gedocumenteerd worden.
Ook moet er een stuk interfacing worden beschreven over de jobs en hoe deze zijn ingepland.
Bij de procesbeschrijvingen is het niet geheel duidelijk wat precies een proces is. Hans geeft aan dat in de volgende applicatie procesbeschrijvingen veel meer belangrijk zijn omdat QlikView hier deel uit maakt van het proces, bij de huidige applicatie is dit niet het geval. Daarom wordt er voor gekozen voor deze applicatie slechts een globaal stuk over op te nemen over hoe de applicatie wordt gebruikt en bij volg applicaties wel processchema’s op te nemen en aan te geven waar QlikView ingezet wordt.
Er moet nog een procedure worden ontwikkeld voor professional gebruikers waarbij wijzigingen door gevoerd worden in productie.
Bijlage 10:Notulen in beheername sessie XCIX
Santosh Mes woensdag 17 juni 2009
Actielijst
Nieuwe structuur document maken waarbij algemene zaken apart opgenomen worden in een document en gedetailleerde info in een apart document gemaakt wordt (Santosh)
o Algemeen document:
Beschrijving organisatie (schema’s waar QV wordt gebruikt)
Interfacing met SAP, volgorde load jobs e.d.
o Gedetailleerd document:
Gedetailleerde informatie over de bronsystemen, opnemen met schema’s en uitleg tabellen, kubussen, ODS enz.
Proces informatie, kleine inleiding waar voor applicatie is bedoeld
Autorisatie op 2 manieren, wie mag welke gegevens zien? En wie is prof, dev en analyzer?
Uitgebreide load statements los gedocumenteerd. Ook afspraken en regels met laden documenteren.
Documentatie aanpassen aan nieuwe structuur documentatie (Remy en Muhammed)
Procedures maken voor het verwerken van wijzigingen van professional gebruikers
Algemeen data model opstellen.
Afspraken maken over bewaken data model.
10 juni bijeenkomst in beheername QlikView.
Datum: 10 juni 2009
Plaats: Vergaderzaal PS CTAC
Aanwezigen: Leon Verbeek, Erik Westerlaken, Jos van der Sterren, Muhammed Erol, Stefan Koppejan, Remy van de Kamp, Santosh Mes
Onderwerp: Documentatie QlikView CTAC project
Ten eerste wil Leon wat algemene beheerstandpunten mee delen. Beheer wil de documentatie beoordelen op het moment dat iets in beheer genomen wordt. Dit gebeurt bij verschillende klanten. Er loopt op dit moment een project om de in beheer name te structureren. Hierbij wordt ook gekeken dat documentatie niet alleen op het laatste moment gemaakt wordt, maar al in het begin van een project mee gestart wordt.
Documentatie is in eerste plaats bedoeld om veranderingen goed te kunnen managen. Op het moment dat een verandering nodig is moet men terug naar de basis en kijken hoe deze in elkaar zit en moet men kunnen afleiden uit de documentatie wat er veranderd moet worden en waar rekening mee gehouden moet worden. Om dit goed te kunnen doen zijn er richtlijnen opgesteld, deze zijn met name opgesteld voor R/3 ECC installaties. Santosh is bezig geweest om naar deze richtlijnen te kijken met QlikView bril op.
In R/3 ECC installaties is er altijd een blauwdruk gemaakt met maatwerk en customizing en een functioneel ontwerp heeft een link naar de blauwdruk. Met QlikView is dit anders, hier is geen sprake van cumstomizing of maatwerk, echter zijn er ook wel veel aspecten die wel spelen. Een beschrijving van de KPI’s, extractie en onderliggende procesbeschrijvingen is wel degelijk aanwezig. verantwoordelijk uit de business voor de KPI’s.
Bijlage 10:Notulen in beheername sessie C
Santosh Mes woensdag 17 juni 2009
Muhammed start met de demo van de applicatie.
Eerst wordt er via de remote desktop verbinding gemaakt op de server (172.21.12.24) met gebruiker Admin003 en als wachtwoord 300nimda. Leon en Jos geven aan dat dit soort informatie ook gedocumenteerd wordt en dat dit nog mist op het moment. Hiervoor moet een algemeen document gemaakt worden voor alle QlikView applicaties van CTAC en moet o.a.
praktische informatie in komen zoals het inloggen in het systeem.
Op dit moment is er nog 1 server, er wordt nagedacht om een tweede server aan te schaffen waardoor er dus een landschap ontstaat waarbij er een productie en ontwikkel omgeving is die fysiek gescheiden is. Nu vind de productie en ontwikkeling nog plaats op de zelfde server.
De mappen structuur van de applicatie staat op de D: schijf van de server. Binnen deze mappen zijn de volgende mappen opgenomen:
Backup, hier wordt een kopie gemaakt van de applicatie alvorens er ontwikkelt gaat worden
Data, hier staan alle data bestanden (QVD) ingedeeld per bron (ECC/BW/Excel)
Dev, hier worden de ontwikkel applicaties geplaatst tijdens het ontwikkelen
General, hier staan installatie bestanden van QlikView
Images, hier staan plaatjes die gebruikt worden tijdens de ontwikkeling van QlikView applicaties
Prod, hier staan de applicaties die “live” zijn
QVPortal, hier staan de bestanden die gebruikt worden in de QlikView portal
Het is verstandig om deze structuur op te nemen in het algemene document. Deze structuur wordt voor alle applicaties aangehouden. Binnen de DEV map krijgt elk project waar aangewerkt wordt weer een aparte map.
Op dit moment is er nog een procedure voor versienummering. Een versie 1.0 is een versie die
“live” is. 1.1 en verder zijn weer ontwikkel versies, op het moment dat een ontwikkeling “klaar”
is wordt de versie 2.0. Dit is gedaan om de link in QlikView Publisher te onderhouden, deze linkt direct naar het bestand namelijk en met steeds nieuwe versienummers moet elke keer deze link aangepast worden.
Voor het bijhouden van changes is wel een protocol opgesteld. Dit gebeurt in de applicatie zelf middels commentaar.
Er zijn 2 applicaties, Holding Hours en Holding Hours Extractie. De eerste is de front-end van de applicatie en bevat dus de rapporten en grafieken die getoond worden aan de gebruikers en de andere bevat het extractie script om de data op te halen. Dit extractie script prikt in op verschillende bronnen (R/3 ECC, BW, Excel) en schrijft de data weg naar QVD bestanden. Dit is gedaan om sneller te kunnen laden in de front-end en dat de data gecomprimeerd wordt. Deze data wordt dan door geladen naar de front-end.
Voor nieuwe applicaties kan er gekozen worden om de extractie opnieuw plaats te laten vinden of (gedeeltelijk) gebruik te maken van de bestaande QVD bestanden. Om dat veel data hetzelfde is wordt hier gebruik van gemaakt. De relaties worden gemaakt in de extractie laag dus in een andere applicatie zijn alle relaties al zichtbaar. In het algemene document moet de link tussen de applicaties en extractie worden aangegeven. Dit is op dit moment wel opgenomen in een document wat gebruikt wordt door de ontwikkelaars zelf.
De afspraken die gemaakt zijn over de changelog en commentaren enz. zijn heel erg belangrijk voor de beheerorganisatie. Op het moment dat deze afspraken bekend zijn, kunnen zij ook volgens deze afspraken werken.
Bijlage 10:Notulen in beheername sessie CI
Santosh Mes woensdag 17 juni 2009
De extractie vindt plaats met de QlikView Publisher. Hiervoor zijn twee taken ingeregeld. Dit is de taak om de extractie vanuit de bronsystemen te regelen en hiernaast om data door te laden naar de front-end. Ook is er een taak aangemaakt voor het klaarzetten van de front-end in de portal.
Afspraken die gemaakt zijn over de naamgeving van data en applicatie bestanden zijn nu nog niet opgenomen, dit moet opgenomen worden in het algemene document. Naamgeving van een QVD bestaand aanpassen betekend dat het hele script nagelopen en aangepast moet worden.
Binnen de mappenstructuur in de map data is ook een onderverdeling gemaakt. Hier wordt per bronsysteem een map aangemaakt met daarin de QVD bestanden. Ook is er een map met sources waarin Excel bestanden staan met additionele gegevens die niet uit de bron te herleiden is. Deze bestanden zijn een “quick en dirty” oplossing voor een probleem wat niet in SAP BW staat. Op het moment dat de gegevens veranderen (zoals een organisatieverandering) moet dit lijstje aangepast worden. Hiervoor moet de checklist aangepast worden die er nu is bij het aanmaken of veranderen van een company code. Dit soort uitzonderingen moeten heel goed gedocumenteerd worden en in de toekomst moet dit netjes in SAP BW afgehandeld worden.
De QVD bestanden hoeven niet 1 op 1 gelijk te zijn met de bronsystmen, hier zit al logica in om tabellen en velden aan elkaar te koppelen.
Het script is ingedeeld in verschillende tabs. De tab algemeen bevat informatie die door QlikView zelf bedacht is. Dit is onder andere een Created datum, purpose, guidelines. De purpose moet nog aangepast worden omdat hier nog een genierek verhaal staat wat door QlikView is opgesteld. Er is nog geen duidelijke afspraak gemaakt of commentaar in het engels of Nederlands opgenomen moet worden. Erik wil dit punt parkeren omdat hier over het algemeen nog geen regels voor zijn binnen beheer.
Wat nog wel gemist wordt is gegevens over de connectie, hoe deze gemaakt wordt, welke gebruiker met pass, mandant, systeem e.d. De gebruikersnaam en wachtwoord worden geencrypt zodat niet iedereen die het script kan zien ook de SAP gebruiker kan zien.
De inline tabllen moeten ook gedocumenteerd worden. Ook moet rekening gehouden worden met de laadvolgorde van het script. Dit begint met de linkse tab en eindigt met de rechtse. De naamgeving van de tabel “approved hours” moet veranderen omdat hier meer type uren in staan dan alleen de approved. Dit is juist een samgengevoegde tabel.
De ziekte uren staan op dit moment niet in SAP BW dus worden opgehaald uit R/3 ECC.
Hiernaast zijn er aparte tabs gemaakt voor de masterdata en voor de data die uit Excel gehaald worden. In de scripts van de front-end worden alleen de QVD bestanden ingeladen, voor de rest gebeurt er niets met de data. Wel wordt er commentaar opgenomen voor het inlezen van de QVD bestanden.
Er moeten afspraken vast gelegd worden waar de logica opgeslagen moet worden, dit kan zowel in de front-end als de back-end. Ook de definitie van de kleuren van de barometers moeten vastgelegd worden. Op het moment dat de professional gebruiker een nieuw ontwerp heeft moet dit wel goedgekeurd worden door ontwikkelaars en/of beheer. Hier ligt organisatorisch nog wel een uitdaging, maar dit is niet alleen bij QlikView maar ook bij BusinessObjects of andere BI pakketten.
Voor het lezen van de autorisatie is een hidden script opgenomen. Dit moet ook in de documentatie vermeld worden. De gebruikers kunnen niet bij de Excel bestand waar de security in geregeld wordt. Het is verstandig voor nieuwe applicaties gebruik te maken van de zelfde Excel lijst. In de grafieken zit ook nog een vorm van expressie. Ook hier moet commentaar opgenomen worden. Op de QlikView server is ook een management console geïnstalleerd. Het beheer hiervan ligt bij HTS/NetIT. De keuzes die gemaakt zijn tijdens en na de installatie bij de console moeten wel vastgelegd worden. En belangrijk is ook de argumentatie van de keuze voor de instellingen. Het gaat dan hier over poortinstellingen e.d.