Dlaczego wyceny wdrożeń e-commerce B2B tak bardzo się różnią? | Agile, analiza i Excel

W dzisiejszym odcinku porozmawiamy o wycenach. Wyobraź sobie sytuację, że masz kilka ofert z różnych agencji IT. Nazwa projektu jest taka sama, zakres teoretycznie powinien być też taki sam, a ceny 350, 680, milion 200. I teraz pytanie, kto ma rację? Kto policzył dobrze i jak to w ogóle porównać, skoro każda oferta wygląda jak z innej beczki. W tym tygodniu opowiem o tym, dlaczego wyceny B2B, wyceny wdrożeń B2B tak bardzo się różnią, jak działa proces wyceny z perspektywy IT oraz z perspektywy biznesu, jak ja jako konsultant radzę sobie z tym, żeby mieć miarodajne i porównywalne wyceny i dlaczego jeden plik Excel, który tak bardzo lubicie, potrafi więcej niż tygodnie negocjacji.

 

Dlaczego wyceny się różnią?

 

Jeśli kiedykolwiek podchodziliście do wyceny projektu IT, projektu oprogramowania, to dobrze wiecie, że te wyceny bardzo się między sobą różnią. I teraz powstaje pytanie, dlaczego właśnie te wyceny się aż tak mocno czasami różnią, w czym tkwi problem. Powodów jest kilka i trzeba powiedzieć, że są one bardzo przyziemne i proste, jeżeli już wiemy, jak to działa. A dziś o tych kwestiach troszeczkę więcej.

 

 

Pierwsza rzecz, która wpływa na to, że wyceny się różnią, to jest różnica interpretacji wymagań. Klient mówi: „Chcemy platformę B2B”. Okej, ale IT zastanawia się, co to oznacza. Dla każdego z was platforma B2B to może być coś zupełnie innego. I każda agencja, jeżeli nie ma dobrze spisanych, precyzyjnie, szczegółowo spisanych wymagań, będzie sobie coś zakładać, coś dopowiadać, będzie uzupełniać luki, które powstały w tym, co jej dostarczyliście. Im więcej takich luk, im więcej takich dopowiedzeń i niejasności, tym większy bufor budżetowy, jaki agencja przyjmie, żeby się zabezpieczyć przed tym, że ta wycena będzie po prostu nietrafiona i żeby później nie musieli dokładać do tego projektu z własnej kieszeni. Co jest efektem tego? Efektem tego, że nie macie tych precyzyjnych wymagań i każda agencja sobie coś dopowiada, czyli w jakiś sposób sobie interpretuje te wasze wymagania, tudzież uzupełnia sobie po swojemu luki, które powstały. Prowadzi to do tego, że tak naprawdę macie trzy różne założenia, więc też trzy różne wyceny, bo każdy wycenia de facto coś innego, choć oczywiście wszyscy wyceniają to pod tą samą nazwą, pod tym samym projektem.

 

Kolejna rzecz to różne zakresy, ukryte albo nieopisane rzeczy. Może być tak, że jedna agencja policzy wam integrację, bo będzie robiła te integracje i też już zabezpieczy ten aspekt w projekcie. Inna agencja tych integracji w ogóle nie policzy, bo okaże się, że dostarczają wam tylko i wyłącznie platformę, bez integracji. Kolejny przypadek może być taki, że jedna agencja spojrzy na wasz projekt i pomyśli, że okej, tu jest potrzebny dedykowany szablon, dedykowany layout i wygląd tej platformy. Inna agencja, żeby jej oferta była konkurencyjna i tańsza, przyjmie, że postawi tę platformę na jednym z domyślnych, darmowych szablonów, a jak będziecie chcieli, to w przyszłości będziecie sobie mogli ten szablon zmienić, rozwinąć, ale to już będą koszty rozwojowe, to już nie będą te koszty pierwotne inwestycyjne, więc ta wycena będzie bardziej atrakcyjna. Im więcej jest takich rzeczy nieopisanych, rzeczy ukrytych, o których się nie rozmawia i nie artykułuje się, czy one są wycenione, czy nie są wycenione, tym większe różnice w wycenach i tym więcej tak naprawdę pułapek tego, że mogliście w różny sposób myśleć o tym samym. I nie dogadujecie się później na końcu.

 

Z czego to wynika? Stricte z komunikacji. Nie wynika to z niczyjej złej woli ani z jakichś błędnych założeń. Wynika to po prostu z komunikacji, potrzeb, oczekiwań i z pewnych założeń, które każdy robi jednak troszkę inaczej. Jeżeli nie ma tych podstaw dobrze rozpisanych, to po prostu, tak jak powiedziałam wcześniej, każdy robi jakieś założenia i będziecie mieć różne wyceny.

 

Kolejna kwestia to są też różne założenia technologiczne. Jeżeli wyceniasz sobie platformę, ale wcześniej nie było analizy i nie wiecie w zasadzie, z jakiego rodzaju technologii powinniście skorzystać, i idziesz po wycenę z jednej strony do dostawcy oprogramowania w opcji SaaS, czyli w opcji wynajmu abonamentowej, w drugiej opcji idziesz jeszcze sprawdzić jakiś open source, a w ogóle trzecia agencja gdzieś trafiła dzisiaj na konferencji, która robi dedykowane oprogramowanie, i stwierdzili, że to byłoby najlepsze dla twojego projektu, i idziesz również do nich po wycenę. I teraz w jaki sposób chcesz porównać wyceny oparte na tak różnych założeniach? Nie da się tego zrobić. Porównanie nie będzie miarodajne, bo zawsze za tymi wycenami, już pomijając zakres, jaki przedstawiasz do wyceny, bo może on być superprecyzyjnie nawet spisany, ale różne założenia technologiczne będą wpływały na to, że będziesz mieć różne koszty inwestycyjne i różne koszty utrzymaniowe. I teraz przy takich opcjach, bardzo różnych opcjach technologicznych, jest bardzo trudno zebrać to w jakiś wspólny mianownik i różnice będą tak duże, że de facto tu trzeba sobie najpierw zadać pytanie, ale które kwestie są dla ciebie kluczowe? Które kwestie biznesowo, jeżeli chodzi o technologie, są dla ciebie kluczowe? I w jakim kierunku, w kierunku jakiego rozwiązania technologicznego powinniście pójść jako firma? Dopiero wtedy warto wybrać jeden rodzaj technologii i to porównywać ze sobą. Przy takim założeniu, że idziesz i masz tutaj SaaS, open source i customowe rozwiązanie, będzie to bardzo ciężkie do zrobienia.

 

Kolejna rzecz to jest właśnie też różna architektura, bo może być tak, że ktoś buduje duży produkt, tak zwany monolit. Może być tak, że masz jakiś silnik open source’owy plus do niego jakieś moduły, wtyczki. Może być tak, że ktoś buduje z komponentów, z jakichś bloków większych. Opcje są różne. Jeżeli ta architektura w każdej opcji, tam gdzie poszedłeś po wycenę, jest zupełnie inna, to też trzeba się przygotować, że koszty będą inne, ale też musisz się przygotować na to, że będzie to trudne do porównania. Nadal będzie to opcja trudna do porównania, jeżeli chodzi o wyceny i wybór opcji najlepszej dla twojej firmy.

 

I na koniec, jako wisienka na torcie, jest analiza przedwdrożeniowa, czyli to, co powinniśmy zrobić w projekcie, żeby spisać wymagania, bardzo szczegółowe, konkretne wymagania, ale analiza biznesowa robiona po stronie klienta, nie u dostawcy. Brak tej analizy jest najczęstszą przyczyną błędnych wycen, niemożności porównania tych wycen i później problemów projektowych, wybuchają nam jakieś bomby po drodze, ponieważ nie mieliśmy właśnie dobrych wytycznych. Dlaczego mówię o analizie po stronie klienta, a nie po stronie dostawcy? O tym jeszcze za moment więcej szczegółów.

 

Agile vs kaskada – dwa światy, dwie metodyki

 

Zanim zacznę w szczegółach opowiadać o analizie przedwdrożeniowej oraz innych aspektach, jeszcze na chwilę zatrzymam się na kwestiach związanych z metodyką. Wiem, że to nie jest bardzo popularny ani sexy temat, ale jednak zrozumienie tego podejścia metodycznego robi ogromną różnicę i buduje większą świadomość, szczególnie po stronie biznesu w podejściu do projektu, w podejściu również do wyceny tego projektu. Dlatego teraz słów kilka dosłownie o metodykach, w jakich pracuje biznes, w jakich pracuje IT. Wiem, że oglądają mnie też specjaliści IT, więc w tym momencie bardzo was przepraszam za mega uproszczenia, jakie tutaj zastosuję, ale nie o to chodzi, żeby robić teraz kurs z metodyk, tylko o to, żeby wyjaśnić podstawowe kwestie związane z różnicami pomiędzy tym podejściem w kontekście wycen. Także będę tutaj mocno upraszczać właśnie w tym celu.

 

I wracając, metodyka agile to metodyka zwinna, w której pracuje IT. Metodyka ta jest metodyką iteracyjną, czyli budujemy coś w cyklach. Zazwyczaj są to tak zwane sprinty i trwają one dwa tygodnie lub czasami dłużej. Założenie jest takie, że w tych cyklach wytwarzamy zawsze jakąś skończoną część całości, która jest do zbudowania, czyli całości systemu, która jest w stanie samodzielnie funkcjonować. Można się już, kolokwialnie mówiąc, przez to przeklikać i dany mechanizm coś konkretnego może zrobić. Budujemy iteracyjnie w środowisku, które nie pracuje na pełnej dokumentacji i już bardzo dobrze sprecyzowanym całościowym założeniu w związku z projektem, czyli budujemy sobie w czasie, doklejając, dobudowując kolejne elementy tej całej układanki.

 

Jest to dobre w projektach, które są mniejszymi projektami, czasami też dużymi projektami, ale na przykład w otoczeniu biznesowym, które bardzo szybko się zmienia. I tak naprawdę gdybyśmy chcieli podejść do tego od razu całościowo, przygotować dokumentację i wdrażać jakąś dużą całość, to okazałoby się, że zanim skończyliśmy, to już otoczenie biznesowe tak bardzo się zmieniło, że w sumie to już nie jest przydatne i można to wyrzucić do kosza. Więc w takich przypadkach to podejście iteracyjne jest naprawdę dobre.

 

A metodyka agile’owa bardzo mocno porządkuje pracę zespołów produkcyjnych, zespołów IT, bo jak w każdej produkcji, tak i przy produkcji oprogramowania są różne zespoły, gdzie każdy po kawałku coś swojego robi, żeby wyprodukować tę finalną całość, czyli ten produkt, który ma powstać na koniec dnia, z którego ty będziesz jako klient korzystać. Więc te wymagania mogą się tu zmieniać w projekcie. Jest to bardzo przyjazne, tak jak powiedziałam, dla branż, które mają bardzo dynamicznie zmieniające się otoczenie biznesowe, bo możemy na bieżąco reagować i zmieniać zakres tego projektu. I to jest ten plus.

 

A teraz jaki jest minus? Minus jest związany stricte z finansami i z tym, czego oczekuje biznes, bo warto tutaj od razu przy metodykach wspomnieć o modelach rozliczeń. Branża IT jako preferowany wskazuje model rozliczeń tak zwany time and material, czyli model rozliczeń, gdzie płacisz za realnie przepracowane godziny pracy programistów, testerów i innych specjalistów. Nie da się tutaj na starcie projektu przewidzieć, ile w całości ten projekt nas będzie kosztował, bo de facto nie wiemy, co będzie w zakresie, nie wiemy, jak długo będziemy ten projekt produkować, nie wiemy, na czym skończymy tak naprawdę.

 

Więc jest to taka ciągła, można powiedzieć, produkcja. W którymś momencie oczywiście przecinamy tam wstęgę i uruchamiamy ten system produkcyjnie, ale dalej go produkujemy i dalej go ulepszamy. I w tym modelu oczywiście jest to sensowne, że płacisz za przepracowane godziny i tak dalej, natomiast nie jesteśmy w stanie określić całościowego budżetu projektu, co bardzo często jest czymś wręcz wymaganym dla biznesu, bo biznes pracuje na strategii, na planach na kolejny rok i na budżecie, na budżecie na konkretny projekt. Więc musi zabezpieczyć ten budżet z jakimś buforem, musi znać skalę tego projektu i mniej więcej chociażby budżet, na jakim ma pracować.

 

I tu wchodzimy w perspektywę biznesu, czyli wchodzimy w inną metodykę, w metodykę kaskadową, tak zwany waterfall. Nawet jeśli dzisiaj jako biznes jesteś na takim etapie, że dziwi cię to, że pracujesz niby w jakiejś metodyce, że nawet o tym nie wiesz, to prawda jest taka, że pracujesz właśnie w sposób kaskadowy. Jest to naturalna, można powiedzieć, taka tradycyjna wręcz metoda pracy w biznesie.

 

I co jest tutaj ważne w tej metodyce? Ważne jest kilka rzeczy. To, że biznes chce wiedzieć, ile taki projekt potrwa, czyli jak długo on będzie trwał, ile miesięcy, tygodni, ile to będzie kosztować, czyli budżet, jakąś konkretną kwotę, i co dostaniemy na końcu, czyli co będzie efektem, jaki jest zakres tego projektu, co zostanie wyprodukowane, jak będzie wyglądać ten finalny produkt, który otrzymamy w ramach tego projektu.

 

I w tym podejściu najpierw buduje się pełen opis zakresu projektu, pełne wymagania, szczegółowe. Wycenia się też całość projektu. Na podstawie wyceny jest przygotowywany budżet. Oczywiście budżet projektu takiego e-commerce wewnątrz firmy jest dużo szerszy niż tylko budżet na samą platformę, ale mamy wszystkie klocki, zbieramy i robimy budżet takiego projektu, zatwierdzamy ten budżet, dopiero następuje wdrożenie. Wdrożenie oczywiście może być etapowe, nie jest powiedziane, że od razu musimy wdrożyć całą całość i dopiero uruchomić taką platformę. Ono może być podzielone na etapy, ale na początku już chcemy znać cenę całości.

 

I model rozliczeniowy, w którym pracuje biznes, zazwyczaj to jest model, który się nazywa fixed price, czyli ustalona z góry cena. Plusem tego podejścia, tej metodyki, jest to, że mamy pełną przewidywalność w projekcie, gdzie jeśli trzymamy się mocno tego projektu, a otoczenie biznesowe nie zmienia się nam tak szybko, więc możemy de facto poświęcić kilka miesięcy, czasami kilkanaście miesięcy, żeby budować sobie tę naszą całość, w którymś momencie oczywiście ją uruchomić. Więc mamy tutaj pełną przewidywalność. Mamy harmonogram, wiemy, co się wydarzy w którym etapie, ile to będzie kosztowało. Więc wiemy też, jakich ewentualnie możemy się spodziewać dopłat, bo wiemy, że każda zmiana w tym projekcie może nas kosztować, a im później, czyli na bardziej zaawansowanym etapie projektu, i im większe zmiany, bardziej gruntowne, tym mocniej będą obciążały budżet i harmonogram.

 

Każdy z tych podejść ma swoje plusy, ma swoje minusy. Jak to w życiu bywa, nigdy nie ma idealnej i czystej sytuacji, więc zawsze musimy tutaj wypracować jakiś kompromis, bo te dwa światy się po prostu ze sobą zderzają, ścierają. Każdy ma swoje oczekiwania i żeby się dogadać, trzeba wypracować coś pośrodku.

 

I w realnych wdrożeniach, w realnej rzeczywistości, biznes tak naprawdę oczekuje podejścia kaskadowego, szczególnie w przypadku zakresu, czyli tego, co dostaniemy, i pieniędzy budżetu, pieniędzy, które musimy wyłożyć na ten projekt. IT znowu chce pracować według agile’a, bo to bardzo mocno też porządkuje sposób pracy i rozliczać się też z godzin przepracowanych w danym miesiącu. Więc dochodzimy do tego, że robimy pewien kompromis. Za chwilę o tym opowiem też przy analizie.

 

Natomiast mamy zazwyczaj początek tego projektu IT, kiedy idziemy do dostawcy, kiedy jeszcze wcześniej robimy analizę. Więc początek jest bardziej kaskadowy, żeby klient się zorientował w zakresie, poznał ten zakres, zorientował się w budżecie. Natomiast później w samym projekcie IT, w samym projekcie wdrożeniowym IT już podchodzimy do tego agilowo, czyli budujemy to oprogramowanie w cyklach, w etapach. Rozliczamy się też etapowo, w transzach albo comiesięcznie z przepracowanych godzin. Na końcu ważne, żeby nam się to mniej więcej bez jakichś większych odchyleń zgodziło, czyli też minimalizujemy te ryzyka popłynięcia całkowicie z budżetem tego projektu.

 

I to jest ważne, żebyśmy pamiętali o tym, że nigdy nie będziemy mieli czystej sytuacji, czyli jednej metodyki albo drugiej, ale warto znać nawzajem sposób, w jakim pracujemy, oraz sposób podejścia do wycen, do rozliczania się w takim projekcie, żebyśmy trochę lepiej zrozumieli siebie nawzajem.

 

Analiza przedwdrożeniowa – fundament wycen

 

Opowiedziałam o dwóch różnych podejściach, o metodyce agile’owej i metodyce kaskadowej, oraz o tym, że trzeba szukać kompromisów. I dla mnie takim kompromisem jest analiza przedwdrożeniowa, ale wykonywana właśnie po stronie klienta. Dlaczego? Dlatego, że analiza przedwdrożeniowa de facto pochodzi z metodyki kaskadowej, czyli z tej metodyki, w której zazwyczaj pracuje biznes. IT, jeżeli robi, to robi warsztaty analityczne, jakąś analizę biznesową. Bardzo różnie to jest nazywane przez firmy IT.

 

Natomiast nie trwa to zazwyczaj tak długo, chociaż niektóre firmy działają trochę bardziej konsultingowo i rzeczywiście skłaniają się właśnie ku takim szczegółowym analizom, szczególnie jeżeli wdrażają rozwiązania dedykowane, to wtedy muszą poznać wszystkie aspekty takiego projektu. Natomiast zazwyczaj pokazują, jakie mają rozwiązanie, co klientowi pasuje, co nie pasuje, ustalają, jakie modyfikacje powinny zostać wprowadzone i to są tego typu prace, tego typu analizy, warsztaty, jakkolwiek byśmy to nie nazwali.

 

Natomiast jeżeli chodzi o analizę przedwdrożeniową, ona jest charakterystyczna dla metodyki kaskadowej, metodyki, w której pracuje biznes. Dlatego ja ją wykonuję, wiedząc o tym, jakie potrzeby ma biznes, i wykonuję ją po stronie klienta na tym etapie, zanim pójdziemy jeszcze do dostawcy oprogramowania, bo to jest czas, w którym klient bardzo dużo się uczy i bardzo dużo zmienia w swoim biznesie, w swojej firmie, modyfikuje procesy, przygotowuje dane.

 

To jest jeszcze za wcześnie, żeby pójść do dostawcy i rozmawiać o oprogramowaniu, bo na wiele pytań, na które dostawca będzie chciał znać odpowiedź, tak z miejsca wy nie będziecie w stanie w ogóle odpowiedzieć. A przygotowanie się do tego, żeby wrócić do dostawcy z powrotem i już być przygotowanym, to zajmuje czasami kilka albo kilkanaście miesięcy. Więc to jest taki, można powiedzieć, trochę falstart. Dlatego robimy tę analizę przedwdrożeniową.

 

I ta analiza przedwdrożeniowa jest takim moim podejściem. Spotkacie na rynku zupełnie inne podejścia, szczególnie jak pójdziecie od razu do dostawców. Natomiast ja robię to w taki sposób, dlatego że mi się to po prostu sprawdza w pracy z klientami. To się sprawdza również później, jeżeli chodzi o wyceny, bo każdy z dostawców dostaje ten sam materiał, te same wytyczne, na podstawie których robi wyceny, ale o tym jeszcze będzie później w tym odcinku.

 

Natomiast jak robię to po stronie klienta, czyli jak robię te analizy, ona nie jest pisana pod żadne oprogramowanie, czyli jeżeli przeczytasz taką analizę, to odniesiesz wniosek, że nie ma takiego oprogramowania na rynku. I to jest prawda. Nie ma takiego oprogramowania na rynku i nie będzie, bo ona nie jest pisana pod konkretne oprogramowanie, bo ja nie jestem dostawcą IT, ja nie sprzedaję żadnej platformy.

 

Ona jest pisana pod wymagania biznesu, bez takiego pręgierza, bez presji stojącej nad głową biznesu, że muszą się dostosowywać w swoich procesach do jakiegoś oprogramowania. Żeby właśnie takiej sytuacji nie było, robimy to odwrotnie. Opisujemy to, czego potrzebuje biznes, czego potrzebuje klient końcowy, a później idziemy w rynek i szukamy rozwiązania, które najbardziej, nigdy nie będzie w 100%, ale które najbardziej odpowiada wymaganiom klienta, a resztę, czego nie ma, możemy dopisać, zrobić jako dedykowane rozwiązanie, dedykowaną funkcjonalność do tej całości, która już jest.

 

Więc uzupełniamy tylko te rzeczy, których po prostu nie ma, albo modyfikujemy to, na czym nam najbardziej zależy, a w jakimś silniku, na przykład w silniku open source, tego nie ma. Ona opisuje cały zakres projektu, czyli w analizie opisujemy sobie wszystko, opisujemy sobie wstęp biznesowy, opisujemy sobie wszelkie wymagania funkcjonalne, niefunkcjonalne, wymagania dedykowane.

 

Czyli jeżeli wiemy już, że funkcjonalność jest dedykowana, jest to jakiś konfigurator albo jakieś inne rozwiązanie, to wtedy opisujemy sobie osobno jako dedykowane rozwiązanie, które trzeba dopisać do tej platformy. Również powstają wtedy projekty. Nie są to superprofesjonalne projekty UX/UI, ale to już jest coś wizualnego, co biznes jest w stanie zobaczyć, jakby to wyglądało, jakby to działało, zrozumieć, a agencja ma wtedy już łatwiej, bo ma już narysowane i w zasadzie po prostu trzeba to zrobić trochę ładniej.

 

Powstają wtedy też schematy, schematy przepływu danych, procesów, na podstawie których można dobrze zrozumieć, jak systemy, wszystkie systemy w tym ekosystemie e-commerce klienta mają ze sobą rozmawiać, czyli jak mają się ze sobą integrować. I ta dokumentacja jest wyjściową dokumentacją dla wszystkich dostawców, bo nigdy nie jest tak, że wdrażasz tę platformę w jakiejś izolacji.

 

Ona komunikuje się z różnymi systemami, które już masz, albo nowymi, które musisz wprowadzić w trakcie takiego projektu. W związku z tym musimy stworzyć bazę informacyjną i bazę wyjściową dla wszystkich interesariuszy w tym projekcie, dla wszystkich uczestników tego projektu, żeby mieli wszyscy jedno źródło prawdy o tym, co my robimy w tym projekcie.

 

I później przerzucamy to sobie, oczywiście te wytyczne przerzucamy sobie do jakiegoś narzędzia, w którym będziemy pracować w projekcie. Natomiast dzięki tej analizie, dzięki tym wytycznym szczegółowym i konkretnym, agencje wiedzą, jak coś wycenić.

 

I teraz gwiazdka. Nie wszystkie elementy w tej analizie są opisane tak, że muszą być zrobione jeden do jednego. W analizie zostawiamy sobie właśnie takie luki, takie opcje, w których moglibyśmy coś dookreślić, że idziemy w jednym albo w drugim kierunku. I w tym celu służą właśnie warsztaty wdrożeniowe, warsztaty analityczne, różnie to nazywamy, ale są to takie spotkania na początku pracy z agencją, na których ustalamy sobie już, co konkretnie chcemy zrealizować w danym oprogramowaniu.

 

I tak jak powiedziałam, nie trwają one trzy miesiące, tylko trwają kilka dni, są dużo krótsze, szybsze i dookreślamy tylko te punkty, w których mieliśmy tam coś jeszcze do ustalenia i możemy zaczynać projekt.

 

Także podsumowując tę część, analiza przedwdrożeniowa po stronie klienta daje ci taką przewagę, że masz po prostu taką solidną podstawę, jedno źródło prawdy, jedno źródło szczegółowych, konkretnych wytycznych dla agencji, które będą wyceniały realizację tej platformy, czyli będą wyceniały twój projekt. Mamy dokładnie ten sam zakres dla wszystkich i dlatego też mamy dobrą podstawę do wycen, które możemy później między sobą łatwo porównywać.

 

Jak to zrobić? Jak to porównywać? Jak wygląda narzędzie, można powiedzieć, w którym będziemy pracować i będziemy porównywać, już za chwilę więcej o tym narzędziu.

 

Excel do wycen – narzędzie, które wyrównuje boisko

 

Narzędzie, o którym wspomniałam, bardzo wam się spodoba, bo jest to plik Excel. Opisaną analizę przerzucam właśnie do pliku Excel, gdzie zbieram wszystkie wymagania, ale mogę też zarządzać sobie bardzo dobrze odpowiedziami dostawców. Mam tam odpowiednie kolumny z wpisaniem czasochłonności.

 

Na tym pliku też pracujemy z klientem, określając priorytety, dzieląc ten projekt na etapy, bądź też analizując, z czego możemy zrezygnować. Jeśli jakaś funkcja była powiedzmy niezbyt ważna albo w ogóle mało ważna, a okazuje się, że dane oprogramowanie super, świetnie nam pasuje, tylko akurat nie ma czegoś, tak? Nie ma tej jednej rzeczy i trzeba ją wyprodukować. Ona bardzo dużo kosztuje, ale okazuje się, że jest dla nas mało istotna, więc wtedy możemy takie rzeczy na przykład usunąć.

 

Jest to praca na konkretnych już danych, na konkretnym pliku z wycenami, więc wtedy nie wróżymy już fusów, czy z czegoś zrezygnujemy na początku, czy nie, tylko podejmujemy te decyzje już na późniejszym etapie, kiedy widzimy konkretne liczby.

 

Jak wygląda praca na takim Excelu i co te agencje konkretnie właśnie ode mnie dostają. Dostają jeden i ten sam plik na podstawie analizy przedwdrożeniowej, czyli z wszystkimi wymaganiami. Wszyscy wypełniają ten sam plik. Dzięki temu każda oferta ma ten sam podział na przykład na moduły, bo ja to dzielę na takie większe części, moduły, i opisuję po prostu każdy z nich.

 

Każda agencja ma też osobną pozycję, w której powinna uwzględnić na przykład testy, project management, integrację. Ja zawsze też opisuję główne i kluczowe funkcjonalności w projekcie i podejście, jakie chcemy zastosować przy wycenie. Każda agencja ma też miejsce na wpisanie dodatkowych elementów, jeżeli takie występują.

 

A my możemy sobie sprawdzić, czy każda agencja przewidziała dokładnie to samo. Likwidujemy też w dużej mierze, tak jak powiedziałam, gdzieś tam sobie furtkę zostawiamy, ale w dużej mierze likwidujemy takie opcje typu do ustalenia. Opcjonalnie wycenimy później. To są rzeczy, które mogą nam wybuchnąć, więc lepiej dookreślić je już na początku i wiedzieć po prostu, ile będą kosztowały, nie zostawiać czegoś takiego w wycenie.

 

Także często jest też tak, że po otrzymaniu pierwszej wersji pliku już z wyceną pracuję z agencją nad tym, żeby jeszcze porozmawiać, dookreślić, jak podeszli do tej wyceny. Czasami jest tak, że jeżeli wyceniamy już powiedzmy nie na tej samej technologii, czy na przykład mieliśmy wszystkie trzy wyceny z open source’a, ale wyceniamy nawet już na tym samym rozwiązaniu, tak? Czyli na tym samym silniku, tylko mamy wyceny od na przykład trzech różnych agencji, to wtedy widzimy jakieś różnice.

 

Możemy zobaczyć różnice w wycenie. Ktoś wycenił na 60 godzin, a inny na 20 godzin. No i powstaje nam pytanie: ktoś przeszacował, ktoś nie doszacował? Nie doszacował, dlaczego, chce zdobyć klienta, potem nam to wybuchnie, czy może wręcz odwrotnie. Ten, kto dał niższą wycenę, dobrze to oszacował, ale na przykład znalazł sposób na to, żeby zrobić to inaczej. Może ma jakąś wtyczkę, którą sam zrobił, na przykład do takiego silnika open source. Może ma kawałek swojego produktu, który napisał i który na dzień dobry daje nam możliwość szybszego wdrożenia czegoś, bo to już jest, a inna agencja czegoś takiego nie zrobiła i w tej chwili musi to dopiero wytworzyć dla nas specjalnie. Dlatego tam wycena jest wyższa.

 

Takie różnice wymagają pytań, wymagają spotkań, wymagają sprawdzenia i dookreślenia tego, jakie podejście zostało zastosowane, jaka to jest sytuacja, żeby dobrze zrozumieć tę wycenę, bo nie należy, jak to mówią, oceniać książki po okładce, czyli od razu z góry zakładać, że ktoś chciał nam zrobić, że tak powiem, krzywdę, źle wycenić i chciał po prostu, nie wiem, zedrzeć z nas kasę, mówiąc kolokwialnie, to może wynikać z zupełnie innych podstaw i absolutnie nie ma w tym niczyjej złej woli. Po prostu inne są podstawy, inne są założenia.

 

Jaki mamy w tym efekt? Jeżeli bazujemy na czymś takim, wyceny te są porównywalne praktycznie jeden do jednego, bo mamy określone moduły, mamy to ładnie obok wycenione, więc one są porównywalne. Nie ma tutaj wróżenia z fusów, nie ma później dopłat z kosmosu, niewyjaśnionych rzeczy, nie ma zgadywania, nie ma czegoś takiego też, że ktoś czegoś nie policzył, bo to po naszej stronie, po stronie klienckiej jest to, żeby uzupełnić ewentualne luki, dopytać o coś, czego tam nie ma, żebyśmy mieli właśnie taki plik porównywalny jeden do jednego i mogli najlepiej podjąć decyzję o wyborze platformy.

 

Co musi być w wycenie?

 

Skoro była mowa o wycenach, była mowa o super magicznym Excelu, który daje nam podstawę do tego, żeby porównywać wyceny, to teraz dosłownie w telegraficznym skrócie, co powinno się znaleźć w takiej wycenie. Możecie sobie z tego zrobić taką checklistę tego, co powinno się znaleźć w wycenie.

 

Po pierwsze, pamiętajcie, że podstawą jest analiza przedwdrożeniowa i zakres, który mamy. Więc jeżeli ktoś przesyła wycenę, powinien to zrobić w tym pliku albo powinien odnieść się do zakresu, który mu przesłaliście. To powinien być załącznik do oferty, załącznik do wyceny, czyli wasz zakres, który podaliście, powinien mieć odzwierciedlenie w wycenie, mieć odzwierciedlenie w ofercie, którą dostajecie.

 

Kolejna rzecz, jeżeli coś jest nieuzasadnione, to mamy warsztaty analityczne i one się powinny znaleźć w wycenie jako pozycja i agencja powinna wskazać, czy dostawca rozwiązania SaaS powinien wskazać, ile będą te warsztaty trwały, ile one będą kosztowały. Więc takie elementy też są elementem wyceny, nie tylko funkcjonalności, ale również właśnie dodatkowe elementy, jak warsztaty analityczne czy na przykład opieka project managera po stronie agencji, po stronie dostawcy.

 

Czyli żebyście nie musieli szukać i nie wiadomo, z kim się komunikować, tylko żebyście mieli jedną osobę do kontaktu, która już będzie po stronie agencji, po stronie IT, będzie załatwiała wszystkie sprawy dla was. Dobrze, żebyście po swojej stronie też mieli taką jedną osobę, wtedy to jest dużo łatwiejsze. Natomiast to też są elementy, które trzeba wycenić, bo to też są godziny, to też jest czyjaś praca.

 

Kolejna rzecz to UX i UI, czyli ten szablon, layout, jakiś design, makiety. I jeżeli potrzebny jest dedykowany szablon, jeżeli nie będziecie bazować na jakimś szablonie darmowym, dostępnym odgórnie w platformie, to wtedy taka wycena też powinna się znaleźć, czyli taka pozycja w wycenie też powinna być.

 

Kolejna rzecz to development. Development to jest wszystko, co musi być wyprodukowane dla was, bo jest dedykowaną funkcjonalnością w waszej platformie. Więc wszystko, co jest powiedzmy tam w silniku, to jest jakaś większa całość, jest wycenione, ale jeżeli są potrzebne jakieś modyfikacje tego, co jest w danym silniku, albo w ogóle całe moduły są do zbudowania dla was, całej funkcjonalności, to to też powinno zostać wycenione i wyodrębnione, żebyście wiedzieli, ile taki development będzie kosztował.

 

Kolejna rzecz to integracje. Jeżeli firma, która dostarcza platformę, jest w stanie zrobić część integracji, może całość integracji, to powinna opisać, co jest w stanie zrobić, ile to będzie kosztowało. Wtedy też dla was to jest informacja, ile integracji zostaje niezaopiekowanych, bo tak jak powiedziałam, wasz projekt e-commerce jest większy, tam jest więcej systemów, więc może się okazać, że trzeba zintegrować również systemy, których dostawca platformy w ogóle, że tak powiem, nie dotyka.

 

No ale to już jest konkretna informacja, jakie integracje wycenili, czy w ogóle jakieś wycenili i jak macie do tematu integracji podejść dalej w swoim projekcie.

 

Dalej, migracja danych. Jeżeli zakładacie, że już wcześniej klienci kupowali, zakładacie, że chcecie, żeby na początku, jak się zalogują do platformy, widzieli na przykład swoje historyczne zamówienia czy faktury, to też trzeba te dane przenieść. Dane kontrahentów na początek też trzeba zaimportować do takiej platformy, więc taka migracja danych też powinna zostać wyceniona.

 

Kolejna rzecz to testy. Testy, różne rodzaje testów, ale nie musicie mieć wypisanych wszystkich szczegółowo. Ważne, żeby była pozycja testy wskazane, ile będą trwały, ile będą kosztowały takie testy, żebyście wiedzieli i mieli pewność, że platforma zostanie przetestowana, zanim zostanie oddana wam do tak zwanych QA testów, czyli testów quality assurance, testów po stronie biznesu, gdzie wy przeklikujecie się przez platformę i akceptujecie to, jak ona działa.

 

Kolejna rzecz to też infrastruktura, na przykład infrastruktura serwerowa. Jeżeli serwery są potrzebne, bo wdrażacie na przykład open source’a, to wtedy warto, żeby agencja zaproponowała taką pozycję, jeżeli w ogóle ma takie możliwości, bo wtedy możecie sobie porównać, ile by was kosztowały serwery, które weźmiecie właśnie od tej agencji, a ile serwery, gdybyście kupowali w innym miejscu, od innego dostawcy.

 

Dlaczego warto to rozważyć? Dlatego że w przypadku open source często idziemy w utrzymanie, czyli agencja, jak wyprodukuje, dalej przejmuje utrzymanie, czyli opiekowanie się tą platformą i ma trochę łatwiej. Nie jest to oczywiście przeszkodą, żeby serwery były gdzieś indziej, ale ma trochę łatwiej, jeżeli te serwery są jakby kupowane od nich i wtedy mogą się nimi po prostu zajmować i sprawdzać od tej strony technicznej, czy wszystko jest okej i czy wasza platforma prawidłowo działa, oraz reagować na różnego rodzaju awarie i błędy.

 

Kolejna pozycja to uruchomienie, czyli tak zwane go live, czyli koszt uruchomienia produkcyjnego sprzedaży w waszej platformie. I tak jak już nawiązałam do tego, kwestia uruchomienia i utrzymania. Jeśli dalej ta sama agencja ma utrzymywać tę platformę, to taka pozycja powinna się znaleźć. W przypadku open source’ów nie jest to konieczne. Możesz utrzymywać tę platformę sam albo przez jakąś inną agencję.

 

Jeżeli bierzesz rozwiązanie SaaS, to utrzymanie jest po stronie dostawcy, więc tym bardziej musisz znać te koszty, dlatego że wtedy to się nazywa abonament i wtedy musisz go płacić co miesiąc. Więc ważne, żebyś wiedział dokładnie, jakiej wysokości to będą koszty. A modele płacenia tego abonamentu i rozliczania kosztów inwestycyjnych też są bardzo różne w przypadku platform SaaS-owych, więc warto wiedzieć, jakie podejście stosuje dany dostawca.

 

Jeżeli mamy produkty, czyli mamy rozwiązania SaaS, albo nawet w open source’ie mamy jakieś wtyczki, moduły tudzież większe całości produktowe, które napisała dana agencja, to zazwyczaj będziemy mieć do tego licencję albo powinniśmy mieć licencję na wykorzystywanie, na używanie takich modułów. I teraz powinniśmy zadbać o to, żeby taka pozycja też się znalazła. Nawet jeżeli tam będzie wpisane zero, bo ktoś wam daje coś za darmo, to taka pozycja niech się znajdzie. Niech tam będzie zero.

 

Zazwyczaj to nie jest zero, więc warto dopilnować i sprawdzić, czy takie elementy są i czy przewidziana została jakaś opłata za taką licencję i ile taka opłata wynosi, jak długo musicie tę opłatę płacić. Czy to jest jednorazowa płatność, czy to jest płatność przez kilka lat, na przykład pierwszych, czy to jest odnawianie co roku i płatność de facto jakiejś kwoty rok do roku, jeżeli będziecie korzystać z danego modułu, z danej wtyczki.

 

Oczywiście do tego wszystkiego, jak już macie wycenę od dostawcy, bo o tym mówimy, jakie są elementy tej wyceny, ale na końcu jeszcze jedno zdanie. Po prostu dopiszcie te pozycje wyceny do budżetu, do wyceny całego projektu e-commerce. Pamiętajcie, że platforma to nie jest tylko jedna pozycja w waszym budżecie. To jest jedna z wielu pozycji w waszym budżecie projektowym. Jeżeli już poznacie tę wycenę, dopisujemy ją jako kolejną pozycję do całego budżetu e-commerce.

 

Jak czytać wycenę?

 

Wiemy już, co powinno znaleźć się w wycenie, jakie elementy powinny tam być. A teraz w skrócie, czego brak w tych wycenach powinien wywołać alarm i jak powinniście czytać te wyceny, żeby wykrywać jakieś pułapki.

 

Pierwsze: jeżeli nie ma informacji o integracji, a zakładaliśmy i pisaliśmy tak w wymaganiach do dostawcy, że ma uwzględnić integrację, a potem w wycenie nie ma takiej pozycji, to powinno cię zaalarmować, dlatego że brak takiej informacji, brak wyceny tego może powodować, że w późniejszym etapie projektu dopłacisz sporo więcej. To może być kilkanaście, kilkadziesiąt tysięcy, to może być kilkaset tysięcy złotych, w zależności od tego, co i jak trzeba zintegrować.

 

Jeżeli nie ma tam informacji o szablonie, o layoucie albo jest wpisane UX, 0 zł, to też musisz wiedzieć, że będzie to wdrożenie na standardowym szablonie. Jeżeli ci to odpowiada, to super. Jeżeli ma być to dedykowany szablon, no to tutaj powinieneś już porozmawiać z dostawcą na temat tego podejścia i ustalić, że jednak być może powinien to być dedykowany szablon. Jeżeli dostawca nie dostarcza czegoś takiego i musisz wziąć do tego jakąś zewnętrzną firmę, to okej, można tu zostawić zero, ale przynajmniej masz tę świadomość, że dostawca nie dostarczy ci dedykowanego szablonu layoutu, tylko musisz przygotować na to środki i wziąć do tego po prostu inną firmę.

 

Jeśli nie ma pozycji testów, to dopytaj, czy takie testy będą prowadzone, bo zazwyczaj, szczególnie w mniejszych agencjach takich butikowych, nie ma zespołu testów, nie ma zespołu testerów, więc najprawdopodobniej tych testów nie będzie albo będą bardzo okrojone i obowiązek przeprowadzenia testów spadnie na ciebie. A ty jako klient w większości przypadków, ja wiem, że są u was wyjątki, gdzie macie jakieś szczątkowe chociażby zespoły IT, ale w większości przypadków nie masz takich ludzi, nie masz takich kompetencji, nie masz pojęcia, jak wykonać takie testy, ani nawet nie masz narzędzi, którymi mógłbyś część z tych testów wykonać.

 

Więc platforma będzie obarczona bardzo dużym ryzykiem, ryzykiem bezpieczeństwa, ale ryzykiem też poprawnego działania. A start u kontrahentów, żeby wzbudzić ich zainteresowanie i zaangażowanie, masz tylko jeden raz. To jest jedna szansa. Jeżeli ją zepsujesz, to potem ciężko będzie to odbudować biznesowo i żadne promocje tutaj nie pomogą.

 

Kolejna rzecz to zbyt niska wycena. Jeżeli ta wycena jest zbyt niska, jeżeli wiesz, że rynkowo to jednak jest trochę drożej albo stawka godzinowa jest zbyt niska, to możesz się spodziewać tego, że albo ktoś celowo to zrobił, żeby zaniżyć wycenę, żeby ona była najniższa, bo wie, że klienci wybierają zazwyczaj najniższą cenę i chciał po prostu wygrać tak ten projekt, albo oznacza to, że będzie robił to jakimiś juniorami, freelancerami na niższej stawce.

 

I to też jest duże ryzyko projektowe, jeżeli on działa na ludziach z niższymi kompetencjami albo jeżeli nie ma zbyt dużego wpływu na to, bo jeżeli freelancer nie będzie miał czasu wykonać tego projektu, będzie pracował przy innych projektach, nie będzie to dla niego kluczowy projekt, to się może okazać, że twój harmonogram się posypał, a czasami czas wdrożenia platformy i moment jej wdrożenia jest dużo ważniejszy niż te pieniądze, które na tym zaoszczędzisz, bo wystartowanie przed sezonem i zrobienie super sprzedaży przez platformę w sezonie może dać ci dużo więcej pieniędzy niż to, co zaoszczędzisz na tym, że wybierzesz najtańszą ofertę.

 

Kolejna rzecz: sprawdzaj wszystkie rzeczy do ustalenia. Jeżeli są, to po prostu wracaj z tą wyceną do dostawcy i ustalaj. Nie zostawiaj czegoś takiego na później, bo później może to się obrócić przeciwko tobie i może się okazać, że tam jest naprawdę sporo jeszcze pieniędzy do włożenia w ten projekt.

 

Jeżeli nie ma pozycji project management czy jakiś opiekun, jakkolwiek by to nazwali, to też dopytaj, czy taka osoba będzie, czy to zostało przewidziane. Jeżeli tak, to poproś o dopisanie tego do wyceny, bo to jest dla ciebie wiążący dokument de facto później do podpisania umowy i do trzymania się tego dalej we współpracy projektowej.

 

Jeżeli nie ma project managera, jest bardzo duże ryzyko, że projekt po prostu nie dojedzie, nie będzie dowieziony, ponieważ nie będzie tej osoby, która by czuwała nad tym projektem.

 

To są takie podstawowe rzeczy, które powinny zwrócić twoją uwagę i powinieneś wrócić z nimi do dostawcy, jeszcze raz je przegadać, ustalić, żeby mieć pełny obraz tego, co zostało wycenione i co zostanie zrealizowane w projekcie.

 

Jak porównać oferty?

 

Na koniec tego odcinka powiem jeszcze kilka słów o tym, jak porównywać oferty dostawców. Jeśli postępujesz tą moją ścieżką z analizą przedwdrożeniową, z magicznym Excelem i wiesz już, jak czytać te oferty, co powinno wzbudzić twoje zainteresowanie, brak czegoś lub jakaś nadmierna ilość pozycji, których nie do końca rozumiesz, to na koniec jeszcze kilka słów dodam o tym, jak porównywać te oferty między sobą, kiedy już masz komplet tych danych.

 

Załóżmy, że odrobiłeś te lekcje wszystkie poprzednie wzorcowo i masz już komplet danych. To teraz idziemy w kierunku tego, jak porównywać te oferty.

 

Przede wszystkim porównuj zakres, nie cenę. Tak jakby finalnie wiem, że cena i ta suma na dole jest najważniejszą liczbą, której szukasz. Natomiast porównuj zakres i patrz, co dostaniesz w każdym rozwiązaniu, czy też od każdej agencji, żeby wybrać coś najbardziej odpowiedniego dla twojego projektu.

 

Kolejna rzecz, porównuj technologię. Czyli jeśli idziesz po wyceny, to na przykład na początku decydujesz się, że idziesz po rozwiązania SaaS, to bierzesz trzy wyceny z rozwiązań SaaS. Jeżeli one ci nie pasują, widzisz już na początku, że to jednak nie ten kierunek, że trzeba iść w open source, to bierzesz trzy z open source i porównujesz open source między sobą. Jeżeli z open source’a któraś ci na przykład przypasuje platforma, masz wycenę, ale chcesz zobaczyć, czy jakaś inna agencja zrobiłaby to za inne pieniądze, to wtedy idziesz kolejny krok i bierzesz trzy wyceny od agencji, które pracują na tym samym rozwiązaniu, na przykład na tym samym silniku. Wtedy takie porównywanie ma w ogóle sens.

 

Porównuj architekturę. Patrz też, jakie rozwiązania przyjęły te firmy. Czy one zbudowały na przykład do open source’a jakiś kawałek swój produktowy i mogą coś przyspieszyć, czy inna firma tego nie ma. W jaki sposób będzie można rozwijać później w przyszłości dane oprogramowanie? Nie kupuj. Kupuj z myślą o tym, że jest to na kilka lat do przodu, więc dobrze wybieraj, żebyś też nie tylko zaoszczędził na wdrożeniu, czyli na tej inwestycji, ale też jakoś sensownie płacił te opłaty utrzymaniowe, bo może się okazać, że tu, gdzie teraz zaoszczędzisz na dzisiaj chwilowo na tej inwestycji, to może się okazać, że po prostu zjedzą cię, za przeproszeniem, a później abonamenty i w żaden sposób całościowo patrząc na projekt nie zaoszczędzisz.

 

I kolejna rzecz to to całościowe spojrzenie na projekt, czyli porównuj TCO, czyli total cost of ownership, czyli biorąc pod uwagę koszt wdrożenia, koszt inwestycji, koszty utrzymaniowe później, które mają doprowadzić do tego, że ten projekt w którymś momencie się w końcu zwróci. Na temat ROI, zwrotu z inwestycji, opowiadałam w jednym z poprzednich odcinków, także zachęcam cię, jeśli nie oglądałeś, żeby wrócić i obejrzeć i nadrobić ten temat.

 

Kolejna rzecz to porównuj kompetencje zespołów. Tak jak opowiadałam, tutaj UX, testerzy, project management, mniejsze agencje zazwyczaj nie mają takich zespołów, czasami mają pojedynczych specjalistów. W tym zakresie większe agencje mają zazwyczaj zespoły. Porównuj, co dana agencja ma, co jest ci w stanie zaproponować, na jakim to będzie poziomie. Zawsze zobaczysz tutaj różnicę i to też ma wpływ na twój projekt, nie tylko to, na ile wycenili, że ci wyprodukują, czyli programistycznie zakodują ci po prostu jakąś funkcjonalność. Takie rzeczy też mają duże znaczenie.

 

Porównuj integrację. Czyli jeżeli wycena jakiejś agencji była wyższa, ale zawierała integrację, druga była niższa, ale nie miała integracji, no to musisz się zorientować, ile kosztowałoby dorobienie samych tych integracji, jednak doliczyć to do tej wyceny i wtedy dopiero masz możliwość porównania prawidłowego tych wycen. Tak jakby nie porównuj, że to jest tańsze, to jest droższe w momencie, kiedy nie wiesz, że na przykład ta droższa zawiera integrację, a ta tańsza nie. I na przykład dodanie integracji, dorobienie tego przez inną firmę i dodanie tego kosztu może się okazać, że ta pierwsza wycena, która była niższa, jednak finalnie jest wyższa niż ta, która wydawała ci się za droga. Także trzeba tutaj umiejtnie to sprawdzić i porównywać.

 

Oceniaj też komunikację i proces. Już w tym procesie wyceny, pierwszych prezentacji, tych warsztatów analitycznych, już w tym etapie widać, czy jest to tak zwane flow. Czy jest to porozumienie, czy jest dobra komunikacja z agencją, bo to jest też pierwszy symptom, taki sygnał, jak będzie ci się z nimi pracować. Nawet jeśli na początku wysyłają handlowca, a potem dostaniesz kogoś innego do pracy, to jednak dobór ludzi do firmy jest pod kątem jakiejś kultury organizacyjnej i sporo ci to powie o tym, co jest wewnątrz firmy i jak ci się będzie z tą firmą współpracowało.

 

To najważniejsze rzeczy, więc pamiętaj o tym, jeżeli będziesz porównywać oferty i zawsze rób to z głową.

 

Na podsumowanie tego odcinka zbiorę cztery najważniejsze rzeczy, które powinniście zapamiętać właśnie na dzisiaj.

 

Po pierwsze, nie da się porównywać wycen, jeśli każda agencja wycenia co innego. Mówimy tutaj o zakresie funkcjonalnym projektu, który każda agencja od ciebie otrzymuje do wyceny.

 

Po drugie, analiza przedwdrożeniowa po stronie klienta eliminuje około 90% chaosu i dopłat. Jeśli wiesz konkretnie, co ma być zrealizowane, i wszyscy pracują na tym samym zakresie, wtedy te wyceny są miarodajne i porównywalne.

 

Kolejna rzecz, trzecia. Jeden spójny Excel sprawia, że oferty stają się porównywalne, wręcz prawie jeden do jednego, bo znasz dokładny zakres, dokładne elementy, punkty, czyli rzeczy, które wycenia ci dana agencja i możesz to między sobą porównywać.

 

I po czwarte, nie wybieraj nigdy najtańszego rozwiązania. Nie wybieraj najdroższego. Wybierz po prostu takie, które jest najbardziej przewidywalne, najbardziej pasujące do twojego przypadku biznesowego. Coś, co jest dopasowane na dzisiaj w twoich wymaganiach, ale również ma potencjał do rozbudowywania tego w przyszłości.