Multiplatform Application Developmentin suunnittelu: ensin prosessi, sitten alusta

Varastopäällikkö vahvistaa tavaran vastaanoton käsiskannerilla. Suunnittelu tarkistaa saman tapahtuman selaimessa. Kuljettaja tarvitsee toimitustilan matkalla älypuhelimella. Multiplatform application development kuulostaa tällä hetkellä tekniseltä kysymykseltä. Todellisuudessa kyse on ensin toimintaprosessista: mikä työ on tehtävä missä, millä luotettavuudella ja millä laitteella?

Pienille ja keskisuurille yrityksille oikea vastaus on harvoin: rakennamme kaiken natiivisti jokaiselle alustalle. Useammin se kuuluu: määrittelemme yhteisen prosessin, valitsemme kohdennetusti tarvittavat käyttöliittymät ja vältämme kaksinkertaisen logiikan. Se ei säästä vain kehitysbudjettia. Se estää myös sen, että varasto, toimisto ja ulkopalvelu työskentelevät eri tietotilanteilla.

Mitä Multiplatform Application Developmentin pitäisi saada aikaan

Multiplatform Application Development tarkoittaa sovelluksen kehittämistä, jota voi käyttää useissa ympäristöissä, esimerkiksi verkkoselaimessa, iOS:llä ja Androidilla tai Windows-työpöytäjärjestelmissä. Käsite supistetaan usein kysymykseen siitä, voiko yksi koodikanta tuottaa useita sovelluksia. Se on vain osa päätöstä.

Operatiivisissa järjestelmissä merkitsee ennen kaikkea, toimiiko sovellus käyttöpaikassaan. Tavaran vastaanotto voi tarvita kameran viivakoodien lukemiseen, suuret käyttöelementit käsineitä varten ja käyttökelpoisen reaktion epävakaassa WLAN-kattavuudessa. Hallinto tarvitsee sen sijaan taulukoita, suodattimia, oikeuskonsepteja ja jäljitettäviä muutoslokeja. Kuljettaja tarvitsee suppean näkymän, ei samaa käyttöliittymää kuin suunnittelu.

Yhteinen tekninen perusta voi yhdistää nämä vaatimukset järkevästi. Mutta sen ei pidä johtaa siihen, että jokaista alustaa palvellaan huonona kompromissina. Paras yhteinen koodi on arvotonta, jos työntekijät kiertävät, koska sovellus ei kuvaa heidän todellista työnkulkuaan.

Ensin prosessi, sitten alusta

Ennen kuin tiimit puhuvat kehyksistä, niiden tulisi tarkastella yhtä konkreettista tapahtumaa alusta loppuun. Otetaan toimitus: tilaus saapuu, tavara kerätään, toimituskirja syntyy, luovutus vahvistetaan ja tila raportoidaan takaisin myyntiin tai asiakaspalveluun. Missä kohdassa syntyy nykyään mediakatkos? Missä jotain kirjataan paperille, näppäillään myöhemmin tai kysytään puhelimitse?

Tämä havainto erottaa todelliset alustavaatimukset toivelistoista. Jos vain kaksi työntekijää toimistossa käyttää jotain toimintoa, hyvin tehty verkkokäyttöliittymä riittää yleensä. Jos kymmenen ihmistä hallin lattialla tekee kirjauksia, mobiili, skannerille sopiva käyttöliittymä voi ratkaista eron. Jos olemassa olevan Windows-ohjelman on toimittava erikoislaitteiston kanssa, työpöytäintegraatio voi olla tarpeen.

Kaikki toiminnot eivät kuulu kaikille laitteille. Se ei ole monialustaratkaisun puute, vaan merkki selkeistä tuotepäätöksistä. Yhteinen data ja liiketoimintasäännöt eivät välttämättä tarkoita identtisiä näyttöjä.

Kolme kysymystä, jotka selventävät kustannuksia ja hyötyä

Ensimmäinen kysymys kuuluu: mitkä laitteet ovat jo käytössä ja kuinka kauan ne pysyvät? Yrityksellä, jolla on hallitut Windows-päätteet, on eri vaatimukset kuin ulkopalvelulla, jolla on yksityisiä älypuhelimia. Toinen kuuluu: mitä tapahtuu ilman verkkoyhteyttä? Offline-kyky lisää vaivaa huomattavasti, koska data on tallennettava paikallisesti, synkronoitava myöhemmin ja käsiteltävä siististi ristiriitatilanteissa. Se on järkevä, jos prosessi muuten pysähtyy - ei vakiovarusteena.

Kolmas kysymys koskee katkoksen seurauksia. Voiko työntekijä kirjata tapahtuman jälkikäteen, vai riippuuko siitä lähetystarra, varasto tai turvallisuusvapautus? Mitä kriittisempi tapahtuma, sitä vahvemmin käyttöoikeudet, tarkistussäännöt, toistettavuus ja lokitus on suunniteltava.

Arkkitehtuuri, joka ei hajoa toisella alustalla

Kestävässä ratkaisussa liiketoimintalogiikka ei ole hajallaan useissa käyttöliittymissä. Varastotarkistukset, tilanvaihdot, numerosarjat, käyttöoikeudet ja asiakirjojen luonti tarvitsevat keskitetyn, testatun perustan. Selain, mobiilisovellus ja työpöytäasiakas käyttävät sitä selkeästi määriteltyjen rajapintojen kautta.

Monissa sisäisissä liiketoimintaprosesseissa moderni verkkosovellus on taloudellisin lähtökohta. Sen voi päivittää keskitetysti, se ei vaadi asennusta jokaiselle työpisteelle ja se toimii tietokoneella, tabletilla ja älypuhelimella. PHP 8.4:llä, modernilla JavaScriptillä ja MySQL 8:lla voidaan rakentaa ylläpidettävä perusta, jos tietomalli, käyttöoikeudet ja käyttöönotto eivät tule harkittavaksi vasta aivan ennen käyttöönottoa.

Asennettava mobiili- tai työpöytäsovellus lisätään silloin, kun se tuo selvän edun: syvä integraatio skannerin, tulostimen tai kameran kanssa, luotettava offline-käyttö, erityiset taustatoiminnot tai laitehallinnan vaatimukset. Se on kohdennettu laajennus, ei itsetarkoitus.

Yleinen virhe on käyttöliittymän täydellinen uudelleenkäyttö hinnalla millä hyvänsä. Teknisesti se voi näyttää houkuttelevalta. Käytännössä syntyy pieniä tekstejä suurille näytöille, ylikuormitettuja lomakkeita älypuhelimille tai käyttöä, joka ei sovi alustalle. Parempi on jakaa tietomalli, säännöt ja komponentit siellä, missä se on järkevää, ja sovittaa käyttö kuhunkin yhteyteen.

Tietojen johdonmukaisuus on tärkeämpää kuin yhteinen koodikanta

Useat alustat lisäävät ristiriitaisen datan vaaraa. Tilaus muutetaan toimistossa, kun kuljettaja näkee laitteellaan vielä vanhan version. Kaksi työntekijää kirjaa samanaikaisesti saman tuotteen varastoa. Offline-laite lähettää muutoksensa takaisin tuntien kuluttua. Nämä tapaukset eivät ole sivuaihe, vaan arkkitehtuurin ydin.

Järjestelmä tarvitsee siksi yksiselitteiset identiteetit, aikaleimat, jäljitettävät tilanvaihdot ja säännöt ristiriidoille. Toimitustilassa viimeksi vahvistettu muutos voi riittää. Varastosaldoissa se on usein liian karkea. Siellä on oltava selvää, mikä liike kirjattiin, miltä varastopaikalta se on peräisin ja onko korjaus perusteltava.

Myös käyttöoikeudet kuuluvat säädettäviksi keskitetysti. Työntekijä saa ehkä kirjata tavaran vastaanottoja, mutta ei hyväksyä varastokorjauksia. Ulkopuolinen kuljettaja saa nähdä vain oman reittinsä. Istuntojen kestot, monivaiheinen tunnistautuminen kriittisissä rooleissa ja tilin lukitusprosessit eivät ole koristeellisia turvaominaisuuksia. Ne suojaavat konkreettisia prosesseja ja tekevät vastuut näkyviksi.

Multiplatform Application Developmentin testaus sellaisena kuin työtä tehdään

Sovellus voi käynnistyä kolmella käyttöjärjestelmällä ja silti epäonnistua käytössä. Ratkaisevia ovat prosessit todellisissa olosuhteissa: skanneri reagoi liian hitaasti, tarratulostin ei ole tavoitettavissa, käyttöoikeus ei tule voimaan roolinvaihdon jälkeen tai synkronointi luo kaksoiskirjauksia.

Siksi kriittiset prosessit tulisi tarkistaa automatisoidusti. Näihin kuuluvat kirjautuminen ja lukitustoiminta, tilausten tallennus, varastoliikkeet, asiakirjojen luonti ja virheellisten syötteiden käsittely. Web- ja Windows-sovelluksille toistuvat testit voidaan ajaa itse isännöidyllä infrastruktuurilla. Se on erityisen tärkeää, jos kuvakaappauksia, sisäisiä tilaustietoja tai testitunnuksia ei haluta välittää ulkoisille pilvipalveluille.

Automaatio ei korvaa ihmisten tekemää tarkistusta hallin lattialla. Se kuitenkin varmistaa, että tunnetut prosessit tarkistetaan muutosten jälkeen yhä uudelleen. Hyvät testiraportit eivät nimeä vain teknistä virhettä, vaan kyseessä olevan prosessin: toimitustodistusta ei voida luoda, käyttäjätili pysyy lukittuna onnistuneen vapautuksen jälkeen tai reittitietoja ei päivitetä.

Milloin alustastrategia on liikaa

Jotkut yritykset eivät tarvitse omaa sovellusta. Jos vakaa selainyhteys riittää, prosessi on harvoin mobiili ja käyttäjämäärä pysyy hallittavana, responsiivinen verkkosovellus on usein järkevämpi valinta. Se vähentää ylläpitotyötä, jakeluongelmia ja mahdollisten virhelähteiden määrää.

Myöskään olemassa olevaa taulukkoa ei tarvitse korvata heti. Jos se toimii vain yksinkertaisena arviointina, yksi henkilö ylläpitää sitä eikä se aiheuta virhealttiita siirtoja, se voi täyttää tarkoituksensa. Järjestelmän aika on tullut, kun tieto on yksittäisten päissä, versiot erkaantuvat, kyselyt lisääntyvät tai tapahtumaa ei voi enää luotettavasti jäljittää.

Toisaalta kevyt alustastrategia käy nopeasti liian pieneksi, kun työntekijöiden on työskenneltävä offline-tilassa, laitteita liitetään tai asiakkaat ja kumppanit tarvitsevat hallittua pääsyä. Silloin kannattaa rahoittaa lisävaatimukset tietoisesti sen sijaan, että ne rakennetaan myöhemmin aikapaineessa.

Aloita kestävällä pilotilla

Hyvä alku ei ole sadan kohdan toimintoluettelo, vaan täydellinen, mitattava prosessi. Esimerkiksi: kirjaa tavaran vastaanotto, päivitä varasto, dokumentoi poikkeama ja luo selvitystehtävä. Tämä pilotti osoittaa varhain, sopivatko tietomalli, laitteet, oikeudet ja käyttö yhteen.

Sen jälkeen ratkaisu voi kasvaa järkevin askelin: keräily, lähetys, reittisuunnittelu tai analyysit. Jokaisen laajennuksen tulisi läpäistä sama kysymys: lyhentääkö se todellista prosessia, vähentääkö se virheitä vai luoko se luotettavaa läpinäkyvyyttä? Jos ei, se voi odottaa.

Järkevin alusta ei lopulta ole se, jolla on eniten teknisiä vaihtoehtoja. Se on se, jolla tiimi aloittaa työnsä aamulla nopeammin, kysyy vuoron aikana vähemmän ja voi illalla jäljittää, mitä todella tapahtui.