Door Anoniem: [Sla de onjuiste aannames over mijn achtergrond maar over. Ik heb een kwart eeuw in de automatisering gezeten, maar wel steeds op automatiseringsafdelingen van bedrijven die hun automatisering zelf deden. Als dat goed georganiseerd is heb je korte lijnen tussen de opdrachtgevers en bouwers, is snel duidelijk wat wel en niet mogelijk is en ontstaan er geen overdreven hoge rekeningen voor redelijk simpele dingen omdat iets niet in de agenda van de leverancier past of omdat er een contract is dat geen ruimte voor flexibiliteit laat. Ik geef zonder meer toe dat mijn perspectief gekleurd is door die achtergrond, ik ben gewend dat dingen die een organisatie iets opleveren en die technisch eenvoudig te realiseren zijn een grote kans hebben om door te gaan.
Wie welke dossiers inziet is al aanwezig in een geautomatiseerd systeem. Een signalering dat er bovenmatig veel mensen zich als behandelaar/verzorger opwerpen is eenvoudig te maken als die gegevens vanuit een programma op te vragen zijn. Als ook al is vastgelegd wie met welke patiënt te maken heeft is de andere opvraging ook niet bepaald een heksentoer. In het soort omgevingen waar ik heb gewerkt zou dat een van de kleine projectjes zijn. Als dat door uitbesteden van de automatisering onbetaalbaar wordt dan heeft uitbesteden naast kostenbesparende kennelijk ook kostenverhogende kanten omdat je niet over functionaliteit kan beschikken die je organisatie maar al te goed kan gebruiken.
Geen probleem om tegen je op te bieden in de ervaringsjaren. Het was jouw statement om te beginnen met "Heb je wel eens van automatiseren gehoord?" die kunnen we denk ik nu gevoeglijk achterwege laten.
Ik stam uit de tijd dat je alles zelf moest programmeren mainframes. PDP's aan de andere kant. De desktop bestond nog niet. Prachtige dingen gedaan maar ook al die de wonderlijke aanbestedingen met persoonlijke voorkeuren van personen en het vrij blind volgen van de leveranciers. Het betreft niet de kleinste omgevingen, integendeel.
Ik heb de hele verandering en de strijden rond tools en strategie meegemaakt en gevolgd. Tijdens dat gedoe het nodige bijgedragen aan de technische continuïteit met het volgen en trekken van de veranderingen.
Ooit in die begintijd was de security iets wat niet apart was maar als zelfgebouwde inputvalidatie aan eigen code werd toegevoegd. Logging kostte te veel resources maar SMF deed het goed. log4- arm logging is er een voortzetting van.
Wat later kwamen de COTS pakketten met de aanbestedingen door. Nu kun je zeggen als dat maar goed georganiseerd is komt dat wel goed. Als de boekhouding verschillende productlijnen financiële verantwoording en marketing allemaal op zich wat gaat gaan doen met eigen keuzes heb je snel een behoorlijk afstemmingsprobleem. Dit is gangbaar in wat grotere omgevingen.
Kijk nu eens naar de logging en monitoring voor het gebruik. Je kunt het niet in de applicatie integreren (hier een cots his). Je moet het los gekoppeld hebben. De monitoring/soc mag niet bij de applicatie gebruikers codeurs niet bij de logging.
Dan heb je snel een dwh bi big-data analytics uitdaging met security log data. Om dat goed in te vullen is hoog niveau vereist (wo), dit is mijn werkveld. Een soc center zet men gewoonlijk eenvoudig en goedkoop in (mbo query vaardigheden, lijstje afvinken).
BI analytics met security BI analytics data hoeft technisch niet zo moeilijk te zijn. Zeker als je dwh's bi analytics door hebt. Het is een standaard wijze van rapportjes maken in veel andere deelgebieden. Met SAP krijg/kreeg je BO daarvoor mee. Het is nou niet bepaald het succes.
Als we nu het haga verhaal er weer bij pakken zien we dat ze het inderdaad op deze genoemde wijze doen.
Met steekproeven (sql-queries op logfiles) door een soc controleren of het gebruik is zoals het zo horen.
Ik lees dat ze die mogelijkheid tot analyses hebben en er door middel van steekproeven wat mensen dat laten doen.
Jouw beeldvorming is wonderlijk genoeg anders dan die van mij. Ik ben benieuwd waar jij een verklaring voor onze verschillen kan geven.