Noutolokerojärjestelmä yrityksessä: arkkitehtuuri, ohjelmistointegraatio ja kitkaton toiminta

Eine Referenz netNotdienst und Abholfachanlage im Unternehmen klingt im ersten Moment nach einem überschaubaren Infrastruktur-Thema: ein Schrank mit Fächern, ein Terminal, ein paar Türen. In der Praxis wird daraus sehr schnell ein geschäftskritischer Ausgabekanal – für Ersatzteile, Werkzeuge, Dokumente, Muster, IT-Equipment oder interne Sendungen. Damit die Anlage wirklich „ohne Reibungsverluste“ funktioniert, muss sie mehr können als öffnen und schließen: Sie muss Aufträge erkennen, Identitäten sicher prüfen, Berechtigungen korrekt ableiten, Vorgänge revisionsfähig protokollieren und bei Störungen kontrolliert weiterarbeiten.

Dieser Beitrag beschreibt eine praxistaugliche Zielarchitektur und die wichtigsten Integrations- und Betriebsentscheidungen. Fokus sind nicht Geräte-Details oder Herstellerfeatures, sondern das, was IT-Leitung, Administration und technische Projektverantwortliche im Alltag wirklich spüren: Schnittstellen, Datenflüsse, Identitätsmanagement (IAM), Security, Monitoring, Fallbacks, Wartung und die Frage, wie man eine Referenz netNotdienst und Abholfachanlage so in die bestehende Systemlandschaft einbettet, dass sie dauerhaft stabil und erweiterbar bleibt.

Warum eine Abholfachanlage mehr als „Hardware“ ist

Der Nutzen entsteht nicht durch das Möbelstück, sondern durch den Prozess: Wer darf was abholen, wann, warum – und wie wird das nachweisbar? Sobald eine Anlage Material ausgibt, berührt sie typischerweise mehrere Unternehmensbereiche:

• Logistik/Intralogistik: Übergabe, Bestandsführung, Nachschub, Rückläufer.
• Produktion/Service: Materialverfügbarkeit, Entstörung, 24/7-Bereitstellung.
• IT/IAM: Benutzer, Rollen, Authentifizierung, Berechtigungen, Lifecycle (Joiner/Mover/Leaver).
• Compliance/Security: Audit-Logs, Nachvollziehbarkeit, Missbrauchsvermeidung.

Diese Querbezüge sind der Grund, warum Projekte scheitern oder zäh werden, wenn man die Abholfachanlage isoliert betrachtet. Reibungsverluste entstehen fast immer an den Übergängen: zwischen ERP und Ausgabepunkt, zwischen Identität und Berechtigung, zwischen Online-Betrieb und Offline-Situation, zwischen Störung und sauberem Incident-Prozess.

Zielbild: Abholfachanlage als integrierter Ausgabekanal

Ein belastbares Zielbild behandelt die Anlage als System aus Hardware, lokaler Steuerung und zentralen Diensten. Bewährt hat sich eine Aufteilung in drei Ebenen:

• Edge/Anlage: Controller/Terminal vor Ort, Türsteuerung, Sensorik (Türkontakt), ggf. Scanner/Leser, lokale Pufferspeicher.
• Integration Layer: Ein zentraler Dienst, der Geschäftsdaten, Berechtigungen und Gerätestatus zusammenführt (oft als REST-Service, also als HTTP-basierte Schnittstelle, betrieben).
• Backends: ERP, DMS/ECM, Ticketing/ITSM, IAM (z. B. Active Directory/Azure AD), Monitoring/Logging-Plattform.

Der entscheidende Punkt: Die Anlage sollte nicht „direkt“ in alle Backends sprechen müssen. Eine zentrale Integrationsschicht reduziert Komplexität, entkoppelt Herstellerprotokolle und schafft einen Ort, an dem Security, Audit und Betrieb konsistent umgesetzt werden können.

Architektur-Entscheidungen, die später über Betriebskosten entscheiden

1) Direktanbindung vs. Integrationsservice

Monet laitteet tarjoavat omia integraatioita tai plugineja. Se voi toimia lyhyellä aikavälillä, mutta kasvattaa pitkällä tähtäimellä riippuvuutta valmistajavaatimuksista, päivityssykleistä ja vaikeasti testattavista kytkennöistä. Yksi integraatiopalvelu (keskitetty backend-palvelu) luo selkeät vastuut:

• Yhtenäiset API:t tilaukselle, käyttöoikeudelle, luovutukselle ja palautukselle
• Standardoitu autentikointi (esim. OAuth2/OpenID Connect tai SAML 2.0 – SAML on yleinen yrityksissä käytetty Single-Sign-On-menetelmä)
• Keskitetty lokitus ja audit-logit
• Rajapintojen selkeä versiohallinta

Käytön ja ylläpidon kannalta tämä on yleensä ero sen välillä, että „jokainen päivitys on riski“ ja että „meillä on kontrolloitu muutosprosessi“.

2) Tapahtumapohjainen vs. kyselypohjainen

Päivittäisessä käytössä laitteen pitää tietää, onko uusia noutotehtäviä, ovatko lokerot varattuja, onko ovi auki. Kaksi mallia ovat tavallisia:

• Kysely (polling): Laite kysyy x sekunnin välein uusia tehtäviä. Yksinkertaista, mutta aiheuttaa kuormitusta, tuntuu hitaalta ja häiriöissä vaikea arvioida puhtaasti („kysyykö se vielä?“).
• Tapahtumapohjainen: Backend lähettää tapahtumia (esim. Message Queue:n tai webhookien kautta). Reagoi nopeasti ja tehokkaasti, mutta vaatii luotettavan toimituksen, uudelleenyrittämislogiikan ja monitoroinnin.

Monissa yritysympäristöissä hybridi-lähestymistapa on robusti: tapahtumat normaalikäyttöön, polling fallback-ina/terveystarkistusmekanismina.

3) Pelkkä online vs. offline-varavaihtoehto

„24/7“ on usein tavoite – verkon todellisuus ei ole sitä. Noutopiste tarvitsee määritellyn strategian offline-tilanteisiin: switch, VLAN-muutos, proxy-virhe, sertifikaatin vanheneminen, DNS-ongelmat. Ilman offline-varavaihtoehtoa pienet häiriöt eskaloituvat välittömästi operatiivisiksi katkoksiksi.

Hyväksi todetut minimivaatimukset:

• Paikallinen välimuisti lyhytaikaisesti voimassa oleville nouto-oikeuksille (voimassaoloajan kanssa)
• Paikallinen lokikirjaus transaktioista (luovutus/palautus) myöhempää synkronointia varten
• Selkeät offline-säännöt: mikä on sallittua, mikä on estetty (esim. arvokkaat tavarat vain online)

Tärkeää: offline-kyvykkyys ei ole „ylimääräinen“, vaan osa turvallisuus- ja käyttöarkkitehtuuria. Välimuisti ei saa luoda „pysyviä avaimia“, vaan sen on vanhentua hallitusti ja olla yksiselitteisesti auditoitavissa.

Ohjelmistointegraatio: Mitkä datavirrat ovat todellisuudessa tarpeen

Noutopistettä voidaan käyttää hyvin erilaisissa prosesseissa. Silti integraatiossa esiintyvät ydinobjektit ovat samankaltaisia:

• Käyttäjä/identiteetti: työntekijän ID, nimi, tila, roolit, mahdollinen kustannuspaikka.
• Noutotehtävä: viite (esim. tilaus/komissio), oikeutettu, voimassaolo, prioriteetti.
• Lokerovaraus: lokeron numero, koko, käyttötilanne, aikaväli.
• Tapahtuma: avaus, otto vahvistettu, ovi suljettu, mahdollinen peruutus.
• Audit-loki: kuka milloin avasi minkä lokeron, millä perusteella ja millä tuloksella.

Näitä objekteja tulisi ylläpitää integraatiokerroksessa kanonisena mallina. „Kanoninen“ tarkoittaa: riippumaton valmistajasta, sisäisistä tietokantarakenteista tai ERP-yksityiskohdista. Näin arkkitehtuuri säilyy siirrettävänä, jos ERP, DMS tai laitevalmistaja vaihtuvat.

ERP-integraatio: Varaston ja tilausten logiikan selkeä erottelu

ERP (tai WMS/MES) on usein totuuden lähde materiaali-, kommissiointi- ja varastotiedoille. Noutolokerijärjestelmän ei kuitenkaan pidä muuttua toiseksi ERP:ksi. Tyypillisiä integraatiomalleja:

• ERP luo noutotilauksen: esim. „Kommission valmis noutoa varten“, vastaanottaja ja aikaväli mukana.
• Integraatiopalvelu varaa lokeron: perustuen lokeroiden kokoon, sijaintiin ja käyttöasteeseen.
• Järjestelmä ilmoittaa luovutuksen: transaktio välitetään integraatiopalvelulle, joka raportoi takaisin ERP:lle.

Tärkeää on vastuiden erottelu: järjestelmä hallinnoi lokeroita ja transaktioita, ERP hallinnoi materiaalitaloutta. Välissä on integraatiologiikka, joka kääntää tilat ja tekee virhetapaukset hallittaviksi (esim. „lokero avattu, noutoa ei vahvistettu“).

DMS/ECM ja dokumenttiprosessit

Joissain skenaarioissa siirretään dokumentteja (tarkastusraportit, rahtikirjat, sopimusasiakirjat). DMS/ECM (dokumentinhallinta-/Enterprise Content Management) voi olla joko lähde tai kohde. Teknisenä kannanottona kaksi seikkaa ovat olennaisia:

• Tietojen minimointi: laitetta ei yleensä tarvitse tallentaa itse dokumenttia, vaan ainoastaan viitteen ja siirron tilan.
• Todentaminen: kuka nouti ja milloin – tapahtumana DMS-/workflowissa tai keskitetussa audit-lokissa.

Näin vältetään, että dokumentit jäävät „varjotallenteiksi“ laitteiden kontrollerien levyille, joita on vaikea suojata ja varmuuskopioida.

Identiteetit ja käyttöoikeudet: toteuta IAM huolellisesti

Yleisimmin aliarvioitu kehityskohde on identiteetti- ja käyttöoikeusmalli. Noutolokerijärjestelmä on fyysinen pääsypiste – virheiden riski on siksi merkittävä. Kaksi periaatetta auttavat:

• Single Source of Truth: identiteetit tulevat IAM:sta (esim. Active Directory tai Azure AD). Ei rinnakkaisia käyttäjälistoja järjestelmässä, paitsi lyhytaikaisena välimuistina.
• Roolit yksittäisten oikeuksien sijaan: käyttöoikeudet tulisi johtaa rooleista/säännöistä (esim. „vuoronjohtaja“, „IT-jakelu“, „työkalujakelu“), täydennettynä tilauskohtaisilla käyttöoikeuksilla.

Terminaalin todennus: kortti, PIN, QR, mobiili

Ympäristöstä riippuen eri todennustavat ovat perusteltavia. IT:lle merkittävämpää kuin „ominaisuudet“ on käytön luotettavuus:

• Kortti/Badge: helppo integroida, mutta elinkaaren hallinta (estot katoamisen yhteydessä) on toimittava luotettavasti.
• PIN: mahdollista käyttää toisena tekijänä, mutta organisatoriset kysymykset (resetointi, tuki) ovat merkittäviä.
• QR-koodi/Token: käytännöllinen kertanoutoihin tai ulkoisille kumppaneille, mutta edellyttää token-hallintaa ja voimassaoloaikojen määrittelyä.
• Mobiili/SSO: houkutteleva, mutta riippuvainen WLAN/verkosta ja päätelaitepolitiikasta (MDM eli Mobile Device Management).

Päätöntä on, että todennus ja valtuutus käsitellään erillisinä: todennus vastaa „kuka olet?“, valtuutus „saatko tehdä sen?“. Integraatiokerroksessa tämän voi toteuttaa johdonmukaisesti ja auditoitavasti.

SAML 2.0, OIDC ja tekniset realiteetit

Monilla yrityksillä on käytössä SSO-standardit: SAML 2.0 on yleinen perinteisissä yritysportaaleissa, OpenID Connect (OIDC) puolestaan nykyaikaisemmissa web- ja API-arkkitehtuureissa. Noutolokerijärjestelmän kannalta on olennaista, missä nämä protokollat päättyvät:

• Terminaalissa itsessään (jos kyseessä on täysiverinen selain-/kioski-asiakas)
• Integraatiopalvelussa (terminaali todentaa teknisesti, käyttäjän kirjautumistiedot välitetään eteenpäin)

Käyttöpisteestä katsottuna yleensä vakaampaa on, että terminaali on kevyt ja identiteettilogiikka pysyy keskitettynä. Näin sertifikaatit, tokenien voimassaoloajat, avainten kierto ja lokitus voidaan hallita yhdestä paikasta.

Transaktioiden eheys: Kun „lokero auki“ ei ole sama kuin „nouto suoritettu“

Varasto- ja jakelukontekstissa suurin virhelähde on olettamus, että avaaminen automaattisesti tarkoittaa noutoa. Todellisuudessa tapahtuu keskeytyksiä, virheotteita, tahattomia avauksia tai tilanteita, joissa lokero jää auki. Kestävä ratkaisu mallintaa siksi tilat eksplisiittisesti:

• Varattu: lokero on kohdistettu tilaukseen, ei vielä avattu.
• Avaus aloitettu: todennus onnistui, avauslupa myönnetty.
• Ovi auki: aikaväli käynnissä, anturi ilmoittaa auki.
• Ovi suljettu: fyysinen sulkeutuminen, mutta nouto mahdollisesti epäselvä.
• Valmis: nouto vahvistettu (automaattisesti tai käyttäjän/operaattorin vahvistuksella), palaute ERP:lle lähetetty.

Laitteistosta riippuen anturit (ovikontakti, paino, RFID) voivat auttaa, mutta ohjelmiston on silti käsiteltävä epävarmuutta. IT-näkökulmasta on tärkeää, että jokainen siirtymä päätyy audit-lokiin ja että on määriteltyjä palautumispolkuja (esim. „ovi jäi auki – eskalointi valmiusryhmälle“).

Käyttö ilman kitkaa: monitorointi, lokitus ja tukaprosessit

Mitä kannattaa valvoa (ja mitä ei)

Ilman monitorointia noutolokerikko muuttuu „black box“ -järjestelmäksi, jossa viat havaitaan vasta, kun joku ei saa yöaikaan materiaalia. Hyödyllisiä ovat metriikat ja tilat, jotka suoraan vaikuttavat palvelun laatuun:

• Yhteys: järjestelmä online/offline, latenssi integraatiopalveluun
• Lokeroiden tilat: pysyvästi auki oleva ovi, toistuvat avaushäiriöt
• Transaktiotukos: paikallinen jono kasvaa, synkronointi jumittaa
• Virheprosentit: todennus epäonnistui, käyttöoikeus evätty, laitteisto-aikakatkaisu
• Kapasiteetti: täyttö lokeroiden koon mukaan, pullonkaulat kussakin sijainnissa

Ei hyödyllisiä ovat „lukujen hautausmaat“ ilman toimenpidevaikutusta. Määritelkää hälytyssäännöt niin, että jokaisella hälytysluokalla on selkeä omistaja ja reagointiaika.

Lokitus ja audit-loki: kaksi eri vaatimusta

Käytössä usein sekoitetaan kahta eri lokityyppiä:

• Tekninen lokitus: virheanalyysiä varten (aikakatkaisut, API-virheet, firmware-tila), mieluiten keskitetysti koottu.
• Audit-loki: jäljitettävyyteen ja vaatimustenmukaisuuteen (kuka/mikä/milloin/miksi), manipuloinnin kestävä, määritellyillä säilytysajoilla.

Molemmilla lokeilla on eri käyttöoikeusvaatimukset. Järjestelmänvalvojat tarvitsevat tekniset lokit, liiketoiminnot usein vain audit-otteet. Erotelkaa nämä maailmat varhain, muuten syntyy tietosuoja- ja käyttöoikeusongelmia.

Patch- ja päivitysstrategia laitteelle, kioskille ja backendille

Noutolokerikolla on yleensä useita päivitysalueita: terminaali/kioski (OS, Browser), laitteiston ohjaus (Firmware), integraatiopalvelu (sovellus), tietokanta ja tarvittaessa reverse proxy. Kitkakustannuksia syntyy, kun päivitykset riippuvat toisistaan suunnittelemattomasti.

Vakiintuneet käytännöt tuotantokäyttöön:

• Versioidut rajapinnat: API-versiot, joita vanhat asiakasohjelmat edelleen tukevat.
• Staging/Referenzanlage: vähintään yksi testipolku firmwaren ja asiakasohjelmistoversioiden tarkistamiseen ennen käyttöönottoa.
• Huoltoikkuna ja palautus (rollback): selkeä suunnitelma, miten palataan takaisin, jos päivitys ei suju odotetusti.

Erityisesti 24/7-ympäristössä palautuskyvykkyys on usein tärkeämpi kuin „nopein päivitys“.

Turvallisuus: uhkamalli ja konkreettiset toimenpiteet

Noutopisteessä IT-turvallisuus ja fyysinen turvallisuus kohtaavat. Pragmatinen uhkamalli kattaa vähintään:

• Luvaton avaaminen: varastetun kortin, heikon PIN-koodin tai tokenin vuodon seurauksena.
• Päätelaitteen manipulointi: USB-pääsy, kiosk-tilan kiertäminen, paikalliset ylläpitäjäoikeudet.
• API:n väärinkäyttö: riittämätön todennus, puuttuvat rate-limitit, epävarma avainten säilytys.
• Tietovuoto: henkilötiedot tai tilauksen tiedot laitteella.

Konkreettiset toimenpiteet, jotka kokemuksen mukaan toimivat projekteissa:

• Laitteiden koventaminen: kiosk-tila, estetyt portit, allekirjoitetut päivitykset, paikallisten ylläpitäjäkäyttöjen valvonta.
• Verkkosegmentointi: oma VLAN, rajoittavat palomuurisäännöt (vain tarvittavat kohteet/portit).
• Mutual TLS tai laitevarmenteet: laitteet todentavat itsensä integraatiopalvelulle; varmenteiden voimassaoloajat ja uusiminen tulee määritellä prosessina.
• Vähimmän etuoikeuden periaate (Least Privilege): API-scopet toiminnon mukaan (esim. ‚tilan lukeminen‘ erillään ‚lokeroa avaaminen‘).
• Datansäästävyys reunassa (Edge): ei täydellisiä henkilötietorekistereitä paikallisesti, vain tekniset ID:t ja lyhytaikaiset tokenit.

Turvallisuus ei ole täällä „lisä“, vaan edellytys sille, ettei käyttöä hallitse poikkeustilanteet.

Prosessisuunnittelu: luovutus, poikkeustapaukset ja vastuut

Tekniikka yksin ei ratkaise tyypillisiä arkitilanteita. Ilman selkeitä prosessipäätöksiä poikkeustapaukset eskaloituvat tukityöhön. Määritelkää ennen Go-livea vähintään nämä tapaukset:

• Lokero varattu, uusi tilaus: priorisointi, uudelleenvaraus, vaihtoehtoinen sijainti.
• Noutaja ei saavu: aikakatkaisu, palautus varastoon, ilmoitus.
• Väärä nouto: korjausprosessi, lukitus, auditoinnin analyysi.
• Oven virhe/mekaniikka: kuka saa avata manuaalisesti, miten dokumentoidaan.
• Ulkopuoliset käyttäjät: ajallisesti rajoitetut tokenit, henkilöllisyyden tarkistus, tietosuoja.

Tärkeää on luokittelu: mikä on IT-incidentti (järjestelmä ei käytettävissä), mikä on operatiivinen toimenpide (lokero estetty), mikä on turvallisuuspoikkeama (luvattoman pääsyn tapaus)? Tämä erottelu pitää tiketöinnin ja päivystysvastuut selkeinä.

Integraatiomallit, jotka toimivat kehittyneissä ympäristöissä

REST-API vakaana kehikkona

Monille yrityksille REST-API (HTTP-pohjainen rajapintamalli) on käytännöllisin „kehys“ ERP:n, portaalin, laitteen ja raportoinnin välillä. Ratkaisevampaa on vähemmän teknologia ja enemmän hallinnointi:

• Selkeät resurssit: tilaukset, lokerot, transaktiot, laitteet.
• Idempotenssi: toistuvat pyynnöt eivät saa aiheuttaa kaksoisvarauksia (tärkeää verkkohäiriöissä ja uudelleenyrityksissä).
• Merkitykselliset virhekoodit: ‚hylätty oikeuksien takia‘ vs. ‚väliaikaisesti ei saatavilla‘.

Näin syntyy integraatiokerros, joka kestää myös myöhemmät laajennukset: toinen laite, lisätoimipaikka, uusi todennusmenetelmä, raportointi tai portaali disponointia ja seurantaa varten.

Queue/Message Bus für robuste Zustellung

Kun tapahtumat eivät saa hävitä, jono (Message Queue, eli viestien puskuri) on usein perusteltu: laite kirjoittaa tapahtumat paikalliseen tai keskitettyyn jonoon, integraatiopalvelu käsittelee ne asynkronisesti. Hyöty: lyhytaikaiset backend-häiriöt eivät estä välittömästi fyysistä toimintaa, ja saat jäljitettävän käsittelyketjun.

IT-päättäjille ratkaisevaa on, että jonoja on ylläpidettävä (monitorointi, säilytys, dead-letter-käsittely). Jos tämä on yrityksessä vakiintunut, kyseessä on vahva malli. Jos ei, hyvin toteutettu uudelleenyritysmekanismi integraatiokerroksessa voi olla realistisempi askel.

Migraatio ja käyttöönotto: Miten minimoida riskit tuotantokäytössä

Noutolokerikkojärjestelmän käyttöönottoa aliarvioidaan, jos sitä käsitellään „uutena laitteena“. Todellisuudessa kyse on uudesta prosessikanavasta. Riskiltään vähäisempi polku näyttää usein tältä:

1. Pilotti rajatulla tuotevalikoimalla: esim. määritellyt varaosat tai IT-laitteet, selkeät vastuuhenkilöt.
2. Integraatio vaiheittain: ensin identiteetti ja perustilaus, myöhemmin varaston tilanneraportti, sen jälkeen raportointi/optimointi.
3. Rinnakkaiskäyttö manuaalisella vararatkaisulla: määritelty hätäprosessi, jota ei tarvitse improvisoida.
4. Vahvistaminen todellisten tapausten perusteella: hälytyssäännöt, offline-politiikka, käyttöoikeuksien hienojakoisuuden tarkentaminen todellisen käytön perusteella.

Näin toiminta pysyy hallittavana ja organisaatio oppii uutta noutokanavaa ilman, että IT:n tarvitsee toimia „palokuntana“.

Mitä kestävä noutolokerikkojärjestelmä yrityksessä edellyttää (tarkistuslista)

• Keskitetty integraatiokerros piste-piste-kytkentöjen sijaan
• IAM-integraatio selkeällä erottelulla todentamisen ja valtuutuksen välillä
• Eksplisiittinen tilamalli varaukselle, avaamiselle, loppuunsaattamiselle ja peruutukselle
• Offline-vararatkaisu hallituilla, lyhytikäisillä käyttöoikeuksilla
• Valvonta & hälytys suunnattu palvelun laatuun
• Audit-loki tarkastuskelpoinen, erillään teknisestä lokituksesta
• Päivitys- ja rollback-strategia kaikissa komponenteissa
• Turvatoimet laitteelle, verkolle ja API:ille

Kun nämä kohdat toteutetaan huolellisesti, järjestelmästä tulee vakaa osa digitaalista liiketoimintaprosessianne – ei eristyksissä pysyvä ratkaisu, joka toimii vain yksittäisten asiantuntijoiden erikoistiedolla.

Yhteenveto: Kitkakustannukset syntyvät rajapinnoissa – ja ne voidaan systemaattisesti välttää

Noutolokerikkojärjestelmä on yrityksessä menestyksekäs, kun se ymmärretään integroiduksi palveluksi: selkeillä dataobjekteilla, keskitetyllä integraatiologiikalla, jämäkällä IAM:lla, jäljitettävillä transaktioilla ja käyttökonseptilla, joka huomioi offline-tilanteet, päivitykset ja turvallisuuden. Tekninen monimutkaisuus ei synny oven avaamisesta, vaan päätöksen luotettavuudesta, kuka saa avata, miksi ja miten se myöhemmin on todennettavissa.

Jos otatte noutolokerikkojärjestelmän uuteen käyttöön tai haluatte integroida nykyisen ratkaisun vakaammin, kannattaa tehdä lyhyt arkkitehtuuri- ja integraatiotarkastus ennen käyttöönottoa. Ota meihin tästä mielellään yhteyttä osoitteessa .

Ammattikontekstissa myös lukituslokerikkojärjestelmät ja 24/7-jakelu ovat tärkeitä, kun integraatioiden, datavirtojen ja jatkokehityksen on toimittava saumattomasti yhdessä.

Keskustele projektista tai modernisointihankkeesta Net-Base kanssa.