Voorafgaand aan de selectie van een systeem moeten een aantal afwegingen gemaakt worden die bepalend zijn als uitgangspunten voor de selectie.

1. Het platform waarop het systeem moet gaan draaien
2. Standaard applicatie of maatwerk
3. Een terminal server applicatie of een client/server applicatie
4. Eigen beheer of beheer uitbesteden
5. Afhankelijkheid van leveranciers (customer lock-in)
6. De interactie van een systeem met andere systemen
7. Intern of extern gebruikt
8. Web-enabled of webbased

Er zijn uiteraard meer keuzes die gemaakt moeten worden bij de aanschaf van een systeem, maar de belangrijkste afwegingen hebben we hier wel opgesomd.

We zullen de punten hieronder nader bespreken



Het platform waarop het systeem (en eventueel clients) moet gaan draaien

Het platform bepaalt in eerste instantie het aanbod van applicaties. Onder het platform verstaan we bijvoorbeeld een Operating System (zoals Windows NT, Mac OS of Linux). De kans is groot dat u al systemen heeft draaien op een bepaald platform. In dat geval zal het voor de hand liggen om op dit platform te blijven draaien. Anders zou u een extra platform krijgen, hetgeen weer extra onderhoudskosten met zich mee kan brengen.


Standaard applicatie of maatwerk

De kans is groot dat er al een systeem bestaat dat grotendeels voldoet aan uw vraag. Daarom is het altijd zinnig om voorontwikkelde standaard systemen te inventariseren. Deze systemen moeten dan wel beschikbaar zijn voor het platform waarop uw andere systemen draaien. De kans is echter ook groot dat standaard systemen een heleboel functionaliteit bevatten die u niet zult gebruiken en die niet voldoen aan bepaalde eisen die u stelt. Daar betaalt u dan wel voor. In dat geval kan een dergelijk standaard systeem misschien aangepast worden aan uw eisen (ook wel: "Standaard maatwerk" genoemd). De vraag is dan of dit uiteindelijk niet zoveel extra kosten met zich meebrengt dat een compleet maatwerk applicatie interessant wordt.
Ook bij het uitvoeren van updates bij standaard maatwerk rijst vaak de vraag (of discussie) of deze updates niet interfereren met de aanpassingen aan het systeem en of u dus mee kunt blijven doen met standaard updates. En of men kosteloos recht heeft op updates die voor het standaard systeem gemaakt zijn, als deze aangepast moeten worden voor het maatwerk.
De realiteit is dat na installatie van maatwerk men vaak door voortschrijdend inzicht toch bepaalde zaken aangepast wil zien. Bekijk dus vooraf goed of dit achteraf kan en of dit qua kosten nog voordelig uit zal pakken.


Een terminal server applicatie of een client/server applicatie

Een client/server applicatie heeft als eigenschap dat de gebruiker op een eigen computer (de "client", meestal een desktop of laptop) een programma heeft draaien dat via een netwerk verbinding contact maakt met een server applicatie. De client applicatie bevat vaak de functionaliteit en schermen die de gebruiker nodig heeft om zijn taken te kunnen uitvoeren, terwijl de server applicatie vaak centraal de data bevat die bewerkt wordt met de client applicatie.
Deze structuur is interessant op het moment dat men met meerdere partijen over dezelfde data moet beschikken, maar zware applicaties moet draaien op een lokale client voor de verwerking ervan. Ook als men tijdelijk niet verbonden is met de server en data op de client machine opgeslagen kan worden, kan men bijvoorbeeld bij een netwerk storing of op een externe locatie zonder netwerk verbinding, toch doorwerken.

De voordelen hiervan zijn dat men de computerkracht van de lokale computer gebruikt voor bewerkingen. Daarnaast kan men vaak offline doorwerken als men data lokaal kan opslaan. Een groot nadeel van deze opzet is dat met de algemene ontwikkeling in toenemende kracht van computers, vaak de applicaties ook zwaarder en groter worden. Dit heeft invloed op de benodigde rekenkracht van de processor, de grootte van het interne geheugen en de opslagcapaciteit van de harde schijven. Dit betekent vaak dat met upgrades van software pakketten, ook de client computers een hardware upgrade moeten krijgen om de pakketten aan te kunnen. Daarnaast betekent dit dat een upgrade in de client software er toe leidt dat iemand alle PC's af moet lopen (al dan niet fysiek) om de upgrades uit te voeren.

Een terminal server applicatie wordt meestal in zijn geheel op de server gedraaid. De terminals, ook wel "domme" clients genoemd, maken uitsluitend verbinding met de server om de schermen te laten zien die de server genereert. Elk commando van de terminal wordt op de server uitgevoerd. De applicatie en data zijn beide centraal beheerd op de server. De voordelen zijn dan ook dat de terminals nauwelijks processorkracht of opslag capaciteit hoeven te bezitten. Al het rekenwerk wordt tenslotte op de server gedaan en de applicaties en data staan beiden op de server.

De voordelen zijn duidelijk; de clients hoeven geen zware computers te zijn, wat kosten kan besparen. Daarnaast kunnen updates voor zowel data als de applicatie op de server uitgevoerd worden waardoor elke gebruiker altijd met dezelfde functionaliteit en data werkt.
Het nadeel is uiteraard dat er altijd een netwerk verbinding moet zijn om gebruik te kunnen maken van de applicaties op de server.
(Lees meer technische informatie over client/server architectuur.)


Eigen beheer of beheer uitbesteden

Hoe bedrijfskritisch is de applicatie? De afhankelijkheid van de organisatie van de werking van de applicatie bepaalt in grote mate het belang van directe ondersteuning bij uitval van het systeem. Hoe snel moeten deskundigen fouten kunnen opsporen? Moeten uw leverancier dit ter plaatse doen of kan dat op afstand via een Internet verbinding? Kunnen zij dan zowel bij de server als bij de client applicaties? Wat te doen als de client applicaties over meerdere locaties verspreid zijn en deze ook nagekeken moeten worden? Wat te doen als in deze situatie een verbinding voor externe support onmogelijk is? Hoe snel kan men dan ter plaatse zijn? Biedt men alleen support op werkdagen tussen 9 en 5? Of ook 's nachts en in het weekend?

Dit zijn vragen die gesteld moeten worden als men gebruik maakt van de support afdeling van een externe partij (al dan niet de leverancier van uw systeem). Maar ook bij intern beheer zijn sommige van deze vragen bijzonder relevant! Daarbij is het de vraag of de kostenafweging van het in eigen beheer hebben van support in relatie staat tot de afhankelijkheid van het systeem. De afwegingen hierin zult u bewust moeten maken bij de keuze voor uw leverancier.


Afhankelijkheid van leveranciers (customer lock-in)

In hoeverre bent u na de aanschaf van het systeem nog afhankelijk van die leverancier. Bij een afhankelijkheid van de klant aan de leverancier, spreekt de leverancier vaak over customer lock-in. Naarmate deze afhankelijkheid groter is, zal het voor de klant moeilijker of kostbaarder zijn om met een andere partij in zee te gaan. Het is duidelijk dat vraag en aanbod hierbij een grote rol spelen. Hierbij moeten ook een aantal vragen beantwoord worden. Bent u afhankelijk van updates? Bent u afhankelijk van specifieke platformen van uw leverancier voor het draaien van het systeem? Beschikt uw leverancier over zeer specifieke kennis, of gebruiken ze technologieën die andere aanbieders niet hebben? Heeft een grote afhankelijkheid consequenties voor kosten die in de toekomst gemaakt moeten worden of ondersteuning die in de toekomst gewenst is?

Als klant bent u uiteraard het beste af als u niet afhankelijk bent van uw leveranciers. Daarom is het zaak om een keuze te maken voor een systeem waarbij u zonder het systeem af te schrijven kunt overstappen naar een andere leverancier.


De interactie van een systeem met andere systemen

Is het de bedoeling dat het systeem informatie kan uitwisselen met andere systemen? Wordt het systeem een onderdeel van een groter bedrijfsproces waarbij informatie uit eerdere deelprocessen in het system geïmporteerd moeten kunnen worden, en waarbij output van het systeem gebruikt wordt in opvolgende deelprocessen?

Zo ja, dan zal het systeem gebruik moeten maken van "open standaarden" voor het uitwisselen van informatie, zodat het ontwikkelen van ingewikkelde interfaces (en daarmee samenhangende kosten) niet nodig zijn. Gebruikelijke protocollen, om informatie tussen systemen uit te wisselen, zijn bijvoorbeeld XML en SOAP of via vooraf gespecificeerde tekstbestanden zoals "Comma Separated Files".
Informeer dus goed of deze mogelijkheden aanwezig zijn en of uw leverancier zich hierbij aan internationaal gespecificeerde standaarden houdt. Ook als u deze koppelingen wellicht nog niet nodig heeft is het goed om op de toekomst voorbereid te zijn.


Intern of extern gebruik

Waar en door wie wordt uw systeem gebruikt? Zijn alle gebruikers altijd lokaal aanwezig of moeten gebruikers ook vanaf externe locaties toegang kunnen hebben tot het systeem? Als men uitsluitend lokaal toegang moet kunnen hebben tot het systeem, zal dat waarschijnlijk via een bestaand bedrijfsnetwerk gebeuren.
Het kan daarentegen zeer interessant zijn om uw gebruikers direct te koppelen aan uw bedrijfsprocessen. Zo kunnen klanten bijvoorbeeld de status van hun bestellingen zien of de laatste planningen bekijken. Dat scheelt vaak een heleboel telefoon verkeer voor uw collegas. Of u laat uw leveranciers zelf hun verwachtte levertijden invoeren zodat u en uw klanten altijd de laatste inzage hebben in leveringen. En zo zijn er legio voordelen te bedenken.

Als men echter vanaf een externe locatie toegang moet kunnen krijgen zal dit zeer waarschijnlijk via een Internet verbinding gebeuren. Hoe moet deze verbinding vanaf een externe locatie tot stand komen? Gaat dat via een (beveiligde) webpagina of via een VPN verbinding met het bedrijfsnetwerk?

De keuze wordt bepaald door een aantal omstandigheden: Biedt u uw klanten of leveranciers ook toegang tot uw systeem? In dat geval is het systeem uiteraard extern te benaderen. Vervolgens is het van belang waar het systeem draait. Wordt het systeem binnen het eigen netwerk gehost of op een externe server (bij een hosting partij). Als het systeem binnen het eigen netwerk gedraaid wordt is het zaak om de interne server bereikbaar te maken van buitenaf. Maar uiteraard wel op zo'n manier dat andere interne databronnen niet toegankelijk zijn. Afhankelijk van uw netwerk configuratie kan uw leverancier u daar het beste in adviseren. Indien u er voor kiest om uw systeem extern te hosten, zullen uw klanten eenvoudig met een browser kunnen inloggen op uw systeem en uw gegevens kunnen raadplegen. De volgende vraag is dan of uw systemen web-enabled moeten zijn of webbased.


Web-enabled of webbased?

Onder web-enabled verstaan we die systemen die in de basis niet op webtechnologie gebouwd zijn, maar het wel mogelijk maken om informatie te ontsluiten voor het web. Deze system kunnen vaak hun output ook direct genereren naar HTML zodat dit in browsers te bekijken is. Webbased systemen daarentegen zijn vanaf de grond opgebouwd in webtechnologie en kunnen derhalve ook als zodanig gedraaid worden op webservers. Over de voor- en nadelen van beide systemen gaat de volgende pagina...