Så kostnadsestimerar du din mobila satsning (Whitepaper)

50 %
50 %
Information about Så kostnadsestimerar du din mobila satsning (Whitepaper)
Technology

Published on February 16, 2014

Author: ScreenInteraction

Source: slideshare.net

Description

I två delar hjälper vi dig att bryta ner och förstå vilka faktorer som påverkar utvecklingskostnadena för en app. Del 1 handlar om de största besluten du kommer behöva fatta. I del 2 förklarar vi hur du konkret kan avgöra projektets storlek – och därmed kostnad med hjälp av några enkla verktyg.

Så kostnadsestimerar du din mobila satsning 1

Vi är en design & innovationsbyrå som hjälper våra kunder att skapa morgondagens digitala tjänster och produkter. 2

VÅRA TJÄNSTER User Insights & Advisory Services Service Design User Research Mobile Strategy Strategic Advisory Services UX Management Advisory Services Business Innovation Trends & Forecasts Business growth / Conversion Optimization Design Innovation User Experience Interaction Design Concept Development Interface Design Responsive Design Creative Services Copywriting Product Development Project Management Technical Development Mobile Development Technical Platforms Continuous Integrations Lifetime & Maintenance 3

URVAL AV VÅRA KUNDER Mobilstrateg & Affärsansvarig Reza Assareh +46 (0)706 85 01 92 reza.assareh@screeninteraction.com 4

Den kanske vanligaste frågan våra mobilstrateger får från företag är vad en mobilsatsning kommer att kosta. Svaret vi ger är alltid detsamma: det beror på. Precis som när du köper en bil eller spelar in en film kan du nå målet med både en liten och stor budget – med ett resultat därefter. Frågan är snarare vad du behöver och hur vi kan hjälpa dig nå dit. Och när du pratar om kostnader, vad är det egentligen du lägger in i begreppet? I två delar kommer vi att bryta ner och visa dig vilka faktorer som påverkar kostnaden. Del 1 handlar om de största besluten du kommer behöva fatta. I del 2 förklarar vi hur du konkret kan avgöra projektets storlek – och därmed kostnad med hjälp av några enkla verktyg. 5

Sex primära kostnadsfaktorer 1. 2. 3. 4. 5. 6. Vilken typ av mobila enheter och operativsystem ska lösningen stödja?  Vilken teknik bör du använda?  Vilka är säkerhetskraven? Hur känslig information kommer du att hantera?  Är mobillösningen fristående eller ska den kommunicera med exempelvis intranät och affärssystem? Leveransalternativ. Kommer du att distribuera appen via de stora app-butikerna eller företagets egen lösning?  Förvaltning. Vilka framtida behov av support, underhåll och förbättringar kommer att finnas? 6

1. Mobila enheter och operativsystem Om företaget förser alla anställda med samma telefonmodell behöver du bara ta hänsyn till ett operativsystem. Däremot får du direkt en högre hårdvarukostnad. Om de anställda istället använder sina egna mobiler undviker du hårdvarukostnaden, men behöver istället stödja olika typer av enheter och operativsystem. Tänk på att företagets säkerhetspolicy kanske förhindrar privata mobiltelefoner från att ansluta till interna stödsystem. 2. Välj rätt teknik Native innebär att mjukvaran är utvecklad specifikt för ett visst operativsystem, medan HTML5 är en webbstandard och därför fungerar på de flesta mobila enheter. I reflektionen delade vi även med oss av en mall för att lättare kunna fatta rätt beslut. Valet av teknik beror exempelvis på användarnas behov, säkerhetskrav och den planerade livslängden hos mobilsatsningen. Generellt är en HTML5-lösningen det billigaste alternativet medan en native-app ger dig högre prestanda och säkerhet. 7

3. Säkerhetskrav En säkerhetslösning har alltid två sidor. Det uppenbara är att den behöver vara tillräckligt säker för det tänkta användningsområdet. Ännu viktigare är att den är enkel att använda. Risken är annars stor att användarna väljer bort tjänsten. Om du hanterar känslig data, där appen är kopplad till andra stödsystem, behöver du givetvis tänka på användarprofiler, inloggningar och krypteringar – som alla kan ha stor påverkan på kostnadsbilden. 4. Fristående eller integrerad lösning Kopplingar mot affärssystem, databaser och intranät är stora kostnadsfaktorer. Ibland är en fristående applikation både billigare och mer passande. Men oftast vill företag ge anställda eller kunder ett eget större ansvar för att själva sköta sin ärenden – som att logga in på banken, betala räkningar och överföra pengar. Ett annat vanligt syfte med mobila satsningar är att effektivisera verktygen du redan har genom ett nytt arbetsflöde och just mobilitet. En fristående applikation utan kopplingar mot affärssystem eller höga säkerhetskrav är billigare och går snabbare att utveckla. Frågan är om den ger dig rätt affärsnytta. 8

5. Appstore eller egenlösning Det finns två kategorier av appar för företag. De som distribueras öppet via Apples, Googles och Microsofts marknadskanaler, och de som är interna arbetsverktyg/ tjänster och bara relevanta inom företaget. Givetvis kommer de två varianterna med olika för- och nackdelar. Om du vill nå så många som möjligt bör appen vara tillgänglig på App store, Google play och Windows store. Det är inte svårare än att ansöka om en utvecklarlicens – som kostar drygt 700 kronor per år – och skicka in appen för godkännande. Men det är också i godkännandeprocessen du kan stöta på problem. Eftersom appen kommer att finnas i de stora nätbutikerna behöver den följa deras riktlinjer och krav på säkerhet och innehåll. Är appen däremot enbart relevant inom företag – och kanske bara för vissa anställda – är den bästa lösningen antagligen att distribuera den själv. Det finns färdiga lösningar för detta. 6. Förvaltning och support Utvecklar man kampanjappar är projektet ofta färdigt efter lanseringen. För arbetsrelaterade appar med en livslängd på 3–4 år kommer du däremot att behöva göra uppdateringar när nya versioner av operativsystemet släpps. Och bara för att appen är lanserad är den inte färdig. Det är nu du har stora möjligheter att optimera den, baserat på användarnas beteende och synpunkter. 9

Genom att tänka på appens hela livscykel redan i planeringsstadiet är det lättare att överblicka och förstå den totala kostnaden – inte bara den för utvecklingen. Rätt mobilstrategi skapar affärsnytta och gör att ditt företag undviker onödigt integrationsarbete. Sandbergit.no (25+50+25)*1.25-regeln Nu är det dags att introducera (25+50+25)*1.25-regeln. Tänk på att den här kostnadsfördelningen är ungefärlig och kommer att se olika ut beroende på ett flertal variabler: hur ditt företags mobilkultur ser ut, hur avancerade användarinteraktioner du vill ha, hur prototypen kommer att se ut och ifall du vill använda native-teknik eller inte. 10

Ett sätt att förenkla kostnadsberäkningen är att skapa en grundtidslinje för utvecklingen av appen. När man har en grund att utgå ifrån kan man justera den utifrån projektets komplexitet och tidigare erfarenheter, men låt oss titta på hur (25+50+25)*1.25-regeln ser ut i sitt ursprungsutförande: ·     De första 25 procenten går till planering, kravspecificering, att ta fram användarfall, undersöka arbetsflöden och skapa en prototyp som man kan visa upp för olika intressenter. ·      De 50 procenten i mitten av processen går till design och teknisk utveckling. Man utvecklar användbarheten, testar och felsöker mobillösningen fristående från resten av systemet. Det kanske låter enkelt men är ett mycket tidskrävande moment. ·      De sista 25 procenten består av att testa hela det integrerade systemet. Fokus ligger på säkerhet, användbarhet och prestanda. Man testar ifall mobilsatsningen möter kravspecificeringen och slutanvändarens förväntningar. Under den här fasen arbetar utvecklarna med beskrivningar av appen, till exempel med skärmdumpar och begripliga förklaringar av appens olika funktioner, som kan användas i App Store, Google Play eller de interna kanalerna. ·      Slutligen multiplicerar du den totala tiden med 1.25, du lägger alltså på 25 procent för projektledning, kommunikation med olika intressenter och andra administrativa uppgifter. En tumregel för tidsåtgången när man arbetar med en ny mobilsatsning är ungefär en veckas arbetstid för varje skärmbild i systemet. Det är visserligen sant att det inte finns något ”normal” tidsåtgång för en app, men det här är ändå en bra fingervisning. 11

Om din app till exempel har åtta huvudsakliga skärmbilder kan vi uppskatta tidsåtgången till åtta veckor. Enligt (25+50+25)*1.25-regeln kan du då dela upp tiden så här: två veckors prototyparbete, fyra veckors utveckling och två veckor för sluttester och sedan ytterligare två veckor (multiplicera med 1.25) för projektledning under hela processen. När vi har gjort en grunduppskattning av tidsåtgången för din mobilsatsning måste vi räkna in de faktorer som vi nämnde tidigare och justera vår tidslinje efter dem. Här är de vanligaste faktorerna, som vi kan betrakta som ”tillägg” till vår tidslinje: Faktor Uppskattad tidsåtgång Företagsspecifika faktorer / utvecklingskultur + 1 till 3 veckor Komplex funktion i gränssnittet + 1 till 3 veckor Login funktionalitet . t.ex signering/ verifiering + 2 till 4 veckor Offlinesynkronisering + 1 till 2 veckor Support för dynamiskt innehåll (CMSgränssnitt) + 2 till 3 veckor Utveckla för en ny plattform Dubbel utvecklingstid Detaljerad varumärkesanpassning + 2 veckor 12

Skärmstorlek och operativ version Skärmstorleken påverkar självklart utvecklingen av mobilapplikationer. Att anpassa en app efter både porträttoch landskapsvy (stående och liggande vy) tar också extra tid. Man måste anpassa alla objekt och marginaler för att de ska fungera i olika vyer. I vissa fall ändras appens funktion när man vänder på enheten och hamnar i en ny vy, till exempel när en kalender ändrar från månadsvy till dagsvy. De här förändringarna ökar komplexiteten och därför också tidsåtgången. Om du vill att en iPhone-app ska fungera även på iPad är det överlag bara små grafiska förändringar som behöver göras om du använder ”2X”-metoden. Android kräver större förändringar eftersom de grafiska förhållandena är relativa och varje skärmbild måste anpassas manuellt. Ju fler Android-enheter du vill att din mobilsatsning ska stödja, desto större blir tidsåtgången eftersom varje skärmbild måste göras om eller i varje fall uppdateras. Dessutom krävs mer testning vilket också tar tid. I vårt exempel med två veckor för att göra en prototyp av appen, kan det lätt växa till tre veckor före och efter programmeringen ifall vi lägger till fler Android-enheter eller om appen beter sig annorlunda på telefon respektive surfplatta. Det blir allt vanligare att man utvecklar separata appar för telefon och surfplatta, så att man utnyttjar det tillgängliga utrymmet på skärmen maximalt och matchar användarnas förväntningar på appen. 13

Integrationer med webbtjänster och affärssystem Appar som är fristående och inte integreras med andra företagssystem fungerar överlag bra i vår grundtidslinje. I de fall man vill ha användarsignering/verifiering, eller integration för att säkra systemet bakom företagets brandvägg (t.ex. CMS-gränssnittet) eller använda andra externa interaktioner, krävs extra arbetsresurser till programmeringsdelen av projektet. I vårt exempel med fyra veckors utvecklingstid för en enkel mobilapplikation, skulle det krävas ytterligare en heltidsresurs för att inte påverka tidsåtgången ifall appen kräver en säker integrering. Eftersom vi skapar appar som skall användas internt hos företag är kryptering och säkra överföringar en ofta naturlig del av integreringsarbetet. 14

Den största kostnadsfaktorn: antal operativsystem du utvecklar för En app som är byggd med native-teknik för två operativsystem är i själva verket två appar. Android-kod kan inte användas direkt i andra operativsystem och vice versa (t.ex. iOS, Symbian och Windows). Skärmarna ser olika ut, Photoshop-tiden fördubblas om vi behöver utveckla appen till två operativsystem. Koden är på ett annat programmeringsspråk, så tiden för programmering och testning fördubblas. Endast vissa delar är i regel återanvändbara: - arbetsflöden och viss interaktionsdesign - till viss del testplanering - externa integrationer I övrigt blir det alltså i princip en dubblering av arbetsbördan. Mobile Operating System Market Share 2012, icrossing.co.uk 15

Den största kostnadsfaktorn består alltså av appens stöd för olika operativsystem, låt oss därför ta en titt på vilka valmöjligheter som finns och vilka beslut du måste ta för att kunna använda dig av flera operativsystem. Hur man väljer att göra här är en vattendelare bland programmerare, det finns många olika åsikter om vad som är ”rätt” och ”fel”, därför ska vi försöka se på alternativen så objektivt vi kan. Om det bara vore en kostnadsfråga vore det enkelt, men eftersom valet också påverkar användarupplevelsen måste man väga in helheten när man gör sitt val. De viktigaste skillnaderna mellan de olika alternativen är: Native-teknik Det dyraste alternativet både att utveckla och underhålla, men ger också den bästa användarupplevelsen. Om vi använder native-teknik kan vi använda respektive operativsystems fördelar maximalt, både mjukvaran och hårdvaran (kameran, lokala databaser, GPS osv.). Eftersom användarna ofta jämför alla appar mot deras favoritappar ligger ribban högt vad gäller användarupplevelsen, vilket talar för native-tekniken. HTML5 Kostar minst att utveckla och att underhålla. Det mesta av ”systemet” finns på en extern server istället för i den mobila enheten, innehållet anpassas bara efter skärmen. HTML5 har bra stöd för till exempel videovisning och nu när HTML6 börjar ta form finns det hopp om att webbapplikationer kommer att närma sig native-tekniken vad gäller integrering. 16

Utmaningarna med HTML5 är bland annat hur man ska hantera enhetsspecifik hårdvara, databaser, nätverksanslutningar och olika användarkommandon som i dagsläget varierar mellan de olika operativsystemen. Multi-plattformutvecklingsverktyg för appar Multi-plattformutvecklingsverktyg för appar är en lösning som ligger någonstans mellan native-teknik och HTML5 vad gäller pris. Lösningen erbjuder möjligheten att dela kod mellan olika plattformar. Tänk på att kvaliteten mellan olika alternativ här varierar mycket både vad gäller användarupplevelse och vilken typ av appar de har stöd för. Utvecklingen går fort på det här området och utvecklarna vill så klart komma så nära native-tekniken som möjligt i användarupplevelse utan att behöva använda nativekodning. Ofta använder man sig av till exempel JavaScript för att skapa appens kärnfunktioner, och gör sedan anpassade ”skins” för de olika enheterna/ operativsystemen för att imitera native-upplevelsen. De flesta användarna har inte koll på hur teknologin bakom appen fungerar, men de uppfattar ofta appen som ett slags mellanting mellan native och HTML5. 17

Sammanfattning För att kostnadsestimera din mobila satsning finns flera olika verktyg och mått att utgå ifrån. Ett sätt att uppskatta tidsåtgången och fördelningen är att använda (25+50+25)regeln, där antalet huvudsakliga skärmbilder i systemet kan vara en fingervisning för det totala antalet veckor. Förutom grundtidslinjen tillkommer också några vanliga tilläggsfaktorer som förlänger utvecklingstiden (till exempel offlinesynkronisering, login eller ny plattform) och därmed kostnaden. Om du vill få konkreta exempel på hur de här uträkningarna kan se ut i verkligheten, läs gärna våra tre fallstudier nedan. 18

Räkneexempel Det finns många faktorer som kan påverka kostnaden för ett mobilutvecklingsprojekt. De övergripande faktorerna och utvecklingsmöjligheterna som vi diskuterat ovan hjälper dig att ta bra affärsmässiga beslut. I våra beräkningar nedan utgår vi från ett timpris på 1000 SEK/h och en arbetsvecka på 40 timmar per FTE (heltidsanställd). För enkelhetens skull bortser vi från faktorer som utvecklingsteamets kompetens, erfarenhet och outsourcingmöjligheter. Dessa faktorer kan påverka kostnaden för projektet med ungefär +/- 30 %. Varje utvecklingsprojekt är unikt och beräkningarna är grovt generaliserade. Därför kan estimeringarna variera mellan apputvecklingsbolag och team. Fallstudierna bör endast användas som riktlinjer och som beslutsunderlag för investering i en mobil satsning och inte till offertförfrågning eller projektspecifikation. 19

Fallstudie 1 Enkel app med åtta huvudsakliga skärmbilder för en plattform, utan integrationer med andra webbtjänster. Användarscenario: Utvecklingsprojektet avser en native-applikation till iOS (iPhone) för beräkning av traktamente. I applikationen kan medarbetarna välja traktamentesbelopp från en skattetabell (sparad lokalt på telefonen) och beräkna sitt skattefria traktamente för varje affärsresa. Traktamentet mejlas sedan till lönekontoret som manuellt för in reseräkningen i bolagets ekonomisystem. Utgångspunkten är att vi utvecklar för en enhet (iPhone) och en plattform (iOS). Mobillösningen har inga integrationspunkter. Grundarbetet estimeras till: Cirka 80 timmar för design av flöden och appens användarupplevelse samt att skapa en klickbar prototyp för att testa lösningsförslaget mot målgruppen. Cirka 160 timmars utvecklingsarbete för iOS-plattformen (Xcode). Cirka 80 timmar av enhetstest, användbarhetstest och slutgiltigt acceptanstest av lösningen. Slutligen multiplicerar vi den totala projekttiden med 1.25 (adderar ytterligare 25 % till den totala utvecklingstiden) = 80 timmar för projektledning av teamet, kommunikation med beställare, hantering av tidsplan, och så vidare. Totalt estimeras projektet till cirka 400 timmar med +/- 20 % differens beroende på applikationens test-, kvalitets-, och användarupplevelseambition samt marknadsföring. Kostnaden är grovt räknat densamma oavsett operativsystem såvida det gäller en enhet. 20

Fallstudie 2 Samma specifikation som ovan fast med två integrationspunkter för att hämta aktuell pristabell och autentisering via företagets inloggningssystem. Användarscenario: Utvecklingsprojektet avser en native-applikation till iPhone 4 för beräkning av traktamente. Medarbetarna kan logga in med samma användarnamn och lösenord som de använder till företagets övriga webbtjänster. Det senaste traktamentesbeloppet och skattetabellen hämtas från en extern webbtjänst. Traktamentet mejlas till lönekontoret som manuellt för in reseräkningen till bolagets ekonomisystem. Utgångspunkten är fortfarande att vi utvecklar för en enhet (iPhone 4) och för en plattform (iOS). Lösningen kräver två integrationspunkter (mot företagets inloggningssystem och mot den externa webbtjänsten). Användarupplevelsen påverkas i och med en inloggningsvy där alternativa scenarion som felaktiga eller förlorade användaruppgifter (användarnamn och lösenord) måste hanteras. Grundarbetet estimeras till: Cirka 90 timmar för design av flöden, gränssnittsdesign, appens användarupplevelse samt att skapa en klickbar prototyp för att testa lösningsförslaget mot målgruppen. Cirka 180 timmars utvecklingsarbete för iOS-plattformen (Xcode). Cirka 80 timmars integrationsarbete per integrationspunkt (givet att API:er funkar och är testade) krävs. Systemarkitekten behöver designa datastrukturer, definiera REST-protokoll, installera och konfigurera säkerhetscertifikat mot inloggningssystemet. Detta arbete kräver en annan typ av kompetens och kan utföras parallellt med iOS-utvecklingen. Cirka 90 timmar av enhetstest, användbarhetstest och slutgiltigt acceptanstest av lösningen. 21

Slutligen multiplicerar vi den totala projekttiden med 1.25 för projektledning av teamet, kommunikation med beställare, hantering av tidsplan, och så vidare. (90+180+80+80+90)*1.25 = 650 timmar Totalt estimeras projektet till cirka 650 timmar med +/- 20 % differens beroende på applikationens test-, kvalitets- och användarupplevelseambition samt marknadsföring. Fallstudie 3 Samma specifikation som ovan fast för två plattformar till utöver iOS (Android och Windows Phone) samt ytterligare en integrationspunkt för att automatiskt föra in reseräkningen till företagets ekonomisystem. Användarscenario: Utvecklingsprojektet avser en native-applikation för beräkning av traktamente till iOS, Android och Windows Phone. Medarbetarna kan logga in med samma användarnamn och lösenord som de använder till företagets övriga webbtjänster. Den senaste traktamentesbeloppet och skattetabellen hämtas från en extern webbtjänst. Traktamentet och reseräkningen registreras automatiskt hos lönekontoret via bolagets ekonomisystem. Utgångspunkten är att vi utvecklar för tre plattformar (iOS, Android och Windows Phone). Vi har nu två val: a)    Utveckla de tre applikationerna till native specifikt för varje plattform, det vill säga Xcode för iOS, Java för Android och .NET för Windows Phone. b)   Utveckla de tre applikationerna med hjälp av multiplattformutvecklingsverktyg. Lösningen kräver tre integrationspunkter (mot företagets inloggningssystem, mot externa webbtjänsten, mot företagets ekonomisystem). Den tredje integrationspunkten påverkar inte användarupplevelsen eftersom detta sker i bakgrunden. Design, UX-arbete och test är dock oberoende av utvecklingsverktyg eller 22

native. Därför ökar projektets fas 1 och 3 i relation med antalet plattformar. Arbetet estimeras då till: Alternativ a: native-utveckling för varje plattform Cirka 90 timmar per plattform för design av flöden, gränssnittsdesign, appens användarupplevelse samt att skapa en klickbar prototyp för att testa lösningsförslaget mot målgruppen. Cirka 180 timmars utvecklingsarbete per plattform. Cirka 80 timmars integrationsarbete per integrationspunkt (givet att API:er funkar och är testade) krävs. Systemarkitekten behöver designa datastrukturer, definiera REST-protokoll, installera och konfigurera säkerhetscertifikat mot inloggningssystemet. Detta arbete kräver en annan typ av kompetens och kan utföras parallellt med apputvecklingen för plattformarna. Cirka 90 timmar av enhetstest, användbarhetstest och slutgiltigt acceptanstest per plattform. Slutligen multiplicerar vi den totala projekttiden med 1.25 för projektledning av teamet, kommunikation med beställare, hantering av tidsplan, och så vidare. (90+90+90+180+180+180+80+80+80+90+90+90)*1.25 = 1650 timmar Totalt estimeras projektet till cirka 1650 timmar med +/- 20 % differens beroende på applikationens test-, kvalitets- och användarupplevelseambition samt marknadsföring. Alternativ b: utveckling med multiplattform-utvecklingsverktyg Den stora skillnaden i det här fallet blir återanvändningen av kod mellan de tre plattformarna (ca 80 % återanvändning av kod). Utvecklingsarbetet estimeras därför enligt: Cirka 90 timmar per plattform för design av flöden, gränssnittsdesign, appens användarupplevelse samt skapa en klickbar prototyp för att testa lösningsförslaget mot målgruppen. Cirka 220 timmars total utvecklingsarbete för alla tre plattformar med 80 % återanvändning av kod mellan varje plattform. Cirka 80 timmars integrationsarbete per integrationspunkt (givet att API:er funkar och är testade) krävs. Systemarkitekten behöver designa datastrukturer, definiera REST-protokoll, installera och konfigurera säkerhetscertifikat mot inloggningssystemet. 23

Detta arbete kräver en annan typ av kompetens och kan utföras parallellt med apputvecklingen för plattformarna. Cirka 90 timmar av enhetstest, användbarhetstest och slutgiltigt acceptanstest per plattform. Slutligen multiplicerar vi den totala projekttiden med 1.25 för projektledning av teamet, kommunikation med beställare, hantering av tidsplan, och så vidare. (90+90+90+180+(180*0.2)+ ((180*0.2)*0.2)+80+80+80+90+90+90)*1.25 = 1254 timmar Totalt estimeras projektet till cirka 1254 timmar med +/- 20 % differens beroende på applikationens test-, kvalitets- och användarupplevelseambition samt marknadsföring. 24

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Samsung på vej ind i bil-branchen med stor satsning ...

Samsung følger i kølvandet på en række af sine konkurrenter med stor satsning rettet ... Så meget it er der i din ... Læs i dette white paper ...
Read more

AV Distribution A/S - Computerworld

Ingram Micros danske satsning har været i gang ... og hør hvilke muligheder du har, for at gøre din virksomheds værdier og viden så ... White paper ...
Read more

TDC i risikabel satsning med Microsoft - Digital | www ...

Men forpasser TDC dette marked, er konsekvenserne værre, siger teleselskabet. ... TDC i risikabel satsning med Microsoft. Af Jakob Skouboe, jse@berlingske.dk
Read more

Indland kort - EVB archive | www.business.dk

er blevet tilbudt ansættelse i fragtmandssystemet. Køber Volvo Silkeborg ...
Read more

Netværksfejl blokerer Microsoft Update - Computerworld

... og hør hvilke muligheder du har, for at gøre din virksomheds værdier og viden så ... Microsofts store satsning på cloud slog ... White paper ...
Read more

Datatilsyn: Hård kritik til tre kommuner - Computerworld

... og hør hvilke muligheder du har, for at gøre din virksomheds værdier og viden så ... Microsofts store satsning på cloud slog ... White paper ...
Read more

Seneste indlæg af icelands_ - Eksperten - Profil - icelands_

Er du træt af reklamerne på nettet, kan Adblock... ... De mobile platforme storhitter: Men vi begår en fejl med gamle applikationer og data.
Read more

Eksperten - Spørgsmål - PS/2 stik

Algoritmernes tid er kommet - snart vil de ændre alt for din virksomhed. ... Microsofts store satsning på cloud slog kraftigt igennem, ... White paper ...
Read more