Langer doorwerken met oude systemen, hogere ict-kosten en minder modernisering van de dienstverlening dan de burger verwacht. UWV ziet het komend jaar weinig ruimte voor vernieuwing en verbetering door innovatie. De basis van de ict is volgens de dienst inmiddels op orde, maar doordat de dienst extra taken moet gaan uitvoeren, een grote datacentermigratie en meer nadruk op securitty, schiet innovatie er bij in.
Dat blijkt uit het Jaarplan 2020 dat UWV dat naar de Tweede Kamer heeft gestuurd. Wie tussen de regels doorleest ziet een uitvoeringsorganisatie die in ambtelijk jargon een juichverhaal houdt over allerlei verbeteringen, maar ook moet toegeven dat het voorlopig behoorlijk blijft hangen in ict-ellende en weinig kan innoveren.
‘Vanwege het beslag wet- en regelgeving op onze verandercapaciteit is er maar beperkte ruimte om initiatieven te starten voor de vernieuwing van het ict-landschap en het verbeteren van de ict-dienstverlening aan onze klanten en medewerkers. We blijven langer werken met oude systemen en maken hogere kosten, zijn minder goed in staat om mee te bewegen met wensen vanuit de maatschappij en kunnen minder moderne dienstverlening bieden dan we zouden willen’, staat in het Jaarplan. Er wordt niet specifiek toegelicht om welke nieuwe taken het gaat.
De dienst stelt dat de afgelopen jaren de basis van het ict-landschap op orde is gebracht. Preventief onderhoud zou zijn geborgd in een reguliere cyclus voor groot onderhoud. Ook zou de aandacht voor continuïteit, stabiliteit, informatiebeveiliging en privacy zijn vergroot en UWV wijst op verbetering van de beveiliging van portalen.
Stapsgewijs
‘We veranderen stapsgewijs en niet alles kan tegelijkertijd. In 2020 legt nieuwe en veranderde wet- en regelgeving een groter beslag op de verandercapaciteit van UWV dan in voorgaande jaren.’ Daarbij ziet de dienst steeds meer impact van zij-instromende opdrachten; wet- en regelgeving buiten het SZW domein. ‘In 2020 gaat het om meer dan een kwart van alle wet- en regelgevingstrajecten.‘
Afscheid van IBM
Het gaat om de overstap naar een nieuwe hostingconsortium waarbij een contract met IBM wordt ontbonden. René Veldwijk, ict-kenner bij de overheid, licht desgevraagd aan Computable toe dat bij UWV-onderdeel Werkbedrijf ‘alles op slot gaat om de ict-omgeving klaar te maken voor die migratie.’
UWV in het Jaarplan 2020: ‘Alle applicaties en voorzieningen die bij de huidige leverancier draaien moeten nu in een periode van tussen de drie en vier jaar worden overgezet naar de nieuwe leverancier. Daarbij zetten we in op het vernieuwen en vervangen van verouderde ict-componenten.’
‘De migratie is complex en zal de komende jaren veel van onze aandacht vragen. Kleine fouten kunnen al leiden tot grote verstoringen van de dienstverlening aan onze klanten. Een goede planning is nodig om een goed verloop te garanderen en onze verandercapaciteit zo gericht mogelijk in te zetten.’
UWV zegt tijdens de migratie dienstverlening te blijven bieden aan klanten. ‘Ook zullen we blijven werken aan vernieuwingen en verandering van wet- en regelgeving.’ Daartoe wordt een traject gestart voor verbetering van de informatievoorziening, schrijft UWV. Ook privacy en het verbeteren van veilig communiceren worden genoemd.
AVG
De dienst deelt verder dat In 2020 de aandacht uitgaat naar ‘het verder inbedden van de AVG in de organisatie.’ Kennelijk was dat nog niet overal het geval.
UWV: ‘Dit betekent dat onze medewerkers zich in toenemende mate bewust moeten zijn hoe zij kunnen bijdragen aan een veilige omgang met informatie. Onvermijdelijk is dat in de uitvoering tot op zekere hoogte ook ongestructureerde gegevens buiten de systemen worden opgeslagen. Voor deze omgevingen richten wij stapsgewijs het schonen en beheer in.’
UWV zegt ook te investeren in maatregelen die bijdragen aan het verder terugdringen van datalekken, zoals het minimaliseren van de exportfunctie in applicaties met veel persoonsgegevens. Ook worden en preventieve oplossingen geïmplementeerd die tijdig moeten signaleren wanneer gevoelige gegevens onnodig of onterecht de organisatie verlaten, bijvoorbeeld via e-mail. Een tijdspad of planning wanneer die systemen actief zijn wordt niet genoemd
@PA VA KE
De operatie die ik voorstel, kost een fractie van wat al uitgegeven is en ook een fractie van wat een groot project kost.
In Nederland willen grote partijen altijd met een voor hun gevoel even grote partij aan tafel. Daarom missen ze kansen. In Duitsland zijn ze slimmer. Daar kom je als kleine partij wel in contact met de directie van een mega grote bank, kom je tot zaken en volgt de aangename verrassing.
Het voorstel is om de rijdende cq op hol geslagen trein, beter bestuurbaar te maken, terwijl die desondanks geen seconde stil hoeft te staan.
Een structureel probleem van velen is, dat je niet kunt weten wat je niet weet.
Onderzoekt het vele en behoudt het goede.
Het ontwerpen van de nieuwe trein moet exacter. Je wilt dat de huidige trein beter functioneert en toegankelijk is voor directe aanpassingen. De vernieuwde onderdelen functioneren ook in het nieuwe systeem.
Ronald heeft daar wel een punt – zo risico minded als veel organisaties zijn blijven ze vaak binnen die o zo bekende, ingesleten olifanten-paadjes wandelen.
Ook vooruitdenken is in veel organisaties nog wel een “dingetje”. Het resultaat binnen een lopend kwartaal/boekjaar weegt vaak zwaarder dan het rendement over 1-2 jaar (of langer); zelfs als dat rendement tegen die tijd een factor 2-3 hoger licht.
Wat dichter bij (mijn) huis:
Een vergelijkbare situatie is ook van toepassing voor de financiële gevolgen bij aanhoudende verstoringen in een hybride, multi-cloud IT/applicatie landschap. In mijn dagelijkse praktijk als TCP-relatie therapeut ervaar ik redelijk wat weerstand rondom geautomatiseerde probleemanalyses. Dit ondanks dat je met zo een aanpak de financiële gevolgen van verstoringen met minstens 50% terugbrengt (tegen een voorinvestering van hooguit 5%).
Vaak kiest men toch voor een meer handmatige, op locatie uitgevoerde procesmatige analyse middels het afnemen van gebruikersinterviews. Of een analyse met (bijvoorbeeld) een Wireshark voor één specifiek probleem binnen een kleine scope.
Beiden met als argument dat een geautomatiseerde aanpak een voorinvestering vereist die “pas” na 1-2 jaar is terugverdient.
Of met een bredere, meer maatschappelijke insteek:
Kijk maar eens naar de aangedragen “oplossingen” voor het klimaat/CO2 vraagstuk: allemaal korte termijn denken met als focus zo min mogelijk impact op de huidige economie/samenleving. Met daarnaast: potentiële oplossingen moeten binnen, pak hem beet, 5 jaar op grote schaal inzetbaar zijn en gekoppeld aan een “harde” terugverdientijd van maximaal 10 jaar.
Terwijl de echte winst (als die er inderdaad gaat zijn!) zich pas laat zien na 20-30 jaar en daarmee generatie overstijgend is. Dit heeft te maken met de “reactietijd” van mensen, samenleving en de natuur. Hoe reageert mens en samenleving op de ingeslagen weg? In hoeverre beïnvloeden de neveneffecten diezelfde natuur (positief of negatief)?
Daarom de volgende suggestie (met het idee dat *niks* doen in ieder geval *geen* optie is):
Geef mensen die er andere, meer revolutionele ideeën op nahouden eens het voordeel van de twijfel door vragen te stellen; de vraag van Jack is daar een mooi voorbeeld van.
In de reacties/beantwoording is het dan wel zaak niet al te veel in statements te blijven hangen. Noem “het conversie-bedrijf” desnoods met naam-en-toenaam. Dat lijkt me nauwelijks een probleem als hun aanpak inderdaad zo goed werkt en universeel toepasbaar is (d.w.z. schaalbaar en reproduceerbaar).
In dat kader heb ik voor Ronald 3 andere vragen die bij mij steeds boven komen drijven:
– Heb je een of twee voorbeelden van de combinatie (1) – “passende repository”, (2) – karakteristieken van de “betreffende organisatie” en (3) – de “vereiste performance”? Hoe zijn elk van deze 3 gedefinieerd?
– Wat zie je als een illustratief voorbeeld van goede, zelfverklarende code en wat maakt dat deze code anders-dan-andere?
– Zijn er artikelen over geschreven? Waar zou ik die terug kunnen vinden?
@Will Moonen
1) Een repository kan worden gegenereerd aan de hand van de code. Doublures worden onderkend en teruggekoppeld. Met iets meer inspanning wordt e.e.a. zo nodig veralgemeniseerd tot een gemeenschappelijke routine.
2) Sommige organisaties die een goede, eigen manier van werken hebben, hebben een duidelijke karakteristiek. Een ‘cultuur’ van gestructureerd ontwikkelen, rekening houdend met allerlei randvoorwaarden. Bijvoorbeeld domino-effecten uitsluiten door bepaalde manieren van koppelen tussen systeem-onderdelen. Goede architectuur. Programmeer-standaards. Een programma wordt door collega’s beoordeeld.
3) Als je naar een ander platform over wenst te gaan, is het goed om een redelijk vermoeden van de performance te hebben. Doe daarvoor enkele tests.
Op het gebied van performance heb ik enige herinneringen:
– een database verkopende organisatie zou hun systeem ‘even’ demonstreren aan een marketing-segmentatie bureau dat werkte met postcodes met daaraan gerelateerd het type klant. De normale laadtijd in de betreffende COBOL PC omgeving van ruim 650000 records was 5 minuten. Tijdens de demonstratie lukt het niet op de toenmalige snelste PC op de markt bij de klant om dit binnen 4 uur geladen te krijgen. De verkoper had juist aangekondigd dat zijn systeem geweldig was. Die hoefde niet meer terug te komen. Pure tijdverspilling en onzinnige claims.
– Toen het UWV als nieuwbakken doorgeefluik van werkgevers-info, moest doorleveren aan De Belastingdienst, duurde dit maanden en bleek de doorlooptijd bij hun van één aanlevering, ongeveer een dag te moeten duren. Andere ervaringen uit die tijd: de verwerking van meer dan 130 miljoen transacties en laden in een big-data omgeving, is binnen 20 minuten voltooid. Een interpreter in COBOL verwerkt 20 miljoen records in een complexe selectie middels die interpreter, binnen 1 minuut, zowel op mainframe als op PC.
– Een sukkelige initialisatie op een mainframe in een realtime-transactie omgeving, verstookte voor 200.000 euro per jaar aan CPU. De aanpassing reduceerde dit tot aanzienlijk minder dan 1 euro per jaar.
– Een eerste release van een zwaar encryptie systeem, verbruikte 64 x meer doorlooptijd op een PC dan in de volgende release, na enige tuning.
Je ziet tegenwoordig vaak dat het theoretische gegevensmodel één op één wordt geïmplementeerd. Als de performance te ver achterblijft, worden de instellingen en/of indexen van de database gewijzigd. Maar dat helpt soms onvoldoende. Een aantrekkelijkere aanpak is de uitbreiding met access-paden en de bijbehorende frequenties, om vervolgens tot een geoptimaliseerd technisch gegevensmodel te komen. Hoeft niet veel tijd te kosten en bespaart enorm.
Ook procesmatig zie je vaak dat de achterliggende life-cycles worden opgesplitst in gekunstelde transities / overgangsmomenten met de ‘bijbehorende’ opslag. Zonde. In de software zie je vaak eindeloos veel uitvragingen hoe het in Godsnaam mogelijk is dat de betreffende transactie hier en nu wordt aangeboden. Als het dan niet anders kan, dan wordt – als ware het de grootste denkbare uitzondering – de transactie in het systeem doorgevoerd. Onhandig. Een herstartbaar proces werkt efficiënter, vereist minder onderhoud, is logischer en laat zich veel gemakkelijker testen, ook op compleetheid.
Methoden & Technieken worden weinig meer beoefend. Maar reken maar dat als je in aanloop naar je nieuwe systeem, vooruit denkt, je heel veel problemen, ontspannen voorkomt. Weinig kosten, veel plezier.
En zo kun je nog uren doorgaan.
Van zelfverklarende code zijn vele voorbeelden, vooral bij de betere bedrijven. Maar als je het Euler project beschouwt waarin oplossingen in moderne programmeertalen worden getoond, dan zie je het veelvuldig gebruik van identifiers als ‘i’ en ‘j’, populair bij wiskundigen e.d. Maar je begrijpt wel dat in een omgeving waarbij software veelvuldig moet worden onderhouden, dit een onacceptabele naamgeving is. Mijn vroegere coach zei dat de koffie-juffrouw mijn programma moest kunnen lezen en begrijpen. Hij had gelijk. In de oefen-programma’s in het Euler project wordt hier en daar gewerkt met priemgetallen. Dus noem die dan niet ‘i’ of ‘j’, maar noem ze wat ze zijn: priemgetal, getal-van-onderzoek, deler, etc. Dat helpt. Weinig moeite, veel plezier. Zelfs als je zo een programma na maanden nog eens ziet. Je kunt het dan sneller en beter doorgronden. Nog beter als je het voorziet van helder commentaar en een schets van de opzet.
Er zijn enorm veel boeken geschreven over programmeren en technieken. Het ontwerpen staat dan centraal. Data gedreven ontwerp versus functioneel. ‘Functioneel’ leidt doorgaans tot minder uniformiteit. Helaas krijgt de wijze waarop e.e.a. gecodeerd wordt, veelal aanzienlijk minder aandacht. Volmac besteedde daar vroeger wel goed aandacht aan met performance winst. Een enkele presentatie over dit soort onderwerpen, kan enorm verhelderend werken. Laat een HBO-stage-team e.e.a. tot een handboek verwerken, als jouw organisatie groot genoeg is om hier mee om te gaan. Een aanrader met uitermate plezierig resultaat.
Overigens kan zelfs het gebruik van een editor tot enorme verschillen in prestaties leiden. Wat te denken van een 1000-tal variabelen die stuk voor stuk in een alinea van 20 regels code een aantal keer moeten worden opgenomen. Mensen die de ‘power-edit’ in een SPF omgeving hebben geleerd, realiseren dit binnen 10 minuten. Je zult ze de kost moeten geven die er een week voor nodig hebben of langer….
In deze tijd ligt het voor de hand om het internet op te gaan voor meer details…
Ronald, je visie heeft wel raakvlakken met een opiniestuk uit 2013 met de toepasselijke titel: Maak legacy klaar voor de toekomst.
https://www.computable.nl/artikel/opinie/security/4775468/1509029/maak-legacy-klaar-voor-de-toekomst.html
Gezien de vele kenmerken van legacy, zoals opgesomd in een reactie bij dit artikel, is het onmogelijk om met een conversieprogramma de verwevenheid in legacysystemen te ontvlechten naar de verschillende lagen binnen een applicatie-architectuur. Hooguit kun je met een conversieprogramma de legacy-spaghetti overzetten naar een andere omgeving.
Toen ‘wij’ (computer-schaak-geïnteresseerden / CSVN) in zeg +/- 1981 voorspellingen deden over het toekomstige computerschaak en het niveau, zaten we er allemaal naast. We zagen weliswaar steeds beter functionerende programma’s maar de wereldkampioen verslaan, was schier onmogelijk. Zelfs toen we na jaren vernamen dat Deep Blue de wereldkampioen verslagen had, konden we bij benadering niet vermoeden dat er een AI systeem zou komen dat in 4 uur tijd op basis van zelf-leren en eigen spel-theorie boven het wereld-niveau zou uitstijgen. Het gaat over AlphaZero. Voor de geïnteresseerden: zoek op AlphaZero op Youtube en laat je een paar bijzondere partijen voorschotelen met Stockfish. Misschien dat dit het ongeloof m.b.t. ontwikkelingen kan wegnemen. Vooral als schaker zul je verrast zijn.
In conversieland zijn er de afgelopen 20 jaar aardig wat ontwikkelingen geweest. Zoals het geautomatiseerd ondersteund interpreteren van allerlei talen, omgevingen en hun eigenschappen. Dat software de mens in behendigheid meer dan de baas is, is kennelijk in sommige kringen nog niet geaccepteerd. Logisch ook, want het inzetten van duizenden handjes – de uurtje-factuurtje fabrieken – is nog altijd heel populair dankzij het succes van de outsource lobby die het hoger management nog immer in hun greep hebben. Niet in het belang van enige opdrachtgever. De nauwkeurigheid van het werk van échte conversie software, gaan de mogelijkheden van de mens te boven. Aan de zijlijn laat je de beste en positief ingestelde mensen meekijken en bijsturen. Dat levert prachtige resultaten op. Dan kun je naast de horizontale herindeling, het verticale aansturen beschouwen: eigenaarschap van bepaalde verzamelingen, business-owners, geautomatiseerd ontvlechten van ongewenste verstrengeling. Prima te doen in interactie met het conversie-bedrijf. In sommige organisaties wordt dit gekscherend het patat-snijden genoemd: de verticale lijnen in de systemen aanbrengen. De contractuele afspraken tussen de verschillende business vastleggen met geautomatiseerde ondersteuning, interface beschrijvingen, etc.
Er zijn teveel beslissers die met het air van de wijsheid in pacht en angstig tegelijk, hard remmend, bang als ze zijn achterop de fiets de berg op te gaan. Dat scenario is uit een mop. Niet het gewenste scenario voor mensen die met beperkt budget en met kennis van actuele ontwikkelingen, alles uit de kast willen halen en mooie resultaten in korte tijd willen halen. Want het kan écht, al het negativisme ten spijt. De mogelijkheden van nu zijn zeker niet de onmogelijkheden van vele jaren terug.
Dat computers beter kunnen schaken dan mensen bewijst alleen dat ze beter kunnen rekenen en dat wisten we al.
Een willekeurige 3GL wordt uiteraard niet zelfverklarend door een betekenisvolle naamgeving van de variabelen. Voor zover je met zelfverklarende code echter doelt op declaratieve programmeertalen kom je met een programmeerstijl die tamelijk hardnekkig niet weet door te breken, namelijk functioneel programmeren (zoals eerder al het logisch programmeren niet van de grond is gekomen).
Zie hiervoor mijn reacties op:
https://www.computable.nl/artikel/opinie/development/6330734/1509029/populariteit-functionele-talen-stijgt.html
Uiteraard heb ik niets tegen het gebruik van functies in een object georiënteerde taal als Python; het gaat mij vooral om de academische pogingen zuiver wiskundige en logische programmeertalen te ontwikkelen.
Daarnaast is er een declaratieve programmeertaal die in de praktijk wel werkt, en dat is: SQL. Zoals is aangetoond in de vele reacties op:
https://www.computable.nl/artikel/opinie/digital-transformation/6666832/1509029/sql-vaardigheden-kunnen-bij-grofvuil.html
Op het tegenargument dat SQL toch ook op wiskunde is gebaseerd ga ik nu even niet in 🙂
Maar echt declaratief/zelfverklarend wordt het pas met een 5GL waar de gewenste eindresultaten dienen als verklaring voor te realiseren deelresultaten.
Zou het toeval zijn dat ‘explainable AI’ tegenwoordig ook ‘declarative AI’ wordt genoemd? Met een winstwaarschuwing: een academische aanpak zal deze benadering opnieuw met heel veel jaren traineren.
https://2020.declarativeai.net/
In mijn optiek past 5GL geheel binnen het idee van declaratieve AI, en mijn proof of concept is hier terug te vinden:
https://dmcommunity.org/challenge/challenge-march-2019/
Nog altijd kun je een oplossing voor deze challenge insturen in een zelfbeschrijvende, declaratieve taal naar keuze!
… “Dat computers beter kunnen schaken dan mensen bewijst alleen dat ze beter kunnen rekenen en dat wisten we al…. ”
Dus niet! Zou je de moeite hebben genomen de commentaren te volgen, dan zie je dat AlphaZero een geheel eigen strategie volgt. De diepte van de berekeningen, is veel minder groot dan verwacht. Zet, tegenzet, iedere zet-stap, noemen we in de schaakprogrammering het aantal ply. Het aantal ply dat AlphaZero benut, blijkt tamelijk gering. Als die vervolgens het lef heeft 3 pionnen te offeren, dan is dat geen onderdeel van het rekenen want dan zou die keus nooit gemaakt zijn. Dus jouw betoog over computers die beter schaken, is slecht onderbouwd. AlphaZero voegt iets toe zonder dat wij mensen, kennis nemen van de door die AI opgebouwde strategie. Helaas. Want er lijkt duidelijk wel iets van te leren.
…. “Een willekeurige 3GL wordt uiteraard niet zelfverklarend door een betekenisvolle naamgeving van de variabelen.” ….
Op zichzelf niet, maar zoals het bij de betere bedrijven wordt toegepast, zeker wel. Ook bij conversies wordt een dergelijk commentaar toegevoegd, wordt van subroutines aangegeven wat er in gaat en wat er uit komt, met zinvolle namen, dus iemand die niet kan programmeren maar wel functionele kennis heeft, die begrijpt wat er gebeurt en kan zich er zelfs een gefundeerde mening over vormen.
… “functioneel programmeren ” ….
Als je daarmee doelt op zogenaamde ‘methoden’ als functionele decompositie, dan klopt het helemaal dat daar niets van deugt. Vooral omdat de ‘methode’ geen ingebouwde zelfcontrole heeft en nieuwkomers in hun benadering er weinig in slagen een éénduidige benadering te creëren. Integendeel. Zoveel beoefenaren, zoveel benaderingen. Heel anders als de mensen data georiënteerde Jackson technieken benutten. Allereerst heeft Jackson wel ingebouwde zelfcontroles, waardoor vroegtijdig onderkend kan worden dat er iets aan schort, zowel op systeem-ontwikkelings-niveau als bij het programmeren. Zo zie dat men bij de grotere financiële instellingen, nog altijd enige hang heeft naar ‘Volmac Structured Programming’ (VSP), terwijl dit maar ongeveer 3,5 hoofdstukken van de 10 hoofdstukken van Jackson Structured Programming tellende (JSP) bevat. Zo heeft Volmac de AMSA weggegooid, dat vooral een zwakke en onvolledige manier was om backtracking problematiek gestalte te geven. Wat de financiële instellingen betreft, heeft VSP echter veel toegevoegde waarde. JSP en JSD dus nog veel meer. Maar aangezien men zich meer en meer op mensen uit India verlaat, die bij benadering geen vermoeden hebben van technieken met ingebouwde zelfcontrole, zie je vooral een forse achteruitgang in kwaliteit. Tegenwoordig zie je vooral de quick&dirty; benadering terugkomen, aangemoedigd door zogenaamde ‘sprints’. Vast ook de reden waarom we overstroomd worden met een hoge frequentie aan ‘updates’ en logischerwijs ook de bijbehorende problemen.
“die in de praktijk wel werkt, en dat is: SQL” . De ’taal’ die als gegevensbenaderaar is opgenomen in de verschillende 3Gl’s. SQL zie je bij de financiële instellingen ongeveer niet in productie draaien als zelfstandig onderdeel en al helemaal niet met rechten om iets te veranderen. Veel te gevaarlijk. Vraag het eens na.
” object georiënteerde taal” …. Ik raad het niemand aan. Schattige domino effecten van ingebouwde erfenissen zijn het gevolg. Wat ik wel aanraad is het benutten van een life-cycle geörienteerd ontwerp en die op de Jackson manier gestalte geven. Professor Verhelst probeerde met ‘Merode’ er al eens mee aan de haal te gaan, maar ging voorbij aan de échte ontwikkelingen in JSD. LBMS kocht de Jackson aanpak op, positioneerde het als ’technisch’ en probeerde daarmee hun eigen ‘methode’ voorrang te laten krijgen, maar als je écht kwaliteit wil, dan geniet het moderne JSD nog steeds de voorkeur, juist in een administratieve omgeving en zonder allerlei merkwaardige watertjes bij de wijn te toen. Gewoon de échte regels toepassen, ook bij online (dus vooral niet denken dat het dan anders zou moeten…. ), complexe systemen, etc.
Prettig nauwkeurig. Gemakkelijk testbaar. Goed onderhoudbaar. Geen geknoei. Daar hou ik van.
Ronald
Je wil dat we de moeite nemen de commentaren te volgen.
Dat zijn er nogal wat.
Lastige is dat niet helemaal duidelijk is wat wordt beweerd.
Het begint bij de stelling dat het niet zo moeilijk is spaghetti code te ontwarren.
“Totaal niet zelfs. En veel hoeft het ook niet te kosten! Je moet dan natuurlijk wel de intelligentie hebben om voor een geautomatiseerde oplossing te kiezen.”
“Als er als klap op de vuurpijl bij de conversie een perfect fraaie repository wordt opgeleverd waarmee functioneel beheerders cq product-owners functionele specificaties in een flits kunnen achterhalen, dan ga je er flink op vooruit.”
Hoe dat automatisch kan volgt in later posts :
1) AI die mensen niet begrijpen : “De nauwkeurigheid van het werk van échte conversie software, gaan de mogelijkheden van de mens te boven.” en “AlphaZero voegt iets toe zonder dat wij mensen, kennis nemen van de door die AI opgebouwde strategie. Helaas. Want er lijkt duidelijk wel iets van te leren.” of “Dat software de mens in behendigheid meer dan de baas is, is kennelijk in sommige kringen nog niet geaccepteerd.”
2) Toch met met menselijk hulp : “Aan de zijlijn laat je de beste en positief ingestelde mensen meekijken en bijsturen.”
Dus we snappen het niet dat het allemaal automatisch kan en het kan eigenlijk ook niet allemaal automatisch 😛
Hozanna over de mogelijkheden van nu en onmogelijkheden van het verleden en dan met schaakprogramma’s
en y2k problemen aankomen en priemgetallen, variabele namen en wat function parameters beschrijven ?
Gaat Alphazero die functionele specs uit de code halen en wordt dat tegengehouden door
“de outsource lobby die het hoger management nog immer in hun greep hebben” ?
Over positief ingesteld mensen gesproken 😉
De enige reden dat we je niet geloven is dat je ongeloofwaardig bent.
Maar we hebben wel genoten 🙂
@Dino’s veelvuldige ‘we’ / ‘pluralis majestatis’? Voer voor psychologen.
Het UWV werkt met falende partijen.Tijd voor verandering. Besturing toevoegen, meer controle, krachtige inventarisatie, alles beter dan doormodderen.