Mjukvaruimplementeringsresan på tusen miles börjar med fas noll (James Monaghan)

Grattis. Du har bestämt dig för att implementera viss programvara och vill att den ska bli framgångsrik. Blir det Agile eller Waterfall eller Lean eller Scrum eller något helt annat. Även om ett framgångsrikt projektimplementering har sina egna krav för att driva det, där
är många saker man bör tänka på innan avspark.

Har måloperativmodellen definierats tillräckligt?

Att rusa in i en implementering av ny teknik har många fallgropar, men inga vanligare än att börja distribuera/integrera ett system utan att överväga hur den övergripande bilden kommer att se ut när den är klar. Alldeles för många projekt har skadats
upp tillbaka i början eftersom någon viktig del av tekniken inte ingick i det övergripande systemet. Med alla fintechs och störare på marknaden idag, kommer alla att sträva efter att sömlöst integrera med varandra, men utan en fullständig förståelse
of hur du vill att de ska ansluta och av vilken anledning kan du lätt hitta på att du gör om din måloperativmodell halvvägs och måste kasta bort all ansträngning och resurser du har spenderat hittills. Det är som att försöka bygga planet medan
flyga den eller byta bildäck medan du kör den. Typiska TOM:er kommer att ha ett CRM-system (Customer Relationship Management) som den kundvänliga personalen kan använda, kopplat till ett Client Lifecycle Management-system som innehåller ett arbetsflöde och regelmotor
att skicka de nödvändiga uppgifterna till relevanta personer för att slutföra datainmatning/dokumentuppladdning/validering och verifiering. Det kan finnas ett Master Data Management-system (MDM) som behandlas som Source of Record/Golden copy, men alltför ofta är detta en siled
system med flera aggregerade eller integrerade datalager med olika system som kan uppdatera journalerna. Det kan finnas transaktions-/handels-/utlåningssystem med inbyggda eller integrerade transaktionsövervakningstjänster. Det kan finnas tredjepartsleverantörer för data/dokument
eller nyheter/negativa nyheter/screeningsändamål. Alla eller några av dessa kan också vara molnbaserade eller på premisssystem. Så nu frågar jag dig igen, har du funderat på var denna 1 nya teknik passar in i din totala TOM och är det en slutversion eller är du
integrera den i den nuvarande installationen men planerar att ändra detta i framtiden

För alla dina nuvarande system, hur länge planerar du att stödja dem/bevara dem?

Det finns ett vanligt misstag som kallas Sunk Cost Fallacy där bara för att du har spenderat X dollar/euro/pund på ett system är det för långt kvar för att erkänna nederlag och skrota det. Eller att den inte är trasig så behöver inte fixas. Eller att det är för förankrat
i nuvarande system för att kunna ta bort eller ersätta den. Om så är fallet, har du sannolikt hamnat på en enda punkt av misslyckande utan att ens inse det. Moderna tekniska lösningar är flexibla och bör byggas för förändring. Tidigare fusioner/förvärv
eller sammanslagning av system har tvingat tekniken att integreras och den vanliga processen är att helt enkelt få den att fungera. Dessa bör behandlas som de möjligheter de är att ompröva hur något görs och sträva efter ett mer effektivt sätt. Andra
till detta kommer de flesta nya teknologier att ha eller göra anspråk på att ha liknande erbjudanden/moduler/funktioner som rapportering, instrumentpaneler, arbetsflöde, ärendehanteringsreglermotorer, konfigurationsstudio. Målet med detta är att tilltala en så bred publik som möjligt och har
vissa människor tänker "Varför behöver jag köpa X när Y redan har den förmågan?". Men med detta i åtanke, vill du verkligen förvandla ditt CRM till ett transaktionsövervakningssystem? Eller ditt kontosystem in i gatewayen för din MDM? Eller din MDM som rektor
datainmatningspunkt. Du vet att du kommer att få tusentals poster med telefonnummer som 12345678.

Bemanning/Roller

För att en implementering ska bli framgångsrik kommer du att ha dina definierade roller på båda sidor av projektet. Dina och försäljarna. Det beror självklart på budget, omfattning och tidslinje. Du kan ha en 4 veckors molnbaserad implementering som kräver 2 anställda från
leverantören eller det kan vara 10 faser av 12 veckors stora utgåvor med 2 veckors agila kravupplägg bestående av affärs-/produktanalytiker, utvecklare, ämnesexperter, kvalitetssäkringstestare, som alla behöver både junior- och seniorroller, projekt
chefer för varje bransch/region/jurisdiktion och en programchef för att övervaka det hela. Släng in en projektsponsor och det är lätt att se varför företagsprogramvaran blir dyr, ibland oöverkomligt. Detta är också innan man tänker på personalnivåerna
som du behöver allokera för att matcha. Glöm inte att dina anställda som är involverade i detta projekt kommer att vara borta från sina dagliga roller under en avsevärd tid. Det är viktigt att se till att säljarens personal är erfaren och inte har varit det
nyligen anställd för att möta efterfrågan på ditt projekt.

Den andra faktorn är partnerskapsmodellen. Många etablerade leverantörer har certifierade partners, några boutiqueföretag och några av de fyra stora, som också kan utarbetas för att hjälpa till med implementeringar, men som också har ett pris.

Dataöverföring

Ett av de stora teman som införlivar en ny mjukvara är övervägande av dataåtkomst och/eller datamigrering. Om det nya systemet kommer att fråga efter din nuvarande databas eller databaser efter behov, när får det åtkomst, vilka användare har vilka behörigheter
för att komma åt den, är åtkomsten skrivskyddad eller kan användarna redigera eller skapa nya poster och när de uppdaterar den centrala posten, vilka system har prioritetsordning för att göra dessa ändringar? Tänk om ett annat system försöker göra en förändring medan en annan användare
av din nya teknik redigerar den för närvarande? Betyder detta nu att alla förfrågningar om dataredigering ska dirigeras via den nya tekniken? Vad händer när alla nya teknologier begär samma prioritetsordning? Dessa är bara för aktiva kundregistersystem.
Vad sägs om att skapa ett nytt konsoliderat enda system? Ska du ta big bang-metoden för att migrera all data dag 1? Föreställ dig riskerna. Vad sägs om en övergångsperiod, till exempel när en granskning är schemalagd, du hämtar från en eller flera källor för att utföra granskningen
och skicka sedan den rena posten till den nya centrala databasen. Det skulle tillåta migrering under en period på 12–18 månader istället. Det är inget som passar alla. Det är allt innan du någonsin börjar överväga att hantera dubbletter.

integrationer

När du överväger att lägga till en ny teknik till ditt ekosystem måste du se till att den fungerar sömlöst med din nuvarande inställning. Detta har 2 alternativ initialt, antingen som ett nettotillskott för att lösa ett specifikt problem eller som en ersättning till ett befintligt system
eller system på plats. Hur som helst vill du se till att den har tillgång till de relevanta systemen som den behöver för både uppströms- och nedströmskonsumtion. Du måste också vara säker på att alla befintliga VVS-system till systemet som avvecklas kan underhållas.
Det finns också en fråga om tillstånd som konsekvent förbises. Användaråtkomstkontroll för att styra vilken behörighet användare har för den nya tekniken för data som den har tillgång till, samtidigt som den säkerställer att det inte finns några krav på administratörsbehörighet.
Men när du lägger till en nyare teknik i framtiden, behöver du då förfina åtkomstkontrollen för alla historiska system? Som med ovan också, låt oss inte glömma behovet av att bestämma vilken teknik som har prioritetsordning för dataändringar/uppdateringar. Annat
hur ser du till att system A gör en förändring idag, system B vänder på den i morgon och system A försöker igen dagen efter.

Systemåtkomst – Infosec-policyer

Har du engagerat relevanta team internt för att tillhandahålla resurser och tillgång till relevanta system i tid. Om du planerar att vänta till sista stund innan du begär tillstånd för en miljö eller tillgång till en databas, etc. Du
kanske bara upptäcker att dina måldatum plötsligt är ouppnåeliga.

Köpare kontra användare

Är slutanvändarna av den nya tekniken involverade i beslutsprocessen? Vad är poängen med att fatta ett beslut på uppdrag av andra användare, om de i slutändan bestämmer sig för att det som byggs inte är lämpligt för deras syften. Kampen mellan näringslivet och
IT är en konstant sådan som förekommer överallt, och svänger fram och tillbaka när det gäller vem som får bestämma. Utformningen av systemet förväntas alltför ofta lösa alla problem, för varje användare, perfekt. Överkonstruera tekniken för att lösa till 100 %
är beundransvärt men i slutändan en resurstung strävan. Det initiala målet bör vara att lösa för majoriteten och vänta tills leveransen lyckas innan du försöker med kantfallen. De sista 20 % eller 10 % av emissionerna borde inte hålla för det huvudsakliga syftet med förvärvet
tekniken, men alltför ofta blir det alltförtärande. Frågan att ställa dig själv är vad som definitivt krävs dag 1, och begränsa dina alternativ till en delmängd eftersom standardsvaret utan är alltid, alltid, allt.

Så nu när vi tittar på vad vi ska tänka på för att göra ett projektgenomförande framgångsrikt måste vi inse att det finns fler saker som är relevanta innan vi börjar, som måste inkluderas. Dessa kommer också att påverka beslutet om vilken programvara som ska väljas i den första
plats. Allt som glimmar är inte guld. Se till att det du väljer är lämpligt för alla överväganden och inte bara för ett enskilt förväntat slutresultat.