Pitäisikö se rakentaa? Kysymys, jonka esitämme ennen kuin kirjoitamme koodia

Kun organisaatio ottaa yhteyttä ohjelmistokehitysyritykseen, odotus on yleensä, että keskustelu päättyy ehdotukseen rakentaa jotain: uusi sovellus, ikääntyvän järjestelmän korvaaja, alusta, joka yhdistää erilliset prosessit. Oletus on ymmärrettävä, mutta se ohittaa kysymyksen, johon pitäisi vastata ennen kuin kukaan puhuu teknologiasta, budjeteista tai toimituspäivistä.

Pitäisikö se todella rakentaa?

Libertas Software Researchilla (LSR) uskomme, että sen tietäminen, pitäisikö ohjelmistoa kehittää, on yhtä tärkeää kuin sen tietäminen, miten. Joskus räätälöity sovellus on täsmälleen oikea ratkaisu. Joskus vakiintunut SaaS-alusta täyttää tarpeen täysin, tai jo olemassa olevien järjestelmien yhdistäminen tuottaa tuloksen ilman korvaamisen kustannuksia ja häiriöitä. Tavoitteena on parantaa organisaation toimintaa, ei lisätä yhtä sovellusta jo ennestään monimutkaiseen ympäristöön.

Aloita ongelmasta, ei ratkaisusta

Organisaatiot kuvaavat usein ratkaisua, jota luulevat tarvitsevansa, eikä ongelmaa, joka niillä on. ”Raportointinäkymä” tai ”sovellus, joka korvaa taulukkomme” kuulostaa selvältä, mutta kertoo vähän siitä, mikä pyynnön laukaisi.

Otetaan kuukausittainen johdon raportti, joka koostetaan käsin useista taulukoista ja järjestelmistä. Siihen menee päiviä, ja kun se valmistuu, tiedot ovat jo vanhentuneita. Ilmeinen johtopäätös on, että tarvitaan raportointiohjelmisto. Tarkemmin katsottuna todellinen ongelma on usein erilliset tiedot ja epäyhtenäiset prosessit: vaatimaton integraatioprojekti, ei uusi sovellus. Ja jos selvitys osoittaa, että tarvitaan erityisiä työnkulkuja tai kontrolleja, joita mikään tuote ei tue, silloin räätälöity kehitys ansaitsee paikkansa.

Milloin ostaminen on järkevämpää

Kaupallinen markkina on kypsä. CRM:llä, kirjanpidolla, ajanvarauksella, dokumenttienhallinnalla ja liiketoimintatiedolla on tuotteita, joita on hiottu vuosia. Jos jokin niistä täyttää tarpeesi kohtuuttomitta rajoituksitta, räätälöity korvaaja tuo vain vähän lisäarvoa.

Vertaa kuitenkin omistuksen kokonaiskustannuksia, ei tilaushintoja. 500 £:n kuukausituote on viidessä vuodessa 30 000 £ ennen konfigurointia, integraatioita, lisälisenssejä tai omien prosessiesi muutoksia. Tarkista, miten hinnoittelu skaalautuu, voitko viedä tietosi ja mitä tapahtuu, jos toimittaja muuttaa mallinsa. Ja varo pakottamasta liiketoimintaa luopumaan toiminnoista, jotka todella erottavat sen muista, vain koska tuote olettaa toisin.

Joskus vastaus on yhdistää se, mitä jo on

Useimmat organisaatiot keräävät järjestelmiä ajan myötä: talous yhdessä, toiminta toisessa, asiakaspalvelu kolmannessa. Jokainen toimii hyvin; ne vain eivät keskustele keskenään, mistä seuraa viiveitä, päällekkäistä työtä ja epäyhtenäistä tietoa.

Kaiken korvaaminen yhdellä sovelluksella houkuttelee, mutta on riskialtista. Olemassa olevat alustat sisältävät vuosien toiminnallista tietoa ja piilotettuja integraatioita. Huolellisesti suunniteltu integraatiokerros (rajapintojen yhdistäminen, siirtojen automatisointi, raportoinnin kokoaminen luotettavista lähteistä) voi pidentää näiden investointien elinkaarta. Se vaatii tarkkaa harkintaa todennuksen, tietojen omistuksen, virheenkäsittelyn ja jäljitettävyyden suhteen, mutta integraation suosittelu korvaamisen sijaan ei ole huonompaa insinöörityötä. Usein se on harkitumpi arkkitehtuuripäätös.

Milloin räätälöinti on oikea investointi

Jotkin vaatimukset eivät todella sovi valtavirran tuotteisiin: erikoistuneet toiminnot, epätavalliset turvallisuus- tai tietotarpeet tai ohjelmisto, joka on itsessään kilpailuetu. Tällöin räätälöity ohjelmisto antaa arkkitehtuurin seurata sitä, miten liiketoiminta todella toimii.

Tämä joustavuus tuo mukanaan pitkäaikaisen vastuun ylläpidosta, tietoturvasta, testauksesta ja tuesta. Järjestelmä voi täyttää alkuperäisen määrittelynsä ja olla silti huono investointi, jos sitä on vaikea ylläpitää tai se ei mukaudu. Räätälöity kehitys on perusteltua, kun tarkoitukseen rakennetun ratkaisun hyödyt ylittävät sekä alkukustannuksen että jatkuvan omistamisen velvoitteen.

Kaikki ongelmat eivät tarvitse lisää ohjelmistoja

Joskus prosessi on ongelma. Hyväksynnät, raportit ja hallinnolliset vaiheet kasautuvat vuosien varrella, kauan sen jälkeen kun ne synnyttäneet olosuhteet ovat poistuneet. Niiden automatisointi täsmälleen sellaisenaan vain säilyttää monimutkaisuuden.

Jos asiakirja tarvitsee viisi hyväksyntää, älä kysy, miten viisi hyväksyntää automatisoidaan, vaan miksi kukin on olemassa ja mitä riskiä se kattaa. Ohjelmisto on erinomainen soveltamaan johdonmukaisia sääntöjä, mutta se ei voi kertoa, onko prosessi järkevä. Työnkulun yksinkertaistaminen tai vastuiden selkeyttäminen voi tuottaa todellista hyötyä ilman uutta järjestelmää, jota pitäisi opetella ja tukea.

Katso alkukustannusta pidemmälle

Räätälöidyillä projekteilla on suuri alkukustannus, kun taas SaaS jakaa kustannuksensa tilauksille, mikä saa vertailun näyttämään vinolta. Reilu vertailu kattaa koko elinkaaren: käyttöönoton, lisensoinnin, hostauksen, tuen, ylläpidon, integraation, koulutuksen ja tulevat muutokset.

Sisällytä myös tekemättä jättämisen hinta. Tehoton prosessi, joka syö 20 työtuntia viikossa, on noin 1 040 tuntia vuodessa. Havainnollistavalla 35 £:n tuntihinnalla se on noin 36 400 £ vuodessa, olettaen että aika voidaan todella saada takaisin ja suunnata uudelleen. Lisää huono tietojen laatu ja hitaat päätökset, joita on vaikeampi hinnoitella mutta jotka ovat yhtä todellisia. Paras vaihtoehto ei ole halvin, vaan se, jossa on vahvin yhdistelmä arvoa, hyväksyttävää riskiä ja pitkän aikavälin kestävyyttä.

Miksi ohjelmistoyritys suosittelisi, ettei ohjelmistoa rakenneta?

Se on oikeutettu kysymys. Jos suosittelemme tuotetta tai pientä integraatiota, se on paperilla vähemmän kehitystyötä.

Kehityskapasiteetin tarjoamisen ja ohjelmistotutkimuksen ja arkkitehtuurin kumppanina toimimisen välillä on kuitenkin ero. Työmme alkaa ennen kuin määrittelyä on olemassa: ongelman ymmärtäminen, vaihtoehtojen punnitseminen ja apu päättää, mihin sijoittaa. Sillä on arvoa lopputuloksesta riippumatta, ja analyysi-, arkkitehtuuri-, suunnittelu- ja integraatiotyötä on yleensä tehtävänä silloinkin, kun räätälöity kehitys ei ole vastaus.

Tarpeettoman kehityksen suosittelu on haitallista. Ajallaan ja määrittelyn mukaan toimitettu projekti epäonnistuu silti, jos se ei ollut oikea ratkaisu. Asiakkaan auttaminen välttämään turhia menoja rakentaa luottamusta, joka kestää.

Kyky rakentaa ei ole syy rakentaa

Tekoäly ja nykyaikaiset työkalut tekevät koodista nopeampaa ja halvempaa tuottaa. Se on hyödyllistä, mutta tekee ennakkoajattelusta tärkeämpää, ei vähemmän tärkeää, koska ponnistus, joka ennen pakotti kysymään ”tarvitsemmeko tätä todella?”, on katoamassa. On täysin mahdollista rakentaa jotain teknisesti erinomaista, toimittaa se tehokkaasti ja huomata, että se oli väärä vastaus.

Ennen kehityksen alkua haluamme selkeät vastaukset liiketoimintaongelmaan, sen ratkaisematta jättämisen hintaan, siihen, mitä vaatimuksia olemassa olevat tuotteet eivät voi täyttää, siihen, miten menestystä mitataan (käsittelyaika, tarkkuus, näkyvyys, vaatimustenmukaisuus, ei ominaisuuksien määrä) ja siihen, kuka ratkaisua jälkeenpäin ylläpitää ja tukee.

On projekteja, joissa räätälöity ohjelmisto on selvästi oikea, toisia, joissa integraatio on parempi arvo, ja kolmansia, joissa valmis alusta hoitaa homman. Tärkeintä on, että suositus perustuu organisaatiosi ymmärtämiseen eikä oletukseen siitä, mitä ohjelmistoyritys haluaa myydä.

Ennen kuin kysytään, miten jotain pitäisi rakentaa, kannattaa selvittää, pitäisikö sitä rakentaa lainkaan.

Libertas Software Research työskentelee organisaatioiden kanssa ohjelmistoratkaisujen tutkimiseksi, arvioimiseksi, suunnittelemiseksi ja kehittämiseksi painottaen pitkän aikavälin ylläpidettävyyttä, toiminnallista arvoa ja harkittuja teknologiainvestointeja.