Masz ten moment pewnie częściej, niż chciałbyś. CEO pyta o budżet nowego produktu. Sales potrzebuje widełek do oferty. Product owner chce wiedzieć, czy kolejna funkcja jeszcze mieści się w planie. A Ty patrzysz na backlog, stawki zespołu, koszty chmury i narzędzi, po czym orientujesz się, że samo „to zajmie mniej więcej trzy sprinty” już nie wystarcza.
Właśnie tu zaczyna się realna wartość pojęcia techniczny koszt wytworzenia. Dla wielu osób brzmi ono jak termin z produkcji przemysłowej i działu księgowości. W praktyce to bardzo użyteczny model myślenia o kosztach. Pozwala odpowiedzieć na proste, ale biznesowo krytyczne pytanie: ile naprawdę kosztuje nas wytworzenie konkretnego produktu, modułu albo projektu.
Dla lidera technologicznego to nie jest teoria. To sposób na obronę budżetu, pilnowanie marży i podejmowanie lepszych decyzji architektonicznych. Ten sam mechanizm, który w fabryce służy do policzenia kosztu wyprodukowania jednej sztuki wyrobu, da się przełożyć na sprinty, MVP, SaaS i development prowadzony w chmurze.
Techniczny koszt wytworzenia – klucz do rentowności Twojego projektu
Załóżmy prostą sytuację. Prowadzisz zespół, który ma zbudować nowe MVP. Zakres wydaje się rozsądny. Kilka ekranów, integracja, panel administracyjny, podstawowa analityka, wdrożenie. Na pierwszy rzut oka wszystko wygląda dobrze, dopóki ktoś nie zada pytania o rentowność.
Jeśli odpowiesz tylko kosztem pracy developerów, prawie zawsze zaniżysz obraz. Jeśli doliczysz wszystko „na oko”, możesz przeszacować projekt i przegrać decyzję inwestycyjną. Techniczny koszt wytworzenia porządkuje ten chaos. Pokazuje, które koszty są przypisane bezpośrednio do wytworzenia produktu, a które wspierają ten proces i też muszą zostać rozliczone.
Dla osób technicznych warto myśleć o TKW jak o porządnym cost modelu dla software delivery. Tak jak przy estymacji nie liczysz tylko samego kodowania, tak przy kalkulacji kosztu nie liczysz tylko godzin programistów. Dochodzą testy, środowiska, narzędzia, utrzymanie procesu wytwórczego i koszty współdzielone.
Jeśli nie liczysz TKW, to zwykle nie wyceniasz produktu. Wyceniasz tylko fragment pracy zespołu.
To ważne szczególnie wtedy, gdy przygotowujesz MVP, ofertę fixed price albo próbujesz uzasadnić sens budowy funkcji in-house zamiast kupna gotowego rozwiązania. TKW daje wspólny język dla technologii, finansów i zarządu.
W praktyce dobrze działa następująca zasada:
- Dla zarządu TKW odpowiada na pytanie, czy produkt ma szansę zarabiać.
- Dla CTO pokazuje, czy architektura i model delivery są ekonomicznie uzasadnione.
- Dla PM-a staje się punktem odniesienia do kontroli odchyleń.
- Dla salesu wyznacza dolną granicę bezpiecznej wyceny.
Jeżeli temat wyceny projektu jest u Ciebie stale źródłem tarć między biznesem a engineeringiem, pomocne bywa uporządkowanie podejścia już na etapie wyceny aplikacji webowej. Wtedy rozmowa przestaje dotyczyć samych roboczogodzin, a zaczyna dotyczyć pełnego kosztu wytworzenia wartości biznesowej.
Czym jest techniczny koszt wytworzenia i z czego się składa
Techniczny koszt wytworzenia najłatwiej zrozumieć przez prostą analogię do produktu fizycznego. Jeśli firma produkuje stół, to musi policzyć nie tylko drewno i śruby, ale też pracę stolarza, energię zużytą przy obróbce oraz część kosztów funkcjonowania wydziału produkcyjnego. Dopiero wtedy wiadomo, ile naprawdę kosztuje wytworzenie gotowego wyrobu.
Zgodnie ze standardami stosowanymi w Polsce, typowy zakres pozycji kalkulacyjnych TKW obejmuje: materiały bezpośrednie, paliwo i energię na cele technologiczne, koszty zakupu, płace bezpośrednie, narzuty na płace, inne koszty bezpośrednie oraz koszty wydziałowe. Suma tych pozycji stanowi TKW. W 2023 roku średni TKW w polskim przetwórstwie przemysłowym stanowił około 75-85% kosztów własnych sprzedaży według opisu przywołanego przez definicję TKW w controlling-24.
Koszty bezpośrednie
To koszty, które możesz przypisać do konkretnego produktu bez większej dyskusji. W produkcji będą to surowce i robocizna. W software ten odpowiednik pojawi się później, ale logika pozostaje identyczna.
Najprościej rozumieć je tak:
- Materiał zużyty do wykonania produktu. Dla stołu będzie to drewno, lakier i okucia.
- Praca wykonana bezpośrednio przy produkcie. Czas stolarza, operatora, montera.
- Inne wydatki powiązane z konkretnym wyrobem. Na przykład energia zużyta ściśle przy obróbce.
Jeśli koszt znika razem z decyzją „nie produkujemy tej sztuki”, zwykle jest kosztem bezpośrednim.
Koszty pośrednie
Tu zaczyna się częste nieporozumienie. Koszty pośrednie nie są mniej realne. Są tylko trudniejsze do przypisania do jednej jednostki produktu. Firma nadal je ponosi, bo bez nich proces nie działa.
Do tej grupy należą między innymi:
| Obszar | Przykład |
|---|---|
| Utrzymanie wydziału | czynsz za halę, media wspólne |
| Sprzęt i park maszynowy | amortyzacja maszyn i narzędzi |
| Organizacja pracy | nadzór produkcji, obsługa wydziału |
Praktyczna zasada: koszt pośredni nie znika dlatego, że trudniej go przypisać. On po prostu wymaga sensownego klucza rozliczeniowego.
To dokładnie ten sam problem, który pojawia się poza przemysłem. Gdy próbujesz oszacować całkowity wydatek związany z importem pojazdu, nie wystarczy policzyć ceny zakupu auta. Dochodzą kolejne elementy procesu, dlatego przydaje się spojrzenie całościowe, podobne do tego, jakie opisuje materiał o koszcie sprowadzenia auta z USA. TKW działa według tej samej logiki. Sam „główny koszt” prawie nigdy nie pokazuje pełnego obrazu.
Gdzie ludzie mylą TKW
Najczęstszy błąd polega na wrzuceniu wszystkich kosztów do jednego worka albo przeciwnie, na nieuwzględnieniu kosztów wspólnych wcale. Oba podejścia zniekształcają rentowność.
W praktyce warto zapamiętać trzy poziomy:
- TKW obejmuje koszty związane z wytworzeniem.
- Po dodaniu kosztów zarządu otrzymujesz zakładowy koszt wytworzenia.
- Po doliczeniu kosztów sprzedaży dostajesz całkowity koszt własny sprzedaży.
To rozróżnienie ma później ogromne znaczenie w IT, bo wiele zespołów miesza koszt budowy produktu z kosztem funkcjonowania całej organizacji.
Jak obliczyć techniczny koszt wytworzenia – wzory i metody kalkulacji
Sama formuła jest prosta: TKW = koszty bezpośrednie + odpowiednio przypisane koszty pośrednie. Trudność nie leży we wzorze. Leży w przypisaniu kosztów pośrednich do konkretnego produktu albo zlecenia w sposób, który da się obronić.
Najprostszy wzór
W praktyce kalkulacja zwykle wygląda tak:
- identyfikujesz koszty bezpośrednie,
- zbierasz pulę kosztów pośrednich dla wydziału lub procesu,
- wybierasz klucz podziałowy,
- rozliczasz część kosztów pośrednich na jednostkę produktu.
Klucz podziałowy to po prostu sposób, według którego dzielisz wspólny koszt. W przemyśle najczęściej stosuje się maszynogodziny albo roboczogodziny. Jeśli dwa produkty korzystają z tej samej maszyny, to logiczne jest przypisanie większej części kosztów temu, który zajmował ją dłużej.
Przykład bez liczb szczegółowych
Załóżmy, że zakład wytwarza dwa typy wyrobów. Jeden wymaga długiej obróbki maszynowej, drugi głównie pracy ręcznej. Jeśli rozdzielisz wszystkie koszty pośrednie wyłącznie według liczby sztuk, wynik będzie mylący. Produkt prosty może zostać sztucznie obciążony kosztami, których faktycznie nie generował.
Lepsze podejście wygląda tak:
- dla kosztów związanych z parkiem maszynowym stosujesz maszynogodziny,
- dla kosztów bardziej zależnych od pracy ludzi stosujesz roboczogodziny,
- dla wybranych kosztów możesz użyć innego klucza, jeśli lepiej oddaje rzeczywistość operacyjną.
To nie jest matematyka dla samej matematyki. Chodzi o to, żeby koszt odzwierciedlał sposób zużycia zasobów.
Zły klucz podziałowy nie psuje tylko raportu. Psuje decyzje o cenie, marży i priorytetach produkcyjnych.
Co automatyzują systemy ERP
W nowoczesnych firmach ręczne liczenie TKW szybko przestaje działać. Dane są rozproszone między produkcją, magazynem, księgowością i raportowaniem czasu. Dlatego firmy korzystają z ERP.
Systemy takie jak VENDO.ERP czy Streamsoft Prestiż automatycznie pobierają dane z systemów MES i księgowości, aby wyliczać TKW dla każdej jednostki produktu. Według danych opisanych w materiale o obliczaniu TKW w systemach ERP, w 2022 roku TKW w polskim przemyśle wzrósł średnio o 18% rok do roku z powodu inflacji i cen surowców, a przedsiębiorstwa stosujące ERP do monitorowania kosztów były w stanie zredukować TKW średnio o 12%.
To ważna lekcja także dla software delivery. Gdy zespół opiera się na arkuszach i ręcznych dopiskach, kontrola kosztu pojawia się za późno. Kiedy dane o czasie pracy, infrastrukturze i zmianach zakresu są spięte w jeden model, koszt widać wcześniej.
Jak myśleć o kalkulacji jako lider techniczny
Dla CTO użyteczne jest potraktowanie TKW jak rozszerzonej estymacji. Nie pytasz wyłącznie „ile potrwa”, ale również:
- Jakie zasoby są zużywane bezpośrednio
- Jakie koszty współdzielone trzeba przypisać
- Jaki klucz rozliczenia jest uczciwy
- Kiedy aktualizować kalkulację po zmianie zakresu
Jeżeli chcesz zestawić to z praktyką projektową po stronie software, dobrym uzupełnieniem jest podejście opisane w materiale o wycenie projektu informatycznego. Tam widać, jak techniczna estymacja spotyka się z modelem kosztowym.
Techniczny koszt wytworzenia w IT – kalkulacja dla oprogramowania i MVP
W software house'ie albo dziale produktowym nikt nie kupuje stali ani nie rozlicza pracy tokarki. To jednak nie znaczy, że techniczny koszt wytworzenia przestaje mieć sens. Po prostu zmieniają się jego odpowiedniki.
Jak przetłumaczyć język produkcji na język IT
W produkcji masz materiały, pracę bezpośrednią i koszty wydziałowe. W IT możesz przełożyć to następująco:
| Produkcja | IT |
|---|---|
| materiały bezpośrednie | płatne API, licencje kupione wyłącznie pod projekt, konkretne usługi cloud użyte przez dany produkt |
| płace bezpośrednie | czas developerów, QA, analityków, UX przypisanych do projektu |
| koszty wydziałowe | narzędzia wspólne, DevOps, utrzymanie środowisk, sprzęt, biuro, proces delivery |
To proste, ale bardzo skuteczne. „Maszynogodzina” w świecie software często staje się deweloperogodziną, godziną zespołu albo innym miernikiem zużycia wspólnych zasobów.
Jak policzyć TKW MVP bez fałszywej precyzji
Załóżmy, że budujesz trzymiesięczne MVP. W modelu kosztowym chcesz oddzielić koszty bezpośrednie od pośrednich.
Do kosztów bezpośrednich zwykle zaliczysz:
- czas programistów pracujących nad backlogiem produktu,
- czas QA wykonującego testy tego rozwiązania,
- pracę analityka lub projektanta, jeśli działają bezpośrednio dla tego projektu,
- licencje albo integracje zakupione wyłącznie pod to MVP.
Koszty pośrednie będą wyglądały inaczej:
- współdzielone środowiska AWS lub Azure,
- GitHub, Jira, Slack, monitoring, repozytoria artefaktów,
- czas DevOps utrzymującego pipeline i środowiska,
- amortyzacja laptopów, koszt przestrzeni biurowej, administracja.
Kluczowe pytanie brzmi: jak rozdzielić koszty pośrednie? Najpraktyczniej użyć klucza, który zespół już rozumie. W IT często sprawdzają się godziny pracy przypisane do projektu, udział zespołu w wykorzystaniu środowisk albo liczba aktywnych sprintów. Nie chodzi o idealną teorię, tylko o model, który jest spójny i powtarzalny.
Jeśli ten sam projekt wygląda rentownie tylko dlatego, że „zapomniałeś” o koszcie CI/CD, DevOps i środowisk, to nie masz marży. Masz złudzenie marży.
Potrzebujesz precyzyjnej wyceny projektu IT?
Skontaktuj się z nami, aby oszacować techniczny koszt wytworzenia Twojego oprogramowania. Nasi eksperci pomogą Ci zoptymalizować budżet i zapewnić rentowność inwestycji.
On-premise, cloud i serverless
Tu TKW mocno zależy od architektury. W modelu on-premise część kosztów pojawia się wcześniej i mocniej obciąża start projektu. W modelu chmurowym częściej przesuwasz wydatki do OPEX i płacisz bardziej za realne zużycie.
Według opisu zawartego w materiale o opłacalności chmury, w modelu on-premise początkowe koszty wdrożenia mogą podnieść całkowity koszt posiadania o 30% względem chmury z powodu ryzyka nadmiarowego zakupu zasobów. Ten sam materiał wskazuje też, że w modelu serverless płacisz za rzeczywiste wykonania funkcji, a tradycyjne maszyny wirtualne mogą generować nawet 70% kosztów na niewykorzystane zasoby.
Dla MVP to ma ogromne znaczenie. Jeśli obciążenie jest nieprzewidywalne, utrzymywanie stałej infrastruktury „na wszelki wypadek” często zniekształca TKW. W serverless część kosztu staje się bardziej zmienna i bliższa faktycznemu użyciu produktu. To nie oznacza, że serverless zawsze wygrywa, ale wymusza lepsze myślenie o koszcie bezczynności.
Co zwykle pomija zespół
Najczęściej pomijane pozycje w IT to:
- Koszt jakości. Testy automatyczne, review, poprawki po wdrożeniu.
- Koszt operacyjny procesu. Pipeline, release management, monitoring.
- Koszt zmian zakresu. Każda „mała rzecz” dodana po drodze przesuwa TKW.
- Koszt utrzymania decyzji architektonicznych. Tani start może oznaczać drogie utrzymanie.
Jeśli planujesz wczesny produkt, warto zestawić tę perspektywę z praktycznym spojrzeniem na koszt stworzenia MVP. Wtedy łatwiej rozmawiać nie tylko o budżecie wejścia, ale o tym, ile naprawdę kosztuje wytworzenie pierwszej wersji, która ma sens biznesowy.
TKW w praktyce – wskazówki dla CTO i Project Managera
Lider technologiczny nie potrzebuje TKW po to, żeby mieć ładniejszy arkusz. Potrzebuje go po to, żeby podejmować lepsze decyzje. Kiedy koszt jest policzony sensownie, nagle łatwiej rozstrzygnąć, czy projekt ma zdrową marżę, czy backlog nie puchnie zbyt drogo i czy model staffingowy dalej się spina.
Gdzie TKW daje największą przewagę
Najbardziej praktyczne zastosowania są cztery.
- Wycena oferty. TKW wyznacza dolną granicę, poniżej której projekt zaczyna zjadać marżę.
- Kontrola sprintów. Jeśli po każdym sprincie porównujesz koszt planowany do rzeczywistego, wcześniej zobaczysz odchylenie.
- Decyzje technologiczne. Możesz porównywać koszt build versus buy bez opierania się na intuicji.
- Rozmowa z finansami. Znika konflikt „tech mówi jedno, finanse drugie”, bo obie strony patrzą na ten sam model.
Body leasing i problem ukrytego kosztu
To szczególnie ważne przy modelach mieszanych. Według danych opisanych w materiale o TKW i podziale kosztów w przedsiębiorstwie, 65% firm IT w Polsce korzysta z body leasingu, a 42% zgłasza problemy z prawidłową kalkulacją TKW, co prowadzi do strat marżowych rzędu 10-18%. Ten sam materiał wskazuje stawki specjalistów na poziomie 120-200 zł za godzinę.
To dobrze pokazuje, gdzie liderzy się wykładają. Sama stawka specjalisty nie jest jeszcze pełnym kosztem wytworzenia. Trzeba doliczyć wdrożenie do procesu, narzędzia, zarządzanie, czas koordynacji i wpływ na koszty pośrednie projektu. Jeśli tego nie zrobisz, body leasing może wyglądać tanio tylko na slajdzie.
Dla PM-a najgroźniejszy jest projekt, który wygląda dobrze w estymacji, a traci rentowność dopiero po kilku sprintach.
Jak wdrożyć TKW bez nadmiernej biurokracji
Nie musisz budować wielkiego modelu controllingowego. Na start wystarczy kilka zasad:
- Zdefiniuj katalog kosztów bezpośrednich dla projektu.
- Ustal pulę kosztów pośrednich, które będą rozliczane na projekty.
- Wybierz jeden klucz podziałowy i stosuj go konsekwentnie.
- Aktualizuj kalkulację cyklicznie, a nie dopiero po zakończeniu projektu.
- Pokazuj odchylenia razem z przyczyną, a nie tylko samą liczbę.
Jeśli chcesz, żeby działało to operacyjnie, a nie tylko na poziomie deklaracji, dobrze jest spiąć model kosztowy z praktyką delivery i raportowania. Właśnie dlatego pomocne bywa uporządkowane zarządzanie projektami IT, w którym koszt, zakres i tempo pracy są widoczne w jednym rytmie zarządczym.
Podsumowanie – Jak TKW wpływa na wycenę i strategię produktu
Techniczny koszt wytworzenia nie jest pojęciem zarezerwowanym dla fabryk. To uniwersalny sposób myślenia o koszcie powstania produktu. W świecie IT pomaga przestać patrzeć wyłącznie na godziny programistów i zacząć widzieć pełny koszt dostarczenia działającego rozwiązania.
Najważniejsza zmiana jest mentalna. Gdy liczysz TKW, przestajesz pytać tylko „ile kosztuje development”, a zaczynasz pytać „ile kosztuje wytworzenie i dostarczenie wartości”. To dużo trafniejsze pytanie dla CTO, Head of Engineering i Project Managera.
Dobrze policzony techniczny koszt wytworzenia wspiera trzy obszary jednocześnie. Pozwala lepiej wyceniać projekt. Ułatwia kontrolę marży w trakcie delivery. Daje też podstawę do decyzji architektonicznych i kadrowych, które wcześniej często opierały się głównie na doświadczeniu i intuicji.
To właśnie dlatego TKW warto traktować jak narzędzie zarządcze, a nie obowiązek księgowy. Jeśli rozumiesz, które koszty są bezpośrednie, które pośrednie i jak je uczciwie przypisywać, łatwiej bronisz budżetu, szybciej wykrywasz odchylenia i podejmujesz spokojniejsze decyzje produktowe.
Dla firmy technologicznej to oznacza jedno. Lepsza kontrola kosztu nie spowalnia rozwoju. Ona daje warunki, żeby rozwijać produkt bez utraty rentowności.
Jeśli chcesz uporządkować wycenę produktu, MVP albo całego procesu delivery, warto porozmawiać z zespołem Develos Ratajczak Gajos S.K.A.. Pomagają przełożyć wymagania biznesowe i techniczne na realny model kosztowy, dzięki któremu łatwiej ocenić opłacalność inwestycji, dobrać architekturę i zaplanować stabilny rozwój oprogramowania.
