pdf-muodossa. - Tampereen ammattikorkeakoulu
pdf-muodossa. - Tampereen ammattikorkeakoulu
pdf-muodossa. - Tampereen ammattikorkeakoulu
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
196<br />
Eräänlaisena esimerkkinä erittäin pitkälle<br />
viedystä tuotetiedon määrittelystä voitaisiin<br />
pitää NATO:n ylläpitämää koodistoa,<br />
jossa jokaiselle useammin käytetylle<br />
tuotteelle muodostetaan tarkka koodi sen<br />
mukaan, miten koodisto ja siihen nojaava<br />
kriteeristö (ACodP-1, ks. lähteet) kyseisen<br />
tuotteen määrittelevät. Tuotteita jaotellaan<br />
ensisijaisesti Fit, Form & Function –periaatteen<br />
mukaisesti eli eri valmistajalta/toimittajalta<br />
saatavat tuotteet määritellään samoiksi,<br />
mikäli ne täyttävät samat kriteerit ja toimivat<br />
näin ollen samalla tavalla samassa käyttötarkoituksessa.<br />
Tuotteiden tunnistaminen,<br />
koodaaminen ja järjestelmään tallentaminen<br />
vie kohtuullisen paljon aikaa, mutta on välttämätöntä,<br />
sillä käytettävä tuotemäärä on<br />
hyvin massiivinen ja vastaavien tuotteiden<br />
tunnistaminen elintärkeää esim. kriisialueilla<br />
tapahtuvissa tehtävissä.<br />
Epäonnistumisen eri tasot ja muodot<br />
Informaatiologistinen järjestelmäkokonaisuus<br />
voidaan määritellä, suunnitella tai rakentaa<br />
väärin. Toimittajat eivät esimerkiksi välttämättä<br />
ymmärrä tilaajan tarpeita tai myyvät siitä huolimatta<br />
tilaajalle sopimattoman tuotteen – jos<br />
ei muuten, niin raskaasti räätälöitynä. Myös<br />
käyttöönotto voidaan toteuttaa virheellisesti<br />
tai täysin mahdottomassa järjestyksessä. Testaamatta,<br />
kouluttamatta tai yhteensovittamatta.<br />
Suuri osa segmenteistä, transaktioista, moduleista<br />
tai kokonaisista järjestelmäkokonaisuuksista<br />
voi jäädä käyttämättä pitkäksi aikaa tai<br />
jopa kokonaan virheellisen tai puutteellisen<br />
käyttöönoton seurauksena. Esim. ennusteita<br />
ei järjestelmästä saada ulos siksi, että tiettyjä<br />
osia ennusteita laativien toimintojen vaatimasta<br />
historiadatasta ei ole saatavilla (koska niitä ei<br />
ole koskaan syötetty eikä syöttämistä ehkä ole<br />
koskaan kenellekään ohjeistettu tai määrätty).<br />
Mitä spesifimpi tai monimutkaisempi järjestelmä,<br />
sitä vaikeampaa on käyttöönotto ja<br />
toisaalta sen vaikeammaksi sen tehokas ylläpito<br />
ja käyttö muodostuu. Spesifiset järjestelmät<br />
ovat yleensä suppeita liittymämahdollisuuksiltaan<br />
ja toisaalta monimutkaiset, laajat<br />
järjestelmät sisältävät harvoin hyviä työkaluja<br />
tai selkeän, intuitiivisen käyttöliittymän. Muutamia<br />
esimerkkejä:<br />
Otetaan käyttöön tiedon- ja dokumentinhallintajärjestelmä.<br />
––<br />
Järjestelmää laajennetaan heti alusta siten, että siinä on päällekkäisiä ominaisuuksia<br />
jo olemassa olevien järjestelmien kanssa vaikka olemassa olevista järjestelmistä ei ole<br />
aikomustakaan tehdä liitäntöjä uuteen järjestelmään tai toisaalta korvata vanhoja.<br />
––<br />
Järjestelmään ei tutustuta riittävissä määrin määrittelyvaiheessa, vaan se otetaan heti käyttöön<br />
kokonaisuudessaan koska ajatellaan, että sitä tarvitaan nyt konfiguraationhallintaan,<br />
HR-datan säilömiseen jne. ja se ”melko varmasti” taipuu myös muihin toimintoihin.<br />
Myöhemmin se kuitenkin havaitaan liian monimutkaiseksi soveltaa ja liittymät muihin<br />
järjestelmiin sekä rajapintojen räätälöinti kalliiksi toteuttaa. Lopullisen iskun antaa lähes<br />
mahdottomaksi muodostuva käyttäjien oikeuksien hallinta ja järjestelmä hylätään.<br />
Otetaan käyttöön palvelupyyntöjärjestelmä.<br />
––<br />
Helpdesk, palvelupiste, tilauskeskus tjms. ottaa vastaan pyynnöt ja kirjaa järjestelmään<br />
– – Järjestelmään ei ole pääsyä kuin pääkäyttäjillä, eikä järjestelmästä ole liittymää muihin<br />
sovelluksiin. Järjestelmään ei myöskään kirjata ratkaisutietoa kuin yleisellä tasolla.
Change language