Verkkokehitys
Järjestelmäkehitys ja integraatiot: milloin yrityksen kannattaa rakentaa oma ratkaisu?
Milloin oman järjestelmän rakentaminen tai nykyisten työkalujen yhdistäminen kannattaa? Katso päätösmatriisi, CRM-esimerkki ja vakaan integraation vaatimukset.
Järjestelmäkehityksen tarve näkyy usein työtehtävänä, jonka joku toistaa päivittäin: tarjouspyynnön kopioiminen CRM:ään, tilauksen tarkistaminen useassa järjestelmässä tai virheiden korjaaminen taulukkolaskennassa. Ennen kuin rakennatte jotain uutta, selvittäkää, miksi tehtävä on olemassa.
Parannus voi olla olemassa olevan työkalun parempi käyttöönotto, kahden järjestelmän välinen integraatio tai räätälöity ratkaisu. Tämä opas antaa pohjan valintaan, ensimmäisen toimituksen rajaamiseen ja konkreettisten kysymysten esittämiseen kehitystoimistolle.
Aloita yhdestä työnkulusta
Valitse tehtävä, joka toistuu usein ja jolla on selkeä päätepiste. Kuvaa, kuka tekee mitä, mitä tietoja käytetään ja mistä tieto tulee. Kirjaa myös odotusajat ja manuaaliset tarkistukset. Verkkosivuston lomake on vasta alku, jos työntekijän pitää yhä kopioida kaikki eteenpäin ennen kuin asiakkaalle voidaan vastata.
Laske esiintymiskerrat edustavalta ajanjaksolta. Mittaa, kuinka kauan eri vaiheet kestävät, ja kirjaa, mitkä virheet vaativat lisätyötä. Älä laske kaikkea aikaa mahdolliseksi säästöksi; osa arvioista on edelleen ihmisen tehtävä.
Ota myös poikkeukset mukaan: olemassa oleva asiakas lähettää uuden pyynnön, jokin kenttä puuttuu tai tilausta muutetaan rekisteröinnin jälkeen. Nämä tilanteet ratkaisevat usein, kuinka yksinkertainen ratkaisu todellisuudessa voi olla.
Valitse konfiguroinnin, integraation ja kehityksen välillä
Selvittäkää ensin, voiko tehtävän hoitaa järjestelmillä, joista jo maksatte. Sen jälkeen arvioikaa, riittääkö valmis liitäntä tai rajattu integraatio. Oma järjestelmäkehitys on kiinnostavin vaihtoehto silloin, kun tärkeää työnkulkua ei pystytä kattamaan järkevästi muilla vaihtoehdoilla.
Pyytäkää esittely samasta tehtävästä jokaisessa vaihtoehdossa. Ominaisuuslista voi peittää eron sen välillä, että jokin on teoriassa mahdollista ja että työntekijät pystyvät oikeasti tekemään sen ilman kiertoteitä. Arvioikaa myös, miten ratkaisua voidaan muuttaa ja kuka vastaa sen ylläpidosta.
| Vaihtoehto | Sopii, kun | Selvitä |
|---|---|---|
| Konfiguroi olemassa oleva työkalu | Tarve katetaan jo käytettävissä olevilla toiminnoilla. | Käyttöoikeudet, työnkulku, koulutus ja rajoitukset. |
| Osta standardiratkaisu | Tehtävä on yleinen ja tuote täyttää keskeiset vaatimukset. | Tilaus, vienti, integraatiot ja toimittajariippuvuus. |
| Yhdistä järjestelmät | Työkalut toimivat, mutta dataa siirretään manuaalisesti. | API-pääsy, kentät, virheenkorjaus ja vastuu liitännästä. |
| Rakenna oma ratkaisu | Työnkululla on erityisvaatimuksia, joilla on selkeä arvo. | Kehitys, ylläpito, dokumentaatio ja pitkäaikainen omistajuus. |
Esimerkki: yhteydenottolomakkeesta CRM:ään
Kuvittele yritys, joka vastaanottaa tarjouspyyntöjä verkkosivustonsa kautta. Integraatio voi siirtää tarvittavat tiedot CRM:ään, luoda myyntitehtävän ja ilmoittaa oikealle tiimille. Tämä on havainnollistava ratkaisuehdotus, ei kuvaus tietystä asiakastoimituksesta.
Aloita määrittämällä, mikä järjestelmä omistaa mitkäkin tiedot. Yhteystiedot voivat tulla lomakkeelta, kun taas asiakasstatus tulee ylläpitää CRM:ssä. Uusi lähetys ei saa korvata myyjän arviota ilman, että siitä on tehty tietoinen sääntö.
Yhteystiedon ja pyynnön välinen ero on tärkeä. Sama henkilö voi lähettää kaksi todellista yhteydenottoa eri tarpeista. Ratkaisu, joka poistaa kaiken samalla sähköpostiosoitteella duplikaattina, voi siksi menettää tietoa.
| Tieto | Tarkoitus | Selvitettävä sääntö |
|---|---|---|
| Yhteystiedot | Mahdollistaa vastaamisen. | Mitä kenttiä tarvitaan ja miten ne validoidaan? |
| Palvelu tai tarve | Jakaa pyyntö oikealle taholle. | Kuka vastaanottaa kunkin tyyppisen yhteydenoton? |
| Lähetys-ID | Erottaa tapahtumat toisistaan ja seurata käsittelyä. | Sama lähetys ei saa luoda tehtävää uudelleen. |
| Lähdesivu | Ymmärtää, mistä asiakas otti yhteyttä. | Siirrä sovitut sivutiedot ilman tarpeetonta vapaatekstidataa. |
| Asiakasstatus | Ohjata myynnin seurantaa. | Mikä järjestelmä ja mikä rooli voi muuttaa statusta? |
Sopikaa, mitä tapahtuu, kun jokin epäonnistuu
Integraation on pystyttävä käsittelemään tilanteet, joissa vastaanottava järjestelmä ei vastaa, käyttöoikeudet vanhenevat tai viesti lähetetään useita kertoja. Sopikaa, mitkä virheet yritetään uudelleen, missä ne näkyvät ja kenelle ilmoitetaan. Sähköposti, jossa lukee vain «virhe», antaa huonot lähtökohdat jatkotoimille.
AWS kuvaa idempotenssia periaatteena, jossa toistettu pyyntö tuottaa saman vaikutuksen kuin yksi käsittelykerta. CRM-työnkulussa yksilöllistä lähetys-ID:tä voidaan käyttää estämään se, että uusi toimitusyritys luo saman myyntitehtävän useita kertoja.
Stripe on konkreettinen esimerkki toimittajasta, joka dokumentoi sekä duplikoidut webhook-tapahtumat että sen, ettei tapahtumien toimitusjärjestystä taata. Hankinnassa olennaista on pyytää kehittäjää tarkistamaan kunkin yhdistettävän järjestelmän varsinainen dokumentaatio.
Tee pieni ensimmäinen toimitus, jossa on selkeä testaus
Rajaa ensimmäinen versio yhteen työnkulkuun, joka tuottaa arvoa jo sellaisenaan. Voitte esimerkiksi siirtää pyynnöt ja luoda tehtävät ennen automaattisen tarjousluonnin rakentamista. Näin datan laatua on helpompi hallita ja palautetta saadaan niiltä, jotka käyttävät järjestelmää.
Testaa sovituilla testitiedoilla ja dokumentoi odotettu tulos. Onnistunut normaali lähetys on vain yksi skenaario. Tarkista myös toistuva toimitus, puuttuvat tiedot, väliaikainen virhe ja olemassa oleva yhteystieto, jolla on uusi tarve.
Ennen käytön laajentamista jonkun pitäisi pystyä jäljittämään tietty testi alusta loppuun. Käytä viitettä, jota voidaan seurata järjestelmien välillä, ja vältä tallentamasta lokeihin enemmän henkilötietoja kuin virheen ymmärtämiseksi on tarpeen.
- Normaali tiedonkulku luo oikeat tiedot oikealle vastaanottajalle.
- Saman tapahtuman toistuva toimitus ei luo ylimääräistä tehtävää.
- Virhe näkyy selvästi, ja sille on nimetty vastuuhenkilö.
- Uusi pyyntö olemassa olevalta yhteyshenkilöltä säilyy tallessa.
- Käyttöoikeudet ja dokumentaatio voidaan luovuttaa yritykselle.
Sovi, kuka omistaa ratkaisun tämän jälkeen
Projektia ei ole suunniteltu valmiiksi ennen kuin käytöllä ja muutoksilla on omistaja. Selvittäkää, missä ratkaisu toimii, kuka maksaa tarvittavat palvelut, kuka voi muuttaa käyttöoikeuksia ja miten saatte apua, jos data lakkaa kulkemasta.
Pyydä myös yksinkertainen yleiskuva järjestelmistä, integraatioista ja edellytyksistä. Kun CRM vaihtaa kentän nimen tai toimittaja muuttaa rajapintaa, pitäisi olla mahdollista selvittää, mihin vaikutukset voivat kohdistua. Hyvä dokumentaatio helpottaa jatkokehityksen tilaamista ja vähentää riippuvuutta yhdestä henkilöstä.
Kysymykset ja vastaukset
Mitä eroa on järjestelmäkehityksellä ja integraatiolla?
Järjestelmäkehitys luo tai muuttaa ohjelmistoratkaisun toiminnallisuuksia. Integraatio yhdistää järjestelmiä niin, että ne voivat vaihtaa tietoa tai käynnistää toimintoja. Projekti voi sisältää molempia.
Voimmeko integroida verkkosivun käyttämäämme CRM-järjestelmään?
Asia on selvitettävä kyseisen järjestelmän, tilauksen ja saatavilla olevien rajapintojen perusteella. Kuvaa, mitä tietoja siirretään, mihin suuntaan ne kulkevat ja mitä vastaanoton jälkeen pitää tapahtua.
Miten arvioimme, onko automaatio investoinnin arvoinen?
Kartoitakaa nykyinen ajankäyttö, virheet ja viiveet. Verratkaa tätä käyttöönoton, käytön ja odotetun ylläpidon kustannuksiin. Ottakaa huomioon myös se, voivatko työntekijät todella käyttää ajan muihin arvokkaisiin tehtäviin.
Lähteet ja lisälukemista
Oivalluksista toimiviin ratkaisuihin.
Keskustele kanssamme siitä, mitä yrityksesi tarvitsee ja mistä on järkevää aloittaa.
Keskustele integraatioista ja kehitystarpeista