Temat: Dobry open source ERP dla firmy produkcyjnej
Jakub Suchocki:
Zastosuj wymienione przez ciebie bazy w systemach bilingowych.
Stosuje - w jednym Oracle, w drugim Postresa, w trzecim MySQL, w czwarteym IBM DB2. Oczywiście nie są to systemy billingowe dla wielkich operatorów telekomunikacyjnych.
Sam nie mam nic do systemów OS. Sam używam, OTRS, Spring, ExtJS4, JQuery, Grails, Oracle XE i inne tego typu rzeczy.
I co, komercyjne, objęte wsparciem z określonym SLA projekty nie korzystają może z tych technologii? Tych i wymienionych przeze mnie, a także wielu innych? Np bibliotek do obsługi stosu TCP/I które też często i gęsto są OS?
Wybierajac system ERP do swojej firmy nie wybrał bym OS mówię to z własnego doświadczenia. Wyobraź sobie , że nagle projekt się wali i kogo w takim przypadku klient ma pociągnąć do odpowiedzialności ? Wyobraź sobie, że przestój godzinny na magazynie wysokiego składowania w średniej firmie FMCG to ok 5 tyś. euro
Wydaje mi się, że przynajmniej jedno zero za mało w tym oszacowaniu. Problem polega na tym, że źle oceniasz ryzyko. Otóż ryzykiem w tym przypadku nie jest korzystanie z OS, a utrata wsparcia.
Ryzyko to występuje niezależnie od tego, czy korzystasz z komercyjnego systemu ERP (pudełkowego z tzw. "kastomizacją"), dedykowanego rozwiązania napisanego specjalnie na Twoje potrzeby (polecam się - w sensie swoją firmę), czy komercyjnego wdrożenia systemu opartego na OS (np przez evolpe), czy samodzielnie wdrożonego systemu (jakiegokolwiek bądź).
Ryzyko utraty wsparcia i możliwości rozwoju występuje zawsze. Zmienia się jedynie jego źródło. Jeżeli maintenance obejmuje SLA, to można przyjąć, że kwestia "przestoju na magazynie" spowodowana błedem w oprogramowaniu oraz usunięcie takiego błędu jest niezależne od sposobu wdrożenia, bo jest firma, która odpowiada za to, aby w określonym czasie usterkę usunąć, lub wskazać sensowne work-around.
Pozostaje kwestia utraty wsparcia w sensie rozwoju oprogramowania. Tutaj ryzyko to, moim zdaniem, zwiększa się wraz z dysproporcją między wielkością producenta oprogramowania a jego odbiorcą.
Jeżeli korzystasz z oprogramowania dużego producenta, wdrażanego przez sieć partnerską to nawet pomijając fakt, że zwykle straciłeś na starcie (analiza przedwdrożeniowa to żart, koszty licencji i "kastomizacji" zwykle przerastają koszty wykonania dedykowanego rozwiązania a korzystanie z gotowych rozwiązań zmusza do kompromisów w obszarze organizacji, co niesie za sobą ryzyka utraty konkurencyjności, wysokiego oporu pracowników, obniżeniu wydajności i innych), ale nie masz żadnego wpływu na wsparcie. Partner, bez wsparcia producenta nie pomoże Wam w niczym co wykracza poza parametry konfiguracyjne. Jeśli producent zdecyduje, że kończy wsparcie dla tej linii produktu, bo zastępuję ją nową - lądujecie w nie lepszej sytuacji niż w przypadku OS, czy systemu dedykowanego, przy czym nie macie żadnej dźwigni na giganta typu SAP, Asseco, Sage, czy Sygnity. Albo wdrażacie nowy system (z jakimś rabatem, który moim zdaniem często wcale nie odzwierciedla poza licencyjnych kosztów migracji) albo zostajecie bez SZANSY na jakiekolwiek wsparcie, czy rozwój funkcjonalności.
Jeżeli korzystasz z dedykowanego oprogramowania, posiadasz kody źródłowe wysokiej jakości, obiektowy projekt oprogramowania (UML) i formalną analizę wymagań (UML+BPMN) oraz dokumentację interfejsów to nawet jeśli firma, która to wykonała powie Ci "już tego nie wspieram" to masz możliwość znaleźć inną firmę programistyczną, która przejmie temat, bo rozwiązania są znane na poziomie programistycznym a dobra dokumentacja (analiza + projekt + kod napisany w wysokim standardzie kodowania) daje możliwość przejęcia projektu po kimś.
Podobnie z Open Source - tutaj firma wdrażająca ma dużo większe pole do popisu i może świadczyć wsparcie i rozwijać oprogramowanie nawet jeśli źródłowy projekt się zamknie, czy zmieni negatywnie dla firmy. Warto też zwrócić uwagę, że część rozwiązań Open Source jest przez producenta objęta komercyjnym wsparciem - Open Bravo, SugarCRM, Alfresco, KnowdlegeTree, Nuxeo - to są projekty Open Source, biznesowe, za którymi stoją nie gorsze firmy z nie gorszym wsparciem niż tradycyjnie komercyjne rozwiązania.
Wniosek jest prosty - ryzyka są podobne, różnią się źródła tych ryzyk i możliwości mitygacji. Nie dyskredytował bym na etapie planowania wdrożenia ani rozwiązań dedykowanych ani opartych o Open Source - analizę wymagań wykonał metodami formalnymi, zebrał oferty - nie katalogi produktów - oferty wskazujące w jaki sposób proponowane rozwiązanie realizuje każde z przedstawionych wymagań (Przypadków użycia, wymagań poza funkcjnalnych), przeanalizował propozycje projektów pod kątem: skuteczności w realizacji wymagań (szansy osiągnięcia biznesowego celu wdrożenia np. obniżenia wartości magazynu półproduktów o 30% przy zachowaniu czasów produkcji), TCO (całkowity koszt posiadania - czyli kosztu licencji, "kastomizacji", wdrożenia, szkolenia, wsparcia, SLA, gwarancji itp) w planowanym okresie eksploatacji, oraz ryzyka w ujęciu szansy wystąpienia, kosztu wystąpienia i możliwości mitygacji.
A potem podjął najlepszą decyzję dla swojej organizacji - co doradzam wszystjkim potencjalym klientom.
пропозиції роботи
