Hur man samarbetar: Bygga en sann allians mellan funktionella och tekniska konsulter

(Del 2 av 5 i serien “Den mänskliga koden för ERP”)

Låt oss vara ärliga. Om du har arbetat med implementering av företagsprogramvara har du förmodligen märkt att det ofta råder dåligt samförstånd mellan funktionella och tekniska konsulter.

Mellan dem ligger en klyfta av missförstånd, passiv-aggressiva mejl och försenade projekttidslinjer.

Den enkla integrationsincidenten

Jag har sett projekt stanna av i veckor helt enkelt för att två yrkesverksamma talat helt olika språk.

Föreställ dig ett typiskt anpassningsmöte. Funktionskonsulten, direkt från en workshop med kunden, lutar sig fram och säger: Kunden behöver synkronisera tillverkningsprogramvaran med ERP-systemet. Det är väldigt enkelt. Vi behöver bara bygga en enkel integration med deras nuvarande MES för att skicka data över.

Problemet är att funktionskonsulten säljer lösningen som "enkel", främst för att det inte är de som faktiskt behöver skriva koden. De ger väldigt få detaljer och tar det tekniska utförandet lättvindigt, och underskattar fullständigt de tunga tekniska konsekvenserna.

För konsulten är en integration bara en konceptuell brygga. För utvecklaren representerar samma "enkla integration" en mardröm av nyttolaststrukturer, timeout-fel, säkerhetstokens och saknade datavalideringar.

När utvecklaren oundvikligen påpekar dessa komplexiteter uppstår onödiga friktioner. Funktionskonsulten anser att utvecklaren i onödan komplicerar ett affärskrav. Utvecklaren anser att funktionskonsulten trivialiserar sitt hårda arbete och ger omöjliga löften till klienten.

Sanningen är att som funktionell konsult finns det svårigheter i jobbet som utvecklaren inte kan förstå, och vice versa. Utvecklaren behöver inte möta de irrationella kraven från en panikslagen klient, och funktionell konsult behöver inte navigera i den oförlåtande logiken i systemarkitekturen. Inget yrke är mindre viktigt eller enklare än det andra. De står bara inför unika utmaningar som den andra sidan sällan ser.

Den verkliga fienden i det här rummet är egot och bristen på ömsesidig förståelse.

Välkommen till den andra delen av ERP:s mänskliga kod. Idag river vi ner silos mellan de människor som utformar affärsprocesserna och de människor som faktiskt måste bygga dem.

Vi pratar om hur man skapar en skottsäker allians mellan funktionella och tekniska team.

Två världar, två språk

För att lösa denna konflikt måste vi först förstå grundorsaken. Funktionella och tekniska konsulter lever i två helt olika verkligheter.

Funktionskonsulten lever i den röriga, oförutsägbara världen av mänsklig affärsverksamhet. De går på fabriksgolvet. De ser operatörernas fysiska svett. De hanterar finanschefens ångest och de kaotiska, ologiska sätt som människor faktiskt utför sina dagliga uppgifter på. Deras mål är att få verksamheten att flyta smidigt.

Den tekniska konsulten lever i en värld av absolut, binär logik. En databastabell bryr sig inte om lagerchefen har en stressig dag. En systemarkitektur kräver rigida regler, exakta definitioner och noll tvetydighet. Deras mål är att göra systemet stabilt, säkert och prestandaeffektivt.

När dessa två världar kolliderar utan en översättare inträffar katastrofen. Det slutar med en systemintegration som är tekniskt felfri men helt värdelös för människorna i verkstaden eftersom den inte tar hänsyn till de fysiska förseningarna med en gaffeltruck som flyttar pallar.

Den tekniska konsultens myt

Det finns en vanlig missuppfattning att en funktionell konsult behöver lära sig att skriva kod för att överbrygga denna klyfta. Detta är helt felaktigt. En bra funktionell ERP-konsult behöver inte veta hur man programmerar ett skript eller skriver komplexa SQL-frågor.

De måste dock absolut veta hur ett system tänker.

Du behöver inte veta hur man skriver API-nyttolasten. Men du måste förstå att när ett system skickar ett meddelande förväntar det sig ett specifikt svar, och du måste utforma en affärsprocess för vad som händer om svaret aldrig anländer. Du måste förstå skillnaden mellan en masterdatatabell och en transaktionstabell. Du måste förstå de grundläggande lagarna för systemarkitektur.

Ditt verkliga jobb som funktionell konsult är att vara den ultimata mänskliga översättaren. Du är bryggan, inte en programmerare. Du måste ta de kaotiska, känslomässiga behoven i verksamheten och översätta dem till rena, logiska ramverk som en utvecklare faktiskt kan arbeta med.

Skydda skyttegravarna

Den värsta typen av funktionell konsult är den blinde utföraren. Det är konsulten som inte bryr sig om det faktiska affärsbehovet. De utför order som en liten soldat, lyssnar på en ologisk eller helt ogenomförbar anpassningsförfrågan från klienten, skriver ner den exakt som den uttalas och lämnar den direkt till det tekniska teamet utan att ifrågasätta om det ens är meningsfullt.

Modern CloudSuite-arkitektur hindrar dig från att bokstavligen förstöra databasen, men användare kommer fortfarande att be om modifieringar som helt bryter mot standardsystemets logik. När utvecklaren oundvikligen påpekar att begäran är tekniskt absurd, rycker den här typen av konsult helt enkelt på axlarna och säger: "Skyll inte på mig. Det är vad klienten vill ha."

Detta beteende förstör förtroendet med tiden. Det leder till att det tekniska teamet blir dåligt.

En sann konsult fungerar som en sköld. Det är ditt jobb att avgöra om en förfrågan är helt ogenomförbar innan du skickar den till IT-avdelningen. Du måste tillämpa de "fem varför" som vi diskuterade i del 1 och avslöja det verkliga affärsbehovet.

Dessutom, om utvecklaren kämpar med att genomföra ett krav, pekar du inte bara på specifikationsdokumentet och kräver resultat. Du samarbetar med dem. Ni undersöker tillsammans för att förstå om den tekniska begränsningen är objektiv. Om det är ett objektivt vägspärr måste du agera som en bro och gå tillbaka till klienten för att förhandla fram en medelväg.

Kunder älskar att använda den klassiska frasen ”Inom IT är allt möjligt”. Du måste skydda ditt tekniska team från detta tankesätt eftersom det inte är så den verkliga världen fungerar. Vi skriver inte om kärnprocesser från grunden. Vi utökar standardfunktioner.

När utvecklare inser att du står vid grindarna, filtrerar bort skräpet och skyddar dem från omöjliga löften, kommer de att respektera dig. De kommer att sluta motarbeta dina önskemål och börja samarbeta kring dina lösningar.

Tar värmen

Funktionskonsulter klagar ofta på en väldigt specifik dynamik. När ett anpassat skript misslyckas eller ett system kraschar sitter den tekniska konsulten säkert bakom en skärm. Samtidigt måste den funktionella konsulten sitta i ett mötesrum, se en arg klient i ögonen och förklara varför den nyligen implementerade anpassningen inte fungerar som förväntat. Det känns otroligt orättvist att ta på sig skulden för ett tekniskt fel man inte skrev.

Men oavsett om du gillar det eller inte, är det just ditt jobb att vara gränssnittet mellan det tekniska teamet och klienten. Du är bryggan. Att klaga på att möta klienten är som en sköld som klagar på att bli slagen.

Hemligheten bakom ett välmående projekt är ömsesidigt försvar. En stark allians innebär att ni täcker upp för varandra. Den funktionella konsulten absorberar chocken, tar emot trycket och hanterar kundens frustration för att köpa värdefull tid. Denna dynamik fungerar bara om utvecklaren står bakom dem.

I ett genuint partnerskap är utvecklaren redan informerad i samma ögonblick som konsulten kliver in i det där fientliga mötesrummet och arbetar i bakgrunden för att leverera en lösning. Du skyddar utvecklaren från klientens panik, och utvecklaren försvarar din trovärdighet genom att åtgärda buggen snabbt.

Alliansens spelbok

Hur förvandlar du en fientlig IT-avdelning till din största allierade? Här är tre praktiska regler att tillämpa i ditt nästa projekt för att bygga ett verkligt partnerskap.

1. Skriv binära specifikationer, inte romaner

Utvecklare hatar tvetydighet mer än något annat i världen. Skriv aldrig en funktionell specifikation som säger: "Systemet ska automatiskt uppdatera statusen och meddela användaren." Det är en nyhet, inte en specifikation. Skriv istället i binär logik. Ange exakt vilken trigger som utlöser händelsen. Definiera exakt vilket tabellfält som behöver ändras från Status A till Status B.

Förtydliga exakt vad meddelandet ska säga och vem den exakta mottagaren är. Ta bort adjektiv och ersätt dem med precisa villkor. Om din specifikation lämnar utrymme för personlig tolkning är det en dålig specifikation. Även de minsta detaljerna måste skrivas ner i en formell analys och delas. Ett kort samtal om samordning för att först granska dessa detaljer kan göra en enorm skillnad för att etablera ett gemensamt språk.

2. Förklara alltid "Varför" i analysen

När du skriver din funktionella specifikation måste du tydligt förklara de affärsmässiga motiven bakom begäran. Behandla inte utvecklaren som enbart en kodexekutör. Precis som funktionella konsulter behöver utvecklare hela kontexten för kravet. De behöver förstå vad de arbetar med, men viktigast av allt, varförde gör det. Ge dem inte bara en teknisk instruktion.

Förklara affärsproblemet. Säg att arbetarna på lagret skriver in det här numret manuellt 500 gånger om dagen, och det orsakar leveransförseningar. Vi behöver automatisera det här fältet för att spara dem två timmar per skift. När en utvecklare förstår sammanhanget och den mänskliga påverkan av sin kod, förvandlas de från en ordermottagare till en aktiv partner som kan föreslå en mycket bättre teknisk lösning än du ursprungligen föreställde dig.

3. Gör dem till en del av resan

I de flesta projekt är det den funktionella konsulten som reser till kunden och sitter i de viktiga mötena. Denna dynamik lämnar ofta utvecklaren isolerad på kontoret. Om du verkligen vill arbeta som ett team måste du göra det ordentligt. Du kan inte bara pinga dina tekniska kollegor bara när du har en specifik kodningsuppgift att tilldela utan att någonsin ge den bredare kontexten.

Du måste få dem att känna sig som en integrerad del av projektet som helhet. Ta chansen att prata med dem regelbundet och häng med i deras kunskaper om den senaste utvecklingen hos kunder, projektförändringar och den övergripande atmosfären. Genom att skapa detta kontinuerliga sammanhang säkerställer du att de är djupt involverade. När utvecklare förstår helheten och känner sig inkluderade i resan, slutar de att vara bara utförare och blir verkliga projektpartners. Ett projekt där en funktionell konsult och en utvecklare arbetar tillsammans kommer utan tvekan att ge utmärkta resultat för både projektet och deras dagliga arbete.

Alliansen i skyttegravarna

Att bygga en anpassad tilläggstjänst eller integrera en extern programvara i ett ERP-system handlar aldrig bara om att skriva kodrader. Det är en övning i mänsklig kommunikation.

Världens bästa tekniska arkitektur kommer att kollapsa om de som definierar processen och de som skriver logiken vägrar att förstå varandra. Genom att släppa våra egon, lära oss att tala tydligt och skydda varandras tid kan vi stoppa det eviga kriget och börja bygga programvara som faktiskt gör skillnad.

En framgångsrik Go-Live-lösning är starkt beroende av den obrytbara alliansen mellan en funktionell och en teknisk konsult. Ingen av dem kan lyckas genom att arbeta ensam.

Nästa steg: Hur man odlar den mest underskattade färdigheten inom konsultbranschen. Vi kommer att utforska nyfikenhetens kraft över encyklopediskt minne.

Skriven av Andrea Guaccio 

7 maj 2026