Buzzword-bingo med Navision

Estimeret læsetid: 32 minutter

Buzzword-bingo, også kendt som bullshit-bingo, betyder, at man bruger meningsløse eller endda ukorrekte tomme sætninger i reklamesnak for at foregive manglende ekspertise.
I løbet af de sidste fire årtier har jeg set så mange hypes komme, oplevet dem og set dem gå igen. Og da jeg har tjent mine penge med Navision siden 1993, har især „at se det gå“ altid været forbundet med et grinende snarere end et grædende øje. Så nu er det tid til at se på noget af hypen omkring „min“ Navision/Business Central 365 Dynamics. Vigtigt: Der er helt sikkert brugbare applikationer til ethvert buzzword. Jeg henviser her kun til den kommercielle verden, specifikt Dynamics Business Central eller Navision.

Agil udvikling

Agil udvikling har altid været standard i Navision & Business Central, i hvert fald i versionerne fra 1993 til og med 2019 Spring Release! Længe før dette begreb eksisterede, var det helt normalt for Navision-udviklere at gå direkte til medarbejderens arbejdsstation, se på problemet på skærmen og derefter hurtigt ændre en linje i programmet. Og takket være Navision-strukturen blev programændringen leveret på få sekunder. Enhver, der aldrig har programmeret i Navision (jeg udelukker bevidst Business Central og BC 365 Dynamics her), har aldrig virkelig cool agil udvikling. Med BC365 og AL har Microsoft „heldigvis“ sat en stopper for dette, selv om Business Central stadig er et af de mest elegante udviklingsmiljøer til hurtig prototyping i verden i dag.

DevOps

En DevOps Engineer overvåger og kontrollerer hele IT-infrastrukturen. De analyserer og vedligeholder servere, netværk og databaser og sikrer, at alle systemer kører korrekt, og at applikationerne kører problemfrit.
Og derudover:
Udfør regelmæssige softwaretests
Overvåg systemets ydeevne
Reagerer på fejl og problemer.
automatisere processer for at øge virksomhedens effektivitet.
En DevOp skriver f.eks. scripts til automatisk opsætning af værktøjer eller udførelse af tests, tager sig af kontinuerlig integration/kontinuerlig udrulning og automatiserer servervedligeholdelse.

Det koster næppe en inkarneret Navision Financials Attain/Microsoft Business Central 365-udvikler mere end et medlidende grin, for det beskriver vores liv, selv uden at vi nogensinde har haft „DevOps“ som et begreb i vores jobbeskrivelse 🙂 .

Kontinuerlig levering

Som med agil udvikling: sekunder efter at en programændring var foretaget, blev den også leveret til brugeren af systemet. Hvor en klient tidligere skulle genstartes, hvis det var nødvendigt, lykkedes det faktisk RTC at få ændringen til at træde i kraft med det samme. Alle C#/Java/SAP/Pearl-udviklere drømmer om dette ... og er ikke engang klar over, hvor gennemtænkt dette „helt mærkelige udviklingsmiljø“ er.

OOP - Objektorienteret programmering

Data og databehandlingslogik udgør en enhed? I 1993 hed det stadig „dbCallfieldcode“, i 1996 blev det ændret til Record.Validate(Field). Objektorienteret programmering på en ren, forståelig og overskuelig måde, helt uden nedarvning, overloading og parameterkonflikter. Typekompatibilitet blev allerede testet, når man gemte, og i mange tilfælde løst af systemet, hvor det var muligt. Ellers var der en forståelig almindelig tekstbesked, ingen undtagelse. Indtil i dag.

Database i hukommelsen (Hana)

Efter mere end 25 års udvikling på de forskellige hardwaremodeller (harddiske, SSD) & Navision-versioner (3.5x, Financials, Dynamics NAV, Business Central) & serverversioner (native, SQL) i denne tid: Hvis hardwaren er for svag, er udvikleren for dårlig. Den oprindelige server kunne nemt håndtere 100-120 aktive brugere med 1 kerne (det er alt, hvad den kunne bruge) og 1 Gb Ram og 10 harddiske (eller en SSD). Men i al den tid har jeg ikke fundet en udvikler, der forstod, hvorfor transaktionstallene skaleres med antallet af harddiske. Eller som overhovedet vidste, hvad transaktionsnumre er ...
Under SQL bør 2 SQL-kerner pr. 50 medarbejdere + 100 Mb pr. medarbejder på et rent system være tilstrækkeligt til et databasesystem, der altid reagerer med høj ydeevne. Her skal man selvfølgelig også holde øje med transaktionstallene, men siden SSD'erne er kommet til, er det ikke længere et spørgsmål selv for mindre bemidlede hardwareinstallatører. Jeg ser dog stadig ofte, at folk placerer en SQL-database og en SQL-transaktionslog sammen på det samme lagermedie (den samme harddisk). Nogle gange gennem bagdøren til et Raid 5-undersystem. Eller SQL-filer på en memory pool. Så ved du det med det samme: Du svømmede mod låsen og overtog derefter konfigurationen, mens du stadig var lidt våd og havde hovedpine. Under SQL blev den nye udfordring føjet til vide, hvordan nøgler og flowfields fungerer. Og hvordan SQL-serveren håndterer forespørgsler (nøgleord „Resultatsæt„), men det er der næsten ingen udviklere, der ved den dag i dag. Hukommelsesdatabaser er et middel, hvis udviklerne ikke er i stand til at håndtere deres datastrukturer eller kun bruger Cronos-klienten til at teste 🙂.

DevOps

Navision installeres én gang, uanset om man bruger DOS-versionen fra 1993, den Windows-native version fra 1996 eller RTC-versionen fra 2012. Dette markerer afslutningen på Ops-siden af DevOps, da en operatør praktisk talt ikke har nogen yderligere rolle i den stabile drift af Navision fra dette tidspunkt. Ofte udføres installationen af SQL-serveren og Navision-tjenesten også direkte af udvikleren. For han/hun ved bedst (bør vide...), hvordan en SQL-server til Navision skal fungere. Udviklingen (Dev) af Navision foregår derefter direkte i Navisions udviklingsmiljø eller, siden Extensions V2 (Business Central 2018), via Visual Studio Code. Også her har operatøren, dvs. „maskinisten“ i IT-teamet, ikke mere at gøre. Sådan har det altid været.

Rammeværk

Selvfølgelig er Navision i sig selv et framework, selv om det bruger andre frameworks, f.eks. .Net, MFC. Men det meste af tiden har en Navision- eller Business Central-udvikler ingen kontakt med dem: Han koncentrerer sig om datamodeller (tabeller), deres forhold til hinanden (relationer) og om forretningslogikken (C/Side, C/AL, AL, alt sammen på en eller anden måde det samme). AngularJS, Drupal, Ruby, JavaScript, VCL, applikationsframeworks, domæneframeworks, klasseframeworks, komponentframeworks? Ja, alt dette er også Navision på en eller anden måde. Kun: Programmøren/udvikleren er ikke interesseret i noget af dette. Desværre driver Microsoft nu selv en ny gris gennem Business Central 365-landsbyerne med et par måneders mellemrum. Heldigvis ikke gennem Navision-landsbyerne, så jeg sidder stadig fast i denne version.
Og dermed kopieres den konstante travlhed fra den „virkelige verden“ derude ind i Business Central 365 Dynamics-verdenen. Men hvis man læner sig tilbage og slapper af som navigationsudvikler, så er det hele i sidste ende på en eller anden måde det samme igen, selv AL med VS Code. Og det er sådan, den nødvendige ro til gode løsninger opstår igen.
Navision og Business Central „framework“ er først og fremmest kendetegnet ved udviklingsmiljøet, som kan beskrives som genialt, og som holder alle de sædvanlige faldgruber i andre programmeringssprog (race-time conditions, garbage collection, managed code, transaction & commitment...) væk fra udvikleren. Siden RTC har Microsoft gjort sig store anstrengelser for at genindføre forskellige problemer fra dengang (pludselige systemnedlukninger, forfærdelig strenghåndtering, sort-on-demand ...) i den tidligere så lykkelige Navision-verden. Men hvis man kender faldgruberne, kan man for det første hurtigt genkende dem og for det andet hurtigt undgå dem.

Lav kode

Skriver du lidt kode for at udvikle en applikation? Navision opfandt det. Tilbage i det forrige årtusinde! Til hurtig prototyping, herunder mockups og dokumentskærme, kunne fuldt fungerende applikationer, herunder rapportering, sortering, søgning og filtrering, oprettes uden en eneste linje kode indtil 2009R2 (uden RTC). Det er desværre ikke længere muligt i dag. Men selv med AL er det stadig hurtigere end i noget andet mere eller mindre opdateret udviklingsmiljø.

Sky

AWS, Azure, privat sky ... „Der er ingen sky. Der er kun computere, som tilhører en anden“. Og dem betaler man for. Fordi computerejeren også ønsker at blive betalt for sine computere. Så enkelt fungerer denne forretning. Med den forskel, at du nu har et flere hundrede kilometer langt kabel mellem din skærm og denne tredjeparts computer. Og at du ikke ved, hvor dette kabel ender, dvs. hvor dine data er. Og du ved heller ikke, hvem der sidder i den anden ende af kablet, og at det nogle gange kan blive afbrudt. Og computeren kan også blive slukket. Er det ikke rigtigt? Hvor er de Windows-telefoner? Hvad skete der med den tyske Microsoft Cloud? Hvad bliver der af Google Cloud Print?, google wave, Google+? Hvad blev der af alle de Blackberry-tjenester? Hvad med Irista fra Canon? Hvad skete der med Lima? Hvordan gemmer du dine data i dag fra Robin smartphone?
Selv med cloud-tjenester, der stadig kører, opstår spørgsmålet, især i Tyskland: Er min båndbredde overhovedet tilstrækkelig til at drive tjenesten i min virksomhed? Hvad nu, hvis jeg flytter min virksomhed fra Berlins centrum til Brandenburg? Jeg kan tage min egen server med mig, men ikke en fiberoptisk forbindelse.
De homøopatiske installationer til en Business Central i Azure-skyen taler for sig selv. De yderligere begrænsninger, som denne beslutning medfører, er ikke engang taget i betragtning. Efter min mening bør man ikke lægge noget i „skyen“, som man ikke kan undvære i mindst én dag. Og spare omkostninger? Som sagt: Det er en server, der tilhører en anden. Og den anden person stiller ikke denne server til rådighed, fordi han er sådan en stor filantrop. Men selvfølgelig findes der, især for software, udlejningsmodeller, som bevidst er beregnet på en sådan måde, at det månedlige gebyr gøres spiseligt for kunden i stedet for købet.

Edge Computing

Som det allerede er tilfældet med cloud computing: Ikke alle båndbredder, der er tilgængelige på stedet, opfylder kravene. Hvad er løsningen? Edge computing! I det enkleste tilfælde, som kommer tættest på definitionen, flytter den nødvendige computerservice fra dit eget sikrede serverrum til det firkantede, nøglesikrede plastikskab i krydset ... edge computing ... computing i hjørnet (eller grænsefladen) mellem dit eget netværk og et eksternt datacenter.

Mikro-services

Lille service. Uafhængig, nem at vedligeholde, nem at skalere. Meget praktisk til at tjekke en valutakurs på internettet. Men hvad nu, hvis en transaktion, f.eks. en valutaoverførsel, skal udføres samtidig med den ønskede valutakurs? Så bliver de mindst to eller flere nødvendige mikrotjenester hurtigt til en makrotjeneste ... En makrotjeneste, der ikke kan handles med. Det er ikke for ingenting, at flyplaner og bookinger, elektricitetsleverancer og pensionsforsikringer stadig i vid udstrækning kortlægges på mainframes. Fordi en transaktion med garanti bliver afsluttet og bekræftet som en helhed. En ERP med tusindvis af mikroservices? Konsekvent prissætning sammen med en ordre, der garanteret kan behandles fuldt ud under hensyntagen til en kreditgrænse? I Navision kan du starte en transaktion og bogføre lagre, saldi, omkostningsregnskaber, produktionsordrer og salg på én gang. Og hvis transaktionen annulleres, er alle data konsekvent tilgængelige i deres oprindelige tilstand. Det er simpelthen umuligt med mikrotjenester. Der er helt sikkert fornuftige anvendelser for disse. Men ikke i ERP-verdenen.

NoSQL

Det er selvfølgelig også rart at gemme helt ustrukturerede data i en slags database. Det kaldte man tidligere et filsystem eller Lotus Notes. På den måde er det bare gammel vin på nye flasker. Men hvad gør man med de ustrukturerede data? Man opretter metadata, attributter ... klassiske SQL-strukturer. Og salg, åbne poster, lagerbeholdninger og hovedkontosaldi har simpelthen ikke brug for No-SQL ... bare det: Ingen NoSql. I et kommercielt system er strukturerede data som dem, der findes i en dBase-, DB2-, Firebase-, Navision- eller SQL-database, det vigtigste. Du har ikke brug for mindre. Men heller ikke mere.

Store data

Buzzwordet i 2018-2019 - er der stadig nogen, der taler om det i dag? Der er mange oplysninger, som kun kan findes i en stor mængde data. Cyklusser for trafiklys baseret på trafikstrømme. Detektering af defekter gennem runtime eller temperaturdetektering. Spredningsmønstre for epidemier. Som med AI betyder „big data“ dog generelt, at nogen bare var for dovne til selv at genkende mønstrene. Jeg kunne også hente cyklusser for trafiklys direkte fra trafiklysets computere. Men hvis du foretrækker at bruge gratis mobiltelefoner i stedet for dyre ledninger til trafiklyscomputere, så er big data igen et fantastisk værktøj til downstream-mønstergenkendelse, hvilket bringer os til AI.
I dag er ny Big data igen trods alt Smarte dataIntelligent forberedte, kompakt indsamlede og nemme at behandle data. Og big data er kun nødvendig som træningsmateriale for den berømte AI. Derefter er data bare ballast.

AI Kunstig intelligens (&deep learning)

Kunstig intelligens? Den findes ikke. Fandtes det ikke i 60'erne, da Eliza var stadig en overskrift værd. Det var det heller ikke senere, ikke før i dag. Det, der i dag sælges til os som AI, er enten kunstigt ... i så fald er det ikke intelligent. Eller også er det intelligent, og så er det ikke kunstigt. Det er en automatiseret mønstergenkendelse ud fra masser af præ-indekserede data, igen big data. Forklædt som ChatGPT er det ikke kun en mønstergenkender, men også en mønstergenerator. Og jo bedre man forstår denne mønstergenkendelse, jo mere tankevækkende bliver det: Mhm ... ikke helt! I den tilsyneladende magiske billedgenkendelsesproces Tog genkendes ikke på låsen, men på skinnerne. Heste genkendes ikke på formen af deres hoveder, men på copyright-meddelelser.. Derfor udføres f.eks. ansigtsgenkendelse (ikke „ansigtsgenkendelse“) også ved hjælp af vektormatchning.

„Det bedste ved AI er, at overskrifterne om blockchain endelig vil forsvinde.“ og „En butik er dårligt organiseret, og de ansvarlige håber at bruge teknologi til at løse det organisatoriske problem.“, plus „Recall vil ikke være det sidste eksempel på, at AI kompenserer for problemer, som vi kunne løse bedre selv, hvis vi ikke var så dumme“. Vidunderlige citater fra denne artikel, der taler til mig fra hjertet.

Meget kompleks programmering. Men også effektiv, i modsætning til den ofte ret „præcis gættende AI“. I Navision, eller mere præcist Business Central, kan du gøre dette på en fantastisk måde ved at bruge Anerkende debitorers (kunders) betalingsadfærd. I næsten alle Navision-installationer, som jeg administrerede, var der kolonnen „Forfalden i dage“ i debitorfakturaposterne. Med en linje i programkoden under udligning af åbne poster blev der logget en forfaldsdato. Det gjorde det meget enkelt og meget præcist at afgøre, om en kunde var en pålidelig betaler, og hvor mange overtræk man generelt kunne forvente pr. kunde. Enkelt og præcist. I Business Central er der nu en AI-løsning, som med en masse besvær og en masse opsætning kan sende en åben post ud: „Kan være i overtræk“. Helt ærligt! Intet andet! I den kommercielle sektor, til lagre og saldi, til overførsler og påmindelser, har jeg simpelthen ikke brug for AI. Jeg har brug for gode regnskabskompetencer, gode salgs- og indkøbskompetencer og solide kompetencer inden for merchandise management. Men Navision behøver ikke at forhindre selvkørende biler i at kollidere med tog ...

Eksempler på mit udsagn: (Jeg vil uddybe dette fra tid til anden)
https://www.heise.de/hintergrund/Neuronale-Netze-Wie-sie-angegriffen-werden-und-wie-man-sie-verteidigt-6132752.html?wt_mc=nl.red.ho.ho-nl-daily.2021-07-10.link.link
Også et godt bidrag fra Mai Thai: https://www.zdf.de/show/mai-think-x-die-show/maithink-x-folge-04-100.html
Især ChatGPT er værd at nævne:
https://www.heise.de/news/ChatGPT-erfindet-Gerichtsurteile-US-Anwalt-faellt-darauf-herein-9068180.html?wt_mc=nl.red.ho.ho-nl-daily.2023-05-30.ansprache.ansprache

Og endnu et rigtig godt eksempel på ChatGPT i forbindelse med Navision: Spørg bare, hvordan man laver en databackup i Navision 2009 ... Her synes jeg, at forskellen mellem ChatGPT og Bing (Microsoft)-varianten er endnu mere bemærkelsesværdig:

Har du også en fornemmelse af, at produkter som ChatGPT lyder mere som „dårlig science fiction“? Du kan være sikker på, at alt, hvad du finder i mainstream-medierne om disse og mange andre AI'er, er netop det: dårlig science fiction. Her er en lille guide til at hjælpe med at rette op på den offentlige diskussion (mest af alt af lægfolk).

Blockchain

Blockchain skal gøre alting nemmere, billigere og mere sikkert. Medicinske rapporter, sporing af containere, opløsning af banker på få måneder, demokratisering af penge. Selvopfyldende kontrakter. En meget høj standard for en Decentraliseret, replikerende database - Med al respekt, det er alt, hvad blockchain er for nu.
Noget „lignende“ findes også på Navision-kontoret: Der kaldes det et kontoudtog, som synkroniserer betalinger og kontantindtægter. Og det har været tilfældet i mange år, på forespørgsel også automatisk.
Hvad er der tilbage af blockchain indtil videre? En meget god metode til at at drive ulovlig forretning eller Computerafpresning til at betale. Dumme mennesker med vanvittige løfter om meningsløse betalinger til at bevæge sig. I realøkonomien er dette mere en Gunstig mulighed for reklame. Nye overskrifter á la „Første gæst, der betalte med Bitcoin“ minder meget om den første jernbanerejse fra Nürnberg til Fürth. Bitcoin er stadig spændende, og blockchain vil finde sit marked. Men en markedsføringshype, der går ud på, at „alt skal ind i blockchain“, er lige så dum som et tankeløst „alt skal ind i skyen“.

GitHub

Et administrationssystem, hvor jeg kan gemme forskellige versioner af et program. Det plejede at hedde en teksteditor eller en sikkerhedskopi og er nu elegant gemt i skyen. OK, merging, branching og forking er nyt ... Og på en eller anden måde endnu mere komplet Overhead, hvis du alligevel kun skal ændre nogle få linjer. Du har originalen i den operationelle backup fra i går ... ikke sandt?

Serverløs computing

Som begreb er det et af de dummeste buzzwords, man kan finde på. Det, der menes, er, at man kan køre funktioner på en abstraheret platform uden at skulle bekymre sig om de nødvendige rammebetingelser (serverhardware, ydeevne, konfiguration, ofte også sikkerhed osv.) Selvfølgelig skal den „serverløse“ ramme, der stilles til rådighed, også være 100% egnet til opgaven. Det er bedre at tjekke dette på forhånd.
I Navision bruger jeg nogle gange dette buzzword som en joke for at sige, at Navision-miljøet (server, klient eller service) „simpelthen kan glemmes“, når det først er blevet sat korrekt op. Hvis du programmerer ordentligt, er det sandt. Jeg har haft kunder, som ikke vidste, hvor deres oprindelige Navision-databaseserver var, fordi ingen havde passet på den i årevis. Men bortset fra det gælder det samme igen: Der er ingen sky. Der er kun computere, som tilhører en anden.

Chatbots

En pest og en plage. Især fordi man ofte ikke kan se forskel på dårligt (=billigt) uddannede supportmedarbejdere og dårligt programmerede chatbots. Og alligevel var chatbots for omkring et årti siden DEN hype, som alle virksomheder havde brug for. Og i dag er de systemer, der var sjusket programmeret dengang, nogle gange stadig irriterende på hjemmesider, fordi nogen har glemt, at scriptet fra dengang stadig kører. Eve„, en lille animeret figur på Yellow-Strom, har opnået kultstatus. -Hvis du indtaster de rigtige termer. nøgen. Desværre blev den ikke „glemt“, men virkelig slukket på et tidspunkt. Hvor er det ærgerligt.
Men hvis du gør det rigtigt og rigtig godt, kan du spare en masse rutine. Eksempel: Amazons klagechatbot. Den stiller kun 2-3 spørgsmål uden at udgive sig for at være et menneske. Og så sender den simpelthen de indsamlede oplysninger (hvilken artikel fra hvilken ordre har hvilket problem?) videre til en ekspedient. Rationelt og funktionelt. En rollemodel!

Andet liv

Linden-Dollar ... er der nogen, der kan huske dette nye „must have“ fra 2003? Webshops, som lige er blevet lanceret for en masse penge, er ved at blive overflødige. Telefonopkald er ved at uddø. Al support og markedsføring skulle være til stede der ... Og i dag? Takket være browsere, Google og SEO-optimering foregår langt størstedelen af kommunikationen via tekst, ligesom i det 18. århundrede. De bliver faktisk stadig læst og ikke sendt direkte ind i hjernen via mikrochip-implantater... Desværre! Desværre? Og second life ... findes det stadig?

Teamwork

Ahhhh.... et af mine foretrukne buzzwords! Toll, ei amere machts - Team.

Fra 1993 til 1995 sad jeg alene på mit lille kontor og indførte Navision (dengang stadig den blå DOS-version) i en komplet industrivirksomhed. Salg, indkøb, simpelt regnskab. Lagerstyring og senere også produktion.
Alene. Med printerprogrammering, stregkodelæsere, indsamling af maskindata.

Derefter fra 1995 til 2005 i systemhuset. Projekterne blev større, men det egentlige problem var det større tidsforbrug, fordi projekterne også blev større. Så vi havde brug for intern support, når jeg var ude at rejse, plus nogen til at træne det hele, når jeg havde fået det op at køre, og så blev projekterne så store, at vi faktisk havde brug for flere programmører ... Og det var der, elendigheden begyndte. Der blev dannet et team.
og jeg spurgte mig selv fra den allerførste programmeringsmedarbejder, hvad der var så svært ved at omsætte kundeønsker til programkode med det bedste programmeringsmiljø nogensinde (ja, jeg mener Navision Financials og i dag Business Central 365!).

Sjovt nok fandt jeg først svaret på dette i en Heise-artikel i dag 🙂 Kollegerne havde allerede problemer med at lade Navision gøre arbejdet i stedet for, at vi programmører skrev os til blods.

Men det var ikke hovedproblemet, hvorfor ingen af programmørerne leverede ordentlige projekter.
Problemet var som regel, at udviklerne simpelthen ikke forstod problemet. Eller når et program var færdigt, men det opførte sig anderledes end planlagt, f.eks. i den positive test (gør det, hvad det skal?) eller i den negative test (gør det ikke noget, når det ikke skal?).

Det faktum, at den negative test normalt blev udeladt, fik også mit blodtryk til at stige mere end én gang...

Klik her for at læse den artikel, der taler til mig fra sjælen:

Den virkelige flaskehals: Hvorfor hurtigere kodning ikke fremskynder projekterne | heise online

En af mine yndlingssætninger i den:

Frederick P. Brooks„ berømte lov (“Hvis man tilføjer arbejdskraft til et sent softwareprojekt, bliver det senere") er ikke en teoretisk gimmick. Den beskriver, hvad der sker, når man tror, at software primært skabes af arbejdskraft.

Dette er lige så godt som „Hvis en kvinde har brug for 9 måneder til at få et barn, så tager vi 9 kvinder og føder efter en måned!„
Eller „En kok skal bruge 10 minutter på at koge 10 hårdkogte æg, hvor lang tid skal 2 kokke bruge på den samme opgave?„

Et team bliver ikke bedre, bare fordi der er flere mennesker i det. Som regel æder de ekstra aftaler fordelene op fra tredje person og frem, så de ekstra medarbejdere fremskynder ikke et projekt, men er, som med første person, vigtigere. Frederick P. Brooks men i sidste ende koster det mere tid, end du bidrager med til projektet.

Også en fin sætning fra hr. Brooks: Da man aldrig kan gøre det rigtigt første gang, bruger man faktisk ikke tid på det, fordi det er et tåbeligt ærinde. Jeg vil alligevel gøre det om!

Du kan finde mere baggrundsinformation om emnet herHemmeligheden bag succes er ikke at programmere løsningen, men at forstå problemet.

Vibe-kodning eller vibrerende kodning

Levende kodning bør ikke mangle på vinderpodiet af meningsløse sætninger.

Papirløst kontor

Endelig et tysk buzzword 🙂 Og næsten lige så gammelt som mig. Og lige så gammel som udtrykket „papirløst kontor“ er Selvmodsigende undersøgelse af papirforbrug mig selv. Men siden 2020 har jeg set de hvem-ved-hvor-mange lyspunkter i horisonten! „Takket være“ corona - og det hjemmekontor, der ofte er blevet nødvendigt som følge heraf (endnu et buzzword, men denne gang et rigtig godt et, efter min mening ...), forsøger mange virksomheder nu virkelig konsekvent at skifte i det mindste deres indgående og udgående fakturaer til elektroniske, papirløse dokumenter (PDF osv.). Og takket være lempeligere statslige regler gør de det med større og større succes. Hvis alle trækker på samme hammel ...
Jeg vil også gerne vise dig min version Papirløs behandling af indgående fakturaer.
Og alligevel ... Når jeg leder efter bogføringsfejl i finansregnskabet, varestyring eller aktivregnskab, laver jeg altid en papirudskrift af den tilsvarende konto først ...

SaaS - Software som en tjeneste

Programmer, som kan parametriseres maksimalt af brugeren, men som ellers ikke kan ændres for alvor, bruges helt uden lokal installation via internettet. Gmail, Microsoft Office 365, Adobe ... Fantastiske løsninger, meget nemme at bruge, tilgængelige på alle enheder. Nu også Business Central! Og reglen er: Brug det præcis, som vi har forestillet os ... selv om vi absolut ikke har nogen idé om dine forretningsprocesser, dine specialpriser og din agentfakturering. Det er ikke helt så ekstremt med BC. Du kan bruge udvidelserne til at integrere komplette løsninger og modifikationer i BC. Du må bare leve med, at Microsoft lige installerer en opdatering, og så virker din varestyring og dit finansregnskab ikke i et par dage, fordi et „plugin“ (som udvidelserne kan forstås som) ikke helt passer til ændringen. Men for enkle virksomheder er BC som SaaS bestemt en mulighed. Jeg kender bare ikke nogen virksomheder, der er så enkle ... Nå ja ... Er der nogen, der kan huske Saas i 70'erne? Nej, det kan jeg ikke. Selv i dag kører alle fly- og togbookinger (i hele verden?) via disse sjove grønne terminaler ... med en seriel forbindelse til en mainframe. Energimæglervirksomhed, banktransaktioner, aktiehandel, flyreservationer, containersporing: mainframesystemer, som kan tilgås fra hvor som helst i verden via en seriel forbindelse. Mainframen er død ... længe leve mainframen 🙂.

Scrum

Er der egentlig nogen, der kender ordets oprindelse? Scrum er det Scrum i rugby med intensiv boldkontakt. Det betyder, at små udviklingsteams kun får ét mål. De bør selv bestemme vejen til dette mål i håb om, at de vil nå deres mål hurtigere uden regulering. På den måde kan man også beskrive mængden i en myretue som et selvorganiserende team. Denne metode er mindre almindelig i Business Central eller Navision, da individuelle udviklere ofte driver komplette løsninger fra opgavedefinition til udrulning (projektejer) i stedet for teams af udviklere. Men selvfølgelig kan SCRUM også kortlægges under/med Navision/BC, måske endda bedre end i andre miljøer på grund af de ekstremt hurtige resultater.

PbV - Pick-by-Voice

En logistik-hype, som jeg personligt aldrig forstod ... ligesom mange brugere ikke forstod stemmerne, og downstream-computeren igen ikke forstod forespørgslerne fra plukkerne. Jeg kender ikke mange virksomheder, der har brugt PbV. Og jeg kender ingen Virksomhed, PbV igen ville bruge. Der vil sikkert være en eller to læsere, der elsker og forsvarer PbV ... de fleste vil, ligesom jeg, bare trække på skuldrene.

Containere, Docker, Kubernetes

Virtuelle maskiner, containere ... værktøjer til bedre at udnytte dyr hardware, men ikke et universalmiddel mod noget ... og slet ikke en mirakelkur. Afhængigt af deres formål kan containere også have ulemper i forhold til virtuelle maskiner. Og begge kan nogle gange tabe et kapløb mod dedikeret hardware. Microsofts bestræbelser på at reklamere for Studio Code-udviklingsmiljøet til Business Central/AL som et Docker-image i mange (alle?) manualer er særligt uhensigtsmæssige. En helt unødvendig forhindring, som allerede har fået mange interesserede til at vende sig bort fra Udvikling af udvidelser har holdt ud. Og den er virkelig cool!

Forstyrrelse

Det, der ikke genopfinder sig selv hver dag, overlever ikke... Dette eller noget lignende er det damoklessværd, der hænger over alle programmer, der ikke bliver rekompileret hver måned med den allernyeste teknologi. Det er en skam, at millioner af linjer med ABAS, Navision (C/)AL, RPG og Cobol ikke har indset dette. Ikke alle programmeringer af gættespil til en radiostation, som er programmeret på det nyeste softwareparadigme, er af så stor økonomisk betydning, at de stadig vil blive vedligeholdt om 10 år. Verdensomspændende flyreservationer i Cobol er derimod.

Mobilen først

Hovedsageligt præget af Google. Flere og flere brugere migrerer til mobiltelefoner. Det er helt sikkert korrekt. Men ... Kender du en indkøber, som beregner sit stålbehov for de næste tre uger på sin mobiltelefon? Kan du forestille dig en revisor, der tjekker og booker 1.200 operationsstuer om dagen på sin mobiltelefon? Amazon, WhatsApp og Facebook er ikke altid de rigtige målestokke for erhvervslivet.

Industri 4.0

Måske er Buzzword 2.0, den Hule højttalere 1.0 Maskiner i netværk? Feedback fra produktionsdata? Robotter, der kan skifte deres egne værktøjer? Det har længe været standard i produktion, hvor det giver mening. En maskine, der producerer 7365 spångafler 24/7, behøver ikke nødvendigvis at kunne håndtere batchstørrelse 1...

KPI - Nøglepræstationsindikatorer

Ja ... HVAD er de vigtigste præstationsindikatorer? Omsætning pr. medarbejder? Omkostninger pr. dag? Ændring i lagerbeholdning i forhold til året før? Det er alle vigtige tal at analysere, men selv uden dette udtryk kunne de findes i 100 år gamle bøger om, hvordan man bliver forretningsassistent.

RAD - Hurtig udvikling af applikationer

...Du kan ikke udvikle kommercielle løsninger hurtigere end med Navsion/Business Central. I 30 år med „revolutionære løfter“ har jeg i hvert fald ikke fundet noget, der gør det muligt. Ellers ville jeg helt sikkert allerede have skiftet mening.

Udvidelser AL

Lad os bryde det ned: Extensions V2 (!) er i sig selv det største skridt, som Business Central eller Navision nogensinde har taget. Korrekt (!) programmeret gør de det virkelig muligt at udvide Navision (set fra brugerens synspunkt) lige så let som en app på en mobiltelefon. I starten giver de også de samme problemer som apps, f.eks. afhængighed af bestemte Navision-versioner, problemer med at opdatere basisapplikationen etc., men det er ikke altid tilfældet.
Men det ligger i sagens natur og er endnu værre med „native“ programmering. Og derfor er det ikke en ulempe.
På trods af alle forsikringer: Udvidelser i sig selv har ikke været en grund til at opgive det integrerede udviklingsmiljø. Det er en ren politisk beslutning, og Microsoft har ikke altid ramt kundernes smag... I den henseende kunne Windows ME, ribbons og Windows 8 også kategoriseres som buzzwords 🙂 .

AL via Visual Studio Code er på den anden side et stort tilbageskridt set fra en udviklers synspunkt, i hvert fald fra mit. AL bliver nu markedsført som et „rigtigt programmeringssprog“ eller „Navision er ved at blive voksen“. Det er stadig ikke et rigtigt programmeringssprog, i hvert fald ikke i sammenligning med C#, Visual Basic, C+, Delphi osv.
Og det er fornuftigt og en god ting!
I et „rigtigt“ programmeringssprog ville jeg bruge noget som #include til at tilføje udvidelser til mit sprog. Microsoft har endda forbudt Net fra AL, i hvert fald fra Azure, og annonceret det for alle efterfølgende versioner.
Omvendt ville jeg i et „rigtigt“ programmeringssprog bøje mine fingre bare for et transaktionsbundt.
AL er præcis, hvad C/Side eller C/AL (under Navision 3.5x hed det også „AL“!) altid har været: et højtydende udviklingsmiljø, der er optimalt fokuseret på kommercielle processer. Ikke mere, men bestemt heller ikke mindre. Den eneste forskel er, at udviklingen nu er blevet meget mere kompliceret i forhold til det tidligere RTC-miljø. Og både RDLC og Studio Code er store tilbageskridt i forhold til det fuldt integrerede miljø inklusive Report Designer fra Navision til 2009R2. Et argument i denne sammenligning var f.eks., at man i RDLC nu også kan placere tekster, der er drejet 90°, f.eks. som virksomhedsreklame, på udskriften. Det savnede jeg ikke fra 1993 til 2015 og har heller ikke haft brug for det den dag i dag. Og hyperlinking kunne også have været indbygget i rapportdesigneren, hvis man ville. Har nogen nogensinde brugt det aktivt? Jeg mener, ikke bare for syns skyld?
OK, for at være fair: side 1 af x og farvet print, f.eks. rødt for negative saldi, er virkelig cool og en reel fordel. Men selv det ville have været muligt med den gamle rapportdesigner, hvis bare Microsoft havde villet. Og hvis jeg kunne bytte, ville jeg hellere undvære røde saldi end den oprindelige rapportdesigner 🙂 .

Når som helst på dagen eller natten deltager jeg i følgende sammenligning/konkurrence for at bevise min pointe: Vi definerer en typisk kommerciel, datadrevet opgave og starter med en passende Navision-opsætnings-dvd (helst som et billede) på en bar Windows-computer. Min opgave: en eksklusiv middag på en eksklusiv restaurant, den langsommere betaler.

Og det sidste argument for AL, at nu „kan alle, der kan programmere, også programmere Navision“: Undskyld, men det er så utroligt dumt ... Ikke alene er det dumt, det er også ekstremt farligt! Selvfølgelig kunne enhver, der kunne kalde Designeren op, også ødelægge Navision. Men der var en naturlig respekt for miljøet: Først forstå Business Central, så gå ud og ændre det. Det forhindrede i det mindste et par komplette idioter i at programmere Navision til ødelæggelse. De andre blev så fundet hos Mibuso. Nu reklamerer Microsoft åbent med, at alle nu kan programmere i dette ERP-system. Selv uden kendskab til varestyring eller regnskab. Jeg ser frem til det... Så... eller så.
Det er ikke uden grund, at selv Thomas Heilsberg, bror til skaberen af Turbo Pascal og i dag stadig en nøglearkitekt for Navision eller Business Central, råder: "For at være en fremragende Microsoft Dynamics NAV-udvikler er det måske endnu mere afgørende at forstå forretningsprocesser end at forstå sproget, objekterne og designmønstrene. Frit oversat: For at være en fremragende Navision-programmør er det måske endnu mere afgørende at forstå forretningsprocesser end at forstå udviklingsmiljøet.
Åh ja ... med Extensions har Navision endelig indhentet SAP teknisk ... Og også arvet de samme problemer som læsbarhed og fejlsøgning. Det kunne have været gjort bedre 30 år senere...

Kanban

„Kort“. Et efterspørgselsdrevet („pull“) kontrolsystem til genopfyldning. Desværre har det kun en nichetilværelse i den vestlige industri. Men når du prøver det for dine kunder?

Kaizen

Kaizen er en filosofi om evig forandring, som stammer fra Japan. I industrien er Kaizen især blevet kendt gennem omvæltningerne og forbedringerne hos Toyota.
I sin industrielle historie består Kaizen primært af de tre Mu, der skal undgås:
Muda Spild. Ting, arbejdstid og materialer må ikke gå til spilde. I den vestlige fortolkning af kaizen er det først og fremmest muda, der er kommet.
Mura Afvigelser i processerne. Processer skal normaliseres og standardiseres og derefter leve i denne form. Alle, der har været involveret i ERP-planlægning og -implementering, ved, at der ikke bruges tid og penge på 90% af simple processer. Der opstår fejl, og der spildes tid, fordi næsten alle diskussioner drejer sig om funktioner til de 10% (eller mindre) afvigelser.
Muri Overbelastning af medarbejdere og maskiner. Denne Mu bliver praktisk talt altid „glemt“. Især i den vestlige industri er der et skadeligt mantra om „næsten 100%-udnyttelse“ af medarbejdere og maskiner. Dette er usundt for dødelige. Vi oplever alle resultaterne (næsten) hver dag: trafikpropper på motorvejene, forsinkelser og aflysninger af tog og fly. Ventetid på, at supermarkedskasser åbner, lange ventetider på tele-hotlinen. Udnyttelser på op til maksimalt 85 % holder processerne kørende. Tomgangstider sparer penge!

Kvantecomputere, kvantecomputere

Ja Holla, hvad har disse fantastiske ting ikke været i stand til at gøre i 10 år? Umiddelbar og pålidelig hacking af alle krypteringer, udvikling af universalmidler, løsning af opgaver på få sekunder, som ville tage vores elskede Windows-pc'er med Navision og Business Central på millioner af år.
OK, når jeg ser på nogle kiksede Navision- eller Business Central 365-opsætninger, ville jeg virkelig ønske, at jeg havde en kvantecomputer til at få svar ud af systemet på en tid, som mennesker kan nå at opleve. Men det skyldes dårlige programmører i stedet for ringere Turing-computere.
I mellemtiden er de første superresultater opnået for meget specifikke optimeringsopgaver. Men vi må stadig vente i årevis, årtier, på resten af resultaterne. Set fra 2021 skriver jeg dette, fordi jeg gerne selv vil vide, hvor længe min prognose holder 🙂 Og indtil da må vi hellere bruge din Navision- eller Business Central 365-database. optimere og rydde op.