Podczas preinkubacji w TechnoBoard wiele razy pojawiają się obawy wśród projektodawców, w jaki sposób zbudować swoją wartość aportową, aby podwyższyć swoją pozycję negocjacyjną wobec funduszu, zwłaszcza gdy dany fundusz nie stosuje takich mechanizmów jak agio czy wycena jest wykonywana w metodzie odtworzeniowej.
Wiele razy zauważyłem również, że znaczna część osób jest nieświadomych posiadanych składników majątkowych, a problem bardzo często leży tylko po stronie dokumentacyjnej, a nie po stronie posiadanych „rzeczy”. Czym jest, zatem aport, jak go definiować? Jak udokumentować pojedyncze jego składniki? Postaram się odpowiedzieć na te pytania w niniejszym artykule.
Zgodnie z definicją ustawową, aport to „świadczenie na pokrycie kapitału zakładowego lub akcyjnego, wniesione do spółki kapitałowej w postaci niepieniężnej”. Jak to rozumieć? Najlepiej ująć to w ten sposób – jeśli posiadam jakiś składnik majątku, który „da się dotknąć”, teoretycznie może on być takim składnikiem aportowym. Najłatwiej „dotknąć” środki trwałe, które mogą być wniesione (np. jakiś sprzęt), tutaj sprawa jest dosyć prosta. Ale w startupie często nie ma takich twardych składników, zazwyczaj ich ilość jest ograniczona np. do określonej liczby posiadanych komputerów, ew. jakichś elementów wyposażenia firm i to często pod warunkiem, że już pracujecie nad projektem już w ramach przedsiębiorstwa (np. własnej działalności gospodarczej).
Od razu zapytacie, co z definicją wartości niematerialnych i prawnych lub rzeczy, których teoretycznie „nie da się dotknąć”? Odpowiedź jest prosta. W przypadku oprogramowania również da się „dotknąć” te składniki, ale trzeba spojrzeć na ich stronę opisową (dokumentując np. prace rozwojowe czy też dokumentując ich zakup). Bardzo ważne jest zrozumienie definicji wartości niematerialnych i prawnych (patrz linki na końcu tekstu). To trochę jak opisywanie samochodu – wyszczególniając jego poszczególne składniki, które składają się na całą jego postać (koła, szyby, silnik, itp.), wraz ze wskazaniem przydatności, (czyli w całości samochód „jeździ”, pojedynczy składnik robi to i to).
Na przykład, dobrym sposobem udokumentowania prac nad aplikacją jest wskazanie rozpiski prac: wydruk postępu prac z jakiegoś systemu do zarządzania projektami (redmine, teambox lub podobny), czy stworzenie własnego WBS prac ze wskazaniem kto i w jakim czasie pracował nad daną rzeczą oraz przypisanie danym fragmentom WBS’a repozytorium z odpowiednimi załącznikami dokumentującymi, wskazanie literalnie kodu źródłowego, wskazanie długości kodu (można zliczyć ilość linii, ile roboczogodzin zajęło jej wykonanie, opisać czy były robione optymalizacje tego kodu, pod jaką postacią, ubrać to w raport itp.), dokonanie opisu technicznego tej aplikacji (specyfikacji technicznej, opisu modułów, instrukcji systemowej itp.). Tutaj sprawa wydaje się na pozór łatwa, ale wymaga dużego zaangażowania i systematyczności w dokumentacji swojego zaangażowania, co nie jest łatwe przy niesprzyjających warunkach budowania takiej aplikacji. Na pocieszenie tylko powiem, że zawsze taka systematyczność procentuje – w końcu dokumentujecie swoją wartość, a więc można powiedzieć, że niebezpośrednio, ale zarabiacie na swojej pracy.
Z dokumentacją know-how jest trochę trudniej. Taka dokumentacja techniczna know-how powinna umożliwiać dokładne skopiowanie tego, co w obszarze Waszego know-how definiujecie. Ja najczęściej porównuję opis know-how do książki kucharskiej – biorąc pod uwagę przepis na ciasto wiecie, jak to ciasto wykonać i z dużą dozą prawdopodobieństwa to ciasto wykonacie prawidłowo (odtworzycie). Analogicznie powinna być przygotowana dokumentacja techniczna z obszaru know-how, które chcecie wnieść, jako składnik aportu. Know-how w głowie twórcy dla rzeczoznawcy nie będzie przedstawiał żadnej wartości. Pamiętajcie też, że rzeczoznawca majątkowy będzie odwoływał się do dokumentów potwierdzających dany nakład pracy poświęcony na wytworzenie danego składnika (lub np. dokumentów zakupu, jeśli coś było zakupione). Hasłem kluczem zarówno przy wartościach niematerialnych i prawnych, a w szczególności know-how jest dokumentacja techniczna, która powinna być wykonana po prostu w sposób rzetelny i potwierdzający, że Wasze składniki faktycznie są odpowiednio warte.
Jak wynika z naszych doświadczeń z poprzednich okresów inwestycyjnych, biegli mogli (ale nie musieli) uznać takie składniki aportu, jak na przykład:
- wszelkiego rodzaju dokumentacje techniczne, które w metodzie odtworzeniowej stanowią równowartość kosztu wiedzy;
- dokumentacja wiedzy technicznej, różnej maści opisy i dokumenty definiujące np. prototyp;
- dokumentacje funkcjonalności, dokumenty opisujące wnioski z testów, wdrożeń itp., również w obszarze know-how;
- know-how udokumentowany technicznie dot. Klientów docelowych, rynku w powiązaniu z planowanym do stworzenia produktem;
- prototyp, kod, gotowa aplikacja, inne elementy, które można „fizycznie dotknąć”;
- wszelkiego rodzaju projekty związane z planowanym produktem, np. projekt systemu, projekt layout, itp. lub inne wersje systemów w zależności od stopnia rozwoju (alfa, beta, live/RC);
- różnego rodzaju specyfikacje związane z planowanym produktem, np. specyfikacje funkcjonalne;
- opisana architektura danego produktu, np. architektura systemu, kod;
- prawa do domen;
- prawa do zastrzeżonych znaków towarowych;
- półprodukty, składniki systemu (np. elementy graficzne, dźwiękowe);
- know-how wynikający z konsultacji eksperckich pod postacią dokumentacji technicznej;
- oraz wiele innych (listę takich przykładowych składników zamieściliśmy w naszym podręczniku 5 kroków – patrz dział Creative Commons mamstartup.pl).
Dlatego przygotowując odpowiednią dokumentację aportową, powinna funkcjonować zasada „chwalę się tym, co posiadam, zapisuję i notuję, dokumentuję”. To, w jaki sposób ostatecznie udokumentujecie swoją „road mapę” aportów – pozostaje w Waszych kompetencjach.
Chciałbym zaznaczyć, że ścieżki tej drogi (jak i mechanizmy inwestycji) są bardzo różne. W tym artykule odniosłem się tylko do jednej ze strategii i pokazałem Wam jak uzbroić się w dodatkowe argumenty w rozmowie z funduszem, ale równie dobrze skuteczną dla Was drogą i równie efektywną będzie np. domówienie się z inwestorem na mechanizm agio, czy też wycena metodą dochodową. Wszystko zależy od tego, co ustalicie z inwestorem oraz jakie możliwości doboru metody wyceny będą akceptowalne.
Grzegorz Sperczyński
Członek Rady Nadzorczej Internet Group SA. Współwłaściciel eFund SA oraz pośrednio grupy kapitałowej, w której jest m.in. fundusz zalążkowy TechnoBoard. Od czerwca 2011 jest Członkiem Komitetu Inwestycyjnego w TechnoBoard Sp. z o.o. oraz Efund SA. W TechnoBoard aktywnie zaangażowany w procesy preinkubacji, piastując funkcję Kierownika Preinkubacji. W trakcie kariery zawodowej pomógł operacyjnie przetworzyć ponad 1200 projektów typu start-up.
