3 Litteraturöversikt
5.3 Förändrade processer och logik
I empirin beskriver respondenterna att deras jobb handlar om att göra lösningar utefter kundernas önskemål och förutsättningar och att som Konsult 2 uttrycker det, möjliggöra processer precis så som kunden vill ha det. I empirin framstår alltså en bild av att kunder vill ha specialanpassade processer, något som också påträffas i tidigare studier. Hustad et al.:s (2016) studie visar att den vanligaste orsaken till att förändringar görs är för att kunder vill ha andra processer än vad som erbjuds i affärssystemet. Kunder vill behålla exakt de processer som de redan har. Den eventuella negativa effekt av att behålla existerande och då även ibland ineffektiva processer som lyfts av Shang och Seddons (2007), är inte något som beskrivs av respondenterna utan det finns snarare en stark övertygelse bland respondenterna om att det behövs göra anpassningar utefter den unika verksamheten.
Viljan av att behålla verksamhetens existerande processer som beskrivs i empirin styrker också det som Al-Mashari och Al-Mosheleh (2015) beskriver med att det är svårt att få ledningen i en verksamhet att vilja anamma affärssystemets standardprocesser. En low-code BPM-plattform kan således ses som en möjliggörare för verksamheter att fortsätta jobba på “sitt sätt”.
I empirin framkommer det flera exempel på hur en low-code BPM-plattform kan användas för att förändra processer och logik. Konsult 2s beskrivning av hur plattformen används för att bygga upp logiken för hur arbetsordrar ska hanteras är ett exempel där logiken i affärssystemets frångåtts. Denna lösning bestod av ett 50-tal applikationer, men till skillnad från vad Uppström et al. (2015) föreslår som “paket av anpassningar”, så är fallföretagets lösningar specialutvecklade för den enskilda kunden och inte generiskt utvecklade för en viss typ av bransch eller verksamhetsområde. Konsult 2 uttrycker det som att:
“Det finns ingenting i grunden utan vi börjar med, “hur vill ni att det ska funka?”
- Konsult 2
Flera av respondenterna uppger att konfigurering av affärssystemet ofta är en del av de lösningar som de levererar till kund, Project Office Director nämner tillägg av fält och event som sådana typer av justeringar. Att däremot göra anpassningar i affärssystemet, det vill säga förändring i kod, är något som Lösningsarkitekten avråder ifrån och som Konsult 2 menar att inga kunder heller vill göra. Detta synsätt stämmer överens med den avrådan om anpassade affärssystem som uppkommit i den vetenskapliga litteraturen (Al-Mashari & Al-Mosheleh, 2015; Shang & Seddon, 2007). Konsult 2 uppger att det i dag inte är alls lika vanligt med anpassningar i själva affärssystemet i och med fler möjligheter genom konfigureringar. Detta bekräftar Uppström et al.:s (2015) bild av att anpassning genom att programmera ändringar i affärssystemet är en inaktuell anpassningstyp. Detta visar också på att leverantörer av affärssystem förändrat sina produkter till att bli mer flexibla och tillåtande vad gäller verksamhetsspecifika anpassningar och tillägg.
Från empirin blir det tydligt att det inom fallföretaget finns en stark övertygelse om behovet för verksamheter att ha specialanpassade processer utefter just deras förutsättningar. Respondenter beskriver hur plattformen kan specialanpassas och ritas om så att det passar precis så som slutanvändaren arbetar. Konsult 1 hävdar att “99 procent av alla företag i världen skulle ha nytta av plattformen”, och Konsult 2s påstående om att plattformen behövs för att få till de exakta lösningarna som kunderna eftersträvar, är avslöjande om den övertygelsen att verksamheter eftersträvar skräddarsydda system. Att synen på behov av anpassning skiljer sig åt jämfört med exempelvis Al-Mashari och Al-Mosheles (2015) studie har troligen till stor del sin grund i att den produkt och de tjänster fallföretaget erbjuder handlar om just verksamhetsspecifika anpassningar. Al-Mashari och Al-Mosheleh (2015) hämtar istället del av sin empiri från en stor affärssystemsleverantör, där ståndpunkten att inte anpassa kan tänkas mer naturlig.
Zach och Munkvold (2012) menar att behovet av anpassningar kan påverkas av hur mycket funktionalitet som affärssystemet erbjuder som standard. Huruvida IFS Applications, vilket är det affärssystem som de allra flesta kunderna till fallföretaget har, är ett “enklare” system jämfört med andra affärssystem är okänt. Men det är en faktor som skulle kunna ha en påverkan på det upplevda anpassningsbehovet bland respondenterna.
Att de inbyggda processerna i affärssystemet inte alltid är “best practice” för den enskilda verksamheten (Hustad et al., 2016) och att affärssystems generiska stuk i hopp om att tillgodose en bredd av verksamheter kan skapa ökad komplexitet och ineffektivitet (Shang & Seddon, 2007) är något som bekräftas i empirin. Project Office Director beskriver det som att de genom low-code BPM-plattformen kan optimera affärskritiska processer genom att göra anpassningar på en detaljerad nivå. Respondenter beskriver också att kunder vill undvika
onödiga steg i processer och minska affärssystemets komplexitet. Low-code BPM-plattformen kan på detta sätt ses som ett verktyg för att förenkla affärssystemets processer i hur de presenteras för användarna av systemet. Genom att plocka ut processer till ett separat lager möjliggörs att endast den logik och funktionalitet som verksamheten är i behov av nyttjas. Utifrån “best practice” som de stora och inflytelserika affärssystemskunderna varit med och format (Hustad et al., 2016) finns således möjlighet för den ökade gruppen av små och medelstora verksamheter som använder affärssystem (Uppström et al., 2015), att skala ner systemets komplexitet. Beskrivningarna från empirin om att förändra, optimera och effektivisera processer visar också på att plattformen agerar hjälpmedel för att omforma processer, det vill säga BPR, vilket är tätt förknippat med implementering och användning av affärssystem (Basoglu et al., 2007). Basoglu et al.:s (2007) syn på BPR är dock att förändra verksamheten så att den följer affärssystemet, vilket skiljer sig från det sätt plattformen används för att optimera processer som på grund av affärssystemets logik inte anses tillräckligt effektiva.