Hoppa till innehållet

Standardprogram eller egenutveckling: pröva samma process

Jämför en befintlig modul, en ny produkt och egenutveckling med en utläggsansökan som ändras efter godkännande.

Daniel Hartmann2 min läsning
Skärm med en kugghjulsmodul och en pusselbit med kodsymbol, med gröna blyertsdetaljer.

Undersök först om ditt befintliga program kan hantera det avgörande arbetsflödet. En ny produkt och egenutveckling blir jämförbara när samma regler, data och undantag bedöms. En allmän visning av gränssnittet räcker inte.

Testfallet: en utläggsansökan ändras

Ett fiktivt företag får ansökan R-17 på 180 EUR. Chefen måste godkänna; från 250 EUR krävs även ekonomiavdelningens godkännande. Gränsen är en påhittad intern regel, ingen skatteregel. Efter godkännandet höjs beloppet till 320 EUR. Det tidigare godkännandet ska därför inte automatiskt gälla det nya beloppet.

Det behövs ansökan, belopp, underlag, sökande, godkännare och handläggningsstatus. Använd påhittade namn och testunderlag. Be att få se normalfallet och följande undantag:

Fall

Förväntat resultat

R-17 på 180 EUR

Behörig chef kan godkänna och beslutet går att följa upp.

Chefen är frånvarande

En uttryckligen behörig ersättare kan ta över. Andra medarbetare får inte godkännanderätt.

Beloppet höjs till 320 EUR

Det tidigare godkännandet upphör att gälla; ekonomiavdelningen deltar i den nya granskningen.

ERP-systemets budgettjänst är otillgänglig

Ansökan väntar på granskning; gränssnittet påstår inte att budgeten har godkänts.

Samma villkor för varje lösning

Börja med modulen i ditt befintliga ERP-system. Pröva sedan en lämplig standardprodukt inklusive den ERP-koppling som behövs. Skilj i båda fallen på vad som redan fungerar, vad som måste konfigureras och vad som kräver ytterligare utveckling.

Egenutveckling är till en början ett förslag med avgränsad omfattning. Funktioner som ännu inte har byggts är fortfarande oprövade. En skiss ska inte få samma bevisvärde som ett genomfört test.

Ett genomarbetat exempel på resultat

I ett helt påhittat testprotokoll klarar alternativ A i det befintliga systemet alla fyra fallen när ersättaren har lagts in. Alternativ B, en tillkommande produkt, klarar normalfallet men behåller det gamla godkännandet vid 320 EUR. Det rapporterar också att allt lyckats när budgettjänsten ligger nere. Detta är exempel, inte påståenden om verkliga leverantörer.

För exempelföretaget är A fortsatt aktuellt. För B behöver man reda ut om konfiguration eller anpassning löser de två felen. Ett nytt test och extra arbete ska ingå i offerten. Ett trevligare gränssnitt löser inte saknade processregler.

Jämför kostnader för samma omfattning

Bedöm införande, datamigrering, ERP-integration, löpande avgifter, drift, underhåll och ett framtida byte under samma period, exempelvis tre år. Anteckna antaganden om användarantal och kommande ändringar. GOV.UK Service Standard kopplar också teknikval till totalkostnad och möjligheten att senare byta riktning.

Om den befintliga modulen uppfyller de nödvändiga reglerna kan införandet stanna där. Om ett viktigt fall förblir olöst i alla prövade produkter, beskriv just det som underlag för en riktad utbyggnad eller egen applikation. Utvecklingsbeslutet får då ett krav som går att kontrollera.

Källor

Skriven av

  • Daniel HartmannRedaktör för teknik och näringslivDaniel Hartmann skriver om teknikbeslut i företag på ASES. Han behandlar mjukvaruinvesteringar, val av lämpliga lösningar och planering av digitala projekt.

Följ ASES

Läs vidare

Alla artiklar

Mjukvaruutveckling med ASES

Skräddarsydd programvara, webb- och mobilappar