IFIP TC 8 Conference on Big Data Information Systems

Big_Data_Information_System_-_TC8_ 2015_1st_CfP_A4-size

Advertisements

Informatica in het middelbaar onderwijs

Zoals beloofd een kleine enquête betreffende het vak informatica in het middelbaar onderwijs.

Ik zal de resultaten van de poll pas achteraf meedelen in een aparte blog.  Nu wil ik niemand beïnvloeden door tussentijdse resultaten te tonen.

Met dank voor de medewerking

jan

seguridad-informatica1-300x225

CONFENIS 2012 – Call for participation

call for participation

ERP: An Inconvenient Truth or A Reassured Lie?

Yesterday I reviewed a sparkling paper of academic research to an ERP failure in an SME. The authors used a interpretative narrative to unfold the complete project from its inception phase to the use phase. Believe or not, but the system is in use! The story has become all too familiar: over budget, over time, a lot of flaws and errors in the system, a troubled relationship with the ISV and a lot of painful scars in the own organization. I took the paper to contemplate on what could be an overall understanding of what is exactly the problem with ERP projects in SMEs. Of course one could say that there are abundant factors that lead or instigate a failure, but there is always a tendency to summarize and to be brief, meaningful and still be truthful.

To my believe and understanding the root cause of the failures lays within the relationship with the ISV or consultant and the inappropriate handling of risk. There is risk involved with an ERP implementation. If statistics say that more than 70% of these project either go over budget or go over time, than it should be wise to take that into account. This is an inconvenient truth. The ISV should confront his customer with that risk, instead of trying to hide this figure. But what does the CEO of the SME wants to hear? An inconvenient truth or a reassured lie?  According to D. Kahneman people largely choose for certainty if chances of a lost are high. A reassured lie?

The risk involved with an outsourced ERP project goes over to the consultant or ISV (the agent). This transfer is done in a sphere of mutual trust which is very difficult to manage. I did a rather large research to trust and outsourced IS failures and my findings where that trust is paramount to the avoidance of a failure. Trust is a highly asymmetric construct: it is much easier to lose trust than to build up trust in a relationship. The agent will try to mitigate the risks of the outsourced contract just as the principal did. In his strive to reduce the intrinsic risks of an ERP project, the agent jeopardize  easily the trust within his relation with the principal.

Let’s face it: It is not possible to transfer all risks involved with an ERP project to one party, the consultant or ISV. Why is this not possible? Because the main reason for ERP failures is the lack of commitment of top management. In SMEs this is a non transferable duty of the owner/manager. It make no sense to ignore that fact or to cover it up with formal controls and other governance mechanisms. When the cat’s away the mice will play!

So is it wise to conduct ERP projects in a traditional principal-agent setting? Maybe the key to the solution is a tripartite with a principal (the SME), the agent (the ISV) and the mediator (the project leader). The mediator should be an independent party that acts only in the interests of the project. The three parties should be independent to each other and all should sign a threefold contract. Maybe that could help to distribute the risks of the project and to avoid failure.

jan

It was twenty years ago today, Sgt. Pepper taught the band to play. They’ve been going in and out of style…

Actually it was more than 25 years ago when I was graduated in Computer Science from university and got my first assignment. I was hired by a SME and independent software vendor to develop software for shop floor terminals (SFT). Since I got two degrees, one in electronics and one in computer science I was very well skilled in using new and higher programming languages for steering low level electronics like SFTs. I developed a complete operating system to offer a platform to develop applications for the 6509 Motorola processor, which was the heart of the SFT. My programming language at that time was C. An almost unknown language then, since most software was at that moment written in Assembler. I managed to installed a very good C cross compiler and wrote my software on a PC and not on a very expensive development system specially designed by the manufacturer. This wasn’t seen before!  I was considered a wonder kid and for me the sky was the limit. I would teach the band how to play.

The first end-user application that I wrote was for a bank. They requested a time registration system for their personnel. A quite controversial issue at that time, since it was not really done that ‘white collars’ had to go through a registration (control) system to keep track of all their actions (and movements). Electronic time registration was at the dawn of its inception and was only well known by ‘blue collars’ on a real shop floor in a production plant.

I wrote for nearly three months on the application when I finally could deliver the first version. The software kept track of the begin and end times of the working day for all employees. There was also a credit system for all employees by which they could go to the restaurant for a snack and for their lunches. The SFT kept track of the lunch pause and calculated the correct times and spendings. The local collected data on the SFTs was send by an own developed communication protocol to the central host computer where the payroll application processed the captured data.

My God, I took pride on that application! I had tested the software till my fingers bled from batching in and out. Nothing could go wrong on the day that I was supposed to installed the software into the terminals. I even developed a special app to load the software into the SFTs. Remember, this was prior to the Internet!

Before I could install the software, the hardware needed to be installed by the technical staff. Bur connections and cables where tested and everything worked fine. I got green light for installation. The next day I was already more than a hour earlier at the appointment and I checked the application in the operational environment. Guess what? It worked smoothly! Then the acceptation tests took place with the customer and the users.

Before we could go into the application the office manager made already a remark. He was responsible for the ergonomics in the workplace and took care for the environmental conditions of the offices. I was already surprised to hear what possible problems my terminals could have with problems of heating, ventilation and air-condition. I soon found out what the problem was. Not the software or the application, he never took notice of it, it was the … color of the terminals. The color was blue with yellow edges. It seems to me a very contemporary choice at that time. According to the office manager these colors could not be reconciled with the light brown colors of the walls. Anyway this was never an issue nor a requirement condition. And even if so, it was not something where I as a humble programmer had any experience to give some professional advice. Although I had to admit that the color palette of brown, blue and yellow was not a perfect match.

We spend more than three hours discussing how my SFTs could get another color. At a certain moment somebody even suggested to repaint the walls. I was not me. Then the meeting was closed and I got my first IS failure to take home.

Lessons learned.

IS failures have nothing to do with technology and are not equal to engineering failures. IS failures are an outcome of a human process. All different stakeholders have to find there correspondence in the information system before you can call it a non-failure (not equal to a success). The correspondences of all stakeholders find there roots in the social values their cultivate. For IT-ers this could be a flawless software, for the CEO this could main saving money, and for the office manager this meant a perfect match with the ‘right’ colors.

jan

Barcelona – ECIS 2012 – 11-13/6/2012

De European Conference for Information Systems (ECIS) met zijn +/- 600 deelnemers, 243 paper presentaties uit meer dan 50 verschillende landen moet zo wat de grootste Europese academische conferentie zijn over Information Systems Research. Dit jaar ging het evenement door aan de befaamde business school ESADE in Barcelona. Toch zal deze gebeurtenis ook dit jaar wellicht voorbij gegaan zijn aan de meeste IT professionals. Een kort verslag.
Dit jaar vierde ECIS zijn 20ste verjaardag. Dit feit werd even in de verf gezet met … wat dacht je?, een paper natuurlijk! Oudgediende Bob Galliers van Bentley University (VS) wist een jonge dame te strikken om wat veldwerk te verrichten over IS research de laatste 20 jaar. Wat leren we daaruit? Dat vooral de Angelsaksische landen de meeste IS research aanleveren, met op kop het Verenigd Koninkrijk (VK), gevolgd door Ierland en Australië en uiteraard de Verenigde Staten, maar die scoren vooral op de Internationale Conferentie for Information Systems (ICIS), grosso modo twee keer zo groot dan ECIS, maar daarover een andere keer meer. Daarna komen de Scandinavische landen aan beurt met Zweden, Denemarken en vooral Finland. Ook Duitsland laat zich niet onbetuigd met vooral stevig onderzoek in samenwerking met bedrijven. België is helaas nergens te bespeuren. Nederland daarentegen heeft ten minste nog wat gewicht in de schaal te gooien en organiseert de conferentie volgend jaar in Utrecht. De conferentie heeft in zijn 20 jaar België nog nooit aangedaan en zal dit de volgende drie jaren ook niet doen, want de plaatsen voor de komende jaren zijn al toegekend aan onder meer Tel Aviv.
We brengt ECIS aan research? Het zal de meeste praktijkmensen misschien verbazen maar IS academici zijn in eerste instantie veel meer begaan met methodiek en minder met inhoud. Meteen een discussiepunt van formaat. Wat moet primeren? De relevantie van de onderzochte onderwerpen of de wijze (de zogenaamde de grondigheid of de theoretische ‘stijfheid’) waarop het onderzoek wordt gevoerd? Geen eenvoudig te beantwoorden vraag. Van wetenschappers mag immers verwachten worden dat ze in eerste instantie uitpakken met gedegen kennis. Iedereen heeft wel een mening en een visie over IS, maar is dat dan ook de wetenschappelijke waarheid of juistheid? Anderzijds is kennis om de kennis een afgedaan hoofdstuk waar alleen nog een paar wereldvreemde academici van dromen. Zeker in het domein van IS steekt een flinke praktische kern. Informatiesystemen hebben immers een functie en worden in die zin ook ingezet in organisaties en overheden.
De meeste gebruikte onderzoeksmethode blijkt de case studie te zijn. Niet onmiddellijk de meest prestigieuze methode om met sterke veralgemeningen te komen, maar wel zeer efficiënt voor de aard van de materie waar er meestal meer variabelen dan gegevens moeten bekeken worden. Daarnaast zien we de focus meer en meer verschuiven naar design science en action research, waarbij de onderzoeker naast zijn onderzoek ook een artefact oplevert. Uiteraard sterk geapprecieerd door onze maatschappij die zich nog wel eens zou durven afvragen met wat die theoretici zich vandaag zo allemaal bezig houden.
Thematisch moet worden vastgesteld dat de focus zich meer en meer verlegd weg van de technologie en meer richting de gebruiker, nu algemeen ‘de mens’ genoemd. De gebruiker was een uitvinding van ingenieurs die daarin een model van ‘de mens aan de machine’ zagen. Belangrijke thema’s zijn nu e-Health (Europa wordt oud), sociale media (moet er nog zand zijn?) en Enterprise Systems (wanneer krijgen we eigenlijk een ROI van IT?).
Een ander thema dat onze academici wereldwijd enorm bezig houdt is de wijze waarop ze zich profileren en dus laten evalueren. Dit blijken dus publicaties te zijn. Een gevoelig onderwerp waar reeds veel inkt is over gevloeid. Wetenschappers schrijven hun bevindingen neer in artikels en die moeten vervolgens geëvalueerd en vooral gepubliceerd worden. Dat laatste is het belangrijkste! Leuk vast te stellen dat ook dat wordt onderzocht. En wat blijkt? Dat 50% van alle IS researchers helemaal niet weten hoe ze zullen worden geëvalueerd en dus maar massaal aan het publiceren slaan. Als hun naam maar onder een artikel staat en ergens in een tijdschrift van A-niveau verschijnt. Hoe meer citaties een artikel heeft hoe beter, dus citeren we onszelf. 90% van alle IS-academici slagen er niet in een A-artikel als eerste auteur te publiceren. Een even groot gedeelte slaagt er maar in één A-artikel in hun gehele carrière gepubliceerd te krijgen. Het is dus drummen aan de top. Er worden daarom deals gemaakt en auteursgroepen gevormd waarbij zoveel mogelijk ‘auteurs’ hun naam onder een titel plaatsen. Met als gevolg dat 30% van alle academici hierdoor in een conflictsituatie verzeild geraakt. Een enkeling in de zaal merkte op (via een tweet) dat dit een gigantisch ethisch probleem vormt. We zijn een groep individualisten en collectief werk is niet aan ons besteed riep iemand in de zaal.
Over naar de inhoud.
Uiteraard is het onmogelijk om alle tracks, laat staan alle paperpresentaties te beluisteren op een dergelijk mega-event. We kozen voor Enterprise Information Systems (EIS), IS Security (ISS), IT Project Management (IPM), Serious Gaming (SG) en Research Methods (RM).
Het blijft huilen met de pet op inzake EIS. Succesverhalen worden opgevolgd door minder succesvolle verhalen. KMO’s doen het volgens een enkeling beter dan grote bedrijven maar veel bijval kende de man helaas niet. IPM staat in relatie met het vorige. Immers alvorens een IS in een organisatie kan worden gebruikt gaat daar meestal een project aan vooraf. En dat project is meestal, hoeft het nog gezegd, niet erg succesvol. Dus maar experimenteren met alternatieve methoden. Een paar leuke suggesties werden gemaakt. Zoals het uittesten van de theorie van dramaturgie als een alternatieve verklaring voor het verloop van een IT project. Of het IKEA-effect, waarbij een ontwerper meer belang hecht aan een object dat hij zelf gemaakt heeft. Ingenieurs zullen dit bijna zeker weer allemaal als niets ter zake doend van tafel vegen. Toch vertrekken deze onderzoekers van zeer relevante onderzoeksvragen. Onder meer waarom er zoveel IT projecten mislukken? Is de ingenieursaanpak dan zo superieur? Eén onderzoeker stelt voor dat we projectteams recycleren op basis van succesfactoren. Het idee van ‘never change a winning team’ dus.
Over IS security kunnen we kort zijn. Niets nieuws onder de zon. Security is weliswaar belangrijk, maar blijkbaar niet echt om onderzocht te worden. De outsourcing ervan verloopt zoals een ander project en security is vooral een issue voor de IT-sector.
Serious gaming wint zeer voorzichtig terrein. Vanuit een business perspectief wordt daar uiteraard zeer argwanend naar gekeken. Net zoals social media trouwens. Business is tot nader order nog steeds geld verdienen en voorlopig lukt dit niet met spelletjes en met Facebook. Tenzij je Marc Zuckerberg bent natuurlijk en Facebook uitvindt, maar dit werd niet onderzocht. Leuk was dat de theorie van misdaad werd aangehaald om het verschijnsel ‘illegale download’ te verklaren.
Steven Alter, een professor uit San Francisco pakte uit met een titanenwerk en presenteerde een ‘body of knowledge’ voor IS. Spectaculair, maar helaas kreeg hij weinig bijval. Hij negeerde dan ook volledig de gedragsmatige component in zijn oeuvre.
Er waren nog heel wat pareltjes van onderzoek te ontdekken. Zoals collega Hans van der Heijden van de universiteit van Surrey die een experiment uitvoerde met de Amazon Mechanical Turk en dat op een meesterlijk wijze wist te presenteren. Hij wist de bestaande modellen van technologie acceptatie sterk te relativeren en toonde de sterkte van een statistisch onderzoek. Ook het vermelden waard waren de presentaties over Design Science Research. Het lijkt erop dat deze vorm van onderzoek wellicht de discipline zal domineren.
De keynotes vielen zowel mee als tegen. De gekozen onderwerpen waren zeer relevant: big data problems (getuigenis CERN), service science (Henry Chesbrough) en ‘Apps for Democracy’. De eerste twee sessies werden zeer steriel gebracht, ondanks hun sterke inhoud. Enkel Peter Corbett, een jonge ex-werkloze, geek, nerd en enterpreneur-by-coincidence wist te boeien met het verhaal over zijn opdracht dat hij van Obama zelf kreeg.
Al bij al zeer interessant en zeker een must voor elke IS-er.
jan devos

Latest presentation on Bricolage and Engineering

http://www.slideshare.net/jandevos/engineer-or-bricoleur

 

%d bloggers like this: