Ward van der Put

Er zijn verschillende tools die patronen kunnen vinden in (big) data. Bijvoorbeeld de Prediction API van het Google Cloud Platform kun je onder andere voor purchase prediction inzetten. Overkill in dit geval, maar nuttig om te weten dat het kan. Je hebt de basis gelegd van een eenvoudig model: je hebt twee variabelen met een lineair verband (het percentage). In werkelijkheid zijn er meer variabelen of drivers die inkoop en verkoop sturen. En de causale verbanden volgen meestal geen rechte lijn, maar kromme lijnen, zoals een afvlakkende curve of een normale verdeling. Zo te zien heb je hiermee een mooie casus en voldoende data voor een afstudeerproject van een student economie, econometrie of statistiek. Ik zou eens bij een universiteit polsen of je daar een opdracht kunt uitzetten: wat zijn die drivers, wat zijn de verbanden ertussen en hoe kan ik die in een praktisch spreadsheetmodel gebruiken, zodat ik de inkoop op scherp kan zetten?

Winst uit onderneming is hier geen zuivere nettowinst, maar loon naar werken. Als je een reële arbeidsvergoeding voor de twee vennoten verdisconteert, houd je mogelijk nul winst of een verlies over. En daarmee kun je evengoed beargumenteren dat de onderneming niets waard is of hooguit het totaal van bij liquidatie verhandelbare activa.

Er is geen keuze. Einde samenwerking ≡ einde VoF. Wel zit er kennelijk nog iets in het samenwerkingsverband dat je graag voor jezelf wilt hebben? Een handelsnaam, een merknaam, een klantenbestand*, een pc of twee, kan van alles zijn. Daarover moet je onderling wat afspreken bij het afrekenen. * Heeft je gebruikersnaam Kingdom MLM toevallig iets te maken met multi-level marketing? Correct. Jullie maken de balans op en sluiten de boeken voor de VoF, letterlijk en figuurlijk. Daarna begin je opnieuw voor jezelf.

Ja, dan is de PSP een debiteur. Bij elke iDEAL-betaling neemt je vordering op die debiteur toe, totdat je van de PSP een creditfactuur ontvangt en de PSP het saldo uitkeert. Die creditfactuur is tevens een kostenfactuur voor de iDEAL-transactiekosten plus de terug te vragen btw daarover. @Highio Ik interpreteerde de vraag wat ruimer vanwege het hypothetisch tegen veel werk opkijken: "Het is nogal wat werk om (stel) 100 orders per maand [...]". Dan kun je dus naar andere oplossingen gaan kijken.

Hangt er wel een beetje van af hoe je iDEAL-betalingen ontvangt: is dat via een PSP (payment service provider) die één keer per week uitkeert, dan heb je immers wel een debiteur. ;) Als iets (te) veel werk wordt, is automatiseren een voor de hand liggende oplossing. Veel webwinkelsoftware laat zich wel op een of andere manier koppelen aan boekhoudsoftware. Als je webwinkelsoftware al veel vastlegt (debiteuren/crediteuren, verkopen, facturen, btw-bedragen en betalingen), is er verder veel voor te zeggen om die verkoopadministratie te gebruiken als subadministratie; daaruit neem je dan met een rapport bijvoorbeeld één keer per dag de totalen over in je hoofdadministratie. Zo heb je overzicht en zijn toch alle details vastgelegd.

Misschien zie je wat alternatieve financieringsmogelijkheden over het hoofd? Een bestelbus kun je ook zakelijk leasen bijvoorbeeld, zodat effectief niet je privéwoning maar de bedrijfswagen het onderpand is. Lijkt mij een veiligere keuze. Werkkapitaal zoals voorraden kun je financieren met leverancierskrediet en een voorraadfinanciering.

Als je niet vraagt om een advies maar om een beslissing of een standpunt, krijg je daarop in de regel wel een goed onderbouwd antwoord ... ... soms zelfs inclusief een kopie van een pagina uit Elsevier Belastingalmanak met in geel gearceerd de relevante passages.

Misschien maar eens bij de bron beginnen: mijnwebwinkel zelf heeft een prima blog voor support, dat onder andere ingaat op de basisbeginselen van SEO en aanverwante onderwerpen zoals het gebruik van Google Search Console voor je webshop. Lees daarnaast zeker eens de Beginnershandleiding voor zoekmachineoptimalisatie (PDF) en de kwaliteitsrichtlijnen van Google zelf. Voor liefhebbers van checklists is deze infographic (JPEG) met de mythologische 200 ranking factors van Google een fijn hebbeding.

Het ding had nooit de "cookiewet" mogen worden genoemd, want hoofdstuk 11 van de Telecommunicatiewet geldt niet slechts voor cookies. Maar, inderdaad, bijvoorbeeld ook voor trackingpixels in e-mail.

Een waarderingsgrondslag overeenkomen is inderdaad belangrijker dan een concrete waarde vooraf vastleggen. Er wordt bovendien nog ingekocht:

Dan gebruik je Mendix kennelijk vooral voor rapid prototyping, maar daarvoor bestaan veel alternatieven, van paper prototyping (met UX Flowchart Cards bijvoorbeeld) tot en met Photoshop. Een frontend developer zal het niet snel doen, maar ik heb managers ook wel eens goede concepten voor applicaties zien uitwerken in (eek) PowerPoint. Net zoals je NoSQL niet moet gebruiken omdat je geen SQL beheerst, moet je low-code ook niet gebruiken omdat je (te) weinig van code weet. Het is anders een non-keuze: je moet een tool niet kiezen omdat andere tools te veel nadelen hebben, maar omdat de voordelen substantieel bijdragen aan je doel. Om daarmee je laatste vraag te beantwoorden: ja, ik denk dat een goede programmeur — en vooral iemand die een bepaald framework beheerst — in code ongeveer even snel iets werkbaars kan neerzetten. Voor een CRM zeker, want dat bestaat voor minstens 80 procent uit bewezen concepten waarvoor je zelf geen compleet nieuwe proof of concept hoeft te bedenken. Niet het wiel opnieuw uitvinden... Als je zelf vooral een goed frontend developer bent, waarom zou je dan niet samenwerken met een sterke backend developer?

Het is waarschijnlijk op forumniveau nu eenmaal ook off topic: een developer die naar de beste developer tools vraagt, is als een tandarts of bouwvakker die naar de beste boormachine vraagt. Als ik zou uitleggen hoe wij git in onze deployment cycle gebruiken, zijn er vermoedelijk 2 Higherlevel-leden die instemmend ja-knikken tegenover 98 Higherlevel-leden die denken dat ik gek geworden ben. Dat moeten we dan misschien maar niet doen.

En iedereen wordt softwareontwikkelaar? Van visual application development kennen we een oudere vormvariant: visual webdesign met Dreamweaver of FrontPage. Die maakten ook van iedereen een webdesigner. :P

Rijden zonder rijbewijs is een misdrijf. Gelijk in gesprek met de werknemer gaan — vanavond nog bellen (en niet slap mailen en niet laf appen) — en deze zonder duidelijk uitsluitsel op non-actief zetten. Aansprakelijkheid voor gepleegde misdrijven uitsluiten is onmogelijk. Norbert kan dat vast beter uitleggen, maar zijn antwoord lijkt me helder: ontslag op staande voet als het waar is.

Gisteren sprak ik een ondernemer die zich keurig aan de meldplicht houdt. Hij had zojuist zijn derde datalek van het jaar gemeld. Hij is echter de enige in zijn branche, hoewel hij zeker weet dat zijn concurrenten precies dezelfde soorten datalekken hebben. Klanten, diensten, processen, hardware en software zijn grotendeels identiek. Hij vraagt zich daarom nu af of hij wel het braafste jongetje van de klas moet blijven. Hij overweegt of de reputatieschade van te boek staan als enige die data lekt wel opweegt tegen het risico op een eventuele boete vanwege niet meer melden. Leek me verontrustend genoeg om hier even als bijwerking te delen.

Zo ken ik inderdaad een ondernemer die vaag dacht dat gemiddeld één keer per week "zakelijk" uit eten gaan wel door de beugel kon. De inspecteur dacht daar later toch anders over: er stonden te vaak kindermenu's op de rekening. Kantines met Michelinsterren. ;D Maar je maakt inderdaad soms rare dingen mee, zoals een 5-koppig adviesbureau met 4 consultants plus 1 chef-kok. Twijfelachtig.

Nuttige column, compliment!

Even een directe link erbij: https://www.higherlevel.nl/extra/columns/view/623 Hmm, dat is wel een puntje voor een feature request. Op mobiel is er geen rechtsboven. Helemaal geen columns te bespeuren zelfs, ook niet als linkje: https://m.hl.nl/ Tenzij je de URL's combineert: https://m.hl.nl/extra/columns/view/623 Nuttige column overigens, compliment!

Overal waar ondernemers, directeuren en managers bij elkaar komen, wordt niet alleen over voetballen gesproken. Dat noemen we netwerken. Maar het zou niet mogen uitmaken. Een goed ondernemingsplan staat of valt nooit met het bewaren van een bedrijfsgeheim. Daarnaast kun je sommige bedrijfsgeheimen prima buiten het plan houden. Je kunt goed beschrijven wat je gaat doen, waarom je dat doet en wat je daarvan verwacht zonder tot in elk technisch of commercieel detail toe te lichten hóé je dat precies doet. Een ondernemingsplan is geen technische specificatie en in een strategisch plan horen geen operationele onderwerpen.

Als je zo naïef optimistisch in het leven staat, ben je vroeg of laat een illusie armer. Of je bent nog nooit op een borrel met bankiers geweest, dat kan natuurlijk ook. Two can keep a secret if one of them is dead.

Zonder er een accounting vs bookkeeping-discussie van te willen maken denk ik, als bedrijfskundige, dat je die twee wel enigszins uit elkaar moet trekken. Voor een ondernemer zijn verschillende vormen van accountability belangrijk. Te beginnen met zelfkennis en verantwoording afleggen aan team en thuisfront: hoe staan we ervoor? Daarvoor moet je jaarstukken kunnen lezen. Maar ook: waar willen we heen? En dan komen de investeringsbegrotingen, kostprijsberekeningen en cashflowanalyses om de hoek kijken. Tot slot uiteraard de verantwoording aan aandeelhouders, investeerders en de fiscus: alstublieft, dit hebben we afgelopen jaar gedaan. Een investeringsbegroting opstellen of een integrale kostprijs berekenen zijn typisch meer ondernemersvaardigheden en atypisch minder boekhoudvaardigheden. Misschien moeten we "boekhouden" daarom vervangen door bedrijfseconomie. Of, altijd beter: bedrijfskunde.

Het werkwoord boekhouden is duidelijk voor meerdere interpretaties vatbaar. Net zoals huishouden...

Als ik Afschrijven voor Dummies erop nasla, mag je niet meer dan 20% per jaar afschrijven. Je hebt echter een gebruikte pc ingebracht, dus daarop is al afgeschreven. Volgens mij kun je dan verdedigen dat je jaarlijks 20% afschrijft van de oorspronkelijke aanschafprijs, niet van de dagwaarde op het moment van inbreng. Op een 5 jaar oude privé-pc nog eens 5 jaar zakelijk moeten afschrijven, lijkt mij geen goed koopmansgebruik. Maar ik denk dat ik het anders zou doen, zoals Ron eerder aanstipte. Met een zakelijke aanschafwaarde van € 406 zit je onder het drempelbedrag van € 450 voor kosten van zaken met een geringe waarde die je direct in één keer mag boeken. En dan is de correctie ook makkelijk: de totale kosten zijn € 406 waarvan € 162,40 (40%) voor privégebruik en € 243,60 (60%) zakelijk.

Ik heb gewerkt met (en vroeger trainingen gegeven in) Microsoft Project. MS Project is ideaal voor grootschalige projecten met een groot aantal resources (mensen, middelen, budgetten) en complexe relaties (afhankelijkheden in tijd bijvoorbeeld). De prijs is er wel naar: ongeveer een euro per gebruiker per dag — en zo'n training per gebruiker is ook geen overbodige luxe. Voor een web-based SaaS-oplossing zou ik inderdaad naar Basecamp kijken. Basecamp is een meer open omgeving, wat zowel een voordeel als een nadeel kan zijn: vrijheid voor de projectdeelnemers versus controle en beheersbaarheid voor projectleiders. Zoals bij forums ontspoort het berichtenverkeer in campfires en op de message boards bijvoorbeeld wel eens, wat misschien niet handig is als klanten daar ook toegang tot hebben. Voor eenvoudiger projectmanagement is Smartsheet wel aardig, vooral als je nu al spreadsheets gebruikt. Dit is een app voor Google Drive die Google Spreadsheets omtovert voor projectmanagement.

Eerder al aangestipt, maar wat is dan toch die "inbreng" van de investeerder(s) dat je zelf je kantoor daarvoor moet verplaatsen naar een locatie die de twee ondernemers slecht uitkomt? Je moet zitten waar je handel en business zit, niet waar je investeerder zit. Een investeerder die dat niet inziet, is bedrijfje aan het spelen. Dat is inderdaad een breekpunt, maar dan anders.