Wprowadzenie do tematu

Dla człowieka, który ma tylko młotek, każdy problem wygląda jak gwuść. W IT oznacza to jedno. Firmy często próbują rozwiązać każdy napotkany problem jedną technologią. A to kończy się kosztami, opóźnieniami i frustracją. I przede wszystkim często nierozwiązaniem właściwego problemu. W tym odcinku opowiem, czym jest tak zwane prawo młotka, czy inaczej nazywana pułapka złotego młotka. Jak jej unikać, jak logicznie dobierać technologię do realnych problemów biznesowych. Nie przedłużam, serdecznie zapraszam. 

Prawo młotka w IT

Cześć, dzień dobry, z tej strony Grzegorz Tabor, a to jest podcast IT i biznes, gdzie jako dyrektor technologiczny pomagam przedsiębiorcom i menedżerom realizować projekty IT, które wspierają cele biznesowe skutecznie i w terminie. Jeśli napotykasz na swojej drodze wyzwania i potrzeby wsparcia twojego biznesu świadomie z użyciem technologii, ten podcast jest dla ciebie. Cześć, dzień dobry, witam serdecznie w odcinku 68 pod tytułem Pułapka złotego młotka. Czym jest w IT i jak się jej wystrzegać. I dzisiaj porozmawiamy sobie o tym, jak to jest, że często na problem A próbujemy znaleźć rozwiązanie B, które kompletnie, czy dopasować rozwiązanie B, które kompletnie nie pasuje do problemu A. W IT często zachwycamy się jakimś, jakąś jedną technologią, jednym frameworkiem, czy jakąś jedną określoną architekturą, czyli wszyscy mówią, o jak zrobisz sobie mikroserwisy, będzie super, albo jak wdrożysz Magento, to będzie najlepszą technologią, albo dla platform B2B, albo na przykład, o AI, AI to jest w ogóle potęga. No i staramy się używać tej technologii wszędzie, niezależnie od kontekstu. Czyli kilka takich przykładów z życia.

Przykłady nadużywania jednej technologii

Klient pojawia się, gdzie nie działa mu wyszukiwarka. Hmm, może byśmy skorzystali tu z AI. Nie zastanawiamy się nad tym, czy można by wdrożyć jakiś lepszy po prostu mechanizm wyszukiwania za nim wsparcie AI, tylko zróbmy to AI. Chcemy zupełnie nowy, ogromny system pokrywający pracę wielu działów. Hmm, może uda się go zrobić taniej z wykorzystaniem istniejącego ERP-a. To nic, że wszyscy narzekają na tego ERP-a i jest on nieczytelny dla większości działów, no ale może spróbujmy, bo ten ERP to jest ten nasz właśnie ukochany młotek, ukochane narzędzie. Być może mamy błąd procesowy w firmie. Hmm, może nowa platforma i wykorzystanie jej w tym nam pomoże, żeby ten błąd procesowy rozwiązać. Może tak, może nie.

Dlaczego to jest problem dla biznesu?

I w IT, i w biznesie tak naprawdę. Jeżeli technologia nie jest dopasowana do biznesu i nie wynika z potrzeb tylko z mody, no jest duża szansa, że ona nie wesprze realnie tego biznesu. Albo że ludzie nie będą chcieli z niej korzystać, bo nie będą widzieli w tym sensu.

Ryzyka uzależnienia od jednej technologii

Wzrost kosztów utrzymania, czyli trudniejsza obsługa danej technologii, czy platformy, czy systemu, z którego korzystacie, powoduje często też konieczność zatrudnienia specjalistów od tego konkretnego narzędzia. Czy dodatkowych specjalistów, bo to mam na myśli. Ryzyko uzależnienia od jednej platformy, czy od jednego dostawcy. Co często nie kończy się dobrze, jeżeli wszystko jest zrealizowane, czy to przez jedną firmę, czy jednego dostawcę, czy też przede wszystkim przez jedno rozwiązanie, jedną platformę. I coś, czego nie widać od razu, to wolniejsza innowacja. Czyli działanie w jednej technologii bardzo często i rozwiązywanie nią wszelkich problemów biznesowych, które napotykamy, powoduje, że siłą rzeczy firma wolniej wdraża innowacje.

Perspektywa firm produktowych

To może być grzechem firm produktowych, czyli takich, które sprzedają jedno określone rozwiązanie. No bo skoro pojawia się klient i chce kupić platformę B2B i trafił do firmy sprzedającej tylko platformę B2B albo rozwiązania dla e-commerce, no to pewnie ta firma powinna mu sprzedać tę platformę B2B. Prawda? No właśnie nie zawsze. Bo jeśli nie przeprowadzi ta firma konkretnego wywiadu z klientem, nie upewni się, że faktycznie platforma B2B rozwiąże jego konkretne problemy biznesowe, nie upewni się, jaka jest wizja klienta, taka wizja końca po wdrożeniu tej platformy, może się okazać, że to będzie kompletnie nietrafiony zakup dla tego klienta no i wbrew pozorom też kompletnie nietrafiona sprzedaż dla tej firmy, bo w ten sposób długoterminowych relacji na pewno się nie zbuduje. A to jest niestety często popełniany błąd, no właśnie doboru jakiegoś konkretnego rozwiązania, no bo skoro klient trafił do konkretnej firmy wdrażającej te rozwiązania, no to kupmy. No i teraz w naszej firmie wyróżniamy się tym, że mamy doradztwo na start takie mocno rozbudowane, czyli zanim zaczniemy cokolwiek programować, szczególnie w większych projektach, to najpierw wchodzimy w cudzysłowie w takie buty klienta i staramy się zrozumieć, co jak działa w jego firmie.

Case study: platforma B2B a błąd procesowy

I tak też było, kiedy zgłosił się do nas klient, który chciałby wymienić platformę B2B na nową. Jest zdecydowany, gotowy, ta stara platforma B2B jest kompletnie beznadziejna. Opowiadał nam o ajaju, o tym, ile można byłoby fajnych rzeczy zrobić, o tym, jak można byłoby dzięki nowej platformie ograniczyć np.czas handlowców, czyli też przeznaczyć ten czas i ich umiejętności na pozyskiwanie nowych klientów. I co się okazało? Po tym, kiedy zrobiliśmy serię wywiadów jeden na jeden w firmie klienta z jego współpracownikami, okazało się, że wszyscy narzekają na jeden określony problem, jeden określony błąd procesowy tak naprawdę, dotyczący etapu składania zamówień u producentów. I ten błąd dotyczył w dużym uproszczeniu tego, że klienci końcowi nie do końca wiedzieli, czy mogą zamówić finalnie produkty, bo nie do końca był znany status ich dostępności, nie do końca był znany ich termin dostępności przede wszystkim i nie do końca była znana cena. No więc wtedy żadna platforma B2B jako technologia nie rozwiąże tego typu problemu. I tutaj przede wszystkim trzeba było najpierw poukładać kwestię tą procesową, czyli żeby było wiadomo w jaki sposób podchodzić do obsługi procesu od A do Z, żeby zarówno handlowcy, dział obsługi klienta, wszyscy wiedzieli, czy te towary są dostępne, od kiedy i za ile. Taki naprawdę podstawowy temat, a dopiero potem myśleć o tym, czy platformę B2B kompletnie wymienić, czy być może ją rozbudować, przebudować, tę już platformę istniejącą.

Case study: gotowy system vs. dedykowane rozwiązanie

Inny przykład. Firma była na etapie decyzji, czy wybrać gotowy system dostępny na rynku do zarządzania pewnym dużym zbiorem procesów, czy wybrać system w pełni dedykowany. No i przedstawiciel firmy tego gotowego systemu realizował piękną prezentację handlową, naprawdę. W sensie pokazywał moduły księgowe, jakieś fakturowe, raportowe, jakiegoś prostego chatbot AI, ale okazało się, że koniec końców, już przebrnęliśmy przez całą prezentację, jaką miał zaplanowano do tego klienta, to tutaj okazało się, że ten klient końcowy ma już te wszystkie obszary takie fakturowo-raportowe zaopiekowane w istniejącym już firmie od dłuższego czasu nowym ERP-ie. No i teraz okazało się, że jeżeli te funkcjonalności, te takie główne, którymi się chwaliła ta firma od gotowego systemu, podłożymy na bok, bo je już mamy, no to okazało się, że tak naprawdę ten gotowy system trzeba by w 70-80% przebudować, czy dostosować pod klienta, wiele rzeczy dopisać, bo okazało się, co wynikało z wcześniej przeprowadzonej przez nas analizy procesów, że wielu rzeczy zwyczajnie brakowało w tym systemie i okazało się, że w przypadku tego konkretnego klienta to konkretne rozwiązanie nie będzie najtańszym rozwiązaniem. Dlaczego? Dlatego, że to rozwiązanie zawierało właśnie też te funkcjonalności ERP-owe i gdyby klient nie miał wdrożonego ERP-a albo miał jakiegoś starego ERP-a, którego planuje wymienić, to prawdopodobnie to gotowe rozwiązanie byłoby pewną formą, którą warto byłoby na pewno rozważyć, a być może nawet wdrożyć. Natomiast, jeżeli już klient miał zaopiekowaną dużą część systemu w swojej firmie i to miał być po prostu jeden kolejny system, który zaopiekowuje lukę powstałą pomiędzy kilkoma działami, no to już tutaj to gotowe rozwiązanie wcale nie wychodziło korzystniej ani cenowo, ani jakościowo względem platformy budowanej od podstaw. Jak widzicie, obszar rozwiązania właściwego problemu biznesowego z użyciem właściwej technologii nie jest z reguły oczywisty, no bo polegamy na różnych opiniach innych ludzi, polegamy na tym, czego być może używa konkurencja albo właśnie czego używają nasi znajomi z innych firm, polegamy na tym, co ktoś powie, no i co w konsekwencji polegamy też na opiniach z internetu. Bardzo często polegamy na tym, co powie dany handlowiec czy przedstawiciel handlowy z danej firmy. No i koniec końców okazuje się, że jeżeli nie użyjemy takiej odrobiny kreatywności w tym wymyślaniu właściwych rozwiązań pod naszą firmę, idziemy takim prostym schematem czy prostym i utartym schematem, ścieżką, no to powoduje, że zwyczajnie te rozwiązania nie są dopasowane. 

Jak podejść do wyboru technologii?

No i dobrze, teraz jak do tego podejść metodycznie czy też logicznie, jeżeli chodzi o wybór i w ogóle rozważanie wdrożenia jakiegoś systemu IT czy np. wdrożenia AI w naszej firmie.

Pięć kroków wyboru rozwiązania IT

Przede wszystkim po pierwsze powinniśmy dokładnie zmopować problem biznesowy na jaki chcemy odpowiedzieć. Co chcemy rozwiązać? Jakiego efektu końcowego oczekujemy? Co nam to da? Jak jeszcze inaczej można ten problem biznesowy rozwiązać? Jakie są dane teraz na temat tego problemu kontradane z wizji końca jakich oczekujemy? I ostatnie, jak zmierzymy czy osiągnęliśmy to czego rzeczywiście oczekujemy? I kiedy już bardzo głęboko wejdziemy w temat tego problemu biznesowego, rozłożymy go tak logicznie na czynniki pierwsze i mamy komplet informacji dzięki którym firmę z zewnątrz możemy wdrożyć w ten nasz problem biznesowy, to wtedy druga rzecz powinniśmy mieć przygotowaną architekturę obecnych rozwiązań IT, czy taką mapę architektury. Co to oznacza? Powinniśmy mieć taki spis, taką mapę systemów już na dziś wykorzystywanych w firmie, no i też spis tego jak działają integracje między tymi systemami, gdzie te dane między jakimi systemami są wymieniane. Dzięki temu, kiedy pojawimy się u dostawcy i z tym już problemem biznesowym rozłożonym na czynniki pierwsze, który jesteśmy w stanie dokładnie nazwać i dokładnie go też pokazać co chcemy rozwiązać i pokażemy jakie systemy już mamy wdrożone, to będzie nam brakowało tylko jeszcze jednej rzeczy, żeby ten dostawca danego rozwiązania IT mógł w pełni świadomie podjąć decyzję, czy pomoże wam ten problem rozwiązać. Mianowicie jest to mapa procesów wokół tego obszaru, który chcecie rozwiązać. Czyli jeżeli pracujecie nad sprzedażą, to przynajmniej wysokopoziomowa mapa tego jak działa sprzedaż w waszej firmie. Jeżeli chcecie rozwiązać jakiś problem procesowy, taki operacyjny bardziej, no to tym bardziej. Mapa procesu tego konkretnego miejsca. 

Znaczenie mapowania procesów

Teraz ostatnio gdzieś usłyszałem takie zdanie, czy taką opinię, że w dzisiejszych czasach już się nie mapuje procesów, nie ma na to czasu, trzeba wdrażać dużo szybciej rozwiązania. Teraz ja uważam, że proces mapowania tych procesów właśnie niekoniecznie musi być super czasochłonny, bo to jest bardzo często kwestia kilku, kilkunastu roboczogodzin, żeby zmapować oczywiście wysokopoziomowo, bez ultrawielkich szczegółów, ale już takie zmapowanie wysokopoziomowe daje ogromny rezultat, jeżeli chodzi o kwestię zrozumienia jak firma działa i jak dane nawet między działami przepływają. Więc jeżeli już mamy zmapowany problem biznesowy rozłożony na czynniki pierwsze, architekturę obecnych rozwiązań w formie mapy albo przynajmniej listy tych rozwiązań, jakie u nas w firmie funkcjonują i obszar procesów, który chcemy poprawić też zmapowany przynajmniej wysokopoziomowo, wtedy dostawca w ramach punktu czwartego może spojrzeć strategicznie, jakich systemów czy automatyzacji wam brakuje i w którym miejscu zarówno tych procesów jak i tej mapy architektury IT wpasowuje się jego rozwiązanie i dopiero wtedy w ramach punktu piątego może zapaść decyzja, czy to do rozwiązania faktycznie nam odpowiada i zapewni lukę, którą faktycznie mamy, czy być może trzeba skorzystać z jakichś rozwiązań dedykowanych albo być może z jakichś zwykłych prostych automatyzacji, bo tego nigdy nie wiadomo tak naprawdę dopóki nie zmapuje się problemu biznesowego, nie zmapuje się architektury i nie zmapuje się wysokopoziomowo procesów. 

Podsumowanie i zaproszenie do kontaktu

No i co? Podsumowując, ja bardzo zachęcam was do tego, żeby patrzeć najpierw na sam problem, a dopiero potem szukać rozwiązań i niekoniecznie rozwiązywać wszystko jednym i tym samym narzędziem, czy nawet dwoma, bo bardzo często może się okazać, że coś co już znacie to nie jest już jakby na dziś najlepsze rozwiązanie na ten konkretny problem, który macie. Jeżeli szukacie pomocy, doradztwa, czy tego żeby ktoś na świeżo spojrzał na ten wasz problem biznesowy śmiało dajcie znać, chętnie pomogę. Dzięki za wysłanie dzisiejszego odcinka i do usłyszenia za tydzień. Cześć!