Viikko 44

Suunnittelu — viikon agenda

Tällä viikolla jatkamme siitä, mihin pääsimme viime viikolla. Alustavan aikataulutuksen myötä päätimme nyt asettaa selkeät tavoitteet seuraavalle iteraatiolle. Tavoitteiden lisäksi aloitimme projektin taloudelliset validaatiot, johon kuuluu muun muassa Business Model Canvas (BMC) sekä suuntaa-antavia kvantitatiivisia arvioita. Myös prototyypin työstäminen on edistynyt, ja työn toteutuksesta sekä tuloksista on eritelty tarkemmin seuraavissa kappaleissa.


Toteutus — viikon työmenetelmät

Prototyypin työstäminen aloitettiin melko tyypilliseen tapaan sopimalla ensin käytettävät teknologiat. Tämä sujui suhteellisen ongelmitta ja päädyimme rakentamaan prototyyppimme Pythonin Django-frameworkkia käyttäen. Valitsimme Djangon, koska se mahdollistaa hyvin nopean prototyyppien työstämisen. Lisäksi muutama ryhmän jäsenistä oli aiemmin käyttänyt Djangoa joko töissä tai koulussa. Versionhallintaan päätimme käyttää kustannussyistä GitLabia.

Varsinaisen prototyypin työstämisen lisäksi teimme tällä viikolla Business Model Canvasin, jossa perustelemme kvalitatiivisesti, miten tuotamme lisäarvoa asiakkaillemme. Tämän lisäksi luomme projektillemme liiketoimintaskenaarioita, joiden avulla pystymme myös kvantitatiivisesti perustelemaan tuotteemme olemassaolon. Lukujen tueksi olemme etsineet muun muassa tilastokeskukselta dataa mm. Ikääntyneiden (yli 75-vuotiaat) ihmisten määrää Suomessa.


Tulokset  — mitä saatiin aikaan

Prototyypin työnteko aloitettiin hoitamalla projektin setup kuntoon. Tässä ei ilmennyt suurempia ongelmia kun käytettävät teknologiat olivat osalle jo entuudestaan tuttuja. Ensimmäisen virallisen työsession aikana saatiin jo oikeastaan koko projektin luuranko pystyyn. Tälle oli varattu alunperin koko ensimmäinen viikko, joten olimme melko tyytyväisiä, miten hommat olivat lähteneet käyntiin.

Saimme alkuinnostuksen siivittämänä jo ensimmäiset toiminallisuudetkin tehtyä melko nopeasti. Näitä pitää vielä hioa jonkin verran, mutta alunperin suunnitelmamme olikin saada ensin mahdollisimman paljon toimimaan ja myöhemmin keskittyä niiden parantelemiseen. Tämä ei välttämättä oikeassa ohjelmistoprojektissa olisi paras tapa lähestyä asiaa. Koimme kuitenkin, että tämän kokoluokan projektiin ja näin kireällä aikataululla se voisi toimia.

Olemme ensin keskittyneet työstämään lääkärin näkymiä ja nämä ovatkin jo hyvällä mallilla. Hiljalleen katseemme ovat kääntyneet kohti potilaan näkymiä, mutta niitä emme ole saaneet vielä kunnolla valmiiksi. Päätimme jättää omaisten näkymät viimeiseksi. Uskomme, että potilaan näkymät menevät melko suoraviivaisesti, kunhan olemme saaneet omaisten näkymät kuntoon ennen sitä.

Emme ole vielä kohdanneet suurempia ongelmia proton puitteissa, mutta ainakin jotain pientä kurssin aikana tulee varmasti vastaan. Olimme huomioineet tämän kuitenkin alustavaa aikataulua tehdessämme, ja näin ollen meillä pitäisi olla aikaa selvittää ongelmia, joita tulemme mahdollisesti kohtaamaan.

 

Prototyypin lisäksi saimme hieman suunniteltua projektimme taloudellista toteutusta sekä tehtyä suuntaa-antavan arvion projektillemme relevanteista luvuista. Ennen lukujen läpikäyntiä käymme seuraavaksi läpi Business Model Canvasia. (Kuva alla, kuvan saa tarvittaessa suuremmaksi avaamalla sen uuteen välilehteen/ikkunaan)

BMC_LARGE

Business Model Canvas (BMC) on työkalu, jonka avulla perustellaan yrityksen tai organisaation liiketoimintamallia: Miten organisaatio luo ja tuottaa (uutta) arvoa. BMC:hen kuuluu kaksi pääosaaluetta: arvo ja tehokkuus. Ensimmäinen osa-alue sisältää arvoon ja arvonluontin liittyvät tekijät, joita ovat arvolupaus, asiakassuhde, jakelukanava, asiakasryhmä ja tulovirrat. Toisen osa-alueen muodostavat avainkumppanit, -suhteet ja -aktiviiteetit, sekä kustannusrakenteen.

Aloitetaan arvolupauksesta. Sovelluksemme tulee tarjoamaan helpon metodin ikääntyneelle potilaalle oman kuntoutuksen ja sairaustenehkäisyn seurantaan ja toteutukseen. Meidän asiakkaan eli sairaalan kannalta tuottamamme arvo näkyy kommunikaation selkeyttämisenä ja siihen liittyvien yhteydenottojen vähentymisenä. Parhaassa tapauksessa pystymme estämään potilaiden turhia sairaalakäyntejä, jolloin sairaalalle syntyy kustannussäästöjä. Sairaalan tehokkuus lisääntyy myös, sillä sairaalahenkilöstö (erityisesti lääkärit) pystyy keskittymään olennaisempiin potilastapauksiin. Potilaan omaiset saavat puolestaan mahdollisuuden seurata etänä ikääntyneen potilaan kuntoutusta ja terveydentilaa, jolloin omaiset eivät tarvitse turhaan murehtia ikääntyneen kuntoa.

Arvolupauksesta selviääkin asiakasryhmämme, joka on siis sairaala. Vakuutusyhtiöt voivat olla myös potentiaalinen asiakasryhmä, mikäli saamme tuotteellamme osoitettua poikkeuksellisen timanttista näyttöä. Aiomme kuitenkin toistaiseksi keskittyä kotimaisiin julkisiin sairaaloihin, sillä julkinen puoli on Suomessa kaikista ryhmistä suurin. Keskitymmekin nyt vain niche-markkinoille scopen takia, mutta tulevaisuudessa harkitsemme massamarkkinoihin tähtäämistä.

Vaikka tuotteemme loppukäyttäjät ovat pääosin ikääntyneitä potilaita ja potilaan omaisia, tähtäämme tehostamaan (julkisten) sairaaloiden palvelua. Heihin tulemmekin pitämään tiivistä, jatkuvaa asiakassuhteen ylläpitoa, jotta voimme seurata sovelluksen käyttöä ja jotta sovelluksen ylläpito olisi sujuvaa. Myynnin kannalta teemme suoramyyntiä sairaaloille sekä muille julkisille palveluntarjoajille ja vakuutusyhtiöille. Tulovirtamme perustuukin pelkästään sovelluksen lisenssimaksuihin – emme halua rahastaa loppukäyttäjiä eli sairaalaan asiakkaita sekä omaisia suoraan, sillä se vähentäisi sovelluksemme suosiota.

Jotta pystymme luomaan asiakkailemme uutta arvoa, tarvitsemme niin avainresursseja kuin -kumppaneita, unohtamatta tietenkään avainaktiviteetteja. Kenties tärkein asiakaskumppanimme onkin itse sairaalat sekä mahdollisesti muut tuotteemme asiakkaat. Toinen kriittinen asiakaskumppani on jokin tietoturvayritys, sillä terveydenhuoltoon liittyy tiukkoja, tarkkoja tietosuojavaatimuksia, ja haluamme tarjota asiakkaallemme mahdollisimman turvallisen sovelluksen. Lisäksi saamme sairaaloilta sekä sairaaloiden asiakkailta tärkeää palautetta, joiden perusteella pystymme kehittämään sovellustamme. Resursseihin kuuluukin ammattiosaajat, jotka huolehtivat aktiviteetteista, kuten platformin rakentamisesta sekä ylläpidosta. Lisäksi meidän täytyy pystyä suorittamaan sovelluksen käyttökoulutuksia, jotta sovelluksen käyttämisessä ei tulisi ongelmia.

Kustannusrakenteemme on varsin yksinkertainen: toistaiseksi meillä on pelkästään kiinteitä kustannuksia, joita ovat palkka sekä sovelluksen ja sivujen ylläpitokustannukset. Palkat tulevat olemaan suurin menoerä, sillä ammattitaidosta maksetaan. Muita kustannuksia ovat esimerkiksi asiakaskumppanuuksista koituvat kustannukset. Kustannusrakenteemme perustuu kuluihin (Cost Driven Business Model) – tarkoituksena on tarjota julkisille palveluntuottajille palveluiden tehostamista, mikä toisi heille säästöä. Koska sovellusta on ajateltu käytettävän pääosin tableteilla ja alustavasti olemme ajatelleet, että sairaalat pystyisivät tarvittaessa lainaamaan tabletteja potilaille, sairaalat joutuisivat hankkimaan näitä. Tämä saattaa muodostaa esteen, sillä haluamme itse keskittyä itse sovelluksen kehittämiseen, emmekä kykene hoitamaan tabletteihin liittyviä logistiikkahaasteita. Emme ole ehtineet pohtia hankintaan liittyviä suurusluokkia, mutta selvitämme asiaa tämän tulevina viikkoina.

 

Näin olemme perustelleet liiketoimintamallimme olemassaolon kvalitatiivisesti. Seuraavaksi tuemme liiketoimintaamme kvantitatiivisesti.

Koska päädyimme hinnoittelemaan tuotteemme kiinteään vuosikustannukseen, olisi meidän osoitettava asiakkaillemme (eli sairaaloille, sairaanhoitopiireille, vakuutusyhtiöille), että käyttäjiä riittäisi. Toisaalta tämä hinnoittelumalli kannustaisi myös asiakkaitamme ottamaan sovelluksen käyttöön mahdollisimman laajalla käyttäjäkunnalla, sillä jokainen eri käyttäjä ei toisi lisäkustannuksia vaan pienentäisi kustannusta per potilas. Näillä perustein relevantteja lukuja kannaltamme olisivat käyttäjämäärät (omien asiakkaidemme prioriteetti), omien asiakkaidemme määrä, liikevaihtopotentiaali sekä kustannukset (kiinteät ja muuttuvat).

Yli 75-vuotiaat eli ikääntyneiksi luokiteltu ikäryhmä kasvaa Suomessa tasaisesti n.4 % vuodessa. Tämä ikäryhmä on perussairauksiensa ja ongelmien moninaisuuden puolesta erityisen otollinen potilasryhmä protollemme ja varsin laaja, 10 vuoden päästä jo yli 750 000. Tästä määrästä karkeasti arvioiden puolet olisi kyvyiltään ja terveydentilaltaan sellaisia, että he voisivat sovellusta käyttää. Hyvin yksilöllistä ja haastavasti arvioitavaa on se, kuinka monen omaiset olisivat halukkaita osallistumaan ikääntyneen hoitoon (sovelluksen kriteeri). Voitaisiinkin ehkä ajatella, että potilasryhmä, joka sopisi käyttäjiksemme olisi suuruudeltaan n. 200 000 vuonna 2027, tällä hetkellä hieman vähemmän, koska teknologian hallinta, jota sovelluksen käyttäminen vaatisi, ei ole tuttua kovinkaan suurelle osalle tästä ikäluokasta. Toisaalta, jotta voitaisiin varmistaa tehokas käyttöönotto sekä hioa sovellus mahdollisimman sopivaksi käyttäjilleen, olisi sitä erittäin hyvä pilotoida asiakkailla rajatulla ja maltillisella potilasryhmällä. Näin ollen mikäli sairaanhoitopiirit eivät juuri tällä hetkellä laskisi sovellusta kannattavaksi pienempien potilasryhmien vuoksi, on tulevaisuudessa tiedossa laajempi potentiaalinen käyttäjäkunta.

index

Lähde: Tilastokeskus

Sovelluksen käyttöön kuluu sairaalan henkilökunnalta aikaa, joten sen käyttöä ei kannata aloittaa jokaisella potilaalla. Jotta sairaalat/sairaanhoitopiirit voisivat parhaiten hyötyä tästä sovelluksesta, tulisi heidän identifioida omasta potilasmäärästään ne, joilla on eniten käyntejä. Tässä saattaa olla alueellisia eroja, mutta esimerkiksi diabeetikoilla, muistipotilailla sekä esimerkiksi infarktipotilailla tulee useita sairaalakäyntejä vuodessa. Pyrimme jatkossa saamaan hieman tarkemman kuvan otollisista potilasryhmistä, mutta haluaisimme säilyttää päätäntävallan asiakkailla. Tämä vaatisi mahdollisesti pientä hiomista sovelluksen valintoihin, mikäli potilasvalinta poikkeaisi oletusvalinnasta, mutta sovellukseen olisi melko vaivatonta tehdä tällaisia pieniä kustomointeja.

Käytännössä alkuinvestointina ratkaisussamme toimii sovelluksen kehitykseen kuluvat rahat. Karkeasti ajateltuna puolen vuoden tiiviin kehitysprojektin aikana kuluisi suunnilleen koodareiden palkat (5 (hlö) x 3000€/kk x 6kk=90 000 €) sekä tietoturvaan ja lakiasioihin liittyvä konsultointityö (2 hlö x 7,5h/vk x 5pv/vk x 4vk x 50€/h= 15 000€) eli yhteensä reilu 100 000 €, yllättävien kulujen ilmaantuessa (mm. juoksevat kulut) arvioisimme kokonaissummaksi n. 120 000€. Tämä voitaisiin laskea poistoina esimerkiksi jaettuna neljälle vuodelle eli 30 000 € per vuosi.

Tämän jälkeen kustannukset käytännössä tarkoittaisivat pääasiassa ylläpito-, kehitys-, myynti-ja markkinoinit- sekä koulutuskustannuksia. Ylläpito ja kehitys ovat tärkeitä, jotta sovelluksemme arvo säilyy ja lisäksi haluaisimme helpottaa käyttöönottoa tarjoamalla käyttökoulutuksia henkilöstölle osana palveluamme. Myös online-tuki sovelluksen käyttäjille olisi mielestämme tärkeää, jotta saisimme varmistettua sovelluksen turvallisen käytön. Arvioimme epäsäännöllisten ylläpitoon menevien kustannusten olevan vuodessa n. 10 000 €/vuosi (vajaa 3kk täysipäiväistä työtä). Jatkossa tietoturva-asiat sekä henkilötietojen säilyttämistä koskevat säännökset muuttuvat, joten ratkaisumme saattaisi jatkossa vaatia suuriakin investointeja siihen liittyen, tämä pitäisi siis osata huomioida myös esim. hinnoittelussa ajoissa.

Näin ollen mikäli saisimme 20 sairaalaa asiakkaiksemme (keskimäärin 2 viikkoa perehdytystä/työaikaa per sairaala vuodessa), pääsisimme 0-tulokseen hinnalla 2000 €/vuosi. Tämä on suuruusluokaltaan melko pieni kustannus, mikäli todella saadaan aikaan hoidon tehon lisääntymistä ja käyntien vähentymistä sekä ikääntyneiden toimintakyvyn parantumista.

 

Sovimme ryhmän kanssa myös toisen iteraation tavoitteet, joihin kuuluu seuraavat asiat:

  • Prototyypin työstäminen
  • Taloudellinen validaatio sekä alustava suunnitelma tuotteen kaupallistamiseksi relevantteine lukuineen ja ennusteineen valmiiksi
  • Ongelman ja ratkaisun selkeän ja yksityiskohtaisen kuvauksen tuottaminen
  • Käyttövalmiin ratkaisun esittäminen (demo)

Viime viikolla sovittiin, että prototyypin työstäminen on jaettu kahteen 2 viikon pituiseen jaksoon: ensimmäinen varsinainen prototyyppi-iteraatio tulee valmistumaan tämän viikon loppuun mennessä. Aiomme kokoontua 13. marraskuuta tarkastelemaan niin prototyypin kuin muiden asioiden edistystä.

Suoritamme kuluvien viikkojen aikana niin tuotteen kuin taloudellista validaatiota. Näin pystymme parantamaan sovelluksemme laatua sekä laskemaan tarkempia lukuja ja luomaan parempia ennusteita.


Reflektio — miten meni ja mitä seuraavaksi

Saimme perjantain esityksessä hyviä kommentteja mm. liittyen ratkaisun ja proton eroon. Pohdimmekin tätä ryhmän kesken ja päätimme budjetoida aikataulullisesti hieman lisää myös taloudelliseen validaatioon sekä kokonaisratkaisun loppupalautuksen hiomiseen, jottei proto veisi huomiotamme liikaa.

Proton käytännön toteutuksessa opimme varmasti paljon, kun jouduimme samanaikaisesti pohtimaan talouspuolta sekä myös teknistä toteutusta. Proto kuitenkin etenee hyvää vauhtia, joten pääsemme jo ensi viikolla testaamaan ensimmäistä versiota eli pääsemme validoimaan jo itse ratkaisua käytännössä!

Kaupallistamisen näkökulmasta havaitsimme suuria aukkoja ratkaisussamme. Pitää selvittää, kenen vastuulla hankinnat ovat (sairaalataso vai sairaanhoitopiiritaso) sekä mitä mieltä julkinen sektori ja yksityinen sektori olisivat hinnottelumallistamme. Haluaisimme myös alustavaa selvyyttä potentiaalisista käyttäjiksi sopivista potilasryhmistä, jotta osaisimme kohdentaa myös proton suunnittelua hieman paremmin. Lisäksi olisi hyvä tietää kriittisimmät lainsäädäntöön liittyvät seikat, jotka koskettavat ratkaisuamme, jotta osaamme ottaa ne huomioon kurssin laajuuden sallimissa puitteissa.

Jatkossa tulemme siis panostamaan haastatteluihin sekä niiden pohjalta tarkentamaan ennusteitamme käyttäjämääristä, proton vaatimista ominaisuuksista sekä talousluvuistamme. Näiden selvennyttyä teemme tarkemman tuloslaskelman ja tarkistamme hinnoitteluamme tämän pohjalta. Nämä ovat erittäin kriittisiä asioita, joten jos hintamme nousee kovasti saatamme joutua miettimään. Tämän viikon perusteella olemme kuitenkin edelleen oikein hyvillä raiteilla sekä hieman aikataulua edellä, joten tästä on hyvä jatkaa.

Posted by TP

This entry was posted in Main Branch. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *