Mirosław K.

Mirosław K. Menedżer IT,
Kierownik projektów,
Rzeczoznawca PTI,
Archi...

Wiele razy spotykałem się z pojęciem "otwartego systemu ERP" ale jakoś nigdy nie zastanawiałem się nad tym zbyt głęboko. Ale czas leci i coraz częściej mówi się o "otwartości" różnych systemów - w tym i ERP/MRPII.
Czy ktoś mógłby wskazać taki "otwarty" system i wyjaśnić na czym ta otwartość polega?

Będę wdzięczny za odpowiedzi.

Pozdrawiam,
Mirek Kowalewski
Piotr K.

Piotr K. QA / Test Engineer
at Luxoft / UBS

Witam

Mnie się "otwarty system ERP" kojarzy z "otwartym" oprogramowaniem (open source). Na przykład jak ten poniżej:

--> http://www.compiere.com/products/open-source/index.php <--

Pzdr.

konto usunięte

Rozszerzalnosc i customizacja?
Mirosław K.

Mirosław K. Menedżer IT,
Kierownik projektów,
Rzeczoznawca PTI,
Archi...

A więc "otwarty" może znaczyć:
1. udostępniający kod źródłowy (jak w przypadku Compiere)
2. rozszerzalny (o co chodzi dokładnie?)
3. customizowalny (też nie bardzo rozumiem co się może kryć pod tym pojęciem - czy nie jest ono synonimem rozszerzalności?)

Rodzi się od razu pytanie - czy dostęp do kodu źródłowego (bez np. dokumentacji funkcjonalnej) coś daje? Ile czasu trzeba byłoby spędzić aby złożony system poznać wyłącznie poprzez kod źródłowy?

Ale może są jeszcze jakieś inne atrybuty "otwartości"?

Zapraszam do wymiany opinii :)

konto usunięte

Poprzez "rozszerzalnosc" systemu otwartego nalezy rozumiec mozliwosc uzytkowania go w coraz to szerszym zakresie. Firmy (teoretycznie) z czasem sie rozrastaja i najczesciej na pewnym etapie ich rozwoju dany system nie jest juz wystarczajacy i nie do konca spelnia wszystkie wymogi. Jego mozliwosci sa po prostu ograniczone. Jezeli system jest rozszerzalny, to jego mozliwosci i funkcjonalnosc "rosna" razem z wymogami.

Customizacja systemu to dostosowanie go do wlasnych indywidualnych potrzeb. Kazda firma funkcjonuje nieco inaczej, inaczej odbywaja sie okreslone procesy, a w zwiazku z tym inne sa wymogi zwiazane z ERP.
Piotr A.

Piotr A. Solution provider

Bardzo trafna uwaga, Dominiko.

My np. tworzymy dedykowane systemy różnych klas i dzięki temu, że piszemy je w zasadzie od zera - nie ma problemu z rozszerzeniem funkcjonalności. Wielokrotnie Klienci wracali np. po pół roku mówiąc, że w sumie to chciałby jeszcze to czy tamto. Tutaj mamy w mojej opinii niewątpliwą przewagę nad rozwiązaniami open-source oraz oprogramowaniem "pudełkowym". Z doświadczenia wiem, że system który naprawdę ma trafiać w potrzeby Klienta - musi rosnąć (lub zmieniać się) wraz z Klientem.
Mirosław K.

Mirosław K. Menedżer IT,
Kierownik projektów,
Rzeczoznawca PTI,
Archi...

Kontynuuję doprecyzowywanie "otwartości":
1. udostępniający kod źródłowy (jak w przypadku Compiere)
2. rozszerzalny - pozwalający na doprojektowywanie nowej funkcjonalności wraz z rozwojem użytkowników
3. customizowalny - pozwalający na dostosowywanie aktualnej funkcjonalności do wymagań użytkowników (nie jest to rozszerzenie systemu)

Trochę nie rozumiem wypowiedzi Piotra. Czy uważasz, że ERP pisany od zera jest "bardziej otwarty" niż ERP gotowy i później zmodyfikowany? Przecież metoda "od zera" w sumie jest tym samym - najpierw robimy coś od zera, potem użytkownik to używa a potem doprojektowujemy coś dodatkowego.

Czy jakieś metody wymiany danych z innymi systemami też można byłoby włączyć do "otwartości"?
Piotr A.

Piotr A. Solution provider

Chyba nie do końca precyzyjnie się wyraziłem, a zamiarem moim była kontynuacja wypowiedzi Dominiki.

Już tłumaczę.

Taki system (pisany od zera) nie jest "bardziej otwarty" - choćby dlatego, że (tu opieram się na naszym przypadku) w większości przypadków nie udostępniany jest kod źródłowy. Odniosłem się natomiast do "rozszerzalności", która niewątpliwie jest prostsza (a czasem po prostu staje się możliwa), gdy system jest pisany od zera.

Naturalnie systemy otwarte (w sensie licencji) mają zazwyczaj skupione wokół siebie grono programistów (choć wolę określenie contributor) i grono to tworzy dodatki lub rozwija sam system, jednak nikt nie da nikomu gwarancji, iż to grono będzie rozwijać system w kierunku pożądanym przez docelowego odbiorcę oprogramowania.

I tutaj właśnie widzę wielką przewagę systemów dedykowanych dla konkretnego Klienta, pisanych od zera.

Ponadto, "customizowalność" w sytuacji gdy system jest pisany specjalnie dla konkretnego Klienta, najczęściej oznacza zmiany we front-endzie. Przygotowywane przez nas specyfikacje techniczne są na każdym kroku konsultowane z Klientem i rzadko się zdarza, by zostało zatwierdzone coś, co później wymaga zmian (dodania jakichś funkcjonalności) w ramach tego projektu.Piotr A. edytował(a) ten post dnia 28.09.07 o godzinie 16:07
Piotr K.

Piotr K. QA / Test Engineer
at Luxoft / UBS

mówiąc najprościej, "rozrzerzalność" to może być inaczej modularność. Jak wiemy cechą zintegrowanego systemu informatycznego jest budowa modułowa. Nie musimy wdrażać każdego modułu z osobna, tylko te, które są przydatne z punktu widzenia profilu działalności przedsiębiorstwa (w przypadku wdrożenia systemu gotowego). Następnym krokiem jest "kastomizacja", dostosowanie/konfiguracja modułu, funkcjonalności do potrzeb organizacji. [z tego co wiem, np. SAP ma z 1000 tablic konfiguracyjnych...].

ale wracając do otwartości...może chodzi o to, że duzi producenci swoich systemów doszli do takiego poziomu ich rozwoju, że dalszy rozwój i budowanie trwalej przewagi konkurencyjnej nie jest możliwy bez zacieśnienia wspólpracy, między niezależnymi twórcami oprogramowania, lub ludźmi którzy mogą mieć jakiś pogląd na rzeczywistość. Poza tym, konkurencja na rynku jest coraz większa, więc z jednej strony "otwierają" się na pomysły innych ludzi, odsłaniając "rąbka tajemnicy" na temat stosowanych rozwiązań, a z drugiej strony, pozyskują zaufanie klientów mniej przekonanych do zbawiennej roli techniki informacyjnej.

Otwartość w tym przypadku, może polegać na budowaniu atmosfery wzajemnego zaufania. Ale interpretacji moze być równie wiele :).
Mirosław K.

Mirosław K. Menedżer IT,
Kierownik projektów,
Rzeczoznawca PTI,
Archi...

Mamy troszkę więcej atrybutów "otwartego ERP":
1. udostępniający kod źródłowy (jak w przypadku Compiere)
2. rozszerzalny - pozwalający na doprojektowywanie nowej funkcjonalności wraz z rozwojem wymagań użytkowników
3. customizowalny - pozwalający na dostosowywanie standardowej funkcjonalności do wymagań użytkowników (nie jest to rozszerzenie systemu)
4. udostępniający rozwiązania producentów (trochę nie bardzo to rozumię - co to jest "rąbek tajemnicy producenta"?)
5. budujący atmosferę wzajemnego zaufania (ale to chyba raczej dotyczy ludzi a nie systemu?)

Myślałem, że zostanę zasypany lawiną odpowiedzi a tu proszę - termin często używany a z definicją wcale nie jest łatwo.
Dzięki dotychczasowym dyskutant(k)om :)

A może coś jeszcze uda się nam dorzucić do tej definicji? Proponowałbym unikać "schodzenia" w kierunku "miękkich" aspektów związanych z ludźmi a skupiać się na "twardych" związanych z bardziej namacalnymi cechami :)

Pozdrawiam,
Mirek Kowalewski
Bartosz T.

Bartosz T. Sprzedaż

Może będę się już powtarzał, ale... Otwartość systemu ERP wg mnie nie ma nic wspólnego z udostępnieniem kodów źródłowych itp. rzeczy. Otwarty system ERP jest to taki system, który jest modyfikowalny poprzez dopisanie np. skryptu, zmiany w tabelach. Patrząc na rynki systemów ERP w Polsce to można wymienić kilku producentów otwartych systemów BPSC, Comarch, Simple.
Patrząc na najbardziej popularne i najtańsze takie jak Symfonia to są to systemy zamknięte, nic w nich nie można zmienić, ani za pomocą skryptów, ani ingerując samodzielnie lub za pomocą programisty. Takie systemy się nie rozwijają, kupujesz Symfonie i musisz pracować na takiej jak kupiłeś, możesz wykorzystać 10% lub 100% funkcjonalności, wszystko zależy od twoich wymagań i oczekiwań.
Stanisław Kaczmarek

Stanisław Kaczmarek Functional
Consultant

Witam
Widze, że jest to dość stary wątek jednak chciałbym dodać coś od siebie:).

Pojęcie to, które jest bardzo modne, a jak widać każdy rozumie na swój sposób. Dla mnie otwartość polega głównie na możliwości rozszerzenia funkcjonalnośći. Można to zrobić na dwa sposoby:
1. Dopisania paru linijek kodu.
2. Dołączenia nowego modułu.
Przykładami drugiego punktu może być np. kontrola jakości, prognozowanie, gospodarka remontowa(to oczywiście zależy od systemu. Ja piszę to w oparci o system, który znam Infor ERP SyteLine).
Powyższą myśl można o rozwinąć dalej i zastanowić sie kto takie rozszerzenia będzie tworzyć. Czy firma która wdrażą czy firma trzecia.
Co do kastomizacji (ja wolę polskie dostosowanie). Wiąże to się czesto z dopisaniem paru linijek kodu ale nie jest to dorabianie nowej funkcjonalności. Fakt granica pomiędzy tymi dwoma pojęciam jest dość płynna.
Natomiast jeśli rozmawiamy o otwartości oprogramowania (open-source). Osobiście nie jestym przekonany czy jako nabywaca poddał bym się eksperymentowi wdrożenia u siebie systemu ERP typu open-source. Ponieważ, co ze wsparciem w trudnych sytacjach i utrata danych czy wyłączenie systemu na pare dni możę dużo więcej kosztować niż pare dziesiąt tysięcy złotych. Piszę paredziesiąt tysięcy a nie kilka set tysięcy bo takie oprogramowanie nie jest w zupełności darmowe. Ale na ten temat to jeszcze można by podyskutować a to nie jestem głównym tematem.

Postrawiam
Stanisław Kaczmarek
Jarosław Żeliński

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

Podobnie jak inni nie wyobrażam sobie ERP z otwartym kodem bo nie wierzę, że ktoś sie do niego poczuje. Zwracam uwagę na to, że ERP w firmie to system wysokiego ryzyka i support po prośbie raczej nie wchodzi w grę, tylko porządne SLA.

Dla mnie otwarty ERP (o ile ma rynkowe szanse to okreslenie) to system komponentowy z udokumentowanymi interfejsami. Funkjconalność można by "skleić" z dostęnych na rynku kawałków. Jest jednak jedno ograniczenie: model danych jest zawsze specyficzny dla firmy i tu pojawiają się moje wątpliwości: na ile firma z historią nagnie sie do modelu danych wbudowanego w gotowy system. Jak na razie jest to jeden z głownych roblemów podczas wdrażania gotowych systemów.
Marek W.

Marek W. Doradztwo
logistyczne,
zarządzanie zapasami

Dla mnie:
Otwarty erp != open source erp.

Oczywiście mając kod źródłowy można (tylko po co i za ile pieniędzy) dowiedzieć się tego, co w otwartym ERPie dostaje się od producenta.

Dla mnie otwart ERP to:

1. Dokładnie zdokumentowany model danych (zarówno idea przechowywania danych jak i znaczenie poszczególnych pól).

2. Dokładne zdefiniowane procesy biznesowe które da się obsłużyć tym programem

3. Dokładnie zdefiniowane procedury/skrypty/parametry, które należy zmodyfikować aby otrzymać oczekiwany efekt

4. Możliwość samodzielnych prac z programem bez udziału albo z wyłącznie usługowym udziałem dostawcy np. możliwość zdefiniowania własnych modeli rotacji czy rozkłądania towaru np. w T-SQLu

5. Możliwość pracy wsadowej z programem (np. Faktura może powstać nie tylko przez wystawienie jej z interfejsu ale np. zaciągnięcie z innego systemu, np. sprzedaży internetowej) - to jest coś niby SOA

6. Możliwość exportu danych do innych systemów (dowolna, najlepiej skryptowana)

5+6 oznacza tak naprawdę możliwość integrowania z innymi aplikacjami zarówno techniczna jak i merytoryczna

7. skalowalność (zaróno modułowa, czyli po roku dodajemy HR, po kolejnym CRM itd jak i skalowalność związana z liczbą użytkowników - dziś 100 za rok 200, dziś 10 tys faktur dziennie za rok 50 tys)

marek
Stanisław Kaczmarek

Stanisław Kaczmarek Functional
Consultant

1. Dokładnie zdokumentowany model danych (zarówno idea przechowywania danych jak i znaczenie poszczególnych pól).

2. Dokładne zdefiniowane procesy biznesowe które da się obsłużyć tym programem

3. Dokładnie zdefiniowane procedury/skrypty/parametry, które należy zmodyfikować aby otrzymać oczekiwany efekt
Dla mnie to czysta teoria, ponieważ:
1. Przy sytemach dużych i bardzo dużych były by tego tysiące stron i analizowanie tego z punktu widzenia użytkownika byłoby bardzo pracochłonne i niecelowe.
2. Producenci oprogramowania tego nie robią bo zbyt często zmieniają się wersje, które nie zawsze mają taka samą struture bazy danych.
3. Generalnie łatwo napisać "dokładnie zdefiniować..." ale praktycznie to jest nie do wykonania. Częst zdażało mi się, że pod tym samym pojęciem użytkownicy rozumieli zupełnie co innego.
Jarosław Żeliński

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

Staszek Kaczmarek:
Dla mnie to czysta teoria, ponieważ:
1. Przy sytemach dużych i bardzo dużych były by tego tysiące stron i analizowanie tego z punktu widzenia użytkownika byłoby bardzo pracochłonne i niecelowe.

Model danych i tak trzeba wykonać, w końcu baza prędzej czy później powstanie, im wcześniej tym lepiej a lepiej by nie była dziełem przyapdku jak to ma miejsce w wielu ciągnących sie w nieskończoność projektach. Co do procesów, ja nie robię map na setki stron bo to faktycznie bezcelowe, raczej na kilkadziesiąt. Modele procesów są po to by uwidocznić w firmie zakres projektu, uchwycić kontekst projektu i otoczenie przypadków użycia. Warto architekturę systemu pzremyślec na papierze i udokumentować ją by nie robić tego na partyzanta już podczas implementacji metodą jak szczur w labiryncie.

2. Producenci oprogramowania tego nie robią bo zbyt często zmieniają się wersje, które nie zawsze mają taka samą struture bazy danych.

O kim piszesz???? Chcesz powiedzieć, że łatwo i bez kosztów można zmienić model danych w działającej aplikacji?
3. Generalnie łatwo napisać "dokładnie zdefiniować..." ale praktycznie to jest nie do wykonania. Częst zdażało mi się, że pod tym samym pojęciem użytkownicy rozumieli zupełnie co innego.

Po pierwsze da się, po drugie dokładnie nie znaczy na setkach stron bo nie raz wystarczą diagramy, po trzecie jeżeli użytkownik zrozumiał co innego to znaczy, że nie zrozumiał dokumentów jakie mu podał wykonawca a to wykonawcę w zasadzie dyskwalifikuje, a już na pewno jego analityków (o ile ich ma).

Podam przykład:

Wystawienie oferty i faktury:
1. Aktor wybiera opcje wystawienia faktury lub oferty
1.1. System powienien dać mozłiwość wyboru na jednym ekranie wystawienia faktury lub oferty
1.1.1. xxx
...... niepotzrebnych kupa szczegółowych opisów.....

To jest bez sensu.

Sens ma napisanie:
1. Na mapie procesów zaznaczono czyności wymagajace wystawienia faktury lub oferty (mam więc kontekst przypadku użycia i jego cel oraz scenariuszo wokół tego przypadku).
1.1. Stan początkowy: mamy wiedze i treści oferty lub faktury czyli liste produktów
1.2. Stan końcowy: na bazie listy produktów i usług mamy dokuemnt będący zgodną z pzrepisami fakturą lub ofertą różniąca się nagłówkiem.

Powyższe zajmuje kilka linijek plus mapa procesów, do której taka specyfikacja się odwołuje. Jednoznaczne, bez zbędnego opisu, jasna dla projektanta i programistów. Zrozumiałe dla klianta. Wykonawca powinien od analityka dostać także model danych!. Taka dokumentacja to coś co daje się przeczytać i zatwierdzić.

Niestety mam wrażenie, że wiele firm programistycznych nie lubi planować i modelować, robi oprogramowanie metodą prób i błędów dając klientowi kolejne prototoypy a nie raz wylatuje w końcu z hukiem bo klientowi puściły nerwy (właśnie zaczne taki projekt po kimś kto wyleciał, była to znana na rynku IT duża firma).

Wracając do wątku: dla mnie otwarty system to komercyjny produkt, komponentowy z udokumentowanymi interfejsami.
Jarosław Żeliński

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

Marek Kubiś

Marek Kubiś programista c#

Jarosław Żeliński:
A co sądzicie o tym?
http://erp5.pl/erp5-system-dla-firm
Diabeł tkwi w szczegółach. Jest kwestią czasu, kiedy takie rozwiązania upowszechnią się ale wszystko zależeć będzie od wdrożenia, a właściwie od analityków, którzy będą umieli lub nie będą umieli dopasować wbudowany w aplikację model danych do konkretnej dziedziny zastosowań. Co prawda istnieje duża część wspólna, która można powiedzieć, że oparta jest na logice tym nie mniej potrzeby biznesowe są bardzo zróżnicowane.

Do upowszechnienia potrzeba jest jeszcze niezmienność w czasie systemów podatkowych, a w konsekwencji modeli księgowych. Dopóki tak nie będzie dopóty "rzemiosło" będzie bezcenne. ;-D
Jarosław Żeliński

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

Marek Kubiś:
Jarosław Żeliński:
A co sądzicie o tym?
http://erp5.pl/erp5-system-dla-firm
Diabeł tkwi w szczegółach. Jest kwestią czasu, kiedy takie rozwiązania upowszechnią się ale wszystko zależeć będzie od wdrożenia, a właściwie od analityków, którzy będą umieli lub nie będą umieli dopasować wbudowany w aplikację model danych do konkretnej dziedziny zastosowań. Co prawda istnieje duża część wspólna, która można powiedzieć, że oparta jest na logice tym nie mniej potrzeby biznesowe są bardzo zróżnicowane.

Do upowszechnienia potrzeba jest jeszcze niezmienność w czasie systemów podatkowych, a w konsekwencji modeli księgowych. Dopóki tak nie będzie dopóty "rzemiosło" będzie bezcenne. ;-D

No cóż, ruszyłeś temat, który ja sam także zaczynam uznawac za słuszny: nie licząc bardzo małych systemów dedykowany system będzie zawsze lepszy i nie koniecznie droższy od krojonego na miare uniwersalnego molocha.... także moim zdanierm właśnie modele danych i przymus ich akcpatacji w przypadku systemów gotowych jest głownym problemem wdrożeń pudełkowych systemów. Teorie o tym, ze model referencyjny jest dobry dla branży, sektora itp. moim zdaniem należy włożyc między bajki....

Czyżby więc nie było szans na otwarty system ERP?
Marek Kubiś

Marek Kubiś programista c#

Jarosław Żeliński:
No cóż, ruszyłeś temat, który ja sam także zaczynam uznawac za słuszny: nie licząc bardzo małych systemów dedykowany system będzie zawsze lepszy i nie koniecznie droższy od krojonego na miare uniwersalnego molocha....
Hmmm, co do kosztów liczonych w jednostce miary pieniądz to temat nieciekawy z punktu widzenia teorii i istotny z punktu widzenia praktyki. Ale już w wielu miejscach na forum się to pojawiało i o ile pamiętam, stanęło na tym, że to tyle co będą nam skłonni zapłacić: czasami dużo, czasami niekoniecznie dużo.

Jeżeli za lepszy uznać system lepiej dostosowany do potrzeb użytkownika to przewaga dedykowanego nad uniwersalnym jest z definicji. Choćby dlatego, że coś uniwersalnego zawierać będzie coś nadmiarowego, niepotrzebnego a to już samo przez się może być postrzegane za coś gorszego (bo niby zaśmieca).

Jeżeli za lepszy uznać system lepiej spełniający wymagania użytkownika to w ogólności nie wiem, bowiem wymagania nie dotyczą tylko i wyłącznie potrzeb ale także zagadnień nietechnicznych, np: renoma dostawcy, wartość marki, postrzeganie przez konkurencję, .. .
także moim zdanierm właśnie modele danych i przymus ich akcpatacji w przypadku systemów gotowych jest głownym problemem wdrożeń pudełkowych systemów. Teorie o tym, ze model referencyjny jest dobry dla branży, sektora itp. moim zdaniem należy włożyc między bajki....
Zgadzam się, co nie oznacza oczywiście, że pudełkowe systemy mają zagwarantowane problemy ze znalezieniem klienta. Liczba klientów systemów z pudełka jest bardzo duża ale jaka nie umiem powiedzieć bo nie widziałem wyników, i chyba nie przeprowadzano, wiarygodnych badań rynku w tym zakresie. Z tego też chyba powodu także wiara, iż pudełkowy system można z sukcesem zastosować obejmuje zbyt szeroki zakres potencjalnych odbiorców.
Czyżby więc nie było szans na otwarty system ERP?
Chyba nie. Chyba wręcz przeciwnie. Toż każdy programista, po kilku latach pracy, ma zbiór własnych bibliotek procedur, które dopieszcza i które na okoliczność różnych aplikacji wykorzystuje.

Myślę, że z czasem, ktoś jednak dopracuje się (czy będzie to firma czy osoba to pozostawiam otwarte) spójnego zbioru bibliotek dla procesów biznesowych i będzie korzystał z nich z powodzeniem na potrzeby tworzenia dedykowanych aplikacji.

Otwartość tym samym będzie miała podwójny wymiar:
- użytkownika (poziom funkcjonalności, potrzeb, wymagań),
- twórcy oprogramowania (poziom kodu).

Do pełni szczęścia brakuje mi tu otwartości modelu danych, materializującego się w strukturze tabel i relacji bazy danych. Cóż, na dziś to nie widzę uniwersalnego rozwiązania. Logicznym dla mnie jest, że najlepiej by chyba było jakby baza mogła powstać za pomocą jakiegoś wizarda z modelu danych.

Póki co ciągle ulegający skróceniu czas życia platform sprzętowych i środowisk programistycznych, nieprzewidywalność kolejnych ministrów finansów i gospodarki oraz niedoskonałość systemu prawa gospodarczego, podpowiada, że o otwartość nie będzie łatwo, a potrzeby dedykowanych rozwiązń będą pojawiać się najrzadziej wraz ze zmianą ekipy rządzącej (w kraju i w korporacjach rządzących IT).

Następna dyskusja:

[n/c] Polski przepis na sys...


Wyślij zaproszenie do