:strip_icc():strip_exif()/u/18112/avatar.jpg?f=community){kind=avatar}
Internet barst van de tutorials over onenote gebruik en hoe je het in moet delen. Maar ik vind niets dat aansluit bij m'n eigen situatie, en ik denk dat er meer mensen met een dergelijke structuur zitten. Voor de beeldvorming: ik werk voor een holding met dochterondernemingen. De hoofdentiteiten zijn
- Dochteronderneming
- Persoon
- Project. In tegenstelling tot de formele definitie van project kan dit ook eeuwiglopend zijn. Denk bijvoorbeeld aan 'HR zaken' (persoonlijke dus, niet als afdeling bedoeld)
- Iets wat ik maar topic zal noemen. Een projectachtig iets maar dan veel kleiner. Als een project een notebook zou zijn zou een topic een sectie zijn. Als een project een sectie zou zijn zou een topic een pagina zijn. Lijkt me tenminste, al zou het kunnen dat afhankelijk van de notebookindeling zowel projecten als topics beiden secties zouden moeten zijn
- Klanten/leveranciers. Deze zijn als entiteit relatief onbelangrijk omdat ze ook al in de andere soorten ondergebracht kunnen worden.
In de volgende situaties gaat het mis:
- Een gesprek met 1 of meerdere personen over diverse onderwerpen die weliswaar gerelateerd zijn, maar die wel eerder als afzonderlijk onderwerp gedefinieerd zijn en dat eigenlijk ook moeten blijven
- Een vervolggesprek over hetzelfde onderwerp met een iets gewijzigde groep
- Twee onderwerpen komen in de loop der tijd samen in 1 onderwerp of omgekeerd
Wat niet goed werkt:
- Indeling per dochteronderneming. Onderwerpen kunnen over dochterondernemingen heen gaan
- Iets op persoonsbasis. Een pagina per persoon leek goed te werken totdat in wisselende samenstellingen over onderwerpen gesproken wordt
- Indeling per onderwerp (project/topic). Het punt is dat deze in de tijd gezien in elkaar over kunnen vloeien en dat notities moeilijk bij te houden worden als een meeting over verschillende onderwerpen gaan die een gezamenlijk raakvlak hebben
- Meerdere personen hebben dezelfde voornaam. Achternaam erbij of initialen gebruiken klinkt logisch maar het is lastig dit structureel hetzelfde te doen. Dat laatste geldt trouwens ook voor projectbenamingen.
Mogelijke oplossing:
De logische oplossing zou zijn om tags toe te voegen aan notities. 1 pagina per meeting, en dan taggen wie erbij betrokken is en tags voor dochteronderneming, project en topic. Op die manier krijg je een structuur die lijkt op een technisch PDM pakket waarbij je dwarsdoorsnedes door een technische structuur kunt maken: een overzicht van de hydrauliekhierarchie, een van de elektrische hierarchie etc terwijl je onder water nog steeds dezelfde dataset hebt maar er gewoon anders naar kijkt. OneNote kan het helaas niet zo visualiseren maar met de zoekfunctie zou je een eind komen.
Waar het knelt is dat onenote tags hier volgens mij niet zo geschikt voor zijn omdat ze meer voor acties bedoeld lijken te zijn. En ik heb het gevoel dat m'n hele adreslijst overtikken in de tags ook niet zo handig is.. Tags lijken bedoeld te zijn voor een setje van max enkele tientallen.
Heeft iemand het ei van columbus? Ik zou bijna een onenote tab bij gaan houden met een beperkte set zoekwoorden en die dan maar handmatig in notities te copy/pasten. Waarschijnlijk zou dit zelfs nog best goed werken, maar het voelt ook zo 2005.
- Dochteronderneming
- Persoon
- Project. In tegenstelling tot de formele definitie van project kan dit ook eeuwiglopend zijn. Denk bijvoorbeeld aan 'HR zaken' (persoonlijke dus, niet als afdeling bedoeld)
- Iets wat ik maar topic zal noemen. Een projectachtig iets maar dan veel kleiner. Als een project een notebook zou zijn zou een topic een sectie zijn. Als een project een sectie zou zijn zou een topic een pagina zijn. Lijkt me tenminste, al zou het kunnen dat afhankelijk van de notebookindeling zowel projecten als topics beiden secties zouden moeten zijn
- Klanten/leveranciers. Deze zijn als entiteit relatief onbelangrijk omdat ze ook al in de andere soorten ondergebracht kunnen worden.
In de volgende situaties gaat het mis:
- Een gesprek met 1 of meerdere personen over diverse onderwerpen die weliswaar gerelateerd zijn, maar die wel eerder als afzonderlijk onderwerp gedefinieerd zijn en dat eigenlijk ook moeten blijven
- Een vervolggesprek over hetzelfde onderwerp met een iets gewijzigde groep
- Twee onderwerpen komen in de loop der tijd samen in 1 onderwerp of omgekeerd
Wat niet goed werkt:
- Indeling per dochteronderneming. Onderwerpen kunnen over dochterondernemingen heen gaan
- Iets op persoonsbasis. Een pagina per persoon leek goed te werken totdat in wisselende samenstellingen over onderwerpen gesproken wordt
- Indeling per onderwerp (project/topic). Het punt is dat deze in de tijd gezien in elkaar over kunnen vloeien en dat notities moeilijk bij te houden worden als een meeting over verschillende onderwerpen gaan die een gezamenlijk raakvlak hebben
- Meerdere personen hebben dezelfde voornaam. Achternaam erbij of initialen gebruiken klinkt logisch maar het is lastig dit structureel hetzelfde te doen. Dat laatste geldt trouwens ook voor projectbenamingen.
Mogelijke oplossing:
De logische oplossing zou zijn om tags toe te voegen aan notities. 1 pagina per meeting, en dan taggen wie erbij betrokken is en tags voor dochteronderneming, project en topic. Op die manier krijg je een structuur die lijkt op een technisch PDM pakket waarbij je dwarsdoorsnedes door een technische structuur kunt maken: een overzicht van de hydrauliekhierarchie, een van de elektrische hierarchie etc terwijl je onder water nog steeds dezelfde dataset hebt maar er gewoon anders naar kijkt. OneNote kan het helaas niet zo visualiseren maar met de zoekfunctie zou je een eind komen.
Waar het knelt is dat onenote tags hier volgens mij niet zo geschikt voor zijn omdat ze meer voor acties bedoeld lijken te zijn. En ik heb het gevoel dat m'n hele adreslijst overtikken in de tags ook niet zo handig is.. Tags lijken bedoeld te zijn voor een setje van max enkele tientallen.
Heeft iemand het ei van columbus? Ik zou bijna een onenote tab bij gaan houden met een beperkte set zoekwoorden en die dan maar handmatig in notities te copy/pasten. Waarschijnlijk zou dit zelfs nog best goed werken, maar het voelt ook zo 2005.