Zdecydowałem się nie robić własnego OCR do faktur.
To jest wpis z serii 1 sukces dziennie.
W tej serii publikuję codziennie jeden sukces, który osiągnąłem poprzedniego dnia. To praktyczna implementacja podejścia z książki Show Your Work!
Codziennie zapisuję swoje postępy w SlowTracker – aplikacji do zapisywania sukcesów. Następnego dnia rano wybieram jeden lub kilka i tworzę z nich krótki post.
Uwielbiam tworzyć narzędzia. Od dziecka starałem się automatyzować co się da. Dołka w ziemi nie umiałem wykopać bez zastanowienia się jak można by tę pracę usprawnić. To jeden z najważniejszych powodów, dla których zostałem programistą.
Gdy widzę problem, który można spróbować rozwiązać za pomocą technologii, to rzucam się na to jak Kubuś Puchatek na garnuszek pysznego miodku. Dlatego gdy zobaczyłem jak moi rodzice w swojej firmie przepisują dane z faktur do arkusza kalkulacyjnego, to postanowiłem to zautomatyzować.
Technologie OCR ↗ istnieją od roku 1914. Skanowanie tablic rejestracyjnych jest jednym z praktyczniejszych zastosowań. Samo rozpoznawanie znaków jest teraz stosunkowo proste. Sam robiłem taki algorytm na zajęcia z computer vision ↗. Jednak rozpoznanie który ciąg znaków jest numerem faktury a który kwotą do zapłaty, to już trudniejsza sprawa.
Mając doświadczenie jako programista od razu sprawdziłem technologie, z których mógłbym zbudować samodzielnie takiego OCR. Miałem wcześniej doświadczenia z tematem, gdy próbowałem zrobić skanowanie paragonów na potrzeby rozliczeń domowych. Nie byłem wtedy zadowolony z żadnych dostępnych bibliotek do aplikacji mobilnych, a zewnętrzne usługi były dość drogie.
Znalazłem AWS Textract. Zrobiłem w ciągu jednego dnia PoC ↗ i stwierdziłem, że można spróbować to wdrożyć. Znalazłem też OCR od Fakturownia. Ceny zaczynały się od 0,50 zł netto za stronę. Wyglądało obiecująco.
Jednak po rozmowie z rodzicami okazało się, że jak wejdzie obowiązkowy KSeF ↗, to taki system nie będzie miał sensu. Poza tym przy 300-350 fakturach kosztowych miesięcznie (1 faktura to czasem więcej niż 1 strona) to sam koszt skanowania może wynieść kilka stówek.
Zostawiłem temat. Ale niebawem okazało się, że KSeF nie będzie obowiązkowy od 2024 roku, a faktury nadal rodzice przepisują.
Sprawdziłem jak sobie radzi AWS Textract i niestety zdarzały się błędy. Przeliczyłem koszty stworzenia oprogramowania, które radziłoby sobie z niedociągnięciami i dawało dobre rezultaty. Niestety, nie było to tanie. Zbudowanie narzędzia, w którym można porównać skan z wyciągniętymi danymi, poprawianie tych danych, utrzymanie infrastruktury, poprawki do systemu… nie wyglądało to na micro-SaaS ↗. Wyglądało to raczej na poważne przedsięwzięcie, które będzie się opłacać, gdy będę miał przynajmniej kilkudziesięciu klientów.
I nie dawało to dobrych zarobków. Z jednego klienta zarobiłbym kilkadziesiąt złotych na czysto. Miałbym sporo pracy ze sprzedażą tego narzędzia.
Mimo to postanowiłem przetestować jeszcze jak radziłby sobie Google Vision. To tańszy model, który mógłby znacznie zbić koszty jednostkowe. W połączeniu z GPT-4 potrafił wyciągnąć wszystkie potrzebne dane lepiej niż AWS Textract i za mniejszą cenę.
Zapytałem jeszcze w mojej grupie mastermind o pewne technikalia. Dostałem rzeczową odpowiedź i sugestię, aby skorzystać z wFirma, bo ponoć działało rewelacyjnie i 100% faktur poprawnie rozczytał.
To mi dało do myślenia. Nie chciałem tak łatwo porzucić idei stworzenia własnego, niewielkiego narzędzia, mającego spory potencjał, ale wiedziałem dwie rzeczy:
- To nie będzie małe narzędzie. Bo przydałby się eksport faktur, dostęp wielu użytkowników, filtrowanie, sortowanie i cholera wie co jeszcze. PoC a MVP ↗ to dwie różne rzeczy.
- To nie jest coś, co mnie jara. O ile samo automatyzowanie spoko, o tyle skanowanie faktur nie jest dla mnie sexy. Jest raczej czymś, na czym można łatwo się wyłożyć. To nie jest biznes dla mnie.
Chwilę walczyłem ze sobą, ale ostatecznie uznałem, że wypróbuję wFirma. Koszt niewielki (na dzień pisania to było 49 zł netto /mc), a jak nie będzie działać dobrze, to będę wiedział co mogę zrobić lepiej w moim narzędziu.
I podjęcie tej decyzji uznałem za duży sukces. Zbyt często rzucałem się na tworzenie narzędzia tylko dlatego, że mogłem. Wartość dla klienta mogę dostarczyć inną metodą, niż od razu tworzyć dedykowane oprogramowanie. Mogę pomóc znacznie mniejszym kosztem. Odpadają mi miesiące rozwoju oprogramowania, frustracja przy sprzedaży go do innych klientów i późniejsze utrzymanie. Za to zyskuję dużo czasu, który mogę przeznaczyć na rozwój produktu, który daje mi większą satysfakcję.
O efektach tej decyzji opowiem we wpisie Najlepszy OCR na rynku.