# Miten rajataan yrityksen ensimmäinen oma web-sovellus?

Muotoilee sisäisestä tarpeesta pienen toteutuskelpoisen ensimmäisen version.

Rajaa ensimmäinen web-sovellus yhden käyttäjäryhmän yhteen päättyvään tehtäväketjuun. Sen pitää helpottaa oikeaa työtä alusta loppuun, mutta sen ei tarvitse sisältää kaikkia tulevia toiveita. Työnohjaus, varaukset tai raportointi voivat olla sopivia lähtökohtia, kun tarve ja tiedot ovat selviä.

Määrittelyn epävarmuus ei estä aloittamista. Kerro yksi tilanne, jossa työ hidastuu, ja näytä nykyinen tapa esimerkkitiedolla. Tavoitteena on ensin yhteinen ymmärrys siitä, mitä käyttäjä tarvitsee.

## Milloin Excelistä kannattaa siirtyä omaan sovellukseen?

Arvioi muutosta, kun samanaikainen käyttö, käyttöoikeudet, tiedon oikeellisuus tai toistuva siirtäminen aiheuttavat jatkuvaa haittaa. Taulukko voi edelleen olla paras työkalu pienelle käyttäjäryhmälle ja joustavalle, harvoin toistuvalle työlle. Pelkkä taulukon koko tai teknologian ikä ei ratkaise asiaa.

Kirjaa, mitä taulukolla ei enää pystytä tekemään luotettavasti. Jos ongelma korjaantuu yhteisellä mallilla tai nykyohjelmiston ominaisuudella, omaa sovellusta ei ehkä tarvita. Jos sama tehtävä tarvitsee hallitun prosessin ja eri roolit, sovelluksen arviointi on perustellumpaa.

## Ensimmäisen version rajauskortti

- **Käyttäjä:** kuka tekee työn ja missä tilanteessa?
- **Laukaiseva tapahtuma:** mistä käyttäjä tietää, että tehtävä alkaa?
- **Tehtäväketju:** mitä hänen pitää nähdä, tehdä ja vahvistaa?
- **Välttämättömät tiedot:** mistä ne tulevat ja kuka saa muuttaa niitä?
- **Valmis tulos:** mikä voidaan hyväksyä onnistuneeksi?
- **Poikkeus:** mitä tehdään, jos tieto puuttuu tai yhteys katkeaa?
- **Poisrajaukset:** mitkä lisätoiveet jätetään myöhempään päätökseen?

Kirjoita hyväksymiskriteeri käyttäjän tekona. Esimerkiksi: ”Työntekijä näkee hänelle osoitetun tehtävän, kuittaa sen ja esihenkilö näkee kuittauksen.” Täydennä tarvittavat käyttöoikeudet ja virhetilanne. Pelkkä ”helppokäyttöinen sovellus” ei vielä ole testattava vaatimus.

## Pienin hyödyllinen siivouksen työnohjaus

Mahdollinen ensimmäinen ketju on kohteen tehtävä, osoitettu työntekijä, lyhyt kuittaus ja esihenkilön näkymä puuttuviin kuittauksiin. Valitse yksi kohderyhmä. Palkanlaskenta, työajanseurannan korvaaminen ja asiakkaan portaali voidaan rajata pois, jos ne eivät ole tämän ketjun toimivuuden edellytyksiä. Rajaus pitää tarkistaa työntekijöiden kanssa; tämä ei ole valmis tuotepaketti.

Jos tehtävät muuttuvat kesken päivän, myös muutoksen näkyminen ja vastaanoton varmistaminen voivat olla välttämättömiä ensimmäisessä versiossa. Pienuus ei tarkoita, että tärkeä poikkeustilanne jätetään ratkaisematta.

## Miten lisätoiveet pidetään hallinnassa?

Pidä erillistä jatkolistaa. Jokaiselle toiveelle kirjataan käyttäjän tarve, vaikutus nykyiseen rajaukseen ja päätös siitä, siirtyykö se myöhemmäksi. Työmäärä, hinta ja aikataulu arvioidaan ennen sovittua lisätyötä. Näin tulevaisuuden mahdollisuudet eivät muutu huomaamatta ensimmäisen toimituksen velvoitteiksi.

Strategiaklinikka käyttää prototyyppiä työnkulun kokeiluun ennen toteutussuunnitelmaa. Jos kokeilu osoittaa, ettei oma sovellus tuo riittävää hyötyä, päätös voi olla valmisohjelma tai nykyisen toimintatavan muutos.

Katso [prototyyppi ja rajaus](/tieto/fi/prototyyppi-rajaus-ja-toteutus.md), [kokonaiskustannus](/tieto/fi/ohjelmistoprojektin-hinta-ja-kokonaiskustannus.md) ja [tarjouspyyntöpohja](/tieto/fi/ohjelmiston-tarjouspyynto.md).

## Lähteet ja julkaisutiedot

- [Strategiaklinikan palvelut ja toimintatapa](https://strategiaklinikka.fi/index.md)

Julkaisija: Strategiaklinikka. Päivitetty: 2026-11-05.

Pysyvä osoite: https://strategiaklinikka.fi/tieto/fi/rajattu-oma-web-sovellus.md

[Kaikki oppaat](/tieto/index.md) · [Palvelut ja yhteystiedot](/index.md)