Belgische spoorwegmaatschappij schrapt it-systeem dat al 30 miljoen euro kostte

De NMBS heeft de ontwikkeling van een uniform ticketingsysteem stopgezet. De ontwikkeling was sinds 2012 bezig en heeft al 30 miljoen euro gekost, maar het systeem werkte nog altijd niet naar behoren.

NMHet gaat om het New Distribution System voor het verkopen van tickets, waar Ypto al sinds 2012 aan werkte. Ypto is de it-dienstverlener voor de NMBS, de organisatie voor de Belgische spoorwegen. Ondanks de investering van 30 miljoen euro is besloten de ontwikkeling stop te zetten, volgens De Tijd omdat het systeem nog altijd grote gebreken vertoont.

De leiding van NMBS bevestigt het schrappen van het systeem. Het was de bedoeling dat de drie ticketingsystemen waar de spoorwegen nu mee werken, voor online, de kaartautomaten en de loketten, onder een overkoepelend systeem zouden vallen. "Na een studie hebben we gekozen voor een ander systeem dan datgene waaraan we werkten", zegt Sophie Dutordoir, ceo van NMBS.

Het is niet de eerste keer dat de NMBS een omvangrijk technisch project schrapt. Recent gebeurde dat met het DICE-project, dat moest voorkomen dat treinen met open deur vertrokken. Met de ontwikkeling hiervan was al een investering van 11 miljoen euro gemoeid.

Door Olaf van Miltenburg

Nieuwscoördinator

13-10-2017 • 12:10

208

Submitter: Gertje97

Reacties (208)

208
203
105
13
2
81
Wijzig sortering
Als treinbestuurder bij de nmbs kan ik hier wel wat ervaring delen.

Over het ticketsysteem weet ik niet zoveel van, maar wel over dat dice-systeem. Het is een werkelijke schande, men heeft er zoveel geld ingepompt, terwijl iedereen het al op voorhand wist dat het nooit ging marcheren. Voor zij die aan een Belgisch perron/station staat, u moet eens kijken op verlichtingspalen,etc, naar gele ronde 'tags'. Via die tags ging de treinbegeleider dan satelliet-gewijs ons melden dat we veilig mochten vertrekken. Maarja, met onze ouderwetse technologie (waarin we met moeite een pdf deftig kunnen openen) ging dat nooit goed komen. En het ergste van al is. die 11 miljoen euro van dice was met één reglementswijziging opgelost. Namelijk dat de treinbegeleider bij vertrek zijn deur zelf mag sluiten (zoals in Nederland), maar neen, wij Belgen moeten weer moeilijk doen.

Lang leve de persoon die er geld heeft aan verdiend.
... maar neen, wij Belgen moeten weer moeilijk doen....
Ach, "wij" Nederlanders stoppen software in een tunnel.
En onze treinen worden vooralsnog bewaakt door een relaissysteem dat in de jaren 60 voor het laatst een upgrade heeft gehad.
En recentelijk nog het Cap Gemini debacle.
En onze treinen worden vooralsnog bewaakt door een relaissysteem dat in de jaren 60 voor het laatst een upgrade heeft gehad.
Als je naar de treinbeveiligingssystemen kijkt in onze buurlanden lopen wij met ons ruim 50 jaar oude systeem nog steeds niet achter. Het ATB systeem is nog steeds (met zijn uitbreidingen door de jaren heen) een erg goed systeem.

Daarnaast heb je een nieuw systeem ook niet op vandaag op morgen uitgerold. Naast de infrastructuur moet ook al het rollend materieel er op aangepast worden.
Wel systeem beveiligt de HSL dan, waar TGV en IC-Direct harder dan 160km/u rijden?

edit:
Sorry, sarcasm-tag vergeten ;) Was reactie over 'vandaag op morgen uitgerold': het is al uitgerold op dat traject.

[Reactie gewijzigd door MBV op 24 juli 2024 02:18]

European Rail Traffic Management System, in het kort, ERTMS. Dat is het systeem wat langzaam uitgerold wordt en de ATB moet opvolgen. Ook tussen Lelystad en Zwolle is dit systeem al aangelegd, zo ook op de Betuwe route en tussen Amsterdam en Utrecht ook.

De Nederlandse regering besloot op 8 juni 2012 het Nederlandse spoorwegnet uit te gaan rusten met het ERTMS naar aanleiding van het 'Parlementair onderzoek onderhoud en innovatie spoor' van de tijdelijke Tweedekamercommissie Kuiken. Op 11 april 2014 presenteerde het kabinet de 'Voorkeursbeslissing ERTMS', waarin werd besloten dat het ERTMS in Nederland tussen 2016 en 2030 wordt ingevoerd op de drukste spoorlijnen en op corridors voor goederentreinen. In de loop van 2015 werd de invoering van het ERTMS stilgezet vanwege een aantal onzekerheden, onder andere over de projectbeheersing, kritiek van de Auditdienst Rijk, de wens van de kamer om de lessen van het Fyra-debacle mee te nemen en ervaringen in het buitenland.

Op 23 september 2016 presenteerde het kabinet een nieuwe 'uitrolsrategie ERTMS'. Eerst wordt het inbouwen van het ERTMS in treinen ter hand genomen, dat duurt tot 2024. Daarna volgt inbouw het spoorwegnet. De planning voor de inbouw in het spoor loopt tot 2038, acht jaar langer dan voorzien in het eerdere plan van kabinet uit 2014. Volgens het nieuwe plan is er dan een groter deel van het spoorwegnet voorzien van ERTMS dan volgens het eerdere kabinetsplan, maar het wordt ook volgens het nieuwe plan nog niet in het hele spoorwegnet ingebouwd. De planning na 2028 wordt 'voorlopig' genoemd.

[Reactie gewijzigd door LordSinclair op 24 juli 2024 02:18]

HA je bedoelt dat stuk over de nieuwe spoorbrug in Zwolle, waar ze een spoor vergeten zijn waardoor de trein naar Lelystad tot aan wezep over het oude langzame spoor moet :) :) :) :)
Die laatste upgrade stamt niet uit de jaren 60. De afgelopen jaren is er stevig gewerkt aan ATB-NG en ATB++ waarvan de laatste uiteindelijk ATB-vv werd.

Het zijn wel meer aan elkaar genaaide lappen-dekens om de problemen eruit te halen, maar het geeft toch aan hoe ATB de laatste jaren stevig is door-ontwikkeld.
Ach die oude relais doen hun taak prima. Blijken net zo betrouwbaar te zijn als PLC’s (ook die gebruikt ProRail) maar bij verstoringen zijn die relais wel sneller gerepareerd. Maar dat komt vooral om dat de verschillende onderaannemers vooral hun eigen straatje schoon vegen. Bij de ouderwetse relais gaat dat niet zo makkelijk.
Als ik het goed begrijp stuurt die software van de tunnel de sluitingmechanisme als de sensoren een te hoge vrachtauto meten. Dat kun je de software (en makers ervan) weinig kwalijk nemen.

Te hoog = te hoog.
De software had nogal moeite om het verschil te zien tussen een vrachtwagen en een zwaluw.

(Een Europese zwaluw, denk ik, ja)

Er zijn heel veel tunnels in de wereld die zonder software kunnen.
Een zeer veilig en betrouwbaar onderdeel wat al ruim 50 jaar trouwe dienst doet. Echter de moderne tijd met meer treinen, lichter materieel en talloze andere elektronische systemen en hun stoorstromen, stelt hogere eisen aan de werking van het relais
Dat is wat er in 'jouw' rapport staat.
Niet dat er in de afgelopen 60 jaar niets aan gebeurt is.
En jij denkt dat het systeem in België niet nog minstens voor een deel op relais draait?

Zeker wel!
Dat is omdat het relatief eenvoudig is en omdat je met doorgedreven kwaliteitscontrole toch met iets zo eenvoudig als een relais alsnog veiligheidsinformatie kan doorgeven.

Er zijn volledige wisselroosters die nog voor veiligheid 100% op relaissystemen (technologie 1955 oid) draaien, en die zijn qua veiligheid equivalent aan onze elektronische inklinking.

het is niet omdat we nu veel dingen anders doen, dat we alles anders doen, of dat alle systemen uit het verleden slecht zijn.
Elke grote tunnel heeft aanturing en monitoring nodig, hoe wil je dat zonder software doen precies?
Uh, waarom heeft een tunnel aansturing nodig? 't Is nou niet zo dat die tunnel veel beweegt ofzo...

Ik reed al door kilometers lange tunnels zonder enig teken van elektronica. Waarom moest dat flutding ineens zo ingewikkeld gemaakt worden?
Je reed kilometers in het donker?

In elke grotere tunnel heb je (nood)verlichting, afzuiging, luchtverversing, bewakingssystemen (sensoren, camera's), pompen (voor als er veel regenval is). Dat moet toch echt allemaal aangestuurd/verwerkt/gemonitord worden :)
Nou, in Arizona was er wel een onverlichte eenbaans tunnel waar je aan het eind een stokje aan de verkeersregelaar moest geven als je de laatste van de "batch" was.

Maar laat ik het zo formuleren: "Waarom moest er NIEUWE software bedacht worden?"
Of de deur bij de 'drank wagon' op de tweakers express die met 120 km/h spontaan openvliegt omdat ze op het station daarvoor de druk er af hadden gehaald.
Dacht is ook wel een leuke toevoeging aan Nederlandse fuck ups (maar echt het was hilarisch).
Mooi systeem. Vroeger hield iemand dan een bordje omhoog. Maar dit kan natuurlijk ook. :)
"Mooi systeem. Vroeger hield iemand dan een bordje omhoog. Maar dit kan natuurlijk ook."

Kunnen we weer invoeren.
Requirement 'Moet spiegelei omhoog kunnen houden'.
En dan laten bouwen door Capgemini. :P
DICE had ook als klein voordeel dat alle modules binnen zijn geweest voor een software update, titanenwerk dat kan ik je wel vertellen. :)
Lang leve de persoon die er geld heeft aan verdiend.
Ruikt dat niet naar vriendjespolitiek? Het lijk mij goed dat een Belgische AFM zo'n onderzoek - wie welke belangen heeft gehad bij zo'n project.
Elk groot contract uitgeschreven door een staatsbedrijf ruikt naar vriendjespolitiek. Bouwprojecten zijn nog erger.
Je hoeft je niet te schamen.In Nederland zijn wij ook hierin kampioen in het geld uitgeven aan staatssoftware dat niet werkt. Bijvoorbeeld bij de politie en belastingdienst.
Familie, vrienden en kennissen worden feestelijk binnengehaald door de opdrachtgever, de software specialist incasseert miljoenen en verdwijnt dan door de achter deur om bij de voordeur weer naar binnen te kunnen.

[Reactie gewijzigd door turtles3 op 24 juli 2024 02:18]

Anoniem: 297325 13 oktober 2017 13:35
Ik blijf het herhalen. Dergelijke projecten moet je IN HOUSE ontwikkelen. Sourcing op een dergelijk ingewikkeld niveau is vragen om te falen. Dat bedrijven, managers, project onwikkelaars dat nog steeds niet snappen is me een raadsel. Mijn vuistregel is: Als je voor het bedrag van de aanbesteding, en voor de duur van het project, zelf ontwikkelaars full time in dienst kan nemen -> in house. Je moet dan initieel natuurlijk wel wat tijd steken in een goede werving, maar dat haal je er zo weer uit. Gesourcte IT projecten falen om de haverklap en van de zogezegde niet gefaalde projecten is de helft brak. Waarom werkt sourcing niet in IT -> omdat er teveel tussenstappen zijn tussen eindgebruiker, systeem, platform en de uiteindelijke programmeur. Problemen, bugs, ... gaan verloren, lopen vertraging, in de complexe, logge bureaucratische structuren. Ticketing systemen waar er enkel input is, maar niemand de moeite doet om er eens een listing uit te halen, laat staan er dan iets mee te doen. En daarbij de onmacht omdat contracten vaak zo vaag zijn opgesteld dat je eigenlijk evengoed gewoon je geld kan storten zonder er iets in return voor te vragen.
Helaas maar zo werkt het niet in de echte wereld. Straks ga je nog opperen dat men zelf kantoorpanden gaat metselen.
Uitbesteden van diensten is heel normaal, daarbij komen doorgaans ook alleen de grote mislukkingen in de media.

Deze mislukkingen delen vaak één ding: slecht opdrachtgeverschap. Van te veel bemoeien tot geen enkele betrokkenheid. Dit wordt vaak aangevuld met extra risico's zoals vage opdrachten, wijzigende opdrachten, moedwillig de opdrachtgever meer gunnen (vriendjespolitiek / kerstpakket), interne discussies over de gewenste oplossing, etcetera.

Vergelijk het met het opknappen van een huis. Bepaalde dingen kan jezelf, kost vaak wat meer tijd. Sommige dingen kan jezelf maar laat je liever door een expert doen vanwege bijv. garantie of ervaring. Ten slotte zijn er zaken waarvan je niks weet en waarbij je afhankelijk bent van de kennis van derden (bijv. Constructeurs). Bij alle drie kan het mis gaan, de risico's leggen echter anders. Er is maar een persoon die dat dient te managen: jezelf.
Er kan wel geklaagd worden (als consultant) dat de opdrachtgever de schuld draagt, maar ik zie de opdrachtnemer zelden stoppen met geld te aanvaarden of aan de alarmbel te trekken bij de hoofdverantwoordelijke, terwijl ze realiseren dat ze geen toereikend product/dienst kunnen leveren naar de vooropgestelde verwachting. Het hele systeem zou in een perfecte wereld werken als leidinggevenden ook effectief verantwoordelijkheid moesten afdragen, ook als ze in de tussentijd een andere job of functie hebben aangenomen.

Grote of complexe projecten duren lang genoeg waardoor de startende groep verantwoordelijken er helemaal anders uitziet dan bij oplevering. De mensen die hun carrière willen fast-tracken zijn al vaak uit de functie vertrokken voordat het project rond is en doordat ze geen tijd hebben voor iets deze projecten op te volgen (want carrière maak je niet door je werk te doen maar te laten zien dat je meer kan dan de rest), valt het nog niet eens op tot dat de nieuwe verantwoordelijke het project moet overnemen en inziet hoe slecht het gemanaged was.
Volledig mee eens, opdrachtnemers zouden ook eervol moeten acteren. Helaas kan je daar als opdrachtgever niet altijd van op aan, zeker niet met de europese aanbestedingen.
Volgens mij lezen veel mensen het artikel niet goed want Ypto is onderdeel van de nmbs. M.a.w. het is in house ontwikkeld! Dat is ook de grote mop hiervan.
Als technicus seininrichting bij de Belgische ProRail equivalent Infrabel kan ik dit volledig beamen.
In het veld zien wij duidelijk wat er gaande is wat de heren en dames aan een bureau of vergadertafel niet zien. Natuurlijk is Infrabel een overheidsbedrijf en dienen de managers te luisteren naar de bevoegde minister(s). De managers moeten het op een te korte termijn klaren met mooi 'beloningen' die aan het resultaat privaat gewijs vast hangen. Wij specialisten moeten plaatsmaken voor de 'onderaannemers' en 'consultants' die meestal via een andere dochteronderneming worden ingeschakeld en er ook heel goed aan verdienen zonder te beseffen dat het over heel complexe materie gaat. Het diversifiëren van de gebruikte technologieën die niet ontwikkeld zijn door Infrabel en wel door onderaanneming (kan soms niet anders door wetgeving) gaat samen met de vele nodige problemen die op het terrein door ons met veel kennis en kunde moeten opgelost worden maar amper erkent worden. Dit stelt natuurlijk die managers in een slecht daglicht dus mag dit het daglicht niet zien. Privatisering is nu een heilige koe....vraag maar aan de mensen in het VK hoe dat is afgelopen.

[Reactie gewijzigd door mutmong op 24 juli 2024 02:18]

+ als je project maar lang genoeg duurt heb je nog een goede kans dat een heel deel van de kennis weg is door personeelsverloop bij je externe partij..
als documentatie dan nog een ramp is, is het plaatje compleet..
spreek ook uit ervaring :)
Alhoewel je deels een punt hebt, moet je ook nog (goede) in house mensen vinden.

Hoe onbegrijpelijk het ook is, er is soms gewoon geen personeel te vinden, hoe hard je ook je best doet. Uitzondering zijn freelancers die per dag een half maandloon vragen, en na een paar maanden weer weg zijn, en bovendien ook niet echt in house zijn.

Er is in BE, en vast ook in Nederland, een enorm tekort aan goede mensen. Het bedrijf waar ik werk smeekt om personeel, maar vindt dat amper.
Ik ben het helemaal met je eens, ik vind het af en toe haast eng hoe weinig kennis er is van essentiële systemen die niet alleen veel geld kosten maar ook nog eens waardevolle data bevatten. Continuïteit is een groot probleem. Mensen vast in dienst hebben helpt, maar het is niet genoeg, ook mensen met een vast contract stoppen er ooit mee. Op een bepaalde manier is het nog lastiger als iemand met 20 jaar ervaring vertrekt; daar zit waarschijnlijk een hele hoop ongedocumenteerde kennis is.

Deel van het probleem is ook het ontbreken van standaarden voor kwaliteit en werkwijze. Daardoor is het erg moeilijk om het werk van een ander over te nemen. De standaardreactie is "ik doe het wel even opnieuw" (Dat is niet alleen in de IT zo hoor, iedere automonteur, loodgieter of elektricien zal je ook vertellen dat zijn voorganger een prutser was, maar in de IT lijkt het nog erger.)

Als alles al perfect is geregistreerd en gedocumenteerd, dan is het maar de vraag of je een geschikte werknemer kan vinden op het moment dat je er eentje nodig hebt. Hoe je beoordeelt of iemand goed is in IT is ook maar zeer de vraag. De meeste mensen zijn niet in staat om gemotiveerd te beoordelen waarom het ene stuk software beter is dan het andere, en welke ontwikkelaar dus beter is, of wat het zou moeten kosten. Sterker nog, als het niet goed is kunnen ze dat ook niet uitleggen. Zie het enorme aantal bugreports en helpdeskmeldingen die niet meer zeggen dan "het werkt niet" zonder aan te geven wat er dan niet werkt of wat er verkeerd gaat.
De markt weet het ook niet. Ik kan voor 5 euro per jaar een kant en klare Drupal/Wordpress/... website uit een "generator" halen, of ik kan 50.000 euro uitgeven aan een webdesigner die ook Drupal als basis gebruikt. Leg een gewoon mens maar eens uit waar het verschil zit.

Ergens snap ik dan wel dat de baas liever een kant-en-klare doos koopt waar een bedrijf achter staat dat mooie beloftes doet. Op papier heeft hij zo alle verantwoordelijkheid netjes belegd. Als het fout gaat dan is het de schuld van dat bedrijf. Dat de eindgebruikers niet kunnen werken is jammer, maar niet zijn verantwoordelijkheid. Tegelijkertijd lijkt iedereen te accepteren dat IT altijd een rommel is en er wordt niemand ooit op afgerekend.

Al dat rommelwerk is een groot probleem. Als 80% van je projecten mislukt dan wordt er enorm veel geld verspilt. Het is lekker verdienen voor hen die het werk uitvoeren, maar uiteindelijk is er minder geld over om het goed te doen. We zitten in een beetje vervelende spiraal waarbij er nooit genoeg geld is om het goed te doen, maar wel om drie goedkope projecten te laten mislukken.
beter nmbs privatiseren denk ik dan..
Daar gaan we weer met deze ongefundeerde dooddoener. Er steekt iets tegen bij de NMBS en men roept al weer om privatisering. Wil je duurdere tickets, minder treinen, minder spoorlijnen, lagere stiptheid maar toch dezelfde overheidssubsidiering? Dan moet je inderdaad privatiseren want zo is de situatie in het Verenigd Koninkrijk nl. ook geëvalueerd. Overigens is de ontwikkelaar een private partij dus dit verhaal had je niet kunnen vermijden door privatisering.

[Reactie gewijzigd door Vnze op 24 juli 2024 02:18]

Waarom altijd het Britse spoor als voorbeeld? Waarom niet het Zwitserse of Japanse?
Omdat het Britse spoorwegmodel het beste bij het Belgische past. Neem inderdaad Japan: dat spoorwegnetwerk is een soort backbone met uitlopers oftewel visgraat. Op zo'n model kan je makkelijk bepaalde lijnen in concessie geven. Het Belgische (en Britse) netwerk is stervormig. Zo goed als alle belangrijke lijnen gaan naar of door één enkel punt (Noord-Zuid verbinding voor België) waarop de dienstverlening volledig moet worden afgestemd. Wat er dan nog overblijft zijn érg verlieslatende rurale lijntjes waar een privéfirma geen boodschap aan heeft en het aanbod bijgevolg zou terugschroeven.

Het Japanse netwerk is heel performant zolang er niks misloopt, als dat wel het geval is loopt alles grondig vast. Een gevolg van het optimaliseren (lees: wegbezuinigen van reserves) van de infrastructuur. Als men dat in België (met een veel minder performant netwerk door de stertopologie) ook zou doen gaat niemand nog op tijd op zijn werk zijn. Dan heb ik het nog niet over de fundamenteel andere cultuur in Japen, ook daar komen wij meer overeen met de Britten. Je ander voorbeeld, de SBB is nog steeds in de handen van de staat terwijl de meeste mensen met "privatiseren!" een verkoop bedoelen.

Tenslotte: privatiseren is geen magische oplossing die alle problemen doet verdwijnen. Men kan wel voorbeelden aanhalen waar het werkt (of niet) maar dat lost het dus niet op. Wat zou een privaat bedrijf beter doen mbt. spoorlopers of een overbezet netwerk? Zou een privaat bedrijf niet het risico lopen vol goede moed een project van 30 miljoen te starten wat uiteindelijk nergens naar toe gaat?

Waarom zouden we dus het openbaar vervoer (mijn inziens een staatsaangelegenheid en basisbehoefte) privatiseren ipv. reorganiseren als je het risico loopt in de Britse situatie terecht te komen bij privatisatie? Ik kan je vraag ook makkelijk omkeren. Kan iemand garanderen dat we met privatisatie in de Japanse of Zwitserse situatie terechtkomen en niet het Britse?

TLDR: de kans dat we naar het Brits model afglijden is m.i. véél groter dan de kans om het Japans model te benaderen. Privatisatie is geen heilige graal en je moet opletten met zo iets belangrijks als openbaar vervoer in de etalage te zetten wil je je mobiliteit naar de toekomst toe kunnen garanderen.
Hoera voor deze heldere uiteenzetting.

OV is een basisbehoefte. De dekkingsgraad van het OV is er in NL bepaald niet op vooruit gegaan sinds de privatisering van de busmaatschappijen.

In treinenland gaat het inmiddels vrij goed, maar ik twijfel sterk of dat dankzij of ondanks de privatisering van de NS (nog steeds grotendeels in overheidshanden) is.
Je bedoelt de NS welke 100% in overheidshanden is: https://nl.wikipedia.org/wiki/Nederlandse_Spoorwegen.
Oftewel het is geprivatiseerd in naam, niet qua aandeelhouders/eigenaren.

Maar in Nederland werkt de privatisering daarom ook meer richting Japanse model, waarbij hoofdlijnen verplicht nog in concessie zijn bij de NS. En de 'visgraten' meer en meer richting andere bedrijven, privaat dan wel dochters van staatsbedrijven (zie bijvoorbeeld Arriva), gaan.
Op cynische dagen denk ik wel eens dat dit soort bedrijven alleen zijn geprivatiseerd om commerciële salarissen aan de directeuren te betalen.
Ik weet dat privatiseren geen magische oplossing maar de algemene perceptie lijkt te zijn dat de NMBS het meest dysfunctionele bedrijf in België is.

Reorganiseren lijkt me ook bijzonder moeilijk met de vakbonden die elke kans die ze kunnen grijpen om te staken (altijd met een acute verkeersinfarct tot gevolg) en aan niemand verantwoording moeten afleggen.

Hoe dan ook moet er wel iets gebeuren want over enkele jaren wordt de Europese markt voor binnenlands reizigersverkeer opengesteld voor concurrentie. Als ze niets doen gaat dit nog eindigen zoals Sabena.
Ik bedoelde dat niet specifiek jou, het is een langlopende ergernis :-) gelukkig loopt het volk dat zo simpel denk niet in te grote getallen rond op Tweakers.

Dat de periode vlak na het openmaken van de markt interessant gaat worden ben ik zeker met je eens. Dat de vakbonden gereorganiseerd moeten worden eveneens, al ben ik niet voor een totale afschaffing of het totaal machteloos maken. Een goed werkende vakbond is in ieders belang: de arbeiders, bedienden, chefs, vakbondsleden (ok niet alle vakbondsleden) én reizigers.
In de UK is het miserie kwa het spoor. Zoveel variabelen op de prijs van je kaartje 8)7 Dat ook zij door de bomen het bos niet meer zien. In Japan werkt het inderdaad een stuk beter.
de vraag was er enkel om de discussie op gang te brengen..
Ivm privatiseren, misschien in beperkte vorm en in stapjes zoals in nederland.
zoals @MSalters aanhaalt:
"In Nederland hebben we dat ook gedaan voor een aantal kleine verbindingen (niet hoofdnet), en hier is de aanbesteding wél een succes"
bedankt voor de info
Geen probleem met de discussie op gang te brengen hoor :) ik persoonlijk ben het gewoon beu dat men bij iedere tegenslag "privatiseren!" roept alsof het een magische oplossing is. Zwartrijders roepen het zelfs naar treinbegeleiders als ze betrapt worden en ook spoorlopen is, uiteraard, veroorzaakt door het feit dat de NMBS een openbaar bedrijf is. Hier is het misschien wat minder duidelijk maar weer had een private firma het niet per definitie beter gedaan.

Mij lijkt dat geen enkele (van de vele) problemen bij de NMBS op te lossen zijn door privatisering. Door een grondige opkuis eventueel wel maar ik ben er van overtuigd dat je OV niet moet privatiseren omdat het mijn inziens een basisbehoefte is.

edit: in ik geloof 2022 worden andere privévervoerders toegelaten op het netwerk dus op dat vlak gaan we naar de Nederlandse situatie die volgens jou werkt (en waar ik niet genoeg van ken om over mee te spreken) maar dat heeft verder niets te maken met het al-dan-niet privatiseren van de NMBS wat m.i. dus een slechte zet zou zijn en de problemen niet per definitie zou oplossen of misschien net verslechteren.

[Reactie gewijzigd door Vnze op 22 juli 2024 15:49]

Ik ben zo blij dat er nog iemand denkt zoals ik, die niet zomaar privatisering roepen en daarmee denken dat alles opgelost is. Staatseigendom van de hand om snel centen te winnen maar uiteindelijk verandert er niets, en zijn de prijzen voor het publiek plots in handen van het kapitalistische marktsysteem, wat in de meeste gevallen geen gunstigheid is. Ik ben ermee akkoord dat openbaar vervoer een basisbehoefte is die gegarandeerd moet worden door de staat. Er is duidelijk iets mis bij NMBS maar daar moet door de leidinggevenden dan iets aan gedaan worden - en daar verandert privatisering niets aan.
Inderdaad! Ik ben ook heel blij dat er toch nog anderen zo denken. Ik heb enige tijd een abbo gehad op de treinen in Engeland, en daar was het niet beter dan in België en tegelijk was het duurder.
ja je hebt wel gelijk denk ik maar soort hybrid (met controlerende organen) lijkt me interessant

bij electrabel was het ook geen goed idee. Nog minder door te verkopen aan de Fransen.
Oei weer andere topic wrs ;)
Ypto is een dochter van de nmbs. Dit is dus geen private partij te noemen.
Weer een van die Belgen die zich graag in allerlei klaagzangen wentelt...

Kerel, ik neem ook elke dag de trein naar Brussel en heb een heel ander en veel positiever verhaal te vertellen over de NMBS en zijn dienstverlening, hoe zou dat toch komen denk je? Het lijkt er volgens mij eerder op dat jij de NMBS gebruikt als een soort zondebok voor je eigen negativiteit. Net zoals veel anderen helaas.

Veel plezier met je "kotsen" overigens, die woordkeuze verraadt ook wel een en ander over je ingesteldheid vind ik.
Misschien wel zo eerlijk zijn om jouw sample size = 1 te laten overeenkomen met zijn sample size = 1. Ik ben gestopt met de trein te nemen, ik woon altijd op lijnen waar ze met opzet psychiatrische instellingen langs bouwen (Geel, Mortsel, Duffel). Iets waar de NMBS niets aan kan doen, maar wat wel mijn beeld van “de trein is altijd een beetje reizen” wel kleurt. Net als hoe een staking waarvan de vakbond er maar niet in slaagt om duidelijk uitgelegd te krijgen waarom precies maar wel voor een record-file zorgt, de opinie beïnvloedt.

Ik ben blij voor jou dat jij een positieve ervaring hebt, maar dat wil niet zeggen dat iedereen blij moet zijn. Er zijn genoeg mensen die een shitty ervaring hebben of nog liever/beter elke dag uren in de file staan dan de trein te nemen. En die ondertussen wel meebetalen aan dit wanbeleid (want sorry, dat is het wel, misschien niet uniek in zijn soort, maar daardoor niet minder).

Niet dat ik vind dat ze de NMBS moeten privatiseren, dat zal niet helpen. Integendeel, ik zie in de privé ook genoeg slechte beslissingen genomen worden en geld verkwanseld. Afschaffen en autowegen van maken zou nog beter helpen, wij Belgen rijden toch met onze bedrijfswagen :) Alleen ligt dat op andere manieren dan weer gevoelig. Fietspaden dan maar ;)

Zoals altijd: waar zijn de verantwoordelijken? En stellen we die aansprakelijk? Zolang iemand andermans geld zomaar mag uitgeven en/of in je zakken stoppen en ermee wegkomen, zal er niets veranderen. En zal dit de publieke opinie voeden over bijvoorbeeld de NMBS.
Maar weeral een dochter die met een minimum aan in-house personeel moet draaien met een maximum aan uitbesteding en dus 'extern personeel'. Privé dus! Dat is het grote geheim dat de overheid probeert te verbergen en is de NMBS weer het zwarte schaap waardoor het publiek vol instemming zonder kennis verontwaardigd is als er weer gestaakt wordt. Ik heb nog geen dag gestaakt maar ben het volmondig eens met het protest van de vakbonden.
1.) Neem eens in een ander land de trein. Als je denkt dat een private trein altijd op tijd is en airco heeft heb ik nieuws voor jou!
2.) Kunnen we niet op de man spelen aub? Ik stem niet links en ik werk niet voor de NMBS. Ik heb wél in Engenland een abbo gehad voor de trein en wéét dus waar ik over spreek. Hou je aannamens voor jezelf.
Tof :) ik vind het heel leuk andere landen te kunnen vergelijken. Van welk land denk jij dat wij het meest kunnen leren? Positieve uitschieters zijn moeilijk te vinden helaas.

Vergis je trouwens ook niet tussen de trein te nemen om te pendelen en de trein te nemen voor een bezoekje. Als toerist neem je vaak IC's op kalmere momenten terwijl als pendelaar je eerder op de piekuurtreinen terecht komt. Dat is vaak moeilijk te vergelijken. Als je in Engenland rondreist als toerist valt het bv. allemaal goed mee maar probeer op de piek maar eens een trein in de thameslink te vinden zonder ridicule vertraging.
Ja, want ProRail is zo'n goed succesverhaal dat Schultz van Haegen-Maas Geesteranus Mansfeld Dijksma er een Zelfstandig BestuursOrgaan van gaat maken 7(8)7

[Reactie gewijzigd door RoestVrijStaal op 24 juli 2024 02:18]

Kijk maar eens goed hoe ProRail het doet het laatste jaar. Minder storingen en een directeur die gewoon een eerlijk verhaal vertelt. Dat de prestaties op de HSL bedroevend komt enerzijds door de TRAXX die de NS inzetten (niet geweldig betrouwbaar) en anderzijds doordat Infraspeed een contract van 30 jaar heeft om het onderhoud op de HSL te doen, waarbij ProRail niet eens een wissel mag verplaatsen/verwijderen/toevoegen.

Dat ProRail nu een ZBO wordt heeft niets te maken met hun prestaties, maar is een 100% politieke keuze, gemaakt door een ministerie dat al jarenlang weigert haar verantwoordelijkheid te nemen voor een goedwerkend spoor. Eerst doen ze jarenlang geen moer en ontstaan er flinke problemen, en nu NS en ProRail wakker geworden zijn worden ze alsnog gemuilkorfd.
..het raakt me volledige deze materie en het is idd een politieke keuze. Voor de machthebbers in Nederland en België is het woord 'openbaar' te veel aan het openbaar vervoer en door die keuze blijven vooral veel minder vermogende of milieu bewuste burgers in de kou staan.
want je hebt natuurlijk gemist dat dit project werd uitgevoerd doro Ypto, een private dochteronderneming.
staat niet in het artikel dat Ypto privaat is
Anoniem: 488958 @flieks13 oktober 2017 13:23
Maar dat is het wel :). Alleen is de NMBS invloed enorm, dus het fungeert niet echt als een privé onderneming.
Das de klassieke manier van de overheid om de anders geldende barema's te omzeilen. Met de normale barema's vang je geen IT'ers

Een Smalls leeft hier ook van.
Een overheidsbedrijf privatiseren is bijna altijd een dom idee.
Het kost meer en de service gaat achteruit.

Het probleem bij veel overheidsbedrijven:
- politieke inmenging (die soms extreem ver gaat)
- vast benoemde krokodillen die veranderingen tegenwerken
Anoniem: 85014 @flieks13 oktober 2017 14:31
De software wordt ontwikkeld door een private onderneming. M.a.w. het ontwikkelen erven is uitbesteed en dus geprivatiseerd.

Toch kunnen ze het niet.

Dat wil zeggen dat het bedrijf dat de ontwikkeling doet een aantal mensen, die nu nog denken dat ze het wel kunnen, moet ontslaan.
Anoniem: 890159 @flieks13 oktober 2017 12:19
Ja, dat heeft in Nederland ook zo goed gewerkt. Vooral voor het salaris van de topmanagers. 8)7
De NS is altijd eigendom van de Staat gebleven dus die “privatisering” was ook maar schijn. Niet dat het uitmaakt. Privatisering in een land als de UK is ook in een ramp uitgelopen.
Kijk alleen maar naar de ticket prijzen in het VK, echt totaal van de pot gerukt.
Anoniem: 156678 @lepel13 oktober 2017 12:51
ja, ik betaalde 50 pond (toen € 70) voor een trein ritje van 2 uur! Terwijl ik € 50 had betaald (enkele reis) van Brussel naar London (euro star).
Maar als je op het juiste moment boekt. Iets met de maanstand of zo kan het goedkoper ;)
Nee, er zijn zoveel variabelen in de prijs dat ook mensen in de UK het niet meer overzien en niet altijd het goedkoopste kaartje hebben omdat ze het gewoon niet weten.

Dan had je je Eurostar tickets wel goedkoop :)
Dat is nog een goede deal..
Als ik een retour Reading-London (minder dan een half uur) inclusief onbeperkt tube neem kost dat me ook full fare meer dan £50 :o
Anoniem: 981211 @lepel13 oktober 2017 12:51
Kijk alleen maar naar de ticket prijzen in het VK, echt totaal van de pot gerukt.
Zeker als je je bedenkt dat de kwaliteit die je krijgt voor dat geld echt wanstaltig is. Totaal niet in verhouding tot elkaar. En ik spreek uit ervaring, ik heb werkervaring in de internationale treinreis industrie.
Helemaal mee eens.. op mijn traject naar London moet ik 9 van de 10 keer staan omdat de trein te vol is..
Anoniem: 902873 @downtime13 oktober 2017 12:24
privatisering word ook in veel landen weer terug gedraaid. Daar is Polen een mooi voorbeeld van.
Nou is de Poolse overheid niet echt een lekker voorbeeld te noemen om als rolmodel te fungeren...
Nouja in de UK, IJsland, Italie, Ierland. Allemaal landen waar ze privatisering aan het terugdraaien zijn omdat ze hebben ontdekt dat het gewoon niet werkt. Zelfs hier in Oostenrijk draaien ze veel privatiseringen terug omdat het gewoon niet meer te betalen is.
Zijn ze in de UK de trein privatisatie aan het terugdraaien? Daar heb ik nog niks concreets van gehoord..
Enkel Network Rail is in handen van de staat, maar dat is geen geweldig voorbeeld van een goedlopend overheidsbedrijf (overheid zegt: hier heb je een zak geld, zoek het zelf maar uit). Het is 3 jaar in private handen geweest (als Railtrack plc), maar dat liep uit op een treinramp.

'The trouble with our trains' is overigens een goede documentaire over het Britse spoor - geeft naar mijn idee een evenwichtig beeld.
die ga ik even opzoeken, bedankt voor de tip :)
Anoniem: 902873 @ToolkiT13 oktober 2017 14:33
Ik heb NERGENS het woord trein en privatisering of terugdraaien in een zin gebruikt.
ah zo, je opmerking was meer algemeen dus? Ik dacht dat hij in context bedoeld was..
Privatisering van infrastructuur is wat mij betreft altijd een no-no.
misschien een gedeeltelijke privatisering dan ?
Met een sterk controlerend orgaan die bv ook de prijsplafond vastlegd..
bij de Post ging het wel goed.
Wat ging er goed bij de post?
- De dienstverlening werd uitgekleed (minder brievenbussen, sluiting van de postkantoren)
- De prijzen van postzegels zijn flink omhoog gegaan
- Postbodes zijn massaal ontslagen en vervangen door "postbezorgers" die slecht betaald worden

In België, met een staatspostbedrijf, zijn er gewoon nog postkantoren, zijn niet massaal postbodes ontslagen. Op het gebied van de prijs van postzegels deed België het altijd slecht, maar vanaf volgend jaar is ook een postzegel in België goedkoper dan in Nederland.
Als het aantal postkantoren en postbodes gelijk was gebleven had de postzegel inmiddels wel 5 euro kunnen zijn. Als ik steekproef=1 doe op mezelf, dan krijg ik nog geen tiende meer aan post in vergelijk met 10 jaar terug, vrijwel alles gaat digitaal. Ik verwacht niet anders dan dat er alleen pakketpost overblijft en dat het tarief voor een envelop gelijk gaat komen met het brievenbuspakketje...

En voor de duidelijkheid: dat heeft dus allemaal niets te maken met de privatisering, maar met de digitalisering.
Als je één postbode hebt die door, laten we zeggen 50 straten post bezorgt, is dat veel efficiënter als dat er 4 postbodes van PostNL, Sandd, Van Straaten Post en Business Post dezelfde 4 straten moeten aflopen. Je kunt het daarom niet uitsluitend op de digitalisering afschuiven, de privatisering heeft er wel degelijk een rol in.
right, merci voor de info
Je haalt denk ik twee zaken door elkaar. De NS is geprivatiseerd maar niet verkocht. Dat betekent bijvoorbeeld dat NS medewerkers geen ambtenaren meer zijn, maar gewone werknemers. In het algemeen valt de NS nu onder het normale privaatrecht, en niet onder speciale wetgeving.

In het VK is de ramp dat er lijnen openbaar zijn aanbesteed, zonder dat er bij de aanbesteding harde eisen zijn gesteld aan de kwaliteit van de dienstverlening. Dat is iets compleet anders als privatisering en staat er los van. In Nederland hebben we dat ook gedaan voor een aantal kleine verbindingen (niet hoofdnet), en hier is de aanbesteding wél een succes. Reizigerstevredenheid is sterk gestegen op de lijnen die niet meer door NS worden gerund.
Bedankt voor de toelichting maar ik haalde geen dingen door elkaar. Ik was alleen maar kort door de bocht. Da’s niet hetzelfde :)
In Nederland hebben we dat ook gedaan voor een aantal kleine verbindingen (niet hoofdnet), en hier is de aanbesteding wél een succes. Reizigerstevredenheid is sterk gestegen op de lijnen die niet meer door NS worden gerund.
Nou nee, je moet steeds in- en uitchecken wanneer je van vervoerder wisselt, en dat is gewoonweg behoorlijk onlogisch & irritant. Zeker wanneer je fout bent ingecheckt. Als je geluk hebt zijn ze coulant, als je pech hebt krijg je de boete. Nou kun je die eens in de 6 maanden aanvechten maar dan nog.

Verder zou het hele uitchecksysteem onnodig zijn wanneer er een failsafe met GPS ingebouwd zou worden die gewoon automatisch uitcheckt. Dwz: wanneer iemand meer dan 15 minuten op dezelfde lokatie zit, dan is hij opzeker uitgecheckt. Heeft hij niet uitgecheckt, dan kun je dat aangeven middels een pushnotificatie. Probeert hij in te checken bij de bus van vervoerder X, dan is hij vergeten uit te checken bij vervoerder Y en moet het systeem dat even handmatig doen. Telefoons met GPS die niet geroot zijn, zouden een prima alternatief kunnen zijn.
De NS is altijd een NV in handen van de overheid geweest. Er was privaatrecht van toepassing. Het personeel is nooit ambtenaar geweest.

Alleen denkt iedereen dat, omdat het tot 1994/1995 het alleenrecht had op het spoor en de lijntjes korter waren.
FYI: Wat met de NS is gebeurd noemt men 'verzelfstandiging'. Het is een tussenstap in een traject waarbij een overheids organisatie eerst wordt verzelfstandig, waarna het verkocht kan worden.

We mogen God op onze knieën bedanken dat onze politici dat toen niet hebben gedaan. Iedereen die ooit in een land met volledige spoorprivatisatie heeft gewoond (VK) kan dat bevestigen.

[Reactie gewijzigd door ApexAlpha op 24 juli 2024 02:18]

Moeten we dan niet eerst weer "iets" vinden, om te kunnen zeggen dat het de schuld van de vakbonden is dat dit systeem niet werkt?

Ik persoonlijk denk eerder aan minder vriendjespolitiek aan de top. En meer competentie.

Allemaal managers, en geen een die verstand heeft van treinen/spoor, of van transport van personen, of zelfs van het leveren van service.
Met privatisering werken er nog steeds dezelfde mensen die dit gezamenlijk hebben laten ontsporen :+
Goed idee!
In een infrastructuur-deel.
En een reizigers-deel.

Hé, eigenlijk zoals onze oude NS!
Als het een eindeloze put is, dan is het beter het stop te zetten. Beter 30 miljoen in de goot dan 60 !
Maar vreemd genoeg (?) lees je toch vaak dergelijke zaken.
Is de IT-sector incompetent?
(Onze ervaring hier op het werk is ook niet zo fantastisch met bedrijven die 'software' maken.)

[Reactie gewijzigd door catfish op 24 juli 2024 02:18]

Is de IT-sector incompetent?
Wat mij betreft in zekere zin wel. Er is een algemeen kwaliteitsprobleem in de informatica.

Enerzijds is dat het personeel: In de informatica is het sinds jaar en dag het probleem dat de vraag naar programmeurs groter is dan het aanbod. Hele volkstammen biologen, economen, boekhouders, misschien zelfs kappers hebben een cursus programmeren gekregen en mogen zich sindsdien programmeur noemen. Bij programmeren is het evenwel zo dat kunnen programmeren niet betekent hoe je kunt programmeren. De kwaliteit zou er flink op vooruit gaan als geschoolde informatici ingezet zouden worden in plaats van omgeschoolde IT'ers.

Een ander probleem is de kwaliteit van de informatica zelf: Onder druk van de industrie is vaak overgeschakeld op hulpmiddelen die helemaal niet zo goed zijn. Het vele gebruik van Java is bijvoorbeeld vanuit technisch oogpunt amper te verantwoorden, laten we het niet hebben over technisch draken van talen als PHP die vragen dat software met bugs erin geschreven wordt.

Ik zie ook een probleem in de het idee dat in de IT-wereld leeft dat je programmeurs zelf niet in dienst moet nemen, maar inhuren in India. Automatiseringsproject staan of vallen bij programmeurs die zich goed kunnen inleven in de praktijksituatie om in te zien welke praktische uitdagingen de software zal tegenkomen. Hoe dichter de programmeurs op de praktijk zitten, hoe groter de kans dat de programmatuur praktisch te gebruiken zal zijn. Zet je ze weg in een ver land, dan kun je er vergif op innemen dat praktische problemen ontstaan. Nog even afgezien dat het personeel in verre landen lang niet zo kundig is als vaak beweerd wordt.
[...]
Enerzijds is dat het personeel: In de informatica is het sinds jaar en dag het probleem dat de vraag naar programmeurs groter is dan het aanbod. Hele volkstammen biologen, economen, boekhouders, misschien zelfs kappers hebben een cursus programmeren gekregen en mogen zich sindsdien programmeur noemen. Bij programmeren is het evenwel zo dat kunnen programmeren niet betekent hoe je kunt programmeren. De kwaliteit zou er flink op vooruit gaan als geschoolde informatici ingezet zouden worden in plaats van omgeschoolde IT'ers.
Over de kwaliteit van de opleiding valt inderdaad wel iets te zeggen, een bachelor/master beschikt normaal over iets betere bagage. Wat ik hierover wel wil toevoegen is het volgende: het zegt niets over de technische competentie van de persoon. Bovendien, welke schoolverlater schrijft al eens geen slechte software in z'n jonge carrière? Ook na het verlaten van de schoolbanken zal je jouw kennis moeten blijven bijschaven, een leve lang leren. Er moet dus zeker ook gekeken worden in welke zin iemand kan groeien en afhankelijk daarvan de gepaste taken aan deze persoon te geven, en de nodige opleiding+tools voorzien om deze taken tot een goed einde te brengen.
IT'er is een knelpuntberoep en dat wil zeggen dat er heel wat mensen zijn die deze leegte kunnen invullen. Digitalisering wil ook zeggen: hervorming van de arbeidsmarkt! De omgeschoold kapper is misschien niet in staat om kernel drivers te schrijven, maar kan bijvoorbeeld wel kwalificeren om unit tests te maken.
Een ander probleem is de kwaliteit van de informatica zelf: Onder druk van de industrie is vaak overgeschakeld op hulpmiddelen die helemaal niet zo goed zijn. Het vele gebruik van Java is bijvoorbeeld vanuit technisch oogpunt amper te verantwoorden, laten we het niet hebben over technisch draken van talen als PHP die vragen dat software met bugs erin geschreven wordt.
Er is genoeg goeie software die leunt op de Java-taal en al z'n mogelijk implementaties. Het is de programmeur die de bug schrijft, niet de taal. Bovendien is er niet één taal die alles kan zoals je het altijd had gewild!
Je hebt zeker gelijk dat iedereen in het vak slechte software geschreven heeft. En ik zou het, als programmeur, nog een stapje verder willen nemen door te stellen dat iedereen nog steeds wel eens slechte software schrijft (ikzelf inclusief). Je moet gewoon onderkennen dat iedereen wel eens een slechte dag heeft, onder druk staat, of gewoon iets over het hoofd ziet. En juist daarom is het zo belangrijk om geen hoekjes af te willen snijden maar wél je unittests te schrijven en te runnen, wél al je commits te peer-reviewen, wél nightly builds te hebben én te testen met (gui) tests en in het algemeen wél een omgeving te hebben waarin aandacht en tijd is voor het (elkaar) leren van (nieuwe) technieken, mentoring en waarin constructieve feedback op waarde geschat wordt.
De zaken die je noemt zijn kwesties die gevolgen hebben voor de kwaliteit van de implementatie. Laten we het beestje bij de naam noemen: De kever, oftewel bugs. Een automatiseringsproject loopt echter over het algemeen niet stuk door bugs. Bugs zijn uit een programma te halen.

Een automatiseringsproject loopt eerder stuk doordat het niet om kan gaan met situaties die in de praktijk optreden, het ontwerp van het systeem niet goed op die situaties voorzien is en omdat het ontwerp van het systeem niet eenvoudig aan te passen is, met knip- en plakwerk de boel provisorisch werkend gekregen moet worden. En als dat na een paar jaar niet gelukt is, dan moet de stekker eruit.

Juist op het gebied van een goed ontwerp kan een geschoold informaticus zijn meerwaarde bewijzen: Hij heeft inzicht in hoe hij de onderliggende infrastructuur van het systeem flexibeler kan maken, meer inzicht in hoe hij een systeem snel en schaalbaar maakt en is beter bewust van valkuilen in projecten.

Het gaat niet om een slechte dag of een keer slecht programma hebben geschreven. Bugs horen erbij en met de juiste procedures zijn die goed te ondervangen.
Het probleem is in België dat heel wat project managers die werken voor software ontwikkeling bedrijven die als hoofdklant een defacto-overheidsbedrijf hebben, geen tot zeer slechte procedures hebben.

Het idee dat iets moet getest worden alvorens je gaat opleveren is hen voor een groot deel vreemd. Het is beter om gewoon te liegen dat iets afgewerkt is, het opleveren vol fouten. Dan met allerlei politiek, zever en gedoe de executie zo lang mogelijk uitstellen in de hoop dat de programmeurs het ineens toch af hebben. Dan lever je dat op in één van de zovele bugfix releases in de hoop dat de klant het niet gemerkt heeft. Falen is de default. Lukken gebeurt zelden of nooit.

Disclaimer: ik ben (als freelancer) release maintainer (en eigenlijk ook hoofdontwikkelaar - degene die alle shit moest oplossen) geweest bij een Belgisch software huis dat voor een Belgische vervoersmaatschappij software schrijft. M.a.w. ik ging de software installeren en ik stelde alle modules samen tot een release.

Ik ben er weg gegaan omdat project management beslissingen nam waar ik professioneel me niet kon achter zetten. En dus waarvan ik niet wil dat ik er iets mee te maken heb (professioneel niet).

Merk op dat ik een referentie heb op mijn CV van de verantwoordelijke voor software bij die vervoersmaatschappij. M.a.w. mijn bijdrage daar ter plaatse werd geapprecieerd. Maar dat vond onze project manager niet leuk. Want door goed release-beheer toe te passen (m.a.w. semver), kon hij niet meer liegen. M.a.w. eerlijk zijn tegen de eindklant was niet in het belang van mijn PO. Dus dan ben ik weg.

[Reactie gewijzigd door Anoniem: 85014 op 24 juli 2024 02:18]

Er komen vaak ook nog spelletjes tussen. De project manager en enkele coders zijn huurling van bedrijf A en een paar andere coders zijn huurling van bedrijf B. Koude oorlog tussen die twee bedrijven die elkaar de loef willen afsteken om de volgende keer de positie van iemand die bij het andere bedrijf werkte te kunnen vullen.

Tel daarbij de lachwekkende NMBS-omgeving en je moet al echt enorm veel geluk hebben dat je een gedreven kerel of dame vindt MET kennis die wat aan je project komt werken.

Met die omgeving bedoel ik onder meer:
-geen sancties wanneer je (herhaaldelijk) niets oplevert, hoogstens wordt je naar een ander project geschoven
-tendens om de kantjes er af te lopen: valsspelen met de prikklok; geen management: geen werk; ...
-zelfs teamleaders kan het niet schelen of je al dan niet werk hebt. Zo lang ze maar genoeg mensen onder zich hebben om belangrijk genoeg te zijn

En na enkele dagen neem je die mentaliteit volledig over. 8)7
Precies. Wat jij beschrijft komt helemaal overeen met wat ik daar meemaakte. Machiavelliaans gedrag tussen consultants. Interne mensen die letterlijk geen klop uitsteken en alles op de externen steken. Interne project managers die na vele jaren met Peters Principle gepromoveerd zijn tot hun niveau van incompetentie. Alles op de klant steken. Wanneer de klant vraagt om precies te documenteren hoe de installatie dan wel juist moet gebeuren, dan was dat totaal onlogisch en ongezien volgens de project manager. Nochtans heb ik (als freelancer die dus bij vele bedrijven al was) nooit iets anders meegemaakt; geen documentatie betekent oprotten.

Sterker, het ontbreken van documentatie werd tegen de klant gebruikt om telkens te beweren dat hij de installatie fout had uitgevoerd. Dus na een tijd werd ik dan gestuurd om het juist te doen (de klant wilde niet meer zelf installeren, wat ik volledig logisch vond). Dus ik begin alles te documenteren tijdens installatie en samen met de klant. Dat vond de project-manager onnozel en tijdverlies en weet ik veel wat (ahja, want dan kon hij dat niet meer tegen de klant gebruiken). Het introduceren van versie-nummers die zinnig zijn (zoals eerder vermeld, semver) was ook ongehoord en dit en dat (want dan konden wij geen binarie zo eens ineens wijzigen en was alles traceerbaar, en dus dan kon hij niet meer liegen tegen de klant).

Eigenlijk was alles leugenachtig, bullshit en belachelijk en had de klant eenvoudigweg altijd gelijk dat wat wij kwamen opleveren een onnozel zootje was.

Zoals ik al zei mocht ik altijd de shit (gaan) oplossen. Maar na een tijd heb ik het voor bekeken gehouden. Daarna is de boel overgenomen geweest door een bedrijf en ik heb vernomen dat die project-manager nu project-manager af is. Maarja de schade die hij heeft aangericht, is aangericht.
Voor de anecdote:

-een van de eerste dagen werd mij verteld dat ik X nodig had om mij de backend uit te leggen van het project (was nog op mainframe). Ik bel die kerel herhaaldelijk om te zien wanneer hij vrij is, neemt niet op. Die zat gewoon aan zijn bureau. Ik vraag hem waarom hij niet opnam: ah ja ik was net met iets bezig |:(

-kerel die herhaaldelijk de namiddag "op missie" ging en eigenlijk gewoon op cafe ging hangen. Dan om 16u de laptop komen halen en naar huis. Ofwel niet uitklokken en dus betaald worden tot 18u. Na verschillende keren betrapt te zijn is die gewoon overgeplaatst.

-ook "de pornoman" is na uitvoerig bewijs van de IT dienst gewoon overgeplaatst. Dit was echter net voor mijn passage dus dit kan ik niet zeker weten.

-deur openbreken (slot kapot en dus een buitendeur die niet meer dicht ging) omdat ze in het ander gebouw wel mochten gaan roken zonder uit te klokken :X
Er wordt mijns inziens veel te veel gefocust op de technische kennis van een persoon.

Ja, uiteraard moet een developer goede code kunnen schrijven, maar dat is maar één deel van het verhaal. Je kunnen inleven in een gebruiker, logisch kunnen redeneren, kunnen communiceren (!!) en allerlei andere "soft skills" zijn minstens even belangrijk. Opleidingen focussen daar vaak maar deels op, waardoor veel IT'ers nog altijd halve zombies zijn. No offence trouwens tegenover mijn collega's :).
Als de Super AI er komt dan is het gedaan met de speeltijd..... en wie weet mss wel met de mensheid ook :)
[...]
laten we het niet hebben over technisch draken van talen als PHP die vragen dat software met bugs erin geschreven wordt.
Als je dit nog steeds als argument aanhaalt, zou ik je willen aanraden om de huidige status van PHP eens te bekijken. Die is namelijk de afgelopen tien jaar sterk verbeterd ten opzichte van PHP4, waar je stelling zelfs ook maar deels op van toepassing is...

Probleem is domweg dat de personen die software moeten bouwen simpelweg bar weinig te zeggen over WAT ze moeten maken en HOE. Je kunt als programmeur simpelweg weigeren iets te maken zoals een 'manager' het heeft gedefinieerd, maar dan gaat diezelfde manager doodleuk naar de volgende toe, die het wel maakt zonder te mekkeren. Probleem blijft: de plannen, ideeën en concepten worden uitgewerkt door mensen zonder kennis van zaken. Zolang dat zo blijft, blijven dit soort situaties bestaan.
Ik vind PHP nog steeds knudde, ook al zijn de ergste ziektes eruit. Wat je beschrijft over onmacht van programmeurs zou je ook kunnen classificeren als een kwaliteitsprobleem in de informaticawereld en een reden waarom de sector incompetent is. Het sluit dan uitstekend aan bij mijn verhaal.
Nog even een onderbouwing waarom ik problemen met PHP heb, vanuit informaticatheoretisch oogpunt bekeken: De manier waarop het web werkt, doordat bij iedere tussenstap een HTML-document opgestuurd wordt en d.m.v. een formulier of gewoon link de volgende stap op de server wordt aangeroepen, moet bij iedere tussenstap een veiligheidscheck plaatsvinden. Een hele elementaire veiligheidsstap is typering van de variabelen: Is een numerieke HTML-formuliervariable ook daadwerkelijk numeriek?

Daarom leent het web zich voor sterk getypeerde talen. Je zou dus als je een taal voor webprogrammering ontwerpt dan ook kiezen voor een taal met sterke typering. PHP is een taal zonder typering, of in ieder geval oorspronkelijk een taal zonder typering. Rasmus Lerdorf was geen informaticus, dus tja, wist de man veel dat dat geen handige keuze was... Met enorme economische schade en veiligheidslekken tot gevolg.

Uiteraard zijn de mensen die PHP programmeren inmiddels ook wijs geworden. Ze hebben, rijkelijk laat overigens, wat functies voor sterke typering toegevoegd. Maar dat er wat voorzieningen mogelijk zijn gemaakt, betekent niet dat die ook gebruikt worden. De grote massa rommelt gewoon aan net zoals voorheen. Met als gevolg nog steeds veel websites die problemen kennen die gewoon te voorkomen waren geweest als men de juiste taal had gebruikt.
Dus je stelling is dat webontwikkeling met ASP.NET en C# beter is? Want dan gebruik je een type-safe taal i.p.v. Ducktyping.

Nuja, ik heb toch veel geklooi al gezien van ASP.NET ontwikkelaars die ook tal van SQL-injection fouten maakten. En als men van alles een string maakt, dan kan je daar alles in stoppen he. Dat doen die webdevelopers dus dan ook heel vaak. Ach ik heb er zelfs al C# code en XML (die geinterpreteerd wordt en uitgevoerd) in relationele databases zien stoppen "omdat het kan". Ze gebruikten ook geen XML writer om die XML bij elkaar te concateneren. Want hun eigen code "was beter".

Kort: prutsers zitten er overal. En de prutser zit in het manneke, niet in de programmeertaal.

[Reactie gewijzigd door Anoniem: 85014 op 24 juli 2024 02:18]

Ik denk inderdaad dat gebruik van die talen een hoop ellende bespaard zou hebben, echter is de populariteit van PHP t.o.v. die talen wel te begrijpen i.v.m. de leercurve die hoort bij objectgeoriënteerde talen en extra handelingen tijdens het programmeren die gepaard gaan bij gecompileerde talen. Je zou dus een sterk getypeerde scripttaal willen nemen of, in het geval van PHP, hebben willen ontwerpen.

SQL-injecties zijn ook te ontmoedigen vanuit de toolkit door gewoon makkelijk te gebruiken faciliteiten te bieden voor queries met parameters.

Knoeien kan natuurlijk altijd en wat mij betreft moet dat ook mogelijk zijn, een programmeur die weet wat hij doet moet niet door een toolkit in de weg gezeten worden. Het gaat erom dat de toolkit niet uitnodigt tot het maken van triviale fouten, daarmee kan een hoop ellende voorkomen worden.
Dan is C++ de perfecte taal voor je. Ze leunt (erg) sterk op type-safety. De betere programmeurs kunnen a.d.h.v. RAII technieken vermijden dat er zelfs maar nood is aan een garbage collector (en dat doen ze ook). De leercurve is behoorlijk hoog. Maar je kan er absurd onnozel hard mee in je eigen voeten schieten. En een prutser die met C++ werkt, zal ook echt gepruts opleveren dat constant crashed en fout gaat. Dus dat is ideaal om het kaf van het koren te scheiden. Prutsers overleven dan ook meestal niet lang in de wereld van C++ programmeurs.

Voorts heb je als populaire toolkits oa. boost, std en Qt en voor de C mensen GLib en Gtk+. Je kan dus kiezen! :-)
Geen string als ingebouwd datatype, daarmee fundamenteel ongeschikt voor het web, waarbij alles nu eenmaal om tekst draait.

Inderdaad wellicht een goed middel om prutsers af te vallen, die logica volg ik, maar in het verhaal wat ik hier neerzet, zijn prutsers en slechte hulpmiddelen twee zijden van dezelfde medaille: een belangrijke oorzaak dat we zoveel prutsers hebben, dat we geen vakmensen inzetten, maar iedere zonderling die een programmeercursus kan volgen.
We kwamen er net op uit dat strings overal gebruiken nefast is voor type-safety! Daarbij, je hebt std::string, QString en GString. Keuze zat. Of dacht je dat System.String in .NET niet in de toolkit (System.*) zat? Toegegeven heeft C# nu ook wel een value type achtige 'string' die vermoedelijk in de taal gebakken zit met een paar speciale boxing regels (wat het er niet eenvoudiger op maakt). Maar dus in de meeste talen is het type string niet iets dat in de taal zit, maar wel bij de standaard toolkit. C++ heeft meerdere toolkits, dus kan je kiezen tussen meerdere string typen. Merk ook op dat "string" niet altijd eenvoudig is als je je code Unicode correct wil maken. M.a.w. de char* in C en string.h zonder een Unicode library zoals ICU, is gewoon los fout 95% van de gevallen waar je Unicode wil. Maarja, dat weten de meeste novice programmeurs allemaal niet. Bij elkaar harken die boel! Dat andere talen bestaan weten we niet, dat andere sorteervolgorden bestaat ook niet. Dat ander karacktersets bestaan ook niet. De Chinezen kunnen de pot op met hun rare taaltje.

Je hebt wel gelijk dat we door we beginnelingen opzadelen met slechte tools, we slechte beginnelingen kweken. En dat er voornamelijk slechte beginnelingen in onze markt zitten. Die zelfs op youtube tegenwoordig liggen kabaal maken dat ze het allemaal beter weten in slechte beginneling te zijn.

ps. Het valt me ook al jaren op bij welke automerken hun dashboardsoftware de MP3tjes totaal verkeert sorteren. Daar werken dus de prutsers die niets van Unicode kennen (als maintainer van het metadata systeem van GNOME, de Jolla en de N9, Tracker, weet ik uiteraard wel hoe je die metadata wel Unicode-technisch juist uit die muziekbestandjes krijgt).

[Reactie gewijzigd door Anoniem: 85014 op 23 juli 2024 23:49]

Dat strings overal voor gebruiken geen goed idee is, dat staat nog steeds, maar een taal zonder strings is bij het werken met tekstuele documenten ook niet handig. Ja, er is std::string, maar:
  • Dan komt de STL om de hoek kijken, leerurve omhoog
  • Debuggers ondersteunen doorgaans alleen ingebouwde datatypen
Ik denk dat als je een webpagina in C++ bouw, als cgi-script bijvoorbeeld, dan je aan de broncode alleen al snel kunt zien dat één en ander niet productief is. Dát is de reden waarom een tool als PHP populair kon worden. Het was productief, zo simpel als dat.

Wat je wilt is een scripttaal gebouwd voor webprogrammering met sterke typering, her en der is daar ook wel wat voor te vinden, maar niets dat op grote schaal gebruikt wordt. PHP zit erg sterk in het zadel met alle bibliotheken, voorbeelden en documentatie die ervoor geschreven is.
Weinig scripttalen hebben een deftige debugger natuurlijk, en voor GDB kan je bv. dit gebruiken om std containers te ondersteunen. In QtCreator zijn dan weer Qt typen zoals QString prima ondersteund.

Wat ik je hoor zeggen wat je wil noemt ASP.NET met C# als programmeertaal en Visual Studio .NET als ontwikkelomgeving. Maar toch wordt dat niet zo vaak gebruikt..

ps. PHP wordt ook al maar minder gebruikt. Van ASP.NET vind ik dat raar, want het grote probleem met de hele .NET wereld was de Windows-only visie van Microsoft. Dat is nu met de nieuwe CEO van Microsoft, die het helemaal niet erg vind om .NET te ondersteunen op bv. Linux (m.b.v. Xamarin en Mono en zo), helemaal veranderd. Dus ik had een enorme toename van .NET verwacht. (Want laten we eerlijk zijn, Windows op servers draaien? Dat zal zeker niet iedereen willen doen).
Bij programmeren is het evenwel zo dat kunnen programmeren niet betekent hoe je kunt programmeren.
Ik vergelijk het graag met schrijven. Op de basisschool leer je in groep 3 "schrijven". Daar leer je met een pen inkt over het papier te wrijven. Op de middelbare school leer je bij Nederlands weer "schrijven". Daar leer je gestructureerd een tekst op te bouwen en je gedachtes begrijpbaar op papier te zetten. Na 10 jaar schrijfles kunnen de meeste mensen het een heel klein beetje.
Als je van schrijven je werk wil maken, bv als journalist, vertaler, columnist of romancier, dan ben je er nog lang niet en moet je nog jaren oefenen om echt goed te worden.

We noemen het allemaal "schrijven". Niemand lijkt te beseffen dat een kleuter die net z'n eigen naam kan schrijven geen Gouden Griffel gaat krijgen voor zijn werk.

Je merkt het ook aan hoe we over programmeurs praten. Voor de meeste mensen is taal een gereedschap, maar niet meer dan dat. Of een onderzoeksjournalist zijn bevindingen opschrijft in het Nederlands, Duits of Engels maakt weinig uit. Natuurlijk zijn er verschillen tussen die talen, maar principes als hoe je een tekst structuur geeft en hoe je een argument presenteert staan daar los van. Die zijn belangrijker dan de taal zelf.
Het minst interessante aspect is op een bepaalde manier in welke taal je schrijft en wat voor inkt je daar voor gebruikt. 95% van schrijven gaat verder dan dat. Als je een advertentie voor een programmeur ziet staan gaat het echter altijd over de programmeertalen die nodig zijn.
Ik zie ook een probleem in de het idee dat in de IT-wereld leeft dat je programmeurs zelf niet in dienst moet nemen, maar inhuren in India.
Uitbesteden doen we omdat het goedkoper is. Weinig verbazend dat het de kwaliteit niet ten goede komt. Omdat mensen IT niet kunnen beoordelen wordt er echter nooit naar kwaliteit gekeken, alleen maar naar prijs. Gebruikers accepteren het want ze weten niet beter dan dat IT vervelend is en vol fouten zit. Tegen de tijd dat duidelijk wordt dat deze software nog slechter is dan gemiddeld is het contract al weer voorbij, en anders verschuilt de aanbieder zich wel achter een SLA.
Het is een combinatie van een aantal factoren:
- Overheiden kiezen hun partij via een aanbesteding en kiezen hierbij (meestal) de goedkoopste partij. Kwaliteit kost ook geld.
- Onrealistische eisen
- Te laat de stekker eruit trekken
veranderen/toevoegen van eisen na de aanbesteding wil ook "helpen". Bijvoorbeeld de eis dat men met NFC moet kunnen betalen terwijl dat bij de aanbesteding nog niet speelde...
Lekker realistisch om nu te voorspellen wat er over de komende 5 jaar allemaal nodig zal zijn, en dat zo op die manier te beschrijven in je RFP dat de aanbieder perfect weet wat ie moet bouwen.
Daarom moeten projecten ook zodanig worden opgezet, dat er een einddatum aan zit, die realistisch is. Ontwerp: komende jaar. Testen: jaar daarna. Oplevering: kwartaal na testen. Doorlooptijden van 5 jaar en meer zijn belachelijk: dan komt er nooit meer iets van de grond.
Verder: duidelijke afspraken. Wat wordt waar, wanneer door wie op welke manier geleverd. Aanpassingen aan het ontwerp? In overleg, in uiterste noodzaak. Afwijkingen van de aanbesteding? Nee. Zelfs niet tenzij...
Dit soort projecten moeten ook worden opgezet met een "Need to have"(wat is per se noodzakelijk), "Nice to have" (wat is leuk om erbij te hebben) en "want to have" (leuk, maar eigenlijk alleen maar dat: leuk). Daarmee kunnen de eisen ook SMART (jeukwoord) gemaakt worden: de Need-to-haves zijn beschreven in de aanbesteding en moeten onvoorwaardleijk op de afgesproken datum opgeleverd worden. Alles wat daarna aan aanvullende eisen/wensen komt is blijkbaar een Nice to have of Want to have en niet belangrijk. Want waren ze wel belangrijk geweest, waren ze wel beschreven in de aanbesteding.
En ja, dat zal soms pijn doen als manager x bedenkt dat hij vergeten is om ... mee te nemen in de aanbesteding. Maar op die manier voorkom je dat projecten volledig ontsporen.

Helaas zijn contracten nooit 100% waterdicht en is het verloop op management-niveau bij veel bedrijven nogal hoog. En van managers is bekend dat ze graag hun plasje willen doen over projecten. En hoe groter het project, hoe groter de aandrang om een plasje erover te kunnen doen. Leveranciers luisteren maar wat graag: iedere aanpassing betekent "kassa!" en een goed excuus om het project te vertragen (dus meer mensen langer aan het werk, wat weer meer opbrengsten betekent).
Daarmee kunnen de eisen ook SMART (jeukwoord) gemaakt worden
Ahh u heeft ook zo'n manager gehad :+
Waren het geen zeemeeuwen, rond fladderen en hier en daar de boel ondersch..ten..... :+
Dan geef je dus direct toe dat de IT-sector incompetent IS.
We leven niet meer in de jaren '60: de wereld evolueert snel. Zeer snel.
Wie vandaag nog software bouwt die niet modulair is zodat er eenvoudig en snel zaken kunnen toegevoegd worden is gewoon incompetent.

Zelf heb ik nog maar 1 keer de ontwikkeling van een pakket van dichterbij meegemaakt en het was overduidelijk dat de 'analist' totaal geen idee had waarmee ze bezig was. (Ik hoopte dat het een alleenstaand geval was.)
Dan geef je dus direct toe dat de IT-sector incompetent IS
Nee, dat is jouw interpretatie gebaseerd op jouw verlangen te horen dat het zo zou zijn.

Ja, de wereld evolueert snel. Maar nee, het feit dat er vandaag iets verandert betekent niet dat we morgen meteen al alles hebben gebaseerd op wat er vandaag verandert. We hebben elektrische auto's, weten dat we daar over 20 jaar allemaal in zullen rijden, maar morgen, volgende week en zelfs over 5 tot 10 jaar zullen er nog volop benzinepompen zijn. Zelfde geldt voor de ICT: het fet dat er vandaag een project wordt uitgeschreven, betekent niet dat morgen de software klaar is. Laat staan dat de aanpassingen die volgende week bedacht worden nu al mee geprogrammeerd kunnen worden.

Wie vandaag nog software bouwt die niet modulair is zodat er eenvoudig en snel zaken kunnen toegevoegd worden is gewoon incompetent.
Daar ben ik het met je eens.
Zo'n betaalterminal-type toevoegen is iets dat je bv. Atos Worldline laat doen. Zij leveren daar APIs voor aan die doorgaans niet moeilijk zijn om in een bestaande omgeving te integreren.
Alleen is dat hier minder van toepassing. Ypto is een dochteronderneming, maar is geen overheidsbedrijf. De mensen die er werken, werken dan ook niet onder een overheidsstatuut en ze zijn ook niet gebonden aan dezelfde regels wat betreft aanbestedigin. Doordat ze een private onderneming zijn hebben ze ook minder last van het gebrek aan competenties aangezien ze gewoon de juiste mensen kunnen aannemen.
ook wel je kan jezelf icter noemen en meer salaris eisen maar of je het verdient is een tweede...
Je mag zeker zijn dat dit project volledige door consultants is ontwikkeld. ;)
Voeg daar ook nog eens aan toe:
- Eisen onduidelijk geformuleerd
- Geen tussentijdse opleveringen met duidelijke eisen
- Te veel mensen die zich er mee mogen bemoeien
- Eisen die tijdens de ontwikkeling worden aangepast (een goudmijn voor de ontwikkelaar)
Dat is zeker waar.
Vergeet ook niet de steeds maar wisselende eisen van de opdrachtgever! Dat is waar de softwarebouwers het veelal op gooien.

Hoewel dat waar is/kan zijn, moet je als softwarebouwer hier dan ook goed sluitende afspraken over maken mijns inziens.
Sabic tenderdienst, bijvoorbeeld, schrijft maar uit op één ding en dat is prijs. Je hoort iedereen schreeuwen over kwaliteit maar uiteindelijk is prijs gewoon het enige dat echt van belang is.
Nee, management die zich bemoeid met de ontwikkeling van systemen en na een tijdje toch weer overstappen naar een andere partij omdat deze 'wel luistert'. IT is not to blame, maar de de top die er verstand van schijnt te hebben.
IT is not to blame, maar de de top die er verstand van schijnt te hebben.
Daar ben ik het volledig mee eens. Als IT'er moet je luisteren naar de eisen en wensen van de klant, welke niet altijd makkelijk is. Daarnaast speelt geld ook een grote rol, het mag niet veel kosten van de management. 30 miljoen euro is best veel en daar kan je wel een goede systeem voor bouwen. Maar goed, ook in Nederland kennen we verschillende projecten die gefaald zijn en/of half werken.
Ik kan met nog goed herinneren toen de OV-chipkaart werdt geïntroduceerd, wat een ramp zeg, nu nog steeds eigenlijk. Voordat ze beginnen met iets te bouwen, vraag eerst aan de mensen die er mee gaan werken, vooral als er tig mensen het gaan gebruiken. Het concept mag dan wel bestaan, maar probeer de concept dan ook te volgen, houdt het makkelijk voor de mensen die het gebruiken.

Maar zoals met bijna elke project, kom je over je budget heen, want tijdens de realisatie wil management ook nog functie x en y er bij hebben. Daarnaast is het ook heel veel troubleshooten tijdens de realisatie en dat kost ook heel veel tijd. Maar goed, testen neemt heel veel tijd in, vooral bij zo'n grote project, dus ik kan het wel begrijpen dat ze het annuleren, wel zonde van de 30 miljoen...
30 miljoen moet je niet als zakgeld zien, er is niet 'ergens' iemand mee gaan lopen.
Elk poppetje en apparaat in de keten moet gewoon betaald worden.
Het gaat over een compleet overkoepelend systeem, logisch dat daar een kostenpost aan hangt.
Hoe veel het ook voor een persoon is, om te zien, is 30 miljoen gewoon een 'eenvoudige' afschrijving.

Tja en zonde van de 30 miljoen, er hebben in ieder gevaal een aantal mensen weer iets geleerd, en ervaringen opgedaan.
Die zijn niet verloren, die kan je uiteindelijk nog gebruiken in de toekomst

Je kan dit verhaal niet zonder nuance zien, niet in de 30 regeltjes van het persbericht
Er is zelden één schuldige in zo'n situatie.

Ja, je kan zeggen dat je als ITer gewoon de code inklopt die je manager wil hebben zonder verdere vragen te stellen, omdat de managementstructuur fout is en je geheel niet betrokken bent bij het eindresultaat. Maar dan moet JIJ daar iets aan proberent te veranderen, om goed resultaat te kunnen leveren (en je baan vaak ook een stukje interessanter te maken)
Overhead is ook 'n kostenpot!

Dat klopt, maar het probleem is dat je dan de baan van je bovenliggende inpikt. Of je moet inderdaad goed in discussie kunnen gaan met die persoon.

Als je in een organisatie werkt waar het aantal developers al zo groot is dat je niet iedereen echt kent wordt het wat lastiger. Ook zijn er vaak beslissingen die laat slechte keuzes lijken te zijn, maar waar het effort van vervangen bijna niet goed te keuren is.

Tussen MT etc. is probleem vaak communicatie, de belangen van development gaan vaak richting het product maar men wordt gepushed om bijv. features te ontwikkelen en daardoor meer technical debt op te bouwen, te weinig tijd om dingen onderhoudbaar te maken.

Nogmaals ligt aan de organisatie, ik zit in de medische wereld, hier is het nog erger je kunt namelijk als 1 persoon zijnde niet alles overzien/weten en als je dan constant wil communiceren is de kans groot dat je alleen maar aan het communiceren bent.

[Reactie gewijzigd door Gopher op 24 juli 2024 02:18]

Niet alleen medische wereld hoor ;)
Hier in de beveiliging ( en dan voornamelijk de electronische beveiliging, systemen en voertuigen ) gaat dat nét zo

Wij hadden een partij gevonden die speciaal op onze wensen een pakket zou maken, en dat 100% op onze noodzaak zou aansluiten.
Geweldig, maar al binnen 6 maanden kregen we stukjes tekst in Portugees, en Pools naar voren.
Eerste reactie ontwikkelaar 'er zijn internationale partijen mee aan het werk'
Maar uiteindelijk bleek men OOK voor de Poolse en Braziliaanse markt te ontwikkelen, alleen hadden die en andere manier van werken.
"Of wij het een probleem vinden dat functie XX hier ook in gezet zou worden, dan kunnen we het testen"

Functie XX was een wekkerfunctie, die de centralist elke 2u moest activeren dmv een captcha :|
Zodat hij kon aantonen niet te slapen op het werk.

Ontwikkelaar was al snel buitengeschopt ;)
Nu een iets ouder(wetser) systeem, maar wel van 'ons'
Kosten kwamen ook steeds hoger uit, en het eindproduct zou zeker 2x duurder zijn geworden
( ondanks de gebroken ontwikkeling met externe partijen )
Welk project loopt nou wel op kosten. Heeft niks met de IT te maken maar meer met algehele incompetentie.
Klopt. Via een zoekmachine kan je heel veel grafiekjes vinden waaruit blijkt dat zaken als de kanaaltunnel, het suezkanaal, het sydney-operagebouw, Berlijn Brandenburg Luchthaven etc. ver over hun budget gaan. Maar niemand zal de verstandige beslissing te nemen: "we gooien die hele luchthaven plat en gaan het vliegverkeer in plaats daarvan beter over kleinere luchthavens verspreiden/investeren in hoge snelheidstreinen" (ook niet zonder risico). Bij software doe je toch minder imagoschade op door weg te gooien wat je al hebt.
Design by committee.
Anoniem: 946815 @catfish13 oktober 2017 12:27
Organisaties zijn dynamische wezens en technieken in de IT zijn, relatief gezien, bovenmatig aan verandering onderhevig. Die combinatie zorgt ervoor dat een IT'er vrijwel altijd te maken heeft met een "moving target".

Bij een eenvoudig project kun je daar vaak wel rekening mee houden: je kent de spelers, je voorziet enkele voor de hand liggende veranderingen en plant daar een X aantal extra uren voor in. Naarmate projecten groter worden en er meer poppetjes en variabelen continue veranderen wordt dat steeds moeilijker.

Mijns inziens is het niet zozeer een IT probleem, maar een management probleem. Zowel het reguliere als projectmanagement begrijpen vaak onvoldoende dat je beter naar een veroudert (maar wel beter dan de huidige situatie) doelwit kunt werken, dan het doelwit continue verschuiven. Het opdelen en faseren van verandering is vaak lastiger dan het lijkt.
Ik heb het idee dat het onder andere ligt aan de waterval ontwikkelmethode, die bij overheidsinstanties nog veel gebruikt wordt (ook bij het aansturen van externe software leveranciers). Hierbij kan er een flinke tijdsduur zitten tussen het maken van het ontwerp en de uiteindelijke implementatie. Vaak is het zo dat tijdens het ontwikkelproces nieuwe inzichten ontstaan waardoor de wensen veranderen, het ontwerp aangepast moet worden, en er dingen overnieuw gedaan moeten worden.
Veel bedrijven, als we het niet over giganten hebben, kloten maar wat aan qua projecten en volgen echt geen officiele methode als SDM :P
De klant kan bij veel IT projecten slecht de requirements verwoorden en de IT sector is niet competent genoeg om deze concreet genoeg en meetbaar te maken. Verder worden er te weinig afspraken gemaakt over doorlooptijd, kosten en wat te doen met bugs.

Wanneer je een huis bouwt en dat loopt uit, ga je ook niet meer betalen, net zo min dat jij betaalt omdat er kozijn verkeerd is gezet tijdens de bouw of dat er lekkage optreedt. In de IT sector is het gebruikelijk dat je dan maar blijft betalen.

De IT sector is helemaal niet incompetent: zolang klanten deze werkwijze accepteren, zouden ze gek zijn om anders te handelen. Op deze manier blijven ze maar werk houden.
In de IT sector is het gebruikelijk dat je dan maar blijft betalen.
Dat is enkel bij de grote consultants zo hoor, die er vreemd genoeg op de één of andere manier blijven in slagen grote projecten binnen te halen, ook al leveren ze erg vaak niet op.

Bij kleinere bedrijven krijg je zo goed als altijd een projectprijs, en betaal je uiteraard niets meer als het project uitloopt, en ook niet om fouten op te lossen. Ik zou nooit een project aanvaarden waarbij ik op voorhand niet weet hoe veel het me gaat kosten.
Eh je betaalt langer bouwrente... Die vergoed de projectontwikkelaar niet. En je wil niet weten wat er bespaart wordt op kwaliteit in sommige grote projecten. Erg anekdotisch, maar in mijn omgeving heeft niemand een oplevering gehad waarbij de keuring geen bevindingen had.
Hoewel ik je als freelance software ontwikkelaar ergens gelijk geeft, moet je ook wel rekening houden met het feit dat de bouwsector al duizenden jaren bestaat en al duizenden jaren ervaring heeft kunnen op doen met wat wel en niet werkt.

Voor zeer moderne bouwtechnieken die ook alles omgooien, wed ik dat ook daar bepaalde onzekerheden zitten en dat het oplossen van tot voor kort onbekende problemen voor het uitlopen van het project kan zorgen. Noot dat hoog bouwen niet noodzakelijk iets is waar geen ervaring in is. Architecten hebben ook daar al langer dan dat de software industrie bestaat, oplossingen voor.

Hoewel ik denk dat software ontwikkeling na enkele honderden jaren op gelijke voet zal staan met bv. architectuur en de bouwindustrie, is dat nu nog niet. We zijn een erg jonge industrie. We bestaan als gehele industrie bv. minder lang dan hoe oud het bedrijf Ford is. Het industrialiseren van software ontwikkeling is iets dat maar eind jaren zeventig begin jaren tachtig is begonnen, en pas in de jaren negentig echt op gang is gekomen. M.a.w. degene die nu software ontwikkeling doen zijn of eerste of tweede generatie.

Dat vergelijken met de bouwsector, die letterlijk al duizenden jaren bestaat, is ...

ps. In die duizenden jaren zijn er ook al heel wat kerken ingestort, piramides afgeschraapt door de lokale bevolking om stenen te pikken, gebouwen in de grond gezakt (waarvan de Toren van Pizza één van de weinigen is die nu nog rechtstaan zodat jij kan gaan kijken), bruggen die zijn gaan schudden door de wind die ingestort zijn en doden veroorzaakten, aardbevingen die gebouwen vernielden maar ook kleinere problemen zoals massa's kelders die ondergelopen zijn, muren die scheuren, daken die te zwaar zijn en de zijmuren uit elkaar duwen, grondverzakkingen bij de buren tijdens grondwerken van een nieuwe woning die het huis ernaast doen instorten, en zo verder.

[Reactie gewijzigd door Anoniem: 85014 op 24 juli 2024 02:18]

Anoniem: 981211 @catfish13 oktober 2017 12:40
Is de IT-sector incompetent?
Niet meer dan andere sectoren. Er zijn tal van factoren die bij kunnen hebben gedragen aan een dergelijk besluit. Een idee kan altijd op papier veel beter lijken te werken dan in het in de praktijk daadwerkelijk doet. Dat is echt niet gelimiteerd tot IT.
Het probleem is vooral wat hierboven wordt aangegeven. Een dermate ingewikkelde oplossing verzinnen voor het probleem.

Hetzelfde is in Nederland aan de hand met rekeningrijden: laten we in alle auto’s een kastje gaan inbouwen. Compleet onschaalbaar idee natuurlijk. Maar ja, accijns verhogen met hetzelfde resultaat (de vervuiler betaald) en vooral minder kosten en risico’s is ongeveer hetzelfde als politieke zelfmoord.
Voor mij is dus altijd een raadsel waarom er niet meer wordt gekeken naar omringende landen.


Een werkend concept dat al werkt en dat aanpassingen nodig heeft,
lijkt me beter dan je op een eilandje wanen en net doen alsof er een totaal nieuw concept uit de grond moet worden gestampt.
Is de IT-sector incompetent?
Je kan competentie van een IT bedrijf niet meten. Je kan alleen prijzen vergelijken, en afgaan op vriendjes-van-vriendjes. Je kan alleen maar een miljoen euro overschrijven en hopen dat er iets afgeleverd wordt, en dat datgene dat afgeleverd wordt een soort van zinnig is.

[Reactie gewijzigd door Gamebuster op 24 juli 2024 02:18]

Mijn ervaring is dat het vaak scope creep is. Vooral tijdens lange trajecten -dus grote projecten- worden steeds meer zaken toegevoegd aan de specificatie. Verder inderdaad het gebrek aan daadkracht om op tijd de stekker eruit te trekken. Die IT managers zullen wel zeggen 'bijna, we zijn er bijna' maar die willen elke cent eruit persen. Ook als ze weten dat het alleen maar erger wordt.
Ik denk dat de communicatie tussen IT en management vaak foutloopt. Een zelfde project is hier compleet van de rails gelopen, omdat een eindgebruiker alle design en software keuzes maakte zonder technische kennis, dan wordt een project zeer snel zeer duur en complex. En een bedrijf gaat dat gewoon implementeren, omdat "klant is koning".
De IT-sector is niet zozeer incompetent maar overschat zichzelf verschrikkelijk. En onderschat hoeveel kennis en intelligentie in het 'domme' werk zit dat ze met software wel eens even zullen vervangen.

Een begrijpelijk en veel aangehaald voorbeeld is het ontwikkelen van een goede automatische lasrobot. Daarbij is niet een geniale, foutloze programmeur of een fantastische projectleider essentieel maar de kennis en input van een vakkundige lasser. Zonder die vakkennis kan je programmeren en projectmanagen tot je een ons weegt, het wordt geen goede lasrobot...

Helaas is de voor de software nodige 'vakkennis' in de praktijk vaak veel minder duidelijk. Ik zie in dit geval het team voor de automatisering al voor mij: een paar universitair geschoolde bestuurders, aangevuld met projectmanagers met een hoge economie opleiding aan de ene kant, een paar IT specialisten met ir. voor hun naam en de meest getalenteerde programmeurs aan de andere kant. Doel: het vervangen van al die loketmedewerkers die met opleiding lagere school de kaartjes verkopen. Jongens, hoe moeilijk kan dat nu helemaal zijn?? Nou, naar nu blijkt veel moeilijker dan ze dachten.

Ik denk dat veel van die megaprojecten niet mislukken omdat de programmeurs niet goed genoeg zijn of de managers de zaak niet in de hand houden of de klant steeds andere dingen wil maar omdat de 'toplaag' van managers en IT-ers stelselmatig onderschatten hoe ingewikkeld zelfs 'dom' werk in de praktijk is en zichzelf gruwelijk overschatten in hoeveel slimmer ze zijn dan de mensen die dat domme werk doen.
Ik werk momenteel aan software voor CNC machines bij de marktleider in CNC besturingen in Duitsland, en ik kan je vertellen dat wat onze software uitvoert niet door mensenhanden kan uitgevoerd worden (qua precisie en snelheid). Eenvoudigweg omdat de mens helemaal niet voldoende fijngevoelig is. Ik heb het dan over precisie van 8 micrometer per lopende meter en beter in metaalbewerking. Dat haalt men vooral door uiterst precieze meetapparatuur die het werkstuk, de tool en vooral ook de machine zelf helemaal meet alvorens te beginnen. Voorts kan materiaal op verschillende plaatsen licht verschillen waardoor er lokale warmte opbouw lichtjes anders is en moet je adaptief je snelheid gaan wijzigen. Machines zijn ook van metaal en metaal zet uit. Dus als je machine uitzet, dan haal je je precisie niet meer.

Dat moet verder tegen een rotsnelheid gebeuren. Want anders worden je vliegtuigmotoronderdelen te duur (voor een samenleving), en duurt het te lang (voor een samenleving) om te produceren (het zou jaren duren). Dan kan jij niet meer zo goedkoop op reis gaan als dat je nu kan. Zelfde geldt trouwens, hoewel het daar veel minder precies hoeft te zijn, voor tal van onderdelen van je wagen.

Dat, kan een mens niet. Dat, kan een computergestuurde machine wel.
Computers en Software wordt gemaakt door mensen. De eisen en wensen van een product wordt ook door mensen opgesteld.

Bijvoorbeeld een duidelijke beschrijving en realistische verwerkingstijden is ieder stuk software te ontwikkelen.

Ik durf hard te stellen dat IT techneuten welke niet een door mensen gebouwd systeem kunnen laten functioneren conform eisen en wensen gewoonweg NIET CAPABEL ZIJN.
Anoniem: 981211 @svennd13 oktober 2017 12:14
Hier ben ik het eigenlijk wel mee eens. Het is natuurlijk zonde van die €30m maar je moet inderdaad op een gegeven moment durven zeggen -- "Laat maar, laten we terug gaan naar de tekentafel".
en die 30 miljoen is nooit helemaal weggegooid want vaak worden de wel werkende onderdelen hergebruikt
Dit wordt in elk geval vaak gezegd. Of dat ze er iets van geleerd hebben. Maar de praktijk lijkt aan te tonen dat vooral bij de overheid er geen les uit wordt getrokken en ze zich telkens aan dezelfde steen stoten.
11 Miljoen om te controleren of een deur open of dicht is?!?!?

En ticketsystemen worden toch in elk land gebruikt? Kwestie van een goede leverancier zoeken en dat product configureren en implementeren. Maar goed, in nederland verzinnen we ook zelf hoe een OV-Chipkaart moet werken want wij zijn zo uniek in de wereld...
Anoniem: 890159 @jongetje13 oktober 2017 13:03
Elk land heeft wel weer eigen eigenaardigheden die met papier makkelijk te implementeren zijn maar elektronisch niet. In Nederland heeft men zaken afgeschaft die te lastig waren voor de OV chipkaart: korting bij retourticket, anoniem meereizen met korting. Misschien wilden ze daar in Belgie niet aan? Dan kan een systeem al snel erg complex worden.
We hebben hier in België inderdaad een behoorlijk aantal verschillende soorten vervoersbewijzen voor verschillende doelgroepen. Neem de 10 ritten kart voor gewone mensen waarmee je dus best goedkoop reist. Ook de kaart voor kleine reizen en die voor studenten. Het zou moeten kunnen om dat allemaal digitaal te krigjen op één chip kaart maar dat lijkt me behoorlijk lastig uit te voeren.
Eigenlijk ging het over het herschrijven van de vertrekprocedure van een trein, niet alleen een controlesysteem of een deur open of dicht was. Er bestaat al een systeem om de deuren te controleren in al het materiaal. Men moest maar 1 regel aanpassen in de regelgeving om ervoor te zorgen dat treinbegeleiders de deur al mochten sluiten wanneer de andere deuren dicht waren.

Maar dat was blijkbaar moeilijker te verantwoorden dan een project op poten te zetten waarbij men in alle stations in Belgie RFID-chips heeft opgehangen op alle palen en een systeem op poten heeft gezet om draadloos te communiceren naar de bestuurder dat de trein vertrekkensklaar is. Dat het bij de laatste testen nog altijd bijna een minuut duurde om zo een trein te laten vertrekken zal waarschijnlijk niet in het voordeel gespeeld hebben van dit plan.
Ok, er is gekozen voor een ander systeem. Uit het artikel (ook in De Tijd) blijkt totaal niet waarom dat product wel zou functioneren. Ik vermoed dat je niet ergens een cloud-treinticketsysteem voor het Belgische openbaar vervoer koopt. Dus betekent dit dat Belgie nog eens 30 miljoen gaat uitgeven aan het nieuwe systeem, om er dan achter te komen dat dat systeem nog slechter werkt?
De tijd dat "cloud" een oplossing voor al onzer en uwer problematiek vormde is alweer gepasseerd. We leven inmiddels in het "scrum" tijdperk :) . https://pauw.bnnvara.nl/media/377816
Scrum is ook niet alles. Er zijn mensen die scrum zien als een soort wondermiddeltje tegen alle projectmatige problemen binnen de ICT. Scrum zou bijvoorbeeld een stuk minder bureaucratische rompslomp meebrengen en een stuk sneller werken. Bij het opzetten van een project is scrum verre van ideaal, ontwikkelaars die er niet goed mee om kunnen gaan en mensen die scrumgroepen verlaten die vervolgens een kennisgat achterlaten door het gebrek aan documentatie. Er zijn bijvoorbeeld grote "key features" die in het begin missen, waardoor het systeem alsnog niet bruikbaar is of afhankelijkheden die niet goed iteratief kunnen worden opgelost.
Het één heft het andere niet op, ik zat 7 jaar terug al in een scrum team, toen was cloud nog iets marginaals. Cloud is een onderliggende technologie / principe keuze. scrum is een methodologie...
Cloud en Scrum hebben uiteraard niets met elkaar te maken. Het ene is een technologie / opzet, het andere een project management techniek. Het is trouwens een grote misvatting dat scrum gebruiken alle issues oplost, soms zelfs integendeel. Het helpt in het beste geval om geforceerd te worden een project in behapbare stukken te delen.

Elk project valt of staat in de eerste plaats met duidelijke requirements, een samenwerking over alle partijen heen, en heldere/eerlijke communicatie. Jammer genoeg komt het, zeker in grote bedrijven, amper voor dat aan al die voorwaarden wordt voldaan. Meestal zelfs geen enkele.
Cloud en Scrum hebben wél wat met elkaar te maken. Namelijk dat het allebei buzzwords zijn waarmee managers denken alle ICT-gerelateerde zaken op te kunnen lossen.
Applaus, u heeft het begrepen! :) Vandaar ook de link in mijn vorige bericht...
Complexe software heeft nou eenmaal tijd nodig om op punt te komen. Na vele development iteraties en QA effort kom je tot een volwaardig product. Weet niet of van nul af aan herbeginnen de oplossing is...
Als je na 5 jaar en 30 mln euro nog geen knap werkend systeem hebt, mag het toch wel overduidelijk zijn dat het nooit meer goed gaat komen. Dus de stekker eruit trekken is een prima besluit. Alleen had dat al veel eerder moeten gebeuren.

Maar ik snap werkelijk niet waarom dit soort projecten zo lang door mogen klungelen. Na een jaar (6 miljoen euro... 40 manjaar!) moet je toch al een knap werkend systeem in productie hebben. Het hoeft nog niet alles te kunnen maar het moet al wel werkend in productie staan.
Maar ik snap werkelijk niet waarom dit soort projecten zo lang door mogen klungelen.
Dat komt door een psychologisch effect, de sunk cost fallacy. Als je ergens al veel geld in hebt geïnvesteerd, dan wordt het moeilijk om toe te geven dat het niet meer goed komt met het project en dat het geld verloren is. Dus dan blijft men maar doorgaan, hopend dat het nog goed komt, totdat het eindigt met een crisis. Het is een bekend psychologisch en economisch effect waar mensen en bedrijven desondanks toch elke keer weer blijven intrappen.

[Reactie gewijzigd door jj71 op 24 juli 2024 02:18]

Voor sommige heel moeilijk te begrijpen en dat is ook volstrekt normaal in de zakenwereld, maar de route naar succes kan je niet perfect inplannen.
R&D kost vreselijk veel, maar als je datgene hebt gevonden dan kan je het je massa's winst leveren. Is het slecht dan kan je in sommige gevallen de boeken sluiten.

In het geval van de NMBS weet je natuurlijk de details niet, maar zal er toch iemand verantwoording voor moeten afleggen. Misschien een slechte RFP geschreven en pas laat tot het besef gekomen van de mogelijkheden? Te veel beloven van de afnemer? ...

Vergeet ook niet, NMBS is een bedrijf met een gigantische omzet en vreselijk complexe structuren. Het is soms goedkoper om een groot project de vuilbak in te gooien dan die structuren aan te pakken.
Ik weet niet wat er precies aan de hand is, maar een ticket-systeem ontwikkelen lijkt me echt niet het moeilijkste. Hoe kan zoiets zo lang duren en zo veel kosten? Ben ik de enige die er te simpel over denkt?

Ik wil dat best voor een miljoentje of 30 ontwikkelen voor ze hoor, geen probleem! Dat is volgend jaar af, want dat hoeft ook niet zo lang te duren.
ik zou zeggen schrijf je in op de pagina's voor overheids opdrachten en stel je kandidaat, je concurrenten zijn volgend jaar toch nog bezig met hun antwoord voor de RFP..
Tja, vind je het gek. Ik denk dat die ondernemingen alleen al minstens 10-15% van de omzet die uit het project moet worden gehaald kwijt zijn aan alle bureaucratische rompslomp, politieke agenda's en meetings.

Maximaal cover your ass, minimaal resultaat.
In Nederland werkt het ook niet echt goed toch? Retour korting? Nee, is er niet :/ Meereizen dan? ohw nee ook niet.

In Belgie hebben we verschillende goedkoper kaartjes voor de trein en die kun je niet zomaar afschaffen omdat het anders niet werkt. Neem de tien ritten kaart, je betaald eenmalig zeg 75 Euro en dat is dan gedeeld door tien. Of je nu van Gent naar Brussel gaat of van Oostende naar het meest oostelijke station. Je betaald dan gewoon die kleine prijs van 7 Euro en 50 Cent. Er zijn ook ritten kaarten te krijgen voor kleine stukken die betaal je ook in één keer en worden dan gedeeld door 5X of zo. Studenten hebben ook een ander tarief met hun kaart. Dan de weekend retours van vrijdag avond tot zondag of soms uitgebreid naar de maandag avond.

Dat is een beetje om een idee te krijgen. Dit lijken me veel variabelen wat natuurlijk mogelijk moet zijn maar lastig lijkt me dat zeker. http://www.belgianrail.be/nl/vervoersbewijzen/biljetten.aspx

Als je dat allemaal goed kunt uitwerken in 1 jaar, doen :D

[Reactie gewijzigd door Daniel_Elessar op 24 juli 2024 02:18]

Heeft YPTO dit zelf gebouwd, of hebben ze een partij daaronder ingehuurd (een system integrator ofzo)? Zo ja, welke was dit?

Kunnen ze een dergelijk systeem niet van een naburig land kopen, en juist hun bedrijfsprocessen laten aansluiten op deze technologie?
Jullie mogen best de OV-chipkaart kopen hoor, het is niet perfect om het zo maar te zeggen, maar het werkt vooralsnog acceptabel.
het werkt vooralsnog acceptabel.
Als je 'acceptabel' leest als 'je hebt het maar te accepteren'. Eigenlijk is het onacceptabel, maar ja, wat moet je?
Nouja als je veel reist is het eigenlijk best wel fijn. Het is meer dat het soms stuk is gegaan in het verleden met beveiligingsproblemen en uptime ed., daar doelde ik eigenlijk op.
Maar dat gaat niet werken met alle kortings tarieven die we hier hebben in Belgie. Ik denk dat dat best een struikelblok zal zijn om digitaal te krijgen. Studenten reizen behoorlijk goedkoop. Dan een 10 Ritten kaart van 76 Euro die je 10 ritten geeft van 7,60 hoe kort of lang je reis ook is. Als dat allemaal op een chip kaart moet komen lijkt me dat best lastig te noemen.

http://www.belgianrail.be/nl/vervoersbewijzen/biljetten.aspx om een indruk te krijgen ;)

[Reactie gewijzigd door Daniel_Elessar op 24 juli 2024 02:18]

Dat is het probleem op zich niet, alle abonnementen/kortingen/whatevers kunnen gewoon geladen worden op de kaarten. En anders snijden ze er maar in. Het zijn er niet eens zo veel.

[Reactie gewijzigd door EraYaN op 24 juli 2024 02:18]

Zoals ik zei, je kunt ook je bedrijfsproces aanpassen. Ik weet niet wat kortingstarieven zijn, maar zoals je het brengt klinkt het alsof het teveel en te complex is.

In Nederland hebben we ook iets dergelijks voor producten die je kunt laden, mogelijk nog meer zelfs.

Op dit item kan niet meer gereageerd worden.