Objektien elinkaari

Yrityksen tuotetiedonhallintaa helpottava ohjelma voi olla PDM-järjestelmä (product data management) tai PLM-järjestelmä (product lifecycle management). Jälkimmäinen on laajempi ja sisältää myös näkökulman PDM-objekteihin liittyviin prosesseihin. Vertex Flow on PLM-järjestelmä. Siinä on ohjelmiston alusta lähtien tuettu prosessinäkökulmaa, vaikka tuoreesta ohjelmasta ei vielä käytetty nimitystä PLM. Siihen, minkälainen prosessinäkökulma on, vaikuttaa mm. yrityksen toimiala, vakiintuneet käytännöt ja asiakasvaatimukset. Yksinkertaistettuna voidaan sanoa, että yleensä hyvin moni objekti käy elinkaarensa aikana eri vastuuhenkilön työpöydällä, osallistuu erilaisiin prosesseihin ja saa erilaisia leimoja – tiloja – yrityksen liiketoiminnan mukaisesti. Objektin tila viestittää kaikille Flow-käyttäjille, mitä objektille on tehty ja mitä seuraavaksi tapahtuu. Tähän liittyy vielä se, kenen vastuulla seuraava operaatio on. On hieman vaihtelua siinä, kuinka laajalti kaikki nämä operaatiot hoidetaan Vertex Flow-järjestelmässä, mikä kuuluu CRM:n piiriin ja mikä on ERP:n rooli tässä kaikessa. Lyhyesti sanottuna, eri vaiheissa tulisi käyttää sitä ohjelmaa, joka parhaiten palvelee yritystä ja sen henkilökuntaa. Yritystä parhaiten palveleva ohjelma ei välttämättä ole se, joka parhaiten palveli prosessien hallinassa esim. 15 vuotta sitten. Ohjelmien roolia tulisi jokaisessa yrityksessa aika-ajoin tarkentaa.

Objektin tilan asetus ei ole itseisarvo. Tilaa ei aseteta siksi, että tietojärjestelmässä on tällainen mahdollisuus. Tila asetetaan, jos se palvelee työyhteisöä ja työprosessia. Esim. asiakas on Flow'n objekti, jonka tila ei välttämättä tuo mitään lisäarvoa. Objektien erilaiset tilat ja se, vaihdetaanko jollekin objektille tila vai ei ja missä vaiheessa, määräytyy käyttötarpeen mukaan jo käyttöönottovaiheessa.

Projektin elinkaari

Tarkastellaan aluksi esimerkkinä projektia. Se voi olla yrityksen sisäinen projekti, tyypillisesti tuotekehitysprojekti, mutta tarkastellaan tässä kaikille tutumpaa asiakasprojektia. Yleensä siinä on kyse jonkin tuotteen räätälöinnistä jonkin tietyn asiakkaan tarpeita silmälläpitäen. Yksinkertaistettuna: asiakas ottaa ensin myyjään yhteyttä tuotteen muutostarpeista ja sitten projekti tarjotaan asiakkaalle. Jos kaupat saadaan, suunnittelu tekee muutokset tuotteeseen ja lähettää työmääräimen valmistukseen. Sieltä räätälöity tuote lopulta toimitetaan asiakkaalle. Projektin tiloja voisi kuvata seuraavanlainen tilamalli:

Tila	Vastuu	Merkitys
TARJOUS	Myyjä	Asiakas on pyytänyt tarjousta. Tarjous on tekeillä tai jo lähetetty ja odottaa asiakkaan päätöstä.
PERUTTU	-	Tarjous ei johtanut kauppaan
MYYTY	Suunnittelupäällikkö	Projekti on myyty ja odottaa suunnittelupäällikön toimenpiteitä, jotta projekti saadaan työn alle.
SUUNNITTELU	Suunnittelija	Tuotteen muutokset tekeillä asiakkaan lähettämän speksin mukaisesti
VALMIS	Tuontopäällikkö	Projektin edellyttämät muutokset ovat suunnittelun kannalta valmiit. Vastuu siirtyy tuotantoon.
TOIMITETTU	-	Tuote on toimitettu asiakkaalle ja lasku lähetetty. Tämä tila on projektin päätöstila Flow'ssa.

Yllä on esitetty yksi mahdollinen asiakasprojektin tilamalli. Tässä esimerkissä on yrityskohtaista vaihtelua tyypilisesti kahdessa tilassa:

Kaikki eivät perusta projektia vielä tarjousvaiheessa - vasta sitten kun myyntitilaus on tehty, perustetaan projekti. Kuitenkin projektin perustaminen jo tarjousvaiheessa Flow'hun mahdollistaa asiakkaan tietojen liittämisen projektiin (näin säilyy muistissa, mitä k.o. asiakkaalle on aikojen saatossa tarjottu). Samaten asiakasvaatimukset voidaan tallentaa FLow'hun ja liittää johonkin projektiin (tarjousprojektiin), jotta ne olisi myöhemmin helppo löytää.
Se, missä vaiheessa projektin käsittely Flow'ssa päättyy ja siirtyy esim. ERP:iin, vaihtelee tapauskohtaisesti. Saattaa olla, että projektin tila "VALMIS" on sen päätetila Flow'ssa ja sen jälkeen projektia - sen valmistusta ja toimitusta - valvotaan toisaalla. Kuitenkin Flow-projekti tarjoaa joka tapauksessa työskentelykentän myös jälkimarkkinoinnille. Projektiin yleensä liitetään myyty, räätälöity nimike, jolloin jälkimarkkinoinnin on helppo löytää tarvitsemansa tiedot Flow'sta.

Objektin elinkaari voi vaihdella tapauksesta riippuen. Projekti syntyisi yllä esitetyssä esimerkissä aina tilassa "TARJOUS". Jos tarjous ei johda kauppaan, seuraava tila olisi asiakkaan hylättyä tarjouksen "PERUTTU". Tilamallissa pitää siis olla sallittu tilasiirtymä "TARJOUS" → "PERUTTU". Normaalitapauksessa projekti etenee tilasta toiseen ylläolevan taulukon mukaisesta riviltä seuraavalle (lukuunottamatta "PERUTTU"-tilaa) ja päätyisi lopulta tilaan "TOIMITETTU". Jos asiakas ottaa yhteyttä suunnittelun jo ollessa käynnissä ja pyytää lisämuutoksia, projekti saattaa olla järkevää asettaa jälleen "TARJOUS"-tilaan odottamaan myyjän toimenpiteitä.

Nimikkeen elinkaari

Nimike on Flow-järjestelmässä hyvin keskeisellä sijalla, sillä siihen liitetään piirustukset ja mallit ja mahdollisesti myös dokumentteja. Ilman nimikkeitä ei voisi perustaa nimikerakenteita. Nimike on yleensä (rakenteineen) se osa suunnittelun tuotoksista, joka siirretään ERP-järjestelmään. Juuri tämä siirto perustuu nimenomaan nimikkeen tilaan. Tyypillinen nimikkeen tilamalli kattaa seuraavat tilat:

Tila	Vastuu	Merkitys
LUONNOS	Suunnittelija	Nimike on perustettu. Nimikkeen tietojen syöttö on kesken.
VALMIS	Suunnittelija	Nimikkeen tiedot on syötetty. Odottaa tarkastusta.
TARKASTETTU	Pääsuunnittelija	Nimike on tarkastettu. Odottaa hyväksyntää.
HYVÄKSYTTY	Tuotantopäällikkö	Nimike on hyväksytty ja siirretty ERP:iin ja tuotantoon.
KÄYTÖSTÄ POISTETTU	Pääsuunnittelija	Nimike on korvattu jollakin toisella vastaavalla nimikkeellä.
HYLÄTTY	Pääsuunnittelija	Nimike ei ole käytössä.

Yllä olevassa esimerkissä vaihtelua installaatiosta toiseen voi olla tyypillisesti tarkastus- ja hyväksymiskäytännöissä: joissakin yrityksissä tarkastusta ei tehdä lainkaan, toisissa ei myöskään hyväksyntää. Jos ERP-siirto on käytössä, jokin tai jotkut nimikkeen tilat toimivat siirron käynnistäjinä. Tilan merkitys on kahtalainen: yhtäältä se toimii siirron käynnistäjänä, mutta toisaalta se samalla ilmaisee kaikille käyttäjille, että siirto on jo tehty. Jos taas nimikkeen tila on "LUONNOS", se kertoo kaikille käyttäjille, että ERP-siirtoa ei ole vielä tehty. Flow-käytössä ei siis ole epätietoisuutta siitä, onko jokin nimike siirretty ERP:iin vai ei. Esimerkkitaulukossa tyypilliset tilasiirtymät ovat ylimmältä riviltä rivi kerrallaan alaspäin aina "HYVÄKSYTTY"-tilaan asti. Tämän jälkeen tiloihin "KÄYTÖSTÄ POISTETTU" tai "HYLÄTTY" siirrytään vain tarpeen vaatiessa. Jos käytössä on tarkastusmenettely, tarkastaja voi muuttaa nimikkeen tilan "VALMIS" takaisin tilaan "LUONNOS" ja asettaa vastuuhenkilöksi suunnittelijan mikäli tarkastuksessa todetaan jotakin huomautettavaa.

Objektien tilamalli on tehty Flow-käyttäjän työtä helpottamaan. Eri objekteille on Flow'n toimitusversiossa jo valmiiksi mietitty, tyypillinen tilamalli, joka monesti sellaisenaan soveltuu käyttöön. Tilamallia ja tiloja lisätään tai poistetaan Flow'n käyttöönottovaiheessa vain jos toimitusversion tilamalli ei tarjoa kaikkia niitä ominaisuuksia, joita yrityksen Flow-käytössä tarvitaan. Toimitusversiossa on tilamalleja, joita käytetään vain jollekin tietylle objektille, mutta jotkut tilamallit (esim. "Standard") on käytössä nimikkeelle, piirustukselle ja mallille. Lähtökohta on aina, että toimitusversion tilamalleja käytetään sellaisenaan, mutta jos tämä ei riitä, lähdetään tekemään sovitustyötä.

Käytöstä poistetut nimikkeet

Flow'ssa on hyvä pitää näkyvissä ja käytettävissä vain saatavilla (varastossa) olevia nimikkeitä. Ei siis kaikkea, mitä rautakaupasta löytyy. Joitakin nimikkeitä on silti pantu ”piiloon” eli KÄYTÖSTÄ POISTETTU -tilaan.
Saat ne näkyviin asettamalla nimikehakuun suodatukseksi em. tilan. Oletuksena käytöstä poistettuja objekteja ei näytetä hakutoiminnoissa lainkaan.
Jos haluat ottaa käytöstä poistetun nimikkeen takaisin käyttöön, vaihtoehtoja on kolme:

vaihda nimikkeen tila, jos tilamalli mahdollistaa tämän,
pakota pääkäyttäjänä nimikkeen tila DRAFTiksi tai
kopioi nimike uudeksi nimikkeeksi