Het formulier is succesvol verzonden.
Meer informatie vindt u in uw mailbox.
Inhuren
Over onsDienstenTechnologieënIndustrieënPortfolio
Volgens een enquête van Clutch, 86% werknemers mobiele apps gebruiken om hun werk te doen. 67% meldde een hogere efficiëntie. Wij zien de vraag. De behoefte aan een mobiele app betekent niet dat elke mobiele app volstaat. Uw medewerkers willen waarschijnlijk een app die aansluit bij alle bestaande systemen, functies en goedkeuringsprocessen. Om aan deze behoefte te voldoen, begint het met het in kaart brengen van de situatie, waarna het coderen volgt.
Een mobiele bedrijfsapp ondersteunt de bedrijfssystemen die al in gebruik zijn. De app kan gegevens lezen en schrijven via CRM of ERP-systemen, zich aan te melden via de bestaande identiteitsprovider van het bedrijf, de aan elke gebruiker toegewezen rollen en rechten te respecteren, en te functioneren binnen het beleid voor apparaatbeheer en de operationele omgeving waarin het wordt geïmplementeerd.
De ontwikkeling van mobiele bedrijfsapps bestaat uit een reeks beslissingen, en de volgorde daarvan is van belang. Ik zal je stap voor stap begeleiden bij het in kaart brengen van de behoefte, de keuze tussen zelf ontwikkelen of kopen, het ontwerpen van de architectuur en de integraties, het beveiligen van de app, de uitrol ervan en het beheer daarna.
Onderneming mobiele app ontwikkeling houdt zich bezig met het ontwerpen, ontwikkelen en onderhouden van mobiele applicaties die zijn geïntegreerd met de ERP-, CRM-, identiteits- en gegevensplatforms van het bedrijf. De apps vallen onder interne beveiligings- en nalevingsbeleidsregels.
Terwijl consumentenapps zijn bedoeld voor een zo breed mogelijk publiek, zijn bedrijfsapps bedoeld voor specifieke gebruikersgroepen met vastomlijnde rollen en beperkte toegang tot gegevens. Laten we eens nader bekijken hoe deze twee categorieën van elkaar verschillen:
| Factor | Onderneming | Consument |
| Primaire gebruikers | Medewerkers, partners of de eigen klanten van een bedrijf met vastgestelde rollen | Het grote publiek, zelf geregistreerd |
| Distributie | Particuliere app-winkels, MDM/EMM-pushberichten, interne catalogi | Openbare app-winkels, zoals de App Store en Google Play |
| Authenticatie | SSO, MFA en biometrische gegevens gekoppeld aan de bedrijfsidentiteit | Inloggen via e-mail of sociale media, optionele MFA |
| Gegevensbron | ERP, CRM, interne API’s, verouderde systemen | Algemene of app-specifieke backend |
| Beveiligingsrichtlijn | OWASP MASVS-maatregelen, MDM-beleid, auditlogging, AVG/HIPAA/PCI DSS voor zover van toepassing | Beoordeling van de App Store, een privacybeleid |
| Offline gedrag | Vaak vereist voor locaties in het veld, magazijnen en gebieden met een slechte netwerkverbinding | Optioneel |
| Uitrol van de update | Uitgesplitst naar apparaatgroep, regio of bedrijfsonderdeel | Snel, meestal automatisch |
| Succesindicator | Tijd die nodig is om een taak te voltooien, foutenpercentage, acceptatiegraad per functie | Downloads, DAU/MAU, sessieduur |
| Eigenaar | IT, de businessunit en de beveiligingsafdeling werken gezamenlijk samen | Product-/bedrijfteam |
Hebben de bedrijfsprocessen van uw onderneming een app nodig, of overweegt u er een aan te schaffen omdat een concurrent er een heeft? Voordat we frameworks of leveranciers gaan vergelijken, raad ik u aan eerst een vraag te beantwoorden: welke specifieke operationele leemte vult deze app op?
Laten we even een korte zelftest doen. Ik heb een checklist opgesteld. Als twee of meer van deze punten op jou van toepassing zijn, is het de moeite waard om de mogelijkheden van een mobiele bedrijfsapp te onderzoeken.
Onze volgende stap is om uw initiatief af te stemmen op de werkzaamheden die het moet ondersteunen. Op basis van de doelgroep worden bedrijfsapps onderverdeeld in apps voor medewerkers, klanten, partners en gedeelde apparaten. Op basis van functie vallen ze onder de zes onderstaande categorieën. Ik zal bepalen welke functies nodig zijn en waar u uw ontwikkelingsinspanningen op moet richten, zodat u de juiste oplossing voor uw situatie kunt vinden.
De mobiele architectuur van een onderneming omvat de volledige keten van systemen waarlangs de app gegevens veilig moet doorsturen. Een functionerende mobiele stack voor ondernemingen bestaat doorgaans uit tien onderdelen:
Het onderstaande diagram laat zien hoe gegevens door de architectuur stromen: van het apparaat, via de synchronisatie- en gateway-lagen, naar de systemen die eigenaar zijn van de gegevens, en weer terug in de vorm van monitoring- en gebruiksgegevens.
Laten we eens wat dieper ingaan op enkele nuances van mobiele bedrijfsapps die deze apps ingewikkelder maken.
De authenticatie voor bedrijfsapps moet plaatsvinden via de bestaande identiteitsprovider, zodat de rol en de rechten die aan de gebruiker op het mobiele apparaat zijn toegewezen, overeenkomen met de rechten in andere systemen. Als je een op zichzelf staand authenticatieproces met gebruikersnaam en wachtwoord opzet, creëer je een tweede identiteitssysteem dat moet worden bijgewerkt, gecontroleerd en uiteindelijk buiten gebruik gesteld. Ik raad aan om op API-niveau rolgebaseerde toegangscontrole (RBAC) te implementeren, zodat wijzigingen onmiddellijk van kracht worden. Bij gedeelde apparaten moet nog een extra beslissing worden genomen: op een tablet in het magazijn of een kiosk moet de sessie aan het einde van de dienst worden beëindigd, dus zorg voor snelle gebruikerswisseling en automatische uitlogging.
Wanneer een mobiele client rechtstreeks een verouderde ERP-API aanroept, moet de client-app bij elke wijziging in de backend opnieuw worden gebouwd. BFF’s of API-gateways fungeren als tussenpersoon tussen beide. Ze zetten backend-API’s om naar een formaat dat geschikt is voor mobiele schermen, voegen rate-limiting en caching toe en bieden mobiele ontwikkelaars een stabiele interface om mee te werken, ondanks alle schommelingen in de backend-systemen.
Als een app bedoeld is voor buitendienstmedewerkers, magazijnen of logistiek, moet deze offline kunnen werken. Dat betekent dat lokale schrijfbewerkingen in de wachtrij op het apparaat worden geplaatst en worden gesynchroniseerd zodra de verbinding weer tot stand is gebracht. Naast de wachtrij moet je op dat niveau nog deze vier beslissingen nemen.
Het monitoren van crashes en prestaties, zoals sessietraces, API-latentie en het percentage crashvrije sessies, moet in verband worden gebracht met het gedrag van de backend. Het doel is om binnen enkele minuten te kunnen vaststellen of een piek in mislukte aanmeldingen het gevolg is van een mobiele bug of een storing bij de identiteitsprovider. Gebruiksanalyses horen hierbij: het gebruik per rol en per apparaattype laat een team zien welke workflows een nieuwe sprint waard zijn en welke niet worden gebruikt.
Je hebt hierboven twee of meer vakjes aangevinkt, dus we kunnen er nu vanuit gaan dat je een app nodig hebt. Je kunt kiezen uit vier opties: een app op maat helemaal zelf bouwen, een kant-en-klare app kopen, een bestaand platform uitbreiden of een app op maat die je al hebt moderniseren. Laten we eens kijken welke optie het beste bij je past:
| Benadering | Het meest geschikt wanneer | Belangrijkste voordeel | Belangrijkste beperking |
| Een mobiele app op maat laten ontwikkelen | U hebt unieke workflows, integraties, gebruikerservaringen of offline behoeften | Volledige controle | Complexer en duurder, grotere verantwoordelijkheid voor levering en onderhoud |
| Een bestaande applicatie kopen | Uw processen zijn gestandaardiseerd | Snellere eerste acceptatie | Beperkte differentiatie en maatwerk |
| ERP-, CRM- of low-code-platform uitbreiden | De processen zijn al gecentraliseerd op één groot platform, en je moet ze mobiel maken | De gegevens en het beheer zijn al geregeld | Platformafhankelijkheid en licentiebeperkingen |
| Een bestaande app moderniseren | Je hebt een waardevol product met verouderde technologie | Behoudt de bedrijfslogica en de investering | Er kunnen nog oude afhankelijkheden overblijven |
De referentiestandaard is de Mobile Application Security Verification Standard (MASVS) van OWASP, momenteel in versie 2.1.0. Deze biedt een raamwerk voor acht verschillende gebieden, verdeeld over 24 verschillende controlemaatregelen op het gebied van opslag, cryptografie, authenticatie, netwerkcommunicatie, platforminteractie, codekwaliteit, veerkracht en privacy. Een penetratietest voor mobiele apps wordt doorgaans beoordeeld aan de hand van MASVS, dat fungeert als een gemeenschappelijke maatstaf voor uw beveiligingsteam, de leverancier van de mobiele app en zelfs eventuele auditors. In de offerteaanvraagfase kunt u gerust aan een leverancier vragen volgens welk testprofiel van de Mobile Application Security Testing Guide (MASTG) zij te werk gaan, en om de testresultaten in te zien. Terwijl MASVS definieert welke beveiligingsmaatregelen moeten worden geïmplementeerd, biedt MASTG de specifieke testprocedures en technische richtlijnen voor het verifiëren van die maatregelen.
Sommige organisaties gebruiken Zero Trust als leidraad bij het opstellen van hun beleid voor mobiel apparaatbeheer (MDM). Dit houdt in dat er controles op de status van apparaten worden uitgevoerd en dat er contextgebonden toegangsbeslissingen worden genomen. Dat is nu des te belangrijker omdat “Bring Your Own Device” (BYOD) de norm is geworden. Naar schatting is tweederde van de apparaten die toegang hebben tot bedrijfsgegevens in particulier bezit. Daarom verschilt het beheerpunt per apparaateigenaar. Bedrijfsapparaten worden beheerd via MDM. In dit geval heeft de afdeling IT de volledige controle over het apparaat. Privéapparaten worden beheerd via Mobile Application Management (MAM) en beveiligingsbeleid voor applicaties. Bedrijfsgegevens en -applicaties worden opgeslagen in een container die de IT-afdeling zelfstandig kan verwijderen, terwijl de rest van de telefoon buiten het bereik van het systeem blijft.
Bij het ontwikkelen van applicaties voor gereguleerde sectoren moet de beveiligingsarchitectuur voldoen aan de geldende wettelijke vereisten. Zo regelt de AVG de verwerking van persoonsgegevens van EU-inwoners; de HIPAA beschermt beschermde gezondheidsinformatie (PHI) die in het bezit is van organisaties die onder de wet vallen en hun zakenpartners in de Verenigde Staten; en de PCI DSS stelt controle-eisen vast voor organisaties die kaartgegevens verwerken. Daarnaast moeten organisaties mogelijk voldoen aan sectorstandaarden of regelgeving, zoals SOC 2-rapportage, FFIEC-richtlijnen of lokale bankvereisten, afhankelijk van hun specifieke operationele context en sector.
Governance wordt vaak pas als laatste aan de orde gesteld, maar is vanaf het allereerste begin van essentieel belang. Vóór de lancering moet u vaststellen wie na de release verantwoordelijk is voor de applicatie, wie de versie goedkeurt voor gebruik in een productieomgeving, wat de SLA-voorwaarden voor ondersteuning zijn en hoe de bedrijfsunit wijzigingen kan aanvragen. U moet twee operationele aspecten in één document behandelen: de rotatie van certificaten en sleutels, en wat er gebeurt met bedrijfsgegevens op een apparaat wanneer een medewerker het bedrijf verlaat.
Zodra alle benodigde beslissingen zijn genomen, kun je beginnen met het technische gedeelte van de ontwikkeling van mobiele bedrijfsapps. Ik zal het proces van Innowise met je doornemen, met korte beschrijvingen van de verschillende fasen:
Ik merkte wel dat ontwikkeling van mobiele bedrijfsapps kost doorgaans tussen $100.000 en $600.000+. Ik zou echter niet aanraden om op deze cijfers af te gaan zonder dat er eerst vereisten zijn vastgesteld en een behoefteanalyse is uitgevoerd. De kosten zijn afhankelijk van het aantal systeemintegraties, de reikwijdte van de compliance-eisen en de offline-vereisten. De kosten variëren sterk, omdat het budget wordt bepaald door de integratie met legacy-systemen, de reikwijdte van de compliance-eisen, de complexiteit van offline- en synchronisatieprocessen, de schaal en het beheer van apparaten, en de keuze van het platform.
Daarnaast is ook het doorlopende onderhoud inbegrepen. Doorlopend onderhoud kost doorgaans jaarlijks 10–20% van de oorspronkelijke aanlegkosten. Dit is een redelijk bedrag om mee te rekenen, zeker als je rekening houdt met het installeren van patches, updates van het besturingssysteem en aanpassingen aan de backend. Het eerste jaar vallen de kosten vaak hoger uit, omdat bij daadwerkelijk gebruik tekortkomingen aan het licht komen die bij de proefimplementatie over het hoofd waren gezien.
Eindelijk is de app in gebruik genomen. Vervolgens meten we het succes ervan op drie gebieden: gebruikersacceptatie, operationele prestaties en financieel rendement.
| Aandachtsgebied | Hoe te meten | Waarom het belangrijk is |
| Overname door gebruikers |
| Zorgt ervoor dat medewerkers en belanghebbenden de app actief gebruiken, waardoor verspilde ontwikkelingsinspanningen worden voorkomen en organisatorische verandering wordt gestimuleerd. |
| Operationele prestaties |
| Bevestigt dat de applicatie bedrijfsprocessen stroomlijnt, operationele wrijving vermindert en zorgt voor een betrouwbare dagelijkse uitvoering. |
| Financieel rendement |
| Toont het management de concrete financiële waarde en de kostenrechtvaardiging aan, waardoor de duurzaamheid van de investering op lange termijn wordt gewaarborgd. |
Apps die één duidelijk omschreven, veelvoorkomende taak vervangen – zoals een goedkeuring, een scan of het inchecken – leveren doorgaans snel rendement op. Apps die bovenop een meerjarige ERP-implementatie worden ingezet, hebben meer tijd nodig om zich terug te betalen, omdat het langzamere systeem eronder bepalend is voor de doorlooptijd.
Nu AI op grote schaal wordt geïntegreerd in bedrijfssystemen, kan ik het belang ervan voor mobiele bedrijfsapps niet negeren. De AI-mogelijkheden die beschikbaar zijn in mobiele bedrijfsapps zijn in de praktijk vrij beperkt en gekoppeld aan een specifieke taak. Voor elke taak gelden duidelijk omschreven succescriteria, zoals het extraheren van een bepaald veld, het detecteren van een bepaalde transactie, het voorspellen van een probleem of het verifiëren van een gebruiker.
Je kunt een op LLM gebaseerde chatfunctie rechtstreeks in de app integreren om vragen van klanten te beantwoorden, supporttickets te sorteren en gebruikers door een proces te leiden. Deze functie vormt een aanvulling op je bestaande supportinhoud en workflows.
Met behulp van computervisie, toegepast op de camera van de telefoon, worden gestructureerde gegevens geëxtraheerd. Uw medewerkers hoeven dan geen informatie meer handmatig in te voeren van een onkostennota, een ondertekend formulier of een verzendetiket. Meestal maken apps voor buitendienstmedewerkers en backoffice-medewerkers als eerste gebruik van deze functie, omdat hiermee een specifieke, repetitieve taak wordt weggenomen.
Gezichts- en vingerafdrukherkenning (Face ID, de biometrische API’s van Android) is ook voor bedrijfsapps de standaard geworden. Het verschil met consumentenapps is dat dit op het apparaat zelf plaatsvindt, in plaats van dat biometrische gegevens naar een server worden verzonden.
Mobiele bedrijfsapps integreren tegenwoordig ook spraakassistenten zoals Siri, Google Assistant en dergelijke. Vanuit ontwikkelingsperspectief is het niet nodig om helemaal vanaf nul een aparte spraaklaag te bouwen, omdat deze assistenten op besturingssysteemniveau werken. Deze functie is handig in situaties waarin je je handen vol hebt en typen niet praktisch is.
Veelvoorkomend in bank-, verzekerings- en betaalapps: modellen die in realtime transactiepatronen, apparaatsignalen en gedrag in de gaten houden en signalen afgeven wanneer iets buiten het normale bereik voor een bepaalde rekening valt. Het ontwerppatroon dat hier van belang is: het model geeft een signaal af; een mens of een vastgestelde workflow beslist. Ik raad volledig automatische blokkering zonder beoordelingsmogelijkheid af, omdat dit de meeste klachten van klanten oplevert.
Deze functie komt veel voor in apps voor productie en buitendienst: modellen die zijn getraind op basis van sensorgegevens en onderhoudsgeschiedenis geven aan welke apparatuur waarschijnlijk onderhoud nodig heeft voordat er een storing optreedt. Vervolgens wordt deze informatie in de app van een technicus weergegeven als een werkopdracht.
Objectdetectie en beeldclassificatie worden uitgevoerd via de camera van een telefoon of tablet voor veiligheidsinspecties, kwaliteitscontrole en conditiecontroles van bedrijfsmiddelen in de bouw, logistiek en productie. Een foto van een pallet, een bouwplaats of een stuk apparatuur wordt beoordeeld aan de hand van vastgestelde criteria.
Een agent voert zelfstandig een afgebakende taak uit. Hij kan een levering omleiden en een magazijn op de hoogte brengen van de vertraging, of gegevens uit een gescande bon overnemen in een onkostendeclaratie. De rode draad in de praktijkvoorbeelden is vrij beperkt: één vastomlijnde stap binnen een workflow waarover de app al beschikt, waarbij een mens alles wat belangrijke gevolgen heeft, moet bevestigen.
Innowise biedt ontwikkelingsdiensten voor mobiele bedrijfsapps over de volledige stack: native iOS en Android, cross-platform ontwikkeling, hybride apps en low-code-oplossingen op platforms zoals Mendix. Onze experts analyseren uw behoeften en adviseren u over de beste optie voor uw bedrijf.
Als erkende bedrijf dat mobiele apps voor bedrijven ontwikkelt, beschikken wij over ISO 9001-, 13485- en 27001/27017/27018-certificeringen en zijn wij partner van AWS, Microsoft, SAP, Databricks, Odoo, InterSystems en UiPath. Wat naleving betreft, voldoen wij aan SOC 2, HIPAA, PCI DSS en de AVG.
Als je op zoek bent naar mobiele app-ontwikkelaars voor bedrijven inhuren, We werken samen met bedrijven in diverse sectoren, waaronder fintech en het bankwezen, de gezondheidszorg en telegeneeskunde, verzekeringen, logistiek en bedrijfsvoering. Onze klanten prijzen ons vaak om de snelheid waarmee we lopende functieontwikkelingen opleveren, onze flexibiliteit bij wijzigingen in de projectomvang en de kwaliteit van onze communicatie tijdens projecten die meerdere weken in beslag nemen.
Tot slot wil ik benadrukken dat het succes van de ontwikkeling van mobiele bedrijfsapps afhangt van een volledige afstemming tussen de bedrijfsstrategie en de onderliggende infrastructuur. Dit betekent directe integratie met bestaande ERP-, CRM- en beveiligingssystemen. Sterk identiteitsbeheer, een schaalbare architectuur en strikte naleving van wettelijke vereisten vanaf het begin helpen u om kostbare herstelwerkzaamheden later te voorkomen. Wanneer een mobiele app wordt ontwikkeld om specifieke operationele tekortkomingen aan te pakken en voldoet aan strenge normen zoals OWASP MASVS, is deze meer dan alleen een operationeel hulpmiddel: het wordt een strategisch belangrijk bedrijfsmiddel dat op de lange termijn efficiëntie en bedrijfswaarde oplevert.
De ontwikkeling van mobiele bedrijfsapps is het proces waarbij mobiele applicaties worden ontworpen, gebouwd en onderhouden die aansluiten op de bestaande systemen van een bedrijf, zoals ERP-, CRM-, identiteits- en dataplatforms. Deze applicaties worden ontwikkeld in overeenstemming met het beveiligings- en nalevingsbeleid van het bedrijf.
Bedrijfsapps maken gebruik van bedrijfsidentiteitssystemen voor authenticatie, maken verbinding met interne gegevensbronnen en voldoen aan het interne beleid inzake apparaatbeheer en naleving. Consumentenapps zijn bedoeld voor een open, zelfgeregistreerd publiek, met minder strenge beveiligingseisen en snellere, frequentere releasecycli.
Apps voor medewerkers, apps voor klanten, apps voor partners en apps voor gedeelde apparaten of kiosken zijn de vier categorieën die aan de meeste gebruiksscenario’s kunnen voldoen. Buitendienst, goedkeuringen en interne tools zijn gebruiksscenario’s van apps voor medewerkers. Apps voor klanten zijn bedoeld voor de bank-, verzekerings- en detailhandel en zijn ontwikkeld voor de eigen klanten van een bedrijf. Apps voor partners zijn portalen voor dealers of distributeurs. Tot slot draaien apps voor gedeelde apparaten of kiosken op beveiligde hardware.
Het ontwikkelen van mobiele apps op maat voor bedrijven is zinvol wanneer de workflow, de integratiebehoeften of de offline-eisen zo specifiek zijn dat geen enkel kant-en-klaar product hier goed aan voldoet. Het kan gaan om unieke werkzaamheden in het veld, niet-standaard systeemkoppelingen of een UX-eis die verband houdt met een bepaalde taak.
Kant-en-klare oplossingen of low-code-oplossingen werken goed voor standaardworkflows. Als het niet je doel is om je op enigerlei wijze van je concurrenten te onderscheiden, maar je alleen een workflow wilt om interne processen te optimaliseren, dan zijn deze benaderingen het overwegen waard.
Native ontwikkeling is een betere keuze wanneer apps uitgebreide toegang tot de hardware, topprestaties of intensieve platformspecifieke functies nodig hebben, zoals verwerking op de achtergrond of complex gebruik van camera’s of sensoren. Meestal gaat het hierbij om apps voor buitendienstmedewerkers en logistiek. Kies voor apps op basis van een cross-platformframework wanneer een gedeelde codebasis voor iOS en Android belangrijker is dan het benutten van het allerlaatste prestatievoordeel van elk platform. Voor zakelijke kopers draait de beslissing meestal om iets anders: een interne app heeft een levensduur van vijf tot zeven jaar, dus vraag je af wie deze stack in het derde jaar zal onderhouden en hoe gemakkelijk je daarvoor personeel kunt aannemen. Low-code-platforms verkorten de tijd tot de eerste release, maar koppelen de levensduur van de app aan een licentie en de roadmap van de leverancier. Dit is een afweging die bewust moet worden gemaakt, en niet zomaar als standaardkeuze.
Meestal worden bedrijfsapps geïntegreerd met ERP- of CRM-systemen via een API-gateway of een ‘backend-for-frontend’-laag, die de gegevens uit de backend omzet voor mobiel gebruik en wijzigingen aan de backend-zijde verwerkt. Zo wordt voorkomen dat de mobiele app telkens uitvalt wanneer er een wijziging in het ERP-systeem plaatsvindt.
Apps die offline kunnen werken, slaan gegevens lokaal op het apparaat op en zetten alle wijzigingen die zonder verbinding zijn aangebracht in de wachtrij. Zodra de verbinding weer tot stand is gebracht, worden de wijzigingen en gegevens gesynchroniseerd. Om gegevensconflicten te voorkomen, moet je echter bepalen wat er gebeurt als hetzelfde record zowel op het apparaat als op de server wordt gewijzigd voordat de synchronisatie plaatsvindt.
De beveiliging volgt de OWASP Mobile Application Security Verification Standard (MASVS), die 24 specifieke controlemaatregelen omvat op het gebied van opslag, cryptografie, authenticatie, netwerkcommunicatie, platformgedrag, codekwaliteit, veerkracht en privacy. Bovenop die basisnorm gelden voor gereguleerde apps bovendien frameworkspecifieke vereisten, zoals HIPAA, PCI DSS en de AVG.
Met Mobile Device Management (MDM) kan IT beveiligingsbeleidsregels opleggen, apps installeren of blokkeren en bedrijfsgegevens van het apparaat wissen. Dit is belangrijk omdat MDM de laag is die bepaalt hoe de applicatie wordt geïmplementeerd en wat er met de bedrijfsgegevens gebeurt wanneer het apparaat wordt gestolen of de medewerker het bedrijf verlaat.
De kosten van mobiele bedrijfsapps zijn afhankelijk van uw zakelijke behoeften. De belangrijkste kostenfactoren zijn de integratie met bestaande systemen, nalevingsvereisten, de mogelijkheid om offline te werken en de omvang van de uitrol van apparaten.
De volledige ontwikkeling duurt 6 tot 18 maanden, afhankelijk van de integratie- en nalevingskwesties die daarbij een rol spelen. Eenvoudige apps die slechts in één bronsysteem worden geïntegreerd en waarvoor geen nalevingsvereisten gelden, kunnen binnen de kortste termijn van deze periode worden gerealiseerd. Complexere apps die met meerdere bronsystemen worden geïntegreerd of waarvoor goedkeuring door de toezichthouder vereist is, zullen vanwege het beoordelingsproces meer tijd in beslag nemen.
De ROI wordt doorgaans gemeten aan de hand van verschillende indicatoren, waaronder de acceptatiegraad, de tijd die nodig is om een taak te voltooien in vergelijking met het oude proces, het fouten- en herinvoerpercentage, en de terugverdientijd. Bij apps voor buitendienst en workflowvervanging wordt de ROI sneller zichtbaar, terwijl dit bij apps die gekoppeld zijn aan een grotere ERP-implementatie langer duurt, omdat de tijdlijn wordt bepaald door het trager werkende onderliggende systeem.
Kies een leverancier of bekwame ontwikkelaars van mobiele bedrijfsapps die rekening houden met identiteits-, integratie- en nalevingsvereisten voordat ze een framework voorstellen. Ze moeten ook kunnen aantonen dat hun beveiligingsprocessen in overeenstemming zijn met MASVS. Eerdere ervaring met het werken in een vergelijkbare regelgevende omgeving of met een systeem van record (specifieke ERP-oplossing, specifiek nalevingsproces voor de branche) is eveneens het overwegen waard.
