Wat gebeurt er met uw bedrijf als internet wegvalt, een clouddienst niet bereikbaar is of u van softwareleverancier wilt veranderen?
Local-first begint bij die vragen. Het is een manier om uw IT zo in te richten dat u grip houdt op de processen en gegevens waarvan uw bedrijf afhankelijk is. Lokaal werken vormt de basis; online diensten voegen mogelijkheden toe.
Het principe: de cloud ondersteunt uw bedrijf
Bij volledig cloudafhankelijke software verlopen belangrijke handelingen via de systemen van een leverancier. Dat kan praktisch zijn, maar maakt de beschikbaarheid van die dienst onderdeel van uw dagelijkse bedrijfsvoering.
Een local-first strategie onderzoekt welke werkzaamheden zelfstandig binnen uw bedrijf moeten kunnen doorgaan. De gegevens en functies die daarvoor nodig zijn, blijven lokaal beschikbaar. Voor samenwerken op afstand worden gerichte gegevens uitgewisseld.
Dit gaat verder dan een lokale kopie van uw gegevens. U moet er ook daadwerkelijk mee kunnen werken: gegevens invoeren, een planning raadplegen of een factuur voorbereiden. Daarvoor moeten ook de applicatie en noodzakelijke afhankelijkheden beschikbaar blijven.
In mijn aanpak voor bestaande bedrijfssoftware kan uw huidige applicatie in Access die lokale basis vormen. Dat betekent niet dat iedere aangesloten Web App ook offline werkt. We maken per onderdeel expliciete keuzes.
Drie praktijkvoorbeelden: dezelfde vraag, verschillende oplossingen
Deze geanonimiseerde voorbeelden laten zien hoe bestaande bedrijfssoftware kan samenwerken met toepassingen voor medewerkers buiten kantoor. De inrichting verschilt per bedrijf: soms blijft Access de administratieve basis, soms werkt iedere medewerker met een eigen lokale database en soms staat de centrale database in de cloud.
Case 1: Keuringen uitvoeren met een app, de administratie in Access
De bedrijfsvraag. Een keuringsbedrijf wil medewerkers in dienst nemen of mensen inhuren die keuringen kunnen uitvoeren met een app. De bestaande applicatie in Access verzorgt de planning, orders en facturatie.
De gekozen opzet. Ik heb met hulp van AI een gekoppelde Web App ontwikkeld. Access blijft de administratieve basis. Alleen de gegevens die nodig zijn om de keuringen uit te voeren, komen beschikbaar in de app.
- Plannen en organiseren op kantoor. De planning en orders worden in Access beheerd.
- Gericht gegevens uitwisselen. De koppeling brengt de voor de app benodigde gegevens naar de cloudomgeving.
- Keuringen uitvoeren. Medewerkers of ingehuurde keurders gebruiken de app bij het uitvoeren en vastleggen van hun keuringen.
- Administratief verwerken. De keuringsgegevens worden gekoppeld aan de bestaande administratie. De facturatie blijft via Access verlopen.
Hoe dit is ontwikkeld. De bestaande applicatie en bedrijfsprocessen vormden het vertrekpunt. De nieuwe app is lokaal met hulp van AI ontwikkeld en via een testomgeving voorbereid op gebruik. De koppeling tussen app en administratie kreeg daarbij afzonderlijke aandacht.
Wat dit mogelijk maakt. De ondernemer kan anderen keuringen laten uitvoeren met een gerichte app, terwijl planning, orders en facturatie in de bestaande applicatie blijven. Voor dit voorbeeld wordt geen offline werking van de Web App verondersteld.
Case 2: Boominspecties: buiten invoeren zonder internet
De bedrijfsvraag. Medewerkers van een bedrijf voor boominspecties, onderhoud en advies moeten hun gegevens buiten kunnen invoeren zonder afhankelijk te zijn van een internetverbinding.
De gekozen opzet. Iedere medewerker heeft een eigen lokale applicatie met een lokale Access-database. Na thuiskomst worden de gegevens gesynchroniseerd met een centrale database in Azure SQL.
- De lokale gegevens meenemen. De medewerker werkt met de gegevens die na de vorige synchronisatie lokaal beschikbaar zijn.
- Inspecteren op locatie. Tijdens de inspectie worden gegevens in de lokale applicatie ingevoerd. Daarvoor is geen internetverbinding nodig.
- Na thuiskomst synchroniseren. De ingevoerde gegevens worden uitgewisseld met de centrale database in Azure.
- Nieuwste gegevens ontvangen. Bij de synchronisatie ontvangt iedere medewerker ook de nieuwste gegevens in zijn eigen lokale database.
Wat dit mogelijk maakt. Het veldwerk kan doorgaan op locaties zonder bereik. Tussen synchronisatiemomenten kunnen lokale gegevens achterlopen op de centrale database; hoe actueel informatie moet zijn, blijft daarom een belangrijk onderdeel van de werkafspraken.
Case 3: Alternatieve koppeling — hybride werken met Azure SQL en Access
Een alternatief naast local-first. Deze case laat de voordelen zien van een mobiele app en een bestaande Access-applicatie die dezelfde centrale clouddatabase gebruiken. Dit is een hybride koppeling, geen local-first oplossing: zonder toegang tot Azure SQL kunnen de databaseafhankelijke functies niet op de gebruikelijke manier verder.
De bedrijfsvraag. Vertegenwoordigers van merken bij een modebedrijf bezoeken klanten en willen onderweg hun klantgegevens en weekplanning bij de hand hebben. Tijdens het bezoek voeren zij gegevens en targets direct in.
De gekozen opzet. De mobiele app is in dit project gebouwd met Power Apps en gebruikt rechtstreeks een centrale Azure SQL-database. De bestaande applicatie in Access is met diezelfde database verbonden en blijft de rapportages en administratieve processen verzorgen.
- Het bezoek voorbereiden. De vertegenwoordiger raadpleegt de benodigde klantgegevens en agenda met weekplanning in de app.
- Bij de klant invoeren. Tijdens het bezoek worden gegevens en targets in de mobiele app vastgelegd.
- Centraal beschikbaar maken. De app werkt met de centrale Azure SQL-database.
- Rapporteren en administreren. De bestaande applicatie in Access gebruikt de gekoppelde gegevens voor rapportages en administratieve verwerking.
Dagelijks een lokale gegevenskopie. De gegevens uit de clouddatabase worden dagelijks naar lokale Access-tabellen gekopieerd. Zo is een lokale kopie beschikbaar van de gegevens op het laatste kopieermoment. Bij dagelijks succesvol kopiëren kunnen daarin tot ongeveer één dag aan recente wijzigingen ontbreken; bij een mislukte kopie kan deze periode langer zijn.
Lokale reserve als onderdeel van de continuïteitsstrategie. Naast de dagelijkse lokale gegevenskopie voorziet de continuïteitsstrategie in overschakelen naar een Access-reservedatabase wanneer internet of Azure niet bereikbaar is. Het noodscenario gaat uit van de gegevens op het laatste kopieermoment. Welke functies lokaal doorgaan en hoe eventuele wijzigingen na herstel worden verwerkt, horen bij de inrichting en beproeving van deze terugvalmogelijkheid. De mobiele app blijft bij deze opzet afhankelijk van de cloud.
Na herstel weer aansluiten. Ontbrekende gegevens in de lokale reserve betekenen niet automatisch definitief dataverlies: de nieuwere gegevens kunnen nog in Azure aanwezig zijn. Als tijdens de noodperiode lokaal gegevens worden ingevoerd, moeten die na herstel gecontroleerd met de centrale gegevens worden samengevoegd. Ongecontroleerd terugzetten kan juist nieuwe wijzigingen overschrijven.
Wat dit laat zien. Ook met een centrale clouddatabase kan Access een waardevolle rol behouden. De lokale reserve biedt een basis voor een noodscenario, terwijl de dagelijkse werking cloudafhankelijk blijft. Bij de boominspecties in case 2 is offline invoeren juist onderdeel van het normale werkproces. Dit verschil bepaalt hoe u met uitval en actualiteit van gegevens omgaat.
De strategie volgt het bedrijfsproces
De drie voorbeelden hebben een gemeenschappelijk uitgangspunt: behouden wat waarde heeft en nieuwe functies gericht toevoegen. Het verschil zit in de plaats waar gegevens worden beheerd en in de afhankelijkheid van verbindingen. Daarom bepalen we eerst waar mensen werken, welke informatie zij nodig hebben en wat er bij uitval moet kunnen doorgaan.
Wat gebeurt er bij een storing?
| Situatie | Vooraf ontworpen gedrag |
|---|---|
| Internet op kantoor valt uit | De afgesproken lokale functies blijven werken als de lokale omgeving beschikbaar is. De uitwisseling met de cloud wacht. Online e-mail of externe controles kunnen tijdelijk ontbreken. |
| De clouddienst is niet bereikbaar | Op kantoor kan lokaal worden doorgewerkt. Het klantportaal en andere cloudfuncties kunnen tijdelijk niet beschikbaar zijn. |
| De monteur heeft geen bereik | Alleen als offline werken is ingebouwd, kan hij eerder beschikbare opdrachten raadplegen en invoer lokaal bewaren. Zonder die voorziening heeft de app verbinding nodig. |
| De lokale server of werkplek valt uit | Local-first lost dit niet vanzelf op. Herstel van apparatuur, een vervangende werkplek en geteste back-ups zijn nodig. |
Een belangrijk aandachtspunt is actualiteit. Als de planner een afspraak wijzigt terwijl de monteur offline is, kan de monteur nog de oude planning zien. De app moet daarom duidelijk tonen wanneer gegevens voor het laatst zijn bijgewerkt. Voor urgente wijzigingen spreken we ook een praktische werkwijze af, bijvoorbeeld telefonisch contact.
Na herstel: niet alles opnieuw versturen
Wanneer de verbinding terugkomt, moet duidelijk zijn wat al is verwerkt en wat nog wacht. Anders kan een werkbon dubbel binnenkomen of een nieuwere wijziging worden overschreven.
- Wachtende wijzigingen herkennen. Iedere wijziging krijgt een herkenbare identiteit en een verwerkingsstatus.
- Gecontroleerd aanbieden. De koppeling verstuurt de nog openstaande wijzigingen. Opnieuw aanbieden van dezelfde wijziging mag geen tweede boeking opleveren.
- De verwerking bevestigen. Pas na bevestiging staat een wijziging als verwerkt geregistreerd. Een onderbroken verzending kan dan opnieuw worden geprobeerd.
- Uitzonderingen zichtbaar maken. Afwijkingen komen in een overzicht voor beoordeling. Een medewerker kan zien welke gegevens aandacht nodig hebben.
Zo wordt synchronisatie een controleerbaar bedrijfsproces. De precieze verwerking en verantwoordelijkheden leggen we vast per toepassing.
Hetzelfde nummer betekent niet hetzelfde record
Op kantoor kan opdracht 125 bestaan, terwijl de clouddatabase nummer 125 al voor iets anders gebruikt. Daarom mag de koppeling niet aannemen dat lokale en online nummers altijd overeenkomen.
Een oplossing kan werken met een vaste, unieke uitwisselidentiteit of een koppeltabel die beide nummers bij elkaar houdt. Ook wordt vastgelegd welk systeem de bron is voor een gegeven. De planner beheert bijvoorbeeld de afspraak; de monteur meldt de uitgevoerde werkzaamheden terug.
Als twee mensen hetzelfde gegeven wijzigen, is alleen de laatste wijziging bewaren niet altijd verantwoord. Een gewijzigd factuurbedrag of een geannuleerde opdracht vraagt om duidelijke regels en soms menselijke beoordeling.
Een klantportaal is een venster op een selectie
Een klant wil zijn facturen downloaden of productgegevens bekijken. Daarvoor hoeft uw administratie niet rechtstreeks toegankelijk te worden vanaf internet. Het portaal kan werken met een gecontroleerde selectie van definitieve documenten en toegestane gegevens.
Een aanvraag vanuit het portaal kan eerst als nieuwe aanvraag binnenkomen op kantoor. Een medewerker beoordeelt deze voordat er een order ontstaat. Zo bepaalt uw bedrijfsproces wat automatisch mag en waar een controle nodig blijft.
Zeggenschap: kunt u later een andere keuze maken?
Digitale soevereiniteit betekent hier praktisch dat u weet wie toegang heeft tot uw gegevens en welke mogelijkheden u heeft om zelfstandig verder te gaan. Dat vraagt om afspraken over:
- Gegevensexport: kunt u gegevens inclusief hun onderlinge verbanden meenemen en opnieuw gebruiken?
- Software en documentatie: zijn de benodigde broncode, installatie-instructies en beschrijvingen beschikbaar?
- Beheer en toegang: heeft uw bedrijf toegang tot de accounts, back-ups en hosting die nodig zijn?
- Overstappen: wat is nodig om een andere ontwikkelaar of hostingpartij in te schakelen?
Lokale software heeft ook afhankelijkheden, zoals apparatuur, licenties en onderhoud. Een toekomstgerichte strategie maakt die zichtbaar en houdt rekening met vervanging en overdracht.
Hoe verhoudt dit zich tot SaaS?
SaaS kan passend zijn voor algemene processen en voor bedrijven die beheer willen uitbesteden. Een eigen lokale toepassing met gekoppelde apps kan aantrekkelijk zijn wanneer uw huidige software goed aansluit op een specifieke werkwijze en continuïteit belangrijk is.
De 80/20-gedachte is een vuistregel: veel algemene wensen passen in standaardsoftware, terwijl de laatste bedrijfsspecifieke behoeften onevenredig veel aanpassingen kunnen vragen. De afweging gaat daarom over het hele plaatje: functionaliteit, abonnementen, ontwikkeling, beheer, koppelingen en toekomstige veranderingen.
Synchronisatie is geen back-up
Als een fout of verwijdering automatisch wordt uitgewisseld, kan die in beide omgevingen terechtkomen. Synchronisatie bewaart dus niet vanzelf een gezonde eerdere versie. Daarvoor zijn afzonderlijke back-ups en geteste herstelprocedures nodig.
Ook lokaal werken is geen garantie tegen ransomware of ongeoorloofde toegang. Updates, toegangsrechten, beveiligde verbindingen en bescherming van werkplekken en servers blijven onderdeel van de oplossing.
Zo wordt het een toetsbare IT-strategie
We beginnen met een overzicht van uw kritische bedrijfsprocessen. Per proces leggen we vast waar gegevens worden beheerd, wie wijzigingen mag doen en wat er bij uitval moet gebeuren.
- Welke werkzaamheden moeten zonder internet door kunnen gaan?
- Hoe lang mogen gegevens onderweg achterlopen?
- Welke gegevens heeft iedere app werkelijk nodig?
- Wie beoordeelt conflicten of afgekeurde wijzigingen?
- Hoe herstellen we na een storing of verkeerde invoer?
Daarna testen we de gemaakte afspraken: verbinding onderbreken, dezelfde wijziging opnieuw aanbieden, een conflict veroorzaken en een back-up terugzetten. Zo wordt zichtbaar of de oplossing zich gedraagt zoals uw bedrijf nodig heeft.
Bespreek welke processen in uw bedrijf zelfstandig moeten blijven werken →