Vad kännetecknar en bra systemutvecklingspartner?

Ett systemutvecklingsprojekt är sällan ett projekt. Det är början på ett åtagande som ofta sträcker sig över flera år: vidareutveckling, förvaltning, nya integrationer, ny personal på båda sidor. Därför är frågan inte bara vem som kan bygga systemet, utan vem ni orkar och vill arbeta med länge. Här är kriterierna som avgör – och signalerna som avslöjar mer än offerten.

Teknisk bredd eller spetskompetens?

Båda behövs, men i olika proportioner beroende på ert läge:

• Välj bredd när systemet ska leva länge och spänner över många discipliner – arkitektur, integrationer, gränssnitt, drift och säkerhet. Ett system som lever i tio år hinner byta både tekniktrender och krav, och då är förmågan att röra sig mellan områden värdefullare än djup i ett enda.
• Välj spets när problemet är avgränsat och stacken given: en prestandakritisk komponent, en specifik plattform, en migrering av en känd teknik.

Två kontrollfrågor hjälper dig att bedöma vad du faktiskt får. Be om CV:n för de personer som ska arbeta i ert projekt – bolagets samlade kompetenslista säger ingenting om ert team. Och be om ett exempel där de gått riktigt djupt i ett problem: bredd får inte vara ett annat ord för ytlighet.

Så bedömer du förmågan att ta arkitekturansvar

Arkitekturbeslut är de dyraste besluten i ett systemprojekt – de är billiga att fatta och dyra att ändra. En partner som ska ta ansvar för dem behöver visa tre saker:

• Ärlighet om egna beslut. Be dem berätta om ett arkitekturbeslut de fattat och ett de tvingats riva upp. Mogna team svarar konkret på båda; omogna har aldrig haft fel.
• Spårbarhet. Hur dokumenteras vägval? En partner som för beslutslogg med motiveringar lämnar efter sig ett system som går att förstå och ta över.
• Affärsspråk. Tekniska val ska kunna förklaras i kostnad, risk och livslängd. Den som bara kan motivera ett val med att tekniken är modern har inte tagit ansvar, bara valt.

Ställ också testfrågan: “Vad i vår idé skulle ni avråda oss ifrån?” En partner som tänker ta ansvar för arkitekturen vågar svara redan i säljmötet.

Varningssignaler vid de första mötena

• Ja till hela kravlistan utan en enda motfråga.
• En offert innan de förstått er verksamhet.
• Samtalet handlar om deras teknikval innan det handlat om ert problem.
• Otydligt vilka personer ni faktiskt får – säljaren är senior, teamet anonymt.
• Press mot ett stort åtagande direkt, i stället för förslag om en avgränsad start.
• Allting är “enkelt”. Systemutveckling är många små svåra saker; den som inte ser dem har inte tittat.

Ingen enskild signal fäller en leverantör, men två eller tre tillsammans är ett mönster.

Ett scenario: två offerter på samma system

Leverantör A tackar ja till hela kravlistan och lägger det lägsta priset. Leverantör B ifrågasätter halva listan, föreslår en första etapp kring de två mest kritiska flödena och redovisar öppet sina antaganden. B ser dyrare och besvärligare ut på papperet.

Men i ett flerårigt systemprojekt kommer kraven att ändras – det är det enda säkra. Då är B:s arbetssätt, att pröva antaganden och leverera i etapper, det som håller totalkostnaden nere. Offertpriset mäter startpunkten. Arbetssättet avgör slutnotan.

Kultur och arbetssätt avgör på lång sikt

Det som skaver lite i säljfasen skaver mycket år tre. Bedöm därför:

• Transparens: får ni tillgång till kod, backlog och löpande demos från start?
• Konflikthantering: fråga om ett projekt som gick snett och vad de gjorde. Alla har ett – frågan är vad de lärde sig.
• Kontinuitet: hur säkras kunskapen när personer i teamet byts ut?
• Referenser med historik: ring en kund som samarbetat med dem i minst tre år, inte bara den senaste nöjda lanseringen.

Vi på Weapp arbetar just så – som långsiktig partner inom systemutveckling, apputveckling och AI, med transparens som grundregel. Läs mer om våra tjänster eller boka ett förutsättningslöst samtal om du står inför valet.