<img src="https://secure.leadforensics.com/133892.png" alt="" style="display:none;">

Trenden i affärssystemsvärlden har under många år varit att anpassa affärssystem efter verksamhetens behov istället för att anpassa verksamheten till affärssystemets affärslogik. Vi tror på att i största möjliga mån hålla sig till en standardlösning. Här berättar jag varför.

Anpassa eller anpassas?

Affärssystem är mer eller mindre lätta att skräddarsy. Att skräddarsy för sitt företags behov kan ge effektiva, strömlinjeformade processer och ett användarvänligt gränssnitt. Men hur går det när man uppgraderar nästa gång? Vad händer med buggfixar från produktleverantören? Eller när ny funktionalitet och uppgraderingar introduceras?

Baksidan av myntet är den höga kostnaden för uppdateringar och uppgraderingar, risken för fel i anpassad kod och krock med affärslogiken i systemet. Genom att mjukvaruleverantörerna gör allt snabbare releaser av nya versioner och uppgraderingar av kärnfunktionalitet har det blivit svårare och svårare att hålla jämna steg.

Det gamla systemet är aldrig så bra som när det ska bytas ut och ett vanligt fel är att man till varje pris vill ha all funktionalitet på samma sätt som i det nya. Vår roll som leverantör är att begränsa och visa nya möjligheter med ett modernt system. En rapport som visar utgångna offerter kanske är helt onödig om säljaren får en signal från Outlook istället.

Bekanta dig med systemets styrkor och svagheter

Ett affärssystems livscykel innehåller mer och mer standardfunktionalitet. Barnsjukdomar rensas ut och stödfunktioner runt produkten blir bättre och bättre. Därför behöver vi inte längre i samma utsträckning bygga egna, skräddarsydda lösningar för att systemen ska fungera som vi vill. När är det läge att göra en anpassning av systemet? Är det bättre att försöka ändra en arbetsprocess? Det är allt viktigare att vi som leverantörer känner till systemets styrkor och svagheter för att kunna ge bra råd.

Ställ dig frågan: behövs det verkligen en anpassning?

Målet måste vara att ha ett minimum av anpassningar, att företaget är förberett att köra processerna så standardmässigt som möjligt, och eventuellt skräddarsy dessa senare om det visar sig vara opraktiskt eller besvärligt.

För att ta ett exempel var vi involverade i ett projekt med en kund som hade över 300 större och mindre anpassningar. Skalan var så stor att en uppgradering var helt uteslutet. Det blev därför ett implementeringsprojekt med fokus på att standardisera affärsprocesser. Efter noggrann analys i workshops, som omfattade både ledning och användare av systemet, resulterade det i en lösningsbeskrivning och gap-analys med 30 anpassningar totalt.

Sammanfattning: 6 sätt att undvika kostsamma anpassningar

  • Välj en leverantör med djup process- och produktkunskap som kan avgöra när en anpassning är på sin plats
  • Fastställ tydliga processägare med beslutsmandat för de ändringar som ska göras i de nuvarande affärsprocesserna och i organisationen
  • Börja med att fråga "varför?". Finns det inte ett väldigt konkret svar på den frågan så finns det heller ingen anledning att göra en anpassning
  • Förankra alla anpassningar ur ett kostnads- och intäktsperspektiv
  • Glöm inte bort att fokusera på användarna och sätt behörigheter och menyer som är inställda för deras roll så att de får rätt information
  • Sist men inte minst: Om du är osäker – börja med standard och lyft blicken innan en eventuell anpassning så att helheten i lösningen alltid går före enskilda funktioner

Diskutera detta inlägg

Rekommenderad läsning

I förra blogg-inlägget introducerades konceptet Data Entities. Här fortsätter beskrivningen av komposita entiteter och verktyget Data Management.
För att utveckla integrationer för tidigare versioner av AX krävdes god kunskap om tabellstrukturen och databasmodellen i AX. Bara att uppdatera t.ex. en kundpost var en stor utmaning och eftersom databasen i AX är väldigt normaliserad blev varje integration ofta onödigt jobbig att implementera. Förutom denna problematik hade man dessutom flera olika sätt att integrera på; Application Integration Framework (AIF),  Data Import- and Export Framework (DIXF) samt ren tabellimport/export vilket ständigt skapade diskussioner om vilken metod som var bäst för varje scenario.
Under Tech Conference i Mars 2017 presenterade Microsoft att Dynamics 365 for Operations kommer finnas tillgänglig i tre olika driftsalternativ; Public Cloud (släppt), Cloud+Edge (släpps dec 2017) samt Local Business Data (släppt).
90 % av dagens problem med Office-integration med AX handlar om autentisering, dvs åtkomst av data i AX begränsas av strul med behörigheter och Office-plugin. Detta har Microsoft tagit fasta på i 365 for Operations och en del av att förbättra användarupplevelsen handlar om att man öppnat upp möjligheten till att använda protokollet Open authentication (Oauth). Detta gör att andelen problem med autentisering ska minska och att användarupplevelsen ska bli bättre. Man har också ersatt AX-plugin:et i Excel med en mer dynamisk Dynamics 365 Data Connector. Denna fungerar både i lokal Excel, Excel Online samt även i Excel på iPad.
Hjälpfunktionaliteten har utvecklats stort i Dynamics 365 for Operations jämfört med tidigare releaser och här finns en del riktigt spännande nyheter. Hjälpen nås via frågetecknet i navigation bar och den första nyheten man ser är att det finns två sektioner i hjälpavsnittet; en som kallas Uppgiftsguider (Task guides) och en som kallas Wiki.
right-arrow share search phone phone-filled menu filter envelope envelope-filled close checkmark caret-down arrow-up arrow-right arrow-left arrow-down