Přejít na obsah
Všechny články

Pořízení DMS

Jak vybrat DMS: zadání poptávky a hodnoticí tabulka pro evropského prodejce

Nejlepší RFP porovnává konkrétní nabízený produkt, trh a implementaci prostřednictvím reálných pracovních postupů, smluvních důkazů a předem stanoveného hodnocení.

Stručná odpověď: Nejprve definujte obchodní výsledky a nepřekročitelné požadavky jednotlivých zemí. Požádejte každého dodavatele o předvedení stejných úplných scénářů se stejnými daty. Pomocí pevných vah hodnoťte prokázané schopnosti, integraci, migraci, zabezpečení, služby a celkové náklady. Stavy Potvrzeno, Veřejně nepotvrzeno a Neposuzováno evidujte odděleně od úsudku hodnotitele.
Vedení dealerské skupiny vyhodnocuje schopnosti softwaru napříč více provozovnami
Hodnoticí tabulka je nástroj řízení rozhodnutí, nikoli ozdobný seznam funkcí.

Klíčové závěry

  • Hodnoťte konkrétní produkt, nasazení a zemi, nikoli marketing dodavatele jako celku.
  • Před váženým hodnocením použijte vyřazovací kritéria způsobilosti.
  • Nechte dodavatele předvést běžné i výjimečné pracovní postupy.
  • Vyžadujte důkazy pro API, zabezpečení, lokalizaci, migraci a výsledky.
  • Oddělte stav veřejných důkazů od konečného ověření v nákupním procesu.

1. Sestavte rozhodovací tým a vymezte rozsah

Výběr DMS ovlivňuje prodej, ojeté vozy, servis, díly, finance, IT, ochranu osobních údajů a skupinový reporting. Sestavte rozhodovací tým s odpovědnými vlastníky provozních oblastí, nejen se zástupci. Určete jednoho výkonného sponzora, vlastníka produktu, vedoucího dat, vedoucího integrací, vedoucího zabezpečení a ochrany osobních údajů, finančního kontrolora a vedoucího změny. Definujte, kdo doporučuje, kdo schvaluje a kdo může návrh odmítnout kvůli povinnému požadavku.

Zdokumentujte právní subjekty, provozovny, značky, země, jazyky, uživatele, objemy transakcí a kritická období. Oddělte současný rozsah od realistického tříletého plánu. Požadavek na každý hypotetický budoucí trh může rozhodnutí zkreslit, zatímco opomenutí pravděpodobné expanze může vyvolat další výměnu systému.

2. Převeďte potřeby na ověřitelné požadavky

Požadavek má určit aktéra, spouštěč, data, akci, výstup a akceptaci. Nahraďte „silné CRM“ požadavkem „poptávka z webu, od výrobce nebo po telefonu se přiřadí či vytvoří, zaznamená se souhlas, zájemce se směruje podle značky a geografické oblasti, je vidět vlastník a SLA, komunikace se zachytí a uzavřený obchod vrátí stav bez duplicitního zákazníka“.

Vytvořte matici zemí a výrobců. Do každé buňky zaznamenejte požadavky na účetnictví, daně, faktury, platby, registraci, záruky, díly, kampaně, reporting, identitu a jazyk. Evropské prostředí je výrazně různorodé. Údaje Eurostatu o osobních automobilech ukazují velké rozdíly mezi zeměmi ve stáří vozového parku a pohonech; pravidla EU pro ochranu osobních údajů, přístup k datům a elektronickou fakturaci přitom stále vyžadují místní implementaci.[1]

3. Použijte vyřazovací kritéria, vážená kritéria a úrovně důkazů

Trychtýř výběru DMSProces postupuje od vyřazovacích kritérií přes doloženou odpověď, demonstraci podle scénáře, ověření a obchodní posouzení až k rozhodnutí. Kritériatrh, výrobce RFPdůkazy Ukázkascénáře Ověřeníreference, technika SmlouvaTCO, SLA, odchod Rozhodnutí

Vyřazovací kritéria brání tomu, aby vysoké celkové skóre zakrylo zásadní nedostatek. Příkladem je produkční podpora požadované země, konkrétní rozhraní výrobce, povinný účetní výstup, hranice umístění dat nebo termín migrace. Nesplněné kritérium lze vyřešit pouze schválenou nápravou s termínem, vlastníkem, náklady a smluvním závazkem.

Ilustrativní struktura hodnocení; váhy musí odpovídat potřebám dealera
OblastIlustrativní váhaPožadované důkazy
Úplné funkční pracovní postupy25%Demonstrace podle scénáře v nabízeném produktu
Soulad se zemí a výrobcem15%Konkrétní produkční reference a specifikace
Data, API a ekosystém15%Katalog, testovací prostředí, limity, vlastnictví, pravidla změn
Migrace a implementace15%Plán, zdroje, akceptace, návrat zpět, reference
Zabezpečení, ochrana osobních údajů a odolnost10%Zprávy, architektura, DPA, test obnovy po havárii a kontrolní opatření
Uživatelská zkušenost a osvojení10%Testování úloh podle rolí a plán školení
Pětileté TCO a smlouva10%Cenový model, indexace, změny, podpora a odchod

4. Připravte scénáře demonstrací namísto přijímání prohlídek produktu

Poskytněte reprezentativní, ale bezpečná data a pevné scénáře. Požádejte dodavatele, aby předvedl průchod zájemce nabídkou, protiúčtem a objednávkou; ojetého vozu oceněním, prohlídkou, přípravou, médii, publikací, cenotvorbou a prodejem; servisní zakázky rezervací, prací technika, díly, dodatečným schválením a fakturou; a postup uzávěrky období nebo manažerského reportingu.

Přidejte výjimky: duplicitního zákazníka, nesprávné VIN, zrušený obchod, nedostupný díl, selhání rozhraní, prohlídku offline, storno faktury a uživatele, který opustí proces v jeho průběhu. Počítejte systémy, kliknutí, znovu zadávané hodnoty, ruční exporty a neviditelné závislosti na pozadí. Zaznamenejte předvedenou verzi a trh.

Standardy mohou zlepšit interoperabilitu, ale nenahrazují demonstraci. STAR zveřejňuje automobilová API pro zájemce, obchody a předání vozidel zákazníkům a doménový model maloobchodu.[2] Zeptejte se, zda a jak dodavatel implementuje relevantní standardy, a poté otestujte skutečné nabízené rozhraní.

5. Ověřte tvrzení o cloudu, API, zabezpečení a datech

U cloudu rozlište SaaS, vyhrazený hosting a hostovanou původní architekturu. Vyžádejte si definice dostupnosti, historii incidentů, RPO, RTO, důkazy testování záloh a obnovy, pravidla údržby a kapacitní model. U API vyžadujte objekty, pole, události, zápisové operace, autentizaci, testovací prostředí, limity požadavků, poplatky za překročení, verzování, monitoring a práva na export dat.

U ochrany osobních údajů a zabezpečení posuďte role, minimální oprávnění, MFA, protokolování, šifrování, správu zranitelností, další zpracovatele, mechanismus předávání, dobu uchování, mazání, oznamování incidentů a nezávislé ověření. GDPR vyžaduje opatření přiměřená riziku a záměrnou ochranu osobních údajů, certifikace ani poskytovatel cloudu však automaticky nezajišťují soulad dealera.[3] Pokyny ENISA mohou strukturovat požadavky na důkazy, působnost NIS2 se však musí posoudit samostatně.[4]

6. Spravedlivě používejte stavy veřejných důkazů

Ilustrativní současný záznam veřejných důkazů, nikoli konečné skóre RFP
Konkrétní produkt/trhDůkazy o otevřenosti/APIDůkazy o zabezpečeníInterpretace
Nextlane Platform, EvropaPotvrzeno: oficiální prezentace otevřeného APIPotvrzeno: transformace s AWS a deklarovaný cíl umístění dat v EUKonkrétní DMS a stav migrace je nutné ověřit v nabídce
Platforma Pinewood, globálně/EvropaPotvrzeno: prohlášení o API DMS a konkrétní integracePotvrzeno: veřejná prohlášení o ISORozsah, zprávy a komerční přístup k API je nutné ověřit
Tekion ARC, Spojené královstvíPotvrzeno: existuje smlouva o APIPotvrzeno: portál důvěry uvádí certifikace a šifrováníVyspělost v kontinentální Evropě Neposuzováno
Omnetic, evropský veřejný webVeřejně nepotvrzeno: nebyl přezkoumán technický katalogVeřejně nepotvrzeno: nebyla přezkoumána matice certifikací/umístění datVyžádejte si důkazy v nabídce; nevyvozujte neexistenci
bee2link OpenFlex, EvropaVeřejně nepotvrzeno: nebyl přezkoumán obecný katalogVeřejně nepotvrzenoNutné prověření konkrétního produktu

Veřejný stav je orientační nástroj. Důkazy v nákupním procesu jej mohou změnit. Dodavatel by měl dostat možnost opravit faktické chyby a poskytnout aktuální důvěrné podklady v rámci odpovídajícího procesu.

7. Dokončete implementací, referencemi a smlouvou

Referenční hovory mají odpovídat zemi, velikosti dealera, složitosti vztahů s výrobci a rozsahu. Ptejte se, co se po podpisu smlouvy změnilo, co vyžadovalo obcházení omezení, která data selhala, jak dlouho trvalo osvojení, jak se řešily incidenty a co by referenční zákazník udělal jinak. Neptejte se pouze, zda se uživatelům produkt líbí.

Zakotvěte akceptační kritéria ve smlouvě. Zahrňte úplnost a odsouhlasení dat, kritické pracovní postupy, integrace, výkon, zabezpečení, školení, přechod a podporu. Oceňte migrační iterace, prostředí, využití API, zprávy, úložiště, práci na reportech, cestování, indexaci a změnové požadavky. Definujte úrovně služeb, eskalaci, export při odchodu, podporu přechodu, mazání a zachování přístupu k zákonem vyžadovaným záznamům.

8. Kam zapadá Omnetic

Omnetic by měl postoupit do užšího výběru tam, kde RFP oceňuje sdílený kontext zákazníka a vozidla, CRM pro prodej a poprodejní služby, hloubku životního cyklu ojetých vozů, cenové a skladové akce a strukturovanou mobilní prohlídku. Jeho obhajitelným odlišením je návaznost od poznatku či důkazu k provozní akci s přidělenou odpovědností.

Férová nabídka Omnetic musí i tak prokázat každé vyřazovací kritérium pro uvedené země, výrobce a moduly. Veřejná tvrzení o rozsahu, certifikacích či počtu nativních modulů potřebují aktuální definice. Důkazy o zabezpečení, architektuře, API, SLA a migraci se mají hodnotit stejným měřítkem jako u každého dodavatele.

Omezení

Váhy jsou ilustrativní a nesmějí se přebírat bez zohlednění priorit dealera. Veřejné srovnání je výběrové a nehodnotí kvalitu implementace. Veřejně nepotvrzeno nikdy neznamená, že něco chybí. Právní, bezpečnostní, daňové a účetní požadavky vyžadují odborné ověření.

Časté dotazy