Kilka tygodni temu specjalistyczny sprzedawca zapytał mnie, czy moglibyśmy drukować faktury dostawy dla jego klientów końcowych z jego logo, danymi nadawcy i jego systemem numeracji. Zapytał tonem przepraszającym, który wykształca się, gdy jest się przyzwyczajonym do odmowy w takich pytaniach. U dystrybutora korzystającego z gotowego oprogramowania odpowiedź brzmiałaby: nie – a dokładniej: zgłoszenie do dostawcy oprogramowania, miejsce gdzieś w harmonogramie wydań i data wdrożenia gdzieś w przyszłym roku. Nasza odpowiedź brzmiała: od poniedziałku. Powód sięga trzydziestu ośmiu lat wstecz i w tamtym czasie nie była to strategia, ale konieczność. Kiedy zaczynaliśmy w 1988 roku, po prostu nie było dostępnego na rynku oprogramowania, które spełniałoby nasze potrzeby. Moglibyśmy kupić coś i dostosować nasze procesy do niego. Zrobiliśmy odwrotnie i dostosowaliśmy oprogramowanie do naszych procesów. Patrząc wstecz, była to najbardziej konsekwentna decyzja, jaką ta firma kiedykolwiek podjęła, i chcę być szczery: w tamtym czasie nie miałem pojęcia, jak znacząca okaże się. Ponieważ standardowy system ERP robi coś bardzo specyficznego dla firmy. Wymusza własne procesy w strukturze, którą ktoś inny zaprojektował dla przeciętnego klienta. Każde odstępstwo staje się obejściem, każde obejście kończy się osobnym arkuszem kalkulacyjnym Excela, a ostatecznie połowa firmy działa wokół własnego oprogramowania. Można to zresztą łatwo zauważyć z zewnątrz: gdy zadaje się pozornie proste pytanie, a odpowiedź brzmi, że niestety nie da się tego zrobić, ponieważ system na to nie pozwala. Żaden system nie odmawia zezwolenia. Nikt nie napisał kodu – to wszystko. Druga część nadeszła w 1995 roku, chociaż nikt wtedy nie nazywał tego chmurą. Klienci łączyli się z naszym systemem, aby sprawdzić, co mamy na stanie – w czasach, gdy zwykłym sposobem uzyskania tych informacji było oddzwonienie kogoś po sprawdzeniu magazynu. Korzyść była wtedy taka sama jak dzisiaj: nie pytasz, sam widzisz. Nic z tego nie jest spektakularne. To po prostu różnica między pracowaniem a czekaniem. Najlepszym sposobem na zrozumienie, dlaczego to ważne, jest na chwilę zmienić strony i zapytać producenta, czego tak naprawdę potrzebuje od dystrybutora. Odpowiedź rzadko brzmi „przychody”. Chcą wiedzieć, gdzie trafiają ich urządzenia, szybko i w ich formacie, nie naszym. Chcą, aby zarejestrowany projekt był faktycznie chroniony, a nie przejęty trzy tygodnie później przez listę cenową. Chcą, aby zmiana ceny dokonana z dnia na dzień przepłynęła przez wszystkie listy cenowe klientów, zamiast kończyć się renegocjacjami. Jeśli wystąpi problem z oprogramowaniem, chcą wiedzieć, których numerów seryjnych to dotyczy – a nie słyszeć, że niestety śledzimy tylko produkty na poziomie pozycji. I chcą, aby nowy produkt był dostępny do zamówienia w dniu jego ogłoszenia, wraz ze wszystkimi specyfikacjami technicznymi, a nie cztery tygodnie później, gdy ktoś gdzieś wreszcie zaktualizuje dane podstawowe. W gotowym systemie każde z tych wymagań jest albo drogim modułem dodatkowym, albo procesem, którym muszą zająć się dwie osoby ręcznie. Dla nas to pytanie do naszych własnych programistów. Dlatego producenci powierzają nam rzeczy, które inaczej robiliby sami: prekonfigurację całych gam urządzeń, tworzenie wiązek dla konkretnych klientów i dostarczanie zgodnie z planem wdrożenia, a nie według kolejności nadejścia zamówień. To nie są standardowe procesy, dlatego standardowe oprogramowanie nie może ich obsłużyć. Dla Ciebie jako sprzedawcy ten sam mechanizm działa po prostu w drugą stronę. Twoje numery produktów zamiast naszych na zamówieniu. Twoja lista cenowa, którą widzi Twój kolega, gdy dzwoni w piątek. Twoje umowy ramowe z zamówieniami częściowymi rozłożonymi na kilka miesięcy. Transmisja stanów magazynowych i cen na żywo do Twojego własnego sklepu internetowego zamiast pliku CSV, który przychodzi rano pocztą i jest już nieaktualny w południe. Numery seryjne na fakturze dostawy, abyś mógł dostarczyć swojemu klientowi końcowemu dokumentację jego urządzeń bez konieczności ręcznego przepisywania. I oczywiście faktura dostawy z Twoim logo, gdy wysyłamy bezpośrednio do Twojego klienta końcowego. Oblicz wartość choćby w jednym z tych punktów. Sprzedawca ręcznie wprowadzający dwieście zamówień miesięcznie zamiast ich przetwarzania przez interfejs, poświęca przy czterech minutach na zamówienie ponad trzynaście godzin miesięcznie na wpisywanie – ponad sto pięćdziesiąt godzin rocznie, podczas których nikt nie sprzedaje; ktoś po prostu ponownie wprowadza informacje, które już były w formie cyfrowej. A operator sklepu internetowego, którego dane o stanie magazynowym są nieaktualne o pół dnia, będzie niezawodnie sprzedawał kilka razy w miesiącu coś, czego już nie ma. Każde z tych anulowań kosztuje go nie tylko marżę na zamówieniu, ale i klienta. Prawdziwy punkt jest jednak taki, że obie strony mówią o tym samym systemie. Informacje zwrotne, których potrzebuje producent, i dane, które chcesz uzyskać, są po prostu dwoma końcami tego samego procesu. Jeśli kupisz jeden system i dołączysz do niego drugi, uzyskasz dwa systemy i arkusz Excela łączący je – a ten arkusz musi być następnie utrzymywany przez kogoś, kto powinien raczej rozmawiać z Tobą. Teraz część niewygodna, ponieważ to podejście nie jest darmowe. Budując własne oprogramowanie, ponosisz koszty rozwoju samodzielnie – przy standardowym produkcie koszty te są dzielone między tysiąc klientów. Płacimy za każdą linię kodu sami, a także płacimy za każdy błąd. Ponieważ wprowadzamy błędy, których nie byłoby w kupionym oprogramowaniu, a kiedy tak się dzieje, nie ma dostawcy, na którego moglibyśmy wskazać palcem. To niewygodne, ale jest to uczciwsze rozwiązanie: ludzie, którzy popełnili błąd, są również tymi, którzy go naprawiają. Ostatecznie jest to ta sama zasada, o której niedawno pisałem. Niezależnie od tego, czy decyzja tutaj zajmuje dzień, czy kwartał, nie zależy to od tego, jak ktoś jest sprytny, ale od tego, ile drzwi stoi między Twoim pytaniem a decyzją. Jeśli chodzi o oprogramowanie, jest dokładnie jedne. Dlatego nasza odpowiedź na nietypowe wymaganie prawie nigdy nie brzmi „nie da się tego zrobić”, ale „kiedy tego potrzebujesz?” Pamiętaj: „Żaden system nie odmawia zezwolenia. Nikt nie napisał kodu – jedyne pytanie brzmi, czy osoba, która może to zrobić, jest w tym samym budynku.”