Modele wyceny oprogramowania obronnego: FFPIF, T&M, cost-plus i SaaS w kontraktach rządowych

Sprzedaż oprogramowania ministerstwu obrony nie przypomina sprzedaży oprogramowania przedsiębiorstwu komercyjnemu. Nabywcy komercyjni podpisują subskrypcję, aktywują wersję próbną i podejmują decyzję w ciągu kwartału. Nabywcy rządowi działają w ramach Federal Acquisition Regulation (FAR), Defense Federal Acquisition Regulation Supplement (DFARS) oraz zestawu zasad wyceny, które określają nie tylko, ile dostawca otrzyma zapłaty, ale czy kontrakt jest w ogóle zgodny z prawem. Model wyceny -- typ kontraktu -- nie jest preferencją rozliczeniową; to instrument prawny, który rozkłada ryzyko kosztowe między rząd a wykonawcę, uruchamia obowiązki audytowe i kształtuje to, do czego dostawca jest motywowany. Firma programistyczna, która podchodzi do zamówień obronnych z komercyjnym cennikiem i bez zrozumienia FAR Part 16, albo przegra z konkurentami, którzy je rozumieją, albo wygra na warunkach, które staną się finansowo szkodliwe w trakcie realizacji. Ten artykuł omawia główne struktury wyceny stosowane dzisiaj dla oprogramowania obronnego, gdzie każdy typ jest odpowiedni oraz jak nowoczesne modele subskrypcyjne SaaS wpisują się w ramy napisane przed powstaniem przetwarzania w chmurze. Czytelnicy budujący strategię kontraktową powinni także zapoznać się z pełnym cyklem życia zamówień obronnych od RFP do podpisanego kontraktu, aby uzyskać kontekst tego, jak typ wyceny jest negocjowany podczas selekcji źródła.

Dlaczego komercyjne modele wyceny zawodzą w kontraktowaniu obronnym

Komercyjny dostawca oprogramowania zazwyczaj oferuje menu: licencję za stanowisko, wycenę API opartą na zużyciu lub stałą opłatę dla przedsiębiorstwa. Cena jest opublikowana, nabywca akceptuje warunki, a kontrakt jest umową subskrypcyjną regulowaną standardowymi warunkami świadczenia usługi dostawcy. Nabywcy rządowi nie mogą działać w ten sposób. Rząd jest związany Truth in Negotiations Act (TINA, obecnie skodyfikowanym w 10 U.S.C. 3702 i 41 U.S.C. 3503), który wymaga, aby wykonawcy powyżej uproszczonego progu zamówień poświadczyli, że proponowane ceny opierają się na aktualnych, dokładnych i kompletnych danych kosztowych lub cenowych, gdy nie istnieje odpowiednia konkurencja cenowa. Oznacza to, że dostawca sprzedający agencji obronnej zdolność programistyczną z jednego źródła musi otworzyć swoją strukturę kosztów -- stawki pracy, narzuty, zysk -- na kontrolę rządową, a nie tylko podać cenę.

Poza przejrzystością, rządowy proces budżetowy tworzy ograniczenia, które nie mają komercyjnego odpowiednika. Przydziały budżetowe na obronę są roczne. Kontrakt finansowany z przydziału na badania, rozwój, testy i ewaluację (Research, Development, Test and Evaluation, RDT&E) z jednego roku obrachunkowego nie może być opłacany ze środków na operacje i utrzymanie (Operations and Maintenance, O&M). Oprogramowanie, które zaczyna się jako wysiłek rozwojowy (finansowany z RDT&E), przechodzi w wysiłek utrzymaniowy (finansowany z O&M) w konkretnym kamieniu milowym programu, a struktura wyceny kontraktu często musi się zmienić w tym samym czasie. Stała roczna opłata SaaS nie odwzorowuje naturalnie tych typów środków, dlatego rządowi urzędnicy kontraktowi często przekształcają komercyjną wycenę dostawcy w numery pozycji kontraktowych (contract line item numbers, CLINs) dopasowane do kategorii przydziałów. Zrozumienie tego ograniczenia jest warunkiem wstępnym ustrukturyzowania jakiejkolwiek propozycji wyceny oprogramowania obronnego, która przetrwa fazę negocjacji kontraktu.

Trzecią różnicą strukturalną jest prawo konkurencji. Competition in Contracting Act (CICA) wymaga, aby rząd uzyskał pełną i otwartą konkurencję, chyba że udokumentowane jest konkretne uzasadnienie udzielenia zamówienia z jednego źródła. Większość powtarzalnych subskrypcji oprogramowania jest poddawana ponownej konkurencji lub umieszczana w istniejących instrumentach kontraktowych -- kontraktach IDIQ, harmonogramach GSA lub OTA -- zamiast być udzielana jako samodzielne umowy z jednego źródła. Każdy instrument ma własne zasady wyceny, a model wyceny dostawcy musi być zgodny z tym, co zostało wcześniej wynegocjowane w instrumencie bazowym, a nie z komercyjnym cennikiem dostawcy.

Firm Fixed Price i FFPIF: kiedy stała cena sprawdza się dla oprogramowania

Firm Fixed Price (FFP) to preferowany przez rząd typ kontraktu. FAR 16.202 stanowi, że FFP należy stosować, gdy ryzyko kontraktowe jest minimalne lub gdy wykonawca może rozsądnie oszacować koszt. Wykonawca otrzymuje uzgodnioną cenę niezależnie od rzeczywiście poniesionych kosztów. Jeśli wykonawca dostarczy taniej, zachowuje marżę. Jeśli przekroczy budżet, pokrywa stratę. Dla dobrze zdefiniowanych prac programistycznych o stabilnych wymaganiach -- konkretnego modułu integracji danych, określonego zestawu komponentów UI lub migracji systemu dziedziczonego na nową platformę -- FFP jest odpowiedni i znany z rynku komercyjnego. Wyzwaniem jest to, że wymagania oprogramowania rzadko są wystarczająco stabilne, aby prawdziwy FFP był uczciwy dla obu stron.

Firm Fixed Price Incentive Fee (FFPIF), regulowany przez FAR 16.403, dodaje mechanizm podziału. Strony negocjują cztery parametry: koszt docelowy, zysk docelowy (opłatę), cenę maksymalną oraz współczynnik podziału. Jeśli koszt końcowy jest poniżej docelowego, wykonawca zarabia więcej niż zysk docelowy proporcjonalnie do oszczędności, do maksymalnego pułapu opłaty. Jeśli koszt końcowy jest powyżej docelowego, ale poniżej ceny maksymalnej, wykonawca zarabia mniej niż zysk docelowy. Powyżej ceny maksymalnej wykonawca pokrywa 100% przekroczeń -- cena maksymalna staje się faktycznym pułapem FFP. Ta struktura dobrze nadaje się do zaangażowań rozwojowych w oprogramowaniu, w których ogólny zakres jest jasny (konkretna zdolność, określona granica integracji), ale szacowanie nakładu pracy obarczone jest umiarkowaną niepewnością. Rząd zyskuje zachętę do redukcji kosztów bez wymogu pełnej przejrzystości kosztów w trakcie realizacji; wykonawca zachowuje potencjał zysku, jeśli jego zespół inżynierski jest efektywny. Dla firm poruszających się w obszarze wyceny obronnej i obowiązków zgodności FFPIF jest często pragmatycznym środkiem między czystym ryzykiem stałej ceny a obciążeniem administracyjnym rachunkowości cost-reimbursement.

Krytyczny aspekt praktyczny: FFP i FFPIF wymagają realistycznej podstawy szacowania (basis of estimate, BOE) na etapie ofertowym. Zespół programistyczny, który nie ma historii śledzenia godzin pracy wobec produktów, będzie miał trudności z opracowaniem wiarygodnego BOE. Rządowi analitycy kosztów porównają proponowane stawki pracy i godziny z danymi historycznymi w swoich bazach i zakwestionują wartości odstające. Dostawcy nowi w kontraktowaniu rządowym często zaniżają oferty FFP, aby wygrać, a następnie odkrywają, że stała cena nie pokrywa rzeczywistego kosztu spełnienia specyficznych dla rządu wymagań bezpieczeństwa, dokumentacji i testowania, które były domyślne w opisie prac wykonawczych, ale nie zostały wycenione w ofercie.

Time and Materials: właściwe zastosowanie i ekspozycja audytowa

Kontraktowanie w trybie Time and Materials (T&M), regulowane przez FAR 16.601, to typ kontraktu najbliższy temu, jak zazwyczaj wycenia się komercyjne usługi tworzenia oprogramowania: wykonawca rozlicza stawki godzinowe za kategorie pracy plus koszt materiałów bez narzutu (lub z wynegocjowaną stawką obsługi materiałów). Rząd płaci za faktycznie przepracowane godziny, do nieprzekraczalnej ceny maksymalnej. T&M jest odpowiedni, gdy ani rząd, ani wykonawca nie mogą zdefiniować zakresu prac z wystarczającą precyzją w momencie udzielenia zamówienia, aby wycenić go jako wysiłek o stałej cenie. Utrzymanie systemu dziedziczonego, gdzie liczba usterek jest z natury nieprzewidywalna, to podręcznikowy przypadek użycia T&M. Fazy szybkiego prototypowania w ramach umowy badawczej, gdzie wymagania ewoluują codziennie, to kolejny. Awaryjne wsparcie programistyczne po incydencie cyberbezpieczeństwa, gdy rząd potrzebuje godzin wykonawcy natychmiast i nie może czekać na szczegółowy SOW, to trzeci.

Ekspozycja audytowa kontraktów T&M jest znacząca. FAR 16.601(c) wymaga, aby urzędnik kontraktowy stwierdził, że żaden inny typ nie jest odpowiedni, zanim autoryzuje T&M, a urzędnicy kontraktowi są kontrolowani pod kątem tego ustalenia. Ponieważ T&M nie zapewnia zachęty do redukcji kosztów -- zysk wykonawcy z pracy jest wbudowany w stałą stawkę godzinową i nie zmienia się wraz z efektywnością -- Defense Contract Audit Agency (DCAA) ściśle bada rozliczenia T&M. Audytorzy sprawdzają, czy rozliczone godziny pracy są poparte bieżącymi zapisami ewidencji czasu pracy, czy rozliczona kategoria pracy odpowiada kategorii pracy faktycznej osoby, która wykonała pracę, oraz czy jakiekolwiek rozliczone godziny dotyczyły prac poza określeniem celów kontraktu. Wykonawcy bez systemu ewidencji czasu pracy zgodnego z DCAA napotkają spory rozliczeniowe, wstrzymania i potencjalnie zarzuty oszukańczego rozliczania na mocy False Claims Act. Dla każdej firmy oprogramowania obronnego planującej korzystanie z instrumentów T&M ustanowienie zgodnego systemu ewidencji czasu pracy przed pierwszym zleceniem zadania jest warunkiem wstępnym, a nie kwestią drugorzędną.

Nabywcy rządowi coraz częściej przesuwają wykonawców z T&M w stronę FFP lub struktur hybrydowych w miarę dojrzewania programów. Oczekuje się, że zlecenie zadania, które zaczyna się jako T&M na etapie wstępnego rozpoznania, przejdzie w zlecenie dostaw o stałej cenie dla fazy produkcyjnej. Wykonawcy, którzy opierają się temu przejściu -- preferując przewidywalność przychodu z rozliczeń godzinowych -- sygnalizują rządowi, że nie potrafią oszacować własnych kosztów, co jest niekorzystne konkurencyjnie w kolejnych zamówieniach. Najbardziej obronną strategią T&M jest wykorzystanie fazy T&M do zbudowania historii roboczogodzin, która następnie wspiera wiarygodne BOE dla FFP w późniejszych pracach.

Struktury Cost Plus: CPFF, CPAF, CPIF i ich implikacje dla oprogramowania

Kontrakty Cost Plus refundują wykonawcy wszystkie dopuszczalne, alokowalne i rozsądne poniesione koszty plus opłatę. Stosuje się je, gdy praca jest zbyt niepewna lub zbyt ryzykowna technicznie, aby wykonawca ponosił ryzyko stałej ceny, oraz gdy rząd potrzebuje, aby pracę wykonał konkretny wykonawca mimo niepewności kosztowej. Dla oprogramowania obronnego istotne są trzy warianty: Cost Plus Fixed Fee (CPFF), Cost Plus Award Fee (CPAF) i Cost Plus Incentive Fee (CPIF).

CPFF (FAR 16.306) płaci opłatę, która jest ustalona w momencie udzielenia zamówienia jako procent szacowanego kosztu, zazwyczaj 6--10% dla prac rozwojowych. Opłata nie zmienia się na podstawie rzeczywistej wydajności kosztowej. CPFF to najczęstszy typ cost-reimbursement dla wczesnych badań i rozwoju oprogramowania obronnego: rząd otrzymuje wykonaną pracę, wykonawca odzyskuje koszty i zarabia skromną opłatę, a żadna ze stron nie korzysta na zawyżonych kosztach. Wadą jest to, że CPFF nie zapewnia zachęty do efektywności kosztowej -- wykonawca zarabia tę samą opłatę, niezależnie od tego, czy projekt przebiega po szacowanym koszcie, czy 40% powyżej. Rządowi kierownicy programów na kontraktach CPFF muszą zarządzać kosztem poprzez aktywny nadzór i zarządzanie wartością wypracowaną, a nie poprzez zachęty finansowe w samym kontrakcie. Zrozumienie pełnego kosztu cyklu życia CPFF i utrzymania zostało dogłębnie omówione w analizie całkowitego kosztu posiadania oprogramowania obronnego.

CPAF (FAR 16.305) dodaje pulę opłaty nagrodowej na szczycie opłaty bazowej i refundowanych kosztów. Opłata nagrodowa jest oceniana okresowo -- zazwyczaj co sześć miesięcy -- przez rządowego urzędnika ds. ustalania opłaty nagrodowej (Award Fee Determining Official, AFDO), który ocenia wykonawcę według kryteriów zdefiniowanych w planie opłaty nagrodowej: wydajność techniczna, dotrzymywanie harmonogramu, efektywność zarządcza i podobne miary jakościowe. Ustalenie AFDO nie podlega klauzuli sporowej, co czyni CPAF wyjątkowo skutecznym dla rządu narzędziem zarządzania wydajnością. Dla programów rozwoju oprogramowania, w których jakość realizacji ma takie samo znaczenie jak koszt -- dostarczanie bezpiecznego, dobrze udokumentowanego, interoperacyjnego oprogramowania -- CPAF dopasowuje zachęty wykonawcy do pozakosztowych priorytetów rządu w sposób, w jaki czysty CPFF nie może. Ryzykiem dla wykonawcy jest to, że ocena AFDO może być subiektywna, a wykonawca, który uważa, że wykonał pracę dobrze, może otrzymać słaby wynik opłaty z ograniczonymi możliwościami odwołania.

Hybrydowe struktury kontraktowe dla fazowanego rozwoju oprogramowania

Rzeczywiste programy oprogramowania obronnego rzadko mieszczą się czysto w pojedynczym typie kontraktu przez cały swój cykl życia. Typowa trajektoria przechodzi przez trzy fazy: fazę projektowania i prototypu o wysokiej niepewności, lepiej zdefiniowaną fazę rozwoju i integracji oraz dojrzałą fazę utrzymania i operacji. Każda faza ma inny profil ryzyka i każda uzasadnia inną strukturę wyceny. Kontrakty hybrydowe -- kontrakty z wieloma CLIN wycenianymi według różnych typów kontraktu -- pozwalają rządowi i wykonawcy zastosować najbardziej odpowiedni typ wyceny do każdej fazy bez wymogu pełnej ponownej konkurencji przy każdym przejściu.

Częstym wzorcem jest fazowana hybryda z CLIN typu CPFF dla początkowej fazy projektowania (powiedzmy sześć miesięcy), po której następuje CLIN typu FFPIF dla podstawowej dostawy rozwojowej (dwanaście miesięcy) oraz CLIN typu T&M z nieprzekraczalną ceną maksymalną dla pierwszego roku utrzymania serwisowego. Każdy CLIN ma własny okres wykonania, zaangażowane środki i kryteria akceptacji. Rząd zachowuje opcję wynegocjowania warunków FFPIF dla CLIN rozwojowego po przeglądzie wyniku fazy projektowania, zamiast musieć wycenić prace rozwojowe z pełną precyzją w momencie pierwotnego udzielenia zamówienia. Bywa to czasem ustrukturyzowane jako kontrakt z opcjami, gdzie okres bazowy obejmuje fazę projektowania CPFF, a okresy opcjonalne obejmują kolejne dostawy FFP lub FFPIF, każda możliwa do uruchomienia po przeglądzie wyniku poprzedzającej fazy przez rząd.

Programy Software Acquisition Pathway (SWP) w ramach DoDI 5000.87 formalizują to podejście fazowane w ramach struktury zakupowej DoD. Programy SWP są zachęcane do stosowania iteracyjnych cykli dostaw ze zleceniami dostaw o stałej cenie w oparciu o bazowy kontrakt IDIQ. IDIQ ustanawia kwalifikacje, stawki i warunki wykonawcy; poszczególne zlecenia dostaw definiują konkretne przyrosty oprogramowania z produktami o stałej cenie. Pozwala to programowi absorbować zmiany wymagań między zleceniami dostaw bez modyfikacji kontraktu, przy zachowaniu dyscypliny kosztowej stałej wyceny w obrębie każdego przyrostu. Dla dostawców oprogramowania obronnego zdobycie pozycji w IDIQ powiązanym z SWP jest często bardziej wartościowe komercyjnie niż wygranie jakiegokolwiek pojedynczego zlecenia dostaw, ponieważ zapewnia wieloletni kanał powtarzalnych zleceń zadań bez ponownej konkurencji na poziomie zlecenia.

Wycena subskrypcyjna SaaS w kontraktach rządowych: ścieżki IDIQ, BPA i OTA

Aparat obronny powoli buduje mechanizmy umożliwiające komercyjną wycenę SaaS, ale dopasowanie wciąż jest niedoskonałe. Fundamentalne napięcie polega na tym, że dostawcy SaaS wyceniają na podstawie zużycia (stanowiska, wywołania API, wolumen danych) w ciągłym modelu subskrypcyjnym, podczas gdy struktura budżetowa rządu jest roczna i specyficzna dla przydziałów. 36-miesięczna korporacyjna umowa SaaS jest prawnie problematyczna, jeśli obejmuje wiele lat obrachunkowych bez ustrukturyzowania jako kontrakt wieloletni w ramach FAR 17.1 lub IDIQ z rocznymi zleceniami dostaw. Każde obronne zaangażowanie SaaS musi ostatecznie zostać pogodzone z tym ograniczeniem.

W praktyce trzy ścieżki instrumentów umożliwiają wycenę subskrypcyjną SaaS. Pierwsza to kontrakt IDIQ z rocznymi lub kwartalnymi zleceniami dostaw. Bazowy IDIQ wcześniej negocjuje ceny jednostkowe (za stanowisko miesięcznie, za wywołanie API, za GB przetworzonych danych), warunki bezpieczeństwa i prawa do danych. Roczne zlecenia dostaw finansują subskrypcję na każdy rok obrachunkowy z odpowiedniego przydziału. Ta struktura dobrze działa dla komercyjnie dostępnego oprogramowania ze statusem FedRAMP Authorized, ponieważ autoryzacja FedRAMP dostarcza dokumentacji bezpieczeństwa, której rząd potrzebuje, aby szybko realizować zlecenia dostaw bez pełnej oceny bezpieczeństwa systemu dla każdego zlecenia. Druga ścieżka to umowa ramowa (Blanket Purchase Agreement, BPA) w oparciu o GSA Multiple Award Schedule (MAS). Harmonogram MAS 518210C obejmuje profesjonalne usługi IT i wiele platform SaaS; BPA w oparciu o kontrakt MAS dostawcy wcześniej negocjuje specyficzny dla rządu rabat i warunki, przy czym poszczególne wezwania BPA finansują każdy okres subskrypcji. Trzecia ścieżka to umowa Other Transaction Agreement (OTA) w ramach 10 U.S.C. 4022. OTA nie wymagają pełnej zgodności z FAR, co oznacza, że agencja obronna może zaangażować komercyjnego dostawcę SaaS na standardowych komercyjnych warunkach cenowych dostawcy, pod warunkiem że OTA zawiera obowiązkowe postanowienia rządowe dotyczące praw do danych, bezpieczeństwa i dostępu audytowego.

Ścieżka OTA jest coraz częściej stosowana dla zaangażowań pilotażowych z komercyjnymi platformami AI i oprogramowania, które nie podjęły jeszcze autoryzacji FedRAMP. Ograniczeniem jest to, że OTA nie mogą być stosowane do produkcyjnego wdrożenia systemu, który będzie obsługiwał informacje niejawne, i są generalnie ograniczone do działań badawczych, rozwojowych i prototypowych. Program, który zaczyna się w ramach OTA, musi przejść do instrumentu kontraktowego opartego na FAR dla pełnego wdrożenia operacyjnego -- a w tym punkcie przejścia komercyjne warunki wyceny SaaS muszą zostać pogodzone z zasadami kosztowymi FAR. Dostawcy, którzy nie przemyśleli tego przejścia, często odkrywają, że ich komercyjne warunki OTA są niezgodne z zasadami dopuszczalności kosztów FAR 31.201, co wymaga znaczącego przekształcenia kontraktu przed wykonaniem przejścia.

Marże zysku, pośrednie stawki kosztowe i co napędza rządowe oceny cenowe

Rządowa ocena cenowa patrzy na więcej niż cenę końcową. Dla zamówień negocjowanych (w przeciwieństwie do ofert zapieczętowanych) rząd ocenia, czy proponowana cena jest uczciwa i rozsądna, analizując elementy kosztowe: pracę bezpośrednią, stawki pośrednie, inne koszty bezpośrednie i zysk. Zysk nie jest ograniczony w kontraktowaniu komercyjnym, ale rządowa polityka zysku w ramach FAR 15.404-4 ustanawia ważone wytyczne, które ograniczają zysk do zakresu zazwyczaj między 5% a 15% kosztu dla większości prac w oprogramowaniu obronnym, przy czym konkretny pułap różni się w zależności od typu kontraktu i rozkładu ryzyka. Dostawca oprogramowania proponujący 30% zysku na kontrakcie cost-reimbursement nie wygra selekcji źródła; dostawca proponujący 8% na wysoce konkurencyjnym kontrakcie FFP może zostawić pieniądze na stole. Zrozumienie, gdzie leżą oczekiwania zysku oceniających dla danego typu zamówienia, jest częścią konkurencyjnej strategii cenowej.

Pośrednie stawki kosztowe to mnożnik, który przelicza dolary pracy bezpośredniej na w pełni obciążony koszt. Inżynier oprogramowania rozliczany po 85 USD/godz. bezpośrednio może kosztować rząd 170 USD/godz. w pełni obciążony, jeśli łączne pośrednie stawki świadczeń dodatkowych, narzutów i G&A wykonawcy wynoszą łącznie 100%. Duzi główni wykonawcy obronni z wysokimi kosztami obiektów, rozbudowanymi organizacjami zgodności i dużymi strukturami narzutów korporacyjnych często mają łączne stawki pośrednie na poziomie 150--250% pracy bezpośredniej. Małe firmy programistyczne z oszczędnymi strukturami narzutów mogą mieć stawki 60--90%. Ta różnica strukturalna oznacza, że mała, zwinna firma programistyczna może często wycenić poniżej dużego głównego wykonawcy przy równoważnej pracy technicznej nawet przy równoważnych marżach zysku, ponieważ baza pracy bezpośredniej jest obciążona ułamkiem stawki głównego wykonawcy. Jasne komunikowanie tego w propozycji cenowej -- pokazanie struktury stawek pośrednich, dostarczenie narracji o tym, jak niskie stawki odzwierciedlają oszczędne narzuty, a nie niedoszacowanie kosztów -- jest istotną częścią konkurencyjnego pozycjonowania mniejszych dostawców oprogramowania obronnego.

Kryteria oceny cenowej różnią się także w zależności od typu zamówienia. Zamówienia Best Value Tradeoff (BVT) pozwalają rządowi zapłacić premię cenową za lepsze oceny techniczne lub dotychczasowej wydajności. Zamówienia Lowest Price Technically Acceptable (LPTA) udzielane są oferentowi o najniższej cenie, który jest technicznie akceptowalny, bez premii za lepsze propozycje techniczne. Zamówienia na oprogramowanie obronne odeszły od LPTA w ostatnich latach po uznaniu, że LPTA prowadzi w stronę najtańszych deweloperów, a nie rozwiązań o najwyższych zdolnościach. Polityka DoD od 2017 r. (DFARS 215.101-2-70) ogranicza stosowanie LPTA dla prac rozwojowych. Dla dostawców oprogramowania obronnego ta zmiana oznacza, że inwestowanie w różnicowanie techniczne -- udokumentowaną metodologię, komponenty wielokrotnego użytku, wykazaną dotychczasową wydajność w podobnych programach -- może przynieść premię cenową w selekcji źródła, zamiast po prostu podnosić ocenianą cenę oferty względem konkurencji.