Formularz został pomyślnie przesłany.
Więcej informacji można znaleźć w skrzynce pocztowej.
Zatrudnij nas
O nasUsługiTechnologiePortfolio
Według badania przeprowadzonego przez firmę Clutch, 86% pracowników korzystają z aplikacji mobilnych do wykonywania zadań służbowych. Firma 67% odnotowała wzrost wydajności. Widzimy to zapotrzebowanie. Potrzeba posiadania aplikacji mobilnej nie oznacza, że wystarczy dowolna aplikacja. Twoi pracownicy prawdopodobnie będą oczekiwać aplikacji, która będzie współpracować ze wszystkimi istniejącymi systemami, rolami i procesami zatwierdzania. Zaspokojenie tej potrzeby zaczyna się od mapowania, a dopiero potem następuje kodowanie.
Mobilna aplikacja dla przedsiębiorstw wspiera już działające systemy biznesowe. Może odczytywać i zapisywać dane za pośrednictwem systemu CRM lub Systemy ERP, uwierzytelniać się za pośrednictwem istniejącego dostawcy tożsamości firmy, uwzględniać role i uprawnienia przypisane każdemu użytkownikowi oraz działać zgodnie z polityką zarządzania urządzeniami i w środowisku operacyjnym, w którym zostało wdrożone.
Tworzenie mobilnych aplikacji dla przedsiębiorstw to ciąg decyzji, a ich kolejność ma znaczenie. Przedstawię Ci krok po kroku proces oceny potrzeb, wyboru między stworzeniem aplikacji a jej zakupem, projektowania architektury i integracji, zabezpieczenia aplikacji, wdrożenia oraz jej późniejszej eksploatacji.
Tworzenie aplikacji mobilnych dla przedsiębiorstw polega na projektowaniu, tworzeniu i utrzymywaniu aplikacji mobilnych zintegrowanych z firmowymi platformami ERP, CRM, zarządzania tożsamością oraz platformami danych. Działanie tych aplikacji regulują wewnętrzne zasady bezpieczeństwa i zgodności z przepisami.
Podczas gdy aplikacje konsumenckie są tworzone z myślą o jak najszerszym gronie odbiorców, aplikacje korporacyjne są przeznaczone dla określonych grup użytkowników o zdefiniowanych rolach i określonym dostępie do danych. Przyjrzyjmy się bliżej, czym różnią się te dwie kategorie:
| Czynnik | Enterprise | Konsument |
| Główni użytkownicy | Pracownicy, partnerzy lub klienci danej firmy, którym przypisano określone role | Ogół społeczeństwa, osoby zarejestrowane samodzielnie |
| Dystrybucja | Prywatne sklepy z aplikacjami, dystrybucja za pośrednictwem rozwiązań MDM/EMM, wewnętrzne katalogi | Publiczne sklepy z aplikacjami, takie jak App Store i Google Play |
| Uwierzytelnianie | SSO, MFA i dane biometryczne powiązane z tożsamością korporacyjną | Logowanie przez e-mail/serwisy społecznościowe, opcjonalne uwierzytelnianie wieloskładnikowe (MFA) |
| Źródło danych | ERP, CRM, wewnętrzne interfejsy API, systemy starszego typu | Backend publiczny lub przeznaczony dla konkretnej aplikacji |
| Podstawowe wymagania dotyczące bezpieczeństwa | Kryteria OWASP MASVS, polityka MDM, rejestrowanie audytowe, RODO/HIPAA/PCI DSS – w stosownych przypadkach | Recenzja sklepu z aplikacjami, polityka prywatności |
| Zachowanie w trybie offline | Często niezbędne w terenie, w magazynach oraz w obszarach o słabej łączności | Opcjonalne |
| Wdrażanie aktualizacji | W podziale na grupy urządzeń, regiony lub jednostki biznesowe | Szybkie, zazwyczaj automatyczne |
| Wskaźnik sukcesu | Czas wykonania zadania, wskaźnik błędów, stopień wykorzystania w poszczególnych rolach | Pobrania, DAU/MAU, czas trwania sesji |
| Właściciel | IT, jednostka biznesowa oraz dział bezpieczeństwa wspólnie | Zespół ds. produktów/biznesu |
Czy procesy biznesowe w Twojej firmie wymagają stworzenia aplikacji, czy też rozważasz jej wprowadzenie tylko dlatego, że konkurencja ją posiada? Zanim zaczniemy porównywać platformy programistyczne lub dostawców, radziłbym odpowiedzieć na pytanie: jaką konkretną lukę operacyjną wypełnia ta aplikacja?
Przeprowadźmy krótki test autodiagnostyczny. Przygotowałem listę kontrolną. Jeśli co najmniej dwa z poniższych punktów mają zastosowanie, warto rozważyć wdrożenie mobilnej aplikacji dla przedsiębiorstw.
Kolejnym krokiem jest dopasowanie Państwa inicjatywy do zadań, które ma ona wspierać. Pod względem grupy docelowej aplikacje korporacyjne dzielą się na te przeznaczone dla pracowników, klientów, partnerów oraz na urządzenia współdzielone. Pod względem funkcji można je podzielić na sześć poniższych kategorii. Określę, jakie funkcje są niezbędne i na czym powinni Państwo skoncentrować wysiłki programistyczne, aby mogli Państwo znaleźć odpowiednią dla siebie aplikację.
Architektura mobilna przedsiębiorstwa obejmuje cały łańcuch systemów, przez które aplikacja musi bezpiecznie przesyłać dane. Funkcjonujący stos mobilny przedsiębiorstwa zazwyczaj składa się z dziesięciu elementów:
Poniższy schemat przedstawia, w jaki sposób dane przepływają przez architekturę: z urządzenia, przez warstwy synchronizacji i bramki, do systemów, do których dane należą, a następnie z powrotem w postaci sygnałów monitorujących i dotyczących wykorzystania.
Przyjrzyjmy się bliżej niektórym niuansom związanym z korporacyjnymi aplikacjami mobilnymi, które sprawiają, że są one bardziej skomplikowane.
Uwierzytelnianie w aplikacjach korporacyjnych musi odbywać się za pośrednictwem istniejącego dostawcy tożsamości, tak aby rola i uprawnienia przypisane użytkownikowi na urządzeniu mobilnym odpowiadały uprawnieniom w innych systemach. Jeśli stworzysz samodzielny proces uwierzytelniania oparty na nazwie użytkownika i haśle, powstanie drugi system tożsamości, który trzeba będzie aktualizować, poddawać audytom i ostatecznie wycofać z użytku. Zalecam wdrożenie kontroli dostępu opartej na rolach (RBAC) na poziomie API, tak aby wszelkie zmiany następowały natychmiast. W przypadku urządzeń współdzielonych należy podjąć jeszcze jedną decyzję: na tablecie magazynowym lub w kiosku sesja musi kończyć się wraz z zakończeniem zmiany, dlatego należy zaplanować szybką zmianę użytkownika i automatyczne wylogowanie.
Gdy klient mobilny nawiązuje bezpośrednie połączenie ze starszym interfejsem API systemu ERP, każda zmiana w zapleczu wymaga ponownego skompilowania aplikacji klienckiej. Rozwiązania typu BFF lub bramy API pełnią rolę pośredników między tymi dwoma elementami. Przekształcają one interfejsy API zaplecza w format dostosowany do ekranów urządzeń mobilnych, wprowadzają ograniczenia szybkości i buforowanie oraz zapewniają inżynierom mobilnym stabilny interfejs do pracy, niezależnie od zmienności systemów zaplecza.
Jeśli aplikacja jest przeznaczona do obsługi terenowej, magazynów lub logistyki, musi działać w trybie offline. Oznacza to, że operacje zapisu są umieszczane w kolejce na urządzeniu i synchronizowane po przywróceniu połączenia. Oprócz kwestii kolejki należy podjąć cztery poniższe decyzje.
Monitorowanie awarii i wydajności — takie jak ślady sesji, opóźnienia API oraz wskaźnik sesji bez awarii — musi być powiązane z zachowaniem zaplecza. Celem jest umożliwienie ustalenia w ciągu kilku minut, czy gwałtowny wzrost liczby nieudanych prób logowania wynika z błędu aplikacji mobilnej, czy z awarii dostawcy tożsamości. Analiza użytkowania wpisuje się w ten sam kontekst: wskaźniki adopcji w podziale na role i typy urządzeń wskazują zespołowi, które procesy robocze warto rozwinąć w kolejnym sprincie, a które nie są wykorzystywane.
Zaznaczyłeś powyżej co najmniej dwa pola, więc możemy teraz założyć, że potrzebujesz aplikacji. Masz do wyboru cztery opcje: stworzyć własną aplikację od podstaw, kupić gotową aplikację, rozbudować istniejącą platformę lub zmodernizować posiadaną już aplikację. Sprawdźmy, która z nich bardziej Ci odpowiada:
| Podejście | Najlepiej sprawdza się, gdy | Główna zaleta | Główne ograniczenie |
| Stwórz własną aplikację mobilną | Masz specyficzne procesy robocze, integracje, rozwiązania w zakresie UX lub potrzeby związane z trybem offline | Całkowita kontrola | Większa złożoność i wyższe koszty, większa odpowiedzialność za dostawę i konserwację |
| Kup istniejącą aplikację | Wasze procesy są standardowe | Szybsze wdrożenie początkowe | Ograniczone możliwości różnicowania i dostosowywania |
| Rozszerz system ERP, CRM lub platformę typu „low-code” | Procesy są już skoncentrowane na jednej głównej platformie, a trzeba je dostosować do urządzeń mobilnych | Dane i zasady zarządzania są już wdrożone | Zależność od platformy i ograniczenia licencyjne |
| Modernizacja istniejącej aplikacji | Masz wartościowy produkt oparty na przestarzałej technologii | Zachowuje logikę biznesową i wartość dotychczasowych inwestycji | Mogą pozostać starsze zależności |
Standardem odniesienia jest standard weryfikacji bezpieczeństwa aplikacji mobilnych OWASP (MASVS), obecnie w wersji 2.1.0. Stanowi on ramy dla ośmiu różnych obszarów obejmujących 24 różne środki kontroli w zakresie przechowywania danych, kryptografii, uwierzytelniania, komunikacji sieciowej, interakcji z platformą, jakości kodu, odporności oraz prywatności. Test penetracyjny aplikacji mobilnej jest zazwyczaj oceniany w oparciu o standard MASVS, który służy jako wspólny punkt odniesienia dla zespołu ds. bezpieczeństwa, dostawcy aplikacji mobilnej, a nawet audytora. Na etapie zapytania ofertowego można śmiało zapytać dostawcę, zgodnie z którym profilem testowym zawartym w „Mobile Application Security Testing Guide” (MASTG) opracowuje swoje rozwiązania, oraz poprosić o wgląd w wyniki testów. Podczas gdy MASVS określa, jakie środki kontroli bezpieczeństwa należy wdrożyć, MASTG zawiera konkretne procedury testowe i wytyczne techniczne dotyczące sposobu weryfikacji tych środków.
Niektóre organizacje wykorzystują model Zero Trust jako wytyczną przy opracowywaniu zasad zarządzania urządzeniami mobilnymi (MDM). Obejmuje to wdrażanie kontroli stanu urządzeń oraz podejmowanie decyzji o dostępie w oparciu o kontekst. Ma to obecnie większe znaczenie, ponieważ model “Bring Your Own Device” (BYOD) stał się normą. Szacuje się, że dwie trzecie urządzeń uzyskujących dostęp do danych firmowych stanowi własność prywatną. Dlatego sposób zarządzania różni się w zależności od właściciela urządzenia. Urządzenia firmowe są zarządzane za pomocą MDM. W tym przypadku dział IT sprawuje kontrolę nad całym urządzeniem. Urządzenia prywatne są zarządzane za pomocą rozwiązania do zarządzania aplikacjami mobilnymi (MAM) oraz zasad bezpieczeństwa aplikacji. Dane i aplikacje firmowe są przechowywane w kontenerze, który dział IT może samodzielnie usunąć, podczas gdy pozostała część telefonu pozostaje poza zakresem systemu.
Podczas tworzenia aplikacji dla branż podlegających regulacjom architektura bezpieczeństwa musi być zgodna z obowiązującymi wymogami prawnymi. Na przykład rozporządzenie RODO reguluje przetwarzanie danych osobowych mieszkańców UE; ustawa HIPAA chroni chronione informacje zdrowotne (PHI) przechowywane przez organizacje podlegające tej ustawie oraz ich partnerów biznesowych w Stanach Zjednoczonych; a standard PCI DSS określa wymagania kontrolne dla organizacji przetwarzających dane posiadaczy kart. Ponadto organizacje mogą być zobowiązane do przestrzegania standardów branżowych lub przepisów, takich jak raportowanie SOC 2, wytyczne FFIEC lub lokalne wymogi bankowe, w zależności od konkretnego kontekstu operacyjnego i branży.
Kwestie związane z zarządzaniem są często rozpatrywane na końcu, ale mają zasadnicze znaczenie już od samego początku. Przed uruchomieniem aplikacji należy ustalić, kto będzie jej właścicielem po wdrożeniu, kto zatwierdza jej wersję do użytku w środowisku produkcyjnym, jakie są warunki umowy SLA dotyczące wsparcia technicznego oraz w jaki sposób jednostka biznesowa może zgłaszać prośby o zmiany. W jednym dokumencie należy uwzględnić dwa aspekty operacyjne: rotację certyfikatów i kluczy oraz to, co dzieje się z danymi firmowymi na urządzeniu w przypadku odejścia pracownika z firmy.
Gdy wszystkie niezbędne decyzje zostaną podjęte, można przystąpić do realizacji technicznej części tworzenie aplikacji mobilnych dla przedsiębiorstw. Przedstawię proces Innowise, podając krótkie opisy poszczególnych etapów:
Dało się zauważyć, że tworzenie aplikacji mobilnych dla przedsiębiorstw Zazwyczaj kosztuje od $100 000 do $600 000+. Nie polecałbym jednak opierania się na tych kwotach bez ustalenia wymagań i przeprowadzenia oceny potrzeb. Koszt zależy od liczby integracji systemowych, zakresu zgodności oraz wymagań dotyczących trybu offline. Zakres kosztów jest szeroki, ponieważ na budżet wpływają: integracja z istniejącymi systemami, zakres zgodności, złożoność trybu offline i synchronizacji, skala i zarządzanie urządzeniami oraz wybór platformy.
Ponadto uwzględniamy bieżącą konserwację. Bieżąca konserwacja kosztuje zazwyczaj od 10 do 20% pierwotnego kosztu wdrożenia rocznie. Jest to rozsądna wartość planistyczna, jeśli weźmie się pod uwagę instalację poprawek, aktualizacje systemu operacyjnego oraz zmiany w infrastrukturze zaplecza. W pierwszym roku koszty są często wyższe, ponieważ rzeczywiste użytkowanie ujawnia luki, które zostały pominięte podczas wdrożenia pilotażowego.
W końcu aplikacja została wdrożona. Następnie oceniamy jej skuteczność w trzech obszarach: stopnia przyjęcia przez użytkowników, wydajności operacyjnej oraz zwrotu finansowego.
| Obszar zainteresowania | Jak dokonać pomiaru | Dlaczego ma to znaczenie |
| Przyjęcie przez użytkowników |
| Gwarantuje, że pracownicy i interesariusze aktywnie korzystają z aplikacji, zapobiegając marnowaniu wysiłków związanych z jej tworzeniem i wspierając zmiany organizacyjne. |
| Wyniki operacyjne |
| Potwierdza, że aplikacja usprawnia procesy biznesowe, zmniejsza utrudnienia operacyjne i zapewnia niezawodne codzienne działanie. |
| Zwrot finansowy |
| Przedstawia kierownictwu wymierną wartość finansową oraz uzasadnienie kosztów, zapewniając długoterminową stabilność inwestycji. |
Aplikacje, które zastępują jedno ściśle określone, często powtarzające się zadanie, takie jak zatwierdzenie, skanowanie czy rejestracja, zazwyczaj szybko przynoszą zwrot z inwestycji. Aplikacje wdrażane w ramach wieloletniego projektu wdrożenia systemu ERP zwracają się dłużej, ponieważ tempo realizacji zależy od wolniejszego systemu, na którym są oparte.
W związku z tym, że sztuczna inteligencja jest aktywnie wdrażana do systemów korporacyjnych, nie mogę pominąć jej znaczenia w korporacyjnych aplikacjach mobilnych. W rzeczywistości możliwości sztucznej inteligencji dostępne w korporacyjnych aplikacjach mobilnych są dość ograniczone i powiązane z konkretnymi zadaniami. Każde z nich ma jasno określone kryteria sukcesu, takie jak wyodrębnienie danego pola, wykrycie określonej transakcji, przewidzenie problemu lub weryfikacja użytkownika.
W samej aplikacji można dodać czat oparty na modelu LLM, który pozwoli odpowiadać na zapytania klientów, klasyfikować zgłoszenia do pomocy technicznej oraz prowadzić użytkowników przez poszczególne etapy procesu. Funkcja ta stanowi uzupełnienie istniejących treści pomocy technicznej i procesów roboczych.
Technologia przetwarzania obrazu zastosowana w aparacie telefonu pozwala na wyodrębnianie danych ustrukturyzowanych. Twoi pracownicy nie muszą ręcznie wprowadzać informacji z rachunku wydatków, podpisanego formularza ani etykiety wysyłkowej. Zazwyczaj jako pierwsze z tej funkcji korzystają aplikacje przeznaczone dla pracowników terenowych oraz działów administracyjnych, ponieważ eliminuje ona konkretne, powtarzalne zadanie.
Rozpoznawanie twarzy i odcisków palców (Face ID, interfejsy API do obsługi danych biometrycznych w systemie Android) stało się standardem również w aplikacjach korporacyjnych. Różnica w stosunku do aplikacji konsumenckich polega na tym, że proces ten odbywa się bezpośrednio na urządzeniu, a nie poprzez wysyłanie danych biometrycznych na serwer.
Aplikacje mobilne dla przedsiębiorstw obsługują obecnie również asystentów głosowych, takich jak Siri, Asystent Google i podobne. Z punktu widzenia programistów nie wymaga to tworzenia od podstaw oddzielnej warstwy głosowej, ponieważ asystenci ci działają na poziomie systemu operacyjnego. Funkcja ta jest przydatna w sytuacjach, gdy użytkownik ma zajęte ręce i pisanie na klawiaturze nie jest praktyczne.
Powszechnie stosowane w aplikacjach bankowych, ubezpieczeniowych i płatniczych: modele, które monitorują w czasie rzeczywistym wzorce transakcji, sygnały z urządzeń oraz zachowania użytkowników, a następnie sygnalizują zdarzenia wykraczające poza normalny zakres dla danego konta. Kluczowy w tym przypadku wzorzec projektowy: model sygnalizuje; decyzję podejmuje człowiek lub zdefiniowany proces. Nie zalecam całkowicie automatycznego blokowania bez możliwości weryfikacji, ponieważ powoduje to najwięcej skarg ze strony klientów.
Funkcja ta jest powszechnie stosowana w aplikacjach przeznaczonych dla przemysłu produkcyjnego i serwisu terenowego: modele wytrenowane na danych z czujników oraz historii konserwacji wskazują, które urządzenia prawdopodobnie będą wymagały serwisu, zanim dojdzie do awarii. Następnie informacje te są przekazywane do aplikacji technika w formie zlecenia serwisowego.
Wykrywanie obiektów i klasyfikacja obrazów odbywają się za pomocą aparatu w telefonie lub tablecie w celu przeprowadzania kontroli bezpieczeństwa, kontroli jakości oraz sprawdzania stanu zasobów w branżach budowlanej, logistycznej i produkcyjnej. Zdjęcie palety, placu budowy lub elementu wyposażenia jest oceniane na podstawie określonych kryteriów.
Agent samodzielnie wykonuje określone zadanie. Może zmienić trasę dostawy i powiadomić magazyn o opóźnieniu lub przenieść dane ze zeskanowanego paragonu do raportu wydatków. Schemat powtarzający się we wszystkich przykładach jest dość wąski — chodzi o jeden zdefiniowany krok w ramach przepływu pracy, który aplikacja już obsługuje, przy czym wszelkie decyzje o istotnych konsekwencjach są zatwierdzane przez człowieka.
Innowise oferuje usługi w zakresie tworzenia aplikacji mobilnych dla przedsiębiorstw w całym stosie technologicznym: natywne aplikacje na iOS i Androida, rozwój międzyplatformowy, aplikacje hybrydowe oraz rozwiązania typu „low-code” na platformach takich jak Mendix. Nasi eksperci analizują Państwa wymagania i doradzają w wyborze najlepszego rozwiązania dla Państwa firmy.
Jako uznany firma zajmująca się tworzeniem aplikacji mobilnych dla przedsiębiorstw, posiadamy certyfikaty ISO 9001, 13485 oraz 27001/27017/27018 i jesteśmy partnerami firm AWS, Microsoft, SAP, Databricks, Odoo, InterSystems oraz UiPath. Jeśli chodzi o zgodność z przepisami, przestrzegamy standardów SOC 2, HIPAA, PCI DSS oraz RODO.
Jeśli chcesz zatrudnij programistów aplikacji mobilnych dla firm, Współpracujemy z firmami z różnych branż, w tym z sektora fintech i bankowości, opieki zdrowotnej i telemedycyny, ubezpieczeń, logistyki oraz operacji korporacyjnych. Nasi klienci często chwalą nas za szybkość realizacji bieżących prac nad nowymi funkcjami, elastyczność w reagowaniu na zmiany zakresu oraz jakość komunikacji podczas wielo-tygodniowych projektów.
Na zakończenie chciałbym podkreślić, że sukces tworzenia korporacyjnych aplikacji mobilnych zależy od pełnej spójności między strategią biznesową a infrastrukturą bazową. Oznacza to bezpośrednią integrację z istniejącymi systemami ERP, CRM oraz systemami bezpieczeństwa. Solidne zarządzanie tożsamością, skalowalna architektura oraz rygorystyczne przestrzeganie wymogów regulacyjnych od samego początku pomogą uniknąć kosztownych poprawek w przyszłości. Aplikacja mobilna opracowana z uwzględnieniem luk operacyjnych oraz rygorystycznych standardów, takich jak OWASP MASVS, wykracza poza rolę prostego narzędzia operacyjnego, stając się strategicznie ważnym zasobem, który zapewnia długoterminową wydajność i wartość biznesową.
Tworzenie aplikacji mobilnych dla przedsiębiorstw to proces projektowania, tworzenia i utrzymywania aplikacji mobilnych, które łączą się z istniejącymi systemami firmy, takimi jak systemy ERP, CRM, platformy zarządzania tożsamością oraz platformy danych. Aplikacje te są tworzone zgodnie z polityką bezpieczeństwa i zgodności obowiązującą w firmie.
Aplikacje korporacyjne uwierzytelniają się za pośrednictwem firmowych systemów tożsamości, łączą się z wewnętrznymi źródłami danych oraz są zgodne z wewnętrznymi zasadami zarządzania urządzeniami i zapewniania zgodności. Aplikacje konsumenckie są tworzone z myślą o otwartej, samodzielnie rejestrującej się grupie odbiorców, charakteryzują się mniej rygorystycznymi wymaganiami bezpieczeństwa oraz szybszymi i częstszymi cyklami wydawania nowych wersji.
Aplikacje dla pracowników, aplikacje dla klientów, aplikacje dla partnerów oraz aplikacje na urządzenia współdzielone lub kioski to cztery kategorie, które mogą zaspokoić większość potrzeb użytkowników. Obsługa terenowa, procesy zatwierdzania oraz narzędzia wewnętrzne to przykłady zastosowań aplikacji dla pracowników. Aplikacje przeznaczone dla klientów obejmują sektor bankowy, ubezpieczeniowy i detaliczny i są tworzone z myślą o klientach danej firmy. Aplikacje przeznaczone dla partnerów to portale dla dealerów lub dystrybutorów. Wreszcie aplikacje na urządzenia współdzielone lub kioski działają na sprzęcie o ograniczonym dostępie.
Tworzenie niestandardowych aplikacji mobilnych dla przedsiębiorstw ma sens, gdy procesy robocze, potrzeby w zakresie integracji lub wymagania dotyczące pracy w trybie offline są na tyle specyficzne, że żadne gotowe rozwiązanie nie spełnia ich w pełni. Mogą to być wyjątkowe operacje terenowe, niestandardowe połączenia systemowe lub wymagania dotyczące interfejsu użytkownika związane z konkretnym zadaniem.
Gotowe rozwiązania lub rozwiązania typu „low-code” sprawdzają się dobrze w przypadku standardowych przepływów pracy. Jeśli Twoim celem nie jest wyróżnienie się na tle konkurencji, a jedynie wdrożenie przepływu pracy w celu optymalizacji procesów wewnętrznych, warto rozważyć te podejścia.
Programowanie natywne jest lepszym wyborem, gdy aplikacje wymagają głębokiego dostępu do sprzętu, najwyższej wydajności lub zaawansowanych funkcji specyficznych dla danej platformy, takich jak przetwarzanie w tle czy złożone wykorzystanie aparatu lub czujników. Zazwyczaj są to aplikacje do obsługi terenowej i logistyki. Aplikacje oparte na frameworkach wieloplatformowych należy wybierać wtedy, gdy wspólna baza kodu dla systemów iOS i Android jest ważniejsza niż uzyskanie maksymalnej wydajności z każdej z platform. Dla nabywców korporacyjnych decyzja zazwyczaj zależy od czegoś innego: aplikacja wewnętrzna funkcjonuje od pięciu do siedmiu lat, więc należy zapytać, kto będzie utrzymywał ten stos technologiczny w trzecim roku i jak łatwo będzie można zatrudnić do tego odpowiednich specjalistów. Platformy typu „low-code” skracają czas wprowadzenia pierwszej wersji, ale wiążą żywotność aplikacji z licencją i planem rozwoju dostawcy, co jest kompromisem, który warto podjąć świadomie, a nie z braku alternatywy.
Zazwyczaj aplikacje korporacyjne integrują się z systemami ERP lub CRM za pośrednictwem bramki API lub warstwy „backend-for-frontend”, która przekształca dane z zaplecza pod kątem wykorzystania na urządzeniach mobilnych oraz przejmuje zmiany wprowadzane po stronie zaplecza. Dzięki temu aplikacja mobilna nie przestaje działać za każdym razem, gdy w systemie ERP pojawia się zmiana.
Aplikacje działające w trybie offline przechowują dane lokalnie na urządzeniu i umieszczają wszelkie zmiany wprowadzone bez połączenia z internetem w kolejce. Po przywróceniu połączenia synchronizują zmiany i dane. Aby jednak uniknąć konfliktów danych, należy ustalić, co ma się stać, gdy ten sam rekord zostanie zmieniony zarówno na urządzeniu, jak i na serwerze przed synchronizacją.
W zakresie bezpieczeństwa stosowany jest standard OWASP Mobile Application Security Verification Standard (MASVS), który obejmuje 24 konkretne środki kontroli dotyczące przechowywania danych, kryptografii, uwierzytelniania, komunikacji sieciowej, działania platformy, jakości kodu, odporności oraz prywatności. Oprócz tych podstawowych wymagań aplikacje podlegające regulacjom muszą spełniać dodatkowe wymagania specyficzne dla danego systemu, takie jak HIPAA, PCI DSS i RODO.
Zarządzanie urządzeniami mobilnymi (MDM) pozwala firmie IT na wdrażanie zasad bezpieczeństwa, instalowanie lub blokowanie aplikacji oraz usuwanie danych firmowych z urządzenia. Jest to istotne, ponieważ MDM stanowi warstwę, która określa sposób wdrażania aplikacji oraz to, co stanie się z danymi firmowymi w przypadku kradzieży urządzenia lub odejścia pracownika.
Koszt aplikacji mobilnych dla przedsiębiorstw zależy od wymagań danej firmy. Głównymi czynnikami wpływającymi na koszt są: integracja z istniejącymi systemami, wymogi dotyczące zgodności z przepisami, możliwość pracy w trybie offline oraz skala wdrożenia urządzeń.
Pełne opracowanie aplikacji trwa od 6 do 18 miesięcy, w zależności od kwestii związanych z integracją i zgodnością z przepisami. Proste aplikacje, które integrują się tylko z jednym systemem referencyjnym i nie podlegają żadnym wymogom zgodności, można zrealizować w najkrótszym możliwym terminie z podanego przedziału czasowego. Bardziej złożone aplikacje, które integrują się z wieloma systemami referencyjnymi lub wymagają zatwierdzenia przez organy regulacyjne, będą wymagały więcej czasu ze względu na proces weryfikacji.
Zwrot z inwestycji (ROI) mierzy się zazwyczaj na podstawie kilku wskaźników, w tym wskaźnika wdrożenia, czasu realizacji zadań w porównaniu ze starym procesem, wskaźnika błędów i ponownego wprowadzania danych oraz okresu zwrotu inwestycji. Zwrot z inwestycji staje się widoczny szybciej w przypadku aplikacji do obsługi serwisu terenowego i zastępujących dotychczasowe procesy robocze, natomiast w przypadku aplikacji powiązanych z wdrożeniem większego systemu ERP trwa to dłużej, ponieważ harmonogram jest uzależniony od wolniej działającego systemu bazowego.
Wybierz dostawcę lub wykwalifikowanych programistów aplikacji mobilnych dla przedsiębiorstw, którzy przed zaproponowaniem frameworka uwzględniają kwestie tożsamości, integracji i zgodności z przepisami. Powinni oni również być w stanie wykazać, że stosują procesy bezpieczeństwa zgodne z MASVS. Warto również zwrócić uwagę na wcześniejsze doświadczenie w pracy w podobnym środowisku regulacyjnym lub z systemem ewidencyjnym (konkretne rozwiązanie ERP, procesy zapewnienia zgodności z przepisami w danej branży).
