Mercura CPQ + IFS Cloud
Konfigurer komplekse produkter, beregn den rigtige pris og opret ordreklare konfigurationer, mens IFS Cloud fortsat er det centrale system for ERP og produktion.
IFS Cloud har allerede stærk Configure-to-Order-funktionalitet, og IFS tilbyder nu også et dedikeret IFS CPQ-produkt. Mercura repræsenterer en alternativ arkitektur: et uafhængigt CPQ-lag forbundet til IFS Cloud for producenter, der vil bruge IFS til ERP, produktion, kalkulation og ordrehåndtering, samtidig med at de leverer konfigurationsoplevelser på tværs af salg, CRM, forhandlere, kunder og digitale kanaler.
Salgstilbud
Hvad er IFS CPQ?
Der er faktisk tre forskellige ting, der er værd at forstå. En søgning på IFS CPQ kan referere til flere relaterede muligheder.
IFS Cloud har i mange år understøttet produktkonfiguration til Configure-to-Order-produktion. Konfigurerbare dele organiseres i konfigurationsfamilier med egenskaber og valgmuligheder. Regler guider brugere gennem gyldige kombinationer, og konfigurationer kan bruges i salgstilbud, kundeordrer, produktionsordrer, Dynamic Order Processing og andre produktionsprocesser.
IFS tilbyder nu også et dedikeret produkt kaldet IFS CPQ. IFS positionerer det som en indlejret CPQ-oplevelse til komplekst produktionssalg med funktioner som guided selling, dynamisk prissætning, konfiguration på flere niveauer og systemniveau, prisstyring, løsninger til forhandlere og distributører samt kundevendt webkonfiguration.
Du kan også beholde IFS Cloud som ERP- og produktionsplatform og bruge et separat CPQ-system som Mercura til produktkonfiguration, prissætning, visualisering og digitale salgsoplevelser. Denne arkitektur er særligt relevant, når konfiguration skal fungere på tværs af systemer og kanaler uden for IFS.
En bekræftet IFS CPQ-konfiguration kan oprette de tilsvarende IFS-kildelinjer med de relevante salgsdele, mængder og IFS CTO Configuration ID'er.
Eksisterende konfigurator
Ja. Det er vigtigt.
En troværdig CPQ-evaluering bør ikke starte med antagelsen om, at IFS mangler produktkonfiguration. IFS Clouds eksisterende Sales Configurator og Configure-to-Order-funktionalitet kan guide brugere gennem karakteristika og optioner, anvende konfigurationsregler, beregne konfigurationsafhængig prissætning og forbinde den resulterende konfiguration med efterfølgende produktionsprocesser.
IFS har siden tilføjet det separate IFS CPQ-tilbud til en bredere CPQ-salgsoplevelse.
Ikke det rigtige spørgsmål
Kan IFS konfigurere produkter?
Ikke længere det eneste spørgsmål
Har IFS CPQ?
Det nyttige spørgsmål
Hvilken konfigurationsarkitektur passer til vores produkter, brugere, salgskanaler og IFS-miljø?
Arkitekturvalg
Det rigtige svar afhænger af det problem, I løser.
Brug IFS til den produktions- og driftsviden, der hører hjemme i IFS. Brug den CPQ-arkitektur, der bedst betjener dem, der faktisk konfigurerer og køber produktet.
Trevægs-sammenligning
| Kapacitet | IFS Cloud CTO / Sales Configurator | IFS CPQ | Mercura + IFS Cloud |
|---|---|---|---|
| IFS ERP og produktion | Native | Native integration | IFS forbliver ansvarlig |
| Konfigurerbare dele | Ja | Bruger IFS CTO-integration | Kan mappes til IFS-konfigurerede dele |
| Karakteristika og optioner | Ja | Ja | Ja |
| Konfigurationsregler | Ja | Ja | Ja |
| Guided selling | Ja, konfigurationsorienteret | Ja | Ja |
| Konfigurationsprissætning | Ja | Ja | Ja |
| Dynamisk prisstyring | IFS-prismuligheder | Ja | Ja |
| Integration med salgstilbud | Native | Native integration | API-integration |
| Integration med kundeordre | Native | Native integration | API-integration |
| IFS CTO Configuration ID | Native | Oprettes via integration | Kan mappes hvor påkrævet |
| BOM / routing-evaluering | Native IFS-ansvar | Forbundet til IFS CTO | IFS kan forblive produktionsmaster |
| Konfiguration på flere niveauer | Produktionsstrukturer | Ja | Ja |
| Salg på systemniveau | Afhænger af model | Ja | Ja |
| Forhandler- / forhandleroplevelse | IFS B2B-muligheder | Ja | Ja |
| Kundevendt webkonfigurator | Kræver valgt IFS-arkitektur | Ja | Ja |
| Tilpasset frontend / SDK-tilgang | Ikke kernens formål | IFS CPQ-arkitektur | Kerne-Mercura-arkitektur |
| CRM-først-workflow | Kræver integration | Afhænger af landskab | Kerneintegrationsmønster |
| Multi-ERP / ERP-uafhængigt CPQ | Nej | IFS-orienteret | Ja |
| Interaktiv 2D / 3D | Afhænger af implementering | Understøttet; 3D-aktiver forbliver kundens ansvar | Kerne-Mercura-kapabilitet |
| Bedst egnet | Produktionscentreret CTO | IFS-centreret end-to-end CPQ | Sammensætteligt, multikanals-CPQ omkring IFS |
Indlejret CPQ-arkitektur
Denne distinktion er nyttig for arkitekturteams.
IFS beskriver IFS CPQ kommercielt som indlejret i IFS Cloud og nativt integreret med IFS Cloud Manufacturing.
IFS' egen tekniske dokumentation forklarer, hvordan dette fungerer under overfladen. CPQ-løsningen provisioneres som en ekstern applikation og forbindes til IFS Cloud via:
En CPQ-applikation behøver ikke køre inde i selve ERP-applikationen for at være dybt integreret med IFS Cloud.
Mercura følger samme brede princip om ansvarsfordeling: IFS fortsætter med at eje ERP og produktionsudførelse, mens CPQ udveksler struktureret information med IFS via understøttede integrationsgrænseflader.
Forskellen er, hvilken CPQ-platform I vil bruge.
Hvad IFS Cloud bør eje
For en IFS-producent bør målet ikke være at genskabe IFS i CPQ. IFS står særligt stærkt på styring og eksekvering af produktionen. Afhængigt af jeres implementering kan IFS fortsat være det autoritative system for:
Mercura bør forbruge eller referere den information, som salgskonfigurationsprocessen faktisk har brug for.
Hvad CPQ bør eje
CPQ-laget handler primært om at omsætte krav til noget, IFS kan udføre. Mercura kan håndtere:
Omsæt kundekrav til teknisk meningsfulde valg.
Anvend afhængigheder, begrænsninger og beregninger, mens brugeren konfigurerer.
Vis brugerne, hvad de bygger.
Generer kommercielle og tekniske dokumenter fra den strukturerede konfiguration.
Configure-to-Order i IFS
IFS' CTO-muligheder går dybere end et simpelt ERP-vareopslag.
En konfigurerbar del er forbundet til en konfigurationsfamilie. Familien definerer fælles karakteristika og optioner til at beskrive gyldige varianter. IFS Sales Configurator kan derefter guide en bruger gennem valgene.
Regler kan:
Anvendes i:
IFS understøtter også revisionskontrol af konfigurationer og genbrug af identiske eksisterende konfigurationer.
Det betyder, at en IFS-integration bør genbruge den eksisterende CTO-model, hvor den er værdifuld — ikke blindt erstatte den.
ERP og produktion
Konfigurer · Pris · Tilbud
Kommerciel eksekvering
Salgskanaler
Interne ERP-brugere er kun ét muligt publikum. Komplekse produkter kan også sælges af CRM-brugere, feltsalg, distributører, forhandlere, forhandlere, partnere, ingeniører, kunder og e-handelsbrugere. Et dedikeret CPQ-lag lader den samme styrede produktviden eksponeres gennem forskellige oplevelser.
Start konfiguration fra en mulighed eller salgsproces. Salg får vejledning uden at skulle forstå den fulde underliggende produktionsstruktur.
Giv eksterne salgskanaler kontrolleret adgang til relevante produkter, gyldige konfigurationsregler, kundespecifikke sortimenter, kommerciel logik og tilbudsgenerering uden at eksponere hele ERP-grænsefladen. IFS CPQ tilbyder også forhandler- og forhandlerportalmuligheder, så organisationer bør sammenligne den krævede oplevelse frem for at antage, at eksternt CPQ automatisk er nødvendigt.
Lad kunder konfigurere produkter direkte via jeres hjemmeside eller portal. IFS CPQ inkluderer kundevendte webkonfiguratormuligheder. Mercura er relevant, når I ønsker, at oplevelsen skal være en del af en bredere headless- eller tilpasset digital arkitektur frem for primært en IFS-centreret løsning.
Mange producenter bruger IFS til ERP og produktion, men en anden platform til CRM. En typisk arkitektur kan derfor være CRM → Mercura CPQ → IFS Cloud. Det undgår at tvinge sælgere ind i ERP blot fordi produktionen kører der.
Det er en af de stærkeste grunde til at evaluere et specialiseret CPQ sammen med IFS CPQ. Nogle organisationer driver:
Skal produktkonfiguration være en IFS-kapabilitet eksponeret udad, eller et uafhængigt produktvidenlag forbundet til IFS og resten af stacken?
Der er ikke ét universelt korrekt svar. Det er en arkitekturbeslutning.
Visuelt CPQ
Komplekse industriprodukter er ofte svære at sælge med karakteristika og ERP-felter alene. Mercura kan kombinere konfigurationslogik med visuel feedback.
IFS CPQ understøtter også visuelle konfigurationsscenarier; IFS' produktvilkår angiver specifikt, at eventuelle 3D-modeller, der kræves til IFS CPQ, er kundens ansvar.
Brug den samme strukturerede konfiguration til at oprette brandede tilbudsdokumenter — og kortlæg derefter det godkendte resultat til IFS Cloud.
Hvornår Mercura passer
Mercura er særligt relevant, når CPQ-problemet rækker ud over ERP-konfiguration.
Konfiguratoren bør åbne fra CRM eller et andet salgsarbejdsområde.
De har brug for en brandet oplevelse frem for en ERP-orienteret grænseflade.
Produktkonfiguratoren er et digitalt salgsprodukt i sig selv.
Én CPQ-model skal betjene flere ERP-, CRM- eller forretningsenheder.
Kunder skal se resultatet, mens de konfigurerer.
Salgslogik ændrer sig i et andet tempo end ERP-stamdata.
Konfiguration skal forbruges via API'er og tilpassede applikationer.
CPQ-laget skal orkestrere produktviden på tværs af IFS, CRM, PIM, CAD og andre systemer.
Hvornår IFS CPQ passer
Hvis IFS Cloud tydeligt er centrum for salgs- og produktionsarkitekturen, og I ønsker CPQ-løsningen leveret inden for IFS-økosystemet, fortjener IFS CPQ seriøs overvejelse.
Mercura bør ikke tilføjes blot for at tilføje endnu en applikation.
Hvornår Sales Configurator er nok
Ikke alle IFS-kunder har behov for et dedikeret CPQ-system.
Det er ofte det første arkitekturspørgsmål, der er værd at besvare.
Produktionsoverdragelse
Her er IFS særligt stærkt. En salgskonfigurator bør ikke skabe et smukt tilbud, som produktionen ikke kan udføre. Integrationen bør fastlægge, hvordan den godkendte kommercielle konfiguration bliver de rigtige data til produktionsprocessen i IFS.
Mercura fastslår, hvilket eksisterende Sales Part der svarer til kundens krav. Den resulterende del og mængde overføres til den relevante IFS-salgsproces.
Bedst når: I producerer eller lagerfører et endeligt katalog af gyldige varianter.
Mercura indfanger de nødvendige valg og mapper dem til de tilsvarende IFS-konfigurationskarakteristika og -optioner. IFS forbliver ansvarlig for den formelle CTO-konfiguration og dens efterfølgende produktionsevaluering.
Bedst når: Jeres eksisterende IFS CTO-opsætning indeholder allerede den produktionslogik, I vil bevare.
Én konfiguration på højt niveau kan resultere i flere salgsdele og mængder. IFS kan derefter bruge sine produktionskonfigurationsregler, produktstrukturer, routings, DOP eller andre downstream-processer til at fastlægge, hvordan ordren skal opfyldes.
Bedst når: CPQ ejer salgsløsningen, mens IFS ejer produktionsdefinitionen.
IFS kan evaluere konfigurationsregler for at oprette produktionsstrukturer. Konfigurerede produkter kan fodre produktstrukturer og routing-logik, og IFS understøtter oprettelse af DOP-strukturer baseret på konfigurationsevaluering.
Bedst når: Kundens valg bestemmer direkte komponenter og produktionsoperationer.
Ikke alle ETO-produkter kan eller bør fuldt automatiseres. Mercura kan standardisere alt, der kan gentages, og producere de parametre, engineering har brug for. Engineering færdiggør derefter produktet, før den godkendte BOM, projektstruktur eller produktionsdefinition indgår i IFS.
Bedst når: Hver ordre indeholder ægte engineering-arbejde, men salg kan stadig automatisere en væsentlig del af konfigurationen.
Den rigtige arkitektur afhænger af jeres produktionsproces. Vi antager ikke, at alle producenter bør generere BOM'er på præcis samme måde.
Interimordrer
IFS giver en interessant bro mellem konfiguration, kalkulation og engineering. Et konfigureret produkt på et salgstilbud eller en kundeordre kan eksploderes til en interimordre.
For komplekse producenter skaber dette en stærk arkitektur:
Det kan være at foretrække frem for at flytte detaljeret produktionskalkulation ind i CPQ-platformen.
Ansvar for prissætningen
IFS har allerede omfattende prisfunktionalitet. Dupliker den ikke unødigt.
For konfigurerbare salgsdele kan IFS beregne pris ved hjælp af grundprisen for den ukonfigurerede salgsdel, den økonomiske værdi af konfigurationskarakteristika og den økonomiske værdi af optioner.
Mercura konfigurerer produktet og anmoder om eller forbruger den relevante pris fra IFS.
Bedst når
IFS indeholder allerede den kommercielle prislogik, kundepriser hører til i ERP, salgsprisstyring er ERP-styret, og konfiguration kræver ikke væsentlig yderligere CPQ-prissætning.
Eksempel: IFS-salgsdelpris + valgte dimensioner + materialfaktor + ydelsespakke + tilbehør + projektspecifikke tillæg = konfigureret salgspris.
Bedst når
ERP ejer standard kommercielle data, men den endelige salgspris afhænger af beregninger, der kun findes i konfigurationskonteksten.
Mercura udfører den fulde konfigurationsberegning og sender den resulterende kommercielle værdi til den aftalte IFS-transaktionsproces.
Bedst når
Prissætning er uadskillelig fra en meget specialiseret konfigurationsmodel.
Hvis I vælger IFS CPQ, markedsfører IFS dynamisk prissætning, scenariemodellering, godkendelsesworkflows og marginbeskyttelse som kernefunktioner. I den arkitektur er der måske ringe grund til at introducere endnu et CPQ-prislag.
Bedst når
I ønsker ét styret CPQ-prislag leveret inden for IFS-økosystemet.
Den vigtigste prisbeslutning er ikke, hvilket system der har den mest kraftfulde prisengine.
Hvilket system bør eje hver prisregel? Kundeaftaler, prislister og ERP-kommerciel logik kan høre til i IFS. Konfigurationsformler kan høre til i CPQ. Produktionsomkostning hører tæt på IFS Costing og produktion. Godkendelseslogik bør have ét styret hjem.
En god IFS CPQ-arkitektur minimerer duplikerede regler.
IFS Cloud-integration
REST og OData
IFS Cloud eksponerer forretningsfunktionalitet via REST API'er baseret på OData. IFS beskriver REST API'er som den foretrukne integrationsmetode og eksponerer IFS Cloud Projections, der kan genbruges til integration. Standard HTTP-operationer som GET, POST, PUT, PATCH og DELETE understøttes afhængigt af API'et.
Til system-til-system-integrationer anbefaler IFS OAuth 2.0 client credentials flow. Den eksterne applikation opnår et access token via en IFS IAM-klient og bruger det token, når de relevante API'er kaldes.
Ekstern konfiguration
Ja.
IFS-dokumentation angiver eksplicit, at en konfiguration kan initieres af en ekstern applikation. IFS' egen moderne CPQ-integration demonstrerer også dette arkitekturmønster.
For en Mercura-implementering vil vi først fastlægge, hvilken IFS-understøttet forretningsflow der skal eje den resulterende konfiguration, frem for at antage, at alle kunder kræver den samme mapping.
Dataudveksling
Et typisk design kan omfatte:
| Data | Retning | Formål |
|---|---|---|
| Sales parts | IFS → Mercura | Genbrug ERP-produktmaster |
| Part information | IFS → Mercura | Teknisk/produktkontekst |
| Customers | IFS → Mercura | Kundespecifik tilbudsgivning |
| Companies | IFS → Mercura | Organisatorisk kontekst |
| Sites | IFS → Mercura | Produktions-/kommerciel kontekst |
| Units | IFS → Mercura | Konsistente mængder |
| Price information | IFS → Mercura | ERP-prisinput |
| Inventory / availability | IFS → Mercura | Salgs tilgængelighed hvor relevant |
| Configuration characteristics | IFS → Mercura | Genbrug eksisterende CTO-model |
| Configuration options | IFS → Mercura | Genbrug tilladte IFS-værdier |
| Cost information | IFS → Mercura | Hvor kommercielt passende |
| Configuration | Mercura → IFS | Godkendt produktdefinition |
| Sales parts | Mercura → IFS | Konfigurerede kommercielle linjer |
| Mængder | Mercura → IFS | Ordremængder |
| Configuration reference | Mercura → IFS | Sporbarhed til CPQ |
| Sales quotation data | Mercura → IFS | Fortsæt tilbudsflow |
| Customer order data | Mercura → IFS | Fortsæt ordreproces |
| Tekniske parametre | Mercura → IFS | Downstream produktionskontekst |
| Component data | Mercura → IFS | Hvor aftalt arkitektur kræver det |
Landskabskvalificering
IFS-implementeringer varierer betydeligt. Før vi definerer integrationen, gennemgår vi:
Resultatet bør være et integrationsdesign baseret på jeres faktiske IFS-miljø frem for et generisk connector-diagram.
Beslutningsstøtte
IFS CPQ er IFS' Configure, Price, Quote-tilbud til producenter, der sælger komplekse konfigurerbare produkter. IFS positionerer det som en indlejret IFS Cloud-oplevelse med guided selling, konfiguration, dynamisk prissætning, godkendelser, konfiguration på flere niveauer og systemniveau, forhandler-/forhandlerstøtte og kundevendt webkonfiguration.
Ja. IFS Cloud inkluderer langvarig Configure-to-Order- og Sales Configurator-funktionalitet baseret på konfigurerbare dele, konfigurationsfamilier, karakteristika, optioner og konfigurationsregler. IFS CPQ er et bredere CPQ-tilbud bygget omkring og integreret med disse produktionsmuligheder.
IFS Sales Configurator er en del af den underliggende IFS Configure-to-Order-funktionalitet og fokuserer på at oprette gyldige konfigurationer af konfigurerbare dele. IFS CPQ er det bredere salgslagsprodukt. Det tilføjer en dedikeret CPQ-oplevelse med funktioner som guided selling, dynamisk prisstyring, konfiguration på systemniveau og eksterne salgsoplevelser, mens resultatet integreres med IFS-forretningsobjekter og CTO.
Kommercielt beskriver IFS IFS CPQ som indlejret og nativt integreret med IFS Cloud. Teknisk beskriver IFS-dokumentation CPQ-løsningen som en ekstern applikation integreret med IFS Cloud via REST-kald, IFS Connect, SSO, webhooks og dedikerede integrationsbrugere. Det giver brugerne en indlejret oplevelse, mens en separat CPQ-servicearkitektur bevares.
Ja. Mercura kan bruges som et uafhængigt CPQ-lag sammen med IFS Cloud i stedet for IFS CPQ. Den bedre arkitektur afhænger af jeres eksisterende IFS CTO-model, salgskanaler, CRM-strategi, frontend-krav, systemlandskab og hvor tæt I ønsjer CPQ koblet til IFS-økosystemet.
Nej. IFS bør fortsat eje ERP, produktion og driftsprocesser. Mercura håndterer salgskonfigurationsoplevelsen og sender det godkendte resultat til den aftalte IFS-proces.
Ja, en integration kan designes til at bevare en eksisterende IFS CTO-arkitektur. Mercura kan f.eks. fastslå eller indsamle konfigurationsvalg, mens IFS forbliver ansvarlig for den formelle konfigurerede del, Configuration ID og downstream produktionsevaluering. Den præcise model afhænger af kundens CTO-opsætning.
IFS-dokumentation tillader eksplicit, at konfigurationer initieres af eksterne applikationer. Den passende integration bør bruge understøttede IFS API'er og bevare de forretningsvalideringer, kundens IFS-proces kræver.
IFS Cloud eksponerer REST API'er via OData og Projections. IFS angiver, at REST API'er er den foretrukne integrationstilgang. En integration kan bruge Premium APIs, Integration APIs, standard projections, IFS Connect eller andre understøttede grænseflader afhængigt af forretningsprocessen.
IFS Cloud REST API-dokumentation →IFS anbefaler OAuth 2.0 client credentials til system-til-system-integrationer. Den endelige autentificeringsopsætning afhænger af interaktionsmønsteret og IFS-miljøet.
IFS OAuth-dokumentation →Den kan ligge i IFS, Mercura eller i en kontrolleret hybridarkitektur. IFS understøtter allerede sofistikeret konfigureret prissætning med grundpriser, karakteristika- og optionsprissætning, formler og kombinationstabeller. Genskab ikke den logik i CPQ, medmindre der er en klar grund.
IFS CTO kan evaluere konfigurationer for at fastlægge downstream produktionsstrukturer, inklusive konfigurationsdrevne DOP-strukturer og operationer. Mercura kan levere salgskonfigurationen, mens IFS fortsætter med at evaluere og udføre produktionslogikken.
Ja. IFS understøtter interimordrer for konfigurerede salgstilbuds- og kundeordrelinjer. Disse kan eksploderes til inspektion og estimeret omkostningsopsummering, og mindre engineering-ændringer kan foretages før genberegning af omkostningen. Det kan være særligt nyttigt for komplekse eller delvist engineerede produkter.
Ja. Både IFS CPQ og Mercura kan understøtte eksterne salgsoplevelser. IFS CPQ annoncerer forhandler-/forhandlerportal- og kundevendte webkonfiguratormuligheder. Mercura er særligt relevant, når disse oplevelser skal indlejres i en bredere tilpasset eller multi-system-arkitektur.
Ja. En almindelig arkitektur er CRM → Mercura CPQ → IFS Cloud. CRM ejer muligheden, Mercura ejer salgskonfigurationsoplevelsen, og IFS ejer driftsudførelsen.
Denne side fokuserer primært på IFS Cloud. Ældre IFS Applications-miljøer bruger andre integrationsteknologier og bør vurderes individuelt, før arkitekturen defineres.
Officielle tekniske ressourcer
Teknisk indhold sidst gennemgået august 2026. Valider antagelser mod jeres IFS Cloud-release, aktiverede moduler og integrationslandskab.
Udforsk kapabilitetsstakken
IFS driver driften. Brug den CPQ-arkitektur, der bedst driver salget.
Hvis I allerede bruger IFS, er det første spørgsmål ikke, om I har brug for endnu et stykke software. Det er, hvor konfigurationsviden skal ligge. For nogle organisationer er den eksisterende IFS Sales Configurator nok. For andre er det nye IFS CPQ-produkt den mest naturlige udvidelse af IFS Cloud. Og for producenter, der har brug for ét sammensætteligt konfigurationslag på tværs af CRM, ERP, forhandlere, kunder og tilpassede digitale oplevelser, kan Mercura levere CPQ-laget, mens IFS forbliver produktions- og driftsrygraden. Medbring et konfigurerbart produkt, et eksempeltilbud og et overblik over jeres nuværende IFS CTO-opsætning. Vi kan kortlægge, hvor produktregler, prissætning, kalkulation og produktionslogik bør ligge — og om Mercura, IFS CPQ eller den eksisterende IFS-konfigurator er det bedste valg.