GoldenLine
Zaloguj się
Kamil Jadczyszyn

Kamil Jadczyszyn Audytor IT

Audyt systemów informatycznych, to mało znany temat szczególnie stronie biznesowej.
Chciałem przybliżyć jego charakterystykę oraz podać zalety wynikające z przeprowadzenia takiego audytu w firmie.
-- Po co mojej firmie audyt IT?
Otoz audyt IT pozwala w sposób obiektywny sprawdzić jakość świadczonych usług przez dział
IT oraz skonfrontować je z wymaganiami biznesu i uznanymi na całym świecie standardami
i dobrymi praktykami: COBiT, ITIL, normami ISO/IEC. Audyt IT pozwala bezpiecznie zarządzać
procesami informatycznymi w firmie; wykrywać niebezpieczeństwa związane z funkcjonowaniem
systemów IT w firmie; wprowadzać skuteczne rozwiązania istniejących i potencjalnych
podatności.

Jeśli kogoś ta tematyka zainteresowała lub chciałby bliżej przyjrzeć się audytowi IT w kontekście korzyści jakie może przynieść firmie, zapraszam na 
http://www.bpg.pl
Link do wypowiedziLink

konto usunięte

Zdecydowana większość audytów to
-- strata środków
-- strata czasu pracowników
-- niepotrzebna nerwówka dla pracowników
-- ITIL i COBiT, standardy ISO ładnie wyglądają na papierze, ale są w informatycznym światku nieużyteczne i nieprzestrzegane
-- pewna forma d...krytki
-- opis rozwiązań na które nie będzie zasobów finansowych i czasowych

Jeszcze pewien sens widzę w audytach stricte technicznych np. dlaczego bazy danych się mulą, co jest wąskim gardłem w przetwarzaniu końca miesiąca, w jaki sposób można lepiej znormalizować dane, czy strony WWW padną przy dużym obciążeniu, czy hackerzy nie pokonają łatwo firmowych zabezpieczeń..
Audyty dokonywane przez szacownych konsultantów krawaciarzy z renomowanych firm nie uwzględniają mnóstwa specyficznych uwarunkowań np.
-- łączenia w jednym pracowniku kilku różnych stanowisk (administrator, analityk, programista w jednym ciele to zjawisko nader częste)
-- tworzenia oprogramowania przez działy biznesowe - tam często są łebscy ludzie i jeszcze nie trzeba im tłumaczyć biznesu
-- utrzymywanie porządku w kodzie źródłowym z krótkimi komentarzami ma większą wartość niż tworzenie opasłych tomów dokumentacji
-- pomimo rotacji pracowników zawsze są osoby dłuższe stażem albo lepiej opłacani kluczowi pracownicy organizacji potrafiący w tym gąszczu się rozeznać
-- udziwnione uprawnienia lub nazbyt restrykcyjne są powodem zapisywania haseł na karteczkach w biurkachKazimierz Szpyt edytował(a) ten post dnia 09.03.13 o godzinie 18:09
Link do wypowiedziLink
Radosław Smilgin

Radosław Smilgin Konsultant i trener
testowania
oprogramowania i
ISTQB. 10...

Czym w takim razie jest audyt Panie Kamilu?
Analiza biznesowa, testowalność, testowanie bezpieczeństwa, wydajności i użyteczności, dobre praktyki kodowania... itd. To są metody stosowane przez role (analityk, tester, koder) w organizacji. Ogólnym zapewnieniem jakości zajmuje się dział QA. Po co więc na to wszystko audyt?
Po co zgodność z COBiT-em, ITIL-em, ISO? Czy produkt / organizacja stają się przez to lepsze? Nie. Audyt kończy się jedynie wytycznymi, więc nie poprawi ani produktu, ani organizacji.
Link do wypowiedziLink
Kamil Jadczyszyn

Kamil Jadczyszyn Audytor IT

Dzien dobry,
Przede wszystkim dziekuje za wypowiedzi. Zawsze warto wymienic poglady, nawet jesli nie zgadzamy sie ze soba.
Pan Krzysztof napisal wg mnie opinie, ktora sie wyklucza. Bo najpierw jest krytyka audytu IT, a potem wiele zdan, ktore pokazuja, ze audyt IT jest potrzebny. Wiele dzialow IT ma wlasnie z takim problemami doczynienia (wiem, bo sam pracowalem przez wiele lat jako - ogolnie rzec ujmujac - informatyk). Audyt jest po to, aby takie rzeczy wylapac, przedstawic jako to sie ma do wymagan biznesu i - najwazniejsze chyba - pokazac w jaki sposob naprawic te nieprawidlowosci (konkretnie, jak przepis kucharski, punkt po punktcie). Poza tym audyt IT nie daje tylko korzysci samemu dzialowi IT i jego pracownikom, ale rowniez stronie biznesowej. Znajac jej wymagania (np. wyrazone poprzez SLA), moze pokierowac prace IT tak, aby w jeszcze lepszym stopniu realizowala przyjete zalozenia. Bo czasami wewnatrz wydaje sie, ze wszystko gra, ale z zewnatrz i obiektywnie mozna zwrocic na pare spraw uwage.

Nie wszystko opiera sie na miedzynarodowych standardach Panie Radoslawie. Wazne jest tez, aby audytor IT posiadal wlasne doswiadczenie w IT, bo wtedy bedzie mogl postawic sie w roli informatyka i z jego perspektywy spojrzec, czy naprawa danych uchybien bedzie dla firmy korzyscia, czy np. koszty naprawy przewyzszaja sens takiego dzialania.

Pozdrawiam,
Kamil
Link do wypowiedziLink
Miłosław F.

Miłosław F. Architekt IT

Jeszcze slowo w obronie audytow.
Audyt robi osoba zewnetrzna, odporna na sytuacje i procesy, ktore istnieja "bo tak zawsze robilismy". Poza tym audyt obejmuje najczesciej wiele jednostek organizacyjnych i nawet jesli kazda z nich osobno dziala perfekcyjnie, to komunikacja pomiedzy nimi niekoniecznie. Osoby pracujace dluzszy czas w takim srodowisku najczesciej tego nie zauwazaja.
Dodatkowo audyt moze zasugerowac inne, lepsze rozwiazania, ktore nie sa wprowadzane, bo pracownicy sa przyzwyczajeni do aktaulnych. Dotyczy to wszystkich szczebli ;)

Przyklad: w wielu organizacjach "wersjonowanie" odbywa sie nadal recznie za pomoca katalogow i archiwow z datami. Wprowadzenie SVN, GIT czy czegos podobnego napotyka na opor, bo przeciez "trzeba sie tego znowu nauczyc".
Link do wypowiedziLink

konto usunięte

Odradzam skrajne opinie, bo oponent w dyskusji zaraz przytoczy masę przykładów, które udowonią, że nie masz racji.

Ameryki nie odkryję, jeśli napiszę, że z audytem IT jest dokładnie tak, jak z niemal każdym innym narzędziem biznesowym. W jednych rękach (w niektórych przypadkach) dadzą dobry efekt, a w innych będa jedynie stratą pieniędzy/czasu.

Znam wiele przypadków (również, a może zwłaszcza wśród największych polskich firm), gdzie wykonuje się mnóstwo audytów, których jedynym efektem jest kolejny segregator na półce.

Moja firma miała też przyjemność na rzecz potencjalnego, nowego inwestora prowadzić proces audytu pewnej organizacji IT. Na podstawie wniosków z tego audytu duży fundusz inwestycyjny podejmował decyzję o wydaniu (lub nie wydaniu) ponad 50 mln euro.

Prawda więc pewnie leży pośrodku?
Link do wypowiedziLink
Marek Kubiś

Marek Kubiś programista c#

Piotr Rutkowski:
Prawda więc pewnie leży pośrodku?
Zgadzając się z przesłaniem postawiłem plus, natomiast z tym pośrodku niekoniecznie stąd ten komentarz. ;-) Pośrodku czyli audytować w IT wszystko ale w ½? Czy jedno audytować drugie nie audytować? Czy czasami (kiedy się uzna za wskazane?) audytować? ..? ;-)))

Moje stanowisko - audytować ale tylko wtedy kiedy firma jest na tyle dojrzała, że wyniki audytu będą uwzględniane w procesie zarządzania i kiedy jest to uzasadnione biznesowo lub technologicznie. ;-)

Jednocześnie zgadzam się z głosami krytycznymi, bo pierwszy wpis to typowa reklama, która powinna znaleźć się w dziale "Ogłoszenia" i już choćby tylko z tego powodu, stając w sprzeczności z podstawowymi zasadami audytu (wskazywanie właściwego miejsca wszystkiemu czego dotyczy), podważa zasadność sugerowanego audytu. :-(

Ponadto zaproponowany pierwszym wpisem audyt do jednego worka wrzucił tak różne zagadnienia, że nic dziwnego, że wielu odpowie - nie dziękuję. ;-) Zapisać do loga zdarzenia wielu potrafi zrobić samodzielnie więc audyt przeprowadzą bez pomocy z zewnątrz i zapewne trafniej go przeprowadzą, gdyż "siedząc w temacie" lepiej się orientują co istotne a co nie, bo jak by się nie orientowali to by nie pracowali (o patologiach zatrudnienia nie dyskutujmy bo nie w tym rzecz). ;-)

Także wymienianie jednym tchem jako przedmiot i cel audytu kompleksu zagadnień nad którymi często muszą baaaardzo długo pracować, jak to określił kolega, całkiem "łebscy" ludzie, świadczy bardziej o oderwanych od rzeczywistości dobrych chęciach audytora (złą wolę podyktowaną chęcią tylko zarobku wykluczmy) niż o rzeczywistych szansach na spełnienie pokładanych oczekiwań i nie ma co się dziwić, że głosy bardzo krytyczne się pojawiają.

Przeprowadzić dobrze audyt nie jest prosto ale uczynić aby standardy (również audyt jako standard) były użyteczne i przestrzegane jeszcze trudniej, dlatego GOTO Moje stanowisko. ;-)
Link do wypowiedziLink
Michał Stępień

Michał Stępień Programista

Marek Kubiś:

Moje stanowisko - audytować ale tylko wtedy kiedy firma jest na tyle dojrzała, że wyniki audytu będą uwzględniane w procesie zarządzania i kiedy jest to uzasadnione biznesowo lub technologicznie. ;-)

Święta prawda. Warte zapamiętania.
Link do wypowiedziLink
Radosław Smilgin

Radosław Smilgin Konsultant i trener
testowania
oprogramowania i
ISTQB. 10...

Audytów zrobiłem już trochę i neguję audyty, które ślepo podążają za "modelem" (chyba, że komuś zależy na wspominanym segregatorze). Dobry audyt opiera się o doświadczonego audytora (audytorów), którzy nie są młodymi wilczkami, ale starymi wyjadaczami (i 10+ lat doświadczenia w IT może być mało). Skuteczność audytu silnie zależy od gotowości organizacji na przyjęcie zmiany.
No i na koniec nie ma najlepszych praktyk, bo nie ma uniwersalnych rozwiązań.
Link do wypowiedziLink
Marek Kubiś

Marek Kubiś programista c#

Radosław Smilgin:
Audytów zrobiłem już trochę i neguję audyty, które ślepo ..
Nie pokłócimy się. ;-)
No i na koniec nie ma najlepszych praktyk,
Są. ;-)
bo nie ma uniwersalnych rozwiązań.
Nie udowodni Pan prawdziwości powyższego twierdzenia. ;-)

Zaprzeczenie choćby poprzez iterację, dla prawdziwości której wystarczy choćby jeden przykład zaprzeczający Pańskiemu twierdzeniu. Np: "nie używaj GOTO" - podejmie się Pan dowodu, że to nie jest jedna z praktyk, która powinna być powszechnie stosowana, tak jak to życzyli sobie już dziadkowie dzisiejszych guru IT? ;-)))

Zgadzam się z Panem co do przesłania, bo zbyt łatwo, zbyt wielu nie tylko młodych, mówi co wie zamiast wiedzieć co mówi. ;-) Co do szczegółów wielu rozpędza się za daleko, ale formułowanie tak mocnego twierdzenia jak powyższe jest co najmniej niesprawiedliwe w odniesieniu np: do zasad SOLID (SRP, OCP, LSP, ISP, DIP) czy KiSS, DRY, TDA, YAGNI, SoC. ;-)))
Link do wypowiedziLink
Radosław Smilgin

Radosław Smilgin Konsultant i trener
testowania
oprogramowania i
ISTQB. 10...

: )
Zaprzeczenie choćby poprzez iterację, dla prawdziwości której wystarczy choćby jeden przykład zaprzeczający Pańskiemu twierdzeniu. Np: "nie używaj GOTO" - podejmie się Pan dowodu, że to nie jest jedna z praktyk, która powinna być powszechnie stosowana, tak jak to życzyli sobie już dziadkowie dzisiejszych guru IT? ;-)))

Z Pana stwierdzenia wynika, że skoro:
"używanie GOTO" jest złą praktyką
to
"nieużywanie GOTO" jest najlepszą praktyką. Ja składaniem się ku nazwie DOBRA praktyka. "Najlepsza" brzmi dość dogmatycznie.

Przyjmuję regułę: każda praktyka zależy od kontekstu.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Kazimierz Szpyt:
Zdecydowana większość audytów to
-- strata środków
-- strata czasu pracowników
-- niepotrzebna nerwówka dla pracowników
-- ITIL i COBiT, standardy ISO ładnie wyglądają na papierze, ale są w informatycznym światku nieużyteczne i nieprzestrzegane
-- pewna forma d...krytki
-- opis rozwiązań na które nie będzie zasobów finansowych i czasowych

w 100% powyższe "treści" mógłbym podać jako odpowiedź na pytanie "Czy projektowanie systemów przez ich przyszłych administratorów ma sens".

Jeszcze pewien sens widzę w audytach stricte technicznych np. dlaczego bazy danych się mulą, co jest wąskim gardłem w przetwarzaniu końca miesiąca, w jaki sposób można lepiej znormalizować dane, czy strony WWW padną przy dużym obciążeniu, czy hackerzy nie pokonają łatwo firmowych zabezpieczeń..

Moim zdaniem to jest akurat rola kompetentnych służb IT... (zarządzanie wydajnością, pojemnością, bezpieczeństwem itp.)

Audyty dokonywane przez szacownych konsultantów krawaciarzy z renomowanych firm nie uwzględniają mnóstwa specyficznych uwarunkowań

Jeżeli tak jest (nie wiem o kim mowa) to były to złe audyty.

Ale proponuję jedną rzecz: audyt z definicji jest porównaniem audytowanego "czegoś" z wzorcem, więc trudno mówić o audycie konkretnego systemu IT (nie istnieje jeden idealny system), można mówić o audycie wdrożenia konkretnej normy czy standardu. Ma sens audyt tam gdzie dział IT deklaruje stosowanie jakichś standardów.

Ale... jeżeli uznać, że zasoby IT służą biznesowi i są jakimś kosztem oraz stwarzają pewne ryzyko biznesowe to ma sens:
- analiza zasadności posiadania "każdego zasobu" (rentowność projektu)
- analiza ryzyka biznesowego stwarzanego przez konkretną architekturę systemu

Niestety wiele działów IT walczy o kolejne nowe technologie i certyfikaty nie z powodów biznesowych a czysto osobistego powodu budowania sobie CV i z tego powodu warto prowadzić audyt: stosowania najlepszych praktyk projektowania architektury (i wymienić je), stosowanie procedur przetargowych (lub wdrożyć jej jeśli ich nie ma w firmie) zarządzania ryzykiem ciągłości działania (bo np. wrzucenie wszystkiego na jeden serwer z wirtualizacią jest działaniem na szkodę firmy)

Niezależnie od formy (standardu) tak zwana Architektura Korporacyjne jest często nielubiana w działach IT bo te niestety bardzo często nie potrafią uzasadnić wielu poczynionych zakupów...

P.S.
Nie oferuję żadnych audytów jednak wielokrotnie, podczas analiz "stanu obecnego" (potrzebne np. do wyspecyfikowania wymaganych interfejsów wymaganych dla nowego systemu) odkrywam koszmarne niegospodarności ...Jarek Żeliński edytował(a) ten post dnia 10.03.13 o godzinie 20:50
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Moje stanowisko - audytować ale tylko wtedy kiedy firma jest na tyle dojrzała, że wyniki audytu będą uwzględniane w procesie zarządzania i kiedy jest to uzasadnione biznesowo lub technologicznie. ;-)

audyty (sensowne) służą właśnie uzyskiwaniu tej dojrzałości, to stanowisko brzmi troszkę jak "zaczniemy oszczędzać pieniądze dopiero jak będziemy bogaci, a na razie słusznie jesteśmy rozrzutni"...

chyba, że nie zrozumiałem stanowiska...
Link do wypowiedziLink
Marek Kubiś

Marek Kubiś programista c#

Jarek Żeliński:
Marek Kubiśi:
Moje stanowisko - audytować ale tylko wtedy kiedy firma jest na tyle dojrzała, że wyniki audytu będą uwzględniane w procesie zarządzania i kiedy jest to uzasadnione biznesowo lub technologicznie. ;-)
audyty (sensowne) służą właśnie uzyskiwaniu tej dojrzałości,
Audyt nie będzie narzędziem podążania w stronę dojrzałości, nie będzie przyczyniał się do doskonalenia, jeżeli wyniki audytu nie będą uwzględniane w procesie zarządzania. Tylko lub aż tyle, bo audytów z których raportów poza audytorami nikt nie czyta aż nadto. :-(
to stanowisko brzmi troszkę jak "zaczniemy oszczędzać pieniądze dopiero jak będziemy bogaci, a na razie słusznie jesteśmy rozrzutni"...
Skojarzenie niezauważające nietrafności pierwszej części wniosku i w efekcie niezgodne z intencją autora. :-( Stanowisko jest takie: Preinit -> Init -> InitComplete -> PreLoad -> Load -> Control Events -> Load Complete -> PreRender -> PreRenderComplete -> SaveStateComplete -> Render -> Unload
lub
BeforeUpdate (formularz) -> AfterUpdate (formularz) -> Exit (formant2) -> LostFocus (formant2) -> RecordExit (formularz) -> Current (formularz)
lub tp. ;-)
chyba, że nie zrozumiałem stanowiska...
Tak.
Radosław Smilgin:
: )
"Najlepsza" brzmi dość dogmatycznie.
No nie wiem czy podtrzymał by Pan stanowisko testując aplikację z powielonym wszędzie gdzie tylko się da kodem Ctrl-A + Ctrl-C + Ctrl-V, zamiast z kodem umieszczonym w jednej metodzie i jej wywoływaniem. ;-)
Przyjmuję regułę: każda praktyka zależy od kontekstu.
Pamiętam kiedy pierwszy raz przeczytałem słowo "najlepsze praktyki", postanowiłem pojechać na konferencję na której guru prosto z UK tłumaczyli co to jest, bo jakoś nie byłem przekonany czy właściwie rozumiem. Ponieważ po wysłuchaniu paru godzin wykładów moje wątpliwości nie opuściły mnie, na koniec kiedy otwarto panel dyskusyjny poprosiłem jeszcze raz o wytłumaczenie na przykładzie.

Skoro najlepsze praktyki są przeniesieniem wzorców które pozwoliły na odniesienie sukcesu, to jak ma postępować np: człowiek porwany przez lawinę. Jeżeli oprzeć się na relacjach tych co przeżyli, to jeden był tak przerażony, że znieruchomiał, cały zesztywniał i lawina tylko uniosła go na powierzchni i przeżył. Drugi tak się zakopał w śniegu, że próbując się wydostać machał rękoma i nogami tak jakby pływał żabką w wodzie i przeżył. Inny porwany zwinął się w kłębek i koziołkując niczym tocząca się piłka, pozostał na powierzchni i przeżył. Każdy teraz daje świadectwo swojej prawdzie, więc o co chodzi z tymi najlepszymi praktykami? ;-)))
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Marek Kubiś:
chyba, że nie zrozumiałem stanowiska...
Tak.

ok
:)
Skoro najlepsze praktyki są przeniesieniem wzorców które pozwoliły na odniesienie sukcesu, to jak ma postępować np: człowiek porwany przez lawinę. Jeżeli oprzeć się na relacjach tych co przeżyli, to jeden był tak przerażony, że znieruchomiał, cały zesztywniał i lawina tylko uniosła go na powierzchni i przeżył. Drugi tak się zakopał w śniegu, że próbując się wydostać machał rękoma i nogami tak jakby pływał żabką w wodzie i przeżył. Inny porwany zwinął się w kłębek i koziołkując niczym tocząca się piłka, pozostał na powierzchni i przeżył. Każdy teraz daje świadectwo swojej prawdzie, więc o co chodzi z tymi najlepszymi praktykami? ;-)))

One są statystyką, o dobrych praktykach w lawinach można mówić dopiero po ocenie np. kilkudziesięciu przypadków "przeżycia" pod warunkiem, że da się wskazać zachowania skorelowane z przypadkami przeżycia, w przeciwnym wypadku nie ma "dobrej praktyki" tak jak nie ma jej w wieli (wszystkich) dziedzinach sztuki. Ale np. w metodach obiektowych mamy taka dobra praktykę w postaci zaleceń SOLID czy wzorców projektowych (ich stosowanie jest "dobrą praktyką") co nie zmienia faktu, że nie są to reguły gwarantujące sukces a jedyne powiększające prawdopodobieństwo sukcesu.

Typowym przykładem dobrych praktyk są heurystyki (ale warto pamiętać, że one są wzorcami a nie prawami).

Wracając do tematu wątku, wydaje mi się, że audyt jak najbardziej ma sens pod warunkiem, że jest z sensem zaplanowany :)
Link do wypowiedziLink
Marcin Laskowski

Marcin Laskowski Inżynier/Specjalista
VoIP (Grandstream)

IMO audyt ma sens o ile ktoś zadał sobie trud zastanowienia się po co się go robi. Dobrze zrobiony powinien odpowiedzieć na ile dobrze dane zadanie jest wykonywane i jakie można wprowadzić poprawki z plusami i minusami konkretnych rozwiązań.
Link do wypowiedziLink
Kamil Jadczyszyn

Kamil Jadczyszyn Audytor IT

Dodam moze jeszcze, ze z tego co zauwazylem do tej pory, pracownicy dzialow IT nie maja pojecia o zasadach bezpieczenstwa i nie wiedza, ze istnieja standardy, ktore to okreslaja. Przykladow moglbym podac wiele, np. w firmie, ktora zatrudnia kilkadziesiat osob, posiada linie produkcyjna itp. trzymala w serwerowni tasmy backupowe w szufladzie.
Gdyby nie audyt IT, zwrocenie na to uwagi oraz zarekomendowanie zabezpieczenia tych nosnikow odpowiednio i przechowywanie poza serwerownia, mogloby to sie nigdy nie wydarzyc. Takich wykrytych ryzyk jest wiecej, wiec wydaje mi sie, ze warto robic audyty IT, uswiadamiac kadre informatyczna i podnosic - firma po firmie - jakosc uslug IT w Polsce, co przelozy sie na jakosc swiadczonych uslug biznesowych.
Link do wypowiedziLink
Tomasz Handschuh

Tomasz Handschuh Project Manager, IT
Manager, Agile PM,
Prince2, ITIL,
PMI...

Kamil Jadczyszyn:
Dodam moze jeszcze, ze z tego co zauwazylem do tej pory, pracownicy dzialow IT nie maja pojecia o zasadach bezpieczenstwa i nie wiedza, ze istnieja standardy, ktore to okreslaja.

??????
Wynika z tego, że w dziale IT sa zatrudnieni ludzie z 'łapanki', z 'ulicy' itp itd....
W takiej firmie nie jest potrzebny audyt IT, ale audyt HR i, nazwijmy to umownie, 'zarządu' z najwyższego poziomu i na zlecenie 'właściciela'. Oczywiscie, o ile właścicielowi zależy na istnieniu firmy....Tomasz Handschuh edytował(a) ten post dnia 11.03.13 o godzinie 12:41
Link do wypowiedziLink
Marcin Laskowski

Marcin Laskowski Inżynier/Specjalista
VoIP (Grandstream)

Tomasz Handschuh:
??????
Wynika z tego, że w dziale IT sa zatrudnieni ludzie z 'łapanki', z 'ulicy' itp itd....
W takiej firmie nie jest potrzebny audyt IT, ale audyt HR i, nazwijmy to umownie, 'zarządu' z najwyższego poziomu i na zlecenie 'właściciela'. Oczywiscie, o ile właścicielowi zależy na istnieniu firmy....

O ile to właściciel nie dał 3000 brutto i znajdź mi informatyka do HR :P
Link do wypowiedziLink
Tomasz Handschuh

Tomasz Handschuh Project Manager, IT
Manager, Agile PM,
Prince2, ITIL,
PMI...

Marcin Laskowski:
O ile to właściciel nie dał 3000 brutto i znajdź mi informatyka do HR :P

To znaczy, że właścicielowi nie zależy, a HR zatrudnia niewłaściwych ludzi. Po co 'informatyka' do HR?
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy



Wyślij zaproszenie do
Anuluj