Verhuur managment software

Greendiek schreef:

Het management wou ook voor de uitstraling naar buiten toe voorkomen dat er met excel gewerkt achter de balie (dit vonden ze erg knullig overkomen).

JeroenVDV schreef:

Liever een fatsoenlijk vormgegeven, ingericht en gedata-linkte Excel spreadsheet dan een gedrocht van een verschrikkelijk systeem als RMS in ieder geval in het verleden was.

JeroenVDV schreef:

Liever een fatsoenlijk vormgegeven, ingericht en gedata-linkte Excel spreadsheet dan een gedrocht van een verschrikkelijk systeem als RMS in ieder geval in het verleden was.

Greendiek schreef:

Ik heb gedurende stage's in mijn opleiding met verschillende systemen gewerkt. Het wordt ook wel omschreven als een MIS (Management Informatie Systeem) of FMIS (Facilitair Management Informatie Systeem).

TB schreef:

Ik proef frustratie . Je moet er even mee leren werken idd haha .

JeroenVDV schreef:

Die software was met versie RMS24 gewoon amateuristischer dan wat een gemiddelde middelbare scholier met een goedkoop database-programma knutselt. Geloof wel dat ze met RMS25 heel wat op de schop hebben gegooid, maar "gebruikersvriendelijkheid" is een woord dat ze daar niet kennen en wat "workflow" betekent is volgens mij een even groot raadsel daar.

Zal best heel goedkoop zijn, maar ik denk dat je voor dat geld + alle extra uren die zo'n inefficiente workflow je kost een klein ICT-bedrijfje een op-maat gemaakt database systeempje laat maken. Er zit namelijk ECHT niks intelligents in, het is pure administratie software. Records lezen, schrijven, koppelen en queries uitvoeren.

CyberDance schreef:

Materialen, klanten en locaties uit een database oproepen en samenvoegen in een lijstje is voor iedere programmeur eitje, maar zodra er functies als voorraadbeheer etc om de hoek komen kijken wordt het toch allemaal wat lastiger in mekaar steken dan het lijkt. Geloof me. Been there, done that.

Roytje schreef:

Inderdaad een mooie opsomming van keuzefactoren. Welk systeem heb je het bedrijf van je stage dus uiteindelijk geadviseerd en waarom?

CyberDance schreef:

Mijn opzet was overigens wel om het volledig in PHP/Mysql op te zetten. Dat het mogelijk is weet ik (maak gebruik van een programma dat ook volledig zo opgezet is voor de ICT business), maar toch schrikt het een hoop programmeurs af.

Als je een beetje handig bent met excel klus je op een namiddagje een complete invoer sheet in mekaar met artikel, klanten en locatie"database"erachter, met daarbij de verschillende offerte/contract en factuur layouts. Dan is het kwestie van invullen en bijhouden. Voor simpele showtjes en verhuurwerkzaamheden heb je tenslotte niet meer nodig.

Nadelen:
* Geen voorraadbeheer
* Niet centraal, dwz veel losse files en minder overzicht.
* Agenda bijhouden in bijv. outlook voor het overzicht is redelijk noodzakelijk.

Roytje schreef:

Ook personeelsplanning wordt lastig, financieel overzicht in een project ontbreekt (personeel houd je los bij van je inhuur, enz.) snel zien wat er beschikbaar is op een bepaalde datum kan niet en zo kan ik nog wel even doorgaan.

CyberDance schreef:

Als je een pakket gaat aanbieden naar het brede publiek moet het naar mijn idee wel schaalbaar zijn. Veel grote bedrijven zijn immers klein begonnen. In het huidige aanbod van goed functionerende verhuursoftware ontbreekt nou juist de stap waarin men klein kan beginnen. Bij de goedkopere pakketten zijn de uitgebreidere functies waardeloos of onvoldoende uitgewerkt om bruikbaar te zijn, wat maakt dat je hoe dan ook zowat verplicht bent om een keer te gaan schakelen.

Als de basis staat wordt het pas écht lastig. Een RMS doet, zodra je het op de rit hebt, in de basis opzich ook prima wat het moet doen. Job aanmaken, klantje en locatie invoegen uit database, artikelen erin kloppen appeltje eitje. Niet uiterst geavanceerd maar het gaat ansich prima. Tot je wijs probeert te komen uit de jobplanner, aan de gang gaat met inhuur, grotere projecten, grootschalig wijzigen van materiaallijsten, artikelen tussenvoegen etc, dan wordt het drama.

Wat doe je met artikels die wijzigen (dat kan prijs zijn, dat kan omschrijving zijn, etc), als je iedere job kaal uit je artikeldatabase oproept adv een ID (lekker makkelijk scripten zeker voor het mogelijk maken van wijzigingen in de materiaalijst, qua belasting voor je databeest alweer wat minder) krijg je serieuze issues bij prijswijzigingen, je oude reeds gefactureerde jobs hebben dan plots ook een totaal ander eindplaatje, of de prijs van je offerte is anders dan die op je factuur

Onderschat ook vooral het support vlak niet. Daarmee staat of valt je software, dat zijn een aantal partijen nu aan het ondervinden :-) Ook bij online pakketten een niet te ondeschatten punt is storingen, dat kan een hoop heibel opleveren als je je platform niet op orde hebt aangezien we hier spreken over een cruciale applicatie binnen een bedrijf. Maar het kan ook zo simpel zijn als een ADSL lijn er een dag of langer uitligt (buurmant verbouwt stoep en hakt op vrijdag om 15.45 wat kabels door, ben je maandagochtend de eerste).

Klopt, maar personeels en transportplanning was ik voor dit geval ook nog niet eens van uit gegaan als functionaliteit voor een simpele drive-in show.