Temat: System ERP

Od dłuższego czasu przymierzamy sie zakupu systemu ERP do firmy. Chcemy zorientowac sie jaki system byłby do malej firmy. Chcialem tu dodac ze firma zatudnia okolo 60 - 70 osob w roznych krajach na swiecie. Chcialibysmy zeby to byl system:
- latwy w obsludze
- przystepny dla kazdego uzytkownika
- przystepny cennowo
- w jezyku angielskim
Zajmujemy sie produkcja urzadzen elektronicznych wiec taki system potrzebny bylby nam do kontrolowania zasobow a takze zakupu czesci, plytek elektronicznych itp.

Prosze o opinie i rady jakis syetem mozna by wybrac ?

Temat: System ERP

Witam.
Jesli to Panu pomoze to prosze sie zapoznac z ofartą formy ComArch S.A. a dokladnie z produktem CDN XL.

http://www.comarch.pl/cdn/Products/CDN+XL

Temat: System ERP

Osobiście bał bym sie polecić cokolwiek nie znając Waszych wymagań. Wymagania biznesowe (!) mieszczące się w pięciu linijkach tekstu to kluczowe ryzyko tego zakupu........

Sugeruję przysiąść fałdów z zarzadem (tak z Zarządem!), powiedzieć sobie "na grzyba mi ten ERP", w razie kłopotów z odpowiedzią na to pytanie proponuje podejście do oceny rentownosci tego wdrożenia, a z tej oceny wyjdzie budżet a potem to już z górki, są systemy po 300zł i po 3 mln. a wielkość firmy nie ma tu nic do rzeczy poza ewentualną wyceną liczby licencji.

Pytam czasem niektóre firmy ile wydali na swój system, potem pytam
dlaczego nie 100 tys. mniej lub 100 tys. wiecej i nie wiedzą... to kiepsko...

to tak na ostudzenie zapału....Jarosław Żeliński edytował(a) ten post dnia 15.07.07 o godzinie 19:02

Temat: System ERP

Ja odsyłam w kolejności do ;
- Sage
- BPSC
- Oracle

Temat: System ERP

Paweł T.:
http://www.comarch.pl/cdn/Products/CDN+XL

Wybacz, że wyrażę opinię.
Comarch to taki drugi Prokom - lepiej z daleka

pisałem już program, który omija wasze udogodnienia z simika ...

- do tematu:

Najlepszy sposób to żadne ERP'y tylko zatrudnić programistę
albo nawiązać z którymś współpracę.

W zależności od wielkości firmy, albo jeden albo więcej
albo stworzyć dział deweloperski IT.

Molochy informatyczne najpierw wyżyłują za program, potem za wdrożenie a potem stały abonament za serwis i porpawianie błędów.
Przy czym często wcale nie są szybsi i sprawniejsi od jednego studencika informatyki, który zrobi to samo za miskę ryżu.

Temat: System ERP

Maciej F.:
Najlepszy sposób to żadne ERP'y tylko zatrudnić programistę
albo nawiązać z którymś współpracę.

Najlepszy sposób na co?
A jak programista zachoruje/zechce zmienić pracę? Kto będzie utrzymywał przygotowany przez niego produkt?

W zależności od wielkości firmy, albo jeden albo więcej
albo stworzyć dział deweloperski IT.

Ile będzie kosztowało utworzenie i utrzymanie takiego działu?
Czy jeden programista - albo nawet cały ich zespół - jest w stanie napisać coś na kształt dedykowanego systemu ERP (bo o kompleksowym systemie mówimy)? czy taki zebrany ad hoc zespół posiada doświadczenia porównywalne z producentem lub firmą wdrażającą na co dzień ERP?
Czy taki zespól jest w stanie przygotować produkt na tyle uniwersalny, by w razie zmiany procesów biznesowych można go było łatwo przystosować?

Jedyne, czego wart jest własny "zespół informatyków", to wiedza merytoryczna (jeśli dotyczy oprogramwoania do zarządzania, bazodanowego czy infrastruktury IT, a nie np. programwania mikroprocesorów do pralek) pozwalająca na kontrolowanie dostawcy systemu ERP. I to jeszcze pod warunkiem, że informatycy będą mieli na względzie potrzeby biznesowe, a nie techniczne widzimisie.

Molochy informatyczne najpierw wyżyłują za program, potem za wdrożenie a potem stały abonament za serwis i porpawianie błędów.

Te molochy konkurują ze sobą, mają doświadczenie producenckie i wdrożeniowe. Utrzymywać produkt i tak ktoś musi, choćby ze względu na częste w naszym kraju zmiany prawne. Własny "zespół programistów" raczej nie zrobi tego taniej.

Przy czym często wcale nie są szybsi i sprawniejsi od jednego studencika informatyki, który zrobi to samo za miskę ryżu.

Szybsi to może i nie są, ale ja swoich pieniędzy nie powierzyłbym oprogramowaniu faceta pracującego za miskę ryżu.

Ogólnie jestem przeciw chałupniczym sposobom załatwiania poważnych problemów. To działa na krótką metę, w dłuższym horyzoncie czasowym kosztuje więcej.

Co zaś tyczy się samego pytania:
- zastanówcie się, czego właściwie potrzebujecie, jakie procesy biznesowe chcecie w pierwszej kolejności wspierać?
- czy ERP zaspokoi większość potrzeb informacyjnych czy też trzeba będzie pointegrować go z innymi systemami?
- jakim doświadczeniem dysponuje dostawca systemu/usługi wdrozeniowej?

Oprócz wspomnianego CDN dla firm Waszej wielkości odpowiednie mogą być pakiety Microsoftu (Dynamics AX/Axapta), firmy TETA (Biznes Partner?), "mały" SAP Business One, SM-Boss oferowany przez Solemis Group, MFG/Pro firmy QAD zy BPCS (Impuls?). Mam nadzieję, że nie pomyliłem nazw - piszę z pamięci. Konkretny system trzeba dostosować do wymagań. Nie trzeba kupować w całości - zazwyczaj cenę negocjuje się indywidualnie, w zależności od liczby wdrażanych modułów i zakresu wdrożenia.

Pociągnijcie poszczególnych dostawców, podpuśćcie ich trochę ("wiecie, a konkurencja w tej cenie daje nam to i to") - zobaczcie,ile da się zbić cenę ;)Maciej K. edytował(a) ten post dnia 28.07.07 o godzinie 09:22

Temat: System ERP

Maciej F.:
Najlepszy sposób to żadne ERP'y tylko zatrudnić programistę
albo nawiązać z którymś współpracę.

W zależności od wielkości firmy, albo jeden albo więcej
albo stworzyć dział deweloperski IT.

Czyli założyć sobie własną firemkę produkującą oprogramowanie i utrzymac ją.

Molochy informatyczne najpierw wyżyłują za program, potem za wdrożenie a potem stały abonament za serwis i porpawianie błędów.

To jakaś teoria spisku i żalu?

Przy czym często wcale nie są szybsi i sprawniejsi od jednego studencika informatyki, który zrobi to samo za miskę ryżu.

Przykłady? Bo ja znam dokładnie odwrotne: jeden lub dwóch z kolegą bez żadnej analizy i projektu metodą prób i błedów dydoliło trzy lata, nie miało to potem dokumentacji coś co można było kupić i wdrożyć za pół roku. Oczywiście panowie obiecali że oni to w kwartał wydziargają.

Temat: System ERP

[author]Jarosław

Link do wypowiedzi

Temat: System ERP

Ano ogólnie polecał bym szukajacym dla siebie systemów analizę potrzeb i ryzyka swoich pomysłów. Proste i nie kluczowe dla firmy systemy można kleić na gumę do żucia i zapałki. Jak cos walnie to mała strata. Ale nie przymyślany zakup systemu nawet za 400zł (nieskomplikowany pakiet finansowo magazynowy) może narazić niejedną firmą na straty rzędu setek tysięcy obrotów więc nie prawdą jest że "to tylko 400zł na program komputerowy do fakturowania".

Jako analityk widuję projekty bez dokumentacji i nie ja a klinci po czasie sie dziwią, że inny "programista za miske ryżu" chce kupe kasy za poprawki w systemie bo zanim wykona prosta robotę za 200zł musi kopać miesiąc w kodzie a to kosztuje juz np. 4000zł.

Polecam wykonywanie nawet przybliżónych analiz rentownosci takich projektów łącznie z kosztami krachu projektu (ryzyko). Kupując programik za 400zł nabywamy narzędzie do zarządzania np. 100.000 obrotu miesięcznie. Jak coś nie wyjdzie narażamy się na potencjalne straty, koszty awaryjnej obsługi klientów, być moze straty części transakcji. Może to być kilkadziesiąt tysięcy i więcej.

Temat: System ERP

Maciej K.:

Maciej F.:
Najlepszy sposób to żadne ERP'y tylko zatrudnić programistę
albo nawiązać z którymś współpracę.

Najlepszy sposób na co?
A jak programista zachoruje/zechce zmienić pracę? Kto będzie utrzymywał przygotowany przez niego produkt?

W zależności od wielkości firmy, albo jeden albo więcej
albo stworzyć dział deweloperski IT.

Ile będzie kosztowało utworzenie i utrzymanie takiego działu?
Czy jeden programista - albo nawet cały ich zespół - jest w stanie napisać coś na kształt dedykowanego systemu ERP (bo o kompleksowym systemie mówimy)? czy taki zebrany ad hoc zespół
posiada doświadczenia porównywalne z producentem lub firmą wdrażającą na co dzień ERP?

Też uważam, że jest to najlepszy sposób.
Pod warunkiem, że mówimy o zarządzanym zespole IT a nie przypadkowej zbieraninie programistów (może nawet wybitnych fachowców)
To jest podobnie jak przy budowie, jak buduję dom jednorodzinny
mogę skorzystać z "typowego" projektu (+ przeróbki).
Ale jaki sens ma, przy budowaniu zakładu przemysłowego
korzystanie z "typowego" projektu zakładu przemysłowego... ?

Zalety własnego zespołu IT:
1. Firma jest niezależna od zewnętrznych dostawców oprogramowania
(czy ktoś rozważał, co się stanie, jeżeli mam produkt firmy X,
i ta firma upadnie lub firma Y dokona np. wrogiego przejęcia tej firmy i ją zlikwiduje)
2. Wiedza zostaje w firmie (nie każdy chce, żeby jego unikalne
rozwiązania były wykorzystywane do poprawy działania konkurencji
albo żeby konsultanci mogli sprawdzić obroty/zysk firmy).
Po kilku latach, firma jest już uzależniona od dostawcy ERP.
3. Oprogramowanie rośnie razem z firmą, (najpierw samochód dostawczy później ciężarówka) wiedza użytkowników też rośnie w miarę rozwoju systemu.
4. Oprogramowanie może stać się istotnym elementem przewagi konkurencyjnej.
5. Przy obecnej prędkości rozwoju komputerów i oprogramowania
co kilka lat 3-8 należy zmienić technologię na nowszą
(wdrożenie nowego systemu ERP (zewnętrznego) to 6-18 m-cy w zalezności od wielkości), przy własnym systemie możemy dokonać tego w sposób "ewolucyjny"
6. Czas modyfikacji oprogramowania w reakcji na zmieniające się przepisy (szczególnie w Polsce) przy własnym zespole jest krótszy.
7. Proponuję sprawdzić ile tak naprawdę osób tworzyło komercyjne systemy ERP, mam na myśli kluczowych programistów/architektów systemu, a nie całą listę płac ;) - tak na prawdę jest to kilka najwyżej kilkanaście osób - tyle wystarczy, żeby taki system zbudować w sensownym czasie.
8. Własny system ERP podlega dobroczynnemu wpływowi "efektu zużycia" (patrz: David Brin "Stare jest piękne") czyli jeżeli system choć trochę działa to możemy go "zużywać" czyli poprawiać jego działanie i rozwijać dążąc dokładnie do tego co uzytkownik potrzebuje.

Wady:
1. Wdrożenie też może się nie udać ;)
2. Jeżeli możemy wykorzystać "typówkę" to po co przepłacać

Temat: System ERP

Piotr W.:
Też uważam, że jest to najlepszy sposób.

No i tak czytam i czytam i jak postawię kilka warunków w rodzaju: zespół dobrze zarządzany, projekt dobrze zarządzany, projekt dobrze udokumentowany ....

to zapomnijmy o kosztach typu miska ryżu, to się niczym nie różni od porządnej firmy IT.

Temat: System ERP

Piotr W.:

Po kilku latach, firma jest już uzależniona od dostawcy ERP.

Nie więcej niż od każdego innego produktu. Kupujesz maszyny do linii produkcyjnej i też uzależniasz się od dostawcy. Każda inwestycja to jakiś balast historyczny i koszty utopione.

Rozumując w ten sposób można by dojść do wniosku, że wszystko (budynki, samochody, sprzęt biurowy) firma powinna zrobić sama. Kiedyś tak właśnie robiono, nie przez przypadek się od tego odchodzi - po prostu koncentracja na "core business" jest bardziej efektywna ekonomicznie.

4. Oprogramowanie może stać się istotnym elementem przewagi konkurencyjnej.

Albo kulą u nogi.

Pod warunkiem, że mówimy o zarządzanym zespole IT a nie przypadkowej zbieraninie programistów (może nawet wybitnych fachowców)

Czyli miska ryżu zamiast porządnej pensji - odpada.

1. Wdrożenie też może się nie udać ;)

Przy firmie, która nie działa w branży informatycznej ryzyko porażki jest spore.

2. Jeżeli możemy wykorzystać "typówkę" to po co przepłacać

I to praktycznie zamyka sprawę. Po co wyważać otwarte drzwi?

Temat: System ERP

Maciej K.:

A jak programista zachoruje/zechce zmienić pracę? Kto będzie utrzymywał przygotowany przez niego produkt?

Trochę oderwane od rzeczywistosci pytanie.
Programista tworzy soft, a pracują na nim pracownicy firmy,
od utrzymania baz danych są bazowcy a nie programiści
- a już na pewno nie firmy piszące programy.
To zupełnie odrębny temat.

Z programistą podpisujesz umowę, ustalasz terminy i kary za zwłokę i nie obchodzi Cię to czy choruje czy nie.

Ile będzie kosztowało utworzenie i utrzymanie takiego działu?
Czy jeden programista - albo nawet cały ich zespół - jest w stanie napisać coś na kształt dedykowanego systemu ERP (bo o kompleksowym systemie mówimy)?

Wszystko zależy od wielkości i potrzeb firmy.
Dla dużych przedsiębiorstw wystarczy zespół 4-10 osób.

czy taki zebrany ad hoc zespół posiada doświadczenia porównywalne z producentem lub firmą wdrażającą na co dzień ERP?

Twój problem w tym, żeby zatrudnić ludzi z właściwymi predyspozycjami. Napewno nie może to być zespół ad hoc.

U nas w firmie ściągnęliśmy jednego młodego wykładowce pewnej szkoły IT, on nam polecił zdolniejszych studentów - są naprawdę dobrzy.

Jeżeli chodzi o porównanie z firmami "kobyłami"
Takie kobyły jak Prokom czy Comarch - jadą na opinii - miałem z nimi dużo do czynienia i uwierz mi, nie polecił bym nikomu - chyba że konkurencji :)

Czy taki zespól jest w stanie przygotować produkt na tyle uniwersalny, by w razie zmiany procesów biznesowych można go było łatwo przystosować?

Jeżeli dobrzy programiści i znają wszystkie tajniki programowania obiektowego, normalizacji i optymalizacji SZBD - to tak.

Obecne narzędzia i technologie programistyczne tak są tworzone, żeby umożliwić jak bardziej elastyczność softu.

Jedyne, czego wart jest własny "zespół informatyków", to wiedza merytoryczna (...) pozwalająca na kontrolowanie dostawcy systemu ERP.

No cóż. masz swoje zdanie ja mam swoje.
Wierzę, że z czasem mentalność zarządów dużych firm w tej kwestii ulegnie zmianie.

Te molochy konkurują ze sobą, mają doświadczenie producenckie i wdrożeniowe.

Widać nie wiesz o czym mówisz. Taki jeden moloch stworzył "Płatnika", zadzwoń do swojego działu rozliczeń i zapytaj o opinię.
Ja mam pewne z nimi doświadczenie, poza płatnikiem. Ale jak uważasz.

Utrzymywać produkt i tak ktoś musi

No i tu jest pies pogrzebany - jeżeli zlecisz firmie zewnętrznej to tylko ona będzie mogła utrzymywać produkt.

Nawet jeżeli udostępnią Ci kod źródłowy - to wierz mi, łatwiej jest czasami napisać program od nowa niż rozpracować czyjś kod źródłowy.

choćby ze względu na częste w naszym kraju zmiany prawne.

Tym bardziej uważam, że mam rację.

Temat: System ERP

[author]Jarosław

Link do wypowiedzi

Temat: System ERP

rodzaju: zespół dobrze zarządzany, projekt dobrze zarządzany, projekt dobrze udokumentowany ....

Na poparcie tych słów mogli byście zajrzeć do nowych narzędzi programistycznych. dużych firm takich jak Borland, Microsoft, Sun

Do niedawna tworzyły one zwykłe środowiska programistyczne dla samych programistów.

Obecnie ich wysiłek bardziej koncentruje się na narzędziach "zarządzających tworzeniem oprogramowania"

Po przetłumaczeniu na ludzkie: Są to narzędzia programistyczne dla osób, które nie muszą znać się na programowaniu - tworzą dział pośredni pomiędzy programistami a potrzebami biznesowymi firmy.

Językiem porozumiewania się pomiędzy warstwą biznesową a programistami jest UML - czyli cały język schematów blokowych, wykresów i rysunków, które są zrozumiałe tak samo dla prezesa firmy jak i pana krzysia, który klepie kod źródłowy.

http://www.borland.pl/pr/Borland_Open_ALM_partnerships...

albo znany Wam zapewne M$-Visio (wszyscy znają bo można sobie schematy rysować, ale mało kto wie do czego służy ten program)

To co Wam tu opowiadam - nie wynika jedynie z moich doświadczeń w firmie w której pracuje, ale z ogólnych tendencji technologii informatycznych.

Nawet jeżeli zatrudnicie zespół ludzi, którzy potrafią na płaszczyźnie inżynierskiej rozmawiać z firmami produkującymi soft
to powinniście zatrudnić takich, którzy potrafią rozmawiać w języku UML a nie hobbystów, którzy potrafią zainstalować linuxa i jakąś bazę danych.

Temat: System ERP

Szczerze to dziwi mnie, że analityk biznesowy i dziennikarz IT
wypowiadają się tak jak inkwizycja na procesie Galileusza.

Tym bardziej powinniście promować informatyzację firm
(już nie ważne czy dział IT, czy firma zewnętrzna - to zależy od warunków biznesowych)
ale nie promować gotowe rozwiązania.

Tu działa święta zasada - jeżeli coś jest do wszystkiego to jest do niczego.

Po wdrożeniu "gotowców" okazuje się, że wykorzystujecie z nich tylko 10% funkcjonalności, bo reszta jest nieprzydatna, i zaspokaja to 30% potrzeb firmy, które mógł by zaspokoić program dedykowany.

Temat: System ERP

Maciej F.:

Maciej K.:
A jak programista zachoruje/zechce zmienić pracę? Kto będzie utrzymywał przygotowany przez niego produkt?

Trochę oderwane od rzeczywistosci pytanie.
Programista tworzy soft, a pracują na nim pracownicy firmy,
od utrzymania baz danych są bazowcy a nie programiści

A jak się zmieniają algorytmy przetwarzania, to też bazowcy grzebią w kodzie?

Z programistą podpisujesz umowę, ustalasz terminy i kary za zwłokę i nie obchodzi Cię to czy choruje czy nie.

Bez żartów. Nikt, kto ma odrobinę oleju w głowie (i do tego perspektyw na mniej ryzykowny zarobek) podpisze takiej umowy. Podpisanie takiej umowy oznacza podnajęcie zastępcy - a więc tak czy inaczej zlecasz zadanie firmie.

Ile będzie kosztowało utworzenie i utrzymanie takiego działu?

Wszystko zależy od wielkości i potrzeb firmy.
Dla dużych przedsiębiorstw wystarczy zespół 4-10 osób.

Jeśli to nie są studenci, za których nie trzeba płacić ZUS, tylko szanujący się programiści, to koszty utrzymania takiego zespołu przez czas opracowania projektu idą w setki tysięcy złotych.

czy taki zebrany ad hoc zespół posiada doświadczenia porównywalne z producentem lub firmą wdrażającą na co dzień ERP?

Twój problem w tym, żeby zatrudnić ludzi z właściwymi predyspozycjami. Napewno nie może to być zespół ad hoc.

Czyli zamiast rozwiązać problem istotny dla mojego core biznesu biorę sobie na głowę kolejny problem z projektem IT?

U nas w firmie ściągnęliśmy jednego młodego wykładowce pewnej szkoły IT, on nam polecił zdolniejszych studentów - są naprawdę dobrzy.
Jeżeli chodzi o porównanie z firmami "kobyłami"
Takie kobyły jak Prokom czy Comarch - jadą na opinii - miałem z nimi dużo do czynienia i uwierz mi, nie polecił bym nikomu - chyba że konkurencji :)

Nie odnosiłbym całego rynku consultingu IT akurat do tych dwóch firm. Te firmy akurat chętnie zatrudniają studentów - czyli robią dokładnie to, co Ty proponujesz.

No cóż. masz swoje zdanie ja mam swoje.
Wierzę, że z czasem mentalność zarządów dużych firm w tej kwestii ulegnie zmianie.

Te molochy konkurują ze sobą, mają doświadczenie producenckie i wdrożeniowe.

Widać nie wiesz o czym mówisz. Taki jeden moloch stworzył "Płatnika", zadzwoń do swojego działu rozliczeń i zapytaj o opinię.

Cały czas generalizujesz na podstawie dwóch firm. To nie jest cały rynek IT.
Akurat tak się składa, że znam sporo innych wdrożeń zewnętrznych - udanych.

No i tu jest pies pogrzebany - jeżeli zlecisz firmie zewnętrznej to tylko ona będzie mogła utrzymywać produkt.

A po co prowadząc biznes mam sobie brać na głowę utrzymanie systemu IT?
Czy samochody do firmy też powinienem produkować we własnym zakresie, bo uzależnię się od serwisu dostawcy?Problem polega na tym, by zawrzeć odpowiednią umowę z dostawcą.

Nawet jeżeli udostępnią Ci kod źródłowy - to wierz mi, łatwiej jest czasami napisać program od nowa niż rozpracować czyjś kod źródłowy.

Tego akurat nie musisz mi mówić. Problem znam doskonale z własnej praktyki.

Nie zmienię zdania. Uważam, że firma, która produkuje układy elektroniczne powinna skoncentrować swoje siły na produkcji tychże układów. Zasada koncentracji sił na tym, co można robić najlepiej jest podstawą sukcesu - w biznesie, na wojnie czy w każdej innej dziedzinie życia. Rozmienianie się na drobne rzadko kiedy przynosi pożądany efekt.Maciej K. edytował(a) ten post dnia 29.07.07 o godzinie 20:45

Temat: System ERP

Maciej F.:

[author]Jarosław

Link do wypowiedzi

Temat: System ERP

Maciej F.:

rodzaju: zespół dobrze zarządzany, projekt dobrze zarządzany, projekt dobrze udokumentowany ....

Na poparcie tych słów mogli byście zajrzeć do nowych narzędzi programistycznych. dużych firm takich jak Borland, Microsoft, Sun

Do niedawna tworzyły one zwykłe środowiska programistyczne dla samych programistów.

Obecnie ich wysiłek bardziej koncentruje się na narzędziach "zarządzających tworzeniem oprogramowania"

Chodzi o CASE? ;)

Po przetłumaczeniu na ludzkie: Są to narzędzia programistyczne dla osób, które nie muszą znać się na programowaniu - tworzą dział pośredni pomiędzy programistami a potrzebami biznesowymi firmy.

Są to narzędzia do modelowania ... programuja programiści.. to taka dygresyjka...

Językiem porozumiewania się pomiędzy warstwą biznesową a programistami jest UML - czyli cały język schematów blokowych,

Jest to notacja do zapisu wynikow analizy i modelowania... jeżeli język to co najwyżej komunikacji pomiędzy analitykami i programistami...

wykresów i rysunków, które są zrozumiałe tak samo dla prezesa firmy jak i pana krzysia, który klepie kod źródłowy.

http://www.borland.pl/pr/Borland_Open_ALM_partnerships...

albo znany Wam zapewne M$-Visio (wszyscy znają bo można sobie schematy rysować, ale mało kto wie do czego służy ten program)

Z całym szacunkime ale Visio to ma daleko do CASE, program raczej tylko do tylko obrazków, nie kontroluje semantyki i syntaktyki modelu, nie generuje dokumentacji, diagram dzielony jest na strony, szalenie trudny do edycji w trakcie pracy nad rozrastającym sie projektem.

To co Wam tu opowiadam - nie wynika jedynie z moich doświadczeń w firmie w której pracuje, ale z ogólnych tendencji technologii informatycznych.

Prawda jest, że nastęuje odzielenie ról analityka, architekta i programisty. Coraz więcej ludzi uważa, że programista nie powinien być analitykiem (w szczególności biznesowym)

Nawet jeżeli zatrudnicie zespół ludzi, którzy potrafią na płaszczyźnie inżynierskiej rozmawiać z firmami produkującymi soft
to powinniście zatrudnić takich, którzy potrafią rozmawiać w języku UML a nie hobbystów, którzy potrafią zainstalować linuxa i jakąś bazę danych.

No tak....ale mam nadzieję, że z klientami nie rozmawiasz tym slangiem... ;)

Drobna uwaga, dla odbiorcy biznesowego nie zaleca sie tworzenia diagramów UML bo analiza obiektowa i ta notacja jest raczej obca tym ludziom, tu doskonale sprawdza sie notacja procesowa opisująca firmę a nie jej systemy (np. BPMN). Pewnie znasz stronę http://www.omg.irg gdzie opis architektury SOA jawnie wskazuje na oddzielną część biznesową dokumentacji (BPMN) i systemową (UML).

A dla normalnych ludzi uwaga: analizy i projekty jako dokumenty są oddzielne dla zamawiajacego klienta biznesowego (to sie nazywa specyfikacja wymagań) i dla wykonawcy systemu (ta specyfikacja plus modele obiektowe).

Wybacz, ale nie mogłem jakoś przejść spokojnie nad tymi nieścisłościami, które prawdopodobnie powstały z Twojego pośpiechu...:)

I jeszcze jedno: wymienieni "bazodanowcy" są fizycznej implementacji i od administrowania serwerami baz danych a nie od ich projektowania. Bazy zaprojektowane na szybko przez takich informatyków widywałem nie raz i stanowiły raczej garb niż pomoc.... to tez robota dla analityka...Jarosław Żeliński edytował(a) ten post dnia 30.07.07 o godzinie 00:30

Temat: System ERP

Pewnie znasz stronę http://omg.irg gdzie opis architektury SOA jawnie wskazuje na oddzielną część biznesową dokumentacji (BPMN) i systemową (UML).

http://omg.org - tak dla błądzących w sieci ;)

Językiem porozumiewania się pomiędzy warstwą biznesową a programistami jest UML

Wprawdzie jestem 'tylko' studentem, ale słowo "język" raczej tu 'nie pasuje' do UML ;)Marcin Samelak edytował(a) ten post dnia 30.07.07 o godzinie 00:50