Galvenie secinājumi
- Vērtējiet nosaukto produktu, ieviešanu un valsti, nevis piegādātāja līmeņa mārketingu.
- Pirms svērtā vērtējuma izmantojiet atbilstības vārtus.
- Pieprasiet piegādātājiem demonstrēt gan parastas, gan izņēmuma darba plūsmas.
- Pieprasiet pierādījumus API, drošībai, lokalizācijai, migrācijai un rezultātiem.
- Nošķiriet publisko pierādījumu statusu no galīgās iepirkuma pārbaudes.
1. Izveidojiet lēmumu pieņemšanas komandu un tvērumu
DMS izvēle ietekmē pārdošanu, lietotos transportlīdzekļus, darbnīcu, detaļas, finanses, IT, privātumu un grupas pārskatus. Izveidojiet lēmumu pieņemšanas komandu ar atbildīgiem darbības atbildīgajiem, nevis tikai pārstāvjiem. Norīkojiet vienu vadības atbalstītāju, produkta atbildīgo, datu vadītāju, integrācijas vadītāju, drošības/privātuma vadītāju, finanšu kontrolieri un izmaiņu vadītāju. Definējiet, kurš iesaka, kurš apstiprina un kurš var noraidīt obligātu prasību.
Dokumentējiet juridiskās vienības, filiāles, zīmolus, valstis, valodas, lietotājus, darījumu apjomus un kritiskos periodus. Nošķiriet pašreizējo tvērumu no ticama trīs gadu ceļveža. Prasība katram hipotētiskam nākotnes tirgum var izkropļot lēmumu, savukārt ticamas paplašināšanās ignorēšana var radīt vēl vienu nomaiņu.
2. Pārvērtiet vajadzības pārbaudāmās prasībās
Prasībā jānorāda dalībnieks, ierosinātājs, dati, darbība, rezultāts un pieņemšana. Aizstājiet „spēcīgu CRM” ar „tīmekļa, OEM vai telefona pieprasījums tiek sasaistīts vai izveidots, piekrišana tiek ierakstīta, potenciālais klients tiek novirzīts pēc zīmola un ģeogrāfijas, ir redzams atbildīgais un SLA, saziņa tiek fiksēta, un pabeigts darījums atgriež statusu bez dublēta klienta”.
Izveidojiet valstu un OEM matricu. Katrai šūnai ierakstiet grāmatvedības, nodokļu, rēķinu, maksājumu, reģistrācijas, garantijas, detaļu, kampaņu, pārskatu, identitātes un valodas prasības. Eiropas konteksts būtiski atšķiras. Eurostat vieglo automobiļu dati rāda lielas atšķirības autoparka vecumā un piedziņas veidā pa valstīm, savukārt ES noteikumi par privātumu, datu piekļuvi un e-rēķiniem joprojām prasa vietēju ieviešanu.[1]
3. Izmantojiet vārtus, svērtus kritērijus un pierādījumu līmeņus
Atbilstības vārti novērš situāciju, kad augsts kopējais vērtējums slēpj kritisku nepilnību. Piemēri ietver ražošanas atbalstu nepieciešamai valstij, nosauktu OEM saskarni, likumā noteiktu grāmatvedības izvadi, datu atrašanās vietas robežu vai migrācijas termiņu. Neizpildītus vārtus var atrisināt tikai ar apstiprinātu novēršanas plānu ar datumu, atbildīgo, izmaksām un līgumisku saistību.
| Dimensija | Ilustratīvs svars | Nepieciešamie pierādījumi |
|---|---|---|
| Visaptverošas funkcionālas darba plūsmas | 25% | Skriptēta demonstrācija piedāvātajā produktā |
| Atbilstība valstij un OEM | 15% | Nosauktas ražošanas atsauces un specifikācijas |
| Dati, API un ekosistēma | 15% | Katalogs, testa vide, ierobežojumi, īpašumtiesības, izmaiņu politika |
| Migrācija un ieviešana | 15% | Plāns, resursi, pieņemšana, atgriešanās, atsauces |
| Drošība, privātums un noturība | 10% | Pārskati, arhitektūra, DPA, avārijas atgūšanas tests un kontroles |
| Lietotāja pieredze un pieņemšana | 10% | Uz lomu balstīta uzdevumu testēšana un apmācības plāns |
| Piecu gadu TCO un līgums | 10% | Cenu modelis, indeksācija, izmaiņas, atbalsts un izstāšanās |
4. Skriptējiet demonstrācijas, nevis pieņemiet produkta apskates
Nodrošiniet reprezentatīvus, bet drošus datus un fiksētus skriptus. Lūdziet piegādātājam parādīt potenciālā klienta ceļu caur piedāvājumu, ieskaitāmo auto un pasūtījumu; lietota auto ceļu caur novērtēšanu, apskati, sagatavošanu, medijiem, publicēšanu, cenu noteikšanu un pārdošanu; remonta pasūtījuma ceļu caur rezervāciju, tehniķa darbu, detaļām, papildu apstiprinājumu un rēķinu; kā arī perioda slēgšanas vai vadības pārskata ceļu.
Pievienojiet izņēmumus: dublēts klients, nepareizs VIN, atcelts darījums, nepieejama detaļa, nedarbojas saskarne, apskate bezsaistē, stornēts rēķins un lietotājs, kas pamet procesu vidū. Skaitiet sistēmas, klikšķus, atkārtoti ievadītas vērtības, manuālus eksportus un neredzamas fona atkarības. Ierakstiet demonstrēto versiju un tirgu.
Standarti var uzlabot savietojamību, taču neaizstāj demonstrāciju. STAR publicē autobūves potenciālo klientu, darījumu un mazumtirdzniecības piegādes API un mazumtirdzniecības domēna modeli.[2] Jautājiet, vai un kā piegādātājs ievieš attiecīgos standartus, tad testējiet faktisko piedāvāto saskarni.
5. Validējiet apgalvojumus par mākoni, API, drošību un datiem
Mākonim nosakiet, vai tas ir SaaS, dedicēta hostinga vai mantotas arhitektūras hostings. Pieprasiet pieejamības definīcijas, incidentu vēsturi, RPO, RTO, dublējuma un atgūšanas testa pierādījumus, uzturēšanas noteikumus un kapacitātes modeli. API pieprasiet objektus, laukus, notikumus, rakstīšanas darbības, autentifikāciju, testa vidi, pieprasījumu ierobežojumus, pārsniegumus, versiju kontroli, uzraudzību un datu eksporta tiesības.
Privātumam un drošībai novērtējiet lomas, mazāko privilēģiju principu, daudzfaktoru autentifikāciju, žurnalēšanu, šifrēšanu, ievainojamību pārvaldību, apakšapstrādātājus, pārsūtīšanas mehānismu, saglabāšanu, dzēšanu, incidentu paziņošanu un neatkarīgu apliecinājumu. BDAR pieprasa riskam atbilstošas kontroles un privātumu jau projektēšanas stadijā, taču sertifikācija vai mākoņa pakalpojumu sniedzējs automātiski nepadara tirgotāju atbilstošu.[3] ENISA vadlīnijas var strukturēt pierādījumu pieprasījumus, lai gan NIS2 tvērums jāvērtē atsevišķi.[4]
6. Piemērojiet godīgus publisko pierādījumu statusus
| Nosauktais produkts/tirgus | Atvērtības/API pierādījumi | Drošības pierādījumi | Interpretācija |
|---|---|---|---|
| Nextlane Platform, Eiropa | Apstiprināts: oficiāla atvērtā API pozīcija | Apstiprināts: AWS transformācija un deklarēts ES datu atrašanās vietas mērķis | Precīzs DMS un migrācijas statuss jāpārbauda piedāvājumā |
| Pinewood platforma, globāla/Eiropas | Apstiprināts: DMS API apgalvojums un nosaukta integrācija | Apstiprināts: publiski ISO apgalvojumi | Tvērums, pārskati un komerciāla API piekļuve jāpārbauda |
| Tekion ARC, Apvienotā Karaliste | Apstiprināts: pastāv API līgums | Apstiprināts: uzticamības portālā uzskaitīti sertifikāti un šifrēšana | Kontinentālās Eiropas brieduma pakāpe Nav novērtēts |
| Omnetic, Eiropas publiskā vietne | Publiski neapstiprināts: nav pārskatīta tehniskā kataloga | Publiski neapstiprināts: nav pārskatītas sertifikācijas/atrašanās vietas matricas | Pieprasiet pierādījumus piedāvājumā; nesecinat neesamību |
| bee2link OpenFlex, Eiropa | Publiski neapstiprināts: nav pārskatīta vispārīga kataloga | Publiski neapstiprināts | Nepieciešama produktam specifiska pienācīga pārbaude |
Publiskais statuss ir orientējošs rīks. Iepirkuma pierādījumi to var mainīt. Piegādātājs jāaicina labot faktu kļūdas un sniegt aktuālus konfidenciālus pierādījumus atbilstošā procesā.
7. Noslēdziet ar ieviešanu, atsaucēm un līgumu
Atsauces sarunām jāatbilst valstij, tirgotāja lielumam, OEM sarežģītībai un tvērumam. Jautājiet, kas mainījās pēc līguma noslēgšanas, kādi apiešanas risinājumi bija nepieciešami, kuri dati neizdevās, cik ilgi ilga pieņemšana, kā tika risināti incidenti un ko atsauce darītu citādi. Nejautājiet tikai to, vai lietotājiem produkts patīk.
Padariet pieņemšanas kritērijus līgumiskus. Aptveriet datu pilnīgumu un saskaņošanu, kritiskas darba plūsmas, integrācijas, veiktspēju, drošību, apmācību, pāreju un atbalstu. Nosakiet cenas migrācijas iterācijām, videm, API izmantošanai, ziņojumiem, glabāšanai, pārskatu izstrādei, ceļojumiem, indeksācijai un izmaiņu pieprasījumiem. Definējiet pakalpojuma līmeņus, eskalāciju, izstāšanās eksportu, pārejas atbalstu, dzēšanu un saglabātu piekļuvi likumā noteiktiem ierakstiem.
8. Kur iederas Omnetic
Omnetic būtu jāiekļauj sarakstā, kad RFP vērtē kopīgu klienta un transportlīdzekļa kontekstu, pārdošanas un popārdošanas CRM, lietota auto dzīves cikla dziļumu, cenu noteikšanas un krājuma darbības, kā arī strukturētu mobilo apskati. Tā pamatotā atšķirība ir nepārtrauktība no ieskata vai pierādījuma līdz piesaistītai darbības darbībai.
Godīgam Omnetic piedāvājumam joprojām jāpierāda katri vārti nosauktajām valstīm, OEM un moduļiem. Publiskiem apgalvojumiem, piemēram, mērogam, sertifikātiem un vietējo moduļu skaitam, nepieciešamas aktuālas definīcijas. Drošības, arhitektūras, API, SLA un migrācijas pierādījumi jāvērtē pēc tā paša standarta, kas tiek piemērots katram piegādātājam.
Ierobežojumi
Svari ir ilustratīvi, un tos nedrīkst kopēt bez tirgotāja prioritātēm. Publiskais salīdzinājums ir selektīvs un nevērtē ieviešanas kvalitāti. „Publiski neapstiprināts” nekad nenozīmē „neesošs”. Juridiskām, drošības, nodokļu un grāmatvedības prasībām nepieciešama speciālista validācija.