Nu är BOX Server i drift på http://www.fundament.se/box.php.
Ta gärna en titt. Logga in med användarnamn: test, lösenord: test, och lägg upp lite filer och så.
BOX Server är alltså just nu en hanterare för "box"-objekt. Ett "box"-objekt är en filkatalog som lagras på en webbserver, men där filerna inte kan kommas åt om man inte är inloggad som rätt person.
Sådärja! Nu har jag börjat installera mig på nya jobbet.
Jag har alltså krupit in under konsultkepsen ännu en gång, nu som konsult på IBS Konsult, närmare bestämt på den del av IBS Konsult som går under namnet JavaSolutions.
Och vad gör då vi?
Jo, till att börja med så är ju IBS en tillverkare och leverantör av affärssystem. Konsultbenet opererar dock oberoende av affärssystemet (även om vi naturligtvis kan det) med att leverera expertis till våra kunder, såsom:
Så det gör jag just nu. Kodar java. Objektorienterar. Utbildar i UML, RUP och agila metoder. Utforskar AS400/Java-integration.
Och har precis hur kul som helst!
Dags för lite kryptografi i Java igen. Det går så långt mellan varven nu att jag glömmer bort hur man gör :-/
Den här gången är det 3DES som ska implementeras.
Först skapar jag nyckeln (från 24 slumpmässiga bytes, från random.org), och de två chifferobjekten.
//the key, from 24 random bytes ("_keyData")
_key = SecretKeyFactory
.getInstance("TripleDES")
.generateSecret( new DESedeKeySpec( _keyData));
//the cipher objects for encryption and decryption
_encryptor = Cipher.getInstance( "TripleDES");
_encryptor.init( Cipher.ENCRYPT_MODE, _key);
_decryptor = Cipher.getInstance( "TripleDES");
_decryptor.init( Cipher.DECRYPT_MODE, _key);
Att kryptera och dekryptera är sedan lätt:
//encrypt a byte[] byte[] encryptedData = _encryptor.doFinal( cleartextData); //decrypt a byte[] byte[] decryptedData = _decryptor.doFinal( encryptedData); //cleartextData and encryptedData is now the same!
Det luriga ligger som vanligt i att försöka få tag i och installera en provider. Jag använder helst den helfria BouncyCastle här.
Men i detta fallet använder jag den medföljande implementationen av 3DES.
Algoritmnamnen ja... usch vad många gånger det har blivit fel. När man skrivit "3DES" istället för "TripleDES" till exempel.
Du vet Microsoft Passport? Skaffa ett konto hos Pyttemjuk, så funkar det på många sajter. OpenID är samma tänk, single sign-on osv, fast utan beroende av en enda drakonisk leverantör.
Jag har skaffat ett OpenID, på en webbplats som heter myopenid.com. Om OpenID-konsortiet försvinner, så gör det inget, mitt ID finns kvar. Om myopenid.com försvinner, så gör det inget, jag kan behålla mitt ID, fast får gå till en annan leverantör.
Ingen utom jag kontrollerar mitt OpenID! Det är det viktiga.
Hälsningar ola.berg.myopenid.com .
Jag misstänker att Mark Baker är en man som vet vad han talar om: nämligen webben som plattform. Läs och ta del!
Ljuvligt med semester. Bad tre gånger om dagen. Ingen skojprogrammering nästan. Förrän på slutet, då det blev regnigt. Och då hittade jag på följande: Dataöar i HTML. Alltså inte i XML i största allmänhet, utan i HTML.
Detta är en av tillämpningarna av mikroformat. Små, enkla dataformat som inte försöker sig på att vara mer än vad de är. microformats.org
Om man vill påstå eller garantera att ett visst XML-dokument följer ordningen i ett visst XML-schema, så kan man göra följande:
<?xml version="1.0" ?>
<mitt
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http//min.server.se/mitt.xsd" >
<fina>dokument</fina>
</mitt>
Sommarlovsteatern på P1 rockar i vanlig ordning. Nu senast har de kört en väldigt spännande och bra fantasypjäs som heter "Skämmerskans dotter". Som "skämmerska" har man gåvan/förbannelsen att i folks ögon se precis allt det som de skäms över. Lysande upplägg.
Men ack! Så har man missat några avsnitt. Som tur är finns pjäsen på webben. Men hur lösa det på landet, där inget bredband finns? Få över pjäsen på CD kanske?
Lite windowstips för den händige:
Högerklicka på länkarna, t ex första avsnittet "http://www.sr.se/p1/lovteatern/sounds/2006/sommar/1.skammerskans_dotter/1.ram" och spara filen (inte köra eller lyssna eller någonting sådant).
Öppna den här ".ram"-filen i en texteditor. Vad ser man? Aha, en URL!
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/1.rm
URL:en pekar på själva ljudfilen.
Nu behövs ett nedladdningsprogram som begriper sig på "rtsp"-protokollet (se i början på URL:en). Jag använder FlashGet.
Bara att mata in alla pjäsens URL:er:
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/1.rm rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/2.rm rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/3.rm rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/4.rm rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/5.rm rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/6.rm rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/7.rm rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/8.rm rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/9.rm rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/10.rm
Ut i solen och dricka kaffe, komma in igen: klart!
Nu kan man lyssna i RealMedia åtminstone. Men få över till CD då? Eller till mp3-spelaren?
Nästa steg är lite lurigare. Det finns nämligen zillioner betalprogram som konverterar rm till mp3. Svårt att hitta gratisprogrammen då!
Jag använder Free RM to MP3 Converter från jodix.com.
Efter ett par minuter har jag rm-filerna konverterade till mp3.
Sedan in i CD-brännaren med mp3-orna, bränn en CD, lyssna.
Jag älskar radioteatern!
(och ja, jag betalar min TV-licens, och nej, jag kopierar inte och sprider P1:s upphovsrättsskyddade material till andra. Vad jag gör är en konvertering till ett format som jag kan lyssna på, absolut fair use ur alla synvinklar).
Så här kan det se ut:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet href="test.xsl" type="text/xsl"?>
<mitt>
<fina>XML-dokument</fina>
</mitt>
Har ni sett den? Har ni provat den? Jag talar om min nya kärlek: XML-databasen eXist!
Vad det är? Joo...
Det är en server, skriven i Java.
Servern innehåller ett enda tomt XML-dokument. Men du kan ta alla dina XML-dokument och stoppa in i det där dokumentet. Och söka fram dem. Och göra omvandlingar med XSLT. Och allt annat XML-igt man gör nu för tiden.
Plus att du har användare och tillgänglighetskontroll (förstås). Jag kan ge dig rätt att läsa vissa delar av det stora XML-dokumentet, och ge dig rätt att skriva vissa delar, och jag kan förbjuda dig tillgång till andra delar.
Världen har väntat på en riktig XML-databas. Åååh vad många tillämpningar man velat skriva under åren, tillämpningar som hade behövt eXist. Tillämpningar som tvingats använda relationsdatabaser eller filsystem.
Alltså, förstå mig rätt. Jag ogillar XML-hajp. Jag gillar filsystem. Jag gillar relationsdatabaser. Men för vissa tillämpningar gör sig XML alldeles ypperligt.
Tack alla utvecklare bakom eXist. Jag känner att ni har gjort mitt liv lite enklare från och med nu.
Projektet som jag jobbar i går in i en ny fas efter semestrarna. Det har varit roligt och lärorikt, och jag har fått arbeta med väldigt intelligenta människor. Faktiskt både bland kolleger och beställare.
Men det är dags att söka sig något nytt. Jag saknar samarbetet (projektet är på väg mot förvaltning och det kommer att bli väldigt mycket ensamarbete), och jag saknar den affärsmässiga pulsen och tänket (det är ett universitetsprojekt).
Så om du känner någon som har behov av en väldigt erfaren och påhittig och kunnig systemutvecklare (med kraftig slagsida åt RUP och Java och serverprogrammering och webbtekniker) så hör av dig!
Mitt något censurerade CV kan du se här.
Mitt ocensurerade CV med alla kontaktmöjligheter kan du få se om du lämnar ett meddelande med svarsadress i kommentarsfältet nedan.
Ännu ett bevis för att mina predikningar om att skilja mellan stödtrupper (system som stöder din verksamhet och som dina konkurrenter har) och spjutspetsar (system som ger just din verksamhet en konkurrensfördel) inte är ett påhitt från mig lämnas oss av cio.idg.se.
Men du behöver inte lägga 50 spänn på en gräll PDF-artikel. Själva språket i blurben borde få dig att tveka. Hör bara: "ett nytt sätt att se på IT". Nytt? Tvärtom!
Det är ett gammalt och beprövat sätt. Och självklart (om man bara ser till att behandla IT som vilken annan investering som helst). Det sorgliga är att blurben har rätt på ett sätt: för många människor i ledande IT-ställning är sådana här självklarheter lika med nyheter. Men det beror mer på att dessa sitter och bestämmer över saker de inte begriper.
Undrar vad som hade hänt om samma tillsättningsprincip hade tillämpats på andra områden:
Ekonomichef! Använd dubbel bokföring med både debet och kredit. Det nya sättet att styra ekonomin!
Klinikchef! Nu behöver du inte hitta en ihålig ek på en kyrkogård att dra barnen igenom. Läs om det nya sättet att bota kikhosta på!
Politiker! Nu behöver du inte... vänta. Kanske ett dåligt exempel...
En kommentar på Slashdot, rörande Microsofts förhållande till fri mjukvara och Gnu Public Licens (GPL):
The GPL is like a nude beach. It's an agreement that you are no going to wear any clothes on this beach. Microsoft wants to hang out on that beach but not remove thier clothing. I can't blame them; but the sunbathers all know that Microsoft is just there to ogle.
Såååå klockrent!
Gå till
http://www.php.net/downloads.php.
Klicka på PHP 5.1.4 zip package. Nu får du välja varifrån du ska tanka hem. T ex från
se.php.net.
Skapa en mapp i C: som heter "PHP". Packa upp zip-filen i den mappen. Mappen C:\PHP ska alltså inte innehålla en mapp som heter "php" eller "php-5.1.4-Win32" eller någonting sådant, utan mappen C:\PHP ska innehålla mapparna dev, ext, extras, och PEAR, samt en massa andra filer.
Nu blir det lite hårigare. Gå till din Apachekatalogen
C:\Program Files\Apache Software Foundation\Apache2.2\. Du ska nu ändra i en konfigurationsfil.
Gå till katalogen conf och öppna filen httpd.conf i någon texteditor.
Sök fram en rad där det står "#LoadModule ssl_module modules/mod_ssl.so På raden under skriver du
LoadModule php5_module "c:/php/php5apache2_2.dll"
Sök fram en rad där det står "AddType application/x-gzip .gz .tgz". På raden under skriver du
AddType application/x-httpd-php .php
Sök fram en rad som börjar med "DocumentRoot ". På raden under skriver du:
PHPIniDir "C:/php"
Sök fram en rad som börjar med "DirectoryIndex index.html". Efter "index.html" skriver du "index.php".
Nu behöver du göra en liten grej i ditt PHP-bibliotek. Gå till C:\PHP. Har du filen "php.ini"? Om inte, namna om "php.ini-dist" till "php.ini". Har du filen "php5apache2_2.dll"? Om inte, öppna filen http://snaps.php.net/win32/php5.2-win32-latest.zip och kopiera den därifrån till C:\PHP.
Spara httpd.conf och klicka på den lilla Apacheikonen bredvid klockan (en liten röd fjäder på en vit boll med en grön pil). Välj "Restart".
Kopiera nedanstående text i en fil du kallar test.php och lägger i htdocs:
<? echo "Hejsan, världen!"; ?>
Nu kan du testa http://localhost/test.php. Om du ser "Hejsan, världen!" men inte "echo", så fungerar det.
Så här gör du för att installera Apache på din windowsburk (XP):
Ladda ner Apache, t ex från
http://apache.archive.sunet.se/dist/httpd/binaries/win32/.
Klicka på "apache_2.2.2-win32-x86-no_ssl.msi".
Dubbelklicka på den nyligen nedladdade MSI-filen.
I dialogen som kommer: klicka på "Next" hela tiden, eller "I accept". Detta ger dig en standardinstallation.
Har du en brandvägg på datorn kommer den kanske fråga dig om du vill att Apache ska vara åtkomlig på nätet. Det vill du förmodligen.
Avsluta installationsdialogen med att klicka på "Finish".
Nu har du förmodligen Apache installerat. Kör din webbläsare till adressen http://localhost. Får du upp ordet "It works!", så har du Apache
Om du gjort en standardinstallation så finns själva Apache-programmet
på C:\Program Files\Apache Software Foundation\Apache2.2.
Dina hemsidesdokument finns i katalogen "htdocs"
(C:\Program Files\Apache Software Foundation\Apache2.2\htdocs).
En smart grej är att göra en mjuklänk från din hemkatalog ("Mina Dokument" eller "My Documents" eller något).
Välj Start - My Documents / Mina Dokument. Högerklicka och välj "New - Shortcut / Nytt - Genväg". Du får fram en dialog
där du ska skriva in sökvägen C:\Program Files\Apache Software Foundation\Apache2.2\htdocs, eller bläddra fram
den.
Du får nu en genväg till dina hemsidesdokument. Genvägen ser ut som en mapp. Spara hemsidesdokumenten där.
Fick ett fint kedjebrev. Eller... javisst, det innehöll en del skrocksmörja om hemskheter som kan drabba en, och sådant är bara smörja.
Men resten av brevet var fint, och därför vill jag skicka det vidare till er:
Fina, enkla, och sanna insikter, som alltför ofta glöms bort. Sprid dem!
Tack, SuS, för dem!
Sådär, nu stängdes The Pirate Bay, och servrarna togs i beslag. För brott mot upphovsrättslagen. Utan att ha brutit mot upphovsrättslagen. Däremot tillhandahållit en kontaktförmedling mellan människor som vill byta filer. Och bland dessa människor (belägna någon helt annanstans än på det aktuella webbhotellet, och vars datorer inte tagits i beslag, märk väl) finns det förmodligen en och annan upphovsrättsbrottsling.
Nå, jag tycker att brott mot upphovsrättslagen ska bestraffas. Men agerandet igår är skandalöst. Ett par frågor:
Är det kontaktförmedlingens fel om två människor som fått kontakt via kontaktförmedlingen börjar bete sig brottsligt?
The Pirate Bay är en kontaktförmedling. Själva har de efter vad jag förstår inget upphovsrättsskyddat material på sina servrar.
Men jag undrar verkligen varför inte polisen griper brottslingarna? Vi som producerar upphovsrättsskyddat material har enligt lagen rättigheter förbundna med detta. Jag önskar verkligen se att brottslingar åker dit.
Istället lägger polisen resurser på att gripa helt andra personer. Hmm. Om knarklangare dyker upp i närheten av mina barns skola vill jag verkligen att polisen ska gripa dessa. Jag skulle bli vansinnig om polisen istället resonerade så här:
Hmm, låt se... knarklangare står på gatan... gatan använder asfalt... Jag vet! Vi åker till Gatubolaget och beslagtar alla asfaltskokare! Case closed!
Genier i arbete...
Att sprida upphovsrättsskyddat material är inte brottsligt. I så fall gör varje producent av upphovsrättsskyddat material sig till stora brottslingar dagligen. Att sprida upphovsrättsskyddat material utan upphovsrättsinnehavarens tillstånd är brottsligt.
Hur stor "collateral damage" (där tredje part drabbas) är ett samhälle villigt att acceptera? Om polisen har husrannsakningsorder på en lägenhet i ett flerfamiljshus, ger det dem rätt att raida alla lägenheter?
Svaret på min fråga är i någon mening "ja", polisen har långtgående befogenheter. I teorin skulle de kunna söka igenom alla bilar i ett P-hus om någon av bilarna misstänks innehålla en bomb. Men denna rätt (och skyldighet) har vi medborgare gett polisen, för att vi litar på att de kan hantera den rätten ansvarsfullt. Igår togs ett stort antal andra sajter ner. Däribland sådana som sysslar med politisk opinionsbildning.
I vanliga fall är polisen duktig på att skydda tredje part. I vanliga fall är polisen försiktig när det är grundlagsskyddade rättigheter som står på spel. Men nu verkar det juridiska förnuftet ha glömts bort på vägen.
Om ett internationellt brottssyndikat hyrde in sig på ett hotell, och polisen avsåg att gripa lite folk, hur brukar polisen göra:
Igår gjorde de det sistnämnda.
Grip skurkarna och sluta trakassera oskyldiga!
Ovanstående googling gav i sökande stund svaret "...matchade inte något dokument" (fast från och med i natt kommer väl detta inlägg upp kan jag tro :-/)
Men hursomhelst: det känns som om det börjar bli dags. Konkretisera yrkesrollen. Formulera branschetiken. Synliggöra nyttan. Få en stiff förkortning efter sitt namn: Ola Berg, Systemarkitekt SFSA
Håller ni med?
I en av de intressanta bloggarna på CIO.com, kom en kommentar upp. Inlägget handlade om när man kan säga att data mining (hitta tendenser utifrån en massa data) fungerar. Kontexten är amerikansk terroristbekämpning (vad annars?) men är tillämpbart överallt.
Ett tekniskt svar på frågan om det fungerade var: "Genom data mining har vi fått ner antalet misstänkta fall från 1 på tio miljoner till 1 på tio tusen." Kochs mer kontextuella invändning: "Men fortfarande gäller samma fråga: 'hur hantera en stor mängd falska positiver?'"
Och det är ju helt sant. Skillnaden med data mining är förvisso en tusenfaldigt större träffsäkerhet. Men det grundläggande problemet har man ju inte löst: hur skilja agnarna från vetet? eller snarare: hur undvika att skada allt detta vete i jakten på ett litet skräpagn? Vad man gör med data mining är att man minskar sökrymden för andra, mer träffsäkra men kostsammare metoder. Man underlättar för det andra steget. Men behovet av detta andra steg kvarstår: då man ska göra något intelligent med det man faktiskt funnit.
En insiktsfull läsare kommenterar:
[snip] ...any data mining solution succeeds or fails based on a) how the business logic is set up in the first place, and b) how "error conditions" are handled.
Man kan stryka "data mining" från ovanstående, uttalandet blir lika sant oavsett system och metod. Allt står och faller med att verksamhetslogiken i sig är bra, och logikens användbarhet beror till största delen på avvikelsehanteringen.
Aldrig blir det så tydligt som när man är i kravfångnings- eller verksamhetsmodelleringsläge och tar fram användningsfall. Ett enkelt jobb kan det tyckas, så länge som man bara beskriver huvudflödet i ett användningsfall. När man däremot kommer till avvikelserna, det är då det börjar bli lurigt. Det är då det går upp för verksamheten exakt på hur många sätt det kan skita sig. Och att verksamheten ofta inte tänkt igenom hur man hanterar dessa avvikelser.
Det är inte ovanligt att avvikelsebeskrivningarna upptar tio gånger så stor plats som huvudflödet. Och då kan man också räkna ut att det är i avvikelserna som ett system eller en process visar sin differentierande sida. Det är genom att jobba med dem som man kan skapa konkurrensfördelen.
Det går bara att baka kakor på ett begränsat antal sätt (för att återvända till bageriet i mitt bludder om mjukvaruekonomi tidigare). Men det går att hantera brända kakor, trasiga förpackningar, skiftande mjölkvalitet osv. osv. på hundratals olika sätt.
Så tänk till i det andra steget. Tänk över avvikelserna. Och tro aldrig att en teknisk lösning, hur bra den än är, gör att du slipper tänka över dina processer!
I avdelningen "Märkliga förväntningar" har turen nu kommit till
Jag ställer kraven, du programmerar lösningen.
Jovisst, det är sant att kraven ska komma från verksamheten. Det är verksamheten som ger intäkten och systemen ska stödja verksamheten.
Och jovisst, det är en utvecklingsavdelning som ska leverera lösningen. Det är deras jobb.
Men däremellan är det inte lika enkelt.
För det första: vad är skillnaden mellan krav och utveckling? Egentligen?
I den stund en tanke väckts på en förändring någonstans, så är utvecklingen igång. Så verksamheten utanför utvecklingsavdelningen är i någon mån utvecklare.
Och även om lösningen ska fungera i verksamheten, så ska den ju först och främst fungera. Vilket betyder att den inte enbart är underkastad verksamhetskrav, utan en hel dröse andra krav som har med IT-systemets egenskap av att vara IT-system att göra. Så utvecklarsidan är på samma sätt i någon mån kravställare.
Och då inträder den intressanta situationen att dessa krav gärna är i konflikt, att vi har en zon där muren mellan kravställare och utvecklare inte kan upprätthållas. Och konflikter måste som bekant lösas. Hur?
IT ska inte styra verksamheten. Verksamhetskraven har alltid prioritet över IT-sidans invändningar.
Ett klassiskt sätt att skjuta sig i foten, som mest avslöjar att man inte riktigt förstår sig på IT-sidans invändningar. Och därmed inte sin egen verksamhet heller. Från den stund man blandat in IT i verksamheten, är IT en del av verksamheten.
IT är verktyg, på samma sätt som telefonsamtal, grafiska manualer, säljkampanjer, fabriksgolv, logistikkedjor, you name it. Verktyg har egenskaper. Försöker man sig på att styra verktygsanvändning utan att förstå sig på hur dessa egenskaper påverkar siffrorna i årsredovisningen, går det vanligtvis åt pepparen. Säljkampanj utan kunskap om kundpsykologi, logistikplanering utan geografikunskaper, beslut om IT-stöd utan kunskap om informationshantering och tekniska begränsningar... Hejdå, vinst!
Så hur bör man göra då?
Jo:
För varje verksamhetskrav finns det hundra designer som kan lösa kravet. Varje design har egenskaper som kommer att påverka din verksamhet på det ena eller andra sättet.
Därför är det så viktigt att du skiljer mellan krav (som är din verksamhets problemformulering), och den lösning som du vill införa.
Så när någon säger:
Jag ställer kraven, du programmerar lösningen.
...så säger denne egentligen:
Jag ger dig bara en liten del av kraven, och jag bryr mig inte om vilken design du kommer upp med, och jag struntar fullständigt i hur din lösning kommer att påverka verksamheten i framtiden.
Och det tycker jag är ett märkligt sätt att förhålla sig till sin egen verksamhet.
Här finns ett exempel på grunkvärde i praktiken. Det är ett whitepaper som förklarar dåliga saker att göra om man har en applikationsserver. Nästan längst ner i dokumentet finns precis det slags IT-matematik som är så enkel och så viktig, men som så sällan görs (är det för enkelt?).
Räkneexemplet denna gång gäller vad nedtid kostar (=vad systemet är värt). Formeln i ett av fallen (en webbshop) lyder:
Antal transaktioner per timme x snittvärdet av varje transaktion).
I ett annat fall är det en affär som både har webbshop och vanlig butik. Systemets andel i processen är 50% (är systemet nere sker bara hälften av transaktionerna):
Antal transaktioner per timme x snittvärdet av varje transaktion x systemets andel
Folket på IBM använder dessa enkla formler för att visa hur dyrt det kan vara att fuska med kvaliteten. I pappret listas de elva vanligaste sätten att fuska med kvaliteten som de stött på när de besökt kunder som haft problem.
Samtliga fusk härrör från tagna affärsbeslut. Inget kan härröras till dåligt handhavande från den tekniska personalens sida. Inget beror på dålig programmering. Även de få fall i pappret där rena applikationsfel är källan till problemet, är det inget fusk från utvecklarnas sida. Allt ligger i investeringsbeslut rörande process, metodik, hårdvaruinköp, resurser avsatta till dokumentation. Investeraren bär ansvaret för investeringens ekonomi, ingen annan.
Tom Demarco (mannen som skrev "Peopleware", boken om människorna i systemutvecklingen) har även skrivit: "Slack : Getting Past Burnout, Busywork, and the Myth of Total Efficiency".
En bra bok som handlar om skillnaden mellan "busywork" och "business", och om hur letandet efter TotalEffektivitet(tm) inte är så effektivt alla gånger.
Egentligen är det inte så konstigt. Vill man vinna effektivitet genom att minska sina marginaler, sina buffertzoner, så blir resultatet välfungerande när det fungerar, men oerhört skört.
Man kan likna det vid bilkörning. Kör man fort, så minskar marginalerna. Tricket (som ju varje bilförare vet) är att dra på när man är på en gles motorväg i bra väder, men sakta ner när man kör i en korsning.
Ibland är verksamheten motorväg (målet är klart, alla rusar åt samma håll, det finns utrymme). Då ska vi dra på. Ibland är det korsningar (många andra trafikanter att hålla reda på, målet eller vägen dit är inte glasklar). Då ska vi hålla igen.
Mer klokskap. Denna gång är det Thomas Murphy som ger goda råd.
I korthet:
Klockrent från cio.com:
Here are smart people being paid major salaries making important business decisions. And they are flying blind when it comes to IT. Executives have figured out finance, marketing, mergers, manufacturing and so on. Time to add IT. It’s not that hard.
Exakt. Precis. Word. Just det.
Det är ju inte så svårt!
http://blogs.cio.com/whats-the-matter-with-business-executives
Låt oss låtsas att du har en IT-avdelning. Den kostar 10 miljoner om året. Men trots att den inte får direkt fler system att ta hand om, så levererar den sämre och sämre resultat, för lika mycket pengar.
Nu säger de som arbetar där att de går på knäna. Du tror dem inte riktigt, så du ber att få se vad de lägger sin tid på och ser att de förmodligen har rätt, de har alldeles förfärligt mycket att göra.
Nu räknar de ut att de skulle behöva öka sin budget med 5 miljoner kronor, till 15 miljoner om året. Ska du acceptera? Och hur blev allt så dyrt, plötsligt?
Vi kan beskriva situationen med följande diagram:
Detta är den förväntade nyttan av IT-avdelningens arbete. Vid nollpunkten, längst till vänster, ligger den i paritet med sin driftskostnad på 10 miljoner.
Men det här är den verkliga situationen. Kostnaden är densamma, men nyttan går ner över tid. Kraftigt ned till och med, om det får fortsätta:
Det som händer här är vad som skämtsamt brukar kallas för "bitröta", eller software rot
Bitrötan är på skoj (databitar ruttnar i allmänhet inte), men allt runtomkring systemet rör på sig. Hårdvara blir sämre, ny hårdvara kräver nya operativsystem som kanske har en lite annorlunda hantering av saker och ting, osv osv.
Men i allmänhet beror det på att själva verksamheten ställer något annorlunda krav nu än tidigare på samma system. Datamängder ökar, nya slags transaktioner ska in osv osv.
Även om man underhåller sina system och programmerar in ny funktionalitet, så kan en ursprunglig design eller arkitektur bara tänjas till en viss gräns. Till slut tar kostnaden för all handpåläggning osv ut sin rätt.
Denna ökade arbetsvolym är det gröna fältet nedan:
Det gäller alltså att vara förutseende, och inte anta att ett driftsatt system kräver lika mycket underhåll dag 1 som dag 700. Redan från början ska man planera in tid för en ordentlig översyn och omarbetning av systemet. Givet en "normal" förändringstakt i omgivningen, så är två år en bra tumregel. Men bara som tumregel, verligheten kan se annorlunda ut i dina omgivningar. Allt beror på hurpass robust designen var från början (hur väl man lyckades förutse vad som komma skulle), och hurpass oförändrad din verksamhet är.
Poängen är att alla ska vara medvetna om detta, redan från början. Och två år är ingen dum avskrivningstid. Skulle ditt system ha klarat sig väl på den tiden, så har du en stor fördel under omarbetningen, i det att du kommer att kunna återanvända såpass mycket. Att göra fel åt andra hållet däremot (förutsätta stabilitet över en femårsperiod, men tvingas till förändringar tidigare), är inte ekonomiskt.
Det handlar ju om att stipulera den tid som du ska räkna hem systemet på. Frågan är om man vågar lita på en tidsperiod som är längre än två år. Det är ju mycket som kan hända.
Nå, ska du stillatigande acceptera en ökning av driftsbudgeten med 5 miljoner? Kanske, men förmodligen inte. Inte innan du vet vad du får för pengarna.
Allt vad IT-avdelningen tar sig för är inte lika effektivt. Alla delsystem är inte lika illa däran. Vad du bör göra är att lämna den klumpvisa "IT-drift"-posten åt sitt öde. Den säger ingenting om hur väl spenderade enkronorna är. Istället ska du ta reda på vad det är för system (och tjänster) som du har i verksamheten, och ställa deras kostnader emot intäkterna, vart och ett för sig.
Förmodligen kommer du att behöva rucka på dina prioriteringar på köpet. Du kommer att se vad du betalar för. Du kommer att kunna rätta munnen (IT-behovet) efter matsäcken (IT-tjänsterna) på ett mycket bättre sätt. Och du kommer att frigöra resurser som kan ta itu med den långsiktiga förbättringen av din plattform.
Det är det som är business alignment. Din verksamhet ser över sitt IT-behov, och ändrar sina krav så att det verkliga IT-behovet blir uppfyllt.
Kanske kommer du att finna att 15 miljoner inte är en orealistisk IT-budget. Men du kommer att ha koll, inte bara på vart de nya fem miljoner kronorna går, utan vart alla femton miljoner går. Du skaffar dig koll, och det är bra att ha. Kanske har dina konkurrenter redan koll.
Jag var lite elak här. Det handlade om Bob Suh från Accenture som i Computer Sweden sade att väldigt många företag dröjer för länge med att uppdatera sina system.
Jag gav honom rätt, men hade inte mycket att ge dem som faktiskt redan satt sig själva i klistret, annat än dessa ord:
Verksamheten måste för det första fatta att det man betalar för nu är priset för gamla synder. Man valde en väg för två år sedan (eller tidigare) som kändes enkel, men som blundade för avskrivningstiden för systemet.
Så visst OK. Vi blundade för det. Vi får ta konsekvenserna. Men vad i hela friden gör vi nu, då?
Så som ett svar på den frågan följer här min punktlista för hur ni ska bära er åt:
Jag ägnade en del av söndagseftermiddagen för att fundera över varför jag irriterar mig så mycket på http://cio.idg.se.
Jag tror jag har det nu: jag irriterar mig eftersom jag förväntar mig att det ska finnas en svenskspråkig tidning som behandlar:
Det närmaste som råkade komma upp i min väg var http://cio.idg.se, och den motsvarade inte mina förväntningar (vilket naturligtvis inte är IDG:s fel).
Det andra skälet är att jag ogillar den är att den har en kraftig slagsida åt tekniska lösningar på verksamhetsproblem. Till skillnad från den engelskspråkliga varianten som ju mer fokuserar på verksamhetsproblem och deras lösning (inklusive metod- och organisationsfrågor).
Därigenom uppfyller den svenskspråkliga utgåvan inte sitt motto: "Länken mellan IT och affärer", utan känns mer som ett reklamblad från den lokala handlaren (just nu specialpris på morötter!).
Den trivialiserar hela frågan, helt enkelt. Och det är inte bra.
Jag har ävensom placerat in denna blogg på http://bloggkartan.se/registrera/7129/goeteborg/
Nuförti'n ska webbapplikationer kodas med Asynkron Xml å Avancerad Javascript (sk AJAX). För att sprida användingen av denna webbteknik har eliten av världens reklambyråer tävlat om att ta fram kampanjmaterial.
Helt oväntat vanns tävlingen av en fotograf i Skövde:
Se där ett mantra som hörs titt som tätt. Men vad menas?
Ofta verkar det som om det är en obehagskänsla man vill besvärja. Ett obehag över det faktum att IT faktiskt styr över den egna verksamheten.
Mantrat är för övrigt alldeles sant. IT ska inte styra. IT vill inte styra. IT har i sig själv ingen riktning (annat än att ett visst slags IT-lösningar är enklare att genomföra än andra, vilket leder till en tonvikt för just dessa lösningar).
Men jag har ännu inte träffat en IT-människa som inget högre önskat än att deras system är i samklang med verksamheten, att deras system skapar affärsnytta, att deras system får lov att följa verksamhetens fastslagna strategi. Den dröm om "business alignment" av IT, som så många "business"-människor drömmer, den drömmen delas av varenda IT-människa, åtminstone som jag någonsin träffat.
Ändå beskylls ofta IT för att just styra över verksamheten. Driva sin egen agenda. Förmodligen för att "business"-människan alltför många gånger har haft en affärsvision, och sedan upptäckt att gjorda IT-investeringar ligger som feta hinder i vägen för dem. Då styr IT över deras affärer.
Men vänta, vaddå "styr"? Det finns ju ingen inneboende vilja hos de gjorda investeringarna att lägga hinder i vägen. Inte heller någon ond programmerare som avsiktligt driver igenom sin egen affärsstrategi för att hindra "business"-människan.
Det verkar finnas ett tankefel här. I vilken mening "styr" IT?
Tankefelet uppenbarar sig i stycket strax härovan. I orden "och sedan upptäckt att gjorda IT-investeringar..." Varför kom det som en överraskning, kan man ju fråga sig.
"Business alignment", alltså när IT följer och stödjer verksamhetens strategiska mål, sker när "the Business" faktiskt "aligns" IT. Vem är t ex ansvarig för de gjorda investeringarna? Varför ser dessa ut som de gör?
Jo, alltid för att "the Business" då, när de gjordes, tyckte det var en bra tanke. Fattade beslut utan att riktigt inse vidden av det. Eller undvek att fatta beslut (kanske vanligare), eftersom man inte kunde se då hur det skulle komma att påverka en senare.
Det finns en massa olika anläggningstillgångar som på liknande sätt styr affärsstrategierna. Beslutet att lägga lagret i Långtbortistan gav låga löneomkostnader, men höga fraktkostnader. Beslutet att satsa på plastförpackningsmaskinen gör det lite lurigt när marknaden tycker att plåtburkar är skojigare.
Skillnaden är att när det gäller logistik, så är affärsmän hyfsat välutbildade. Och när det gäller maskiner så finns det folk som kan lagom mycket om både maskiner och marknad för att inse de marknadsmässiga aspekterna av plast och plåt.
Men när det gäller IT är kunskapen på många ställen ofattbart låg. Man vill inte heller behöva skaffa sig den nödvändiga kunskapen (och jag talar inte om konsten att programmera, eller att använda PowerPoint, jag talar om IT-kunskap). Nä, varför ska man behöva skaffa sig kunskap om IT, "IT ska ju inte styra över affären"
Fel tänkt. Antingen är du ett offer för omständigheterna, eller så skaffar du dig ett grepp om omständigheterna. Antingen styr verksamheten över IT, eller så "styr" IT din verksamhet. Antingen driver du för vinden, eller så lär du dig segla.
Skaffa kunskap (den behöver inte läras, den kan även anställas eller på annat sätt hyras in), och handla i enlighet med denna kunskap. Då äger du IT och hela affären. Annars blir du ägd.
Som ett brev på posten, eller åtminstone som en tidning, kom Pravda, förlåt Computer Sweden, med en liten artikel som illustrerar grunkvärde och mjukvaruekonomin.
Det är Accenture som gjort en liten undersökning hur mycket gamla system kostar.
Några citat från teknikstrategen Bob Suh:
Många företag vet hur många it-anställda de har, men vet inte vad de lägger tiden på.
Precis. Och läsare av denna blogg vet precis vad det beror på, nämligen att man heltokigt budgeterar efter antal anställda, och inte efter vilka system/tjänster/grunkor som verksamheten vill ha.
Lösning: Grunkbudget först, sedan kan man börja tänka på hur mycket folk som behövs.
Som man ropar får man nämligen svar. Frågar slanträknarna inte efter vilka grunkor (produkter och tjänster) som IT-avdelningen levererar, så förblir IT-avdelningens arbetstid ett töcken. IT-strategin faller redan redan innan den lämnat ekonomiavdelningen, långt innan den nått utvecklarrummet.
Mer visdomar från Accenture:
Mycket resurser läggs på dokumentation, men lite energi läggs på att se till att systemen verkligen stöder nya affärer.
Förutom att det inte alls är ovanligt att inte alls mycket tid läggs på dokumentation (den går åt till att släcka bränder i gamla skrotfärdiga datasystem i stället), så är det rätt.
Att se till att systemen stöder nya affärer, det börjar man med redan under utvecklingen. Redan i början av utvecklingen. Redan i början av inceptionsfasen (fasen i utvecklingen där man ska börja fatta vad det är man överhuvudtaget ska göra). Och sedan fortsätter man med det. Affären, the Business Case, måste vara drivande i utvecklingen. Det är de dyrbara problemen som ska fixas, annars blir lösningarna inte lönsamma. Och ansvaret för att projektet löser de dyrbara problemen vilar främst på projektets sponsorer och på projektet. Gemensamt. Och projektet är inte liktydigt med utvecklarna, utan däri ingår även beställarna.
Lösning: en projekt- och utvecklingsmetod som från början är inriktad på lönsamhet. Till exempel RUP. Och den metoden börjar och slutar inte i utvecklarrummet. Den börjar långt tidigare, och fortsätter under systemet livslängd.
Företag med gamla system lägger ned för mycket tid på att fixa dem. De är i en loop där de inte kan investera i nya system, medan de som frigjort resurser för att investera i nytt har färre problem och lättare att dra nytta av de fördelar som systemen ger.
Lösning: Verksamheten måste för det första fatta att det man betalar för nu är priset för gamla synder. Man valde en väg för två år sedan (eller tidigare) som kändes enkel, men som blundade för avskrivningstiden för systemet.
Om man utvecklar system som ska vara lönsamma, då måste man beräkna kostnaden för systemet. Och kostnaden är hela kostnaden, under hela systemets livslängd. Och då måste man från början ha bestämt sig för hur stor livslängd systemet ska ha. Och systemets livslängd beror inte på systemet i sig självt, utan systemet satt i sin omgivning (dvs verksamheten). Och om verksamheten förändras tillräckligt på, låt säga två år (vilket inte är ovanligt), så är systemets livslängd tjugofyra månader, no more no less.
Försöker man fuska och säga: "Äh, vi räknar på tre år istället", då har man förbundit sig att inte förändra sin verksamhet så mycket under dessa tre år. Visst, kan man stå för det så är det OK. Men vill du om två år vara bakbunden av att nya affärer hindras pga gamla system? Vill du kasta in dina IT-resurser i precis den dyrbara hantering som artikeln talar om (handpåläggning, brandsläckning, fix och jox), och aldrig få tid för att utveckla vare sig affär eller system?
Det är ditt val. Men skyll inte på någon annan om du hamnar i träsket. Skyll i synnerhet inte på IT-avdelningen för att du själv glömt matematiken.
Så länge det finns ett gap mellan dem som använder tekniken bra och de som gör det dåligt, kommer it att spela roll, säger Bob Suh.
Välj rätt.
Med all respekt för ert val att läsa dessa mina usla rader, så vill jag ändå drista mig att påpeka att mina tankar blott är flugskitar i jämförelse med vad andra, långt klokare personer, tänkt.
Här finns en artikel om SOA som är helt och hållet sann. Läs och begrunda. Möjligen att jag skulle vilja lyfta fram "Challenge 4: Apply SOA Principles to Your Data Too" något mer än vad artikeln gör.
Ett kedjebrev har börjat dyka upp i världen. Ett bra kedjebrev, här i Sverige sponsrat av självaste sosalarm.se (a k a ett-ett-två). Det går ut på att i sin mobiltelefon lägga in kontakten "ICE" (InCaseofEmergency) med det nummer som man vill att folk ska ringa om det hänt en något. Genial idé som härmed vidarebefordras. Sprid den till alla ni känner!
Vad man gör om man känner någon som faktiskt heter ICE (nån hip-hop-musiker t ex), förtäljer dock inte brevet.
Hej!
Ett snabbt sätt för räddnings/sjukvårdspersonal att i händelse av olyckshändelse/akut sjukdom komma i kontakt med anhöriga är att söka i den nödställdes telefonbok.
I takt med att telefonböckerna ökar i omfång, blir det allt svårare för räddningspersonalen att snabbt finna rätt nummer. För att underlätta sökningen föreslog en frustrerad ambulanssjukvårdare i Storbritannien följande enkla lösning: lägg in nummer till närmast anhörig i mobiltelefonen under rubriken ICE (In Case of Emergency).
Förslaget håller nu på att bli standard genom att det snabbt sprider sig över världen.
Anders Klarström, presstalesman på SOS Alarm: "Om du hittas akut sjuk eller skadad kan ett telefonnummer medbokstavskombination ICE i din mobils telefonbok få avgörande betydelse."
ICE står för In case of emergency. Idén kommer från en ambulanssjukvårdare vid East Anglian Ambulance, som tröttnat på att leta efter anhörigas telefonnummer. I telefonboken i sin mobiltelefon lägger man in kontaktpersonen "ICE" och numret till någon nära anhörig som behöver nås när man själv råkat ut för något och inte är kontaktbar.
Använd utlandsprefix så att det även fungerar när du är utomlands. Det är också viktigt att man informerar den eller de personer som lagts in som kontaktpersoner.På så vis kan räddningspersonalen snabbt nå närmast anhörig och få viktiga besked om medicinering eller om man lider av någon sjukdom, säger Anders Klarström, central presstalesman vid SOS Alarm.
Bokstäverna har sedan dess fått spridning både i Storbritannien och USA, och Klarström tror på ett ökat användande i Sverige. Det är smart och enkelt och kostar ingenting. Se det som att du har en försäkring som du i bästa fall aldrig behöver utnyttja men händer något allvarligt har du förberett dig för att öka din trygghet, säger han.
Skicka gärna informationen vidare till andra så att den sprids i hela Sverige, hälsar Anders Klarström, som gör vad han kan för att få ut budskapet via media.
Att informationen är korrekt och internationellt gångbar kan du själv bekräfta med ett besök på bifogade länkar (eller med en sökning på "In case of emergency" på Google):
http://www.sosalarm.se/press/pressklipparkiv.asp?onPage=1&ID=604&Read=
Kanske även vore en bra relation att ha med i LDAP (tänker min systemutvecklarhjärna) ice=xxxxxxxxx?
Update! Följande även hämtat från den engelskspråkiga världen: "For more than one contact name ICE1, ICE2, ICE3 etc".
En tanke som ibland dyker upp är att "det svåraste med att införa SOA är de politiska hindren". Hmmm...
Om politiken är ett hinder, så betyder det att skälet för att införa SOA inte är politiskt. Och då undrar jag om man verkligen ska införa SOA. Om den egna organisationen är mogen för det.
De utlovade bra följderna av SOA är ju allesammans i första hand politiska. Visst, det finns en massa goda tekniska skäl att införa SOA, men om de bara betraktas som tekniska, så betyder det att icke-tekniska befattningshavare tänker: "Jag bryr mig inte om hur ni implementerar dessa-och-dessa funktioner, bara ni gör det!".
Men det är ett ignorant sätt att förhålla sig. Hur du beskriver ditt data i organisationen bestämmer helt och hållet vad du kan göra med det. Vilka processer du identifierar som viktiga för många (som alltså lämpar sig som tjänster i en SOA) är en i högsta grad icke-teknisk fråga.
Så SOA löser inte i första hand ett tekniskt problem (även om det visserligen löser vissa tekniska problem). SOA löser i första hand politiska, verksamhetsnära, problem. Vilket betyder att initiativet och ansvaret för genomdrivandet ska ske från dem som har ansvar för företagspolitiken.
Och om dessa inte förstår varför (det är ju trots allt inte teknik), så är det så illa, att man måste ta till Bob Dylan för att rätt beskriva det:Come mothers and fathers throughout the land
and don't criticize what you don't understand
Your sons and your daughters are beyond your command
Your old road is rapidly ageing
Please get out of the new one, if you can't lend a hand
'cause the times, they are a-changing
Mitt förtroende för den svenska varianten av CIO http://cio.idg.se har dalat ytterligare från en alldeles för låg nivå.
Lyssna på denna säljpitch för en nedladdningsbar PDF-artikel om SOA:
Vi tipsar om vad du bör tänka på i upphandlingen, och bjuder på en guide till marknadens lösningar.(http://cio.idg.se/globalincludes/applikationer/pdf_arkivet/articleBuy.asp?item=17419)
Upphandlingen? Hallååå!? Du kan inte köpa en strategi. Du kan inte köpa en strategi.
Låt mig gissa: detta är ytterligare ett försök att lansera SOA som en teknik. Något som en chef liksom kan köpa in, likt en skurmopp eller en ny server, eller chokladkaka till personalfikat.
Men är det något som svenska chefer definitivt inte behöver höra, är att koncept och tankesätt och strategiskt värdefulla metoder är produkter, som gör att de slipper tänka eller bry sig. Det har vi sett tillräckligt av.
Man kan fråga sig varför den svenska tidningen har så låga tankar om chefer, när den engelskspråkiga modertidningen tar frågan på allvar.
Jeeeesh!
Visst är det härligt när en god tanke får ett namn, som dessutom blir ett surreord?
Nu är det Service Oriented Architectures som myntats (ja, ja, det var några år sedan), och renderat en del bla bla bla runt om i världen.
Mjukvaruförsäljarna är inte långsamma med att rycka ordet till sig och gärna knyta något av sina produktnamn till surret. Microsofts .NET-teknik, t ex, eller Javas J2EE. SOAP-server. Protokoll.
Och så blir det (återigen, suck) fokus på tekniken, medan filosofin trängs undan. Vilket får till följd att de teknikrädda men smarta människorna som borde tagit till sig filosofin, istället tror att det är fråga om att välja rätt teknik.
När det handlar om att välja rätt tänkesätt. Och det är inte teknik. Jag upprepar: inte teknik.
För den som vill läsa på tycker jag att Wikipedia i vanlig ordning ger en bra beskrivning: http://en.wikipedia.org/wiki/Service_Oriented_Architecture.
Rent tekniskt (ja, jag måste börja i den ändan) handlar det om att göra vissa funktioner tillgängliga för verksamheten, fast inte med grafiska gränssnitt för människor att klicka på, utan som maskinläsbara gränssnitt för dataprogram att använda.
Tänk dig att ni har ett intranät där de anställda kan rapportera tid, effektuera kundordrar, göra valuaomvandlingar eller någonting annat. Ett fantastiskt arbetsbesparande redskap.
Tänk dig nu att ni även har en grupp gravt handikappade men lojala och effektiva anställda (begåvade med handikappet intelligensbefrielse). Dessa anställda brukar i vanliga fall kallas "datasystem". Jag tycker om att tänka mig dem som robotar i äkta Plåtniklas-skrud (med lampor som ögon och antenner på huvudet).
Om ert intranät innehåller tjänsterna även för denna grupp anställda, vad betyder det? Jo, det betyder att de själva inte behöver innehålla någon kod för att räkna om valutor, eller för att ta sig in i tidrapporteringssystemet, eller för att effektuera kundordrar.
Och ett dataprogram som inte behöver innehålla så mycket kod är ett på alla sätt bra dataprogram. Få kodrader = få fel = enkelt att underhålla = billigt. Billiga, men ändå lika kapabla som deras mer välväxta kusiner som inte använder intranätet.
Det är SOA. Ett smart sätt att centralisera funktionerna som behövs.
Nå, vad är haken? Jo, haken är att verksamheten måste identifiera vilka tjänster (Services) som ska ingå i arkitekturen. Tjänsten måste ingå i företagets allmäna medvetande som en grunka, på precis samma villkor som de verktyg som människorna använder.
Och det betyder att samma strategiska tänkande som identifierade tjänster väl värda att ha på intranätet, även måste appliceras på robotarnas behov.
Och det betyder i sin tur att folk på strategisk nivå måste börja bry sig om robotarna och deras behov.
Och det betyder att folk som är utbildade och tränade på att känna robotarnas behov måste beredas plats i åtminstone den delen av verksamhetens strategiutveckling. Precis som alla andra som sysslar med arbetsledning.
För det är det som en mjukvaruarkitekt är: en arbetsledare. Låt vara att arbetarna är av plåt (eller kisel och elektroner), men likväl en arbetsledare. Är arbetets organisation en strategisk fråga, så är företagets mjukvaruarkitektur en strategisk fråga.
Det är fler namn, och betydligt tyngre än mitt, som insett vitsen med grunkvärde
Här är det den amerikanske konsulten Dean Meyer som talar om IT-budget.
Lägg märke till detta citat:
Traditional budgets -- listing cost factors like compensation, travel, and training by group -- cause numerous problems. Two problems are really damaging:
- First, they don't support sound financial decision making, since the full cost of individual projects and services is not known.
- Second, they don't define exactly which projects and services are covered by the budget. As a result, organizations face expectations well beyond their resources, and are blamed when they can't satisfy every request.
Instead, budgets should list deliverables -- the products and services produced by the organization -- and present the full cost of each.
Exakt! Alltför ofta ser man en massa aktiviteter budgeterade, gärna som kostnadsposter. Bla bla personalkostnad, bla bla utbildningskostnad bla bla. Men det är fortfarande GRUNKOR som genererar pengar, och GRUNKOR som kostar pengar.
"Grunkor" är alltså "deliverables" i hans terminologi. Produkter och tjänster som uppfyller någon sorts funktion i verksamheten. Som tar del i värdeskapandet.
Om man inte värdesätter grunkorna, både för vad de är värda och för vad de kostar (och det första ska överstiga det sista), så har man ingen finansiell koll på sin IT.
Har man koll på vad personalen kostar, så har man koll på en illusion. All personaltid, effektiv och nyttig, eller ineffektiv och skadlig, kostar enligt den modellen lika mycket. Vilket ju inte är fallet. En krona lagd på ett värdefullt system är betydligt billigare än en krona lagd på ett värdelöst.
Det är så enkelt: håll koll på grunkorna (budget, intäkt, kostnad), så kommer den andra kollen av sig själv. Gör du tvärtom har du ingen koll.
(forts. fr. Del 3)
OK, vad har vi lärt oss? Jo, att det är smart med
Vi har också lärt oss att det är skillnad mellan
Och att fel i dessa grunkor innebär större kostnader än man tror. Och att du förmodligen bör ge dem en rejäl översyn, kanske vidareutveckla eller förbättra dem vartannat år.
Nu börjar vi närma oss den punkt då vi faktiskt kan veta svaret på frågan
Givet vad vi lärt oss innan kan vi dra några slutsatser, beroende på vad det är för system vi talar om:
Dina konkurrenter har samma IT-stöd för vanliga grejer som du (stödtrupperna). Det är alltså inte befogat att satsa pengar på att försöka förbättra stödtrupperna. Vinnare är den som tvärtom håller nere kostnaderna.
Men för att kunna hålla nere kostnaderna krävs det kanske satsningar. Stödtruppssystemen ska bara ticka och gå, utan att göra så mycket väsen av sig. Ingen ska behöva lägga mer än en ynka del av sin tid på att hålla stödtrupperna rullande.
Eftersom stödtruppssystem ofta är av det slaget att det finns många leverantörer, är det lite "köparens marknad" över dem. Det kan löna sig att omförhandla eller lägga ut på kontrakt (även om du har intern IT-personal). Detta sänker kostnaderna.
Även stödtruppssystemen behöver ses över vartannat år. Därför bör de vara av ett flexibelt snitt, så att de lätt låter sig ses över och konfigureras om och anpassas efter nya förutsättningar. Eftersom spjutspetsar alltid byggs för att kommunicera med stödsystemen, bör stödsystemen dessutom vara av typen "öppna lösningar", alltså bygga på öppna standarder för kommunikation. Leverantörerna och tillverkarna av stödsystem vet detta. Därför bygger de ofta in spärrar som gör det svårt att integrera spjuspetsar med stödtrupperna. Det gör att en all-in-all-lösning för t ex e-post som verkar vara väldigt billig blir svindyr eftersom varje försök att göra något mer av dem blir svårt, dyrt, och krångligt.
Just bland stödsystemen har FOSS (Free & Open Source Software) funnit sin nisch. Dessa system är oftare enklare att bygga ut än andra.
Den stora kostnaden för illa fungerande stödsystem är ju allt som krävs för att hålla dem under armarna. Den stora vinsten med att satsa på felfria och självgående stödtrupper, är att du frigör resurser för att utveckla och/eller underhålla det andra slaget: spjutspetsarna. Det är i spjutspetsarna dina stora vinster genereras.
Så din första prioritering måste vara att se till att dina stödtrupper, de grundläggande funktionerna som även dina konkurrenter har, fungerar smärtfritt. Få ner antalet fel. Minska antalet tillfällen då IT-personal måste syssla med handpåläggning för att få det att fungera. Satsa på att göra dem självgående. Kanske outsourcing?
Mottot för stödtrupperna är "Varför ska en sån enkel skitsak som alla andra har krångla för oss?". Tänk på KISS (Keep It Super Simple).
När konstnaderna och krånglet för stödtrupperna går ner, då frigörs resurser. Dessa ska naturligtvis läggas på sådant som direkt påverkar marginalerna. Nu kan du få tid och pengar att faktiskt utveckla din verksamhet. Automatisera, fixa till webbplatsen och göra den till ett proaktivt verktyg för att kommunicera med kunden, ordna och fixa så att du blir bättre än dina konkurrenter.
Men då är det viktigt att vi slutar titta på IT-ekonomin för en stund. Annars är risken att vi låser blicken i IT-träsket. Nu handlar det i första hand om hur du vill utveckla din verksamhet, och det kan du bäst själv.
Däremot, när du kommit på ungefär vad det är du vill du ska göra, då är det dags att ta på sig IT-glasögonen igen. För även utveckling kan bedrivas på antingen ett ekonomiskt eller ett fullständigt vansinnigt sätt.
Nyss hemkommen från ett par kompisar som behövde lite omvårdnad. Alltså, datorn deras behövde att någon gullade med den. Windows XP, förstås. Min linuxinstallation klarar sig väldigt bra på egen hand, men kompisarnas Windows XP har ett aldrig sinande ömhetsbehov.
Först en rejäl koll efter suspekta processer och dylikt. Sedan avinstallation av en massa toolbars till Internet Explorer. Sedan fixa prenumeration på antivirusprogram och en genomgång av hårddisken. Lite borttag av program som bråkade med varandra och gjorde hela systemet instabilt. Sedan hade CD-spelaren fått storhetsvansinne och kallade sig för SCSI-enhet, fast det är en vanlig IDE-spelare. Fixa fixa.
Sedan... in med Firefox som standardwebbläsare. Den hade de kört innan och gillat. Men the killer app: Thunderbird.
-"Kan du fixa epostkontot också?"
-"Kanske, vi får se..."
Klick, klick, klick. Klart.
-"Woah, så enkelt?"
Thunderbird rular! Och som jag nämnde här, så är fullfjädrad kryptering och digitala signaturer enklare på Thunderbird än att lägga barnens Bamsepussel. Klick, klick, klick. Klart.
http://www.mozilla.com/thunderbird/ (e-postprogrammet)
http://www.gnupg.org/(en)/download/index.html#auto-ref-1 (kryptomotorn)
http://enigmail.mozdev.org/ (kopplar kryptomotorn till e-postprogrammet)
I förra lektionen fick du en räknemodell för att räkna ut nettovärdet av dina IT-investeringar, genom att se hur de stödjer dina processer. På köpet tvingades du se dina processer, för vad de är värda. Vilket är viktigt. De som känner att IT-stödet har en oklar roll i organisationen, har ofta en oklar bild av själva organisationen nämligen. Vad datasystemen gör är glasklart, men den roll de spelar avgörs av sammanhanget de är insatta i.
Dina processers intäkter och dina IT-satsningars andel i den intäkten är A & O när det gäller att räkna med IT. Dels vid införandet av nya IT-satsningar, men också när det gäller att se över underhållsbehovet.
Allt handlar om "the business case", alltså det affärsmässiga skälet till att utföra förändringar i ett arbetssätt (och att införa ett IT-system är ingenting annat än just det). "Är det dyrt?" vill många fråga. "Lönar det sig?" menar jag är den rätta frågan. Och hur ska man prioritera sina satsningar? Vi börjar med att lära oss hur man ser på saker som fungerar dåligt.
På kostnadssidan för varje IT-grunka radas allt det dyra upp: införandekostnader, service, licenser osv. Och personaltid för att hantera grunkan, inte bara systemfolk, utan alla inblandade. Även chefens tid.
Det man missar om man bara tittar på kostnadsspalten är den dolda kostnaden, när något inte finns eller fungerar som det är tänkt. När alltså den intäktsbringande delen av systemet inte levererar, och det blir ett intäktstapp.
Om man har rätt system på plats, så är de lönsamma, dvs intäkterna för processen överstiger de sammanlagda kostnaderna för processen. Men det betyder att om systemet fungerar dåligt, så slår det obönhörligen på intäkterna. Slår det inte på intäkterna, så kanske inte systemet alls behövs, eller hur?
Orden "fungerar dåligt" kan både syfta på att systemet är instabilt, och på att systemets roll i organisationen inte riktigt motsvarar vad organisationen kräver. Hur som helst innebär "fungerar dåligt" en avsevärd kostnad.
Här kommer felrapporteringen in. För varje system måste organisationen hålla sig med en fellogg, där driftstörningar rapporteras och, om möjligt, vad detta inneburit för intäkterna. Glöm inte bort följdfel och oväntade kostnader för att rädda systemet osv. Ju mer precist man kan hänföra direkta kostnader till direkta fel och driftstopp, desto bättre.
När det gäller systemets roll i organisationen är det viktigt med uppföljningar där de drabbade av systemet får säga sitt. Efter två år har förmodligen verksamheten förändrats så mycket att det är dags för en översyn (tidigare i vissa slags organisationer), men eftersom förändringen oftast sker smygande, så degraderar systemets intäktsbringande roll gradvis. Det kallas för "bitröta" eftersom känslan är att systemet ruttnar ihop, men det är naturligtvis inte systemet som degraderar, utan resten av världen som rör på sig.
Också när det gäller uppföljningar ska man försöka hitta kostnaderna. Vad innebär det i tid för användarna att de behöver gnugga systemets data manuellt, om det skulle kunna automatiseras? Vad innebär det för intäkten att systemet bara kan hantera beställningar av typen X och Y när vi nu faktiskt har typen Z också, och det blir fler och fler Z-beställningar?
Dessa kostnader är viktiga, för de är de som är själva motivet för att göra något åt situationen. Denna kostnad är en förbättringspotential, alltså en framtida intäkt. Därför ska du inte gömma undan dessa kostnader genom att blanda den med de kostnader du redan identifierat. Skapa en ny spalt för förbättringspotentialen istället. Kostnadsspalten beskriver vad det kostar att hålla systemet på dagens nivå. Förbättringspotentialen är vad du kan tjäna på att ändra dagens nivå.
Nu har vi kommit så långt att vi kan se
Nu borde vi väl kunna, utifrån dessa siffror, prioritera?
Nej.
Vi betraktar nämligen än så länge systemen som isolerade företeelser. Visst, vi har en processbild att utgå ifrån, men det finns betydligt mer att titta på, som har med de större sammanhangen att göra.
Men det är en lektion för sig.
E-post borde inte heta e-post. Det borde heta e-vykort, för det är precis vad det är. Allt som du skriver syns för hela världen, om någon
bara bryr sig om att titta efter. Och inte heller kan man vara säker på att avsändaren är den rätta heller. Det är bara för vem som helst att skicka
ett brev från knugen@kungahuset.se eller president@whitehouse.gov.
Med kryptering, däremot, kan obehöriga inte läsa vad du har skrivit, och alla kan vara säkra på att det är just du som har skrivit. Titta här på ett e-brev jag skriver:
Detta är en hemlis. Hemlis, hemlis. Hälsningar Ola.
Jag skickar det till en kompis. Jag har fått kompisens "publika nyckel" (alltså en nyckel som alla får se på och använda för att kryptera meddelanden till den kompisen). Mitt epostprogram (Thunderbird) krypterar meddelandet:
-----BEGIN PGP MESSAGE----- Charset: ISO-8859-1 Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org hQIOA4hpCTpSCv3WEAgAraoLHrH+ophzwFzS1xxZKOnGlo1kEXe3cMiycxYfzcIW VEOqLvoOx4mBKz8SiX9xtmCFjjbyRyBpGVPQerL2VyfjXx4btZ9hbXNt91p2nhEk u1c2sTIJ+DjmILgIgtY/CdvKSoK65oAY7lSfCWcfXhlQ+T6EbVFaly0SDTyxf2YD Us9YknTXdKIjfFJGwPSlMYvvXC0380tgQ4pJV3MG3vhnmIRnID+a+eHYjGoGdY55 mDuTrJh+Cw4sLVgAngtk+QjJ/WKodbgKVWT0DnYl/DIGkq7t4poqkEpbsC1fE4eu tawD79RkqiEoT74xuNuo4RApuqiFdrkrh2EI8EyXwgf+PNbJMnn1LDEOQHhIaxkG qgKpb0Vm4ti+eaIJ1gXgSEM+F0vpBCGi0FU/CQEJ+aGGt4nGT5kOtLmIHfnLU5Dw U0RZsonbXa+4DXyGRMIbDVpOf3s417F6MnE46cyQglCYqms+SoB77bWqOtUUbiAu bfhq5DisQX6pA1s7rWb+xD8bXkHrETyPUImf3nuvewIVWEILLN57kRmG5hu4Tx+B lKe5k/O2SBeF5AYJJ1BgGerSwbrm37qhu3P9Wt9Bkelh5WZwCH3sxshlgng3a9oM E5fpcCuuZ9H4gn18tquMDpVbJ9trpGKyu2l0X/ZXHCxb8w9LhmyVqY7LLzX2LvmT xYUCDgMG7KwiDgYAoBAH/jwzC9y3oglJvVrey5rx/znwdjzJeQfNwtHJc58ppKbt J22cZ9HYVPar/RM9gNiQZdTqwcPRbeCUblWKGTlgS523aTR/R2OnJG03z8UCEYWF PG1W9pl1Oca+UFN0iKIYwgiNDwKyfptrsIqrtAVWYnVWEIvmR06fzNX3A0xg4Xyf f/dgWPbvYOi+439z/BsKTVy4sIOWfql8Iii+YtKhJS+i9InIEbpURfyPP1hTvNj8 4FjW2sKEZyJkLjV1cEGlnpW/U73zZfTUdO35R8VM4v+WfFpNE1J6YDDTQxRn1wJM kvraLpg/tiWObkuEXpbbKjd7Jzk/f7p+gCBmmjyWXXYH/Rp9i07bfDlGsSLbZ3vM i8xsa36E9UWb0Bo3hIdJOhHLOJvd1/vAnwkrGJlwCVzAgX6z3rTf4M9k0u0zcV7t FmhuACQLYkZO6M6RcD7rDlfW9b+w/8kOHxlSyBDXLfWfVpB7dJ3dZfeIdVyAopOn DRAgprzPYDjtOAnkhFuTw0TdgQNXGJYNP6OJF+Vd9fw9m/9BGV+PDgakjtcBq3Nd jLifO97uyMGhLtnLuI4VppbDARWPa6xfhBZxaJmOpp02XGqbwlsIw909xRCjdvet aQ4JxWfl//HRTUIMSWwVO0zxlQpqcKiADnVJQsm5jfZ6DXsU7KvJ399Dw9JkUDwF egbStQG0+vWmJF8B7NUBtHMAnai6SCD+knfbS56oKgvv000PzVgVG8N4t2IDOq3G hvVwFmQK606F3oLuwHxd/xF2FPWcWf77Zcc2+H8oAD4cyDXeGB1q36VrqGQ3vQJy 4tUlE/3+XQtyflfAQ2B2fo3u8jdNw2cr+FJRn98TPbmFo3sGgFPd7nzH/8qGa8zL fDeY1reGPjlcM3ZI0w8GUCriyM0jpVqPXmIjlZtQL1N1qejpeD9pE8A= =V96x -----END PGP MESSAGE-----
Försök läsa den om du kan!
Kompisen kan. Med sin privata nyckel (som bara hon har tillgång till) kan hennes epost-program avkryptera meddelandet. Meddelandet är dessutom först signerat av mitt epost-program, med hjälp av min privata nyckel. Genom att jämföra med min publika nyckel (som ju hon har) så kan hon vara säker på att det är jag som skrivit.
Nuförtiden, med snabba datorer (ja, din dator är tillräckligt snabb, kan din dator surfa detta kan den kryptera), finns det inget skäl att låta bli.
Dessutom: nuförtiden är det så enkelt. Det tog mig mindre än fem minuter att ladda ner all programvara och komma igång! Kontakta mig om du behöver hjälp.
Om någon vill ha tag i min publika nyckel, så har den id "0xB4DD4F5B". Den finns uppladdad (bl. a.) på nyckelservern pgp.mit.edu.
Om du hämtar den, så kontrollera att nyckel har fingeravtrycket "39FA 9320 A63E 81F6 312A C014 59F3 69A0 B4DD 4F5B" så att du är säker på att den är min.
...är inte helt lätt alla gånger. Det finns många tankefällor här.
I Birgitta Fagerströms doktorsavhandling som jag pushade för här finns en intressant formulering rörande nyttomätning:
Ett visst systems ”framgång” i termer av användning.
Tanken är inte ny. Ett infört system dissas när utvärderingsgruppen finner att bara 12% av systemets funktioner faktiskt används.
Hmmm... det finns ett ganska stort utrymme på vår tomt som jag aldrig beträder. Betyder det att det var misslyckat att köpa huset? Jag kör aldrig över 110 km/h. Gör det min bil (som ju kan gå fortare) mindre nyttig? Jag åker tåg och spårvagn 14 från och till jobbet varje dag, och ser inte åt de andra linjerna. Är mitt månadskort i onödan?
Om 88% av funktionerna i ett system aldrig används säger det visserligen att dessa funktioner var i någon mening onödiga. Men nyttan måste väl ändå främst mätas på de funktioner som faktiskt används, eller hur? Det är ju funktionerna som används, som bidrar till systemets positiva effekt i verksamhetens värdeskapande process (se här om det viktiga nyckeltalet "grunkvärde").
Jovisst, de 88 procenten kanske aldrig hade behövt utvecklas (om det är ett egenutvecklat system man pratar om). Men var de svåra att göra, eller bara en enkel spin-off från den grundläggande arkitektur som systemet ändå behövde ha?
Och om det är ett köpesystem, så köper man väl in det utifrån de funktioner man faktiskt behöver? De övriga funktionerna är mer "på köpet". En ordbehandlare blir ju inte sämre, bara för att majoriteten av dess användare inte förmår eller ens har behov av att skapa komplicerade makron.
Och vad är en "funktion"? Ur användarens synvinkel är det en del av ett användningsfall. Men om man väljer att implementera ett användningsfall som en eller flera "funktioner" kan ju bero på en massa olika överväganden.
Så nä... "endast 12% av funktionerna används" säger ingenting om systemets nytta. Det säger en del om att systemet inte riktigt används som det var tänkt, men det är ju någonting helt annat.
Så hur bör man tänka då? Jo...
Om man är intresserad av problemställningarna kring mjukvaruinförande och utvärdering och sånt, så är denna doktorsavhandling från Luleå Tekniska Högskola superintressant. Den är akademisk, men absolut inte teknisk i sin karaktär. Den behandlar inte mjukvaruekonomi i sig, men talar om effekter på organisationer.
Det är bra att det forskas på sådant här. Jag är ju en varm anhängare av RUP, och inbyggt i den metodiken är ju en utvärdering både av användarnas nytta liksom att man hela tiden håller koll på att det som tillverkas är ekonomiskt sunt att tillverka. Då är en utvärderingsmetod av nöden.
Hennes slutsatser är tankeväckande. Om du inte orkar läsa hela (hon har ett ganska långt och tråkigt metodkapitel där hon nästan defensivt går igen grundläggande saker om kvalitativa analyser - måhända för att folket vid en teknisk högskola är mer vana vid kvantitativa), så läs åtminstone hennes Abstract (i början) och Conclusions (i slutet).
I förra lektionen fick du lära dig att tänka på dina system som antingen spjutspets eller stödtrupp, och att man kan se lite olika på dessa två.
Vad som dessutom hände var att du började tänka på dina system som grunkor, om du inte redan gjort det. En vanlig åkomma är nämligen att man ser sina system som enbart processer, dvs man ser inte systemen alls och vill helst inte tänka på dem. Det är sant att processerna är viktiga, men de realiseras trots allt av grunkor, och grunkor kostar.
Finessen med god IT-ekonomi är nämligen att maximera värdet av processerna som realiseras av grunkor med maximalt nettovärde.
Nu har grunkorna fått varsitt namn, och du har till och med börjat dela upp dem lite. Ditt epostsystem som förutom att leverera epost dessutom kan ta emot och behandla ordrar på ett finurligt sätt, är ju i själva verket två system: stödsystemet "Epost", och spjutspetsen "Ordermottagning med e-post".
Nu kan man göra sig en karta över detta, en karta där vi dessutom noterar processerna.
-"Men fattar du inte Ola, det kostar ju 17 000!" Orden kom från en mellanchef. "Hur vet vi om det är dyrt?" frågade jag.
Det är grundfrågan. Om man inte kan sätta en kostnad i relation till någonting annat, hur vet vi om det är dyrt? När det gäller företagsekonomi gäller ju i alla fall inte samma regler som för hushållskassan. I ett företag ska vi inte bränna pengar, där ska vi tjäna pengar. I ett företag är 5000 kr ut i tomma intet jättedyrt, men 500 000 kr som kostnad för att tjäna 2 miljoner kan vara ett acceptabelt pris.
Alla IT-grunkor (maskiner och mjukvara) i ett företag betjänar minst en process. Det är i processerna värdet skapas. Ett datasystem genererar inga pengar. Affärsprocesser genererar pengar. System stöder (i bästa fall) processer, men är aldrig processer i sig själva. Så första steget för att få reda på vad "dyrt" betyder, är att kolla in värdena på intäktsidan för processerna. Hur mycket stålar drar processerna in?
En värdelös process, eller en process med negativa värden, är dyra i sig själva. Naturligtvis blir varje enkrona som läggs, antingen på maskiner, mjukvara eller människor i en sådan process, oerhört dyr. Men att städa upp bland dyra processer är inte specifikt IT-relaterat, utan ingår i normal verksamhetsutveckling. Dock är det så att eftersom IT-ekonomi kräver att vi sätter kostnaderna i relation till processerna, så kan en IT-ekonomisk genomgång vara ett bra tillfälle för att genomföra en genomgång av verksamheten i stort.
Nu vet vi vad som står på spel. Nu tittar vi på den aktuella grunkans andel i processen, genom att tänka vad som händer om grunkan lyfts bort. I vilken grad kan processen fortgå utan IT-stödet? För e-postsystemet är andelen mycket hög (utan e-postserver stannar e-posten och får 0%, e-postserverns andel är alltså 100%). För andra system, t ex den automatiserade ordermottagningen över e-post, är andelen lägre (man kan ju hantera ordrarna för hand även om det går långsammare). Om ordermottagningen hanterar en order fyra gånger snabbare än för hand, så sjunker produktiviteten i processen till 20% om IT-stödet tas bort. Värdet av den automatiska ordermottagningen blir alltså 80% av hela ordermottagningsprocessens värde.
Bra grunkor stöder dessutom flera processer. Då lägger man samman värdet för varje process, gånger grunkans andel i varje process, för att få grunkans värde.
För en IT-intensiv verksamhet kan det mycket väl vara så att systemens andel i varje process är 100%. Då kanske det är dags att se över processen för att minska risken, men det faller utanför ämnet för dagens lektion.
Nu vet vi värdet av varje grunka (skriv ner det). I nästa spalt skriver vi den sammanlagda kostnaden för varje grunka. Den sammanlagda konstnaden alltså, över hela systemets livslängd. Från det att det började kravställas, köpas in, byggas, införas, finjusteras, lagas, förbättras osv fram till dess att det skrotas. Kostnaden för personal, maskiner, licenser, konsulter, allt ska bokföras.
Grunkans nettovärde är dess bruttovärde minus dess totalkostnad.
Och för hur lång tid? Det där beror väldigt mycket på. En god tumregel säger att man bör betrakta systemets livslängd på cirka två år. Detta för att det tar ungefär två år för systemets omgivning (verksamheten) att ha förändrats såpass mycket att någon form av radikal omstrukturering av systemet måste ske. Systemet ändras inte, men det gör omgivningen. Vid en omstrukturering/omimplementering av systemet (efter ungefär två år) kan man naturligtvis ofta återanvända stora delar av systemet. Men räkna inte med det från början. Det är en vinst som kommer systemet till del genom minskade utvecklings- och införandekostnader under nästa tvåårsperiod. Dividera med tjugofyra och du får en månadskostnad.
Nu kan vi plötsligt jämföra värdet av en process, med de sammanlagda kostnaderna för alla grunkor som stödjer densamma (för grunkor som stöder flera processer ska naturligtvis kostnaden spridas ut på dessa).
Och vi kan jämföra kostnaden för varje grunka med värdet av densamma. På så sätt får vi syn på olönsam och lönsam, och viktig respektive oviktig teknikanvändning. Och vi kan sätta kostnaden för underhåll i relation till kostnaden för att byta ut grunkan, eller i relation till att arbeta om processen helt.
Vi kan också dra några andra slutsatser:
Inga banbrytande insikter, men vi vet nu inte bara att vissa saker är dyra, utan också hur dyra de är.
Öka varje grunkas värde genom att ha värdefulla processer som stöds av totalt sett få grunkor av hög kvalitet!
Notera att jag skriver om "grunkor i en verksamhet" och inte "grunkor i en process". Det finns nämligen en frestelse här att suboptimera genom att försöka minska antalet grunkor i varje process. Men ofta leder det till att grunkorna blir väldigt specialiserade och lämpar sig dåligt för användning i olika processer, vilket leder till ett ökat antal grunkor i verksamheten och därmed sämre total ekonomi. Märk hur värdet av en grunka drastiskt höjs när den är del av flera processer, och hur kostnaden för en process drastiskt sänks när kostnaden för en grunka delas upp på flera processer.
Och notera att det inte gäller att höja hela verksamhetens grunkvärde genom att ha många grunkor. Värdet på verksamheten är i varje given stund inte högre än värdet av dess processer. Det är värdet på varje grunka som ska höjas, genom att man har optimalt få och välfungerande sådana.
Det första jag ska flytta över är mitt svammel / mina halvstrukturerade tankar om mjukvaruekonomi.
- "Ja det är ju IT det", sägs det, och blicken blir flackande. "Jag kan ju inte IT". Man misstänker att den som just yttrat sig inte riktigt vet vad som är bak och fram på en nätverkskabel. Vill inte riktigt befatta sig med saken. Det är ju IT.
Men samma person kan glatt räkna med personalkostnader, utan att för den sakens skull vara expert på HR-frågor. Eller förhandla om hyreskontrakt utan att veta hur man bygger hus. Eller göra en avräkningskalkyl på en plåtpress utan att veta något om hur styr- och reglersystemet för den är uppbyggt.
Att räkna kostnader och intäkter för en mojäng kräver ju inte att man känner till hur den fungerar. Det är inte programmerarkunskaper som krävs för att göra beräkningar på mjukvara. Däremot finns det naturligtvis saker som man måste känna till. Det blir ofta fel när någon applicerar beräkningsmodeller som grundas i helt felaktiga antaganden.
Med det är alltså inte djup kunskap om programmeringstekniker som krävs. Till och med en ekonom kan lära sig räkna med IT.
På Beda Olssons Bageri finns det maskiner. Alltifrån truckarna som kör mjölsäckar, till det specialanpassade hypereffektiva förpackningsbandet. Skulle du fråga Beda Olsson skulle hon säga att det är rätt stor skillnad mellan truckarna och förpackningsbandet.
Truckar finns i många industrier. Men förpackningsbandet är hon ganska ensam om. Det är det som är hemligheten bakom den höga produktiviteten i hennes bageri.
Både trucken och bandet är teknik. Men medan den första är en stapelvara och vanlig syn i större bagerier, så är den andra diversifierande. Den skiljer ut Beda Olssons från andra bagerier, och hjälper henne att göra goda affärer.
På precis samma sätt fungerar IT. Det finns IT som alla andra har, och det finns IT som är diversifierande. Stödtrupper och spjutspets. Ett e-postsystem är viktigt, men ingår i allmänhet inte i spjutspetsen. Man tjänar i oftast inga pengar på att vidareutveckla e-posten i sig, däremot skulle man förlora pengar utan den, och man kan spara pengar om den har så låga omkostnader som möjligt.
Googles sökmaskiner däremot, det är pengagenererande spjutspets. Naturligtvis applicerar man inte riktigt samma beräkningsmodell för spjutspetsen som för stödtruppen. Stödtruppen är ett kostnadsställe, medan spjutspetsen är intäkt. För stödtruppen ska man hålla nere kostnaden, för spjutspetsen ska man se hur många kronor varje satsad krona ger.
Så hemläxan till nästa gång blir att tänka över vilket slags IT hos dig som är spjutspets respektive stödtrupp. Vad krävs för att hålla verksamheten rullande, och var sker själva produktionen? Vad har du och alla andra, och vad har du men inte de andra? Vad kan man köpa eller hyra, och vad måste man specialanpassa?
Kanske är din spjutspets ditt e-postsystem, medan söket är stödtruppen. Förmodligen har du system hos dig som är båda delarna. Försök då dela upp systemen i delsystem:
vad i systemet utgör spjutspets, och vad utgör stödtrupp?
Nu flyttar jag över en del av mina gamla bloggningar till den här nya.
På sikt ska jag försöka fixa så att det som postas här kommer att synas på min gamla adress: www.fundament.se
Ska bara se om jag kan grokka det här...