Tänkte skriva några rader om de systemteorier som kallas för HST, Hard Systems Thinking eller Hårt systemtänkande på svenska.
De systemteorier som Peter Checkland i efterhand har grupperat som Hårt systemtänkande (HST) utvecklades för att vara mer anpassade till praktisk problemlösning än de teorier som fanns tidigare. De var mer luddiga och abstrakta, och alltför ofta var det inte möjligt att tillämpa teorierna i praktiken. De teorier som tillhör HST; Operational Research (OR), Systems Analysis (SA) och Systems Engineering (SE), har starka band med ingenjörstänkandet. Man försöker finna den optimala vägen från ett tillstånd till ett annat, och vägen till problemets lösning är väldigt linjär enligt dessa teorier.
OR har sin grund i matematiken och användes till en början av engelsmännen under andra världskriget. Man kunde räkna ut effektiva sätt att sänka U-båtar eller skjuta ner flygplan. Det gick bra just för att det var möjligt att ta fram matematiska modeller som beräknade ett optimalt sätt att träffa U-båtarna eller flygplanen. Man försökte även att bli en tvärvetenskap och fungera som beslutshjälp inom organisationer, men det misslyckades. Tillslut så blev två av de tre mest kända personerna inom OR dess största kritiker, främst för att tänkandet var så stelt och fast i matematiken, som inte kan spegla människors agerande på ett rättvist sätt. Statiska modeller fungerar inte i alla sammanhang.
SA uppkom på ett liknande sätt, fast denna gång var det den amerikanska krigsmakten som utvecklade fram det under efterkrigstiden. Man ansåg SA vara en systerdiciplin till OR. Skillnaderna var att SA inte var lika fast i det matematiska tänket som OR. Dessutom var den mer fokuserad på kostnader, analys av strategiska och politiska frågor. Tanken var att SA skulle se till att en organisation fick största möjliga ekonomiska nytta ur sina resurser, och underlätta uträkning av resurstilldelning. SA användes på många delar av departementen och används än idag till stor utsträckning.
SE är nog den vanligast förekommande skolbildningen i USA. Den utvecklades främst vid Bell under 40- och 50-talet och även här försökte man få till mer praktiska metoder och teorier. Man ville få till mer slutprodukt och ödsla mindre tid på att tänka på vägen dit. Man tyckte att det viktigaste är att man använder de resurser man har, i form av människor, pengar, maskiner eller material, skulle användas på ett så optimalt sätt som möjligt. Att man får feedback under vägen till målet och har dessutom väldigt tydligt definierade mål är därför viktigt inom SE.
tisdag, maj 30, 2006
Problemet fixat
Näe, visst var det mitt eget fel. Hade försökt ha med nå ottillåten html kod i en post. Blogger sa att det gills inte, så jag tänkte inte mer på det. Men trots varningen hade den tydligen lagt in html taggarna i posten.
Dethär var ju högst beklagligt, nu har en massa ändringar jag gjort i templaten försvunnit och lite annat jobbigt.
Dethär var ju högst beklagligt, nu har en massa ändringar jag gjort i templaten försvunnit och lite annat jobbigt.
Blogger
Nånting är seriöst fel med bloggen. Hela sidebaren hamanr längst ner. Och jag har inte ens ändrat på något! Tog bort allt jag ändrat på templaten och allt, ändå verkar den ha ballat ur helt.
Får titta på detdär imorrn, kan ju vara något på bloggers sida.
Får titta på detdär imorrn, kan ju vara något på bloggers sida.
måndag, maj 29, 2006
Soft Systems Methodology
Här har ni en sammanfattning av vad SSM är för någonting.
SSM skapades av Peter Checkland under 60-talet när han arbetade på det brittiska Lancaster universitetet. När han försökte applicera dåtidens systemtänkande (SE/SA) på problemområden så som företagsmanagement insåg Checkland och hans kollegor snabbt att det inte var möjligt. SE/SA fungerade inte för ostrukturerade och multifacetterade problem med många mänskliga variabler. Systems Engineering kräver nästan att man känner till problemet och systemet är tydligt avgränsat. Men i de fall som gruppen arbetade med insåg de att det var svårt att ge det undersökta systemet tydliga gränser och hitta en tydlig uppgift som systemet skulle arbeta med. De fick lov att acceptera att i mänskliga situationer så strävar olika individer efter olika saker
De började skissa på en helt ny metodologi där de baserade sitt arbete på aktionsforskning, vilket innebär att istället för att endast undersöka och se på problemet utifrån, så ger personen som undersöker organisationen sig själv in arbetet och försöker åstadkomma en förändring eller förbättring rent praktiskt, för att lära sig hur det fungerar. De ansåg att på ett högre plan så var varje situation de hittade sig själv i en mänsklig situation, där varje individ försöker agera på ett sätt som är meningsfullt för dem själva.
Efter att ha under en tid använt SSM i praktiken så kom Checkland fram till att de sju steg som då ingick i SSM sällan följdes och bestämde sig då för att göra metodologin flexiblare och mer generaliserad. Checkland såg att det fanns fler faktorer än bara de logiska, t.ex. saker som företagskultur och politik, som kunde ha inverkan på verksamheten. Till slut så kom de fram till det SSM som förespråkas idag..
De fyra faser som SSM idag består av heter följande på engelska: Finding out, Modelling, Comparison and Debate, Take action. Fritt översatt till svenska betyder de: Ta reda på, modellera, jämför och debattera, ta aktion.
Den första fasen i SSM, Finding out, delas upp i två delar, en logisk analys och en kulturell analys. I och med att tyngdpunkten i SSM är den mänskliga faktorn så ligger tyngdpunkten här på den kulturella analysen. Den kulturella analysen kan delas upp i ännu mindre delar, nämligen en rollanalys, en social analys och en politisk analys. Kallas även för analys ett, analys två och analys tre.
I analys ett så undersöks alla de roller som finns i situationen. Att känna till vem/vilka som är klienter, problemägare och problemlösare är mycket relevant i arbetet längre fram. Klienterna är de som satt igång det hela, de som varit missnöjda med hur saker och ting varit tidigare. Problemlösare är de människor som ska förbättra situationen, det är problemlösarna som är drivkraften i projektet. Och slutligen, problemlösarna är de som måste intervjuas för att få en så bra bild av problemsituationen som möjligt. Det är problemlösarna som avgör vilka som är problemägarna .
Analys två och tre hanterar de mer outtalade aspekterna som berör problemsituationen, det kan vara normer, värderingar, sociala roller och politiskt klimat. Svårigheter kan uppstå i sökandet efter information om detta, då det är oftast mycket svårt för människor att sätta ord på saker som normer och värderingar, ibland känner individerna inte ens till vad de har för normer och värderingar. Det innebär att det inte går att fråga människor om dessa saker, personen som analyserar tvingas helt enkelt observera situationen och försöka reda ut själv vilka roller, normer och värderingar som finns i problemsituationen.
Efter att både den kulturella och logiska analysen slutförts så tas det fram en bild på situationen, en sk. rik bild. Att rita bilder för att förtydliga de olika element som finns i en mänsklig situation är något som varit karakteristiskt för SSM sedan första början. Checkland menar att bilder är bra för att förtydliga att problemsituationen är en helhet och inte endast en mängd delar. Dessa rika bilder är ovärderliga för att ha som grund vid en diskussion.
När den rika bilden av situationen är färdig, så är det dags att börja modellera, dvs. fas två. Det finns 3 olika verktyg som kan användas vid modelleringsarbetet: CATWOE, rotdefinition och en konceptuell modell.
CATWOE står för Customers, Actors, Transformation, Weltanschauung, Owner, Enviromental constraints. Weltanschauung är den världsuppfattning som gör transformationen meningsfull. Vid Transformation fasen bör man tänka på 3E modellen som består av tre relevanta kriterier, nämligen Efficacy, Efficiency och Effectiveness.
Rotdefinition är en förkortad beskrivning av de grundläggande aspekterna hos systemet. Den konceptuella modellen består av det minimum av aktiviteter som behövs för att utföra den transformation som organisationen vill åstadkomma.
PQR är en översiktlig beskrivning. P står för vad ett system skall göra, Q hur det skall göras och R varför det skall göras.
Genom att jämföra modellerna med verkligheten så är det möjligt att vid en diskussion få fram deltagarnas motsatta åsikter på ett sätt som annars inte vore möjlig. I denna fas är det du som analytiker som låter alla intressenter diskutera med varandra och det du gör är bara att agera mötesledare, medlare och stöttepelare för intressenterna.
Checkland har definierat fyra tekniker för hur modellerna kan jämföras mot verkligheten, nämligen question definition, scenario construction, general discussion och model overlay. Den vanligaste tekniken är Question definition där alla aktiviteter i modellen jämförs med verkligheten för att se om de stämmer överens, och om man ska vidareutveckla dem. I Scenario construction så skapas olika scenarion utifrån tidigare händelser och applicerar dessa mot modellerna. General discussion är som det låter, helt vanlig generell och informell diskussion som kan förbättra jämförelserna. I model overlay så skapas en modell över verkligheten och läggs över den gamla modellen för att se hur väl dessa två stämmer överens. I det stora hela så går denna fas ut på att skapa debatt mellan alla intressenter och i slutändan komma fram till ett resultat alla är mer eller mindre nöjda med.
Till sist så har man kommit fram till den sista fasen, då de förändringar/förbättringar som parterna kommit överrens om genomförs. Arbetet ska dock inte ses som slutfört här, implementationen kan medföra nya komplexa problem. SSM är snarare en kontinuerlig process utan slut, än en punktlista med en tydlig början och ett tydligt slut.
Lästips: Checkland, P. (2000). Soft systems methodology: A 30-year retrospective. Systems Research and Behavioral Science 17 (S1): S11-S58.
Tack till Johan Jonsson för vissa bitar av texten.
SSM skapades av Peter Checkland under 60-talet när han arbetade på det brittiska Lancaster universitetet. När han försökte applicera dåtidens systemtänkande (SE/SA) på problemområden så som företagsmanagement insåg Checkland och hans kollegor snabbt att det inte var möjligt. SE/SA fungerade inte för ostrukturerade och multifacetterade problem med många mänskliga variabler. Systems Engineering kräver nästan att man känner till problemet och systemet är tydligt avgränsat. Men i de fall som gruppen arbetade med insåg de att det var svårt att ge det undersökta systemet tydliga gränser och hitta en tydlig uppgift som systemet skulle arbeta med. De fick lov att acceptera att i mänskliga situationer så strävar olika individer efter olika saker
De började skissa på en helt ny metodologi där de baserade sitt arbete på aktionsforskning, vilket innebär att istället för att endast undersöka och se på problemet utifrån, så ger personen som undersöker organisationen sig själv in arbetet och försöker åstadkomma en förändring eller förbättring rent praktiskt, för att lära sig hur det fungerar. De ansåg att på ett högre plan så var varje situation de hittade sig själv i en mänsklig situation, där varje individ försöker agera på ett sätt som är meningsfullt för dem själva.
Efter att ha under en tid använt SSM i praktiken så kom Checkland fram till att de sju steg som då ingick i SSM sällan följdes och bestämde sig då för att göra metodologin flexiblare och mer generaliserad. Checkland såg att det fanns fler faktorer än bara de logiska, t.ex. saker som företagskultur och politik, som kunde ha inverkan på verksamheten. Till slut så kom de fram till det SSM som förespråkas idag..
De fyra faser som SSM idag består av heter följande på engelska: Finding out, Modelling, Comparison and Debate, Take action. Fritt översatt till svenska betyder de: Ta reda på, modellera, jämför och debattera, ta aktion.
Den första fasen i SSM, Finding out, delas upp i två delar, en logisk analys och en kulturell analys. I och med att tyngdpunkten i SSM är den mänskliga faktorn så ligger tyngdpunkten här på den kulturella analysen. Den kulturella analysen kan delas upp i ännu mindre delar, nämligen en rollanalys, en social analys och en politisk analys. Kallas även för analys ett, analys två och analys tre.
I analys ett så undersöks alla de roller som finns i situationen. Att känna till vem/vilka som är klienter, problemägare och problemlösare är mycket relevant i arbetet längre fram. Klienterna är de som satt igång det hela, de som varit missnöjda med hur saker och ting varit tidigare. Problemlösare är de människor som ska förbättra situationen, det är problemlösarna som är drivkraften i projektet. Och slutligen, problemlösarna är de som måste intervjuas för att få en så bra bild av problemsituationen som möjligt. Det är problemlösarna som avgör vilka som är problemägarna .
Analys två och tre hanterar de mer outtalade aspekterna som berör problemsituationen, det kan vara normer, värderingar, sociala roller och politiskt klimat. Svårigheter kan uppstå i sökandet efter information om detta, då det är oftast mycket svårt för människor att sätta ord på saker som normer och värderingar, ibland känner individerna inte ens till vad de har för normer och värderingar. Det innebär att det inte går att fråga människor om dessa saker, personen som analyserar tvingas helt enkelt observera situationen och försöka reda ut själv vilka roller, normer och värderingar som finns i problemsituationen.
Efter att både den kulturella och logiska analysen slutförts så tas det fram en bild på situationen, en sk. rik bild. Att rita bilder för att förtydliga de olika element som finns i en mänsklig situation är något som varit karakteristiskt för SSM sedan första början. Checkland menar att bilder är bra för att förtydliga att problemsituationen är en helhet och inte endast en mängd delar. Dessa rika bilder är ovärderliga för att ha som grund vid en diskussion.
När den rika bilden av situationen är färdig, så är det dags att börja modellera, dvs. fas två. Det finns 3 olika verktyg som kan användas vid modelleringsarbetet: CATWOE, rotdefinition och en konceptuell modell.
CATWOE står för Customers, Actors, Transformation, Weltanschauung, Owner, Enviromental constraints. Weltanschauung är den världsuppfattning som gör transformationen meningsfull. Vid Transformation fasen bör man tänka på 3E modellen som består av tre relevanta kriterier, nämligen Efficacy, Efficiency och Effectiveness.
Rotdefinition är en förkortad beskrivning av de grundläggande aspekterna hos systemet. Den konceptuella modellen består av det minimum av aktiviteter som behövs för att utföra den transformation som organisationen vill åstadkomma.
PQR är en översiktlig beskrivning. P står för vad ett system skall göra, Q hur det skall göras och R varför det skall göras.
Genom att jämföra modellerna med verkligheten så är det möjligt att vid en diskussion få fram deltagarnas motsatta åsikter på ett sätt som annars inte vore möjlig. I denna fas är det du som analytiker som låter alla intressenter diskutera med varandra och det du gör är bara att agera mötesledare, medlare och stöttepelare för intressenterna.
Checkland har definierat fyra tekniker för hur modellerna kan jämföras mot verkligheten, nämligen question definition, scenario construction, general discussion och model overlay. Den vanligaste tekniken är Question definition där alla aktiviteter i modellen jämförs med verkligheten för att se om de stämmer överens, och om man ska vidareutveckla dem. I Scenario construction så skapas olika scenarion utifrån tidigare händelser och applicerar dessa mot modellerna. General discussion är som det låter, helt vanlig generell och informell diskussion som kan förbättra jämförelserna. I model overlay så skapas en modell över verkligheten och läggs över den gamla modellen för att se hur väl dessa två stämmer överens. I det stora hela så går denna fas ut på att skapa debatt mellan alla intressenter och i slutändan komma fram till ett resultat alla är mer eller mindre nöjda med.
Till sist så har man kommit fram till den sista fasen, då de förändringar/förbättringar som parterna kommit överrens om genomförs. Arbetet ska dock inte ses som slutfört här, implementationen kan medföra nya komplexa problem. SSM är snarare en kontinuerlig process utan slut, än en punktlista med en tydlig början och ett tydligt slut.
Lästips: Checkland, P. (2000). Soft systems methodology: A 30-year retrospective. Systems Research and Behavioral Science 17 (S1): S11-S58.
Tack till Johan Jonsson för vissa bitar av texten.
torsdag, maj 25, 2006
NullPointerException in Java
This the same post as below that is in Swedish, but in English instead. I thought I might aswell translate that post in case someone googles on this problem.
I thought I'd share some insights I've made during the time I was making a small app for a class I'm taking at the moment, consering error messages in Java.
Java doesn't always have the best messages (not that any language really does) but this one can be a bit tricky to understand if you are a newbie.
The one I'm talking about is the NullPointerException error. Most newbies have heard people say that Java doesn't have pointers, which makes this one even harder to understand.
Java DOES have pointers, it's just that you don't have to deal with them yourself.
What NullPointerException really means, is that you are trying to use an object, that doesn't exist. You have a reference to null.
That can happen in all sorts of situations (f.ex getText() that returns this if the textbox is empty), but the one that I belive to be the most common is the one I'll talk about in this point.
What it all boils down to, really, is scope. Combine that with an easily made typo and you can find yourself in a real hassle that can be quite painful to debug if you don't understand what this NullPointerException even means.
Look at the following code example:
public class MyClass {
private SecondClass classtwo;
public MyClass() {
// Notice the error on the row below
SecondClass classtwo = new SecondClass();
}
private void Thingy() {
classtwo.changeto(42);
}
}
As you can see, I first declare a reference to an object, that I call classtwo. But I haven't yet made such an object.
The problem comes when I in the constructor, I do it again. But this time I create the object also.
But, because it's made inside a method, the scope of that object is only inside that method.
The Thingy() method later on, only sees the first classtwo reference, which leads to nothing == NullPointerException.
The right way would have been to do 'classtwo = new SecondClass()' in the constructor. Then the both methods would have been talking about the same object.
Another problem could be that I forgot the "new SecondClass()" part, ie. create the object. A class is not an object, and you should never confuse the two.
This is something you should keep in mind. Creating a reference to an object is not the same as creating the object. And you CAN have several objects with the same name. In that case, it's all about scope.
Now mix this with static and non-static methods/variables, and it can be quite cumbersome to grasp when you are new to the object oriented way of thought.
Disclaimer:
English is not my mother-tongue, I have only been programming Java for a month so I am not in any way an expert.
The terminology might be off, I might not even know what the h*ll im talking about. But this might help someone, so why not.
onsdag, maj 24, 2006
NullPointerException i Java
Tänkte dela med mig av en sak jag bråkade med ett tag, när jag höll på och arbeta med en inlämningsuppgift.
Java har inte så himla bra felmeddelanden alltid, inte för att andra språk har det heller, men man kan bli lite ställd ibland.
Somliga säger t ex att java inte har pekare, vilket inte är sant, det är bara så att du inte behöver hantera dem själv.
Angående NullPointerException error, så betyder det att du har försökt använda en referens som inte pekar till någonting. Det kan hända i alla möjliga slags situationer, men jag tänkte skriva om den vanligaste (och den jag fick bråka med).
Det hela handlar egentligen om "scope", och ett skrivfel som är mycket lätt hänt.
Se på följande kodexempel:
Misstaget här, handlar om att jag först definerar ett objekt som heter klasstva, men instansierar inte det, alltså att minne inte är reserverat för objektet ännu.
Det handlar bara om att meddela metoderna längre ner om att det finns ett sådant objekt.
Men när jag sen i constructen skriver 'AndraKlassen klasstva', då kommer jag göra samma sak en gång till, samt instansiera objektet.
Det innebär att jag har två objekt med samma namn, det ena instansierat och det ena tomt (null).
När metoden längre ner sedan försöker använda objektet, vilket ser det? Det instansierade eller det tomma?
Det tomma givetvis, eftersom den i en metod syns bara inom metoden. Och den var tom == NullPointerException.
Dethär är någonting som tål att tänkas på. Vilka objekt syns var, vilka variabler syns var. Blanda sedan ännu in static och non-static metoder och variabler, så blir det en riktig härva i huvudet om man är ny på dethär med objektorienterat.
Iaf för mig. ;-)
[edit:]
Felet heter "NullPointerException"! Borde ha kollat upp det först, minnet svek mig där.
Java har inte så himla bra felmeddelanden alltid, inte för att andra språk har det heller, men man kan bli lite ställd ibland.
Somliga säger t ex att java inte har pekare, vilket inte är sant, det är bara så att du inte behöver hantera dem själv.
Angående NullPointerException error, så betyder det att du har försökt använda en referens som inte pekar till någonting. Det kan hända i alla möjliga slags situationer, men jag tänkte skriva om den vanligaste (och den jag fick bråka med).
Det hela handlar egentligen om "scope", och ett skrivfel som är mycket lätt hänt.
Se på följande kodexempel:
public class MinKlass {
private AndraKlassen klasstva;
public MinKlass() {
// Notera misstaget här
AndraKlassen klasstva = new AndraKlassen();
}
private void AndraEnGrej() {
klasstva.fixalite(21);
}
}
Misstaget här, handlar om att jag först definerar ett objekt som heter klasstva, men instansierar inte det, alltså att minne inte är reserverat för objektet ännu.
Det handlar bara om att meddela metoderna längre ner om att det finns ett sådant objekt.
Men när jag sen i constructen skriver 'AndraKlassen klasstva', då kommer jag göra samma sak en gång till, samt instansiera objektet.
Det innebär att jag har två objekt med samma namn, det ena instansierat och det ena tomt (null).
När metoden längre ner sedan försöker använda objektet, vilket ser det? Det instansierade eller det tomma?
Det tomma givetvis, eftersom den i en metod syns bara inom metoden. Och den var tom == NullPointerException.
Dethär är någonting som tål att tänkas på. Vilka objekt syns var, vilka variabler syns var. Blanda sedan ännu in static och non-static metoder och variabler, så blir det en riktig härva i huvudet om man är ny på dethär med objektorienterat.
Iaf för mig. ;-)
[edit:]
Felet heter "NullPointerException"! Borde ha kollat upp det först, minnet svek mig där.
tisdag, maj 23, 2006
Varför systemvetenskap?
Tänkte ta en repost här från min andra blogg, en grej som jag skrev några månader sedan om varför jag valde att börja på det systemvetenskapliga programmet. (Med vissa förbättringar/små ändringar).
Vi har väldigt få elever just nu, så programmet behöver all reklam de kan få. Så jag försöker göra min del för att förbättra det, kan man väl säga (somsagt).
Tycker Ackoff sammanfattade det hela väl i en enda mening, i sin bok Re-creating the Corporation.
"...System sciences, which focuses on ways of dissolving problems and messes." -- Ackoff, 1999
Problemlösning med andra ord, på ett sätt som inte fokuserar på individuella detaljer. Holistiskt tänkande, eller med andra ord, ett helhetstänkande, är något som är en nyckelpunkt.
Ifall man t ex har en stad där det tar väldigt lång tid att ta sig från punkt A till punkt B med en bil, då kanske nån smart människa kommer på att vi måste bygga snabbare bilar.
Har man då löst problemet? Troligtvis inte, kanske det är infrastrukturen det är fel på. Kanske nån miljöaktivist kommer på att personbilar ska bli förbjudna på den vägen istället, alla måste använda bussar och tåg. Har man då löst problemet? Nej, inte egentligen, man har istället ändrat villkoren för transportationen. (Exemplet taget från Re-creating the Corporation, och handlade om Mexico City om jag minns rätt)
Sånt kan man ju fundera på ad nauseam. Det är egentligen tjusningen med ämnet, som jag ser det. En filosofisk aspekt till problemlösning, som inte fokuserar på tekniska detaljer lika mycket. Men inte bara filosofiskt, den tekniska aspekten kan finnas där, om du tycker det. Det är väldigt brett, från rena teknikproblemlösandet till filosofiskt funderande kring hur problemlösande bör ske.
Sen jag började grundskolan har jag alltid känt att jag har väldigt lätt för att lära mig saker, så länge som vissa villkor fullföljs. Uppgiften måste kännas som ett problem av något slag, och jag måste känna att det finns en mening med att lösa problemet, en viss relevans mao. Ställs jag inför ett problem som jag ska lösa så känner jag nästan ett slags rus.
"Nu jävlar ska jag lösa dethär snabbt och smidigt" ungefär.
Som sidonotering kan det ju nämnas att när det sen kom till gymnasiematte, där det var så abstrakt och kändes väldigt meningslöst just där och då, då orkade jag inte engagera mig alls. Man ställs inför några siffror som ska beräknas utifrån befintliga regler för att få ett slutresultat som består av mer siffror. Det kändes inte som ett problem, det kändes inte applicerbart mot någonting.
Det kändes om att man ska endast memorisera räkneregler och formler för att kunna få fram en abstrakt slutprodukt, och hela uppgiften fanns till för att pränta in dessa räkneregler.
Totalt ointressant, vilket sen gjorde att jag fortfarande inte tycker om att räkna matte. Det gick bra så länge det handlade om äpplen som skulle räknas eller kossans hage som skulle mätas.
Den känslan har jag inte haft sen jag började på här på högskolan. Även fast ämnena kan vara väldigt abstrakta och flummiga, och man ibland ifrågasätter motiven för att lära sig vissa saker och ting, så kan man ändå ta de individuella uppgifterna som problem som ska lösas. Och på vägen får man de verktyg som behövs för framtida problemlösning i organisationer. Det känns intressant i det stora hela samtidigt som jag uppgifterna ibland är såpass intressanta och stimulerande att jag tar egna initiativ till att lära mig mer än som krävs för just den uppgiften.
En till sak som vi stött på i utbildningen som jag finner fascinerande är något som heter Cybernetik.
En grundprincip i cybernetiken förklaras väl av följande citat, av Ashby.
"Cybernetics .. treats, not things but ways of behaving." -- Ashby, 1956
Alltså att man inte fokuserar på människor och andra ting, utan beteende och funktioner.
Och som vi alla vet så är våra medmänniskor jobbiga, som Jean-Paul Sarte så väl konstaterade.
"Hell is other people." -- Sarte, 1944
Visst låter det intressant? ;-)
Vi har väldigt få elever just nu, så programmet behöver all reklam de kan få. Så jag försöker göra min del för att förbättra det, kan man väl säga (somsagt).
Tycker Ackoff sammanfattade det hela väl i en enda mening, i sin bok Re-creating the Corporation.
"...System sciences, which focuses on ways of dissolving problems and messes." -- Ackoff, 1999
Problemlösning med andra ord, på ett sätt som inte fokuserar på individuella detaljer. Holistiskt tänkande, eller med andra ord, ett helhetstänkande, är något som är en nyckelpunkt.
Ifall man t ex har en stad där det tar väldigt lång tid att ta sig från punkt A till punkt B med en bil, då kanske nån smart människa kommer på att vi måste bygga snabbare bilar.
Har man då löst problemet? Troligtvis inte, kanske det är infrastrukturen det är fel på. Kanske nån miljöaktivist kommer på att personbilar ska bli förbjudna på den vägen istället, alla måste använda bussar och tåg. Har man då löst problemet? Nej, inte egentligen, man har istället ändrat villkoren för transportationen. (Exemplet taget från Re-creating the Corporation, och handlade om Mexico City om jag minns rätt)
Sånt kan man ju fundera på ad nauseam. Det är egentligen tjusningen med ämnet, som jag ser det. En filosofisk aspekt till problemlösning, som inte fokuserar på tekniska detaljer lika mycket. Men inte bara filosofiskt, den tekniska aspekten kan finnas där, om du tycker det. Det är väldigt brett, från rena teknikproblemlösandet till filosofiskt funderande kring hur problemlösande bör ske.
Sen jag började grundskolan har jag alltid känt att jag har väldigt lätt för att lära mig saker, så länge som vissa villkor fullföljs. Uppgiften måste kännas som ett problem av något slag, och jag måste känna att det finns en mening med att lösa problemet, en viss relevans mao. Ställs jag inför ett problem som jag ska lösa så känner jag nästan ett slags rus.
"Nu jävlar ska jag lösa dethär snabbt och smidigt" ungefär.
Som sidonotering kan det ju nämnas att när det sen kom till gymnasiematte, där det var så abstrakt och kändes väldigt meningslöst just där och då, då orkade jag inte engagera mig alls. Man ställs inför några siffror som ska beräknas utifrån befintliga regler för att få ett slutresultat som består av mer siffror. Det kändes inte som ett problem, det kändes inte applicerbart mot någonting.
Det kändes om att man ska endast memorisera räkneregler och formler för att kunna få fram en abstrakt slutprodukt, och hela uppgiften fanns till för att pränta in dessa räkneregler.
Totalt ointressant, vilket sen gjorde att jag fortfarande inte tycker om att räkna matte. Det gick bra så länge det handlade om äpplen som skulle räknas eller kossans hage som skulle mätas.
Den känslan har jag inte haft sen jag började på här på högskolan. Även fast ämnena kan vara väldigt abstrakta och flummiga, och man ibland ifrågasätter motiven för att lära sig vissa saker och ting, så kan man ändå ta de individuella uppgifterna som problem som ska lösas. Och på vägen får man de verktyg som behövs för framtida problemlösning i organisationer. Det känns intressant i det stora hela samtidigt som jag uppgifterna ibland är såpass intressanta och stimulerande att jag tar egna initiativ till att lära mig mer än som krävs för just den uppgiften.
En till sak som vi stött på i utbildningen som jag finner fascinerande är något som heter Cybernetik.
En grundprincip i cybernetiken förklaras väl av följande citat, av Ashby.
"Cybernetics .. treats, not things but ways of behaving." -- Ashby, 1956
Alltså att man inte fokuserar på människor och andra ting, utan beteende och funktioner.
Och som vi alla vet så är våra medmänniskor jobbiga, som Jean-Paul Sarte så väl konstaterade.
"Hell is other people." -- Sarte, 1944
Visst låter det intressant? ;-)
Första posten
Okej, så jag har startat en ny/en till blogg. Varför?
Anledningen är nämligen att jag har upptäckt under mitt första år som systemvetare att det finns mycket lite information om programmet och ämnet på svenska, i Sverige.
Det hela har fallit lite i skymundan tycker jag. Och det tänkte jag råda bot på, så gott jag kan.
Min tanke är att skriva lite lättlästa sammanfattningar om saker och ting som jag har läst om, och lägga upp här. Värt att upprepas dock, jag är student själv, så hoppas ingen börjar citera mig och använda bloggen som referens. Det går inge bra nämligen.
Men, somsagt, lättlästa sammanfattningar, lite funderingar om ämnet, nyheter om branchen, allt sådant som kan intressera en framtida/nybliven/erfaren systemvetare. Och jag siktar på att skita i (det börjar bra, eller hur?) det akademiska språket, för det är bara inbitna akademiker som tycker att "betalt per ord" är något som fungerar bra.
Nåja, vi får se hur jag kommer igång med dethär. Sommaren har både knackat på dörren och klivit in, vilket innebär att man inte längre har så mycket tid och ork till att sitta vid datorn och skriva en massa saker.
Jajustja, och vem är jag då? 22 årig student på LTU, läser Systemvetenskap somsagt, heter Henri i förnamn (finska föräldrar), mer information än så kanske inte är nödvändigt ännu?
Anledningen är nämligen att jag har upptäckt under mitt första år som systemvetare att det finns mycket lite information om programmet och ämnet på svenska, i Sverige.
Det hela har fallit lite i skymundan tycker jag. Och det tänkte jag råda bot på, så gott jag kan.
Min tanke är att skriva lite lättlästa sammanfattningar om saker och ting som jag har läst om, och lägga upp här. Värt att upprepas dock, jag är student själv, så hoppas ingen börjar citera mig och använda bloggen som referens. Det går inge bra nämligen.
Men, somsagt, lättlästa sammanfattningar, lite funderingar om ämnet, nyheter om branchen, allt sådant som kan intressera en framtida/nybliven/erfaren systemvetare. Och jag siktar på att skita i (det börjar bra, eller hur?) det akademiska språket, för det är bara inbitna akademiker som tycker att "betalt per ord" är något som fungerar bra.
Nåja, vi får se hur jag kommer igång med dethär. Sommaren har både knackat på dörren och klivit in, vilket innebär att man inte längre har så mycket tid och ork till att sitta vid datorn och skriva en massa saker.
Jajustja, och vem är jag då? 22 årig student på LTU, läser Systemvetenskap somsagt, heter Henri i förnamn (finska föräldrar), mer information än så kanske inte är nödvändigt ännu?
Prenumerera på:
Inlägg (Atom)