Hur värderar man en applikations livslängd?

Jag sitter just nu och ska försöka dels värdera mina applikationer, men även sätta en livslängd på dem.

Det jag ska värdera är en e-handelslösning med administration, en inköpsportal och ett projektidssystem.


Lite fakta:
e-handelslösning, 1 pers beräknat 8h/dag i 3 mån.

Inköpsportalen, 3 pers 8h/dag i 6v.

Projekttidssystemet, 1 pers, gissar på 1 mån utvecklingstid.
Tanken är att jag ska köpa in dessa till min firma när den går igång senare i höst.

[Edit]
Kan man räkna t ex 600kr/h * arbetad tid och ange det som värde på applikationen,
eller ska man räkna med ett lägre värde, isådant fall, hur ska man räkna?
[/Edit]

Andra tips å trix mottages tacksamt.


//Anna-Karin

Jag har svårt för att föreställa mig någon generell tillförlitlig metod att beräkna en applikations livslängd på.
Det beror på så många olika faktorer.
Viktigast är väl applikationens kvalitet, stabilitet, och prestanda. Man måste åtminstone ta med detta i beräkningarna, och hur beräknar man det på ett korrekt sätt.. ?
Vi har stordatorsystem i vår organisation som har rötterna i tidigt 80-tal, i vissa fall ännu tidigare.
Och de används fortfarande år 2004. Givetvis har de förändrats och förbättrats med tiden men det är i grunden samma systemlösningar. Det finns alltså system i drift som är 20-30 år gamla, t.ex. inom bankvärlden är det inte ovanligt.
Några mindre lyckade projekt från sent 90-tal klarade sig bara i några år, om ens det.
Skriver man ett system nu i .NET och gör det rätt då tror jag det kan hålla i 10-20 år, men det är väldigt svårt att sia om detta, ingen vet ju hur det ser ut på Windows/.NET plattformen om 10 år.

Ola

Det verkar vara en svår nöt det här så jag stänger tråden.

Det är svårt att värdera en applikation och framförallt hur länge den "lever".
E-handelslösningen har "levt" sen -99 och kommer väl att leva ett tag till, frågan är bara hur man värderar livslängden på den när man ska skriva av den. Tar jag in den i företaget så vill jag ju inte skatta bort pengarna. Koden är ju skriven innan jag startade eget.

Många funderingar är det och kommer det att vara..

//Anna-Karin

Jag tror att många väljer att inte skriva av sånt, just för att det är så svårt att göra det rätt.
I stället tar man smällen det år man gör investeringen, och det får helt enkelt bli sämre resultat det året, man får då ha i minnet att man gjort vissa investeringar det året..
Eller så drar man till med en grov gissning.
Jag är inte ekonom så jag kan inte svara på vilket som är mest korrekt ur redovisningssynpunkt, men den förstnämnda metoden bör vara säkrast :)

Ola

Därför skall man också sälja källkoden så att köparen har möjlighet att porta till nyare system.

Skulle aldrig investera i ett system om jag inte fick tillgång till källkod.

man brukar väl räkna att ett program kan säljas i ca 3 år utan att skrivas om totalt.

är det ett jobb som ska utföras åt en kund så självklart prissätter man per timme man tror att det tar att utföra jobbet , så är det ju upp till kunden att godta det eller inte.

ska du sälja rättigheterna till en befintlig produkt med ett injobbat namn och befintliga kunder så kan du höja priset ganska rejält.

ska man flytta rättigheter för kod från ett bolag till ett annat , tex från sitt eget hb till ett eget ab så ska man bevisligen inte värdera koden alls... vi pratade med våran revisor om det och hon sa att det vore bara korkat eftersom man får skatta på det. där skulle man bara anta att koden var värd 0 kr och tuta och köra...

//Roger

Har du varit ute och hälsat på i verkligheten någon gång Sven??

;)

/K