Herbert Röblreiter tarkastaa tietojen tuontia yhteyshenkilön kanssa.
Takaisin palvelukatsaukseen Kehitys ja integraatiot

Rajapinnat tarkemmin.
Tiedot hallitusti yhteen.

Konkreettisesta pullonkaulasta ylläpidettävään integraatioon: tietojen saatavuuden, tarkastuksen, virheenkäsittelyn, vaiheittaisen toteutuksen ja jatkoylläpidon yhteinen suunnittelu.

Sovi alkukeskustelu Kerro tarpeestasi
Lähdetään liikkeelle työprosessista

Mihin aikaa kuluu hukkaan joka päivä?

Tilaus syötetään kahdesti. Raportti kootaan useista vienneistä. Toimialan ohjelmisto sopii lähes täydellisesti — yhtä ratkaisevaa vaihetta lukuun ottamatta.

Selvitämme ensin, mitä nykyiset tuotteet ja standardit jo mahdollistavat. Rajapinta, kohdennettu laajennus tai pieni työkalu voi tehdä nykyisistä investoinneista hyödyllisempiä.

Hallittu tietojen siirtoHavainnollistava työkalu
Lähde
Tilaukset nykyisestä sovelluksesta
Tarkastus
Pakolliset kentät ja yksiselitteinen kohdistus
Poikkeus
Puutteellisen tietueen palautus käsittelyyn
Luovutus
Kohdejärjestelmään vasta onnistuneen tarkastuksen jälkeen

Virheet pysyvät näkyvinä. Vastuut ja lokitus kuuluvat prosessiin.

Selkeä eteneminen

Ensimmäisestä syötteestä käyttökelpoiseen tulokseen.

Yhteyden tulee toimia arjessa: tietojen tarkastus, virheiden näkyväksi tekeminen ja ylläpitovastuiden määrittely.

Tietojen tarkastus ja siirto korjauspolulla, rajatulla uusintakäsittelyllä ja kohdejärjestelmän tarkastuksella.
Esimerkki: CRM:n tai liiketoimintasovelluksen tilaus tarkastetaan ja siirretään kohdejärjestelmään. Epäselvät tiedot palautuvat korjattaviksi; keskeytyneet siirrot toistetaan rajatusti ja kaksoistietueita luomatta.
Alusta tarpeen mukaan

Kolme tietä sopivaan yhteyteen.

Nykyinen palvelu voi sopia yhtä hyvin kuin yksilöllinen rajapinta. Selvitämme yhdessä, mikä ratkaisu on teknisesti ja taloudellisesti tarkoituksenmukainen.

Kolme vaihtoehtoista esimerkkipolkua: Azure API Management ja Logic Apps, Apigee ja Cloud Run tai oma REST-API ja yksilöllinen käsittely. Valinta ja ylläpito määräytyvät tarpeen mukaan.
Kolme vaihtoehtoista teknistä esimerkkiä. Sopiva toteutus riippuu nykyisistä järjestelmistä, tiedoista, ylläpitovaatimuksista ja budjetista. Valmistajien lähteet: Azure API Management, Logic Apps ja Apigee.
Kohdennettu täydentäminen

Kehitystä tehtävän vaatimassa laajuudessa.

01

Rajapinnat

APIt, tietokannat, verkkopalvelut ja hallitut tuonnit yhdistävät liiketoimintaohjelmistot, verkkosivut ja pilvipalvelut.

02

Automaatio

Toistuvan käsittelyn, tilamuutosten, ilmoitusten ja raporttien tarkoituksenmukainen suorittaminen.

03

Nykyiset ohjelmistot

Sovellusten ja sisäisten työkalujen analysointi, ylläpidettävien osien uudistaminen ja mukauttaminen muuttuviin prosesseihin.

04

Laajennukset

Puuttuvan toiminnon lisääminen, kun koko ohjelmiston korvaamisesta ei ole perusteltua hyötyä.

05

Pienet sovellukset

Rajattuun tehtävään tarkoitetun selkeän ja ylläpidettävän työkalun kehittäminen.

06

Operointi ja luovutus

Käyttöoikeuksien, dokumentoinnin, virheenkäsittelyn ja ylläpidon huomiointi alusta alkaen.

Ideasta ylläpitoon

Ensin pullonkaulan selvittäminen. Sitten hallittu toteutus.

Hallittava projektipolku
  1. 01 · YMMÄRRÄKonkreettisen prosessin kartoitusMistä tiedot syntyvät, mitkä vaiheet tehdään käsin ja mikä lopputulos tarvitaan?
  2. 02 · TOTEUTAPienten vaiheiden testausTietovirrasta ja laajuudesta sopiminen, sopivien standardien hyödyntäminen ja tarkastus toiminnallisilla esimerkeillä.
  3. 03 · TUETiedon ja vastuiden varmistaminenDokumentointi, luovutus ja mukauttaminen sovellusten tai prosessien muuttuessa.
Mahdollinen hanke

Tilauksen siirtäminen kahden sovelluksen välillä.

Tilaus syntyy ensisijaisessa järjestelmässä, ja sen tulee olla käytettävissä toisessa sovelluksessa. DAXS selvittää, mikä järjestelmä vastaa mistäkin tiedosta ja milloin siirto on toiminnallisesti onnistunut. Näin ehkäistään sitä, että tekninen yhteys tuottaa huomaamatta vääriä tai päällekkäisiä tietueita.

Rajapinnan määrittely

Kenttien kohdistus, tunnisteet, sallitut arvot ja muutokset kuvataan todellisten tietorakenteiden perusteella; testiin käytetään sopivia puhdistettuja esimerkkejä. Käyttöoikeudet rajataan tarvittavaan laajuuteen. Tapahtumat, ajastetut ajot tai manuaaliset hyväksynnät määräytyvät työprosessin mukaan.

Virheiden hallittu käsittely

Keskeytys ei saa jättää huomaamatonta aukkoa. Lokitus, uudelleenkäsittely ja kaksoiskappaleiden käsittely suunnitellaan erikseen. Kun tietueen sisältö on toiminnallisesti epäselvä, vastuuhenkilö saa selkeän tehtävän sen sijaan, että siirto jatkuisi hiljaisesti.

Tutustu suunnittelu- ja hyväksyntäkohtiin
  • Ensisijaisen järjestelmän ja jokaisen tietokentän vastuun määrittely.
  • Tunnisteista, tietomuodoista ja pakollisista kentistä sopiminen.
  • Käyttöoikeuksien ja suojattujen siirtoreittien tarkastus.
  • Tavallisten tapausten, virheellisten arvojen ja yhteyskatkon testaus.
  • Uusintakäsittelyn ja jo siirrettyjen tietueiden käsittelyn tarkastus.
  • Hyväksyntä: kohdejärjestelmän tuloksen, lokin ja ylläpito-ohjeen todentaminen.

Esimerkinomainen tarkastuskehys. Laajuus ja sopivat todisteet sovitaan ympäristönne mukaan.

Ennen päätöstä

Kysymyksiä kehityksestä ja rajapinnoista.

Onko nykyinen ohjelmisto korvattava?
Usein ei. Ensin tarkastamme nykyiset toiminnot, rajapinnat ja laajennusmahdollisuudet. Korvaaminen perustellaan toiminnallisesti ja taloudellisesti.
Voiko kaikki järjestelmät yhdistää?
Tietojen saatavuus, rajapinnat, valmistajien ehdot ja käyttöympäristö asettavat rajat. Nämä edellytykset tarkastetaan ennen ratkaisun lupaamista.
Milloin oma sovellus kannattaa?
Kun rajattua tehtävää ei voi ratkaista hyvin sopivilla vakiotuotteilla ja toiminnallinen hyöty perustelee kehitys- ja ylläpitotyön.
Miten virheet ja tietojen laatu huomioidaan?
Validointi, yksiselitteiset kohdistukset, lokitus ja hallitut uusintayritykset kuuluvat suunnitteluun. Toiminnallisilla pistokokeilla tarkastetaan, vastaako tulos työprosessia.
Kuka ylläpitää ratkaisua jatkossa?
Dokumentoinnista, virheenkäsittelystä ja vastuista sovitaan alusta alkaen. Ylläpito sovitetaan nykyiseen IT-organisaatioonne.
Voiko DAXS jatkokehittää nykyisiä sisäisiä työkaluja?
Kyllä, jos käyttöoikeudet, tekninen perusta ja tehtävä sopivat siihen. Analysoimme nykytilan ja uudistamme tarkoituksenmukaisesti sen sijaan, että rakentaisimme hyvän ratkaisun liian nopeasti uudelleen.
Seuraava tarkoituksenmukainen askel

Näyttäkää konkreettinen pullonkaulanne.

Kaksi järjestelmää, joiden tulisi vaihtaa tietoja? Tai arjesta puuttuva toiminto? Konkreettinen esimerkki riittää alkuun.

Sovi alkukeskusteluLähetä yhteydenotto
Jatkuva ylläpito mukaan suunnitteluunPilvipalvelut osaksi kokonaisuutta[email protected]+43 7229 22722

Selkeästi selitetty

Tällä sivulla kerrotaan tarkemmin, miten kaksi ohjelmaa vaihtaa tietoja, miten siirtovirheet pysyvät näkyvinä ja kuka yhteyttä ylläpitää jatkossa.