Aplikacje internetowe dla firm i dedykowane oprogramowanie coraz częściej powstają z wykorzystaniem narzędzi AI. Czy to oznacza, że każdy może zbudować aplikację firmową z pomocą AI? Wyjaśniamy, gdzie przebiega granica między aplikacją zrobioną na własny użytek a systemem, który ma realnie działać w firmie - obsługiwać procesy, dane, integracje i odpowiedzialność biznesową. Pokazujemy, kiedy AI dla firm jest realnym wsparciem, a kiedy zaczyna generować ryzyko
Darmowe prompty pomogą Ci jasno opisać potrzeby i zakres projektu
Pobierz promptyJeszcze kilka lat temu stworzenie aplikacji dla firmy oznaczało projekt za 200-300 tysięcy, a czasem nawet pół miliona złotych czy milion. Dziś jesteśmy w momencie, w którym próg wejścia do tworzenia aplikacji spada do minimum. Masz pomysł, masz narzędzia oparte o AI, masz trochę determinacji i jesteś w stanie zbudować coś, co technicznie działa. Nie musisz być programistą ani programistką, nie musisz zatrudniać zespołu, nie musisz wydawać kilkuset tysięcy złotych. I właśnie dlatego coraz częściej pojawia się pytanie czy AI faktycznie wystarczy, żeby zbudować aplikację dla firmy. I gdzie jest granica między tym, co działa na własny użytek, a tym, co ma działać w organizacji.
Bo czym innym jest aplikacja zrobiona samodzielnie, a czym innym system, który ma realnie funkcjonować w firmie. Obsługiwać procesy, ludzi i dane, integrować się z innymi narzędziami i zwyczajnie dowozić codzienną pracę. I właśnie o tej różnicy chcę dzisiaj porozmawiać.
Załóżmy, że na początku budujesz aplikację dla jednego konkretnego procesu. Coś prostego, jednorazowego.
Na start wszystko działa dobrze. Z czasem jednak zaczyna korzystać z niej coraz więcej osób, pojawiają się nowe potrzeby i nowe oczekiwania. I naturalnie rodzi się pomysł, żeby tę aplikację rozwijać.
Ktoś zgłasza poprawkę, ktoś cenową funkcję, ktoś inny potrzebuje zmiany w logice działania. I w pewnym momencie tych potrzeb jest już na tyle dużo, że to ty zaczynasz być tak zwanym wąskim gardłem i jedyną przeszkodą ku innowacji w twojej organizacji, bo to ty znasz całą logikę aplikacji, którą zbudowałeś z wykorzystaniem AI. To ty pamiętasz założenia, które były w głowie albo zapisane w promptach do AI.
Każda decyzja, każda zmiana i każdy problem zaczynają przechodzić przez ciebie. Naturalną konsekwencją tego stanu rzeczy jest próba uporządkowania tematu albo przekazania aplikacji dalej do utrzymania i rozwoju. I tutaj często pojawia się zderzenie ze ścianą.
Gdy próbujesz wesprzeć się z software house'em, zewnętrzny zespół zaczyna pytać o dokumentację, o środowiska testowe, o strukturę kodu, o standardy jakości, jakie były wykorzystywane, czyli o rzeczy, o których na etapie szybkiego budowania aplikacji często w ogóle się nie myśli. I to jest też moment, w którym wychodzi dług technologiczny. Nie pojawia się on nagle, on był tam od samego początku.
Po prostu przez jakiś czas dało się go ignorować no i wszyscy byli oczarowani aplikacją, która powstała i słusznie. Ale potem wraca za każdym razem ten dług technologiczny, gdy próbujesz coś rozwinąć albo zmienić. Aplikacja, która wcześniej była tylko wsparciem, zaczyna być traktowana jak element infrastruktury firmy, nawet jeśli nikt od początku takiej nie projektował.
Pojawia się potrzeba wysyłania danych do innych systemów, pobierania danych z ERP-a, CRM-a czy WMS-a, synchronizacji informacji pomiędzy różnymi narzędziami. I bardzo szybko wychodzi, że integracja to nie jest już tylko podpięcie się pod jakieś jedno z iluś API, ale uprawnienia, logi, obsługa błędów i bezpieczeństwo danych. Im więcej realnych procesów i danych jest po drodze, tym większe są konsekwencje ewentualnych błędów.
Dobrym przykładem jest prosta wtyczka do Chroma. Jeśli poprosimy AI o stworzenie takiej wtyczki, to oczywiście ją otrzymamy. Możemy dokładniej opisać jak ma działać, jaki problem ma rozwiązywać, tylko, że jeśli nie damy AI kontekstu technicznego, to bardzo łatwo rozwiązanie, które zadziała na start, ale nie da się sensownie rozwijać w przyszłości.
I nagle okazuje się, że potrzebna jest zmiana technologii. Teoretycznie można napisać wszystko od nowa, tylko to z reguły oznacza czas, migrację danych no i powoduje przez to właśnie dodatkowe ryzyko. No i również temat bezpieczeństwa robi się krytyczny, bo kiedy pracujesz na realnych danych i realnych procesach, nie ma już miejsca na eksperymenty bez konsekwencji.
Trzeba wiedzieć, gdzie te dane są, kto ma do nich dostęp, jak są zabezpieczone i co się stanie, jeśli coś pójdzie nie tak. I tutaj AI ma swoje ograniczenia, szczególnie wtedy, gdy w grę wchodzą dane produkcyjne i odpowiedzialność biznesowa.
AI daje dziś ogromne możliwości i byłoby błędem z nich nie korzystać. To świetne narzędzie do testowania pomysłów, budowania prototypów i szybkiego sprawdzania kierunku. Kluczowe pytanie już nie brzmi, czy korzystać, tylko jak korzystać i w jakim kontekście się wspierać AI. Inaczej podchodzi się do narzędzia robionego dla siebie, a inaczej do systemu, który ma realnie działać w firmie, gdzie pracuje ileś osób, rozwijać się i integrować z innymi rozwiązaniami.
Oczywiście da się zbudować także aplikację firmową w oparciu o AI, ale wymaga to świadomego, procesowego podejścia. Jeśli ten temat Cię interesuje, wróć do dwóch poprzednich odcinków, bo tam rozkładam to podejście na czynniki pierwsze. W takich sytuacjach bardzo szybko okazuje się, że kluczowe nie jest już samo narzędzie, ale koszt decyzji, czas, który na to poświęcasz, odpowiedzialność, którą bierzesz na siebie i ryzyko, które pojawia się wtedy, gdy coś przestaje działać na danych produkcyjnych.
Jednocześnie uczciwie trzeba powiedzieć też o plusach. Jeśli interesuje Cię interfejs, wygląd, konkretne flow użytkownika czy szybkie prototypowanie, to dziś naprawdę wiele rzeczy można wygenerować znacznie szybciej niż dało się to zrobić kiedyś. Możesz sprawdzić pomysł, zobaczyć jak coś może wyglądać, przetestować koncepcje bez angażowania dużych zespołów i dużych budżetów, z zaangażowaniem swojego czasu i swojej energii.
Dodatkową wartością jest też to, że próbując samodzielnie coś zbudować z pomocą AI zaczynasz lepiej rozumieć, z czym mierzą się programiści i programistki. Łatwiej wtedy zrozumieć, dlaczego coś trwa, dlaczego coś jest trudne i z czego wynikają konkretne decyzje techniczne. I na koniec zostaje najważniejsze pytanie.
Czy w Twoim konkretnym przypadku chodzi o naukę i eksperyment, czy o szybkie dowiedzenie efektu biznesowego? Bo odpowiedź na to pytanie bardzo często decyduje o tym, czy budowanie aplikacji samodzielnie ma sens. To nie jest pytanie, czy się da, bo oczywiście, że się da. To jest pytanie, czy w tym kontekście, w którym aktualnie się znajdujesz, w tej sytuacji, w której się znajdujesz, to się zwyczajnie opłaca.
Podsumowując, ja zalecam podchodzić do tego w ten sposób, że drobne projekty realizowane na własny użytek warto zrobić, czy to z ciekawości, czy to dla poznania możliwości, ale duże, skomplikowane projekty warto zorganizować, czy mieć pod kontrolą zespołu technicznego, który będzie te prace dokumentował i w pewnym sensie challenge'ował AI, czy ten kod, który powstaje ma dokumentację, ma testy, czy nadaje się do rozwoju w przyszłości i w skrócie, czy ma ręce i nogi, po prostu.
Darmowe prompty pomogą Ci jasno opisać potrzeby i zakres projektu
Pobierz prompty
Wyślij zapytanie. Omówimy zakres i Twoje cele biznesowe.
Nie musisz mieć gotowej specyfikacji. Odezwiemy się, doprecyzujemy zakres i pomożemy ustalić priorytety, żeby szybko przejść do działania.
Po krótkiej rozmowie zaproponujemy kolejne kroki:
1. Umówimy się na spotkanie online, by pogłębić temat,
2. Lub od razu na wizytę lokalną, aby lepiej poznać Twój biznes w praktyce.