Jarosław Żeliński

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

Krzysztof Torenc:
Żeby pisać muszę znać wymagania klienta, bez nich nie wiem co mam pisać :)

ufff..:)

Jeżeli są obszary niezdefiniowane (zdarza się) potwierdzam swoją wizję (sprawdzam czy uzyska ona akceptację) i dziergam dalej.

To sie nazywa prototypowanie "na czuja"
Dokumentacja wykonanego obszaru zawsze musi być dopasowana do standardu firmy - klient wie czy chce ode mnie dokumentację i jaką. Wie również ile kosztuje mój czas.

i tu sie nie raz pojawia kłopot, klient chce oszczędzić i rezygnuje z dokumentacji... co prawda podobno klient to nasz Pan ale co sie dzieje jak np. po nas za trzy lata przyjdzie ktos inny, spojrzy i powie: "no co Pan opowiada, ten wykonawca zostawił Pana bez dokumentacji? Ale partacz!"

P.S.
Ja dlatego nawet nie wpisuje w ofercie czegos takiego jak dokumentacja jako opcja :)Jarek Żeliński edytował(a) ten post dnia 03.09.09 o godzinie 14:01
Jarosław Żeliński

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

ROMAN WILK:
Ma Pan rację, po prostu strzeliłem tymi procentami, bo interesowała mnie odpowiedź Pana Jarka ...

a wystarczyło zapytac :)
Krzysztof T.

Krzysztof T. Software maker

Ciekawa ta nasza dyskucja, ale odjechalismy od tematu okrótnie ;)
Jarosław Żeliński

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

Krzysztof Torenc:
Ciekawa ta nasza dyskucja, ale odjechalismy od tematu okrótnie ;)

oj, nie ... cały czas toczy sie dyskusja czy powinno to być oprogramowanie dedykowane, gotowe i jak to wszystko udokumentowac :)
Krzysztof T.

Krzysztof T. Software maker

Jarek Żeliński:
[...]
Ja dlatego nawet nie wpisuje w ofercie czegos takiego jak dokumentacja jako opcja :)Jarek Żeliński edytował(a) ten post dnia 03.09.09 o godzinie 14:01

Jestem w lepszej sytuacji,
klient kontraktuje mój czas, przyklepuję terminy na określone prace w tym czasie. Wyrobię się szybciej - mój zysk, mam tyły - moja strata. Dodatkowe taski - dodatkowa kasa.
Innymi słowy klient wykupuje mój czas, ten przekładamy na planowane zadania - i w nich się rozliczamy.
Klient zatem wie czego chce. Jest zdecydowany jak chce wykorzystać mój czas.
Krzysztof T.

Krzysztof T. Software maker

Jarek Żeliński:
Krzysztof Torenc:
Ciekawa ta nasza dyskucja, ale odjechalismy od tematu okrótnie ;)

oj, nie ... cały czas toczy sie dyskusja czy powinno to być oprogramowanie dedykowane, gotowe i jak to wszystko udokumentowac :)

Juz od dawna nie toczy się dyskusja na ten temat :)
Wiemy juz ze dedykowane powinno być gdy takowe jest lepsze, w przeciwnym razie powinno byc gotowe.
Dokumentacja zawsze mile widziana - ale ta rozsądna. Niema sensu produkowac ton kwitów w które nikt nigdy nie zajrzy.
Jarosław Żeliński

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

Krzysztof Torenc:
Jestem w lepszej sytuacji,
klient kontraktuje mój czas, przyklepuję terminy na określone

no coż, ja juz nie mam tego komfortu, jestem rozliczany za dzieło a nie za czas.... w każdym razie rzadko i coraz rzadziej ludzie płaca analitykom i programistom na zasadzie czas i materiał.... zeby było śmieszniej sam takie rozliczenia odradzam klientom..
Jarosław Żeliński

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

Krzysztof Torenc:
Wiemy juz ze dedykowane powinno być gdy takowe jest lepsze, w przeciwnym razie powinno byc gotowe.
Dokumentacja zawsze mile widziana - ale ta rozsądna. Niema sensu produkowac ton kwitów w które nikt nigdy nie zajrzy.

no i po dyskusji :)
Krzysztof T.

Krzysztof T. Software maker

Jarek Żeliński:
Krzysztof Torenc:
Jestem w lepszej sytuacji,
klient kontraktuje mój czas, przyklepuję terminy na określone

no coż, ja juz nie mam tego komfortu, jestem rozliczany za dzieło a nie za czas.... w każdym razie rzadko i coraz rzadziej ludzie płaca analitykom i programistom na zasadzie czas i materiał.... zeby było śmieszniej sam takie rozliczenia odradzam klientom..

heh, i mamy winnego ! ;))))

Ja ostatnio mam inny dylemat. Wszechobecne oszczędności sprawiają, że firmy przejrzały swoje rachunki i dotarło do nich że konsultanci są drodzy.
Ostatnimi czasy z jaką korporacją bym nie gawędził rozpoznając potencjalny kontrakt to słyszę: "czy przejdzie Pan na etat ? to jedyna możliwa forma współpracy, innej teraz nie zdołamy przeforsować.".
:-|
Jarosław Żeliński

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

Krzysztof Torenc:
Ja ostatnio mam inny dylemat. Wszechobecne oszczędności sprawiają, że firmy przejrzały swoje rachunki i dotarło do nich że konsultanci są drodzy.

Na szczęscie ja jestem analitykiem i projektantem a nie konsultantem, tu oszczedności jest mało ;) co do konsultantów to moim zdaniem "wielkei firmy" zniszczyły wizerunek tego fachu negocjując umowy na wielkie kwoty za dniówke i wysyłając studentow do pracy w projektach.
Ostatnimi czasy z jaką korporacją bym nie gawędził rozpoznając potencjalny kontrakt to słyszę: "czy przejdzie Pan
na etat ? to jedyna możliwa forma współpracy, innej teraz nie
zdołamy przeforsować.".

tez tak słysze, ale jest cos fajnego ostatnio: umowa o prace na wykonanie zadania :), polecam. Inaczej tez kalkuluje sie projekt na kilkanaście roboczo dni a inaczej na kwartał czy nawet rok.

Oszczedności ja odczuwam inaczej: firmy zaczynają analizować ryzyko i coraz częściej nie dyskutuja ze mną o koszcie dniówki (o ile jest rozsadna ;)) a o referencjach...
Krzysztof T.

Krzysztof T. Software maker

Jarek Żeliński:

Na szczęscie ja jestem analitykiem i projektantem a nie konsultantem,
ja jestem koderem/projektantem - jednak praca z pozycji wolnego strzelca to skakanie między firmami (czasem jest dość długi łancuszek firm na drodze faktury) - no czyli konsulting (praca w biurach klienta, w jego zespołach, itd.).
tu oszczedności jest mało ;) co do konsultantów to moim zdaniem "wielkei firmy" zniszczyły wizerunek tego fachu negocjując umowy na wielkie kwoty za dniówke i wysyłając studentow do pracy w projektach.

nie sposób zaprzeczyć
Ostatnimi czasy z jaką korporacją bym nie gawędził rozpoznając potencjalny kontrakt to słyszę: "czy przejdzie Pan
na etat ? to jedyna możliwa forma współpracy, innej teraz nie
zdołamy przeforsować.".

tez tak słysze, ale jest cos fajnego ostatnio: umowa o prace na wykonanie zadania :), polecam. Inaczej tez kalkuluje sie projekt na kilkanaście roboczo dni a inaczej na kwartał czy nawet rok.

Oszczedności ja odczuwam inaczej: firmy zaczynają analizować ryzyko i coraz częściej nie dyskutuja ze mną o koszcie dniówki (o ile jest rozsadna ;)) a o referencjach...


czym się to różni od umowy o dzieło (w kontekscie firma-firma) ?
Możesz mi na priv wrzucić jak przykładowo wzrastają Twoje stawki (np procentowo) wraz ze skróceniem terminu projektu ? (nawijają mi się ostatnio bardzo krótkie projekty - i mam spory dylemat jak je szacować).
Lech D.

Lech D. Doradca
Biznesowo-informatyc
zny, Kierownik
Projektów IT (...

oj, nie ... cały czas toczy sie dyskusja czy powinno to być oprogramowanie dedykowane, gotowe i jak to wszystko udokumentowac :)

nie zostalo doprecyzowane co sie uwaza za oprogramowanie dedykowane, a co za oprogramowanie gotowe.

ja rozumiem pod pojeciem "oprogramowanie gotowe" taki soft, ktory wyjmujemy z pudelka, instalujemy, uruchamiamy i dzialamy produktywnie (po jakiejs drobnej parametryzacji) - jako przyklad podam programy firmy Lefthand.

system juz gotowy, na ktorym pracuja produktywnie klienci, a co za tym sprawdzony i przetestowany rowniez w "boju", jednakze wymagajacy dokonfigurowania pod kontretne potrzeby danego klienta, uwazam za "rozwiazanie dedykowane" - przykladem niech bedzie People Soft.

natomiast "system ERP" pisany od zera pod potrzeby danego klienta, to w/g mnie rozwiazanie chalupnicze.Lech Dzierżawski edytował(a) ten post dnia 03.09.09 o godzinie 18:20
Roman Wilk

Roman Wilk Tak właściwie, to
gram dużo w squash'a
:), ale to wciąż
z...

Jarek Żeliński:
Krzysztof Torenc:
Wiemy juz ze dedykowane powinno być gdy takowe jest lepsze, w przeciwnym razie powinno byc gotowe.
Dokumentacja zawsze mile widziana - ale ta rozsądna. Niema sensu produkowac ton kwitów w które nikt nigdy nie zajrzy.

no i po dyskusji :)

Obawiam się Pani Jarku, że to "niestety" dopiero początek dyskusji :)

Po analizie Pana wypowiedzi, mogę je podsumować tak (to oczywiście moja interpretacja)

1. ERP to może być konglomerat, modułów/ Aplikacji różnych producentów np. jak Pan pisze FK to komponent, który można wykorzystać jako składnik "dedykowanego" oprogramowania
2. z 1 wynika wniosek, iż do ogarnięcia dzieciny tak zdefiniowanego ERP'a może zostać użytych kilka różnych (oczywiście opartych na SQL) baz danych
3. z 2 wynika, że mogą zostać użyte różne platformy systemowe (również zazwyczaj hardware, choć to można ładnie dziś załatwić wirtualizacją)
4. z 3 wynika, że mamy kilku Adminów (bo np. jedna baza to Oracle, druga DB2, a trzecia MS Server)
5. z 4 wynika, że koszty zarządzanie samymi bazami będą wyższe, niż składowanie wszystkiego na jednej bazie w gotowym ERP np. SAP
6. z 4 wynika, że podstawowa zaleta jedne bazy danych to tzw. "atomowość transakcji" (czyli, wszyskie procesy biznesowe na bazie i ERP'e albo są spójne, albo ich nie ma ...)
7. z 4 wynika, iż podnoszenie wersji softu i wersi baz danych to "koszmar"
8. z 1 wynika, iż w przypadku ewentualnych błędów w działaniu tej "hybrydy", mamy klasyczny przypadek spychologii dostawców ...
9. z 1 wynika, iż pracownicy muszą się, uczyć inferfejsów i działania każdej Aplikacji (bo w jednej F2 to wybór czegoś tam, a drugiej do szukaj coś tam)

Lista wątpliwości jeszcze długa..., ale to są moje najpoważniejsze wątpliwości odnoście Pan wizji "dzisiejszego" ERP. W pana wersji ERP'a "dedykowanego" widzę same dziury logiki biznesowej + koszmarne koszty utrzymania tego rozwiązania + .... (mogę jeszcze wymienić kilka innych wad)

pozdrawiam
Krzysztof T.

Krzysztof T. Software maker

Kilka nieścisłości tu widzę:
1 - nadal brak określenia wielkości systemu (z tego co Pan pisze, @Romanie, wynika że chodzi o sysem olbrzymi)

ad.3: z technicznego punktu widzenia to nie stanowi problemu. Wszystko kwestia techniki spinania podsystemów.

ad.4: praktyka wykazuje, iż nie jest konieczne zatrudniać osobnego admina do każdej bazy danych.

ad.5: tem punkt zostaje obalony wraz z obaleniem pkt 4.

ad.7: podnoszenie wersji softu nie stanowi problemu z dokładnościa do spójności interfejsów (jakiekolwiek nie były by uzyte do spinania podsystemów).
Podnoszenie wersji bazy danych jest równie kopotliwe dla obu rozważanych wariantów.

Tyle moich uwag technicznych.
Punkty 3,4,5,7 uważam za nietrafione.

PS. nadal uważam że nie istnieje możliwość wykazania jednoznacznej przewagi któregokolwiek z wariantów - inaczej rynek empirycznie wykazał by wyższość jednego nad drugim.
Roman Wilk

Roman Wilk Tak właściwie, to
gram dużo w squash'a
:), ale to wciąż
z...

Krzysztof Torenc:
Kilka nieścisłości tu widzę:
1 - nadal brak określenia wielkości systemu (z tego co Pan pisze, @Romanie, wynika że chodzi o sysem olbrzymi)
Ma Pan racje, chodzi raczej o duży system, ale z wypowiedzi Pana Jarka wnioskuje, iż z jego doświadczenia to właśnie "dedytowane" system są stosowane w dużych korporacjach (z tym się zgodzę, sam mam kilku znajomych PM pracujących w działach IT tych korporacji i utrzymujących te "dedykowane" systemy). Bo moim zdaniem mała / średnia firma nie ma szans na utrzymanie "dedykowanych rozwiązań"

ad.3: z technicznego punktu widzenia to nie stanowi problemu. Wszystko kwestia techniki spinania podsystemów.
Diabeł tkwi w szczegółach (obydwaj o tym wiemy), ale nie kwestionuje Pan, iż jedna baza danych to najlepsze rozwiązanie

ad.4: praktyka wykazuje, iż nie jest konieczne zatrudniać osobnego admina do każdej bazy danych.

Zgadzam się w 100 %, tylko tyle, że będzie on (Admin) odpowiednio droższy dla firmy
ad.5: tem punkt zostaje obalony wraz z obaleniem pkt 4.
OK...
ad.7: podnoszenie wersji softu nie stanowi problemu z dokładnościa do spójności interfejsów (jakiekolwiek nie były by uzyte do spinania podsystemów).
Podnoszenie wersji bazy danych jest równie kopotliwe dla obu rozważanych wariantów.
Tylko tyle, że prościej (mniej pracy) jest podnosić jedną bazy (a dla firm produkcyjnych często nie ma zbyt wiele czasu, na tzw. przerwy technicze)
Tyle moich uwag technicznych.
Punkty 3,4,5,7 uważam za nietrafione.

PS. nadal uważam że nie istnieje możliwość wykazania jednoznacznej przewagi któregokolwiek z wariantów - inaczej rynek empirycznie wykazał by wyższość jednego nad drugim.

Nigdy nie sprawdzałem, żadnej statystyki na ten temat, ale pewnie bym się założył, iż na 100 wybranych pod kątem obrotu firm, 70 % korzysta z "gotowego" ERP'a
Krzysztof T.

Krzysztof T. Software maker

ROMAN WILK:

ad.3: z technicznego punktu widzenia to nie stanowi problemu. Wszystko kwestia techniki spinania podsystemów.
Diabeł tkwi w szczegółach (obydwaj o tym wiemy), ale nie kwestionuje Pan, iż jedna baza danych to najlepsze rozwiązanie
Oczywistym jest, ze spójny system bazodanowy jest zaletą.
(Zwłaszcza pod kątem redundantności).
ad.7: podnoszenie wersji softu nie stanowi problemu z dokładnościa do spójności interfejsów (jakiekolwiek nie były by uzyte do spinania podsystemów).
Podnoszenie wersji bazy danych jest równie kopotliwe dla obu rozważanych wariantów.
Tylko tyle, że prościej (mniej pracy) jest podnosić jedną bazy (a dla firm produkcyjnych często nie ma zbyt wiele czasu, na tzw. przerwy technicze)

OK, ilość baz danych jest argumentem z którym trzeba się liczyć - może mieć wpływ na częstość zmian.
PS. nadal uważam że nie istnieje możliwość wykazania jednoznacznej przewagi któregokolwiek z wariantów - inaczej rynek empirycznie wykazał by wyższość jednego nad drugim.

Nigdy nie sprawdzałem, żadnej statystyki na ten temat, ale pewnie bym się założył, iż na 100 wybranych pod kątem obrotu firm, 70 % korzysta z "gotowego" ERP'a

a na 100 wybranych kolosów (każdy w innej branży) ?
Żeby coś więcej powiedzieć musieli bysmy mieć porównawczą statystykę jaki procent firm siedzi w ogólnie pojętych "standardach", a jaki procent zajmuje nietypowe nisze.
Przykładowo - jeżeli obejrzy Pan europejskie fabryki mebli - to prawdopodobnie nigdzie nie znajdzie Pan standardowego ERP, no chyba że uzna Pan za standardowe "niestandardowe ERP wyspecjalizowany dla niszy wytwórstwa meblowego" które i tak za kazdym razem musi być dociągane chociaż spina już właściwie holdingi fabryk mebli.

I tu się rodzi kolejne pytanie - czy oprogramowanie dedykowane dla danej niszy to oprogramowanie jeszcze dedykowane czy juz standardowe ?Krzysztof Torenc edytował(a) ten post dnia 03.09.09 o godzinie 21:23
Jarosław Żeliński

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

Lech Dzierżawski:
natomiast "system ERP" pisany od zera pod potrzeby danego klienta, to w/g mnie rozwiazanie chalupnicze.

dlaczego?
Roman Wilk

Roman Wilk Tak właściwie, to
gram dużo w squash'a
:), ale to wciąż
z...

Krzysztof Torenc:
a na 100 wybranych kolosów (każdy w innej branży) ?
Żeby coś więcej powiedzieć musieli bysmy mieć porównawczą statystykę jaki procent firm siedzi w ogólnie pojętych "standardach", a jaki procent zajmuje nietypowe nisze.
Przykładowo - jeżeli obejrzy Pan europejskie fabryki mebli - to prawdopodobnie nigdzie nie znajdzie Pan standardowego ERP, no chyba że uzna Pan za standardowe "niestandardowe ERP wyspecjalizowany dla niszy wytwórstwa meblowego" które i tak za kazdym razem musi być dociągane chociaż spina już właściwie holdingi fabryk mebli.

I tu się rodzi kolejne pytanie - czy oprogramowanie dedykowane dla danej niszy to oprogramowanie jeszcze dedykowane czy juz standardowe ?
Roman Wilk

Roman Wilk Tak właściwie, to
gram dużo w squash'a
:), ale to wciąż
z...

Jak najbardziej standardowe, tym bardziej, że "przeważnie" jego autorem jest firma, która dysponuje już rozwiązaniem ERP i na bazie tego tworzy "specjalizowane" moduły.
Uważam, że na pisanie ERP (mam na myśli zintegrowane rozwiązanie na jedne bazie danych :
1. Księga główna (oczywiście w full opcji))
2. Gospodarka magazynowa
3. Obsługa zamówień
4. coś na wzór MRP (ale nie koniecznie super wypasione))
od podstaw to jak ktoś już się wcześniej to po prostu chałpnictwo
Jarosław Żeliński

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

ROMAN WILK:
Lista wątpliwości jeszcze długa..., ale to są moje najpoważniejsze wątpliwości odnoście Pan wizji "dzisiejszego"

1. rozwiazania dedykowane wzięły się z tego, że wielki szwajcarski scyzoryk czasem nie ma jakiegoś potrzebnego ostrza i wtedy mamy dwa scenariusze:
- kupić jeszcze większy scyzoryk tylko po to by korzystać z czterech potrzebnych ostrzy
- mieć mały scyzoryk i finkę do czego pewnie ma przekonanie każdy wyżarty harcerz, nawet największy i najlepszy i najbardziej uniwersalny scyzoryk jest tylko wielkim nieporadnym molochem, zaleta polegająca na tym, że nosi się go w jednej dedykowanej pochwie jest zaletą pozorną bo i tak zajmuje więcej miejsca niż dwa małe noże.

Zwracam uwagę, że sensowny system IT ma:
1. jedną spójna warstwę sprzętową
2. jedną bazę danych (motor bazy)
3. można na tym "postawić" dowolna ilość dedykowanych i zintegrowanych aplikacji

administrator platformy to jedna, dwie osoby
każda aplikacja ma najczęściej dziedzinowego specjalistę

Pan niestety opisał bałagan a nie dobrze zaprojektowany system ot choćby w architekturze SOA czy podobnej...

moja wątpliwość to ta, ze nie widział Pan chyba w działaniu np. systemu w jakimś np. banku czy dajmy na to większym urzędzie, gdzie nikt rozsądny nie kupi "jednego wielkiego gotowego dla urzędu fajnego systemu od wszystkiego".

świat nie zawsze jest taki prosty jak hurtownia butelek czy producent mebli giętych, są firmy których przewaga na rynku polega na tym, ze różnią się od wszystkich konkurentów, nie raz nawet firmy w tej samej branży maja różne modele danych a szwajcarski scyzoryk ma zawsze jeden model danych.

Gdyby powyższe było nieprawdą to hurtownie danych były by gotowymi systemami z pudełka a jakoś nie są...

Powiem więcej: nie raz łatwiej i taniej np. kupić finanse i produkcję w SAP, zintegrować mu krajowy CRM i dodać dedykowany system obiegu dokumentów, obawiam się, że to wyjście kilkukrotnie tańsze i nie raz lepsze dla klienta niż cały komplet z SAP, do tego z reguły pakiety są licencjonowane w całości na użytkowników a nie raz potrzebne jest kilku użytkowników w każdej dziedzinie.

Po czwarte nie przypadkiem nowe wersje wielu systemów ERP można kupić w kawałkach a całość ma wbudowane API i konfigurowalny interfejs np. AXAPTA v.4.0, od ludzi wdrażających AXAPTĘ słyszałem, ze czasem zamiast grzebać w AXAPCIE lepiej dopisać "na boku" modulik i zintegrowac go.

Na koniec zapytam: mamy jeden system ERP i w nim mnóstwo przeróbek by dopasować go do potrzeb klienta, jak wygląda upgrade tego do nowej wersji? czy przypadkiem nie trzeba całego wdrożenia wykonać niemalże od zera? Czy może "wgrywamy" nową wersje wieczorem a rano startujemy na nowej ?

Wyślij zaproszenie do