Mercura CPQ + IFS Cloud
Konfigurera komplexa produkter, beräkna rätt pris och skapa orderfärdiga konfigurationer medan IFS Cloud förblir källsystem för ERP och tillverkning.
IFS Cloud har redan kraftfull Configure-to-Order-funktionalitet, och IFS erbjuder nu även den egna CPQ-lösningen IFS CPQ. Mercura representerar en alternativ arkitektur: ett oberoende, modulärt CPQ-lager kopplat till IFS Cloud för tillverkare som vill använda IFS för ERP, tillverkning, kalkyl och orderexekvering samtidigt som de levererar dedikerade konfigurationsupplevelser i försäljning, CRM, återförsäljarkanaler, kundkanaler och digitala kanaler.
Försäljningsoffert
Vad är IFS CPQ?
Det finns tre olika nivåer som är viktiga att skilja mellan. En sökning på IFS CPQ kan syfta på flera närliggande funktioner och lösningar.
IFS Cloud har långvarig produktkonfigurationsfunktionalitet för Configure-to-Order-tillverkning. Konfigurerbara delar organiseras i konfigurationsfamiljer med egenskaper och alternativ. Regler guidar användare genom giltiga kombinationer, och konfigurationer kan användas i Sales Quotations, Customer Orders, shop orders, Dynamic Order Processing och andra tillverkningsprocesser.
IFS erbjuder också en dedikerad produkt som kallas IFS CPQ. IFS positionerar den som en inbäddad CPQ-upplevelse för komplex industriförsäljning med funktioner som Guided Selling, dynamisk prissättning, konfiguration på flera nivåer och systemnivå, prisstyrning, återförsäljar- och distributörsupplevelser samt kundvänt webbkonfiguration.
Ni kan också behålla IFS Cloud som ERP- och tillverkningsplattform och använda ett separat CPQ-system som Mercura för produktkonfiguration, prissättning, visualisering och digitala försäljningsupplevelser. Den här arkitekturen är särskilt relevant när konfiguration måste fungera över system och kanaler utanför IFS.
En bekräftad IFS CPQ-konfiguration kan skapa motsvarande IFS-källrader med rätt Sales Parts, kvantiteter och IFS CTO Configuration IDs.
Befintlig konfigurator
Ja. Det är viktigt.
En trovärdig CPQ-utvärdering bör inte utgå från antagandet att IFS saknar produktkonfiguration. IFS Clouds befintliga Sales Configurator och Configure-to-Order-funktionalitet kan guida användare genom egenskaper och alternativ, tillämpa konfigurationsregler, beräkna konfigurationsberoende prissättning och koppla den resulterande konfigurationen till efterföljande tillverkningsprocesser.
IFS har därefter lagt till det separata IFS CPQ-erbjudandet för en bredare CPQ-försäljningsupplevelse.
Inte rätt fråga
Kan IFS konfigurera produkter?
Inte längre hela frågan
Har IFS CPQ?
Frågan som spelar roll
Vilken konfigurationsarkitektur passar våra produkter, användare, försäljningskanaler och IFS-miljö?
Arkitekturval
Rätt svar beror på problemet ni löser.
Använd IFS för tillverknings- och driftskunskap som hör hemma i IFS. Välj den CPQ-arkitektur som bäst tjänar de som faktiskt konfigurerar och köper produkten.
Trevägsjämförelse
| Kapacitet | IFS Cloud CTO / Sales Configurator | IFS CPQ | Mercura + IFS Cloud |
|---|---|---|---|
| IFS ERP och tillverkning | Nativt | Native integration | IFS förblir ansvarig |
| Konfigurerbara delar | Ja | Använder IFS CTO-integration | Kan mappas till IFS konfigurerade delar |
| Egenskaper och alternativ | Ja | Ja | Ja |
| Konfigurationsregler | Ja | Ja | Ja |
| Guided Selling | Ja, konfigurationsorienterat | Ja | Ja |
| Konfigurationsprissättning | Ja | Ja | Ja |
| Dynamisk prisstyrning | IFS prissättningsfunktioner | Ja | Ja |
| Integration med Sales Quotation | Nativt | Native integration | API-integration |
| Integration med Customer Order | Nativt | Native integration | API-integration |
| IFS CTO Configuration ID | Nativt | Skapas via integration | Kan mappas där det krävs |
| BOM / routing-utvärdering | Nativt IFS-ansvar | Kopplat till IFS CTO | IFS kan förbli tillverkningsmaster |
| Konfiguration på flera nivåer | Tillverkningsstrukturer | Ja | Ja |
| Försäljning på systemnivå | Beror på modell | Ja | Ja |
| Återförsäljar- / distributörsupplevelse | IFS B2B-möjligheter | Ja | Ja |
| Webbkonfigurator för kunder | Kräver vald IFS-arkitektur | Ja | Ja |
| Anpassad frontend / SDK-arkitektur | Inte kärnsyftet | IFS CPQ-arkitektur | En central del av Mercuras arkitektur |
| CRM-first-arbetsflöde | Kräver integration | Beror på landskap | Kärnintegrationsmönster |
| Multi-ERP / ERP-oberoende CPQ | Nej | IFS-orienterat | Ja |
| Interaktiv 2D / 3D | Beror på implementation | Stöds; 3D-tillgångar är kundens ansvar | En central del av Mercuras arkitektur |
| Passar bäst för | Tillverkningscentrerat CTO | IFS-centrerat end-to-end-CPQ | Modulärt CPQ för flera försäljningskanaler kring IFS |
Inbäddad CPQ-arkitektur
Den här distinktionen är användbar för arkitekturteam.
IFS beskriver IFS CPQ kommersiellt som inbäddat i IFS Cloud och nativt integrerat med IFS Cloud Manufacturing.
IFS egen tekniska dokumentation förklarar hur det fungerar under ytan. CPQ-lösningen tillhandahålls som en extern applikation och kopplas till IFS Cloud med:
En CPQ-applikation behöver inte köras inuti själva ERP-applikationen för att vara djupt integrerad med IFS Cloud.
Mercura följer samma breda princip om ansvarsfördelning: IFS fortsätter att äga ERP och tillverkningsutförande, medan CPQ utbyter strukturerad information med IFS via stödda integrationsgränssnitt.
Skillnaden är vilken CPQ-plattform ni vill använda.
Vad IFS Cloud bör äga
För en IFS-tillverkare bör målet inte vara att återskapa IFS i CPQ. IFS är exceptionellt starkt i tillverkningsutförande. Beroende på er implementation kan IFS förbli auktoritativt för:
Mercura bör konsumera eller referera till den information som försäljningskonfigurationsprocessen faktiskt behöver.
Vad CPQ bör äga
CPQ-lagret handlar främst om att omvandla krav till något som IFS kan exekvera. Mercura kan hantera:
Omvandla kundkrav till tekniskt meningsfulla val.
Tillämpa beroenden, begränsningar och beräkningar medan användaren konfigurerar.
Visa användare vad de bygger.
Generera kommersiella och tekniska dokument från den strukturerade konfigurationen.
Configure-to-Order i IFS
IFS CTO-förmågor går längre än en enkel ERP-artikeluppslagning.
En konfigurerbar del är kopplad till en konfigurationsfamilj. Familjen definierar gemensamma egenskaper och alternativ som beskriver giltiga varianter. IFS Sales Configurator kan sedan guida en användare genom valen.
Regler kan:
Används i:
IFS stödjer också revisionskontroll av konfigurationer och återanvändning av identiska befintliga konfigurationer.
Det innebär att en IFS-integration bör återanvända den befintliga CTO-modellen där den är värdefull — inte ersätta den blint.
ERP och tillverkning
Konfigurera · Pris · Offert
Order- och affärshantering
Försäljningskanaler
Interna ERP-användare är bara en möjlig målgrupp. Komplexa produkter säljs också via CRM-användare, fältförsäljning, distributörer, återförsäljare, partners, ingenjörer, kunder och e-handelsanvändare. Ett dedikerat CPQ-lager låter samma styrda produktkunskap exponeras genom olika upplevelser.
Starta konfiguration från en möjlighet eller försäljningsprocess. Försäljning får vägledning utan att behöva förstå hela den underliggande tillverkningsstrukturen.
Ge externa försäljningskanaler kontrollerad åtkomst till relevanta produkter, giltiga konfigurationsregler, kundspecifika sortiment, kommersiell logik och offertgenerering utan att exponera hela ERP-gränssnittet. IFS CPQ erbjuder också portalfunktioner för återförsäljare och distributörer, så organisationer bör jämföra den erforderliga upplevelsen i stället för att automatiskt anta att externt CPQ behövs.
Låt kunder konfigurera produkter direkt via er webbplats eller portal. IFS CPQ inkluderar kundvända webbkonfiguratorfunktioner. Mercura är relevant när den upplevelsen ska vara del av en bredare headless- eller anpassad digital arkitektur snarare än främst en IFS-centrerad lösning.
Många tillverkare använder IFS för ERP och tillverkning men en annan plattform för CRM. En typisk arkitektur är därför CRM → Mercura CPQ → IFS Cloud. Det undviker att tvinga säljare in i ERP bara för att tillverkningen körs där.
Det är en av de starkaste anledningarna att utvärdera specialiserat CPQ vid sidan av IFS CPQ. Vissa organisationer driver:
Ska produktkonfiguration vara en IFS-förmåga exponerad utåt, eller ett oberoende produktkunskapslager kopplat till IFS och resten av stacken?
Det finns inget universellt rätt svar. Det är ett arkitekturbeslut.
Visuell CPQ
Komplexa industriprodukter är ofta svåra att sälja enbart med egenskaper och ERP-fält. Mercura kan kombinera konfigurationslogik med visuell återkoppling.
IFS CPQ stödjer också visuella konfigurationsscenarier; IFS produktvillkor anger särskilt att eventuella 3D-modeller som krävs för IFS CPQ är kundens ansvar.
Använd samma strukturerade konfiguration för att skapa märkesanpassade offertdokument — och mappa sedan det godkända resultatet till IFS Cloud.
När Mercura passar
Mercura är särskilt relevant när CPQ-problemet sträcker sig bortom ERP-konfiguration.
Konfiguratorn bör öppnas från CRM eller ett annat försäljningsarbetsutrymme.
De behöver en varumärkesupplevelse snarare än ett ERP-orienterat gränssnitt.
Produktkonfiguratorn är en digital försäljningsprodukt i sig.
En CPQ-modell måste tjäna flera ERP-, CRM- eller affärsenheter.
Kunder behöver se resultatet medan de konfigurerar.
Försäljningslogik förändras i annan takt än ERP-masterdata.
Konfiguration måste konsumeras via API:er och anpassade applikationer.
CPQ-lagret behöver orkestrera produktkunskap över IFS, CRM, PIM, CAD och andra system.
När IFS CPQ passar
Om IFS Cloud tydligt är centrum i försäljnings- och tillverkningsarkitekturen och ni vill ha CPQ-lösningen levererad inom IFS-ekosystemet förtjänar IFS CPQ allvarlig övervägning.
Mercura bör inte läggas till bara för att lägga till ytterligare en applikation.
När Sales Configurator räcker
Inte varje IFS-kund behöver ett dedikerat CPQ-produkt alls.
Det är ofta den första arkitekturfrågan som är värd att besvara.
Tillverkningsöverlämning
Det är här IFS är särskilt starkt. En försäljningskonfigurator bör inte skapa en vacker offert som tillverkningen inte kan exekvera. Integrationen bör fastställa hur den godkända kommersiella konfigurationen blir rätt tillverkningsinput i IFS.
Mercura fastställer vilken befintlig Sales Part som motsvarar kundens krav. Den resulterande delen och kvantiteten överförs till relevant IFS-försäljningsprocess.
Bäst när: Ni tillverkar eller lagrar en ändlig katalog av giltiga varianter.
Mercura fångar de nödvändiga valen och mappar dem till motsvarande IFS-konfigurationsegenskaper och alternativ. IFS förblir ansvarig för den formella CTO-konfigurationen och dess efterföljande tillverkningsutvärdering.
Bäst när: Er befintliga IFS CTO-uppsättning innehåller redan den tillverkningslogik ni vill bevara.
En konfiguration på hög nivå kan resultera i flera Sales Parts och kvantiteter. IFS kan sedan använda sina tillverkningskonfigurationsregler, produktstrukturer, routings, DOP eller andra efterföljande processer för att fastställa hur ordern ska uppfyllas.
Bäst när: CPQ äger försäljningslösningen medan IFS äger tillverkningsdefinitionen.
IFS kan utvärdera konfigurationsregler för att skapa tillverkningsstrukturer. Konfigurerade produkter kan mata produktstrukturer och routinglogik, och IFS stödjer skapande av DOP-strukturer baserat på konfigurationsutvärdering.
Bäst när: Kundens val avgör direkt komponenter och tillverkningsoperationer.
Inte varje ETO-produkt kan eller bör automatiseras helt. Mercura kan standardisera allt som är repeterbart och producera de parametrar som engineering behöver. Engineering färdigställer sedan produkten innan den godkända BOM, projektstruktur eller tillverkningsdefinition går in i IFS.
Bäst när: Varje order innehåller genuint engineering-arbete, men försäljning kan fortfarande automatisera en betydande del av konfigurationen.
Rätt arkitektur beror på er tillverkningsprocess. Vi antar inte att varje tillverkare ska generera BOMs på exakt samma sätt.
Interimorder
IFS erbjuder en intressant bro mellan konfiguration, kalkyl och engineering. En konfigurerad produkt på en Sales Quotation eller Customer Order kan brytas ned till en interimorder.
För komplexa tillverkare skapar det här en stark arkitektur:
Det kan vara att föredra framför att flytta detaljerad tillverkningskalkyl till CPQ-plattformen.
Prisägarskap
IFS har redan omfattande prissättningsfunktioner. Duplicera dem inte i onödan.
För konfigurerbara Sales Parts kan IFS beräkna pris med baspriset för den okonfigurerade Sales Part, det ekonomiska värdet av konfigurationsegenskaper och det ekonomiska värdet av alternativ.
Mercura konfigurerar produkten och begär eller konsumerar relevant pris från IFS.
Bäst när
IFS innehåller redan den kommersiella prislogiken, kundprissättning hör hemma i ERP, styrning av försäljningspriser är ERP-kontrollerad och konfigurationen kräver inte väsentlig ytterligare CPQ-prissättning.
Exempel: IFS Sales Part-pris + valda dimensioner + materialfaktor + prestandapaket + tillbehör + projektspecifika tillägg = konfigurerat försäljningspris.
Bäst när
ERP äger standardkommersiell data men slutligt försäljningspris beror på beräkningar som bara finns i konfigurationskontexten.
Mercura utför den fullständiga konfigurationsberäkningen och skickar det resulterande kommersiella värdet till den överenskomna IFS-transaktionsprocessen.
Bäst när
Prissättning är oupplösligt kopplad till en hög specialiserad konfigurationsmodell.
Om ni väljer IFS CPQ marknadsför IFS dynamisk prissättning, scenariomodellering, godkännandeflöden och marginalskydd som kärnfunktioner. I den arkitekturen finns det sällan skäl att införa ytterligare ett CPQ-prislager.
Bäst när
Ni vill ha ett enda styrt CPQ-prislager inom IFS-ekosystemet.
Det viktigaste prisbeslutet är inte vilket system som har den kraftfullaste prissättningsmotorn.
Vilket system ska äga varje prisregel? Kundavtal, prislistor och ERP-kommersiell logik kan höra hemma i IFS. Konfigurationsformler kan höra hemma i CPQ. Tillverkningskostnad hör nära IFS Costing och tillverkning. Godkännandelogik bör ha ett enda styrt hem.
En bra IFS CPQ-arkitektur minimerar duplicerade regler.
IFS Cloud-integration
REST och OData
IFS Cloud exponerar affärsfunktionalitet via REST API:er baserade på OData. IFS beskriver REST API:er som den föredragna integrationsmetoden och exponerar IFS Cloud Projections som kan återanvändas för integration. Standard HTTP-operationer som GET, POST, PUT, PATCH och DELETE stöds beroende på API.
För system-till-system-integrationer rekommenderar IFS OAuth 2.0 client credentials flow. Den externa applikationen erhåller en access token via en IFS IAM-klient och använder den token när relevanta API:er anropas.
Extern konfiguration
Ja.
IFS dokumentation anger uttryckligen att en konfiguration kan initieras av en extern applikation. IFS egen moderna CPQ-integration demonstrerar också det här arkitekturmönstret.
För en Mercura-implementation skulle vi först fastställa vilket IFS-stött affärsflöde som ska äga den resulterande konfigurationen — i stället för att anta att varje kund kräver samma mappning.
Datautbyte
En typisk design kan omfatta:
| Data | Riktning | Syfte |
|---|---|---|
| Sales Parts | IFS → Mercura | Återanvänd ERP-produktmaster |
| Delinformation | IFS → Mercura | Teknisk/produktkontext |
| Kunder | IFS → Mercura | Kundspecifik offertgivning |
| Företag | IFS → Mercura | Organisationskontext |
| Anläggningar | IFS → Mercura | Tillverknings-/kommersiell kontext |
| Enheter | IFS → Mercura | Konsekventa kvantiteter |
| Prisinformation | IFS → Mercura | ERP-prisinput |
| Lager / tillgänglighet | IFS → Mercura | Försäljningstillgänglighet där relevant |
| Konfigurationsegenskaper | IFS → Mercura | Återanvänd befintlig CTO-modell |
| Konfigurationsalternativ | IFS → Mercura | Återanvänd tillåtna IFS-värden |
| Kostnadsinformation | IFS → Mercura | Där kommersiellt lämpligt |
| Konfiguration | Mercura → IFS | Godkänd produktdefinition |
| Sales Parts | Mercura → IFS | Konfigurerade kommersiella rader |
| Kvantiteter | Mercura → IFS | Orderkvantiteter |
| Konfigurationsreferens | Mercura → IFS | Spårbarhet till CPQ |
| Sales Quotation-data | Mercura → IFS | Fortsätt offertflöde |
| Customer Order-data | Mercura → IFS | Fortsätt orderprocess |
| Tekniska parametrar | Mercura → IFS | Efterföljande tillverkningskontext |
| Komponentdata | Mercura → IFS | Där överenskommen arkitektur kräver det |
Landskapskvalificering
IFS-implementationer skiljer sig avsevärt. Innan integrationen definieras granskar vi:
Resultatet bör vara en integrationsdesign baserad på er faktiska IFS-miljö — inte ett generiskt connector-diagram.
Beslutsstöd
IFS CPQ är IFS Configure, Price, Quote-erbjudande för tillverkare som säljer komplexa konfigurerbara produkter. IFS positionerar det som en inbäddad IFS Cloud-upplevelse med Guided Selling, konfiguration, dynamisk prissättning, godkännanden, konfiguration på flera nivåer och systemnivå, stöd för återförsäljare/distributörer och kundvänt webbkonfiguration.
Ja. IFS Cloud inkluderar långvarig Configure-to-Order- och Sales Configurator-funktionalitet baserad på konfigurerbara delar, konfigurationsfamiljer, egenskaper, alternativ och konfigurationsregler. IFS CPQ är ett bredare CPQ-erbjudande byggt kring och integrerat med dessa tillverkningsförmågor.
IFS Sales Configurator är en del av den underliggande IFS Configure-to-Order-funktionaliteten och fokuserar på att skapa giltiga konfigurationer av konfigurerbara delar. IFS CPQ är det bredare försäljningslagret. Det tillför en dedikerad CPQ-upplevelse med funktioner som Guided Selling, dynamisk prisstyrning, konfiguration på systemnivå och externa försäljningsupplevelser samtidigt som resultatet integreras med IFS affärsobjekt och CTO.
Kommersiellt beskriver IFS IFS CPQ som inbäddat och nativt integrerat med IFS Cloud. Tekniskt beskriver IFS dokumentation CPQ-lösningen som en extern applikation integrerad med IFS Cloud via REST-anrop, IFS Connect, SSO, webhooks och dedikerade integrationsanvändare. Det ger användare en inbäddad upplevelse samtidigt som CPQ-tjänstarkitekturen förblir separat.
Ja. Mercura kan användas som ett oberoende CPQ-lager vid sidan av IFS Cloud i stället för IFS CPQ. Bättre arkitektur beror på er befintliga IFS CTO-modell, försäljningskanaler, CRM-strategi, frontend-krav, systemlandskap och hur tätt ni vill koppla CPQ till IFS-ekosystemet.
Nej. IFS bör fortsätta äga ERP, tillverkning och operativa processer. Mercura hanterar försäljningskonfigurationsupplevelsen och skickar det godkända resultatet till den överenskomna IFS-processen.
Ja, en integration kan designas för att bevara en befintlig IFS CTO-arkitektur. Mercura kan till exempel fastställa eller samla konfigurationsval medan IFS förblir ansvarig för den formella konfigurerade delen, Configuration ID och efterföljande tillverkningsutvärdering. Exakt modell beror på kundens CTO-uppsättning.
IFS dokumentation tillåter uttryckligen att konfigurationer initieras av externa applikationer. Rätt integration bör använda stödda IFS API:er och bevara de affärsvalideringar som kundens IFS-process kräver.
IFS Cloud exponerar REST API:er med OData och Projections. IFS anger att REST API:er är det föredragna integrationsalternativet. En integration kan använda Premium APIs, Integration APIs, standardprojections, IFS Connect eller andra stödda gränssnitt beroende på affärsprocess.
IFS Cloud REST API-dokumentation →IFS rekommenderar OAuth 2.0 client credentials för system-till-system-integrationer. Slutlig autentiseringsuppsättning beror på interaktionsmönster och IFS-miljö.
IFS OAuth-dokumentation →Den kan finnas i IFS, Mercura eller i en kontrollerad hybridarkitektur. IFS stödjer redan sofistikerad konfigurerad prissättning med baspriser, egenskaps- och alternativprissättning, formler och kombinationstabeller. Återskapa inte den logiken i CPQ utan tydlig anledning.
IFS CTO kan utvärdera konfigurationer för att fastställa efterföljande tillverkningsstrukturer, inklusive konfigurationsdrivna DOP-strukturer och operationer. Mercura kan tillhandahålla försäljningskonfigurationen medan IFS fortsätter utvärdera och exekvera tillverkningslogiken.
Ja. IFS stödjer interimorder för konfigurerade Sales Quotation- och Customer Order-rader. Dessa kan brytas ned för inspektion och uppskattad kostnadssammanräkning, och mindre engineering-ändringar kan göras före omberäkning av kostnad. Det kan vara särskilt användbart för komplexa eller delvis konstruerade produkter.
Ja. Både IFS CPQ och Mercura kan stödja externa försäljningsupplevelser. IFS CPQ marknadsför portalfunktioner för återförsäljare/distributörer och kundvända webbkonfiguratorer. Mercura är särskilt relevant när de upplevelserna måste bäddas in i en bredare anpassad eller multi-system-arkitektur.
Ja. En vanlig arkitektur är CRM → Mercura CPQ → IFS Cloud. CRM äger möjligheten, Mercura äger försäljningskonfigurationsupplevelsen och IFS äger operativ exekvering.
Den här sidan fokuserar främst på IFS Cloud. Äldre IFS Applications-miljöer använder andra integrationstekniker och bör bedömas individuellt innan arkitekturen definieras.
Officiella tekniska resurser
Tekniskt innehåll senast granskat augusti 2026. Validera antaganden mot er IFS Cloud-version, aktiverade moduler och integrationslandskap.
Utforska kapabilitetsstacken
IFS driver driften. Använd den CPQ-arkitektur som bäst driver försäljningen.
Om ni redan använder IFS är den första frågan inte om ni behöver ytterligare programvara. Det handlar om var konfigurationskunskap ska finnas. För vissa organisationer räcker den befintliga IFS Sales Configurator. För andra är det nya IFS CPQ-produktet den mest naturliga utvidgningen av IFS Cloud. Och för tillverkare som behöver ett modulärt konfigurationslager över CRM, ERP, återförsäljare, kunder och anpassade digitala upplevelser kan Mercura tillhandahålla CPQ-lagret medan IFS förblir ryggraden för tillverkning och drift. Ta med en konfigurerbar produkt, ett exempel på offert och en översikt över er nuvarande IFS CTO-uppsättning. Vi kan kartlägga var produktregler, prissättning, kalkyl och tillverkningslogik bör finnas — och om Mercura, IFS CPQ eller den befintliga IFS-konfiguratorn passar bäst.