Avainsana: muutos

Opitaan työssä luomaan muutos

luodaan yhdessä
muutos, taotaan kivet
katedraaliksi
Teemu Arinan johdattelema IT-kouluttajien tilaisuus Oppiminen työelämässä 6.11.07 Haaga-Heliassa jäsentyi vuorovaikutteiseksi monipuolisten ryhmätöiden ja asenteita ravistelevan multimediaesityksen myötä. Ryhmissä pohdimme työelämän trendejä ja visioimme parempaa, jota haluaisimme yhdessä luoda. Neljän ryhmän iskulauseiksi muotoutuivat:

  • YouTube, MySpace, OurWorld
  • Ilo olla
  • Löydän aina oikean mestarin
  • Älyllä ja tunteella muutoksessa mukana.

Eettinen yritystoiminta ja muutoksen luominen soivat ryhmien vuoropuhelussa.
”Kieli on talo, jossa ihminen asuu”, Teemu Arina siteerasi Heideggeria. Tulevaisuus luodaan itse. Koulu kaipaa vuorovaikutusta ja reflektiota opettajan monologin tilalle.
Teemu Arina kertoi tarinan kuudesta sokeasta miehestä ja norsusta. Kaikki olivat väärässä ja tavallaan oikeassa, jokainen miehistä kuvaili tunnustelemaansa norsun osaa, mutta yksikään ei hahmottanut kokonaisuutta.
Kaikilla työtätekevillä on velvollisuus unelmoida paremmasta. Pienet muutokset monimutkaisessa järjestelmässä merkitsevät paljon. Kukaan ei ole asiantuntija eikä tulevaisuutta voi ennustaa.
Kuuntelemisen taito on tärkeä, vaikka kokemukset omista ajatuksista kuuluisivat voimakkaimpina. Analoginen malli, jota käytämme vuorovaikutuksessa, rajoittaa ilmaisua; tiedämme enemmän kuin pystymme muille välittämään.
Teknologia vaikuttaa tekemiseen. Kuvitelkaa maailma, jossa olisi Beethoven ilman pianoa, da Vinci ilman sivellintä tai Linus ilman tietokonetta. Tulevaisuuden työ voi olla tyystin toista kuin nykyiset toiveammatit.
Moderni koulujärjestelmä on teollisen ajan tuote. Kokeeko yksittäinen oppija hakkaavansa kiveä tai rakentavansa katedraalia, on sivuseikka. Ihmiset lokeroidaan koulutuksen mukaan eikä huomata heidän monipuolista osaamistaan muilla alueilla. Ihmiset eivät ole koneen vaihdettavia osia, heille ei kannata opettaa ”pankkiin” asioita. Parasiitti etsii opettajansa eikä odota, että koulu antaa sen hänelle. ”Teknologiat ovat ruumiimme jatke”, Teemu Arina siteerasi McLuhania ja katsoi silmälasejaan.
Erään epäonnistuneen projektin jälkeen projektipäällikkö totesi, että projekti olisi ollut hyvä, jos kaikki olisi mennyt suunnitelmien mukaan. Niin. Tuosta tuli mieleeni 1980-luvun vakuutusmatemaatikko, joka selitti, ettei eläkelaskelmissa ole virhettä, väestö ei vain jostain syystä käyttäydy laskelmien mukaisesti.
Teemu Arina hymähteli, että nykyisin tehdään jopa tutkimusta Web 2.0:sta, joka alunperin oli hype-termi. Puhumme sosiaalisesta mediasta, mutta mitä on epäsosiaalinen media?
Jakaessamme kokemuksiamme verkostossa tuotamme muille metakokemuksia uudella tavalla. Yhteistyö on olennaista – vaikka sitä koulussa kutsutaankin lunttaamiseksi. Olennaista ei enää ole, mitä itse tiedän, vaan keitä on verkostossani, joita voin käyttää hyväkseni. Tässä tarvitaan taitoja, joita ei opeteta missään.
Kirjassa Yritys 2.0 keskustellaan uudesta tavasta tehdä töitä. Kuka tekee innovaation? Post-it-laput syntyivät, kun yritettiin keksiä maailman pitävin liima. Tavoitteeseen ei päästy, mutta saavutettiin jotain muuta.
Homo contextus on yhteenverkostunut ihminen. Oppiminen ei ole muistamista vaan uusien yhteyksien muodostumista. Kai Hakkaraisen mukaan asiantuntijaksi kasvamiseksi pitäisi toimi 10 000 tuntia oman lähikehityksen vyöhykkeen äärirajoilla. Miten tämä onnistuu oppilaitoksen tiukoissa opetussuunnitelmissa, joissa aikaa oppimistavoitteiden saavuttamiseen on yhä vähemmän? Fast food ja slow food, kumman valitsemme?
Jos koulujärjestelmää ei olisi olemassa, millaisia oppimisen tiloja rakentaisit? Korostaisitko vuorovaikutusta vai sisältöjä? Mitä pieniä variaatioita voisit omassa elämässäsi tehdä? Miten luot ideaviruksen, joka leviää kuin rutto? Kirjoitatko sitä varten 500-sivuisen väitöskirjan? Parhaiten verkostossa leviää väite, jota ei perustella loppuun. Täydellinen selitys ei synnytä keskustelua.

Mikä on systeemityössä IN?

hanke purjehtii
vesiputouksesta
muutoskaaokseen

hiljainen tieto
siivittää muuttolinnun
laadunhallinnan

tutkija testaa
haarukalla perunaa
ilman speksejä

Systeemityöyhdistys Sytyken kymmenennessä laivaseminaarissa Viking Mariellalla 5.-7.9.2007 kysyttiin: ”Mikä mahtaa olla IN?”
Sytyken sytyttämiä sponsoreita oli niin paljon, ettei kaikille riittänyt puheenvuoroa paripäiväisessä seminaarissa. Niinpä puheenvuorotta jäänyt Samcom ilmoittautui jo ensi vuoden sponsoriksi.
Timo Kaisla Ixonos Projektinjohtopalveluista kertoi haasteista suurissa tietojärjestelmähankkeissa, sata kertaa tavallisia suuremmissa, tuhansia henkilötyövuosia ja yli kolme kalenterivuotta nielevissä migraatio eli konsolidointi- tai vaihtohankkeissa. Alustava suunnitelma ja lopullinen todellisuus poikkeavat toisistaan merkittävästi: kustannukset kasvavat nelinkertaisiksi ja aikataulu kolminkertaiseksi, hanke koskettaa koko organisaatiota ja suurta alihankkijajoukkoa.
Ainutkertaisen hankkeen skaalasokeutta ei riko konsulttikaan. Johto ja kokenut projektipäällikkö hallitsevat normaaliprojektit, ei koko henkilöstöä koskevaa muutosta. Organisaation pitäisi lääkitä itseään ulkopuolisten kokemuksilla suurista projekteista.
Puolet meneillään olevista projekteista pitäisi tappaa, jotta migraatiohankkeeseen saataisiin kaikkien divisioonien parhaat resurssit. Päällikkövetoinen vaatimusmääritys, vaikka siihen varattaisiin reilut puoli vuotta, tuottaa puutteellisia ja tasoltaan kirjavia tuloksia, jos päälliköt eivät ole systeemityön ammattilaisia. Systematisointi on saattanyt rämettyä organisaation pienissä projekteissa; suurissa sitä tarvitaan. Pienissä projekteissa kannuksensa ansainnut projektipäällikkö ei ehkä uskalla skaalata resurssi- ja aikatarvetta riittävän ylös – ja jos uskaltaisi, esimies ei sitä hyväksyisi.
PMBOK kuvaa, mitä pitäisi tehdä, ei sitä, miten se tehtäisiin.
Vaatimusten- ja muutostenhallinnassa työpajat toimivat, ne tuottavat paljon dokumentoimatonta, ns. hiljaista tietoa. Aikataulu annetaan yleensä ylhäältä, vaikka suurta hanketta pitäisi suunnitella alhaalta ylös. Linjaihmiset arvioivat työmäärät kirjavasti. Katselmointi vaatii pari kuukautta ja kymmenen henkilöä, ettei ”takaseinä jää puuttumaan”.
Laadunhallinnasta tarvitaan kuvaus, jossa käsitellään muutakin kuin testausta. Testaajiksi tarvitaan ulkopuolisia ammattitestaajia, he oppivat nopeasti prosessit kuin prosessit. Jos talon omat asiantuntijat pannaan kolmeksi kuukaudeksi ajamaan erilaisia testejä, kyse on heidän ammattitaitonsa väärinkäytöstä.
Miten henkilöstö saadaan mukaan? Aluksi voisi kutsua vaikka Esa Saarisen luennoimaan, muutoshan koskee kaikkea ja kaikkia. Projektipäälliköt ovat avainasemassa: jos homma on liian iso jollekulle heistä, hänet pitäisi vaihtaa toiseen mahdollisimman pian, muuten muutosvastarinta kasvaa.
Miten suuri tietojärjestelmäprojekti ostetaan? Vaatimusmääritys on niin vaativa, että kiinteä hinta johtaa yleensä jatkuvaan sopimuspapereiden läpikäyntiin juristien kanssa.
Ostavan ja tilaavan organisaation toiminta- ja kulttuurierot vaikuttavat projektiin. Jos organisaatiot ovat eri maissa, ongelmat yleensä lisääntyvät. Halvin tapa rakentaa siltoja saattaa joissain tapauksissa olla ilmainen viina. Projektissa työskentelevien ihmisten pitäisi kokea olevansa ”yhdessä veneessä” eikä vain asiakassuhteessa. Parhaimmillaan projektin lopussa ei enää voi erottaa, kuka on toimittajan ja kuka asiakkaan edustaja.
Nopeasti muuttuvassa maailmassa isoissa projekteissa voidaan käyttää ketteriä menetelmiä monin sprintein.
Claus Günther ja Sakari Lehtonen IDS Scheer Finlandilta selvittivät meille Open BPM:n merkitystä liiketoiminnalle. Claus Güntherin mukaan nykyinen muutosten aika edellyttää kokonaisratkaisuja, liiketoiminnan harmonisointia ja segmentointia. Miten se näkyy attribuuttitasolla? Mitä tehdään itse ja mitä ostetaan?
Kokonaisuuden hallinta tarkoittaa suhteiden hallintaa, asioiden välisten suhteiden ymmärtämistä. Onko tämän hallitseva toimitusjohtajasukupolvi vasta kasvamassa? Kolme vuotta sitten puhuttiin malliin perustuvasta arkkitehtuurista (Model Driven Architecture), nykyisin arkkitehtuurin pitäisi perustua liiketoimintaan (Business Driven Architecture).
Mikä on IN? Olisiko Business Driven SOA? Tulevaisuudessa yritysarkkitehtuuria ja SOA:a hallitaan yhdessä.
Sakari Lehtonen kysyi, miten järjestelmät palvelevat liiketoimintaa kokonaisuutena. Monessa organisaatiossa on kiinnitetty huomiota prosessien hallintaan, mutta laajempi kehikko, sovellukset, tiedot, laitteistot ja integrointi, on jäänyt hoitamatta. Olennaista olisi saada nämä kaikki samaan tietokantaan, jotta tiedetään, mitä sovellusta, tietoja ja laitteistoja tietty prosessi tarvitsee. Miten tällaista tietokantaa ylläpidetään? Tuskin PowerPointilla.
SOA:ssa on aina sama kerrosarkkitehtuuri: käyttöliittymät – integraatioalusta – ERPit. Portaalista tuleva käsky reitittyy integraatiokerroksen läpi keskuskoneelle, jossa kaikki tiedot ovat luontevissa moduuleissa. Muutaman vuoden kuluttua integrointikerroksen korvaa ohjaava kerros.
Entä tulevaisuus? Yrityksellä on yksi sovittu tapa kuvata ohjelmalogiikka, joka voidaan generoida eri alustoille. Prosessit mallinnetaan BPM:lla ja tekniikka UML:lla – ja nämä kuvaustavat pidetään erillään!
Joakim Sandström nSenselta vakuutti innostavassa puheessaan, että tietoturvan testaaminen on osa systeemityötä. Hän kertoi aloittaneensa uusmediahypen aikana ohjelmoijana, törmänneensä koodin tietoturvaongelmiin ja innostuneensa sovellustietoturvahaavoittuvuudesta, josta kukaan ei tuolloin ymmärtänyt mitään. Ohjelmistorobotilla hän löysi viikossa puolesta miljoonasta verkkopalvelusta pari miljoonaa haavoittuvuutta.
Hän kertoi esimerkin, miten oli sovellushaavoittuvuuksia käyttäen muuttanut tilaukseensa 80 %:n alennuksen. Varastomies alkoi kuitenkin ihmetellä suurta alennusprosenttia ja tarttui puhelimeen. Entä tulevaisuudessa, jos tuotantoketju automatisoituu eikä ole enää varastomiestä lukemassa tilausta?
Ohjelmoijille ei kerrota, miten tehdään tietoturvallista SOAP:ia. Heille opetetaan, että ensin koodataan ja sitten testataan, vaikka tietoturva pitäisi rakentaa osaksi koko prosessia.
Monet kuvittelevat, että palomuuri, VPN ja SSL takaavat tietoturvan. Uusia haavoittuvuuksia on kuitenkin 75 % enemmän kuin ennen; nyt ne ovat sovelluksissa eivätkä linjoissa tai palvelimissa.
Jos autoja rakennettaisiin kuin tietojärjestelmiä, niissä ei olisi ikkunoita eikä jarruja; eihän niitä itsestäänselvyyksinä mainittaisi vaatimusmäärittelyissä.
nSense teki vuonna 2006 yli sata turvatestiä, joista löytyi vain viisi puhdasta sovellusta.
Yrityksen pitäisi analysoida, mitä tietoturvaongelmista seuraa? Ensimmäinen raportoitu verkkopankkihaavoittuvuus lienee se, kun äiti jätti verkkopankin auki ja 16-vuotias poika huomasi, että osoitekentässä pyöri tilinumeroita. Hän pääsi vaivattomasti siirtämään rahoja toisten tileiltä.
Http-protokolla on tilaton ja ohittaa kaikki tietoturvat. Se suosii ”pahiksia”. OWASP kuvaa, millaisia haavoittuvuuksia sovelluksista löytyy. Niitä löytyy 80 % sovelluksista, mikäli tietoturvatestaus uupuu.
Tietoturvahaavoittuvuudet voidaan jakaa teknisiin ja loogisiin. Jälkimmäiset liittyvät tilanteisiin, joissa sovellus ei tarkista syötettä: sushia saatiin parissakymmenessä minuutissa, vaikka ohjeellinen vähimmäisaika oli pari tuntia. 95 % haavoittuvuuksista voitaisiin välttää validoimalla syöte ja enkoodaamalla tuloste.
Missään ei rakenneta ohjelmistoja niin, että tietoturvallisuus olisi ohjelmoijasta riippumatonta. Liian usein ohjelmoija itse testaa sovelluksen tietoturvan ja liian harva asiakas vaatii tietoturvallista toimintaa. Tietoturva pitäisi testata silloin, kun ympäristö muuttuu – mutta ympäristöhän muuttuu päivittäin.
Koulutuksessa pitäisi korostaa, että sovelluksen tietoturva on laatukriteeri siinä missä toiminnallisuuskin. Kaikille sovelluksille pitäisi määrittää minimivaatimukset. Organisaatio jää riskianalyysissaan liian usein sille tasolle, että tunkeutujaa ei päästetä palvelimelle, mutta unohdetaan, että tunkeutuja voi hintoja muuttamalla huijata itselleen ilmaiseksi musiikkifirman kaikki kappaleet.
Pentti Virtanen Tieturilta kertoi kouluttajan ottein, miten vaatimukset valmistuvat viikossa. Riittävän pieniksi pilkotuilla kokonaisuuksilla, joita osaavat ihmiset käsittelevät.
Perinteinen vesiputousmenetelmä on kuin organisaatiota vaihdettaisiin joka vaiheen jälkeen ja tieto välitettäisiin kuvauksissa keskustelua välttäen. Ketterissä menetelmissä myönnetään, ettei vaatimuksia saada kerralla oikein – varsinkaan sitä, mitä kaivataan neljän vuoden kuluttua tai ensi joulumarkkinoilla. Sitäpaitsi: jatkuvasti löytyy uusia tapoja tietojärjestelmien toteuttamiseen. Miksi ne jätettäisiin hyödyntämättä kiveen hakatuilla vaatimusmäärityksillä ja tietojärjestelmäprojekteilla?
Sopimukset eivät tee järjestelmää eikä tavoitteena ole voitto välimiesoikeudessa vaan toimiva järjestelmä. Sopimusten sijaan tarvitaan luottamusta ja sopeutumista muutoksiin!
Ketterissä projekteissa asioita tehdään rinnakkain, siksi kalenteriaika lyhenee. Ketteryys edellyttää ammattitaitoisia, motivoituneita ihmisiä sekä kommunikointia tiimien sisällä, niiden välillä ja asiakkaiden kanssa. Projektissa pitää olla riittävästi osaavia ihmisiä, jotka voivat keskittyä päätoimisesti, tuntea ”flown”. Mieluummin tehdään heti tietoturvallista koodia kuin etsitään haavoittuvuuksia jälkeenpäin.
Kallein tapa rakentaa on kokonaishintainen budjetti. Jos järjestelmä tilataan paloissa, voidaan lopettaa ajoissa. Scrum tuottaa asiakkaalle joka kuukausi toimivan sovelluksen, jota on helppo arvioida. Miten perinteisessä projektissa voidaan tietää, milloin sovelluksesta 22 % olisi valmiina?
Millainen projektisuunnitelma on muuttolinnuilla? Niillä ei ole projektipäällikköä ja ne sopeutuvat kulloinkin eteen tuleviin tilanteisiin.
Miten keität perunoita? Mittaatko veden määrän ja perunoiden koon ja lasketko siitä, kuinka kauan perunoiden pitää kiehua? Vai kokeiletko perunoiden kypsyyttä haarukalla?
Ketterät menetelmät eivät ole hopealuoti. Ohjelmistotuotannossa vaikeinta on ajatteleminen.
Byrokraattisessa organisaatiossa, jossa luvan saamiseen menee kuukausia, on vaikea toimia ketterästi. Perinteistä ohjelmistokehityksestä siirrytään ketteriin pienin askelin – aluksi vaikka lisäämällä kommunikointia.
Minna Oksanen SysOpen Digialta innosti meidät Business Intelligencesta. Onko organisaatiosi pulloposti, purjevene vai laiva? Ajelehditko vai ohjaatko itse? Business Intelligence tarkoittaa liiketoimintatiedon hallintaa yhtenäisen tietomallin avulla. Muutosta mitataan mahdollisimman pienin syklein, jotta saadaan konkreettisia tuloksia järkevässä ajassa.
Mitä tällä alueella on tapahtunut kymmenessä vuodessa? Voisiko metatiedoin kertoa, että tiedot liittyvät toisiinsa niin, ettei tietoa tarvitsisi toistaa? Perustiedot keskittyvät transaktioihin, kuutiot analyysiin. Kahden eri järjestelmän raportit saattavat poiketa toisistaan, jos luvut lasketaan eri tavoin. Samalle näytölle voidaan yhdistää eri elementtejä, kunhan tiedot ovat olemassa.
Näkyviä ratkaisuja saadaan sadassa päivässä. Real Time Datawarehousing and Reporting tarjoaa vastauksen kysymykseen, kuinka monelta kalkkunalta pitää katkaista kaula, jotta huomenna liikkeessä on riittävä määrä kalkkunaleikkeitä. Vastaus ei saa perustua viime viikon tilanteeseen, jos huomisen tilaukset ovat jo tiedossa.
Metadatan merkitys kasvaa, mallinnuksesta ei koskaan saa luopua ja liiketoiminnan kanssa pitää keskustella.
Perttu Karvinen ja Mikko Holmberg CodeBakersista kertoivat Java-kehityksessä puhaltavista tuulista. Kehitysrytmi on hidastunut, Java on vakiinnuttanut asemansa, mutta vaihtoehtojakin löytyy. Suppeimmillaan Java on ohjelmointikieli, laajimmillaan ohjelmistoalusta. Skriptikielillä pystytään nopeasti tekemään jotain tilanteissa, joissa Javalla joudutaan vääntämään paljon.
Spring on ohjelmointikehys, joka hoitaa sille esiteltyjen olioiden väliset riippuvuudet. Hibernate on olio-relaatio-tulkki, joka piilottaa relaatiomaailman olio-ohjelmoijalta. Java-koodaajan ei siis tarvitse tietää mitään SQL:stä. Hibernaten ongelmana on, että sovellus voi lähettää SQL-käskyjä ilman, että tulkki huomaa sitä. Eclipse taas on avoin kehitysympäristö.
Ketterään kehitykseen on tulossa kollaboraatioalustoja. Työkalutuki on jo olemassa ja kasvaa jatkuvasti. TDD eli Test Driven Development vaatii aloittamaan testauksen heti. Jatkuva integraatio varmistaa, että koodi toimii. Silti projektinhallintaakin tarvitaan. SOA ja BPM, joista aiemmin puhuttiin, eivät periaatteessa vaikuta sovelluskehitykseen Javalla.
Juhani Snellman Qentinelista kysyi: Testaus, Quo Vadis? Hän aloitti esityksensä kolmesta taidemaalarista, joiden piti kuvata omena. Yksi kuvasi omenan, toinen omenapuun ja kolmas puutarhan, jossa omenapuu kasvoi. Juhani Snellman kuvasi meille testauksen ympäristössään, nopeutuvan liiketoiminnan ja globalisaation puutarhassa, jossa kaikkea halutaan enemmän, nopeammin ja kustannustehokkaammin.
Testaus tekee näkyviksi liiketoiminnan riskit ja mahdollisuudet. Testaus sinänsä ei paranna ohjelmistoa vaan tuottaa relevanttia informaatiota liiketoimintariskien hallintaan. Testaus on ohjelmistokehityksen ja tietojärjestelmähankkeiden tukiprosessi.
Testauksen trendeinä voidaan mainita halpatuotanto, erikoistuminen ja ketterä testaus. Kymmenen erikoistunutta testaajaa voivat korvata tuhat halpatuotantomaista ostettua perustestaajaa.
Ketterän menetelmän kirjat eivät käsittele testausta. Osaava ketterä testaaja tukee sekä kehittäjätiimiä että liiketoimintaa.
Yksikkötesti ohjaa suunnittelua ja hyväksyntätesti tavoitteiden määrittelyä. Näistä voidaan automatisoida ne, jotka eivät vaadi aivokapasiteettia.
Tutkivassa testauksessa testaajan ammattitaito korostuu: hän ei toimi etukäteen mietittyjen määritysten mukaan vaan kokeilee asioita, joista tiedetään, että niissä joskus on ongelmia tämänkaltaisissa järjestelmissä. Kyse on negatiivisesta testaamisesta. Se ei onnistu perinteisessä organisaatiossa, jossa vaaditaan paljon kuvauksia ja testitapausten katselmointia etukäteen.
Siirtyminen perinteisestä ohjelmistokehityksestä ketterään tuottaa välivaiheessa kaaoksen; ihmisen toimintahan ei muutu nopeasti.
Lopuksi Silja Räisänen Osuuspankkikeskuksesta kertoi omien kokemustensa ja Systeemityölehtien valossa, mikä kymmenen vuoden aikana Sytyken laivaseminaareissa on ollut IN.

TieVie minne vie

TieVie minne vie
oppimaan porukassa
verkon ihmeitä

luovuus, joustavuus
luovu, luo uutta, loikkaa
joustavaan verkkoon

innosta verkkoon
organisaatiosi
pehmennä muutos
TieVie, verkko-opetuksen asiantuntijakoulutus käynnistyi orientaatiojakson jälkeen lähiseminaarilla Oulun yliopistossa 30-31.8.07. Ensimmäisen seminaaripäivän aluksi Oulun yliopiston Katja Pura ja Tiina Salmijärvi luotsasivat meidät käytännön kysymyksiin ja kouluttajien esittelyyn, jonka jälkeen Asko Karjalainen, myös Oulun yliopistosta, ravisteli ajatuksiamme koulutusorganisaation prosesseista. Iltapäivän työskentelimme vertaisryhmissä ja illalla verkostoiduimme Kruunumakasiinissa.
Toinen seminaaripäivä alkoi Oulun yliopiston Mailis Aaltosen ja Methods Consultingin Marianne Tensingin ohjaamalla simuloidulla roolileikillä kehittämistyön kompleksisuudesta, mikä herätti monenlaisia tunteita. Iltapäivällä tutustuimme Jyväskylän yliopiston Markku Närhen ja Antti Auerin johdolla opetusta ja ohjausta tukeviin tietojärjestelmiin ja Teknisen korkeakoulun Anna-Kaarina Kairamon johdolla portfoliotyöskentelyyn. Lopuksi Katja Pura ja Tiina Salmijärvi johdattivat meidät seuraavaan, Organisatorinen muutos -verkkojaksoon.
Asko Karjalaisen mukaan koulutusorganisaatio vastustaa muutosta ja noudattaa vanhoja rutiineita, sen kulttuurihan on individualistinen. Ihmisillä on yksilölliset ominaisuutensa, he ovat korvaamattomia. Tutkimuksista paistaa tutkijan kehityshistoria ja asiantuntemus. Korkeakoulu on kuin organisaatio, jossa on kolmesataa toimitusjohtajaa. Jos kolme heistä laatii uuden strategian, se ei välttämättä kiinnosta muita.
Uudet opintosuunnitelmat on ajettu korkeakouluihin ja oikea retoriikka omaksuttu, mutta pääosin kaikki tehtäneen kuten ennenkin. Opiskelijan valmistumisen pitäisi olla seurausta oppimisesta, lopputuloksen laadun pitäisi heijastaa oppimisen hyvyyttä.
Kaikki tunnetut laatujärjestelmät ovat prosessien laadunvarmistusta. Kun laatua kehitetään, prosessit kirjoitetaan auki. Satunnaiset poikkeamat vaikuttavat kuitenkin prosessiin. Jos kurssikalvot eivät ole olleet oppimisalustalla ennen lähitapaamista tai jos kurssikirjoja ei ole riittänyt kaikille, voiko opettaja opettaa ikään kuin kaikki olisivat ennalta tutustuneet aineistoihin?
PowerPoint-ohjelmisto sai kritiikkiä. Asko Karjalaisen mukaan se johtaa opettajan toimimaan lineaarisesti kalvo toisensa jälkeen sen sijaan, että opettaja tilanteesta riippuen voisi joustavasti valita kalvojensa joukosta seuraavan. Jo vuonna 2002 Mart Laanpere totesi NERA:n (Nordic Educational Research Association) konferenssin workshopissa, että PowerPointin lineaarinen esitysmuoto heikentää hänen ajattelutapaansa: se sitouttaa liiaksi lineaariseen sisällysluetteloon. Postmoderni maailmahan vihaa lineaarisuutta. (ks. seminaarimuistiinpanoni.)
Ymmärrän toki, että ranskalaiset viivat suuntaavat ajattelua eri tavoin kuin miellekartta, MindMap, mutta väite kalvojen pakollisesta lineaarisesta järjestyksestä herättää mielessäni kritiikkiä. Osaava luennoitsijahan voi käyttää PowerPointia tilassa, jossa kaikki kalvot näkyvät pikkukuvina. Siitä hänen on helppo tilanteen mukaan – postmodernin joustavasti – valita juuri se helmi, joka iskee luokkahuoneen tai seminaarisalin keskusteluun kuin ilotulitusraketti taivaalle uudenvuoden yönä.
Asko Karjalaisen mukaan laatujärjestelmä sopii tilanteisiin, joissa pitää tuottaa yksinkertainen tuote, tuote, joka on osiensa summa. Inhimilliset yhteistyöprosessit ovat kuitenkin kompleksisia ja ennustamattomia, enemmän kuin osiensa summa.
Organisaatioihin tarvitaan ihmisiä, jotka ovat innostuneita ja kiinnostuneita työstään enemmän kuin sääntöjen noudattamisesta, ”kuumia ryhmiä”, jotka kokeilevat uusia asioita. Sääntöjä kurinalaisesti noudattavan organisaation toiminta on usein tehottomampaa kuin joustavan organisaation. Luova ilmapiiri syntyy vapaudessa eikä noudatettavien sääntöjen tiheikössä. Jokainen tietää, miten mahtavia ovat harrastukset, joissa ihminen voi vapaasti kehittää itseään koko ajan.
Miten opetustilanteet joustaisivat niin, että jokaisen opiskelijan potentiaaliset mahdollisuudet otettaisiin huomioon? Että Suomeen saataisiin enemmän nobelisteja? Oppimisprosessiahan ei voi käynnistää ulkoapäin. Voisiko opettajalle koko prosessin sijaan riittää tietoisuus prosessin päämäärästä?
Asko Karjalaisen kysymykset ja ajatukset innostavat. Viittaako joustava opiskeluprosessi, jossa opettaja prosessin sijaan tietää vain päämäärän, tutkivaan tai trialogiseen oppimiseen? Vai ohjaako opettaja niissä opiskelijoiden valitsemaa prosessia eikä tiedä päämäärää? Yhteisöllisen tiedonrakentelun lopputuloshan parhaimmillaan ylittää jokaisen yksittäisen oppijan ja opettajan tietämyksen rajat.
Mailis Aaltosen ja Marianne Tensingin roolileikin lähtökohtana oli opetusministeriön selvitys yliopiston ja ammattikorkeakoulun toimintojen yhdistämisestä. Selvitysryhmä haastatteli eri osapuolia: tukihenkilöitä, rehtoreita, tutkijoita ja opiskelijoita. Myöhemmin todettiin, että ehkä työelämän edustajia olisi myös pitänyt haastatella.
Hmm! Eri osapuolten valitsijat edustivat ilmeisesti yliopistoja; ammattikorkeakouluissa valtaosa henkilöstöstä on opetushenkilöstöä eli lehtoreita, opettajia ja yliopettajia. Miksi heitä ei nimetty haastateltaviin henkilöstöryhmiin?
Roolileikin myötä opimme, että kehittämistyö tähtää aina muutokseen. Tunneinformaatio on tärkeää ja sitä pitää kuunnella. Nyt jokainen haastateltava ryhmä koki, että selvitysryhmän nopeasti laatima yhteenveto oli pinnallinen eikä ottanut huomioon kaikkia haastateltavien esittämiä asioita. Haastateltavat olivat ensin saaneet yhdet ohjeet ja valmistautuneet sen mukaisesti. Sitten ohjeita muutettiin, porukka hämmentyi ja lopuksi turhautui.
Mitä tästä voisi oppia omaan kehittämishankkeeseen? TieVie-verkko-opetuksen asiantuntijakoulutus ei tähtää vain verkkokurssin rakentamiseen. Meidän pitäisi kasvaa mentoreiksi ja muutosagenteiksi omiin organisaatioihimme, kehittämään yhdessä kollegoiden, esimiesten ja tukihenkilöiden kanssa verkko-opetusta mielekkääksi osaksi toimintaamme. Mistä asioista pitäisi huolehtia? Riittävä pohjatyö voisi rakentaa pohjaa luottamukselle. Kehitystyön hedelmälliset ristiriidat pitää poimia herkästi kuunnellen, niistähän muutokset syntyvät.
Markku Närhi ja Antti Auer kertoivat opetusta ja ohjausta tukevista tietojärjestelmistä: oppimisalustoista, eHopsista, JOPSista, Haka-projektista Shibboleth-tekniikoineen, JOO:sta sekä sosiaalisesta webistä, josta löytyy asiaa myös Helsingin yliopiston Piirtoheitin-verkkolehdessä. Parhaimmillaan opiskelija voi räätälöidä itselleen oppimisympäristön verkkoon ja kerätä sinne RSS-feedein opintojaan koskevat asiat. Elgg-projekti kehittää persoonallisia oppimisyhteisöjä. Sosiaalinen web lähestyy itsensä ylittämistä ja akateemista ajattelua. Pelkkä puuhastelu verkossa ei kuitenkaan riitä, mikäli se ei liity opiskeltaviin aiheisiin.
Tieto- ja viestintätekniikalla korkeakoulut tavoittelevat kustannustehokkuutta ja joustavuutta. Luennot voidaan videoida ja välittää verkossa suurille massoille. Työssäkäyvien opiskelijoiden ei tarvitse enää tulla kampuksille viettämään opiskelijaelämää vaan he voivat opiskella verkossa.
Opetusministeriön Tietohallintostrategiassa vuosille 2006-2015 tavoitteena mainitaan korkeakoulujen yhteistyö ja tietojärjestelmien yhteiskäyttöisyys.
Kaikista opetusta ja ohjausta tukevista tietojärjestelmistä huolimatta valtaosalle opettajista verkko-opetus on edelleen PowerPoint-kalvojen ja pdf-tiedostojen siirtämistä verkkoon ja tehtävien palautusta sähköpostitse.
Anna-Kaarina Kairamo painotti, että portfoliotyöskentelyssä kannattaa miettiä, missä käyttää portfoliota koulutuksen jälkeen. Sen pitäisi olla tallella muuallakin kuin TieVie-koulutuksen oppimisympäristössä, joka sulkeutuu koulutuksen päätyttyä. Voisimme kerätä portfoliota omalle verkkosivustolle tai blogiin, jonka linkittäisimme TieVie-oppimisympäristöön.
Portfoliotyöskentely kannattaa aloittaa heti: Mitä opit Oulun lähiseminaarissa? Mitä odotit ja mitä sait?
Katja Puran ja Tiina Salmijärven kanssa sovimme, että Organisatorinen muutos -verkkojaksolla voimme käsitellä joko oman organisaatiomme tai ministeriön asiakirjoja. Kaikissa koulutusorganisaatioissa strategiat ja kehittämissuunnitelmat eivät ole julkisia asiakirjoja eikä niitä voida edes referoiden käsitellä kaikille TieVie-opiskelijoille avoimella oppimisalustalla.