V prejšnjem prispevku o problemih pri uvajanju P2P rešitev, smo predstavili, kje vse se vam lahko zalomi na projektu.

Današnji prispevek predstavlja odgovor na problem »slabo pripravljen RFP«.

Prevečkrat smo prebrali takšen RFP, pri katerih se nam je dejansko zasmilila organizacija, ki ga je pripravila, ker vemo, da so bili odgovori na tak RFP lahko samo porazni. V veliki večini so ponudniki na tak RFP poslali konkretne ponudbe »tanjše kot papir«, poleg njih pa goro neuporabnega tržnega materiala. Ponudniki so na osnovi RFP prepoznali, da bodo potencialnega naročnika v prodajnem procesu morali krepko izobraziti, da bi se sploh lahko sporazumeli, kaj je predmet sodelovanja, projekta, ponudbe,.. A ker je izplen takšnega »izobraževanja« negotov, saj naročnika »šolajo« vsi ponudniki hkrati, je vseeno višji cilj zapreti posel (pod skoraj kakršnimi koli pogoji), kot korektno izobraziti naročnika. A to včasih tepe. Praviloma vedno bolj naročnika kot ponudnika. Sklenjen posel na osnovi slabega oz. nedorečenega RFP, je prej ali slej jedro spora v poslovnem odnosu med novima poslovnima partnerjema.

Bistvo RFP je, da ga enako razumeta tako ponudnik kot naročnik

Lahko bi rekli, da gre za neke vrste folkloro. Iz ne vem kakšnega razloga se večina potencialnih naročnikov P2P rešitev pri pripravi RFP izogibajo opredelitvi procesnega vidika P2P in se predvsem osredotočijo samo na funkcionalnosti, ki naj bi jih ponudnikova rešitev omogočala. Če povzamem zadnji stavek, naročniki opredelijo »kakšno funkcionalno lastnost naj vsebuje programska oprema« in pozabijo na dejstvo, »scenarij, ki ga morajo z rešitvijo pokriti«. Slednje pa je bistveno pomembnejši »input« ponudniku za oblikovanje in dimenzioniranje ustrezne rešitve ter posledično tudi za pripravo primerne in ustrezne ponudbe. Če ponudnik ne pozna natančnih pričakovanj naročnika, bo takoj pričel z intenzivnim lobiranjem za uveljavljanje svojega dobrega imena v očeh naročnika, pripravil pa bo zgolj okvirno ponudbo, ki bo dovolj odprta, da bo lahko izkazoval dodatna dela, ko izvedba naročila ne bo več rentabilna. Dodatna dela pa (če ni drugače dogovorjeno) pri večini naročnikov niso dolgoročno vzdržna. In že smo pri sporu.

Podaljševanje rokov izvedbe na projektu je bolj posledičnega značaja. Ali gre za to, da se ponudnik uči na vašem projektu (naročnik je slabo preveril ponudnikove kompetence) ali pa je zamuda »politične« narave, ker izvedba posla ne bi bila rentabilna.

Splošno velja, da je RFP dokument, na podlagi katerega je zgrajen pomemben del mostu med naročnikom in ponudnikom. Gre za temelj medsebojnega razumevanja, pa naj gre za P2P rešitve ali gradnjo avtocestnega odseka.

Naročnikove zahteve so ohlapne, ker je izvajalec že izbran ali zaradi neznanja (občutka samozadostnosti) naročnika

Če se osredotočimo samo na tisto slednje (poskušamo biti aktualni zgolj za bralce našega bloga), bi rad najprej malo pomiril morebitno napetost zaradi zgornje izjave in povedal, da je pomanjkanje znanja nekaj povsem običajnega, pričakovanega. Dejstvo je, da se zaposlenci naročnika prvič in po vsej verjetnosti edino krat v življenju srečujejo s projekti »dematerializacije« nabavnega procesa in likvidacije računov. Na nasprotnem bregu (karikirano) nanje prežijo »lisjaki«, ki so dnevno v tem poslu. Z več letnimi izkušnjami in preverjenimi poslovnimi metodami.

Za pomoč pri opredeljevanju projekta (RFP, kriteriji za izbor, nadzor projektov,..) nas danes najema malo organizacij. A vedno bolj običajno bo, da si bo naročnik pred samim izvedbenim projektom omislil pomoč neodvisnega svetovalca, ki ne ponuja informacijskih rešitev niti storitev implementacije rešitev. Ta isti svetovalec je obenem tudi najučinkovitejši nadzornik samega izvedbenega projekta. Vse dokler naročnik verjame v njegovo neodvisnost.

Nadaljevanje tega prispevka bo objavljeno v naslednjem tednu. Želite drugi del prispevka prebrati takoj?

Tilen.markus@frodx.com