Ideeën over te ontwikkelen softwarepakket: hoe uitvoeren?

[Anoniem: 208823]

Mijn vraag:
Zelf heb ik dus een idee over een te ontwikkelen stuk software. Klinkt wat oneerbiedig, want ik begrijp dat dat best een hele klus is en geen stukje is.

Het idee betreft software in de zorgsector. En dan namelijk de bestaande voordelen van huidige softwarepakketten te combineren in een nieuw pakket, zónder de nadelen (uiteraard).

Zelf ben ik gebruiker van een dergelijke software, maar heb inmiddels al wel ervaring met een x aantal pakketten en eigenlijk kriebelt het bij mij om zélf een bedrijf te starten wat het beter kan dan de bestaande concurrentie. Echter ik heb geen verstand van het schrijven van software, maar wél verstand van wat er nodig is, maar dan weer niet wat allemaal mogelijk is.

Eigenlijk is mijn vraag dus: *knip niet-discussie gericht aspect* hoe te starten met dit idee?


PS: Geachte moderator, *knip* prima met kleine aanpassing

[ Voor 23% gewijzigd door Rukapul op 04-05-2020 09:22 ]

[msteggink]

Oef. Zorg/medische software.. zorg ervoor dat beveiliging/privacy in orde is. Je wil niet bij de lancering al reputatieschade hebben..

[Anoniem: 208823]

Nou, daar dacht ik ook al aan ja. Dat zou inderdaad funest zijn. Echter als de anderen het kunnen, dan is het blijkbaar mogelijk.

[wm1234]

Ik kan je niet helpen met je plan maar ik heb klanten in de medische / zorgsector maar een aantal zaken waar je rekening mee moet houden:

- Doorlooptijden voor beslissingen zijn extreem lang -> soms wel jaren. Je hebt dus vanaf het eerste contact een enorm lange adem nodig (en tevens moet je dat ook ergens van bekostigen).

- De medische /zorg proffesional is over het algemeen niet rationeel. De beste software met de meeste functionaliteit tegen de gunstigste prijs is niet altijd de keuze. De medische/zorg proffesional moet vooral zijn werk goed kunnen doen, dat is altijd prioriteit nummer 1 en houdt van gemak / gewoonte zonder teveel met software bezig te willen zijn. Nieuwe software zorgt voor gedoe en is dus een drempel.

- Als je leuk binnenkomt bij de IT afdeling met leuke contacten -> die hebben het vaak niet voor het zeggen. Die kunnen heel positief zijn maar als de business niet mee wil (zijn over het algemeen zeer risico mijdend) dan heb je alsnog pech.

- In de markt zijn een aantal dominante partijen die een groot deel van de markt heeft en ook zorgt met relatiebeheer dat ze klanten behouden.

- Als de investering boven een bepaald drempel bedrag komt (wat in de software over het algemeen het geval is met meerjarige contracten), moet de instantie in het algemeen Europees aanbesteden. Veel partijen hebben hier oren naar en gaan er alles aan doen om dat contract te winnen. Is een aparte tak van sport, kostbaar (vaak maanden tot jaren) en je moet ook snappen wat je doet. De meeste partijen hebben een heel leger aan specialisten (financieel, juridisch, technisch, aanbesteding, inkoop, partners, benchmarking etc.) Aanbestedende partijen in de sector huren vaak ook aanbestedingsbureau's in (die graag hun toegevoegde waarde willen laten zien) die leveranciers het leven behoorlijk lastig maken met onmogelijke eisen.

- Zorg er altijd voor dat alle software voldoet aan de Nictiz standaard en dat de architectuur ook op die manier is opgebouwd.

Een aantal positieve punten:

- In de zorg (zeer groot domein dus het is lastig om een algemeen beeld te krijgen), is een hoop winst te behalen op allerlei vlakken. Er is dus zeker ruimte voor een goed product.
- Als een zorginstelling eenmaal klant is, zijn ze vaak wel trouw en betalen ze goed. De hoge drempel om binnen te komen, heeft dus ook een positieve kant.

Voordat je begint, zou ik in ieder geval niet je baan opzeggen maar eerst zorgen dat je een product hebt en vervolgens ook betalende klanten.

[ Voor 7% gewijzigd door wm1234 op 04-05-2020 00:12 ]

[johnkeates]

Ik denk niet dat dit gaat lukken tenzij je ~10 jaar zonder inkomsten met 100+ mensen kan ontwikkelen. En dan nog zal je maar beperkt klanten kunnen krijgen (in NL) om dat die samen al miljarden in HiX en Epic gepompt hebben; daar tegen in gaan is niet erg realistisch.

Het is dan ook eigenlijk geen technisch probleem, het is puur management en sales die er voor zorgen dat er zo veel tijd en geld in het bestaande spul zit maar het technische resultaat niet heel geweldig is.

[ Voor 15% gewijzigd door johnkeates op 04-05-2020 00:26 ]

[Tsurany]

Het klinkt heel simpel, even de voordelen van alle pakketten combineren zonder de nadelen mee te nemen. Echter moet je dan vanaf begin af aan zorgen dat je software architectuur echt op orde is om niet later alsnog met allerlei workarounds te komen als procedures veranderen of andere integraties nodig zijn. Als je niet zorgt dat je een zeer sterke basis hebt komen ook die nadelen uiteindelijk weer in jouw pakket. Features die net niet genoeg uitgedacht zijn waardoor je toch weer een scherm extra nodig hebt.

Een applicatie ontwikkelen doe je niet even, daar heb je heel wat development teams voor nodig die elk aan hun eigen onderdelen werken. Je zit niet alleen met het ontwikkelen van een UI maar ook de bijbehorende backend met interfaces. Daarnaast zit je met autorisatie modellen, moet je audit tevreden houden en ondertussen aan alle wetgeving voldoen met betrekking tot dataopslag, retentie, privacy,...
Software ontwikkeling is echt niet zo makkelijk als je op dit niveau applicaties moet ontwerpen. Voor je een regel code geschreven hebt ben je al weken verder.

Daarnaast ben je een gebruiker en dat zijn doorgaans de mensen waar je eigenlijk het minst naar moet luisteren. Ze hebben vaak een eigen interpretatie van hoe het werk gedaan moet worden, zien cruciale features op gebied van audit en controle als onzin en willen dat de software past bij hoe zij de het werk uitvoeren, niet hoe het uitgevoerd zou moeten worden.

Maar stel dat ik dit avontuur met je aan wilt gaan, heb jij dan de middelen om de komende jaren enkele miljoenen aan salarissen te betalen? Want dat gaat het kosten, een grote groep specialisten die jaren aan het werk zijn. Je kan zo'n product niet op de agile manier uitrollen waarbij je elke keer een extra feature live zet voor een gebruiker, het moet direct aan alle eisen voldoen om hun huidige pakket te vervangen. En dat kost dus jaren werk voordat er inkomsten zijn.

[ Voor 6% gewijzigd door Tsurany op 04-05-2020 00:22 ]

[Hahn]

Of misschien eerst de vraag wel: hoe te starten met dit idee?

Weten waar je aan begint. En niet een ideetje hebben, maar echt heel goed weten.

Dat idee krijg ik bij jou nog niet. Je zegt dat je een gebruiker bent van een bepaald softwarepakket, en dat je ideeën hebt hoe dat beter kan. En daar lijkt het op te houden. Ik gok dat je dus zelf weinig verstand hebt van software-ontwikkeling en/of ondernemen. Hoe zie je dan voor je hoe dit zal gaan?

[Wim-Bart]

Geld verdienen aan software ontwikkelen is: gebruikers laten meedenken en de software op hun werkwijze af stemmen,

Heel veel branches hebben vaste procedures, waarin alles van a tot z is vastgelegd. Alle software van grote bedrijven is hier op gebaseerd. Mevrouw muts van afdeling 209 werk al 28 jaar op haar wijze, en die wijkt af van wat er standaard is. Mevrouw muts zit vaak als beslisser in het team wat de software moet accepteren met alle ellende tot gevolg. Menig traject zien mislukken door mensen als mevrouw muts.

Het gevolg is dat er nu heel veel mensen zijn die zeggen, ik kan het beter, mijn software is wel foutloos. Ergo... je kan het wel bedenken.

[Richh]

Zoals al vaker genoemd, is binnendringen in deze markt verre van makkelijk. Ook is ontwikkelen erg duur en tijdrovend.

Wat nog niet genoemd is: "If you can't beat them, join them"
Wellicht zijn er wel wat softwarehuizen die precies opzoek zijn naar mensen met jouw kennis en kunde over zorgapplicaties. Wellicht staan ze wel open voor een gesprek. (ik werk zelf aan een businessapplicatie en wij staan 100% te springen om mensen 'uit het veld' die constructieve, waardevolle input kunnen geven).

Misschien kan je jezelf het een en ander leren op UI/UX niveau (ontwerpen, user interfaces, user experience), analist, en/of misschien wel als product owner.

Tuurlijk valt daar een heel stuk minder mee te verdienen, maar je draagt ook minder risico. Misschien kan je toch iets van je droom verwezenlijken op zo'n manier

[ Voor 12% gewijzigd door Richh op 04-05-2020 02:00 ]

[Qwerty-273]

Zoals @Richh al aangeeft kan je altijd eens polsen of je als proces specialist / domein expert / subject matter expert of welke naam je er op wilt plakken mee kan helpen (of te wel gewoon een werkcontract) met het verbeteren van het pakket. Vaak ontbreekt het bij de ontwikkelhuizen aan mensen die huidige dagelijkse praktijk ervaring hebben. En de "valkuilen" van pakketten in de praktijk kennen. Dat is in de zorg, maar ook elke andere sector het geval.

[Yucon]

En TS, heb je er nog zin in?

Ik voorzie nog een kleine uitweg: "alle software" kan niet, maar het is ook vrijwel onmogelijk dat jij daar als gebruiker ook allemaal mee werkt want wat is zo breed dat niemand het doet. Het gaat dus zonder twijfel om een stukje. Nu zou het kunnen zijn dat specifiek bij jouw stukje iets heel erg wringt waar wel een haalbare verbetering mogelijk zou kunnen zijn.. maar om dat te bepalen zul je specifieker moeten zijn.

[codebeat]

Een afbeelding, doe het niet:
https://xkcd.com/927/

[blue_ludo]

TS, in welke subsector verwacht je actief te zijn? is dit de ziekenhuiszorg met medische specialisatie of bijvoorbeeld de gehandicaptenzorg of ouderenzorg waarbij het dossier minder medisch specifiek is maar ook een sociale 'twist' heeft?

[Ulster Seedling]

Heb je het over echte ziekenhuissoftware, of over software voor een kleinere (private) medische niche?

In geval van het laatste: ik ben een aantal jaar geleden aan zoiets gaan werken Ik kwam in contact met een arts die ideeën had over hoe de software voor zijn private branche beter kon. We zijn met drie personen gestart: de arts, een internetondernemer, en ik als developer.

Onderschat niet hoe lang het duurt om dingen te ontwikkelen, en daarna ook je pakket te verkopen aan voldoende partijen om wat omzet te halen. Dat hangt natuurlijk af van hoe snel je start (part-time vs. full-time, en hoeveel mensen je direct kunt betalen).

In geval van het eerste: succes

[DeveloperNL]

Wat wil je maken? ECD/EPD/ZBC? Ik heb zelf ooit aan een EPD gewerkt als werknemer en dat bedrijf had tot 2012 best een goede positie, toen kwamen de grote jongens (Epic, hix was al groot).

Paar jaar later met 2 mensen een startup opgericht om een app te bouwen over ECD's heen. Ben er zelf uitgestapt, maar startup bestaat nog steeds en zover ik kan zien nog succesvol.

Eerste stap die we ons zelf vertelden: wees niet de bron, zorginstellingen stappen niet zomaar over op nieuwe bronsystemen en uitroltrajecten kunnen jaren duren. Zoveel geld heb je als startup niet.

[Furion2000]

Ongeacht of het idee feasible is of niet, is je antwoord niet zomaar hier te vinden.

De eerste stap om van een idee een plan te maken is 'thinking hat' methode toe te passen, zo kom je achter de goede en slechte punten en weet je waar je meer informatie moet vergaren.

Stap twee is het idee tegen anderen aan houden (daar is deze TS ook onderdeel van) en ze zullen proberen je idee basically 'kapot te schieten'. Elk idee valt kapot te krijgen met de juiste argumenten, maar beslis pas of ze gelijk hebben als je deze punten zelf hebt onderzocht. Dus vul hiermee je nog-te-onderzoeken lijstje aan zou ik zeggen, laat je vooral niet tegenhouden.

De derde stap is die informatie vergaren. Bill Gates gaat dan boeken lezen over dit onderwerp en mensen met verstand van die zaken interviewen. Persoonlijk begin ik steeds meer te geloven dat dit de manier is, want de grootste valkuil is tegenwoordig het internet en het nieuws. Het is bizar hoe een goed idee kan veranderen na een paar forum reacties bijvoorbeeld

Vierde stap is je plan formuleren in behapbare stappen en tot actie komen.

Succes!

[ Voor 22% gewijzigd door Furion2000 op 04-05-2020 10:00 ]

[JackBol]

@Fireburner in de cloud ontwikkelen gaat een uitdaging worden. Proces manager hebben nog steeds het idee dat het ziekenhuis moet doordraaien als de stroom uit valt (denk aan batterijen met printers op noodstroom in de kelder die een snapshot van het archief beginnen uit te printen bij stroom onderbreking).

Zelfs voor Epic en Hix is het een mammoth task om de zorg naar de cloud te verhuizen. Daar ga je met je software pakketje geen zoden mee aan de dijk krijgen.

Echter ik heb geen verstand van het schrijven van software, maar wél verstand van wat er nodig is, maar dan weer niet wat allemaal mogelijk is.

Als je echt zo bekend bent met de tekortkomingen van de huidige producten op de markt zou ik bij de grote spelers informeren of je daar in het product development team terecht kan komen. Er zijn voldoende rollen waarbij je zelf geen software hoeft te schrijven, maar je wel bezig kan houden met het verzamelen van requirements, user journeys, etc.

[ Voor 9% gewijzigd door JackBol op 04-05-2020 09:20 ]

[F_J_K]

Er is meer zorg dan ziekenhuizen en 'de cloud' (lees: alles buiten de eigen muren) begint elders erg grond aan de voeten te krijgen. Er zijn daarnaast ook zegmaar enkele zorginstellingen die meer dan 1 locatie hebben en dan toch al afhankelijk zijn van dataverbindingen.
Maar hoe dan ook is al dan niet 'in de cloud' het minst spannende. De cloud is 1 lift&shift weekend verwijderd van on premise en andersom (Jaja, dat is natuurlijk veel te kort door de bocht maar het gaat om het concept).

Furion2000 schreef op maandag 4 mei 2020 @ 09:04:
Derde stap is je plan en tot actie komen.

En dat is de stap waar in de TS hulp is gevraagd

-
Ongeacht in welke rol je eindgebruiker bent: bedenk dat er nog vele andere rollen zijn die ook belangrijk zijn en zich ook hebben te houden aan allerlei wet- en regelgeving. Wat heel mooi werkt voor de een, werkt niet mooi voor de ander. En als het vandaag werkt dan werkt het misschien niet meer na 5 jaar onderhoud en een aantal wijzigingen in de omgeving, de wet, etc.

Bij gebrek aan een durfinvesteerder die ook nog eens de juiste ervaring heeft in ontwikkeltrajecten en wekelijks golft met wat instellingsdirecteuren ( ) zou inderdaad jezelf laten inhuren door bijv jullie huidige leverancier een gedachte kunnen zijn.

Of misschien kan je je ideeën verkopen? Als het -echt- een goed idee is dat niet al vaker is bedacht maar verworpen om redenen a, b en c. Dat levert natuurlijk wel minder op dan wanneer je eigenaar bent van het bedrijf dat Chipsoft of Nedap van de nr1 positie haalt Ik zou het toejuichen, maar tigduizend in de plus is meer dan een kans op tig ton in de plus en grotere kans op meer in de min.

Of: gaat het om geld, of gaat het er om dat de markt verbetert? Publiekelijk delen is ook een manier. Laat een paar bestaande partijen het maar bouwen. Of maak een open source proof of concept en hoop wat licenties te verkopen maar geef de rest kans het concept te verbeteren.

Edit: dat neemt overigens niet weg dat het goed is om verbetering in de branche / voor de zorg na te streven en om ondernemend te zijn

[ Voor 3% gewijzigd door F_J_K op 04-05-2020 09:33 ]

[Skyaero]

Anoniem: 208823 schreef op zondag 3 mei 2020 @ 22:52:
Eigenlijk is mijn vraag dus: [mbr]*knip niet-discussie gericht aspect*[/] hoe te starten met dit idee?

Allemachtig wat een negatieve reacties in dit topic.

Ondernemen is risico's nemen en doorzetten. Je hebt een idee, de marktwaarde van dat idee zul je moeten verifiëren. Daarvoor hoef je geen regel programmeercode te schrijven, dat kan gewoon in Powerpoint.

Daarna zul je een klantpropositie moeten gaan maken. Hoe gaat je business model er uit zien? Op welke wijze gaat de klant betalen en waarvoor precies?

Vervolgens moet je een idee gaan krijgen hoe de uitvoering eruit gaat zien. Wat heb je nodig om datgene wat je verkoopt aan klanten te kunnen verkopen (marketing), leveren (sales) en onderhouden (support). Welke kosten gaat het bedrijf maken?

Software vereist een voorinvestering. Je moet het eerst bouwen voordat je het kunt verkopen. Hoeveel geld heb je nodig? Je zal software engineers in moeten huren, maar ook sales en marketing mensen. Kun je een investeerder aan de hand van je business plan overtuigen om geld in je bedrijf te steken?

Goede startpunten zijn het boek van Eric Ries, "The Lean Startup" en het Business Canvas Model. Als je een begin gemaakt hebt met je business plan, zou je ook naar startup accelerators kunnen kijken of zij je kunnen helpen, bijvoorbeeld Rockstart in Amsterdam. Zij hebben ook goede netwerken met VC investors.

Software vereist een uitermate lange adem. Het kan jaren duren voordat het een beetje succesvol wordt.

[ Voor 3% gewijzigd door Skyaero op 04-05-2020 09:45 ]

[Furion2000]

@F_J_K

Ik heb de reactie aangepast, ik bedoel er mee te zeggen dat hij stappen overslaat en beter eerst het idee kan 'refinen' en beter niet 'expert forum reacties' als de bijbel moet beschouwen

Dat gezegd hebbende; hij zit dan eerder denk ik in stap 1.5 (die ik dan weer vergeten ben), vertel je idee tegen mensen en overweeg de reacties en zorg dat aan de dingen waaraan je niet gedacht had ook kennis gaat vergaren.

[elhopo]

een onderneming starten voor iets als dit is niet heel moeilijk. Er zijn wat stappen die je moet nemen om iets als dit te verwezenlijken. Ik zal niet proberen in al teveel details te treden, anders wordt het wel een heel lang verhaal.
Stap 1 is je plan uitwerken. Je wil een uniek product maken. Wat maakt het zo uniek, hoe zorg je ervoor dat de concurrent dit niet ook ook snel namaakt? Hoe wil je je product gaan verkopen, wie zijn je klanten. Ook kan je wat marktonderzoek doen. Kijk hoe klanten tegenover je idee staan. Als je hier mee kl;aar bent heb je een redelijk idee van de haalbaarheid van je project.
Stap 2 is geld vinden, tenzij je zelf een paar miljoen op de bank hebt staan. Om een nieuw softwarepakket te beginnen heb je een team van ontwikkelaars nodig, en die zijn 2 a 3 jaar bezig om jouw droom te verwezenlijken. Met een team van een man of 5 ervaren ontwikkelaars moet je heel ver kunnen komen. Die mensen en jij moeten wel in de tussentijd betaald worden. Hiervoor heb je een bank of een investeerder nodig. Als je idee wat riskanter lijkt wil een bank over het algemeen niet instappen, dus is een investeerder waarschijnlijker. Die wil natuurlijk wel een deel van je bedrijf, want hoe hoger zijn risico, hoe meer winst hij eruit wil halen.
Bij stap 1 heb je een beetje een gevoel gekregen hoe haalbaar je project is, bij stap 2 heb je een idee wat het ongeveer gaat kosten om je product te maken. Als je een reële inschatting maakt van het aantal klanten kan je bepalen wat de prijs per klant is, en of de klant er warm voor zal lopen. Reken op een onderhoudscontract van 1% van de aanschafprijs per maand en dan heb je een idee van je cashflow.
Mocht je bij stap 3 aankomen dan is het tijd om alles een beetje op te gaan tuigen. We weten niet om wat voor applicatie het gaat, maar het is belangrijk om te weten welke support je moet bieden. Je zal wat consultants nodig hebben die de klant helpen bij implementaties en conversies naar het nieuwe softwarepakket. Ook heb je helpdesk / support medewerkers nodig, zelf wil je ook wel eens een dagje vrij.

De ontwikkeltijd van 2 a 3 jaar is gebaseerd op een soort standaard administratieve applicatie. Wat invoerschermen, wellicht wat factuurtjes maken ofzo, afsprakensysteem en dat soort zaken. Mocht het iets AI achtigs worden, zoals weet ik veel, automatisch röntgenfoto's beoordelen, dan kan dat heel anders zijn.

Ik hoop dat ik je hier mee geholpen heb. Let vooral niet teveel op anderen, en laat je niet door opmerkingen in dit forum tegenhouden. Google was ook niet de eerste zoekmachine.

[downtime]

elhopo schreef op maandag 4 mei 2020 @ 11:34:

Ik hoop dat ik je hier mee geholpen heb. Let vooral niet teveel op anderen, en laat je niet door opmerkingen in dit forum tegenhouden. Google was ook niet de eerste zoekmachine.

De vergelijking met Google is niet zo sterk. Google startte toen het internet enorm snel groeide en het richtte zich met een gratis dienst op consumenten. Dat zijn wel de meest ideale omstandigheden.

TS wil software maken voor een markt die niet of nauwelijks groeit, die van nature conservatief is, die sterk gereguleerd is, en waar organisaties soms grote investeringen in de huidige software hebben gedaan. Dan is er wel wat meer nodig dan alleen een goed idee.

[Anoniem: 511810]

Grappig hier zeg,
Mensen die zeggen: vooral niet naar de gebruiker luisteren, want die begrijpt niet hoe ie de sw moet gebruiken
en mensen die zeggen: kom UAB bij ons werken, wij hebben mensen nodig die weten hoe het zou moeten werken, liefst gebruikers.

Ben stiekum wel heel erg beniewd wie nu waar (aan) werkt ...

[chielsen]

Tsurany schreef op maandag 4 mei 2020 @ 00:21:
[..]

Daarnaast ben je een gebruiker en dat zijn doorgaans de mensen waar je eigenlijk het minst naar moet luisteren. Ze hebben vaak een eigen interpretatie van hoe het werk gedaan moet worden, zien cruciale features op gebied van audit en controle als onzin en willen dat de software past bij hoe zij de het werk uitvoeren, niet hoe het uitgevoerd zou moeten worden.
[..]

Heel apart advies. Je moet juist vooral naar gebruikers luisteren. Maar iemand die audits wil kunnen doen is óók een gebruiker! Die moet je dus ook faciliteren, en zo dus alle gebruikers.
Over het algemeen is het probleem precies andersom. In theorie zou het op een bepaalde manier moeten, maar in de praktijk is dat onmogelijk. Dan kan je wel in alle macht een werkmanier proberen aan te leren, maar dat is op zijn best sub-optimaal.



Verder draait het in deze business denk ik vooral om hoe je de software verkoopt en minder hoe je die bouwt. Je kan kijken of je kan samenwerken met een kleinere software ontwikkelaar (als die er is). Die heeft al veel geleerd maar staat misschien wel open voor samenwerking.

[Tsurany]

Anoniem: 511810 schreef op maandag 4 mei 2020 @ 14:14:
Grappig hier zeg,
Mensen die zeggen: vooral niet naar de gebruiker luisteren, want die begrijpt niet hoe ie de sw moet gebruiken
en mensen die zeggen: kom UAB bij ons werken, wij hebben mensen nodig die weten hoe het zou moeten werken, liefst gebruikers.

Ben stiekum wel heel erg beniewd wie nu waar (aan) werkt ...

Het is natuurlijk niet zo zwart-wit als jij dat nu stelt. Gebruikers zijn zeker wel relevante stakeholders maar je moet niet naar ze toe als het gaat om informatiebeveiliging, het opzetten van procedures en workflows of het ontwerpen van een gebruikersinterface. Gebruikers zijn je doelgroep en je test je software met hun samen maar ze zijn niet leidend voor het ontwikkelen van de software.

Ik merk dit zelf in het bankwezen ook, gebruikers hebben vaak hun eigen manier van werken die lang niet altijd bij het beleid aansluit dat de organisatie wilt voeren of bij de wettelijke eisen waar ze aan moeten voldoen. En ze gebruiken de software lang niet altijd op de manier waarop het bedoeld is. Als je dan met ze gaat praten over een nieuw systeem dan willen ze iets dat hun huidige werkwijze volgt met hier en daar een aanpassing terwijl als je echt kijkt naar wat het systeem moet doen en wat er mogelijk is kom je soms op een hele andere werkwijze uit die het werk eigenlijk veel makkelijker maakt.

Terug naar het zorg verhaal, wil je uit gaan van een verzorger die verteld hoe ze de behandelingen van een patient invullen in het systeem en hoe ze informatie overdragen aan de volgende verzorger of wil je uit gaan van de leidinggevende die de procedures opstelt en de (juridische) specialisten die weten hoe informatiebeveiliging in de zorg toegepast moet worden en aan welke wettelijke eisen voldaan moeten worden? Dan kom je er achter dat die verzorger het misschien al jaren verkeerd doet en informatie lekt of juist te weinig opslaat voor auditability.

chielsen schreef op maandag 4 mei 2020 @ 14:32:
[...]


Heel apart advies. Je moet juist vooral naar gebruikers luisteren. Maar iemand die audits wil kunnen doen is óók een gebruiker! Die moet je dus ook faciliteren, en zo dus alle gebruikers.
Over het algemeen is het probleem precies andersom. In theorie zou het op een bepaalde manier moeten, maar in de praktijk is dat onmogelijk. Dan kan je wel in alle macht een werkmanier proberen aan te leren, maar dat is op zijn best sub-optimaal.

Daarom test je je software in de praktijk met praktijksituaties en met eindgebruikers. Maar bij het oorspronkelijke design kijk je daar veel minder naar.

Zo hebben wij software ontwikkeld waar managers en hun medewerkers tezamen in de applicatie moeten werken. Managers wilden hun taken kunnen delegeren aan iemand, dat was een cruciale feature, want dan konden ze het werk overdragen aan hun secretaresse. Echter vanuit policy mag een manager die verantwoordelijkheid niet delegeren aan bijvoorbeeld zijn secretaresse, enkel aan een andere manager. En enkel indien hij zelf afwezig is vanwege ziekte of vakantie.

Zou je dus naar de gebruiker luisteren dan zou je iets ontwikkelen wat niet bij het beleid aansluit en wat uiteindelijk voor problemen kan zorgen bij controles.

[Afbeelding]

Dit laat wel goed zien hoe de gebruiker zijn eigen draai geeft aan het gebruik maar daardoor juist problemen creëert. Immers wat je nu hebt zijn twee paden die je afzonderlijk moet onderhouden. Het nieuwe pad werkt weliswaar goed als je van beneden komt en rechtsaf moet of andersom maar is verre van ideaal voor mensen die van boven komen of mensen die van rechts komen en naar boven moeten. Je krijgt dus een oplossing waarbij of iedereen zijn eigen pad krijgt, wat meer werk kost om te ontwikkelen en te onderhouden, of je krijgt een enkel pad die voor iedereen te gebruiken is maar niet altijd optimaal is.

En wat als op dat stukje groen nu wat gebouwd moet worden? Dat kan niet omdat het al in gebruik is als voetpad. Dat zou dus betekenen dat daar iets bouwen de workflow van een gebruiker verstoort.

[ Voor 37% gewijzigd door Tsurany op 04-05-2020 14:46 ]

[chielsen]

@Tsurany Het is niet een of / of probleem, maar en / en.
Veel gebruikers gaan (sub-optimale) workarounds toepassen, omdat het systeem de gangbare workflow niet ondersteunt. Dat is eerder een gebrek aan UX onderzoek, dan dat de gebruikers het systeem oneigenlijk gebruiken. Uiteindelijk zijn de meeste systemen bedoeld om de gebruikers te ondersteunen.

[Tsurany]

chielsen schreef op maandag 4 mei 2020 @ 14:51:
@Tsurany Het is niet een of / of probleem, maar en / en.
Veel gebruikers gaan (sub-optimale) workarounds toepassen, omdat het systeem de gangbare workflow niet ondersteunt. Dat is eerder een gebrek aan UX onderzoek, dan dat de gebruikers het systeem oneigenlijk gebruiken. Uiteindelijk zijn de meeste systemen bedoeld om de gebruikers te ondersteunen.

Maar in hoeverre is de user experience iets waarbij een gebruiker direct betrokken moet zijn? De UX zou door specialisten op dat vlak ontworpen moeten worden op basis van wetenschappelijk onderzoek en jarenlange ervaring. Uiteindelijk test je wel of de daar uit komende UI goed werkt voor de gebruiker, het liefst door vroeg al met prototyping en mockups te starten, maar voor het design heb je ze niet direct nodig.
Maar wanneer je begint met hoe een enkele gebruiker vind dat het moet werken en dat als uitgangspunt neemt dan gaat het vaak niet de goede kant op en krijg je een systeem dat net als hun huidige systeem werkt want dat zijn ze gewend.

[Anoniem: 511810]

Tsurany schreef op maandag 4 mei 2020 @ 14:58:
[...]

Maar in hoeverre is de user experience iets waarbij een gebruiker direct betrokken moet zijn? De UX zou door specialisten op dat vlak ontworpen moeten worden op basis van wetenschappelijk onderzoek en jarenlange ervaring. Uiteindelijk test je wel of de daar uit komende UI goed werkt voor de gebruiker, het liefst door vroeg al met prototyping en mockups te starten, maar voor het design heb je ze niet direct nodig.
Maar wanneer je begint met hoe een enkele gebruiker vind dat het moet werken en dat als uitgangspunt neemt dan gaat het vaak niet de goede kant op en krijg je een systeem dat net als hun huidige systeem werkt want dat zijn ze gewend.

Hier kan je een oeverloze discussie over houden, maar dat is mi ver voorbij de vraag van de TS.
Vanuit mijn ervaring is het vaak dom en duur om puur omwille van het veranderen de UX te veranderen. Los van de andere aspecten van een wijziging is het gebruik van een systeem door een (groot?) deel van de mensen die er mee moet werken vaak een evolutie, en die gaan 9 van de 10 keer de goede kant op. Als ik kijk naar mijn eigen werkomgeving zie ik eigenlijk geen veranderingstrajecten, die vaak inderdaad vanwege auditability ingezet zijn, die 'in the end' de productiviteit ten goede zijn gekomen.

Hoeft geen probleem te zijn, als het maar wel netjes wordt geaccepteerd en geanticipeerd.

[chielsen]

Tsurany schreef op maandag 4 mei 2020 @ 14:58:
[...]

Maar in hoeverre is de user experience iets waarbij een gebruiker direct betrokken moet zijn? De UX zou door specialisten op dat vlak ontworpen moeten worden op basis van wetenschappelijk onderzoek en jarenlange ervaring. Uiteindelijk test je wel of de daar uit komende UI goed werkt voor de gebruiker, het liefst door vroeg al met prototyping en mockups te starten, maar voor het design heb je ze niet direct nodig.
Maar wanneer je begint met hoe een enkele gebruiker vind dat het moet werken en dat als uitgangspunt neemt dan gaat het vaak niet de goede kant op en krijg je een systeem dat net als hun huidige systeem werkt want dat zijn ze gewend.

Ben ik het niet mee eens en is ook precies niet de reden dat TS wil beginnen. Volgens mij is hij ook een gebruiker die zich stoort aan hoe het nu werkt.
UX is grotendeels testen, de eerste gebruiker die precies is zoals een tekstboek dat voorstelt moet nog geboren worden...
UX is meer dan UI. Belangrijk is dat de workflow goed loopt en daar kan je prima gebruikers bij betrekken. Dit moet namelijk haarfijn aansluiten.

[martin_v_z]

chielsen schreef op maandag 4 mei 2020 @ 14:32:
[...]


Heel apart advies. Je moet juist vooral naar gebruikers luisteren. Maar iemand die audits wil kunnen doen is óók een gebruiker! Die moet je dus ook faciliteren, en zo dus alle gebruikers.
Over het algemeen is het probleem precies andersom. In theorie zou het op een bepaalde manier moeten, maar in de praktijk is dat onmogelijk. Dan kan je wel in alle macht een werkmanier proberen aan te leren, maar dat is op zijn best sub-optimaal.

[Afbeelding]

Verder draait het in deze business denk ik vooral om hoe je de software verkoopt en minder hoe je die bouwt. Je kan kijken of je kan samenwerken met een kleinere software ontwikkelaar (als die er is). Die heeft al veel geleerd maar staat misschien wel open voor samenwerking.

Eens. Gebruikers zijn heel belangrijk in het proces. Vaak moet je alleen niet naar hun oplossingen luisteren, maar naar hun problemen. Wat is het einddoel, en dan een oplossing bedenken. Oplossing weer voorleggen aan de gebruiker.

[Gomez12]

chielsen schreef op maandag 4 mei 2020 @ 16:48:
[...]
Ben ik het niet mee eens en is ook precies niet de reden dat TS wil beginnen. Volgens mij is hij ook een gebruiker die zich stoort aan hoe het nu werkt.

Jezelf storen aan hoe het nu werkt is een uitermate makkelijke en luie positie.
Weet TS ook waarom het zo werkt?

Want het kan zijn dat het vanuit overheidsregels zo moet gaan, het kan zijn dat het vanwege bedrijfsbeleid zo moet gaan, het kan zijn dat het vanwege security-beleid zo moet gaan, het kan zelfs zo zijn dat het komt doordat we met zijn allen extreem goed geluisterd hebben naar tante truus die haar eigen werkwijze had en de functie verrichte voordat de TS er was.
Het kan zelfs zo zijn dat niemand exact weet waarom het zo werkt en dan kom je helemaal in de gevarenzone, want als je dan dingen gaat wijzigen dan is het einde zoek.

[chielsen]

Gomez12 schreef op maandag 4 mei 2020 @ 17:55:
[...]

Jezelf storen aan hoe het nu werkt is een uitermate makkelijke en luie positie.
Weet TS ook waarom het zo werkt?

Ik denk dat 90% van de innovatie komt van: dat kan toch beter... Of TS verder heeft nagedacht weet ik niet, maar dat lijkt me toch wel als je van plan bent een bedrijf te beginnen.

[Sport_Life]

msteggink schreef op zondag 3 mei 2020 @ 22:58:
Oef. Zorg/medische software.. zorg ervoor dat beveiliging/privacy in orde is. Je wil niet bij de lancering al reputatieschade hebben..

Dat maakt het al bijna praktisch onmogelijk, zowel in de uitvoering als de verkoop.
Ik heb geen kennis van programmeren, wel van AVG /gdpr en die maakt het voor met name de zorg erg lastig (terecht).

[ Voor 15% gewijzigd door Sport_Life op 04-05-2020 20:51 ]

[Gomez12]

chielsen schreef op maandag 4 mei 2020 @ 20:34:
[...]


Ik denk dat 90% van de innovatie komt van: dat kan toch beter... Of TS verder heeft nagedacht weet ik niet, maar dat lijkt me toch wel als je van plan bent een bedrijf te beginnen.

Tja, met een heel klein beetje denkwerk kan je zo bedenken hoe je een bedrijf hiervoor opstart. Alleen dat is exact wat de TS hier vraagt, dus ik ben bang dat TS het nog niet zo goed uitgedacht heeft...

Het bedenken van perfecte software is ook geen enkel probleem, met dat idee zijn alle bedrijven zo ongeveer gestart in die business. De truc is alleen hoe voorkom je dat je net zo als de rest wordt. En je dus over 5 jaar als je een uitgewerkt pakket hebt dat het allerlei flaws bevat.