Bransjer

Vanligvis ikke. De fleste banker tjener mer på å pakke kjernen inn i veldefinerte API-er og bygge nye produkter og kanaler som tjenester rundt den. Det holder primærsystemet stabilt mens kundevendte deler endres raskere. Der en kjerne virkelig må erstattes, planlegger vi migreringen i trinn, med avstemming mellom begge systemene til det gamle slås av.

Les mer: Fintech og finansielle tjenesterLenke til dette spørsmålet

Ja. Vi bygger tjenester som oppretter, validerer og leser ISO 20022-meldinger, både for bedriftsbetalinger og rapportering, som pain.001 og camt.053, og for interbankmeldingene som brukes av sanntids- og betalingssystemer for høye verdier. Hver ordning og bank har egne regler, så vi arbeider ut fra deres implementeringsveiledninger og tester i deres testmiljøer.

Les mer: Fintech og finansielle tjenesterLenke til dette spørsmålet

Ja. Vi kombinerer regler som analytikerne dine kan lese og endre, med maskinlæringsmodeller trent på dine egne data, og vi forklarer hvorfor hvert varsel ble utløst. Varsler går til en saksbehandlingskø der analytikere bestemmer, og beslutningene deres føres tilbake til reglene og modellene. Der dere allerede bruker spesialiserte screeningleverandører, kobler vi dem til.

Les mer: Fintech og finansielle tjenesterLenke til dette spørsmålet

Vi designer etter WCAG 2.2 AA fra første prototype, skriver i klarspråk og tester med tastatur, skjermleser og forstørrelse. Automatiske tilgjengelighetssjekker kjøres i leveransepipelinen, og før større utgivelser tester vi med personer som bruker hjelpeteknologi.

Les mer: Offentlig sektorLenke til dette spørsmålet

Ja. Mange offentlige tjenester er avhengige av systemer som har levd lenge. Vi kobler til dem gjennom deres eksisterende grensesnitt, filer eller databaser, og setter et moderne API foran der det hjelper. Hvis en utskifting er nødvendig, skjer den i trinn, med begge systemer i drift til det nye er bevist.

Les mer: Offentlig sektorLenke til dette spørsmålet

En digital tvilling er en levende 3D-modell av en bygning, et feriested eller et område, matet med data fra enhetene og systemene der. Det er verdt å bygge den når mange team må planlegge, drifte eller øve på samme store eiendom. Vi starter med spørsmålene den skal svare på, og avgjør deretter hvilke data den trenger.

Les mer: Eiendom og reiselivLenke til dette spørsmålet

Ja. Vi starter med å kartlegge systemene dere har og grensesnittene leverandørene deres tilbyr, og kobler dem deretter sammen via API-er, hendelser eller filer. Å erstatte et system er et valg vi tar sammen med dere, aldri standardvalget.

Les mer: Eiendom og reiselivLenke til dette spørsmålet

Ja. Vi kobler ERP-systemet deres til UAE PINT-AE, Saudi ZATCA fase 2 og Omans e-fakturering, med automatisert validering og en unntaksbane for avviste fakturaer. Sprinten vår for e-fakturering og ERP-beredskap er et vanlig sted å begynne.

Les mer: Eiendom og reiselivLenke til dette spørsmålet

Sensor- og vedlikeholdshistorikk for enhetene i omfanget, og ingeniører som kan fortelle oss hvilke feil som betyr noe. Vi starter med enhetene der en uplanlagt stans koster mest, og beviser modellen der før vi utvider den.

Les mer: Energi og forsyningLenke til dette spørsmålet

Vi bygger datapipelinen bak dem: data samles inn fra driftssystemer, kontrolleres for kvalitet og spores tilbake til kilden. Rapporten viser da hvordan hvert tall ble produsert.

Les mer: Energi og forsyningLenke til dette spørsmålet

Butikken fortsetter å selge. Salg lagres lokalt og sendes når forbindelsen kommer tilbake, hvert med en unik identifikator slik at ingenting posteres to ganger. Pris- og lageroppdateringer legges i kø på samme måte. Drift kan se hvilke butikker som ligger etter og hvor mye, slik at en lang driftsstans oppdages med en gang, ikke ved månedsslutt.

Les mer: Detaljhandel og omnikanalLenke til dette spørsmålet

Vi integrerer POS-plattformer gjennom det de tilbyr: sky-API-er, butikkservere, databaseeksport eller filer. Før vi anslår, går vi gjennom POS-dokumentasjonen og et utvalg av dataene, fordi det avgjør tilnærmingen. Å nevne en POS-plattform eller et ERP-system på dette nettstedet betyr ikke et partnerskap med leverandøren.

Les mer: Detaljhandel og omnikanalLenke til dette spørsmålet

Ja. Vi bygger grensesnitt som sender og mottar HL7 v2-meldinger, som innleggelser, rekvisisjoner og svar, og tjenester som eksponerer eller bruker FHIR-ressurser. Vi mapper lokale koder til terminologiene partnerne dine forventer, og vi tester med deres testmiljøer før noe settes i produksjon.

Les mer: HelsevesenLenke til dette spørsmålet

Vanligvis ja, via grensesnittene leverandøren tilbyr: HL7 v2-strømmer, FHIR-API-er eller en integreringsmotor. Noen leverandører krever registrering eller godkjenning før en integrasjon settes i produksjon. Vi går gjennom leverandørens dokumentasjon tidlig, fordi den avgjør omfanget og planen.

Les mer: HelsevesenLenke til dette spørsmålet

Ikke hvis det bygges riktig. Vi bruker ERP-systemets støttede utvidelsespunkter, som API-er, hendelser og utvidelsesrammeverk, og holder egenutviklet kode atskilt fra standardproduktet. Hver utvidelse dokumenteres og testes, slik at den kan kontrolleres mot en ny versjon før du oppgraderer.

Les mer: Industri og ERP for store virksomheterLenke til dette spørsmålet

Vi arbeider med SAP S/4HANA og SAP Business One, Microsoft Dynamics 365 Finance and Supply Chain Management og Business Central, Oracle NetSuite, Oracle Fusion Cloud ERP, Odoo og Sage Intacct og Sage X3. Å nevne et produkt betyr ikke et partnerskap med leverandøren. Si oss hvilken versjon og hvilke moduler du har, for de avgjør integrasjonsmulighetene.

Les mer: Industri og ERP for store virksomheterLenke til dette spørsmålet

Ja. Vi designer integrasjoner som håndterer flere juridiske enheter, valutaer, banker og skatteregler fra én plattform, med innstillingene for hver enhet som konfigurasjon og ikke kode. Å legge til en enhet betyr da å legge til konfigurasjon og tester, ikke en ny integrasjon.

Les mer: Industri og ERP for store virksomheterLenke til dette spørsmålet

Ja. Vi bygger og vedlikeholder EDI-flyter i EDIFACT og ANSI X12, over AS2, SFTP eller et verdiøkende nettverk, for ordrer, leveringsvarsel, fakturaer og statusmeldinger. Vi oversetter også EDI til API-er og hendelser, slik at nyere systemer ikke selv må lese EDI, og vi tester hver flyt med handelspartneren før den settes i drift.

Les mer: Logistikk og distribusjonLenke til dette spørsmålet

Vi setter ett transportørlag mellom systemene dine og transportørene. Systemene dine booker, merker og sporer gjennom ett grensesnitt, og laget mapper hver forespørsel til den enkelte transportørens API eller filformat. Å legge til en transportør betyr da å legge til én mapping og testene for den, ikke å endre hvert system som sender. Priser, etiketter og sporingshendelser kommer tilbake i ett format.

Les mer: Logistikk og distribusjonLenke til dette spørsmålet

Ja. Vi utvider eksisterende systemer gjennom API-ene, meldingsgrensesnittene eller databasene deres, og legger til mobilverktøy og integrasjoner rundt dem. Hvis et system har nådd grensene sine, planlegger vi en gradvis utskifting, der begge systemene kjører til det nye er bevist.

Les mer: Logistikk og distribusjonLenke til dette spørsmålet

Vi velger isolasjonsnivå sammen med deg, per lag: delte eller separate databaser, skjemaer eller krypteringsnøkler, og grenser for datakraft og API-bruk. Valget avhenger av kundenes kontrakter, behovet for datalokalisering og kostnaden per leietaker.

Les mer: SaaS- og CRM-plattformerLenke til dette spørsmålet

Vanligvis, ja. Vi flytter én funksjon om gangen ut av monolitten med strangler-fig-mønsteret, bak automatiserte tester, slik at utgivelsene fortsetter hele veien.

Les mer: SaaS- og CRM-plattformerLenke til dette spørsmålet

Begge. Vi implementerer og utvider Salesforce, ServiceNow og Microsoft Power Platform, og vi bygger CRM-funksjoner inn i et produkt når det tjener virksomheten bedre. Vi anbefaler én løsning etter å ha sett på prosessene dine.

Les mer: SaaS- og CRM-plattformerLenke til dette spørsmålet

Vi designer for toppen fra starten, og beviser det deretter: belastnings- og kaostester ved og utover forventet publikum, og observerbarhet som varsler før brukerne merker det. I produksjon overvåker SRE-ingeniører plattformen og svarer innenfor avtalte tjenestenivåer.

Les mer: Medier og telekommunikasjonLenke til dette spørsmålet

Ja. Vi bygger klassifisering, personalisering og anbefalingsmotorer på dine publikums- og innholdsdata, i ditt miljø, og måler dem mot resultatene du bryr deg om.

Les mer: Medier og telekommunikasjonLenke til dette spørsmålet

Ja. Vi finjusterer arabisk-først-modeller og regionale dialektmodeller som Jais, Falcon og ALLaM, og hoster dem i en privat eller suveren sky når innholds- eller publikumsdata må forbli i landet.

Les mer: Medier og telekommunikasjonLenke til dette spørsmålet

Ja. Vi kartlegger innholds-, publikums- og faktureringssystemene du allerede drifter, og kobler til dem via deres API-er, hendelser eller filer. Nye plattformer bygges rundt dem, og en utskifting planlegges bare når den betaler seg selv.

Les mer: Medier og telekommunikasjonLenke til dette spørsmålet

Ja. Grensesnitt bygges for språk med høyre til venstre og venstre til høyre, og KI-en kan bruke arabisk-først-modeller og regionale dialektmodeller driftet i en privat eller suveren sky.

Les mer: Utdanning og kompetanseheving i arbeidslivetLenke til dette spørsmålet

Når det er kostbart, risikabelt eller vanskelig å øve på det virkelige utstyret eller i den virkelige situasjonen. Vi starter med oppgavene der feil koster mest, og måler om simuleringen forbedrer ytelsen.

Les mer: Utdanning og kompetanseheving i arbeidslivetLenke til dette spørsmålet

Vi designer og tester dem etter WCAG, med tanke på brukere av tastatur, skjermleser og forstørrelsesprogram, og vi inkluderer tilgjengelighetssjekker i automatisert testing.

Les mer: Utdanning og kompetanseheving i arbeidslivetLenke til dette spørsmålet