Pyyntö- & tukipalvelu: jokainen osastojen välinen työpyyntö ja asiakastuki yhdessä auditoitavassa virrassa

IT:stä laadunhallintaan, hallinnollisista töistä tekniseen tiimiin – jokainen osaston työpyyntö ja ulkoinen asiakastukitapaus etenee sähköpostin ja WhatsAppin sijaan yhdessä koodilla varustetussa (TLP-2026-0001), tilakoneella ohjatussa ja auditointijäljen sisältävässä tikettijärjestelmässä. Pyyntö ohjautuu kategorian mukaan oikealle osastolle, otetaan jonosta hoidettavaksi tai osoitetaan henkilölle, käynnistetään, ratkaistaan, varmennetaan ja suljetaan. Jokainen vaihe kirjautuu vain lisättävissä olevaan (append-only) toimintolokiin; kuka teki, milloin ja miksi ei koskaan katoa. Tämä on ITSM-/helpdesk-kerros ja alue, johon ERP-järjestelmäsi ei lainkaan kosketa.

ERP-aukko

ERP-järjestelmässä ei ole "osastolta osastolle -työpyyntöä" objektina

Logo, Mikro, SAP, Netsis tai Uyumsoft ei mallinna pyynnön elinkaarta (avattu → osoitettu → ratkaistu → varmennettu → suljettu), sen uudelleenavausta, sisäisen muistiinpanon ja asiakkaalle näkyvän vastauksen erottamista, SLA-/määräaikaseurantaa tai pyynnön ohjaamista toiselle osastolle ja putoamista sen jonoon. Nämä ovat ERP:n ulkopuolinen ITSM-/helpdesk-tarve. ERP:n pakottaminen tähän käyttäytymiseen räätälöinnillä on sekä arkkitehtuurin vastaista että sietämättömän kallista; siksi useimmat yritykset hukkaavat pyynnöt Exceliin ja sähköpostiin. Portaali lisää tämän kerroksen koskematta ERP:hen; ERP pysyy ainoana totuuden lähteenä.

Keskeiset ominaisuudet

Kategoriapohjainen automaattinen ohjaus

Jokaisella osastolla on omat kategoriansa (esim. IT: Laitteisto / Ohjelmisto / Verkko). Pyyntöä avattaessa valitaan kategoria ja se ohjautuu oikealle osastolle. Jokaisella osastolla on varakategoria 'Muu'; kun pyyntö ohjataan toiselle osastolle, kategoria kohdistetaan automaattisesti kohteen 'Muu'-kategoriaan.

Jonosta ottaminen, osoittaminen ja siirtäminen

Avoin pyyntö odottaa osaston jonossa. Osaston jäsen ottaa pyynnön itselleen (claim), esihenkilö osoittaa sen tietylle henkilölle (assign), ja osoitettu henkilö siirtää sen perusteluineen toiselle saman osaston jäsenelle (transfer). Jokainen tapahtuma tuottaa ilmoituksen ja kirjautuu lokiin.

Ohjaus toiselle osastolle

Väärälle osastolle pudonneen pyynnön esihenkilö ohjaa perustellen oikealle osastolle (redirect). Pyyntö putoaa kohdeosastolla uudelleen jonoon (open), osoitus nollataan ja kategoria kohdistetaan kohteen varakategoriaan. Ohjauksen perustelu säilytetään toimintolokissa.

Guardeilla suojattu tilakone

Päälinja open → assigned → in_progress → resolved → closed; open/assigned-tiloista perusteltu hylkäys tai peruutus, resolved-tilasta uudelleenavaus. Jokainen siirtymä käy yhden transaktion sisällä tilaguardin läpi; vanhentunut näkymä tai samanaikainen toiminto estää virheellisen siirtymän. Suljettu/hylätty/peruutettu pyyntö on päätepiste, eikä ota enää vastaan toimintoja.

Ratkaise–varmenna–sulje -sykli

Osoitettu henkilö merkitsee pyynnön 'ratkaistuksi' ratkaisumuistiinpanolla; sulkemisvaltuus on pyynnön esittäjällä. Esittäjä hyväksyy ratkaisun ja sulkee sen tai avaa uudelleen perustellen (resolved → in_progress, osoitus säilyy). Määritetyn päivämäärän odottaneet ratkaistut pyynnöt suljetaan automaattisesti cron-ajolla.

Sisäisen muistiinpanon ja asiakkaalle näkyvän vastauksen erottaminen

Kommentit voivat olla sisäisiä (is_internal) tai julkisia. Sisäisen muistiinpanon näkevät vain kohdeosaston jäsenet ja esihenkilöt; sitä ei koskaan lähetetä pyynnön esittäjälle. Myös sisäiseen kommenttiin liitetyt tiedostot ovat esittäjältä piilotettuja. Tiimi keskustelee vapaasti keskenään, ja esittäjä näkee vain hänelle suunnatut vastaukset.

Append-only-toimintoloki ja auditointijälki

Avaus, ottaminen, osoittaminen, siirto, ohjaus, käynnistys, ratkaisu, sulkeminen, uudelleenavaus, hylkäys ja peruutus – jokainen toiminto kirjautuu muuttumattomaan toimintolokiin. Hylkäyksen/peruutuksen/ohjauksen perustelut ja siirtokohteet säilytetään lokin meta-kentässä. Kysymykseen 'kuka, milloin, miksi' saadaan aina vastaus.

Prioriteetin, määräajan ja SLA:n seuranta

Jokaiselle pyynnölle annetaan prioriteetti (matala/normaali/korkea/kiireellinen) ja määräaika (due_date). Pyyntöjä seurataan prioriteetin ja määräajan mukaan; myöhässä olevat ja lähestyvät pyynnöt nousevat esiin. Roolipohjaiset näkymät 'minulle osoitetut / osaston jono / avaamani' tekevät työmäärän seurannasta selkeää.

Asiakastuen versio

Sama infrastruktuuri toimii myös ulospäin suunnattuna tukipalveluna: yritys- ja tuotekohtainen kirjaus, tukikategoria/-tyyppi, ilmoitussähköposti sekä osoitus- ja vastausvirta. Sisäiset työpyynnöt ja ulkoiset asiakastukipyynnöt hallitaan yhdessä kurinalaisessa mallissa.

Kuinka se toimii

01

Pyyntö avataan ja saa koodin

Työntekijä (tai asiakas) avaa pyynnön otsikolla, kuvauksella, kohdeosastolla, kategorialla, prioriteetilla ja mahdollisella määräajalla; liittää tiedostoja. Pyyntö saa yksilöllisen koodin (esim. TLP-2026-0001) ja kohdeosaston esihenkilöille lähtee ilmoitus.

02

Ohjataan ja otetaan hoidettavaksi

Pyyntö putoaa osaston jonoon. Jäsen ottaa sen itselleen tai esihenkilö osoittaa sen jollekulle. Jos pyyntö tuli väärälle osastolle, se ohjataan perustellen oikealle osastolle ja putoaa siellä uudelleen jonoon.

03

Käynnistetään ja ratkaistaan

Osoitettu henkilö käynnistää pyynnön (in_progress), etenee tiimin kesken sisäisillä muistiinpanoilla ja tarvittaessa siirtää sen saman osaston sisällä. Työn valmistuttua pyyntö merkitään 'ratkaistuksi' ratkaisumuistiinpanolla ja esittäjää tiedotetaan.

04

Varmennetaan ja suljetaan

Esittäjä hyväksyy ratkaisun ja sulkee sen tai avaa uudelleen perustellen. Jos hyväksyntää ei tule, järjestelmä sulkee pyynnön automaattisesti määritellyn päivämäärän jälkeen. Jokainen vaihe kirjataan auditointijälkeen.

Kuinka se liittyy ERP-järjestelmääsi

Pyyntö- & tukipalvelu on ytimeltään puhdas intranet-/ITSM-kerros; sillä ei ole ERP:ssä vastaavaa objektia eikä se ole toiminnassaan riippuvainen ERP:stä. Suhde ERP:hen rakentuu perustiedon (henkilöstö, osasto, organisaatio) syöttämisen ja pyyntöjen tulosten liittämisen kautta asianomaisiin operatiivisiin moduuleihin.

Henkilöstö- ja osastoperustiedot

Pyynnön esittäjät, osoitetut henkilöt, esihenkilöt ja osastohierarkia syötetään ERP:stä/HR-moduulista vain luku -tilassa peilatulla henkilöstö- ja organisaatiotiedolla. Osastoesihenkilön määrittely ja jäsenyydet tulevat tästä perustiedosta; erillistä käyttäjälistaa ei tarvitse ylläpitää.

Moduulien välinen silta

Jos pyyntö laukaisee kulun, kunnossapidon työmääräyksen, hankintapyynnön tai varallisuuden siirron, se liitetään asianomaiseen moduuliin; hyväksyntää vaativat vaiheet siirretään keskitettyyn hyväksyntämoottoriin. Näin pyyntötapahtumat yhdistyvät muiden portaalin prosessien kanssa yhteen auditoitavaan virtaan.

Toimii koskematta ERP:hen

Tiketin elinkaari etenee kokonaan portaalissa; ERP:hen kirjoittaminen ei ole pakollista. ERP pysyy ainoana totuuden lähteenä, eikä portaali muuta sitä lainkaan tätä ITSM-tarvetta varten. Haluttaessa ratkaistujen pyyntöjen yhteenveto yhdistetään raportointikerroksessa ERP-tiedon kanssa.

Liittyvät moduulit

Usein kysytyt kysymykset

Molempia. Sama kurinalainen infrastruktuuri hallitsee sekä osastojen välisiä sisäisiä työpyyntöjä (IT, laadunhallinta, hallinnolliset työt, tekninen) että yritys- ja tuotekohtaisia ulkoisia asiakastukipyyntöjä. Sisäpuolella toimivat kategoriapohjainen ohjaus, itselleen ottaminen, osoittaminen, siirto ja tilakone; ulkopuolella yritys/tuote, tukikategoria-tyyppi, ilmoitussähköposti ja vastausvirta.
Esihenkilö ohjaa pyynnön perustellen oikealle osastolle. Pyyntö putoaa kohdeosastolla uudelleen jonoon, osoitus nollataan ja kategoria kohdistetaan automaattisesti kohteen 'Muu'-varakategoriaan. Ohjauksen perustelu sekä se, mistä minne pyyntö siirtyi, säilytetään pysyvästi toimintolokissa.
Ei. Kommentit merkitään sisäisiksi tai julkisiksi. Sisäiset muistiinpanot ja niihin liitetyt tiedostot näkevät vain kohdeosaston jäsenet ja esihenkilöt; niitä ei koskaan lähetetä pyynnön esittäjälle. Tiimi tekee vapaasti sisäistä arviointia, ja esittäjä näkee vain hänelle suunnatut julkiset vastaukset.
'Ratkaistuksi' ratkaisumuistiinpanolla merkityn pyynnön sulkemisvaltuus on esittäjällä; hän joko hyväksyy tai avaa uudelleen perustellen. Jos esittäjä ei tee mitään toimenpidettä, järjestelmä sulkee pyynnön automaattisesti määritellyn päivämäärän lopussa ja kirjaa tämän auditointijälkeen toimijana 'järjestelmä'. Näin ratkaistut pyynnöt eivät jää auki loputtomiin.
Kyllä. Avauksesta sulkemiseen jokainen toiminto (ottaminen, osoittaminen, siirto, ohjaus, käynnistys, ratkaisu, uudelleenavaus, hylkäys, peruutus) kirjautuu muuttumattomaan toimintolokiin. Perustelut sekä siirto-/ohjauskohteet säilytetään lokin meta-kentässä. Jokaisella pyynnöllä on täydellinen auditointijälki; yksikään vaihe ei katoa eikä sitä voi jälkikäteen hiljaisesti muuttaa.

Näe Pyyntö- & tukipalvelu (tiketit) livenä

Kerro ERP:si ja prosessisi. Näytämme, miten tämä moduuli toimii, ja sisällytämme sen tilaukseesi — ei henkilötyöpäivä-, lisenssi- tai käyttöönottomaksua.

Varaa esittely →