Kunnen inspelen op een continu veranderende wereld is geen optie. Het is hét criterium voor het opstarten én onderhouden van een succesvolle business. In de woorden van Darwin:

Business modellen moeten steeds heruitgevonden worden. Interne processen moeten hertekend worden. Niet innoveren in een constant veranderende wereld is achteruit gaan. En dat zeker in de laatste decennia waarin alles aan een record temp wijzigt.

Meer dan ooit is wendbare software op maat een troef om het verschil te maken. Voor al wat commodity is bestaan er schitterende standaard pakketten. Maar als je bedrijf enkel uit commodity bestaat, wat is dan je bestaansreden? Door te innoveren breek je op bepaalde vlakken uit standaard patronen. En doordat je uit standaard patronen breekt, ben je (op bepaalde vlakken) niets met standaard software pakketten.

U wil als eerste fruit online verkopen? U wil uw interne processen verbeteren door middel van gebruik van eID? U wil uw klanten een bijzonder goede service bieden waarbij ze online de status van hun bestelling kunnen opvolgen? U wil een iPhone applicatie om klanten beter op de hoogte te houden? Telkens opnieuw een razend interessant concurrentieel voordeel. En dus telkens ook iets waarvoor geen standaard pakket bestaat. Indien er een standaard pakken voor zou bestaan, was het geen concurrentieel voordeel!

Door zijn business af te stemmen op wat “de standaard” informatica pakketten bieden, stem je je business af op de commodity. Je business wordt niet efficiënter dan de concurrentie, wordt niet innovatiever, beter, goedkoper of creatiever. Enkel door verder te denken dan wat bestaande oplossingen bieden, kan je je concurrentie beter afzijn.

Ruby on Rails (RoR) is een web applicatie framework: een stevige verzameling code die toelaat om op een zeer efficiënte en doelgerichte manier web applicaties te maken. Ruby on Rails focust sterk op het ondersteunen van de business en het oplossen van problemen door middel van IT en (web) applicaties. Deze business oriëntatie en filosofie zit in Ruby on Rails ingebakken door middel van volgende eenvoudige principes:

• Don’t Repeat Yourself (DRY): informatie, code, business logica en layout wordt slim gebundeld en verzameld op centrale plaatsen in de architectuur van de applicatie. Hiernaar wordt vanuit de rest van de code verwezen. Dit betekent dat een wijziging in je bedrijfsproces, in de business logica, in de code, of in je kleurenschema steeds maar op één centrale plaats moet gebeuren. Een veranderende business vraagt een flexiebele applicatie.
• Convention over configuration: Rails vraagt je geen overbodige zaken te configureren die er in 99% van de gevallen niet afwijken van “het typische scenario”. In een applicatie om foto’s te beheren, gaat Rails er van uit dat je (1) foto’s kan uploaden, (2) foto’s kan bewerken, (3) foto’s kan verwijderen en (4) je foto’s kan bekijken. Hiervoor moet je als developer niets doen. Rails neemt dat aan, aangezien dit voor 99% van de gevallen zal kloppen. Moest je toch willen afwijken van wat Rails standaard voorziet, dan kan dat uiteraard. Werken met zoveel mogelijk “conventies” en dus minder “configuratie”, zorgt voor minder code. Minder code is minder frustratie, problemen, verrassingen, maintenance, vergissingen. En dus meer tijd voor je échte business.
• Test driven development: Rails moedigt developers aan om automatische testen te schrijven, en voorziet out of the box een mooi test framework. Deze geautomatiseerde testen gaan de applicatie zeer regelmatig testen. Bij een groeiende en meer complexe applicatie wordt het voordeel hiervan zeer duidelijk: je laat je testen lopen, en op enkele minuten gaat een “robot” heel je applicatie na op bugs, fouten of onverwachte scenario’s. Eventuele problemen kunnen snel ontdekt worden. Dit geeft beslissingsnemers een gerust gevoel wanneer aan de business logica wordt gesleuteld die gevolg heeft op de code. De automatische tests geven ons eventuele problemen aan, ook inconsistenties in de business logica. Ook kunnen er wekelijks nieuwe functionaliteiten gereleased worden, zonder dat een 10-koppig test team telkens door de hele applicatie moet gaan om na te gaan of er nergens problemen opduiken. Dat doet onze geautomatiseerde test omgeving wel wekelijks voor ons!

Hierboven: 467 tests, waarin 686 “assumpties” over de code en business logica positief verlopen. En dat in 38 seconden! Een mens doet hier enkele dagen over. Alle testen zijn “groen”: we kunnen met een gerust hart de code online zetten.

Rails geeft developers de mogelijkheid om meteen op de business logica te gaan focussen. Zaken zoals paswoord management voor gebruikers, converties naar XML, API’s, overbodige configuratie en vaak terugkerende stukken code die onafhankelijk zijn van de business worden allemaal voorzien, telkens met als doel het ontwikkelings team te ontlasten van niet project specifieke taken en beslissingen.

Daarnaast moedigt Rails agile ontwikkeling aan: de brug tussen de ontwikkelaars en de klant wordt zo klein mogelijk gehouden, door middel van vele, snel op elkaar volgende releases en feedback rondes. Feedback van de klant kan snel in rekening worden gebracht, waardoor het project snel kan bijgestuurd worden. Hoe vroeger een fout wordt rechtgezet, hoe minder duur de fout is. Rails doet er alles aan om flexiebel en “vinnig” te zijn, en slaagt hier bijzonder goed in.

Daarnaast is Rails open source. En dat blijft niet bij een theoretisch principe. Een hele gemeenschap van ontwikkelaars deelt op Github stukjes interessante en business onafhankelijke code. Andere developers verbeteren deze code, of breiden ze uit. Na verloop van tijd zijn er honderden interessante, herbruikbare componenten ontstaan die je in je Rails applicatie kan gaan aanwenden, waardoor je weer beter op je eigen business logica kan gaan focussen. Er zijn ook nieuwe frameworks ontstaan bovenop Rails, zoals Spree voor e-commerce of Radiant voor CMS, die een stevige basis vormen voor zulke projecten.

Tot dat iemand me van het tegendeel kan overuigen, ken ik geen beter framework voor complexere (web) applicaties die steeds veranderende business, processen, wereld of markt moeten ondersteunen…

Zoals overal, zijn er ook in software development veel dingen kan je onmogelijk op voorhand plannen. Denk maar even aan de renovatiewerken die je ooit hebt laten uitvoeren, of de bouw van je huis. Zelfs niet met een 300 pagina’s dikke functionele design en technische analyse kan je heel het project uitstippelen. En dat is precies het probleem dat agile ontwikkeling wil aanpakken. Planning is guessing. De weg die je op voorhand uitstippelt aan de hand van een gedetailleerde functionele design wordt toch nooit bewandeld. Er zijn onderweg altijd bijsturingen nodig. Die vangen we op door onderweg feedback te vragen en bij te sturen. We proberen niet eens om de weg uit te stippelen. Agile software ontwikkeling.

Daarnaast is het zo dat gaandeweg een project, zeker bij grotere projecten, de functionele vereisten wijzigen. Dit omdat het in het begin nog niet helemaal duidelijk was wat nu eigenlijk de bedoeling was van de software, omdat er nieuwe elementen opduiken die invloed hebben op de uiteindelijke vereisten. Agile ontwikkeling speelt hier mooi op in, aangezien de functionele vereisten pas gaandeweg worden bepaald.

Echter, ik vind het een probleem als Agile ontwikkeling een excuus wordt om helemaal geen functionele of technische analyse te doen. Er zijn namelijk een heel aantal zaken die je wél perfect op voorhand kan uitstippelen. Agile ontwikkeling is geen reden om de functionele design over te slaan. Een document van een paar pagina’s met een redelijk gedetailleerde uitwerking van de gewenste functionaliteiten is niet overbodig. Agile ontwikkeling is geen reden om helemaal geen technische analyse te doen. Bepaalde belangrijke technische keuzes kunnen pas correct gemaakt worden als er wél een volledig helikopter overzicht is van de volledige scope. Het is dus heus niet overbodig om de data die je ter beschikking hebt en de business logica die later met die data zal werken, even nader te bekijken.

Een goede functionele en technische analyse zorgen ervoor dat je koers zet in de juiste richting, zonder over details te praten. Agile ontwikkeling kan/moet gaandeweg die koers nog bijsturen. Maar als je op basis van “gevoel” en “Agile-we-zien-wel-na-de-eerste-iteratie” je koers kiest, kan je wel eens de verkeerde koers kiezen. Ik geloof dat een deftige functionele en technische analyse vòòr de eerste letter code het project serieus kunnen inperken qua tijd, kost, frustratie en misverstand. Ik geloof ook dat agile ontwikkeling nodig is om het project, na de eerste letter code, op koers te houden, en rekening te houden met onvoorziene omstandigheden die tijdens de functionele en technische analyse niet duidelijk waren.

Een onderzoek van Boston Consulting Group toont aan dat België redelijk wat achter staat op gebied van internet economie, e-business en e-commerce. Het online aanbod groeit zeer geleidelijk, terwijl het aantal internetgebruikers en het vertrouwen in de markt elke dag groeit. Er zijn voor KMO’s dus nog heel wat mogelijkheden op Belgische internetmarkt. Ook blijkt dat KMO’s en bedrijven die het internet juist gaan inschakelen in hun strategie of hun operations, een stuk competitiever staan dan hun concurrenten.

Meer info en het volledige rapport van BCG op www.interneteconomy.be

Niemand. Niemand wordt écht graag onderbroken voor een email of een grappig reclamefilmpje, een radiospot of TV ad. Zelfs een gratis staaltje van het een of ander is meestal irritant. Denk even aan de vriendelijke dame of heer die je in de supermarkt een gratis toastje met zalm laat proeven – nét wat ik nodig had op een drukke zaterdagochtend! Er wordt te veel gemarked. Te veel emails, flyers, presentaties, radiospots, TV trailers, Google Ads, banners en gratis T-shirts en balpennen. Marketing en reclame komt zo goed als altijd ongelegen. Mensen zijn dat beu. Er scheelt iets met de klassieke manier van marketen.

De beste marketing volgens mij, zeker voor een startup, is je klanten overladen met waarde, service en oplossingen. Toon hen je commitment. Verras hen tot ze “wow” zeggen. Toon hen dat je van hun probleem, jouw probleem maakt. Dit is alvast wat we nastreven met Zorros en Fikket. Soms mislukt dit, soms lukt dit. Een feit is dat we er steeds beter in worden. Het is ons streefdoel. En klanten voelen dat. Dàt is jezelf marketen.

Je mag als startup echter niet de vergissing maken van helemaal geen marketing te doen. Je moet op een of andere manier wel in de hoofden van je toekomstige klanten belanden, zodat ze, de volgende keer dat ze een dienst nodig hebben die jij levert, aan je denken. Maar doe dit leuk en zoek iets a-typisch. Dat hoeft daarom niet veel moeite en geld te kosten. Bij Zorros bijvoorbeeld hadden we het idee T-shirts te drukken…tot we beseften dat mensen die toch nooit aandoen omdat:

1. het in België meer wintert dan zomert, dus mensen dragen die T-shirt altijd onder iets.
2. het altijd veel te duidelijk is dat het een gesponsorde bedrijfs T-shirt is, dus die T-shirt komt dan toch maar op de stapel van “gratis gekregen T-shirts” te liggen die men enkel aandoet als men behangt of de muren gaat schilderen.

Dat hebben we als volgt opgelost

1. Geen T-shirt, maar een (weliswaar iets duurdere) sweater
2. Enkel ons logo, geen tekst of typische reclameslogan, zodat de sweater als het ware niet gesponsord lijkt door een bedrijf.

Resultaat? De sweaters worden met plezier gedragen, mensen vertellen erover (“gratis gekregen van die mannen van Zorros”), en we stick into their head.

En zoals gezegd: behalve het drukken van die sweaters gaat al onze energie naar échte waarde creatie.

Fact: Mensen zijn lui en ongeduldig.

Hoe sneller hoe beter. Als een website 1 seconde hapert worden we redelijk ongeduldig. Bij de tweede seconde volgt er een *zucht*. Bij seconde nummer 3 klikken we gefrustreerd op “back”. Hoe minder clicks hoe beter. Hoe eenvoudiger hoe beter. De “Like” button van Facebook is niet toevallig ontstaan: door de interactie met de gebruiker te beperken tot een eenvoudige klik, wordt er veel meer geïnterageerd. Zo hoeven de luie gebruikers niet telkens iets neer te pennen. Gewoon “Like” klikken volstaat al. Snel en efficiënt.

Hou rekening met luie klanten!

Vraag van je (toekomstige) klanten niet te veel. Maak de drempel om geld uit te geven zo laag mogelijk. Elke virtuele drempel, hoe klein ook, is een moment waarop gebruikers mogelijks afhaken.

• Zorg dat het niet meer dan een paar klikken kost om een gebruiker aan te maken.
• Zorg dat online betalingen eenvoudig en voor de hand liggend werken. Volg hierbij de juiste design patterns.
• Vraag zo weinig mogelijk gegevens om in te vullen bij online bestellingen, zodat dit geen klanten afschrikt. Email, naam, en adres zouden moeten volstaan. Andere optionele velden kunnen, maar maak ze niet verplicht om de drempel tot aankoop laag te houden. Duid ook duidelijk aan dat ze niet verplicht zijn.
• Werk niet met (ingewikkelde) invite-systemen waarbij gebruikers enkel via een registratie-code een user kunnen aanmaken zolang daar geen goede reden voor is. Ik weet het: Google werkt wél zo. Maar de kans is groot dat u niet Google bent, maar wel een startup die zich nog moet bewijzen.
• Leid klanten doorheen hun aankoop aan de hand van duidelijke en eenvoudige stappen. Elke scherm is een mogelijk scherm waarop ze afhaken, dus hou het aantal schermen indien mogelijk beperkt.
• Zet op elke pagina je contactgegevens (onderaan bijvoorbeeld), zodat luie klanten die vastlopen op elk moment je zonder veel moeite kunnen contacteren. En antwoord hen asap. Goede klanten support doet enorm veel. Ikzelf tracht altijd zowel meteen te antwoorden als mogelijk. Je kan je niet voorstellen hoeveel mensen verbaasd zijn dat ze meteen antwoord krijgen. Ze antwoorden vaak met een “leuk dat je zo snel antwoord!” of “bedankt voor je snelle antwoord”.

Nog best practices?

Noot: lui zijn is volgens mij geen negatieve eigenschap. In tegendeel: om efficient en effectief te zijn, moet je een op een of andere manier “lui” zijn. Excuses aan al mijn klanten die zich beledigd zouden voelen.

Gebruikers of klanten van je e-commerce website, software of web applicatie maken geen verschil tussen “de software” en “de helpdesk”. Voor hen is dat één en dezelfde gebruikers-ervaring. Indien ze vragen hebben over het gebruik van je software of website, dan willen ze die eenvoudig en snel kunnen stellen, en vooral snel antwoord krijgen. Zorg ervoor dat klanten die met een vraag of probleem zitten, snel geholpen worden. Dit is eens zo belangrijk als een mooie en goede webapplicatie of software op zich. Velen focussen zich vooral op ontwikkeling van de software. Echter, een vriendelijke stem aan de helpdesk die u een welgemeende prettige dag wenst nadat uw vraag is opgelost, kan wonderen doen!

Het is makkelijk om je te verschuilen achter een website, en een FAQ online te zetten waarmee klanten zich maar moeten behelpen. Het is veel minder leuk en makkelijk om telefoons op te nemen of de meest onnozele vragen te beantwoorden via email. Vragen die soms niets met uw software te maken hebben (“ik kan niet online bestellen want ik krijg een foutmelding van VISA”). Toch loont het, en is het een eenvoudige manier om op termijn klanten om te toveren in evangelisten die nieuwe klanten overtuigen.

Hoe bent u zelf als u – tegen alle verwachtingen – snel, professioneel en met een glimlach geholpen wordt door een helpdesk of een support team. Hoe zou u reageren moest u een mailtje sturen naar info@blablabla.com, en binnen het half uur een to the point antwoord krijgen?

Laat ons even uitgaan van een business proces dat we willen automatiseren. We willen hiervoor een online software laten ontwikkelen. We werven een legertje Deloitte/Accenture/… consultants aan die de processen komen beschrijven in flow charts. Na een paar weken of maanden hebben we een bundeltje Powerpoints. Vervolgens betalen we Softwarehouse XYZ om de processen in functionele designs te gieten. 3 maanden na de kick off van het project hebben we een FD (=Functionele Design, of beschrijving van de software die we willen laten ontwikkelen), een Word document van zo’n 250 pagina’s, waarin elk mogelijk scenario en scherm is beschreven. We gaan naar Web Dev Agency ABC, overhandigen de FD, en laten de webapplicatie ontwikkelen. 4 maanden en enkele tienduizenden euro’s later staat onze software online. Hoera!

En wat blijkt nu?

• Je bedrijf is sterk aangegroeid op die 7 maanden. De business is veranderd. Je processen eigenlijk ook.
• Functionaliteit ABC die op papier super nuttig en sexy leek, is eigenlijk toch niet zo interessant als eerst gedacht.
• De mensen “op de vloer”, oftewel de dagdagelijkse eindgebruikers, vragen zich af waarom feature XYZ ontbreekt…in hun ogen cruciaal, maar blijkbaar compleet vergeten door Deloitte/Accenture/het management.
• …

In het algemeen geldt dat software over de tijd heen devalueert. De wereld verandert, de business verandert, processen veranderen, concurrenten veranderen, leveranciers haken af, klanten krijgen andere eisen . Alleen groeit software niet altijd mee. Agile development is een methode van software ontwikkeling, die deze problemen wil aanpakken. De belangrijkste filosofie erachter is de volgende:

Focus op 1 core probleem

Tracht dat ene, aller belangrijkste basisprobleem duidelijk te omschrijven en op te lossen. Laat eindgebruikers het probleem omschrijven. Externe (dure) consultants mag, maar eindgebruikers werken dagdagelijks met de software en bedrijfsprocessen. Zij weten waar de nood het hoogst is! Los dit ene core probleem op met het minimum aantal features die nodig zijn. Less is more. Wie houdt er niet van een eenvoudige, simpele software, die exact doet wat ie moet doen en niet meer? Het bekendste voorbeeld is het volgende scherm. Je vergissen in wat deze online soft doet is onmogelijk.

Laat je business meteen genieten van de software

Laat je software en gebruikersinterface zo snel mogelijk los op eindgebruikers. Zet meteen online wat je online kan zetten, zelfs al ben je beschaamd over hoe weinig je software kan en hoe lelijk de interface is. Eindgebruikers zullen je dankbaar zijn, want vanaf de eerste release hebben ze (1) een basis oplossing voor hun core probleem, en (2) je geeft hen een manier om concrete feedback te geven. Feedback die gebaseerd is op gebruik van de software en niet op een 250 pagina’s dik document dat men “Functionele Design” noemt. Beter een software die na 1 week al online staat en (een deel van) het basis probleem oplost, dan een software die 7 maanden op zich laat wachten om te verschijnen op het moment dat uw processen en de wereld al deels veranderd zijn!

Korte release cycles op basis van feedback van je gebruikers

Na de eerste prille versie krijg je ongetwijfeld feedback. Positieve en negatieve. En aan de hand van die feedback kan je je gebruikers omtoveren van onverschillige gebruikers tot echte fans. Zorg ervoor dat je een eenvoudige release cycle hebt, waardoor je wekelijks kleine verbeteringen en nieuwe fine tunes online kan brengen zonder al te veel moeite. Gebruikers die vandaag klagen over een button op een ongelukkige plaats, zullen veranderen in enthousiaste fans indien die knop de week erna al op de juiste plaats staat! Gebruikers zijn je veel meer dankbaar indien je erin slaagt om een probleem meteen op te lossen of binnen de week hun feedback in nieuwe functionaliteit om te zetten, dan indien je hen belooft dat er ooit, one day, in de toekomst, een enorm fantastische soft aankomt die elk aspect van hun werk ondersteunt.

Wat is jullie ervaring met software ontwikkeling? Waar loopt het vaak fout, en hoe kunnen we dit verbeteren? Comments welkom!

Basis economie:

Een bedrijf creëert waarde door iets te kopen, en het te verkopen voor meer geld. Wat je koopt zijn je kosten, wat je verkoopt zijn je opbrengsten. Opbrengsten – Kosten = Winst. Zie figuur hieronder. Een bedrijf wil zijn winst maximaliseren. Dit gezegd zijnde kan elk kind van het eerste leerjaar me allicht 2 manieren vertellen hoe je je winst groter maakt. Juist! De opbrengsten naar boven, of de kosten naar beneden!

Het uiteindelijke doel van webapplicaties en (online) software is steeds ofwel het drukken van de kosten, ofwel het opkrikken van de opbrengsten. Dit is zo voor de hand liggend, maar toch wordt dit veel te vaak vergeten. Dit geldt zowel voor webapplicaties die je voor jezelf als voor een klant ontwikkelt. Hou 1 van deze 2 doelen steeds in het achterhoofd bij het ontwikkelen van een webapplicatie (of het laten ontwikkelen van een webapplicatie).

Webapplicaties om de kosten te drukken

Bedrijfskosten of operationele kosten groeien door inefficiënties. Te veel dubbele communicatie, te veel processen, te veel menselijke fouten bij het ingeven en verwerken van data, te veel informatie, te weinig relevante informatie, overbodige meetings, verschillende documenten op verschillende servers, te veel email-verkeer, onduidelijke processen, overbodige processen. Denk even na over de werking binnen uw bedrijf. Indien je in een bedrijf werkt met meer dan 20 personen, dan weet je exact wat ik bedoel.

Nu zijn er wel standaard pakketten en software die dit deels trachten op te lossen. Maar (1) die zijn vaak ontwikkeld in een pre-internet tijdperk en (2) die zijn nooit helemaal afgestemd op de processen en manier van werken binnen uw bedrijf. Hiermee wil ik niet zeggen dat die standaard software pakketten niet nuttig zijn. Wat ik wil zeggen is dat je door middel van een juiste webapplicatie op maat bovenop je pre-internet ERP pakket je operationele kosten enorm kan laten dalen. De rode lijn zakt, je winst wordt groter. Het internet en mobile applicaties worden volgens mij nog niet voldoende aangewend om deze inefficiënties te drukken.

Webapplicaties om de opbrengsten te verhogen

Andere webapplicaties hebben voornamelijk als doel de opbrengsten te verhogen. Daarbij is het vaak een bestaand business model dat wordt aangezwengeld door gebruik van het web. E-commerce websites zijn een goed voorbeeld. Steeds meer en meer klassieke shops worden aangevuld met een online variant. Of bestaande bedrijven gebruiken e-mail marketing om hun omzet te verhogen.

Voorbeelden zijn zoals reeds gezegd: e-commerce websites, e-mail marketing, Twitter dat wordt gebruikt als marketing tool. Telkens opnieuw is het de bedoeling een business aan te zwengelen, en de omzet te verhogen.

Extra: Webapplicaties die innoveren

Een minder voor de hand liggende maar des te interessantere context waarvoor webapplicaties worden aangewend is innovatie. 10 jaar geleden bestond het internet niet zoals het vandaag bestond. En dat gegeven heeft gezorgd voor een golf van nieuwe innovaties die laatste 10 jaar voor webapplicaties. Een nieuwe technologie opent nieuwe markten. Nieuwe opportuniteiten. De nieuwe parameter “internet” heeft ervoor gezorgd dat business modellen overhoop worden gegooid. Denk aan de muziekindustrie die overhoop ligt. De regels van het spel zijn veranderd. Hier is het niet zozeer het bestaande business model dat wordt aangezwengeld door gebruik van het web. Noch worden de kosten gedrukt.  Er ontstaan gewoon nieuwe business modellen. En die golf van innovatie is nog steeds aan de gang.

Voorbeelden zijn eBay (veilingen her-uitgevonden), PayPal (geld transacties her-uitgevonden), Google. Business modellen zoals SaaS en SOA. Freemium, waarbij software online gratis wordt aangeboden (en de opbrengsten via een ander kanaal worden binnengehaald).

Tot in 2011!