O jakich aplikacjach mowa? Z reguły są to skrypty lub makra stworzone w Excelu i Access, wspomagane językiem Visual Basic. I fascynujące w tym wszystkim jest to, że historia powstania tych aplikacji dla wszystkich firm jest praktycznie taka sama!

Skąd w firmach biorą się takie aplikacje?

Zaczyna się od tego, że dział firmy ma coraz więcej pracy, z którą zaczyna się nie wyrabiać. W efekcie ludzie są przytłoczeni mozolną pracą, ale muszą ją wykonywać. Okazuje się jednak, że w dziale pracuje jeden sprytny człowiek, który wie jak ułatwić sobie życie. Ten sprytny człowiek stworzył sobie arkusz w Excelu, dzięki któremu zautomatyzował pewne czynności i obliczenia, i usprawnił swoją pracę.

Niedługo potem wszyscy w dziale korzystali z jego dobroczynności, ale on nie osiadł na laurach i dalej usprawniał swoje dzieło. Po kilku latach zrobił się z tego system kilku lub kilkudziesięciu powiązanych ze sobą aplikacji, które działają na zasadzie: „tutaj wpisz, skopiuj i wyślij do Janka, on to wklei u siebie, przepisze wynik i prześle dalej…”

I na pierwszy rzut oka wszystko jest w porządku, bo w sprytny sposób i prawie zerowym kosztem praca działu została usprawniona. Problem pojawia się wtedy, gdy twórca systemu odchodzi z firmy – bo nikt nie wie jak zadbać o te aplikacje. I prawdopodobnie nikt nie wie, jak one działają.

I tutaj właśnie pojawia się duże ryzyko dla bezpieczeństwa danych w takiej firmie.

Czy takie aplikacje na pewno są bezpieczne?

Jakie mogą to być zagrożenia? No cóż, tutaj wyobraźnia wyznacza limit. Moglibyśmy wymieniać i wymieniać bez końca, jakie luki mogą kryć się w takich aplikacjach i w jaki sposób inni mogą wykorzystać je przeciwko firmie.

Zamiast tego, przytoczę jeden, ale za to dobitny przykład. I co ważniejsze – nie jest on wymyślony.

Pewna firma miała w swoim dziale taki właśnie system i jak zawsze, historia jego powstania była dokładnie taka sama, jaką przytoczyłem wyżej. System ten działał, lecz jego twórca już w firmie nie pracował. Z tego powodu nikt nie potrafił go rozbudować o nowe funkcje, nie mówiąc już o przeglądzie i bieżącej obsłudze. Więc wzięliśmy ten system pod lupę.

Zaczęliśmy standardowo – od rozmowy z klientem i użytkownikami systemu, aby poznać jego działanie w teorii. Z reguły etap ten daje nam bardzo ogólny pogląd na jego strukturę, ale… Już w jego trakcie zapaliła nam się czerwona lampka, gdy ze strony klienta padły słowa, że system przetwarza pliki .pfd na dokumenty tekstowe.

No dobrze, ale w jaki sposób to robi?

Klient nie wiedział. Nie mogąc tego tak zostawić, poprosiliśmy o dostęp do systemu, aby móc go sprawdzić na własną rękę. Zrozumienie całego procesu nie było trudne, wystarczyło prześledzić drogę dokumentu, od wprowadzenia go do systemu, do jego obróbki na dokument tekstowy.

I oczywiście dowiedzieliśmy się, w jaki sposób ta obróbka się odbywała. I co tu wiele mówić – sprawa była naprawdę nieciekawa.

Mały system – duże zagrożenie

To trochę ironiczne, że takie małe systemiki, z których korzystają pracownicy do wykonywania prostych, powtarzalnych czynności, mogą stanowić prawdziwe zagrożenie dla dobra firmy. A jednak tak jest. Dzieje się tak z wielu powodów, a najważniejszy z nich jest taki, że ludzie, którzy tworzyli te systemy, nie byli wykwalifikowanymi programistami. Każdy programista wie, jak ważne jest bezpieczeństwo danych i wie, w jaki sposób o nie zadbać. Tymczasem ciężko wymagać, aby pracownik administracyjny taką wiedzę posiadał. On i tak mocno ułatwił procesy w firmie, a że w trakcie tych usprawnień nie przemyślał wszystkich kwestii bezpieczeństwa? Trudno go za to winić.

Co więc działo się z tymi dokumentami .pdf, które miały zostać obrobione na pliki tekstowe?

System wysyłał je na NIEZABEZPIECZONY, zewnętrzny serwer, który oferuje darmową obróbkę takich plików! Czy to było sprytne rozwiązanie? Jak najbardziej, ale… zastanówmy się, jakie tworzy to ryzyko dla firmy. Czy chciałbyś, aby ktoś (na przykład duża, konkurencyjna firma) uzyskał dostęp do Waszych dokumentów takich jak:

• Korespondencja z kancelarią prawną
• Pisma od klientów (te często zawierają poufne dane, wliczając w to dane klienta, wyceny usług i inne warunki współpracy)
• Dane ważnych pracowników
• Korespondencja wewnętrzna
• Umowy z dostawcami/klientami
• Korespondencja z innymi podmiotami i urzędami państwowymi

Czy coś jeszcze? Wstaw tutaj dowolne dokumenty, których ujawnienie mogłoby w jakikolwiek sposób zagrozić Twojej firmie. Czy chciałbyś, aby bez niczyjej wiedzy lądowały one na niezabezpieczonym serwerze, którego właściciel może przechwytywać je bez problemu (i zgodnie z prawem!), a potem szantażować firmę lub sprzedać je do konkurencji?

Czy Twoje oprogramowanie jest bezpieczne?

Z oprogramowaniem nie ma żartów. Niejeden profesjonalny system informatyczny ma błędy i luki, które umożliwiają wyciek informacji, ale w przypadku takich amatorskich aplikacji… Twoja firma może wręcz krzyczeć do internetowych cwaniaków „Hej, to są nasze tajne dokumenty! Sami Ci je wysyłamy! Nie musisz się nawet do nas włamywać. Po prostu je weź i zrób z nimi, co tylko zechcesz!”

Dlatego zachęcam Cię do uważnego przyglądnięcia się oprogramowaniu, z jakiego korzystają działy Twojej firmy. Lepiej zapobiegać teraz niż później tracić miliony na bolesne i mało skuteczne leczenie. Jeśli nikt w Twojej firmie nie ma odpowiednich kompetencji, aby sprawdzić programy i systemy pod kątem bezpieczeństwa, warto wtedy skonsultować się z zewnętrzną firmą programistyczną.

A jeśli chcesz mieć pogląd na temat obsługi takich systemów i aplikacji, przeczytaj nasz artykuł, w którym dokładnie omawiamy ten temat. Kliknij -> „Obsługa aplikacji stworzonych w Excel, Access, Visual Basic. Jak zrobić to w optymalny sposób?”

Artykuł Czy masz pewność, że systemy i aplikacje w Twojej firmie nie wysyłają Waszych tajnych dokumentów w świat? pochodzi z serwisu Atinea.

Systemy IT pisane na zamówienie, to rozbudowane oprogramowanie. Często składa się z wielu modułów i napisane jest w różnych technologiach. Jest to produkt jedyny w swoim rodzaju. Jest skomplikowaną masą kodu, której zrozumienie wymaga nie lada wysiłku, ponieważ nie ma w nim elementów powtarzalnych. Z tego powodu, jeśli nie zdecydujesz się na wsparcie i obsługę ze strony wykonawcy systemu… narażasz się na spore wydatki w przyszłości. A oto dlaczego.

Wykonawca traci motywację – wersja łagodna

Każdy dostawca oprogramowania czerpie zyski z jego tworzenia, a następnie z obsługi stworzonego systemu. Jeśli klient nie chce skorzystać z jego wsparcia, wtedy wykonawca traci motywację do dalszej współpracy. Owszem, po kilku tygodniach lub miesiącach może być w stanie Ci pomóc, gdy z systemem dzieje się coś złego. Istnieje wysokie prawdopodobieństwo, że programiści odpowiedzialni za Twój system nadal u niego pracują i nadal dysponują wiedzą na temat działania Twojego systemu. Jeśli wykonawca wykaże się dobrą wolą, wtedy pomoże Ci rozwiązać problem i wszystko będzie ok. To jest optymistyczny scenariusz i nie jest powiedziane, że zawsze tak będzie. A z pewnością takie sytuacje będą należeć do rzadkości w drugim przypadku, który opisuję poniżej.

A teraz wersja drastyczna (i wcale nierzadka!)

Twój system działa stabilnie już co najmniej od dwóch lat, a Ty nie korzystałeś z wsparcia dostawcy – bo i po co? Wszystko gra, wszystko funkcjonuje, więc za co miałbyś mu płacić? Sielanka trwa do momentu, gdy pojawia się pierwsza, poważna awaria. Od razu rozwieję Twoje nadzieje: nie łudź się, że w Twoim przypadku ten dzień nigdy nie nastąpi. Awaria systemu to tylko kwestia czasu – wie to każda dobra firma programistyczna i ma na to odpowiednie procedury. Dzięki nim system można łatwo odtworzyć z kopii zapasowej, a w międzyczasie naprawić błąd, który powodował usterkę i wszystko wraca do normy.

Pewnego dnia system się „zawalił”. Naturalną reakcją w takiej sytuacji jest skontaktować się z jego wykonawcą. Niestety, z rozmowy dowiadujesz się, że wykonawca nie jest zainteresowany dalszą współpracą z Twoją firmą.

Dlaczego? Oto potencjalne powody:

• Wykonawca nie chce dalszej współpracy, ponieważ nie posłuchałeś jego rad o konieczności obsługi Twojego systemu (najmniej prawdopodobne)
• Programiści odpowiedzialni za wykonanie systemu dla Ciebie już u niego nie pracują (duże prawdopodobieństwo)
• Wykonawca musi ponieść duże nakłady czasu, aby na nowo nauczyć się Twojego systemu, a Ty nie zgadzasz się z jego wyceną (większość przypadków)
• Wykonawca nie widział interesu w opłacaniu swoich pracowników z własnej kieszeni, aby oni pozostali na bieżąco z funkcjonowaniem Twojego systemu (jak wyżej)

Co możesz zrobić w tej sytuacji? Albo zapłacić odpowiednio więcej i nakłonić wykonawcę do współpracy, albo… skorzystać z usług innej firmy programistycznej i zapłacić krocie za usunięcie jednej, być może błahej usterki.

Korzyści z regularnej obsługi systemu IT

Wszystkiego tego da się uniknąć, współpracując regularnie z wykonawcą systemu lub zatrudniając do tego inną firmę, kiedy system jeszcze działa sprawnie. Szybka i niedroga naprawa usterek nie jest jedynym uzasadnieniem dla takiej współpracy… jest ich całe mnóstwo!

Każdy system IT wymaga regularnej obsługi, ponieważ:

• Technologie się starzeją
• Zabezpieczenia stają się nieaktualne
• System wymaga optymalizacji
• W kodzie są błędy, które należy naprawić (w każdym kodzie są takowe)
• Zmieniają się procedury, jednostki lub miary i należy dostosować system do nowych wymogów
• Należy regularnie tworzyć kopie zapasowe systemu i danych
• Kwestią czasu jest, aż pojawią się usterki i przerwy w działaniu systemu

To kwestia krytyczna dla Waszego działu lub firmy, aby kontynuować taką współpracę z wykonawcą systemu. Fakt – jest to dodatkowy koszt, ale masz go pod kontrolą. Z reguły tego typu współpraca polega na ustaleniu miesięcznego pakietu godzin i realizowaniu prac obsługowych w ramach tego pakietu. My tak robimy – zarówno tworząc systemy na zamówienie, jak i obsługując systemy po innych wykonawcach.

Długofalowa współpraca to oszczędność czasu i nerwów

Regularna współpraca to jedyny sposób, dzięki któremu powyższe problemy nigdy Cię nie spotkają. W długofalowym rozrachunku Twoja firma wyjdzie na tym na plus, ponieważ umawiasz się na stałe koszty obsługi i żadne awarie nie będą zagrożeniem dla Twojego budżetu… Zupełnie przeciwnie do sytuacji, gdy system nie był obsługiwany, a Wy na szybko potrzebujecie firmy, która „postawi go na nogi” – wtedy koszty rosną lawinowo, bo nie tylko musicie opłacić firmę IT, ale też marnujecie pieniądze ze względu na przerwę w działaniu systemu.

Stała obsługa systemu to niezwykle ważna kwestia i nie można jej ignorować.

Jeśli zainteresował Cię ten temat i chciałbyś dowiedzieć się o nim więcej, chętnie odpowiemy na Twoje pytania. Być może aktualnie żadna firma nie zajmuje się obsługą Waszego systemu i chcesz porozmawiać z nami o najlepszych rozwiązaniach dla Waszej sytuacji? W każdym przypadku skorzystaj z poniższego formularza kontaktu. Nasze konsultacje są darmowe i do niczego nie zobowiązują. Po prostu zadzwoń lub wyślij nam wiadomość, a my skontaktujemy się z Tobą, aby omówić interesujące Cię tematy.

Skorzystaj z formularza w stopce i skontaktuj się z nami.

Artykuł Dlaczego długofalowa współpraca z firmą programistyczną, to czynnik krytyczny dla sprawnego działania Twojego systemu IT? pochodzi z serwisu Atinea.

Jeśli miałbym zgadywać, to zapewne rozważałeś już co najmniej dwa rozwiązania:

• Zakup gotowego programu
• Zamówienie systemu napisanego dla Was od zera (dedykowanego)

Są to typowe sposoby radzenia sobie z przestarzałym systemem ERP w firmach produkcyjnych. Ale czy ktoś wspominał Ci o ich wadach? Czy ktoś sugerował Ci inne, lepsze rozwiązanie?

Ja znam takie rozwiązanie, które może Cię zaskoczyć swoją prostotą i skutecznością. Zacznijmy jednak od wad powyższych dwóch sposobów, bo ich zrozumienie jest kluczowe.

Wady gotowego programu

Kupno gotowego programu to proste i stosunkowo niedrogie rozwiązanie. Niestety pierwszy poważny problem pojawia się już na starcie: to Wy musicie dostosować się do programu, a nie program do Was.

To raczej niemożliwe, aby zakupiony program pracował zgodnie z Waszymi procedurami. Niemożliwym jest też, że pracownicy z dnia na dzień przyzwyczają się do niego. Czeka Cię więc niezły chaos w opracowaniu nowych metod pracy i szkoleniu pracowników.

Drugiej poważnej wady nie widać od razu, ale ujawni się ona w momencie, gdy będziecie potrzebować modyfikacji systemu. Będzie to niezwykle droga „zabawa”, bo system ten z definicji nie jest przystosowany do daleko idącej personalizacji. Ponadto, za kilka lat… ten system również będzie przestarzały. Co wtedy? Zakup nowego? Droga modernizacja?

Hmm… No to może zakup systemu pisanego pod Was będzie lepszym rozwiązaniem? Sprawdźmy to.

Wady systemu napisanego pod Was (dedykowanego)

System dedykowany to rozwiązanie idealnie dopasowane do Waszej firmy, stworzone według Waszych wytycznych… I bardzo, bardzo drogie. Napisanie sensownego systemu tego typu będzie oscylować w granicach 200-500tyś złotych… choć tutaj nigdy nie ma górnej granicy. Ponadto wdrożenie go zajmie niewiarygodnie dużo czasu – licząc zachowawczo, 2 lata to minimum.

Mamy więc wysoki koszt i bardzo długi czas oczekiwania. Czy coś jeszcze? Niestety tak. W tego typu projektach istnieje wysokie ryzyko niepowodzenia. W trakcie pisania systemu mogą wystąpić nieprzewidziane przeszkody lub wykonawca może źle oszacować projekt. Efekt? Otrzymasz niefunkcjonalny system, a w najgorszym przypadku zostaniesz z nim sam, bez żadnego wsparcia od jego twórców.

I także w tym przypadku, co zrobisz za kilka lat, gdy i ten drogi system okaże się przestarzały?

No cóż, to rozwiązanie jest również dalekie od ideału, ale… Nie może być przecież tak, że firmy skazane są wyłącznie na dwa, skrajnie nieskuteczne rozwiązania.

I na szczęście tak nie jest.

Optymalne rozwiązanie

A co, jeśli powiem Ci, że wcale nie potrzebujesz nowego systemu, aby Twoja firma kontynuowała swój dynamiczny rozwój?

Co, jeśli powiem Ci, że możesz rozwiązać problem z ERP-em już w kilka tygodni, bez chaosu w firmie i niższym kosztem?

Co, jeśli powiem Ci, że dzięki temu rozwiązaniu Wasz system ERP zawszebędzie aktualny?

Jest wysoce prawdopodobne, że rozwiązanie to będzie idealne dla Waszej firmy (bo jest bardzo uniwersalne). Ale my nigdy nie bazujemy na domysłach i współpracujemy tylko z ludźmi, którzy wiedzą czego chcą. Dlatego mam do Ciebie pytanie:

Chcesz pozbyć się problemu z systemem ERP i poznać nasz optymalny sposób na to?

Zatem musimy o tym krótko porozmawiać. Nie da się tego załatwić tak po prostu, pisząc o tym, bo w ten sposób mógłbym wprowadzić Cię w błąd. Muszę najpierw poznać sytuację w Twojej firmie oraz obecny stan Waszego systemu. Dopiero wtedy będę w 100% pewny, czy to optymalne rozwiązanie jest dla Was odpowiednie. I oczywiście opowiem Ci jak za jego pomocą rozwiążecie ten problem dużo lepiej, niż w przypadku tradycyjnych metod.

Będzie to w 100% bezpłatna konsultacja – bez żadnych późniejszych reklam, trików i innego badziewia.

Ja nazywam się Tomek Stachowicz i jestem wiceprezesem firmy Atinea Sp. z o.o.. Zrealizowaliśmy już ponad 200 projektów informatycznych dla małych, średnich i dużych firm. Uwierz mi, że dzięki temu doskonale wiem, jakie rozwiązania są najlepsze dla firm produkcyjnych, takich jak Twoja.

Więc jeśli jesteś zdecydowany i chcesz porozmawiać ze mną o Waszym systemie ERP, po prostu wypełnij poniższy formularz, a mój asystent umówi nas na rozmowę telefoniczną:

Artykuł Przestarzały system ERP blokuje rozwój Twojej firmy? pochodzi z serwisu Atinea.

Po co rozmawiać, skoro nie masz potrzeb?

Rozmowy „od niechcenia” zdarzają się w każdej branży. „No dobra, opowiedzcie Panowie o swojej ofercie, ale my i tak nie jesteśmy zainteresowani zakupem Waszych usług”. Czy warto ignorować takie rozmowy? My tego nie robimy, bo doświadczenie nauczyło nas, że nawet taka sucha i pozornie jałowa rozmowa, może przełożyć się na owocną współpracę dla obu stron. Co zatem sprawia, że rozmowa z zewnętrznym dostawcą może być taka przełomowa?

Jeśli chodzi o działy IT w firmach – w niektórzych przypadkach pracują tam ludzie, którzy skupiają się wyłącznie na „własnym podwórku”. Są kompetentni i wiedzą co robią, ale… Znają tylko swoje systemy, pracują tylko według swoich procedur i rozwijają się tylko według swoich potrzeb.

W firmach bez IT jest jeszcze gorzej – bo tam być może są jakieś potrzeby, ale nie ma z kim ich omówić. Owszem – można wymyślić własne rozwiązanie i szukać kogoś, kto je zrealizuje, jednak… czy to rozwiązanie jest optymalne? Czy nie da się tego zrobić lepiej/taniej/szybciej?

W takich momentach warto skonsultować się z kimś z zewnątrz.

Co zatem daje rozmowa z renomowaną firmą programistyczną?

Profesjonalni dostawcy usług programistycznych to z reguły firmy o bogatym doświadczeniu w branży. Kodują w różnych technologiach, pracują z różnymi systemami, realizują różne projekty dla różnych firm. Mówiąc w skrócie: znają mnóstwo rozwiązań i sposobów na zaspokojenie potrzeb programistycznych w firmach. Nie zamykają się wyłącznie na jeden typ zleceń lub projektów, przez co mają świetne know-how i szeroką wiedzę.

Dzięki tej wiedzy są w stranie wypracować lepsze rozwiązania niż ekipy, które skupiają się wyłącznie na pracy z jednym i tym samym projektem. Dzięki swojemu doświadczeniu dostrzegają możliwości do usprawnień i potrafią doradzić optymalne rozwiązania.

U nas wygląda to z reguły tak: pytamy klienta o sytuację w jego firmie – z jakiego oprogramowania korzystają i w jaki sposób ono funkcjonuje lub jak chcieliby usprawnić pracę w ich firmie. Już to jedno pytanie często otwiera nam drzwi do znalezienia potencjalnych błędów i usprawnień, a także… możliwości do zrobienia tego niższym kosztem. Następnie drążymy temat, aż będziemy mieć komplet informacji niezbędnych do znalezienia optymalnego rozwiązania.

Żeby nie bazować na ogólnikach, oto jeden z wielu przykładów z naszych rozmów.

Przykład jednej takiej rozmowy

Rozmawialiśmy z dyrektorem firmy transportowej. W firmie pracuje informatyk, który przy okazji stworzył im rozbudowany arkusz w Excelu, który gromadzi dane na temat ich firmy. Organizacja jednak rozwija się niezwykle dynamicznie i ów arkusz zaczyna niewyrabiać. Ilość rekordów ciągle się zwiększa i ławo sobie wyobrazić co się dzieje, gdy pojedynczy arkusz w Excelu zaczyna ważyć ponad 250MB. Jego obsługa i stabilność działania są mocno wątpliwe.

Klient był utwierdzony w przekonaniu, że potrzebuje zamówić nowy system, który usprawni pracę firmy i zapewni im spokój na następne lata (firma planuje mocny rozwój). Okazało się jednak, że koszt takiego systemu wyniesie około 500tyś złotych. To nie był jedyny problem.

Zapytaliśmy go, co się stanie, gdy przyjdzie im wdrożyć ten system. Kto zadba, aby wdrożenie odbyło się stopniowo, tak żeby nie zaburzać pracy ludzi przyzwyczajonych do starego arkusza? Kto upewni się, że firma programistyczna wywiązała się z umowy i kto zadba o właściwy odbiór kodów źródłowych? Kto zrobi to wszystko w trosce o stabilność działania firmy?

Kolejny problem: co, jeśli ten system za 5 lat okaże się za słaby, bo firma podwoi obroty i zatrudnienie? Czy wtedy zamówią nowy system? A może opłacą kogoś, żeby szybko rozwinął jego możliwości (zrobienie tego „szybko” jest technicznie niemożliwe)?

Klient zamilkł. Nie przewidział takich problemów, bo zwyczajnie nie miał z tym nigdy styczności, a jego firma nie zatrudnia programistów.

Zaproponowaliśmy rozwiązanie, które było tańsze i dużo lepsze w długoterminowej perspektywie. Firma ta potrzebuje… zespołu programistów. Albo wewnętrznego, albo zewnętrznego, z którym może współpracować długofalowo.

W ten sposób obecny arkusz można nieco zoptymalizować, a jednocześnie krok po kroku tworzyć system, który będzie zawsze spełniał aktualne wymogi i potrzeby firmy. Mając programistów dostępnych na stałe w firmie można reagować na aktualne zmiany procedur, zwiększone obroty, zmianę charakteru pracy firmy i każdy inny czynnik, który wymaga modernizacji systemu. Co więcej – zmiany są wprowadzane praktycznie od ręki, kiedy na nowy system robiony na zamówienie trzeba czekać średnio 2 lata… a potem go wdrożyć. A za kilka lat kupić następny.

Co tu dużo mówić – klient był zachwycony, że można to rozwiązać w taki sposób. I gdyby nie ta rozmowa, za jakiś czas pewnie szukałby dostawcy, który stworzy mu „potrzebny” system.

To rozmowa, która nic nie kosztuje, a może wiele zmienić

To jeden z wielu przykładów, gdzie nasza znajomość branży pomogła pozornie niezainteresowanym klientom usprawnić pracę w ich firmach. To dlatego jeśli jesteś dyrektorem firmy, dyrektorem działu lub kierownikiem projektu, warto abyś skonsultował się raz na jakiś czas z renomowaną, zewnętrzną firmą programistyczną. Jeśli nie trafisz na naciągaczy, wtedy możesz liczyć na fachową poradę, skupioną na tym jak pomóc Tobie, a nie jak na Tobie zarobić.

Jeśli chciałbyś porozmawiać na ten temat z nami, skorzystaj z danych kontaktowych lub formularza w stopce tej strony. Chętnie umówimy się z Tobą na niezobowiązującą rozmowę i doradzimy Ci zgodnie z naszą najlepszą wiedzą.

Artykuł Rozmowa z firmą programistyczną może przynieść przełom w Twojej firmie pochodzi z serwisu Atinea.

Ambitny człowiek i projekt na boku

Zacznijmy od genezy problemu. Jest sobie firma, a w firmie jest dział, który nie narzeka na brak pracy. Budżet działu nie pozwala na zatrudnienie nowych osób, a pracy przybywa. Na szczęście w dziale pracuje pewien sprytny człowiek. Nie jest programistą, ale doskonale zna się na aplikacjach biurowych. Potrzeby w dziale wzrastają, dlatego konieczne jest podwyższenie wydajności. Co robi sprytny człowiek? Tworzy usprawnienia we własnym zakresie: przygotowuje proste szablony w Excelu, które ułatwiają obliczenia, katalogowanie lub obieg informacji. Firma kontynuuje rozwój. Potrzeby stają się większe. Z jego rozwiązań zaczynają korzystać inni pracownicy.

Okazuje się, że gość od Excela jest prawdziwym człowiekiem renesansu. Bez problemu dogaduje się z użytkownikami szablonów, które przygotował i dowiaduje się, w jaki sposób można je ulepszyć. I robi to. Nagle proste dokumenty wzbogaca o automatyzację, pojawia się Access, Visual Basic i inne, „dziwne” technologie.

Po kilku latach cały dział w firmie opiera swoją pracę na tym prostym niegdyś szablonie w Excelu, który obecnie…  Jest już zaawansowanym zestawem aplikacji i skryptów. Ich obsługa niekoniecznie jest intuicyjna, ale ludzie i tak są zadowoleni, bo nie muszą już wykonywać całej tej mozolnej pracy. To działa.

Wszystko to dzięki jednemu człowiekowi, który miał zapał i umiejętności, i wiedział jak je wykorzystać. Znał biznes, znał ludzi, znał technologie, a teraz… go nie ma. Odszedł z firmy? Przeszedł na emeryturę? Zachorował?

Pozostał po nim zestaw aplikacji, od którego zależy praca całego działu. A od pracy działu… zależy stabilność całej firmy. Raptem aplikacje stają się kluczowym czynnikiem, o który należy zadbać, aby zapewnić firmie bezpieczeństwo, ale…

Nikt nie wie, o co w tym wszystkim chodzi

Nikt nie potrafi ich obsłużyć. Nikt nie ma pojęcia, jak je konserwować i rozbudowywać. Co więcej – każdy boi się za to zabrać, żeby przypadkiem czegoś nie zepsuć.

Pokładasz nadzieję w programistach z działu IT (jeśli takowi pracują w Twojej firmie). Ci jednak umywają ręce – to nie ich projekt. Dlaczego mają nadstawiać karku za system, który jakiś człowiek stworzył sobie na boku? Poza tym nie mają na to czasu, zasobów ani wiedzy. Ich rozwiązanie jest proste – kupmy nowy system od dostawcy, który zapewni mu obsługę i wsparcie.

Jednak to nie wchodzi w grę. Poszukiwanie dostawcy, tworzenie specyfikacji, analiza potrzeb i wymagań, analiza biznesowa, zorganizowanie pieniędzy… To wszystko ciągnie się miesiącami, a dodać do tego czas na wdrożenie i optymalizację systemu i ostatecznie, w optymistycznej wersji nowy system będzie gotowy za 2 lata. Tymczasem zmiany w obecnych aplikacjach muszą być robione na bieżąco: bo zmieniają się przepisy, formaty danych ulegają zmianie, zmieniają się potrzeby lub… Twoje aplikacje mogą po prostu się zepsuć.

A może by tak zatrudnić człowieka, który zapanuje nad tym wszystkim? Rozwiązanie to wydaje się optymalne, ale… Dział IT uzna, że jeden człowiek to za mało – potrzebujecie co najmniej trzech, bo mało kto będzie w stanie zrozumieć działanie Waszego „dziwnego” systemu w pojedynkę. Tylko skąd wziąć na to pieniądze? I drugie pytanie: czy ci ludzie faktycznie będą chcieli w tym grzebać?

Sytuacja skrajnie nieciekawa. Co zrobić w takim przypadku?

Mamy rozwiązanie tego problemu

Znamy dziesiątki podobnych historii. Znamy je, bo odbyliśmy mnóstwo rozmów z klientami, którzy nie mogli poradzić sobie z obsługą tego typu aplikacji w swojej firmie. Poszukiwali rozwiązania, które będzie pewne i skuteczne, i nie zrujnuje ich finansowo, i…

Znaleźli je u nas.

Jako jedni z nielicznych (być może jedyni?) na Polskim rynku IT zajmujemy się obsługą takich przypadków. Na stałe zatrudniamy ekspertów od starych technologii, takich jak Visual Basic, Access, Excel, DOS i inne. Możemy przytoczyć wiele przykładów, kiedy nasza usługa oszczędziła klientom mnóstwo nerwów, czasu i pieniędzy. Działamy w oparciu o autorskie procesy przejęcia, modernizacji i utrzymania systemów oraz aplikacji. Nie tylko zapewnimy stabilność działania Twojej firmie, ale też rozbudujemy i unowocześnimy Wasz obecny zestaw skryptów i aplikacji.

Co więcej, nasi programiści to prawdziwi eksperci. Pracują wydajniej, uczą się szybciej, a koszt ich zatrudnienia paradoksalnie jest niższy niż koszt pracy słabych programistów. W miejsce jednego naszego eksperta, należałoby zatrudnić 2-3 przeciętnych pracowników, aby osiągnąć podobne rezultaty. Dlatego zatrudniamy wyłącznie najlepszych.

Skorzystaj na tym, tak jak zrobili to inni

Jeśli potrzebujesz kogoś, kto pomoże Ci rozwiązać podobny problem w Twojej firmie, to trafiłeś we właściwe miejsce. Dla potwierdzenia, oto kilka firm, które skorzystały z naszej usługi utrzymania systemu oraz ich opinie o naszej pracy:

Skontaktuj się z nami. Chętnie poznamy Twoją sytuację. Zaproponujemy Ci rozwiązania dopasowane konkretnie do potrzeb Twoich i Twojej firmy.

Umów się na niezobowiązujące spotkanie lub rozmowę telefoniczną i dowiedz się, jak możemy Wam pomóc rozwiązać ten problem.

Skorzystaj z poniższego formularza lub zadzwoń do naszego sekretariatu i ustal termin rozmowy.

PS: Mamy dla Ciebie jeszcze kilka innych artykułów, które mogą Cię zaciekawić:

Jak we właściwy sposób odbierać kody źródłowe, aby uniknąć poważnych problemów z rozwojem systemu?

Stare systemy – lepiej utrzymywać, czy przepisać na nowe technologie?

Artykuł Obsługa aplikacji stworzonych w Excel, Access, Visual Basic. Jak zrobić to w optymalny sposób? pochodzi z serwisu Atinea.

Z artykułu dowiesz się:

• jakie błędy popełniają firmy odbierając kody źródłowe
• jakie są konsekwencje posiadania niewłaściwych kodów
• z jakimi problemami mieli do czynienia nasi klienci
• jak prawidłowo przejmować kody wraz z dokumentacją

Najczęstsze błędy

W wielu przypadkach klient nie zatrudnia programistów, którzy mogliby sprawdzić stan przekazanych danych. Dla niego najważniejszym zagadnieniem jest test działania systemu, natomiast sprawdzając kody, upewnia się jedynie… czy je otrzymał. Nie weryfikuje ich i zakłada, że są zgodne z systemem uruchomionym przez wykonawcę. Co więcej, często odbiera je tylko po zakończeniu głównej części projektu i nie uzupełnia ich po późniejszych modyfikacjach.

Dopóki klient regularnie współpracuje z wykonawcą systemu, dopóty wszystko działa jak należy. Problem pojawia się, gdy ktoś inny przejmuje obsługę programu. Czy ja napisałem problem? Pojawia się masa problemów i to w najgorszym możliwym momencie!

Typowe konsekwencje niewłaściwego odbioru kodów:

• systemu nie da się skompilować ze względu na braki w dokumentacji lub w kodach,
• po wykonaniu kompilacji okazuje się, że brakuje kodów do poszczególnych modułów,
• systemu nie da się zainstalować „od zera” ze względu na brakujące komponenty,
• system uruchomiony na serwerze testowym działa inaczej niż ten dostarczony przez wykonawcę.

Klienci w tej sytuacji kontaktują się z wykonawcą programu i to często załatwia sprawę. Zdarza się jednak, że wykonawca nie przechowywał kodów ani dokumentacji, bo ich współpraca zakończyła się dawno temu. Nierzadko jest tak, że osoby odpowiedzialne za projekt już nie pracują w danej firmie. Bez względu na przyczyny, brak pomocy ze strony twórcy systemu oznacza kłopoty dla właściciela.

Tak to wygląda w praktyce – przykłady problemów naszych klientów

Przykład pierwszy – mnóstwo zmarnowanego czasu

U jednego z klientów przejmowaliśmy opiekę nad systemem po innym wykonawcy. System składał się z kilkunastu dużych modułów i całość stanowiła dosyć rozbudowany program. Wraz z dokumentacją otrzymaliśmy paczkę kodów źródłowych i teoretycznie wszystko powinno pójść gładko. Zaczęliśmy od sprawdzenia kodów i już na starcie trafiliśmy na przeszkodę. Programu nie dało się uruchomić na serwerze testowym.

Poświęciliśmy miesiąc na intensywną komunikację z klientem i wykonawcą i w jej wyniku otrzymaliśmy właściwe kody. „Tym razem się udało” – pomyśleliśmy. Niestety, niedługo potem odkryliśmy, że nadal nie dysponujemy kodami do wszystkich składników. Ich brak, mimo działającego systemu, uniemożliwiał nam jego rozwój. Uzyskanie brakujących kodów zajęło nam następne kilka tygodni. Zmarnowaliśmy mnóstwo czasu uruchomienie i uzyskanie pełnego dostępu do programu. Czasu, który mogliśmy poświęcić na właściwą pracę nad obsługą i rozwojem.

Przykład drugi – mały problem, duże konsekwencje

Kilka lat temu, nasz obecny klient zamówił w pewnej firmie system do przetwarzania skanów dokumentów. Przez następne lata system pracował stabilnie i nie było z nim problemów. Następnie zmieniło się prawo, a wraz z nim należało lekko zmodyfikować system. Niestety, wykonawca systemu nie był zainteresowany współpracą – być może nie dysponował już ani dokumentacją, ani ludźmi, którzy tworzyli ten projekt. Wtedy klient, szukając innego wykonawcy, zgłosił się do nas.

Po wstępnych rozmowach ustaliliśmy, że:

• klient posiadał kody źródłowe, ale tylko do pierwszej wersji systemu,
• system korzystał z zewnętrznej biblioteki OCR, do której klient nie miał licencji programistycznej,
• aby przeprowadzić zmiany, musielibyśmy wykupić analogiczną licencję, a jej koszt stanowił znaczny procent wartości projektu.

Tutaj nie było happy endu. Mimo iż modernizacja systemu była niewielka, powyższe problemy skutecznie ją uniemożliwiły. W efekcie klient nie miał innego wyjścia niż zamówić nowy system.

Zatem, jak prawidłowo odbierać kody?

Poprawna procedura odbioru kodów nie jest skomplikowana, ale należy jej ściśle przestrzegać. Stosuj ją nie tylko przy odbiorze głównej części systemu, ale także przy każdej modyfikacji programu.

Odbierając system:

• dokładnie skontroluj kompletność kodów źródłowych z uwzględnieniem wszystkich modułów i poprawek,
• zapoznaj się i sprawdź kompletność instrukcji instalacji systemu,
• zainstaluj całość „od zera” na nowym serwerze korzystając z otrzymanych kodów,
• testy działania przeprowadzaj na systemie uruchomionym z kodów źródłowych.

Minimalny wariant bezpieczeństwa zakłada, że powyższą procedurę powinien przeprowadzić wykonawca w obecności zamawiającego. Jest to wygodna opcja, szczególnie dla firm bez własnego zaplecza IT. Nie gwarantuje jednak 100% pewności, że w przyszłości wszystko będzie działać, jak należy.

W optymalnym wariancie wykonawca przekazuje paczkę kodów i dokumentacji klientowi. Ten z pomocą własnego zespołu lub zatrudniając zewnętrzną firmę, przeprowadza całą procedurę na własną rękę, bez udziału wykonawcy. Dzięki temu klient może dokładnie zweryfikować kompletność kodów i poprawność działania systemu. Ewentualne braki i usterki zostaną naprawione, a w przyszłości nie będzie problemów z modyfikacją oprogramowania przez inne ekipy programistów. Koszt takiego rozwiązania to zaledwie mały procent wartości zamówienia, ale skutecznie minimalizuje ryzyko strat w przyszłości.

Bądź skrupulatny

Systemy informatyczne pisane na zamówienie, to unikalne oprogramowanie, do którego obsługi niezbędna jest kompletna dokumentacja i aktualne kody źródłowe. Dlatego tym bardziej zachęcamy Cię do wnikliwej analizy otrzymywanych kodów i postępowaniu według zalecanej procedury, jaką przedstawiliśmy w tym artykule. Dzięki niej Twoja firma nigdy nie doświadczy problemów z rozwojem systemu.

Artykuł Jak we właściwy sposób odbierać kody źródłowe, aby uniknąć poważnych problemów z rozwojem systemu? pochodzi z serwisu Atinea.

Popularny, ale czy uniwersalny?

Najpopularniejszym sposobem rozliczeń z firmami IT jest model Fixed Price.
Wykonawca tworzy listę funkcjonalności, przelicza to na czas pracy i z góry ustala odpowiednią kwotę za wykonanie całości. Z perspektywy klienta jest to bardzo wygodna metoda – jeszcze przed rozpoczęciem pracy zna dokładny koszt i termin wykonania. Projekt rozliczany w ten sposób ma łatwiejszą drogę do przejścia przez odpowiednie działy w firmie:

• dział budżetowy zorganizuje wymaganą kwotę,
• dział IT nie poniesie bezpośredniej odpowiedzialności za ewentualne problemy,
• dział zakupów może łatwo porównać kilka ofert i obniżyć koszt,
• dział prawny bez większych problemów zminimalizuje ryzyko, stosując kary umowne.

No dobrze – wydaje się, że zalety są mocne. Jednak czemu to właśnie model Fixed Price sprawia, iż wiele projektów kończy się fiaskiem?

Początkowo wszystko jest pod kontrolą…

Załóżmy, że zgłaszasz się do wykonawcy. Opowiadasz o swoich potrzebach i przedstawiasz wymagania: potrzebujesz software na zamówienie, taki który będzie idealnie dopasowany do działalności, jaką prowadzi Twoja firma. Wykonawca zapoznaje się z tematem, szacuje czas oraz koszt i prezentuje Ci ofertę.
Zadowolony, że masz pełną kontrolę nad zleceniem, podpisujesz umowę i wiesz, że znowu wykonałeś dobrą robotę. Wszystko idzie dobrze, do czasu aż pojawią się pierwsze…

Problemy

A te pojawiają się już na etapie projektowania. Skoro projekt ma ograniczony budżet, wykonawca będzie trzymał się minimalnego planu, zgodnego ze specyfikacją. W tym samym czasie Tobie zależy na tym, aby Twój system miał jak największą funkcjonalność i był wygodny w obsłudze – mamy pierwszy zgrzyt. Kolejny jest już w drodze.

Konflikt interesów

Wykonawcy zależy na zysku, więc będzie zabezpieczał swój interes powiększając kwotę o odpowiedni „margines bezpieczeństwa”. Jeśli wszystko pójdzie po jego myśli, wtedy prawdopodobnie przepłacisz – wartość na umowie znacząco przekroczy realny koszt projektu.

Drugi i zdecydowanie częstszy scenariusz jest taki, że w trakcie kodowania wystąpią nieprzewidziane problemy; będziesz chciał coś zmienić, albo system okaże się bardziej rozbudowany, niż zakładano na początku.
Co to oznacza dla wykonawcy? Potężny wzrost nakładów pracy, ryzyko niedotrzymania terminu, a w efekcie stratę pieniędzy. Tutaj nie ma górnej granicy, koszty mogą wzrastać lawinowo, a przewidzieć to na etapie projektowania jest praktycznie niemożliwym.

No dobrze, ale przecież jesteś klientem i to nie Twój problem, bo i tak dostaniesz to, co zamówiłeś… ale czy na pewno?

Kłopoty wykonawcy = Twoje kłopoty

Wykonawca w tarapatach będzie minimalizował straty. Pominie wszystkie dodatkowe elementy, które w trakcie prac okazały się zbędne do poprawnego funkcjonowania systemu. Pominie także Twoje sugestie zmian, bo de facto nie jest zobowiązany do ich wykonania. Będzie dążył do wdrożenia głównej specyfikacji, pomijając optymalizację, jakość oraz testy. Co więcej – skupi się na tym, aby jak najszybciej zakończyć Waszą współpracę i nie będzie skory do pomocy przy implementacji i rozwoju systemu w przyszłości.

Owszem, można renegocjować umowę i dopisywać aneksy, ale to zaowocuje wzajemną niechęcią i dużą stratą czasu oraz pieniędzy.

Ktoś musi stracić

Konsekwencją zawsze będzie nieudana współpraca. Raz poszkodowany może być dostawca, który w obawie przed negatywną reputacją stworzy bardziej rozbudowany system, niż zakładała specyfikacja i straci pieniądze.
Innym razem będzie to klient – otrzyma oprogramowanie, które nie spełni jego potrzeb i mimo iż dostawca będzie chciał kontynuować współpracę, to zamawiający już niekoniecznie.

Model rozliczeń ma znaczenie

Fixed Price doskonale sprawdza się przy rozliczaniu małych, powtarzalnych projektów, jednak w przypadku systemów pisanych na zamówienie (nawet tych stosunkowo niewielkich) tworzy barierę pomiędzy klientem a wykonawcą i jest źródłem sporów. W tej sytuacji, zamiast skupić się na rozwiązaniach, obie strony starają się wywalczyć jak najwięcej korzyści lub ograniczyć straty. Dlatego tak ważne jest, aby przed podpisaniem umowy dokładnie przemyśleć, czy wybrany model rozliczeń wpłynie pozytywnie na realizację projektu.

Artykuł Wady modelu Fixed Price. Dlaczego ten popularny sposób rozliczeń prowadzi do problemów? pochodzi z serwisu Atinea.

Jeśli spytać programistów, którą z opcji należy wybrać, raczej nie będą mieli wątpliwości. “Napiszmy system od nowa, ale lepiej niż to zrobili poprzednicy. Użyjmy nowych technologii, które dobrze znamy, poprawmy przy okazji architekturę systemu, a stary system zaorajmy. Dzięki temu będziemy mogli wreszcie przeczyścić listę błędów, zaimplementować nowe funkcje, o które biznes dopomina się od miesięcy, a na deser dorzucimy trochę wodotrysków w interfejsie użytkownika.” Korzyści z takiego scenariusza są jasne – dział IT odzyska sprawność wprowadzania zmian w systemie, pojawią się nowe możliwości integracyjne oraz rozwiążemy problem przestarzałości rozwiązania na wiele lat.

Jednak kierownik IT zwykle nie będzie aż tak entuzjastycznie nastawiony do tego pomysłu. Przede wszystkim będzie potrafił sobie wyobrazić spojrzenie właściciela biznesowego systemu, któremu powie: “co prawda od wielu miesięcy czekacie na realizację swoich pilnych zgłoszeń, ale zaakceptujcie teraz ten kilkusettysięczny budżet, a już za rok… no, góra dwa, będziemy mogli je dla was wykonać”. Poza tym będzie wiedział – szczególnie, jeśli miał już doświadczenie z podobnymi projektami – że koszt ponownej implementacji i czas do uruchomienia produkcyjnego są zazwyczaj znacznie niedoszacowane.

Z drugiej strony scenariusz budowy zespołu, który zajmie się utrzymaniem i rozwojem kodu obecnego systemu, też nie rysuje się optymistycznie. Oczywiście w przypadku sukcesu korzyści są warte wysiłku. Dział IT może w krótkim czasie zająć się naprawą najbardziej uciążliwych błędów i realizacją nowych potrzeb biznesu. Ponadto koszty usprawniania i rozwoju stabilnego systemu zwykle stanowią niewielki procent kosztu jego wytworzenia, więc zorganizowanie budżetu w firmie staje się o wiele łatwiejsze. Jednak droga do tego sukcesu wydaje się znacznie bardziej stroma niż w wariancie ponownej implementacji systemu. Najpierw trzeba znaleźć programistów, którzy będą mieli chęć i kompetencje do zagłębienia się w dziesiątki tysięcy linii kodu, do których nie ma za bardzo dokumentacji. Już samo to jest wyzwaniem, a jeśli do tego dodamy fakt, że zwykle kod jest napisany w starszym języku programowania i przy użyciu nierozwijanych już bibliotek i narzędzi, to sytuacja staje się naprawdę trudna. Potem wcale nie jest łatwiej, bo taki zespół trzeba utrzymać, a na tak konkurencyjnym rynku znacznie lepiej w CV prezentuje się “tworzenie nowej aplikacji mobilnej w React Native” niż “poprawianie błędów w starym systemie w Visual Basic 6”.

Jak zatem poradzić sobie z problemem rozwoju systemu, gdy oba scenariusze generują znaczne trudności? Przede wszystkim trzeba mieć świadomość, że w dłuższej perspektywie aktualizacja technologiczna jest konieczna, gdyż z każdym rokiem koszt wspierania starych rozwiązań będzie rósł, a możliwość ich dostosowania do zmieniających się potrzeb biznesu będzie malała. Istotne jest jednak, żeby do takiego projektu zorganizować zespół, który nie tylko będzie posiadał odpowiednie kompetencje techniczne, ale będzie też dobrze znał realne potrzeby biznesowe, które stoją za systemem.

I tu dochodzimy do sedna sprawy, bowiem najlepszym sposobem pozyskania tej wiedzy merytorycznej jest… spędzenie kilku miesięcy na utrzymaniu i rozwoju starego systemu. Tak przeszkolony zespół będzie znacznie lepiej przygotowany do realnego zaplanowania migracji technologicznej. Będzie też w stanie po partnersku rozmawiać z biznesem o potrzebach i odróżniać usprawnienia uzasadnione biznesowo od wymagań z kategorii “nice to have”, które są kosztowne, ale nie wnoszą wiele wartości.

Takie podejście pozwoli uzyskać korzyści z obu opisanych wyżej scenariuszy – w krótkiej perspektywie będzie można na bieżąco reagować na błędy i potrzeby zmian, a w dłuższej rozwiązać problem długu technologicznego i zwiększyć możliwości rozwoju i integracji. Równocześnie zniknie część problemów – dobrze przygotowany zespół uniknie nadmiernego optymizmu w planowaniu migracji, biznes będzie widział bezpośrednie efekty z budżetu, programiści nie będą rozglądać się za ofertami pracy z ciekawszymi technologiami. Nadal jednak pozostaje kwestia, jak zorganizować odpowiednie osoby do takiego zespołu. Na pewno istotne jest, żeby składał się z osób, które są chętne do nauki nowych rzeczy, zarówno w obszarze technologii jak i wiedzy biznesowej. W przypadku programistów bardziej niż np. 10 lat doświadczenia w tworzeniu systemów CRM w JEE na Oracle’u, liczy się obycie z różnymi językami i narzędziami oraz zdolność pracy na cudzym kodzie. Wybranie odpowiednich osób z mnogości ofert na rynku nie jest zadaniem łatwym, jednak możliwym – ale to już temat na osobny artykuł. Zawsze też można skorzystać ze wsparcia zewnętrznych firm, które wezmą tą kwestię na siebie.

Artykuł Stare systemy — lepiej utrzymywać czy przepisywać na nowe technologie? pochodzi z serwisu Atinea.