Suosittelen myös katsomaan löytyisikö "integraatiot" termin alta jotain. Karkeasti töiden voi ajatella jakautuvan data- ja prosessi-integraatioihin, ensimmäisessä synkataan dataa systeemien välillä ja jälkimmäisessä (mitä ensisijaisesti nyt ehdotan) välitetään järjestelmien välillä viestejä ja automatisoidaan prosesseja.Kiitos vinkistä, ja kiitos myös mopnex ja dropadrop kommenteista yllä! Tää RPA-kurssi on ainakin sivujensa mukaan erityisesti vahvoille Java-osaajille, mutta sillein kyllä hyvä tietää, että tällaisia trainee-tyyppisiä paikkoja on auki.
Aloin miettiä sitäkin, että helpoin tie varmaan olisi päivittää tuota käytettävyyspuolen osaamista nykytasolle. Tykkäsin yliopistossa etenkin käytännön suunnittelu- ja arviointitöistä ja sain niistä ihan hyviä arvosanojakin. Toisaalta, olin silloin nuori ja siten ehkä vähän enemmän sosiaalinen ihminen. Nykyisin olen lähinnä omassa työkomerossa viihtyvä totaali-introvertti, ja korona-aika on osoittanut, että voin sitä paremmin, mitä vähemmän tarvii olla päivittäin ihmisten kanssa tekemisissä (puoliso poislukien). Ja tämä liittyy asiaan siten, että käyttäjälähtöisessä suunnittelussa pitäisi noinniinkuin lähtökohtaisesti olla niiden käyttäjien kanssa tekemisissä![]()
RPA voi olla kuviossa mukana, mutta miksi luoda määrämittaisia dokumentteja robotin luettavaksi, jos datan voi viedä koneluettavassa muodossa putken läpi ja luoda sen ihmisluettavan tulosteen sitten siellä missä sitä oikeasti tarvitaan? Tuon vuoksi minun on vaikea suositella RPAta osaamisen ykkösfokukseksi. Usein on parempia vaihtoehtoja asioiden toteuttamiseen.
Integraatiossa pääsee pelaamaan monenlaisten järjestelmien kanssa (ERPit jne.) vähintään pintatasolla ja saa yleiskuvaa miten kokonaisuuksia rakennetaan. Asioita voidaan toteuttaa suoraan koodaamalla, pilvityökaluilla tai dedikoiduilla low-code -alustoilla, joten läheskään aina ei tarvitse olla koodivelho.
Tiimin työnjaosta riippuu miten pitkälle toteutuksen tekijä pärjää siellä komerossa