• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Informatiemanagement
Informatiemanagement
Lean software development volgens Claudio Perrone
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

software development claudio perrone

In zijn presentatie Lean & Agile op slideshare.net deelt Claudio Perrone (@agilesensei) zijn inzichten op het gebied van het combineren van Lean en Agile met softwareontwikkeling.

Volgens Claudio Perrone zijn zeven principes van Lean thinking die cruciaal zijn voor het ontwikkelen van software:

  1. Elimineren van verspilling (waste)

  2. Inbouwen van kwaliteit

  3. Creëren van kennis

  4. Weifelen (defer) met commitment

  5. Snel leveren

  6. Respect voor mensen

  7. Optimaliseren van het geheel

 

agile development tradional software

Bron: presentatie Lean & Agile op slideshare.net, Claudio Perrone

Laatst aangepast op zondag, 18 oktober 2020 12:17  
Agile, Lean en Scrum volgens Joe Justice (1)
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

Joe Justice (Wikispeed) legt in zijn Ted-talk (26-12-2011) uit hoe de toepassing van Agile, Lean en Scrum binnen de auto-industrie revolutionaire resultaten oplevert bij het ontwikkelen van een '100 miles per gallon'-auto.

Mocht je écht de smaak te pakken krijgen, dan bekijk dan het uitgebreidere verhaal van Joe Justice's presentatie (1:31:13) op de Scrum Gathering in Seattle.

Laatst aangepast op zondag, 18 oktober 2020 12:09  
Vraaggestuurde informatievoorziening volgens Remko van der Pols
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

bisl vraaggestuurde

BiSL-goeroe Remko van der Pols doet in het boek Naar een vraaggestuurde informatievoorziening samen met René Sieders en Ben Stoltenborg een poging theorie te combineren met de gezondheidszorg als praktijkcase om concrete handvatten te geven voor de inrichting van businessinformatiemanagement (BIM) in zorgorganisaties.

Persoonlijk vindt ik de case minder interessant. Hieronder een paar veralgemeniseerde 'losse flodders' uit het boek.

Organisaties staan volgens Van der Pols & co. voor drie uitdagingen:

  1. Vernieuwing van de informatievoorziening: de informatievoorziening is een kritische succes- en productiefactor geworden, met het disfunctioneren van de informatievoorziening als bedrijfsrisico. Het landschap met vooragl centrale, gesloten systemen staat voor grootschalige vernieuwing.

  2. Inrichting van businessinformatiemanagement: gezien het (toenemende) belang van de informatievoorziening voor het primaire proces, vraagt de organisatie van zowel IT als beheer expliciet aandacht. Vraagsturing is hierbij belangrijk en de inrichting van de vraagorganisatie, het businessinformatiemanagement vormt hierbij een belangrijke activiteit.

  3. Professionalisering van de vraag en vraagorganisatie: om de omslag te maken van aanbodgedreven naar vraaggedreven wordt het essentieel kennis en vaardigheden te verkrijgen om leveranciers goed aan te sturen (incl. outsourcing).

Volgens Van der Pols & co. zijn er twee manieren waarop de informatievoorziening kan worden aangestuurd:

  1. Aanbodsturing: de IT-organisatie onderkent de ontwikkelingen en beslist over de te gebruiken middelen en investeringen ten aanzien van de informatievoorziening. De gebruikersorganisatie heeft (alleen) een inhoudelijke en adviserende rol.

  2. Vraagsturing: het besturen van de informatievoorziening vanuit gebruikers- en bedrijfsperspectief; de organisatie is zélf (eind)verantwoordelijk voor wat zij nodig heeft en het nemen van investeringenbeslisingen over de informatievoorziening.

De keuze voor vraagsturing of aanbodgedreven sturing is afhankelijk van het belang van de informatievoorziening. Van der Pols & co. onderscheiden hierbij vier categorieën:

  1. IT als hulpmiddel: automatisering speelt nauwelijks een rol (ledenadministratie)

  2. IT als ondersteuning: automatisering begtreft alleen ondersteundend processen (financiële en personeelsadministraties)

  3. IT als bedrijfskritisch: primaire proces is afhankelijk van IT (bedrijfspakketten zoals ERP)

  4. IT als bedrijfsproces: informatieverwerking is het primaire bedrijfsproces (banken, verzekeraars of overheid)

Dé aanleiding om over te stappen op vraagsturing is als de informatievoorziening te belangrijk is om ICT'ers over te laten. Dit is het geval als de informatievoorziening bedrijfskritisch wordt óf het bedrijfsproces vormt.

Zodra een organisatie ervoor kiest over te gaan van aanbod- naar vraaggestuurd, wordt de vraagorganisatie expliciet en krijgt zij ook de macht. De structuur van de vraagorganisatie moet expliciet worden ingericht (governancestructuur). Volgens Van der Pols & co. moet de structuur van de vraagorganisatie passen in de (informele) machtslijnen van de organisatie zelf. De inrichting wordt daarmee primair machts- en invloedgedreven, waarbij de structuur primair afhankelijk is van de inrichting van de gebruikersorganisatie en de personen daarin. Omdat in veel organisatie de macht verspreid is en de omvang van zgn. informatiedomeinen verschillend is, is de sturing op de informatievoorzienining nooit uniform. De invulling en uitwerking is - aldus Van der Pols & co. - situationeel bepaald.

Volgens Van der Pols & co. zijn gelden drie wetten bij het het inrichten van de besturingsstructuur van de informatievoorziening in een organisatie (governancestructuur):

  1. De structuur van de sturing over de informatievoorziening moet een afgeleide zijn van de machtsstructuur van de organisatie: effectieve vraagsturing veronderstelt dat de betrokken manager in staat is, het voor hem of haar relevante deel van de informatievoorziening direct te sturen.

  2. Kennis van het bedrijfsproces is essentieel: de businessinformatiemanager moet dezelfde taal spreken als de businessmanager en moet het bedrijfsproces goed kennen.

  3. De invulling van informatiemanagement volgt de lijnen van de baas: sturing van de informatievoorziening is baasafhankelijk, waarbij de persoon en stijl van de manager van invloed is op de governance, en dus voor de relatie tussen businessinformatiemanagement en management.

Bij het inrichten van de governancestructuur moet aandacht besteed worden aan:

  1. Opdeling applicatielandschap en afbakening informatiedomeinen: het applicatielandschap beschrijft op hoofdlijnen de samenhang van de verschillende applicaties van een organisatie. Dit landschap vormt de basis voor de opdeling en vaststelling van de informatiedomeinen en het beleggen van de domeinverantwoordeliijkheid door één persoon (functie) aan te wijzen die de verantwoordelijkheid krijgt voor de informatievoorziening in een informatiedomein.

  2. Afspraken over belangen: afspreken wat de rechten en plichten zijn voor andere belanghebbenden dan de vastgestelde, verantwoordelijke domeineigenaar. Een belangrijke voorwaarde is dat de belangrijkste belanghebbenden geïnventariseerd zijn, waarbij wordt onderkend welke belanghebbenden belangen hebben in welke delen van de informatievoorziening, wat die belangen inhouden en hoe zwaarwegend die zijn.

  3. Overkoepelende autoriteit: het kan noodzakelijk of wenselijk zijn om een domein-overstijgende, overkoepelende autoriteit te benoemen.

  4. Corporate-informatiemanager: benoemen van corporate-informatiemanager die verantwoordelijk is voor het bewaken, coördineren en afstemmen van samenhang van de informatievoorziening.

  5. Ophanging van businessinformatiemanagement: ophangen van businessinformatiemanagement in de organisatie (in de afdeling, werkzaam vanuit een aparte afdeling of ingehuurd vanuit de IT-afdeling). Bij grote organisaties kan het wenselijk zijn verschillende modellen naast elkaar te gebruiken gebruiken.

Businessinformatiemanagement moet borgen dat de informatievoorziening goed aansluit en blijft aansluiten op de bedrijfsprocessen. Een belangrijjk onderdeel van businessinformatiemanagement is het inventariseren van de veranderbehoefte, zowel vanuit de huidige situatie (functionele kwaliteit, technische kwaliteit en exploitatiekwaliteit) en de ontwikkelingen in de keten, het bedrijfsproces en op technologisch gebied.

Van der Pols & co. stellen dat elke keuze die je maakt, voorafgegaan wordt door een afweging van kosten, baten en de ellende die je je op de hals haalt met het al of niet doorvoeren van een wijziging. Deze afweging illustreren zij met een zgn. ellendedriehoek:

Ellendedriehoek

Bron: Naar een vraaggestuurde informatievoorziening, Remko van der Pols René Sieders en Ben Stoltenborg

 

Laatst aangepast op zaterdag, 25 juli 2020 07:32  
Succesvolle ict-projecten volgens Chris Verhoef
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

ict projecten verhoef

In een interview in De Volkskrant (6/12/2011) gaat Chris Verhoef, hoogleraar informatica aan de VU, in op de rol van de (overheids als) opdrachtgever bij het mislukken van ict-projecten. Verhoef spreekt over echecs 'die iedereen met kennis van zaken van verre ziet aankomen'.

Verhoef gaat in op het belang van de Amerikaanse Clinger-Cohen Act; een harde wet op de financiering en ontwikkeling van ict-systemen uit 1996 die de boel vooral wakker heeft geschud: "De echte betekenis van de Clinger Cohen wet is dat het de voorwaarden opsomt waaraan een ict-project moet voldoen. Als we in Nederland zo'n regelgeving hadden gekend, had dat veel zeperds gescheeld.'

De reden waarom we in Nederland dergelijke regels (nog) niet hebben is - aldus Verhoef - '[o]mdat bij ons de bom nog niet gebarsten is en we de politieke discipline ontberen die nodig is om debacles te vermijden.' Met deze politieke discipline bedoelt hij '[d]at je als opdrachtgever niet elke dag iets anders zegt over wat je verlangt van je nieuwe systeem.'

Verhoef stelt dan ook dat de eerste vraag aan een opdrachtgever zijn: "Wat wilt u precies? Maar de politiek is volgens hem vaak (te) opportunistisch: "Ict'ers moeten meer weerstand bieden. Politici moeten zich beperken tot de wat-vraag en de hoe-vraag overlaten aan de lui die kennis hebben van creatieve problemen." "Verder waarschuwt hij voor een te hoog ambitieniveau: "We moeten niet meteen voor 100 procent gaat, 80 procent is al geweldig. Daarvoor kiezen, vergt politieke discipline. En die is ver te zoeken. Zo blijven we mislukkingen genereren."

Verhoef noemt als voorbeeld het rekeningrijden. "Er zijn files in het land. De vraag voor de politiek moet zijn: wat kan gedaan worden om doorstroming te bevorderen? Goeie vraag. Maar dan voegt de politiek er meteen aan toe dat er kastjes moeten komen in auto's, en dat het ons 3,5 miljard gaat kosten en een half miljard aan jaarlijks onderhoud. Dan kunnen we rekeningrijden. 'Maar wat is nodig voor rekeningrijden? Je moet weten wie wanneer waar op de weg is. Zo iemand moet je een rekening kunnen sturen. Je hebt dus een klantrelatie nodig. 'Nou, zo'n systeem hebben we al. Het heet trajectcontrole. Het stelt de overheid in staat te zien of jij te hard hebt gereden op een bepaald stuk weg. Zo ja, dan krijg je de rekening thuis gestuurd. Er is dus een klantrelatie. Ik zeg: stuur altijd een rekening, namelijk voor het gebruik van de weg in spitsuren. Rekeningrijden ingevoerd! Wat is nog het probleem'"

Ook het Electronisch Patiëntendossier noemt Verhoef als voorbeeld van een overbodig systeem. "Wat wilde men? Geautomatiseerde uitwisseling van gegevens tussen artsen om medische missers te voorkomen. Prima. Het draaide uit op enorm geharrewar. 'Het ergste is: we hebben al een geautomatiseerd systeem van medische informatie. het heet Vecozo, Veilige Communicatie in de Zorg en is een portaal van de vereniging van zorgverzekeraars. Ik denk dat 90 procent van alle declaraties van dokters via dat portaal loopt. (...) Het is een systeem waarvan ik zeg: petje af. En weer blijkt dat het probleem is opgelost en met bestaande middelen kan worden gerealiseerd."

In de Clinger-Cohen Act is geregeld dat het Office of Management and Budget (OMB) gaat over de spelregels voor nieuwe ict-projecten. Het OMB kwam met een set van zgn Raines Rules (genoemd naar de auteur), "een setje van acht regels; zo helder als glas en zo hard als staal. Regels als: kijk eerst of er een alternatief is. Lever een businesscase, een financieel-economische onderbouwing. Ontwikkel het project in kleine stapjes, zodat je tussentijds kunt bijstellen. Wie niet aan alle acht regels kan voldoen, krijgt geen geld en kan fluiten naar zijn project."

"Verhoef: 'Waar de kromming van een banaan gespecificeerd is in een Europese richtlijn is er voor ict gewoon niks in Nederland. Dat is echt te weining. Zo'n lijstje als dat van Raines inspireert: acht of tien harde heldere regels. Ik zou er meteen al een van Raines invoeren: ga niet een systeem bouwen dat al bestaat."

Zie ook: 8 gouden regels bij IT-investeringen: Raines Rules

Bron: interview met Chris Verhoef in De Volkskrant (6/12/2011) "Mijn eerste regel zou zijn: bouw geen ict-systeem dat al bestaat"; Jan Tromp

Laatst aangepast op zaterdag, 06 juni 2020 20:05  
Beheren onder architectuur
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

Bart de Best beschrijft in een BEA-stappenplan hoe 'beheren onder architectuur' kan worden vormgegeven:

BEA-stappenplan

Het BEA-raamwerk

De basis van het boek wordt gevormd door het BEA-raamwerk. Dit raamwerk maakt een onderscheid in drie niveaus (aspectgebieden):
• Richten (beleid)
• Inrichten (ontwerp)
• Verrichten (uitvoering)

Per aspectgebied zijn stappen gedefinieerd. Elke stap is een hoofdactiviteit die plaats dient te vinden om onder architectuur tot een goed ingerichte beheerorganisatie te komen. Per stap worden vervolgens best practices beschreven voor zowel een beheerorganisatie als een projectorganisatie (ten behoeve van projectbeheersing).

Op het niveau ‘Richten’ is de eerste stap dat een ICT-beleid en ICT-beleidsplan worden opgesteld. In de tweede stap worden, uitgaande van het ICT-beleidsplan de architectuurprincipes die richtinggevend zijn voor de inrichting van de beheerprocessen opgesteld. De principes worden in de derde stap uitgewerkt in modellen.

Het aspectgebied ‘Inrichten’ bestaat uit twee deelgebieden, ‘Structuur’ en ‘Vormgeving’. Per deelgebied zijn ook weer drie stappen gedefinieerd. In deelgebied structuur wordt in de eerste stap het organogram, met bijbehorende functies en rollen beschreven. In de tweede stap worden de doelen van de beheerprocessen beschreven en zodanig uitgewerkt dat bewaking van deze doelen mogelijk wordt. In de derde stap worden de requirements beschreven die worden gesteld aan de beheerprocessen. Deze requirements zijn voorschrijvend voor de inrichting van beheerprocessen.

De eerste stap in deelgebied vormgeving is het opstellen van procesontwerpen voor de diverse beheerprocessen. Vervolgens wordt in de tweede stap de taakverdeling over de processen vormgegeven. Hierbij zijn ondermeer een logische groepering van taken en essentiële functiescheidingen
van belang. Tot slot worden in de derde stap de ontworpen processen verder ingericht waarbij methoden, middelen en mensen aan de taken worden gekoppeld.

Binnen het laatste aspectgebied ‘Verrichten’worden afspraken gemaakt over de uitvoering van het beheer. In de eerste stap van dit aspectgebied worden afspraken beschreven over de toepassing van beheermiddelen. Voorbeelden hiervan zijn afspraken over hergebruik en richtlijnen voor vernieuwing. In de tweede stap worden de competenties van de beheermedewerkers opgesteld, c.q. aangepast op basis van bestaande functiebeschrijvingen. Ten slotte wordt in de derde stap het sluitstuk van het beheer opgezet door afspraken te maken over audit en review. Het definiëren van meetpunten en het inrichten van een terugkoppelingsmechanisme om verbeteringen uit de audits en reviews door te voeren zijn hier voorbeelden van. Bij deze laatste stap is een auditor de aangewezen persoon om vanuit zijn vaktechnische kennis de architect te adviseren.

Door middel van een RASCI-tabel, dat wil zeggen een tabel waarin rollen worden af gezet tegen de verantwoordelijkheden Responsible, Accountable, Supportive, Con sulted en Informed, zijn per stap de acti viteiten die hierin plaatsvinden uitgezet tegen de bij de stappen betrokken rollen. Hierdoor ontstaat een helder overzicht van de diverse verantwoordelijkheden en taken die nodig zijn bij het inrichten en uitvoeren van een beheerorganisatie onder architectuur.

Bron: IT Beheer Magazine nummer 10, 2007

 

Laatst aangepast op zaterdag, 06 juni 2020 20:03  
9 Kenmerken van goede requirements volgens IBM
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

9 number negen

In de whitepaper "Ten steps to better requirements management" van Dominic Tavassoli (IBM) wordt gesteld dat de impact van slecht geformuleerde requirements verwoesten kan zijn: "(I)t can have a domino effect that leads to time-consuming rework, inadequate deliveries and budget overruns." en worden de onderstaande 9 kenmerken genoemd van goede requirements:

  1. Correct (correct): technisch en juridisch mogelijk

  2. Volledig (complete): express a whole idea

  3. Duidelijk (clear): eenduidig en helder

  4. Consistent (niet conflicterend)

  5. Verifieerbaar (verificable): het is mogelijk vast te stellen óf de oplossing voldoet aan de gesteld eisen

  6. Traceerbaar (traceable): uniek identificeerbaar en herleidbaar

  7. Haalbaar (feasible): realiseerbaar binnen tijd en budget

  8. Modulair (modular): aanpasbaar zonder drastische gevolgen (excessive impact)

  9. Ontwerp-onafhankelijk (design-independent): beperken zich tot het 'wat' (en gaan dus niet over het 'hoe').

Bron: Ten steps to better requirements management, Requirements Management Whitepaper, Dominic Tavassoli (Juni 2009, IBM)

 

Laatst aangepast op maandag, 13 april 2020 10:16  
7 Mythes over requirements volgens James Robertson
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

7 cognitieve activiteiten

Volgens James Robertson zijn er zeven mythes op het gebied van requirements:

  1. Mythe-1: Requirements gaan over requirements: de waarheid is dat requirements gaan over problemen van de business. Kijk dus - als business analist - niet te veel naar de software, maar blijf oog houden voor het bedrijfsprobeem 'achter de software'.

  2. Mythe-2: Luister naar de gebruikers: gebruikers komen niet op de proppen met innovaties, maar vragen vaak alleen om aanpassingen en verbeteringen van de bestaande situatie. De beroemde uitspraak van Henry Ford is dat als hij de mensen zou vragen wat ze zouden willen, ze naar alle waarschijnlijk hadden gezegd: snellere paarden.

  3. Mythe-3: Testers testen software: testers moeten niet alleen het eindproduct testen, maar ook de tussenproducten (end-to-end), zodat je fouten in requirements vroegtijdig ontdekt.

  4. Mythe-4: Schrijf altijd een complete set aan requirements: de 80/20 regel geldt ook voor requirements.

  5. Mythe-5: Ruim tijd in for het debuggen: debuggen doe je pas op het eind, besteed in plaats daarvan juist meer tijd aan het goed krijgen van je requirements. Dit verdient zichzelf qua doorlooptijd en kosten zeker terug.

  6. Mythe-6: Begin met use cases: use cases gaan over de oplossing, begin eerst met het begrijpen van het probleem.

  7. Mythe-7: Met agile heb je geen requirements nodig: ook al kent agile geen requirementsfase, requirements blijven cruciaal (bijv. voor het visiedocument, je initiële requirementsset, de gesprekken en het testen).

Bron: http://it-maintenance.blogspot.com/2011/04/7-requirements-myths.html en http://www.reaco.nl/kenniscentrum/requirementsMythes.asp

Laatst aangepast op zondag, 12 april 2020 16:08  
7 Misvattingen over de relatie tussen testen en requirements
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

7 cognitieve activiteiten

Volgens Dororthy Graham kan er veel tijd en geld bespaard worden als testers betrokken zijn bij het testen van requirements. Zij benoemt zeven misvattingen over het verband tussen testen en requirements:

  1. Requirements aan het begin, testen aan het eind: het vroegtijdig betrekken van testers is juist een garantie voor goede requirements.

  2. Testen is pas mogelijk als het systeem bestaat: benut de mogelijk om requirements 'op papier' te testen.

  3. Requirements worden gebruikt bij het testen, maar omgekeerd niet: goede testanalyse leidt tot betere requirements.

  4. Het opstellen van testscripts is slechts een testprobleem: vage specificaties zijn moelijk meetbaar en (dus) testbaar te maken

  5. Kleine wijzigingen beïnvloeden project minimaal: 'klein' vanuit requirementsperspectief , kan test-technisch grote gevolgen hebben

  6. Tester hebben requirements niet écht nodig: requirements zijn dé testbasis omdat ze de verwachte uitkomst voorspellen

  7. Testers kunnen niet testen zonder requirements: bij inadequate requirements resteren 'exploratief testen' en goede testware om te testen.

Bron: Requirements and Testing: Seven Missing-Link Myths, Dorothy Graham, IEEE Software (sept/oct 2002)

Laatst aangepast op zondag, 12 april 2020 16:07  
Automatisering volgens Daan Rijsenbrij
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

keep things simple daan rijsenbrij

daan rijsenbrij

'De Belastingdienst vroeg me in 2015 na te denken over de digitale architectuur daar. Ik vroeg hoeveel architecten ze hadden. Dat wisten ze niet precies: 200, 250. Dat vind ik een een gek antwoord. Jan en alleman is daar architect. Ik schat dat er in Nederland circa twintigduizend IT-ers rondlopen die zich architect noemen. Ik neem er slechts duizend serieus.'

Zijn ideaal is dit: 'De hoofdregel in de automatisering luidt: eerst reorganiseren en vereenvoudigen, dan pas IT. Anders ben je bezig chaos te automatiseren. Dat doet de overheid nu. Er zitten te veel ambtenaren in Den Haag. Er zijn te veel ingewikkelde besluitvormingsprocessen. Het idee van de compacte overheid is in de kast gestopt en daar ligt nu een laag stof op. met goede IT kun je die compacte overheid wel bereiken.'

Bron: Interview met Daan Rijsenbrij, in: Elsevier 5 oktober 2019

Laatst aangepast op vrijdag, 03 januari 2020 19:40  
Diensten volgens Philip Kotler
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

service kotler

philip kotler diensten

Kotler (2000) definieert dienstverlening (service) als volgt: ‘A service is any act or performance that one party can offer to another that is essentially intangible and does not result in the ownership of anything. Its production may or may not be tied to a physical product.’ Deze definitie wordt door Kotler vervolgens vertaald naar de navolgende eigenschappen van diensten:

  1. Ontastbaarheid (intangibility): afnemer kan niet de precieze resultaten zien voor af aan de dienstverlening.

  2. Ondeelbaarheid (inseparability): diensten worden gelijktijdig geproduceerd en geconsumeerd.

  3. Variabiliteit (variability): diensten worden door personen geproduceerd en zijn daardoor van deze persoon afhankelijk, hierbij beseffend dat geen twee personen exact gelijk of even goed zijn in de aangeboden dienst.

  4. Vergankelijkheid (perishability): er kan geen voorraad van de dienst worden aangelegd. Hierdoor kan de benodigde capaciteit voor het opvangen van piekmomenten hoger zijn dan bij gelijkmatige vraag.


Op basis hiervan onderkent Kotler vijf categorieën van product- of dienstaanbiedingen (offerings):

  1. ‘Pure tangible goods. The offering consist primarily of a tangible good such as soap, toothpaste, or salt. No services accompany the product.

  2. Tangible with accompanying services. The offering consists of a tangible good accompanied by one or more services.

  3. Hybrid. The offering consists of equal parts of goods and services. For example: people patronize restaurants for both food and service.

  4. Major service with accompanying goods and services. The offering consists of a major service along with additional services or supporting goods. For example
    airline passengers buy transportation service. The trip includes some tangibles, such as foods and drinks, a ticket stub, and an airline magazine. The service requires a capital-intensive good – an airplane – for its realization, but the primary item is a service.

  5. Pure service. The offering consists primarily of a service. Examples include baby-sitting, psychotherapy, and massage.

Bron: Kluskens, P. en I. van der Wijst, (2005), Typologie van informatie: een voorzet tot verandering, Maandblad voor Accountancy en Bedrijfseconomie


Laatst aangepast op vrijdag, 03 januari 2020 13:13  
Meer artikelen...


JPAGE_CURRENT_OF_TOTAL

It is not that I'm so smart. But I stay with the questions much longer.

Albert Einstein

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 105 gasten online
Artikelen

problems business caused management workman taylor quote

Banner
Banner

hooked nir eyal mensen verslingerd product

Hooked
Hoe je mensen 'verslaafd' maakt aan je product
Nir Eyal

Bij Bol.com | Managementboek



Lean boekentips

Toyota Kata Culture
Building Organizational Capability and Mindset through Kata Coaching
Mike Rother & Gerd Aulinger

Bij Bol.com | Managementboek

Bewaren

Banner