BELEIDSINFORMATIESYSTEMEN
Frank Goethals
H1: Inleiding
1.1. THE IS LIFECYCLE (4 fases):
1. SYSTEM CONCEPTION
- Bepalen dat we een nieuw systeem willen
- Vastleggen wat we willen
- Line leadership: business mensen nemen
initiatief
2. DESIGN & PROGRAMMING & TESTING
- Opzetten systeem
- Testen systeem
- IS leadership: IT mensen
3. IMPLEMENTATION
- Systeem in productie brengen
- Change management: gedrag aanpassen en getraind worden om systeem te gebruiken
- Line leadership
4. OPERATIONAL (MAINTANCE)
- Verder gaan met het gebruik van het systeem
- Onderhouden systeem
- IS leadership
IT project success factors (30%):
1. Executive management support
- Management moet achter het project staan
2. User involvement
- Gebruiker moet betrokken worden in het proces/ resultaat
3. Clear objectives
- Moeilijk om duidelijke objectieven vast te leggen
- Je kan niet alles vastleggen vooraf
4. …
Keep it small and agile!
Verschil “waterfall” en “agile”
Waterfall Agile
1. Behoeften meedelen 1. Project opsplitsen in kleine projecten
2. Design (wordt vooraf beslist en 2. Elke 2/3/4 weken krijg je een nieuwere
verandert niet meer) versie van je IT systeem
3. Programmeren en testen Project design wordt duidelijk tijdens het
4. Implementatie (als het volledig klaar is) project.
Begin met weinig functionaliteit
Mening meedelen over de huidige versie na
iedere “sprint” (user involvement)
,H2: Enterprise architecture
Eerste belangrijke taak voor business mensen in IS projecten: benodigdheden definiëren
2.1. Weet je wel wat je doet/ wilt?
Data ophalen kan je doen door DATA MINING
Alles wordt vaak super complex en bijna onverstaanbaar.
Benodigdheden communiceren:
Expliciet maken -> mogelijke optimalisering
-> Maak en onderhoud verschillende modellen
2.2. Enterprise architecture
= “is the fundamental organization of a system embodied in its components (such as people, tasks…),
their relationships to each other, and to the environment, and the principles guiding its design and
evolution.” (IEEE)
IESEG en KULAK zijn beide educatieve instellingen zijn, maar…
- het process om tot een uurrooster te komen is volledig verschillend
- het ondersteunende IT system moet dus ook verschillen (Business-IT alignment: bv.:
vakdesign & prof beschikbaarheden)
Bepaalt: wie, wat, wanneer, waar, hoe, waarom
EA kan gezien worden als een onderdeel van ‘governance’ (i.e., controlling an organization)
=> kan in dat kader gebruikt worden om
1. een bestaande situatie (as-is) te beschrijven
2. de strategische richting van de onderneming weer te geven
3. de tactische planning te duiden: grenzen en mijlpalen vastleggen.
4. de operationele planning te kaderen: richting geven aan een portfolio van projecten
5. gap analysis te doen: waar zijn we en waar willen we naartoe?
6. partiële oplossingen te selecteren
7. de to-be situatie vast te leggen
SPEL:
Fase 1: Bouw een vehicle
Fase 2: Ik wou eigenlijk een boot, dus vorm het om naar een boot
Fase 3: Bouw een watervliegtuig
Conclusie:
- Round 1 to round 2
The same requirements can be understood differently. Requirements have to be accurate; it is
costly and a waste of time if they change.
, - Round 2 to round 3:
Requirements have to fit in the big picture; it is hard to fit small existing systems together if they
were not designed to fit together. You are constrained by old systems.
-> your task as a manager: think enterprise-wide; reveal requirements (immediately accurate and
important); importance of enterprise architecture
- Round 3 to round 4:
We need good documentation.
2.3. Zachman raamwerk
Welke informatie hebben we nodig? (H3)
Processen: hoe gaan we met informatie om (H5)
Classificatie van alle modellen die je kan bouwen
beschrijvend a.d.h.v. 6 vragen (je kan dit op
meerdere manieren bekijken):
1. What (data,…)
2. How (processen,…)
3. Where
4. Who (Wie gaat wat uitvoeren,…)
5. When
6. Why (Waarom doe je dingen in andere
kolommen op die manier = principes die
toelaten keuzes te maken in andere kolommen,…)
6 rijen:
1. Contextual: wat doet het bedrijf? Niet veel detail gevend.
2. Conceptual: meer detail toevoegen aan de gegeven data in fase contextual
3. Logical: waar gaan we alles opslaan?
4. …
Vraag: rij 1,2,3
Aanbod: rij 4,5
H3: Informatiemanagement
3.1. Doelstelling
Als je werkt in een ‘grote’ onderneming:
- In staat zijn je informatiebehoeften te communiceren aan het IT departement en
begrijpen welke data effectief opgeslagen zit in de Database.
- In staat zijn data om te vragen uit de database met beperkte tussenkomst van het IT
departement + correctheid van KPIs nagaan.
Als je werkt in een ‘kleine’ onderneming (of zelf een onderneming opricht):
- Zelf de tabellen in een database kunnen definiëren, en
- in staat zijn data op te vragen uit de database.
Data wordt in dergelijke zaken maar al te vaak verkeerd gestructureerd, waardoor de werking
belemmerd wordt.
Frank Goethals
H1: Inleiding
1.1. THE IS LIFECYCLE (4 fases):
1. SYSTEM CONCEPTION
- Bepalen dat we een nieuw systeem willen
- Vastleggen wat we willen
- Line leadership: business mensen nemen
initiatief
2. DESIGN & PROGRAMMING & TESTING
- Opzetten systeem
- Testen systeem
- IS leadership: IT mensen
3. IMPLEMENTATION
- Systeem in productie brengen
- Change management: gedrag aanpassen en getraind worden om systeem te gebruiken
- Line leadership
4. OPERATIONAL (MAINTANCE)
- Verder gaan met het gebruik van het systeem
- Onderhouden systeem
- IS leadership
IT project success factors (30%):
1. Executive management support
- Management moet achter het project staan
2. User involvement
- Gebruiker moet betrokken worden in het proces/ resultaat
3. Clear objectives
- Moeilijk om duidelijke objectieven vast te leggen
- Je kan niet alles vastleggen vooraf
4. …
Keep it small and agile!
Verschil “waterfall” en “agile”
Waterfall Agile
1. Behoeften meedelen 1. Project opsplitsen in kleine projecten
2. Design (wordt vooraf beslist en 2. Elke 2/3/4 weken krijg je een nieuwere
verandert niet meer) versie van je IT systeem
3. Programmeren en testen Project design wordt duidelijk tijdens het
4. Implementatie (als het volledig klaar is) project.
Begin met weinig functionaliteit
Mening meedelen over de huidige versie na
iedere “sprint” (user involvement)
,H2: Enterprise architecture
Eerste belangrijke taak voor business mensen in IS projecten: benodigdheden definiëren
2.1. Weet je wel wat je doet/ wilt?
Data ophalen kan je doen door DATA MINING
Alles wordt vaak super complex en bijna onverstaanbaar.
Benodigdheden communiceren:
Expliciet maken -> mogelijke optimalisering
-> Maak en onderhoud verschillende modellen
2.2. Enterprise architecture
= “is the fundamental organization of a system embodied in its components (such as people, tasks…),
their relationships to each other, and to the environment, and the principles guiding its design and
evolution.” (IEEE)
IESEG en KULAK zijn beide educatieve instellingen zijn, maar…
- het process om tot een uurrooster te komen is volledig verschillend
- het ondersteunende IT system moet dus ook verschillen (Business-IT alignment: bv.:
vakdesign & prof beschikbaarheden)
Bepaalt: wie, wat, wanneer, waar, hoe, waarom
EA kan gezien worden als een onderdeel van ‘governance’ (i.e., controlling an organization)
=> kan in dat kader gebruikt worden om
1. een bestaande situatie (as-is) te beschrijven
2. de strategische richting van de onderneming weer te geven
3. de tactische planning te duiden: grenzen en mijlpalen vastleggen.
4. de operationele planning te kaderen: richting geven aan een portfolio van projecten
5. gap analysis te doen: waar zijn we en waar willen we naartoe?
6. partiële oplossingen te selecteren
7. de to-be situatie vast te leggen
SPEL:
Fase 1: Bouw een vehicle
Fase 2: Ik wou eigenlijk een boot, dus vorm het om naar een boot
Fase 3: Bouw een watervliegtuig
Conclusie:
- Round 1 to round 2
The same requirements can be understood differently. Requirements have to be accurate; it is
costly and a waste of time if they change.
, - Round 2 to round 3:
Requirements have to fit in the big picture; it is hard to fit small existing systems together if they
were not designed to fit together. You are constrained by old systems.
-> your task as a manager: think enterprise-wide; reveal requirements (immediately accurate and
important); importance of enterprise architecture
- Round 3 to round 4:
We need good documentation.
2.3. Zachman raamwerk
Welke informatie hebben we nodig? (H3)
Processen: hoe gaan we met informatie om (H5)
Classificatie van alle modellen die je kan bouwen
beschrijvend a.d.h.v. 6 vragen (je kan dit op
meerdere manieren bekijken):
1. What (data,…)
2. How (processen,…)
3. Where
4. Who (Wie gaat wat uitvoeren,…)
5. When
6. Why (Waarom doe je dingen in andere
kolommen op die manier = principes die
toelaten keuzes te maken in andere kolommen,…)
6 rijen:
1. Contextual: wat doet het bedrijf? Niet veel detail gevend.
2. Conceptual: meer detail toevoegen aan de gegeven data in fase contextual
3. Logical: waar gaan we alles opslaan?
4. …
Vraag: rij 1,2,3
Aanbod: rij 4,5
H3: Informatiemanagement
3.1. Doelstelling
Als je werkt in een ‘grote’ onderneming:
- In staat zijn je informatiebehoeften te communiceren aan het IT departement en
begrijpen welke data effectief opgeslagen zit in de Database.
- In staat zijn data om te vragen uit de database met beperkte tussenkomst van het IT
departement + correctheid van KPIs nagaan.
Als je werkt in een ‘kleine’ onderneming (of zelf een onderneming opricht):
- Zelf de tabellen in een database kunnen definiëren, en
- in staat zijn data op te vragen uit de database.
Data wordt in dergelijke zaken maar al te vaak verkeerd gestructureerd, waardoor de werking
belemmerd wordt.
