Oprogramowanie

Zarządzanie relacjami z klientami lub System relacji z klientami, CRM (ang. Customer Relationship Management) to zestaw narzędzi i procedur istotnych w zarządzaniu kontaktami z klientami.

CRM należy traktować nie tylko jako narzędzie, ale jako część strategii i filozofii biznesu, gdzie stały kontakt i zadowolenie klienta jest kluczową wartością. Istotną kwestią jest zapewnienie jednolitego systemu we wszystkich procesach biznesowych – od początku procesu sprzedaży poprzez serwis do sporządzania odpowiednich statystyk wykorzystywanych przy tworzeniu portfela produktów.

Sam sposób komunikacji dla systemu CRM nie jest sprawą pierwszoplanową, a jedynie narzędziem. Systemy CRM obudowane są w różnorodne moduły komunikacji.

Sprawne działanie systemu CRM nie byłoby możliwe bez systemów baz danych i systemów informatycznych.

CRM to nie jest system informatyczny, tylko jak określa to wielu praktyków jest przyjętą strategią, filozofią działania przedsiębiorstwa, która ma na celu poprawę kontaktów z klientami, przez co możliwy jest dynamiczniejszy rozwój przedsiębiorstwa i lepsza realizacja wyznaczonego celu – osiągnięcie zysku.

Spis treści

• 1 Zastosowania systemów “klasy CRM”
• 2 Architektura CRM
• 3 Związek z klientem
• 4 Narzędzia CRM
• 5 Historia CRM

//

Zastosowania systemów “klasy CRM”

• W systemie informatycznym odnotowano kupno usługi lub towaru.
• Niezapłacenie rachunku w odpowiednim terminie powoduje podjęcie akcji wysłania ponaglenia.
• Jeśli system nie odnotuje wpływu pieniędzy w odpowiednim czasie spróbuje podjąć próbę przypomnienia klientowi o tym fakcie np. automatycznie drukując korespondencję do wysyłki, wysyłając SMS itp.
• Jeśli okaże się, że np. ponaglenie nie przyniosło skutku, system “klasy CRM” może dodać takiego klienta do kolejki rozmów telefonicznych pracownika firmy lub powiadomić prawnika firmy z prośbą wszczęcia postępowania sądowego.
• Automatyzacja wysyłania kartek urodzinowych dla klientów firmy, ofert handlowych (często sprofilowanych dzięki danym wcześniej zebranym w CRM).

Z front-office różnych systemów CRM spotykamy się codziennie np. korzystając z Błękitnej Linii TP S.A.. Jest to przykład wykorzystania CRM w tzw. Call center. Klient dzwoniąc na infolinię, po podaniu swoich danych jest identyfikowany przez obsługującą go osobę, która uzyskuje te dane z systemu CRM.

Z (back–office), korzysta z danych mających swe źródło w systemach transakcyjnych. Dane te pochodzą głównie z działów sprzedaży, marketingu, serwisu. Na jego podstawie możliwe jest uzyskanie materiału analitycznego, który stanowi podstawę do dalszych działań.

Systemy “klasy CRM” są często integralną częścią całego systemu informatycznego. Przykładem może być połączenie w systemach SAP systemu CRM z systemem R/3. Mamy tu możliwość tworzenia dokumentów sprzedaży w systemie CRM i przekazywania informacji o tych dokumentach do systemu R/3, w którym może się odbywać dalsza część procesu biznesowego (jak np. zamówienie części potrzebnych do wytworzenia sprzedawanego produktu czy chociażby część procesu związanego z dostawą, czyli generowanie dokumentów sprzedaży). Oznacza, to, że każdy obszar działalności dzięki tym systemom może być ze sobą zintegrowany.

Systemy CRM często wykorzystywane są też w firmach korzystających z sieci mobilnych sprzedawców. Jest to możliwe dzięki takim funkcjom jak Mobile Sales. Na przenośnych komputerach sprzedawców instalowane są aplikacje pozwalające na synchronizację z centralnym systemem CRM. Łączą się oni co jakiś czas z systemem centralnym, dzięki czemu zmienione przez nich dane bądź informacje o nowych klientach przesyłane są do centralnego systemu. Z drugiej strony dostarczane są aktualizacje danych, w zależności od tzw. subskrypcji. Do każdego sprzedawcy możemy przypisać inne subskrypcje. Subskrypcje mają zminimalizować transfer danych do niezbędnego minimum (np. sprzedawcy działającego na terenie Polski północnej nie są dostarczane informacje o klientach z z Polski południowej).

Systemy “klasy CRM” ułatwiają stworzenie klasyfikacji klientów z podziałem, np na klientów kluczowych (przynoszących zasadniczy zysk) i klientów mniej opłacalnych, a czasem nawet nieopłacalnych (generujących zbyt małe zyski lub wręcz straty). Tej klasyfikacji dokonuje się m.in. poprzez: analizę RFM, analizę LVT, macierz możliwego do osiągnięcia zysku (ang. profit opportunity cycle), analizę opłacalności relacji klient – produkt.

Po dokonaniu klasyfikacji klientów i produktów na odpowiednie grupy, przedsiębiorstwo w stosunku do nich podejmuje odpowiednią decyzję. I tak, wskazuje się na następujące, możliwe do realizacji (najkorzystniejsze), alternatywne rozstrzygnięcia:

• przekonanie nieopłacalnych klientów do rezygnacji z dalszej współpracy lub przekonanie ich do zakupu produktów wysoko opłacalnych dla przedsiębiorstwa;
• zwiększenie ceny za mało opłacalne produkty lub wycofanie ich z rynku.

Architektura CRM

Istnieją trzy istotne elementy dla systemu CRM:

• Operacyjny (front-office) – odpowiadający za automatyzację podstawowych procesów biznesowych (marketing, sprzedaż, serwis).
• Analityczny (back-office) – odpowiadający za analizę zachowań klientów na podstawie danych zgromadzonych w elemencie operacyjnym.
• Komunikacyjny (interakcyjny) – odpowiadający za komunikację z klientami.

Od strony technicznej system CRM składa się z trzech warstw:

• serwera aplikacji;
• serwera baz danych;
• warstwy interfejsu.

Związek z klientem

Wszystkie relacje związane z danym klientem określamy mianem związku. Składa się z epizodów, które dzieli się na:

• transakcje finansowo-towarowo-usługowe;
• kontakty, rozmowy.

Narzędzia CRM

• SFA – automatyzacja sprzedaży (ang. Sales Force Automation).
• Call center (ang.).
• Contact Center (ang.).
• Knowledge Management (ang.) – zarządzanie wiedzą.
• Campaign Management (ang.) – zarządzanie kampaniami.
• Lead Management (ang.) – zarządzanie namiarami.
• Key Account Management (ang.) – zarządzanie klientami kluczowymi.
• Trade Promotion Management (ang.) – zarządzanie promocjami.

Historia CRM

CRM powstał w latach 90. wchłaniając wcześniejsze systemy utworzone w latach 80.: SFA (ang. Sales Force Automation) wprowadzony dla automatyzacji procesów sprzedaży i CSS (ang. Customer Service Support) dla usprawnienia obsługi serwisowej po sprzedaży.

Zintegrowany system informatyczny (ang. integrated system) – najbardziej merytorycznie i technologicznie zaawansowana klasa systemów informatycznych wspomagających zarządzanie w przedsiębiorstwach i instytucjach. Optymalizuje procesy zarówno wewnętrzne, jak i zachodzące w najbliższym otoczeniu poprzez oferowanie gotowych narzędzi. Narzędzia te służą do automatyzacji wymiany danych pomiędzy działami przedsiębiorstwa oraz pomiędzy przedsiębiorstwem a innymi podmiotami biznesowymi z jego otoczenia (np. kooperantami, dostawcami, odbiorcami, bankami, urzędami skarbowymi).

Głównymi cechami są: kompleksowość funkcjonalna, integracja danych i procedur, elastyczność funkcjonalna i strukturalna, zaawansowanie merytoryczne i technologiczne oraz otwartość.

Wśród tendencji rozwojowych należy wskazać:

• szerszy zakres usług biznesowych (np. CRM, ERM, PRM, SCM)
• pełniejsze wykorzystanie technologii internetowych w realizacji idei e-biznesu
• rozwój aplikacji na platformy mobilne
• systemy wspomagające zarządzanie wiedzą

Zobacz też

• ECM
• ERP - Zaawansowane zarządzanie zasobami
• MRP

Microsoft Dynamics AX, dawniej znany jako Microsoft Business Solutions - Axapta - system informatyczny ERP firmy Microsoft. System podzielony na moduły, każdy z nich ma pełną integrację z modułem finansów. W systemie występują między innymi moduły: Finanse, Handel i logistyka, Planowanie produkcji, CRM, Planowanie główne. System ma pełne możliwości rozwoju, ponieważ jest dostępny kod źródłowy (tylko dla warstwy użytkowej aplikacji).

System został stworzony przez duńską firmę Damgaard, która połączyła się z firmą Navision a następnie z Microsoftem.

Programowanie - MorphX i X++

MorphX jest zintegrowanym środowiskiem programistycznym dostępnym w Microsoft Dynamics AX. Można z jego pomocą tworzyć formularze, menu, zapytania, raporty itp. Wewnętrznie MorphX wykorzystuje język X++. Jest to język obiektowy, posiadający wiele podobieństw do C# i Javy. Programiści mogą tworzyć kod również bezpośrednio w X++, korzystając z udostępnianego przez MorphX edytora kodu.

Linki zewnętrzne

• Strona Microsoft Dynamics AX (pol.)
• Wiki dla Programistów Microsoft Dynamics AX (ang.)
• Axapta forum - Polska społeczność Axapty (pol.)

Decision Support Systems (DSS) – systemy wspomagające podejmowanie decyzji. Aplikacje dostarczające informacji i wiedzy, wykorzystywane głównie przez kierownictwo średniego i wysokiego szczebla oraz analityków korporacyjnych. W efekcie wykorzystania systemów DSS uzyskujemy raporty i zestawienia, które dostarczane są kierownictwu w ramach systemów informowania kierownictwa EIS (Executive Information Systems). Dlatego też często systemy DSS określane są jako specjalizowana forma EIS.

Od końca lat 80. rozwija się też w różnych gałęziach przemysłu tzw. wysokiego ryzyka, medycynie i dla zarządzania zagrożeniami “inteligentne” DSS (IDSS) wykorzystujące technologie sztucznej inteligencji, systemy ekspertowe oraz modelowanie operacyjne i kognitywistyczne procesów decyzyjnych. Celem tych systemów jest zastępowanie lub wspomaganie złożonych lecz już dobrze zdefiniowanych funkcji rozumowania.

Samo pojęcie „Systemy Wspomagania Decyzji” pierwszy raz opisał w swojej pracy doktorskiej S.Morton w 1971 r. Nazwę DSS(Decision Support Systems – Systemy Wspomagania Decyzji) utrwalono na początku lat 80. w USA, Europie, również w Polsce. Wraz z pojawieniem się mikrokomputerów budowa SWD(Systemy Wspomagania Dedyzji) nabrała rozmachu i przyspieszenia. Koszty wdrożenia systemu wahają się w granicach od kilku tysięcy do kilku milionów złoty w zależności od rodzaju systemu, jego wielkości i ilości modułów.

Ewolucja DSS

Przez ostatnie 10 lat zmieniała się nazwa programów wspomagających decyzję – od EIS (Executive Information Systems) poprzez DSS (Decision Support Systems) aż do systemów BI (Business Inelligence). Programy EIS – systemy informowania kierownictwa – były zwykle budowane przez zespoły programistów przy użyciu języka C++ lub 4GL aby umożliwić menedżerom i szefom firm łatwe i proste otrzymywanie wybranych informacji o kondycji ich przedsiębiorstwa. W wielu przypadkach aplikacje EIS miały predefiniowane zestawy zapytań, wyposażone w szereg parametrów ustawianych przez użytkownika. Rezultatem zapytań były tabele lub wykresy. Działalność aplikacji EIS była ograniczona tylko do tych zastosowań, które określili wcześniej programiści. Rodzaj informacji jakie dostarczały EIS dotyczył zwykle sprzedaży ogólnej, sprzedaży poszczególnych produktów czy liczby produktów sprzedanych w okresie rozliczeniowym. Jakiekolwiek nietuzinkowe pytania biznesowe, wymagające głębszych analiz wymagały skorzystania z usług zakładowego informatyka, który pisał zapytania w języku SQL i formatował odpowiedzi w formie raportu.

Aplikacje DSS – systemy wspomagania podejmowania decyzji – należały do pierwszej generacji oprogramowania, które w sposób dynamiczny generowały zapytania SQL w celu uzyskania takiej informacji, jaką użytkownik DSS chce zobaczyć. Pozwalają one w sposób efektywny wyodrębnić dane z relacyjnej bazy danych bez konieczności zrozumienia czy nauczenia się pisania skryptów SQL. W odróżnieniu od aplikacji EIS, programy DSS mogły dotyczyć różnych zastosowań, pod warunkiem, że ich opis był przechowywany w relacyjnej bazie danych. Na dodatek użytkownik DSS mógł zadawać pytania w szerokim zakresie zastosowań w biznesie, a uzyskane informacje-odpowiedzi mógł w prosty sposób formatować w bardziej zrozumiałe prezentacje. Pytania zadawane przez użytkowników DSS mogą dotyczyć o wiele bardziej złożonych spraw niż to co oferował EIS. I tak w aplikacji DSS możemy zadawać pytania takie, jak: Jak wielu klientów korzysta z usług firmy? Jaki jest najlepiej sprzedający się produkt? Jaki jest najgorzej sprzedający się produkt? Uwieńczeniem ewolucji zmian oprogramowania DSS stały się pierwsze aplikacje BI (Business Intelligence) czyli systemy dostarczające kompleksowych informacji, wspierające podejmowanie decyzji na wszystkich szczeblach zarządzania przedsiębiorstwem. Tego typu aplikacje oparte na interfejsach sieciowych pozwalają użytkownikowi łatwo wybierać interesujące go dane z jednego lub wielu źródeł i mogą dotyczyć wielu zastosowań – a wszystko po to, żeby służyć pomocą we właściwym podejmowaniu decyzji na poziomie zarządzania przedsiębiorstwem. W skład aplikacji BI wchodzą: DSS, aplikacje przeznaczone do przetwarzania online (OLAP), aplikacje do tworzenia statystyk oraz aplikacje do analizy związków między danymi (data mining – eksploracja danych) – korelacji, związków przyczynowo-skutkowych itp.

Zobacz też

• Teoria decyzji
• System informacyjny
• Business intelligence

Linki zewnętrzne

• Adam Maria Gadomski, at al.(2001) “An Approach to the Intelligent Decision Advisor (IDA) for Emergency Managers. Int. J. Risk Assessment and Management, Vol. 2, Nos. 3/4.

Magazynowy system informatyczny (skr. WMS od ang. Warehouse Management System) – program do zarządzania ruchem produktów w magazynach, wykorzystywany w logistyce zwany też systemem do obsługi magazynu wysokiego składu.

Zastosowania

Rozwiązania typu WMS służą koordynowaniu prac magazynowych. Są to wysoce wyspecjalizowane systemy usprawniające wszystkie procesy, które zachodzą w magazynach. Mają one duże znaczenie przede wszystkim dla operatorów (usługodawców) logistycznych, obsługujących w swoich magazynach i terminalach codziennie dużą liczbę zróżnicowanych przesyłek, pochodzących od wielu nadawców i kierowanych do wielu odbiorców.

W firmach świadczących usługi logistyczne systemy WMS stanowią często technologię wspierającą działanie systemu zarządzającego klasy ERP. Pomiędzy tymi systemami powinna funkcjonować sprawna wymiana danych, oparta na ujednoliconych standardach przekazywania informacji. Nowe klasy oprogramowania zapewniają zwykle obsługę zróżnicowanych danych w poszczególnych podsystemach informatycznych przedsiębiorstw i swobodne przenoszenie ich z modułu do modułu. To z kolei pozwala na całkowite automatyzowanie ruchu produktów w magazynach z wykorzystaniem oprogramowania WMS.

Niektórzy dostawcy systemów ERP oferują funkcjonalność WMS jako jeden z modułów integralnie wbudowanych w pakiet ERP lub obsługują ją częściowo w ramach modułów gospodarki magazynowej.

Funkcje systemów WMS

Szczególnym zadaniem realizowanym w ramach systemów WMS jest bezbłędna lokalizacja towarów w magazynie oraz kontrola przebiegu obrotu magazynowego. System dostarcza informacji dotyczących stanu magazynowego według wielu różnych kryteriów oraz umożliwia sprawną lokalizację każdej partii towaru i każdej pojedynczej przesyłki. W systemie WMS operator może wygenerować odpowiednią etykietę i oznaczyć nią jednostki towarowe lub w momencie przyjmowania towaru do magazynu przyjąć do systemu informacje zawarte na etykiecie nadanej jej wcześniej przez inny podmiot.

Za pomocą systemu WMS możliwa jest również kontrola ilościowa i asortymentowa przyjmowanego do magazynu towaru, np. pod kątem zgodności dostawy z dokonanym wcześniej zamówieniem. Systemy WMS doskonale sprawdzają się w centrach logistycznych, gdzie ruch towarów jest intensywny, w jednym czasie następuje zarówno przyjęcie towaru, jak i wysyłka – skoordynowanie ruchu towarów wymaga automatyzacji operacji zachodzących w systemie, przy możliwości skontrolowania ich prawidłowości w każdym momencie – bez konieczności żmudnego przeliczania partii towarów na regałach magazynowych.

Istotną rolę dla usługodawców logistycznych może stanowić możliwość planowania wysyłek z magazynu w taki sposób, aby zoptymalizować wykorzystanie posiadanych zasobów, a także skrócić czas magazynowania i obniżyć w ten sposób koszty „zamrożenia” kapitału obrotowego. Oznacza to, że system WMS można odpowiednio zintegrować z innymi systemami wykorzystanymi przez przedsiębiorstwa w sferze logistyki.

Bibliografia

• Kawa A., Informatyka integralną częścią logistyki, „Raport Informatyka” „Eurologistics” 2002, nr 4.
• Książkiewicz A., Rola Internetu w usługach logistycznych, W. Rydzkowski (red.), Usługi logistyczne, Instytut Logistyki i Magazynowania, Poznań 2004, s. 162-166.

Planowanie zapotrzebowania materiałowego (ang. Material requirements planning (MRP)) - jest to zbiór technik, które pomagają w zarządzaniu procesem produkcji. Techniki te często wspomagane są odpowiednimi aplikacjami komputerowymi.

Głównym celem jest zmniejszenie nakładów finansowych potrzebnych przez organizację produkcyjną. Jest to osiągane przez optymalizację zapasów oraz samego procesu produkcyjnego.

Do systemu wprowadza się informację o zaplanowanej produkcji, lub wielkość sprzedaży lub przyjętych zamówieniach na wyroby gotowe. Na tej podstawie system planuje produkcję poszczególnych elementów oraz dostawy podzespołów i materiałów. Planowanie może być wykonane wprzód lub wstecz (tzn. od zadanego dnia obliczenie, kiedy wymagana produkcja zostanie wykonana lub kiedy trzeba rozpocząć proces aby uzyskać wymaganą produkcję na zadaną datę). System przewiduje czasy produkcyjne, czasy dostaw. W procesie planowania może następować optymalizacja kosztów, czasu wykonania, opłacalności. Do różnych typów produkcji stosuje się inne algorytmy obliczeń.

Cele MRP

• redukcja zapasów
• dokładne określenie czasów dostaw surowców i półproduktów
• dokładne wyznaczenie kosztów produkcji
• lepsze wykorzystanie posiadanej infrastruktury (magazynów, możliwości wytwórczych)
• szybsze reagowanie na zmiany zachodzące w otoczeniu
• kontrola realizacji poszczególnych etapów produkcji

Zobacz też

• MRP II
• ERP

OpenERP

ERP,CRM

Interfejs programu

Producent
Tiny , Sprl

System operacyjny
Windows, Linux, Unix, Mac OS X

Aktualna wersja stabilna
5.0.7 / 1 marca 2010; 54 dni temu

Licencja
GNU GPL

www.openerp.com

OpenERP (poprzednio nazywany TinyERP) jest systemem ERP/CRM.

System zawiera oddzielne komponenty klienta (GTK i WEB) oraz serwera. Dostępny jest interfejs XML-RPC. System jest rozwijany jako Open Source na licencji GNU General Public License. Źródła można oglądać i rozwijać w Launchpad. Nazwa głównego projektu to OpenObject. Projekt OpenObject stanowi platformę do pisania dowolnych aplikacji bazodanowych przy pomocy języka Python. Projekt OpenObject składa się kilkunastu podprojektów, z których najważniejsze to:

1. OpenObject Server - silnik systemu
2. OpenObject Client - Klient GTK systemu
3. OpenObject Web Client - Klient WEB systemu
4. OpenObject Addons - zbiór modułów tworzących system OpenERP.

Podstawowe moduły spośród ponad 300 to: zarządzanie finansami, księgowością, zapasami, sprzedażą, zakupami, relacjami z klientami, planowaniem.

Dostępne są wersje na Linux (z interfejsem GTK+), Windows i Mac OS X. Interfejs WEB ‘eTiny’ jest dostępny przy użyciu Turbogears web framework. Od roku 2008 dostępny jest również interfejs KDE. Ostatnia wersja OpenERP (5.0) zawiera dynamiczne wykresy Gantta (drag&drop), współdzielone kalendarze, zintegrowane widoki BPM, edytor obiegów i projektanta ekranów.

Spis treści

• 1 Model biznesowy
• 2 Licencja
• 3 Architektura
• 4 Środowiska rozwojowe
• 5 Polska wersja
• 6 Linki zewnętrzne

//

Model biznesowy

OpenERP rozwija się w modelu całkowicie otwartych źródeł. Rozwój systemu i wysiłki społeczności są zarządzane przy pomocy systemu Launchpad, z zastosowaniem systemu repozytoriów Bazaar. Społeczność OpenERP jest zorganizowana na stronie WEB OpenObject, gdzie można znaleźć forum, IRC i wszystkie dostępne moduły OpenERP. Rozwój dokumentacji jest również zarządzanay w Launchpad. Strona web do publikacji dokumentacji również jest dostępna.

W społeczności OpenERP wyróżnieni zostali partnerzy i producent. Partnerzy budują rynek OpenERP i oferują swój serwis. Producent dba o jakość i wizję rozwoju. Cała społeczność jest zaangażowana budowanie systemu i jego nowych modułów. Wszystkie moduły, zarówno stworzone przez producenta, partnerów jak i społeczność, są dostępne jako OpenSource.

Licencja

Właścicielem rozwiązania OpenERP jest firma Tiny sprl (Belgia).

OpenERP Server i GTK+ client są publikowane według licencji GPL wersja 3.0.

Klient WEB jest dostępny na podstawie licencji “OpenERP Public Licence”. Licencja pochodzi z Mozilli, oprogramowanie wolne do stosowania i modyfikacji. Najważniejszym zastrzeżeniem jest pozostawienie oryginalnego logo Tiny, Open ERP i Axelor na stronach WEB widocznych dla użytkownika.

Niektóre moduły są dystrybuowane w modelu “wspólnej inwestycji”. Tiny zapewnia, że moduły są w licencji GPL i będą dostępne dla wszystkich, ale oficjalna publikacja jest wstrzymana do czasu pokrycia kosztów.

Architektura

OpenERP ma strukturę 3 warstwową.

Baza danych jest PostgreSQL.

Część serwerowa jest napisana w Python. Funkcjonalność biznesowa jest zorganizowana w modułach. Moduł jest folderem o predefiniowanej strukturze zawierającym kod Python i pliki XML. Moduł definiuje strukturę danych, formularze raporty, menu, procedury i obiegi.

Klient jest “cienki” i sam w sobie nie zawiera żadnej funkcjonalności biznesowej. Dopiero dodanie obiektów, jak menu, czy formularzy powoduje, że sa one dostępne w dowolnym kliencie (serwer OpenERP może być dostępny dla różnych typów klientów: gtk+, web lub Qt).

Klient GTK+ został napisany na platformie PyGTK (Python).

Klient Web został napisany w Python. Stosuje on platformę turboGears do wersji 5.0.1. Jednak zawartość funkcjonalna klientów GTK+ i web jest jednakowa, są jedynie drobne różnice w funkcjonalności interfejsów: np. klient web ma funkcjonalność “dostosuj” w każdym formularzu, a klient gtk+ nie ma takiej funkcjonalności.

Klient Qt jest napisany w Python.

Środowiska rozwojowe

Nie ma zintegrowanego środowiska. Kod Python musi być edytowany w zewnętrznym edytorze.

Część logiki (np. obiegi i struktura danych) może być zmieniana w kliencie.

Polska wersja

System OpenERP został przetłumaczony na język polski przez polską społeczność OpenERP. Zostały również stworzone moduły z polskim wzorcowym planem kont, polskimi podatkami VAT, oraz moduł do automatycznego importu kursów walut ze stron internetowych NBP. Proces importu kursów może działać automatycznie co noc. Wszystkie te moduły są dostępne w Launchpad. W przyszłośći będą zawarte w standardowych pakietach instalacyjnych. W Polsce działają osoby i firmy, które przez udział w społeczności OpenERP są doskonale przygotowane do wdrażania tego systemu.

Linki zewnętrzne

• Oficjalna strona OpenERP
• Strona społeczności
• Forum
• Społecznościowa platforma rozwoju - Launchpad

Planowanie zapotrzebowania materiałowego (ang. Material requirements planning (MRP)) - jest to zbiór technik, które pomagają w zarządzaniu procesem produkcji. Techniki te często wspomagane są odpowiednimi aplikacjami komputerowymi.

Głównym celem jest zmniejszenie nakładów finansowych potrzebnych przez organizację produkcyjną. Jest to osiągane przez optymalizację zapasów oraz samego procesu produkcyjnego.

Do systemu wprowadza się informację o zaplanowanej produkcji, lub wielkość sprzedaży lub przyjętych zamówieniach na wyroby gotowe. Na tej podstawie system planuje produkcję poszczególnych elementów oraz dostawy podzespołów i materiałów. Planowanie może być wykonane wprzód lub wstecz (tzn. od zadanego dnia obliczenie, kiedy wymagana produkcja zostanie wykonana lub kiedy trzeba rozpocząć proces aby uzyskać wymaganą produkcję na zadaną datę). System przewiduje czasy produkcyjne, czasy dostaw. W procesie planowania może następować optymalizacja kosztów, czasu wykonania, opłacalności. Do różnych typów produkcji stosuje się inne algorytmy obliczeń.

Cele MRP

• redukcja zapasów
• dokładne określenie czasów dostaw surowców i półproduktów
• dokładne wyznaczenie kosztów produkcji
• lepsze wykorzystanie posiadanej infrastruktury (magazynów, możliwości wytwórczych)
• szybsze reagowanie na zmiany zachodzące w otoczeniu
• kontrola realizacji poszczególnych etapów produkcji

Zobacz też

• MRP II
• ERP

Ten artykuł dotyczy przysyłania informacji o transakcjach biznesowych. Zobacz też: inne znaczenia skrótu “EDI”.

Elektroniczna wymiana danych (EDI, ang. Electronic Data Interchange) - transfer biznesowej informacji transakcyjnej od komputera do komputera z wykorzystaniem standardowych, zaakceptowanych formatów komunikatu.

EDI określa sposób wymiany pomiędzy komputerami stron dokładnie określonych co do formatu komunikatów zawierających treści inne niż mechanizmy przekazu środków pieniężnych. W ramach EDI definiuje się sekwencję komunikatów między stronami transmisji, przy czym każda z nich może być jej nadawcą lub odbiorcą. Dane zawierające treść dokumentów mogą być przesłane od nadawcy do odbiorcy poprzez środki porozumiewania się na odległość lub też mogą być przewiezione na nośniku pamięci.

Celem EDI jest wyeliminowanie wielokrotnego wprowadzania danych oraz przyspieszenie i zwiększenie dokładności przepływu informacji dzięki połączeniu odpowiednich aplikacji komputerowych w firmach uczestniczących w wymianie. Użycie EDI pozwala poprawić czasową dostępność informacji logistycznej, poszerzyć i uściślić dane, a także zmniejszyć pracochłonność procesu. Aby w pełni wykorzystać zalety EDI, uczestnicy kanału logistycznego powinni się komunikować za pośrednictwem komputera. Innymi słowy, efektywne wdrożenie EDI wymaga bezpośredniej komunikacji między systemami komputerowymi zarówno nabywców jak i sprzedawców produktu.

Komunikaty EDI są technicznym sposobem zapisu komunikacji biznesowej pomiędzy dwoma stronami (wewnątrz lub na zewnątrz przedsiębiorstwa). Standardy EDI określają ściśle format przesyłanego dokumentu.

EDI nie określa sposobu przesyłania komunikatów - mogą one być przesyłane przez dowolne medium, którym posługują się obie strony transmisji. Może to być transmisja modemowa, poprzez FTP, HTTP, AS1, AS2. IETF określiła standardy przesyłu komunikatów EDI przez Internet: w 2002 RFC3335 określił sposób przesyłania EDI poprzez pocztę elektroniczą, a w 2005 roku określono sposób przesyłania przez HTTP z użyciem MIME (tzw. EDIINT, AS2) w RFC4130.

Istnieją cztery standardy komunikatów EDI:

• Zalecany przez Narody Zjednoczone EDIFACT - jedyny standard międzynarodowy, stosowany przeważnie poza krajami Ameryki Północnej.
• Amerykański standard ANSI ASC X12 - stosowany głównie w Ameryce Północnej.
• Standard TRADACOMS rozwijany przez ANA (Article Numbering Association) stosowany w handlu detalicznym w Wielkiej Brytanii.
• Standard ODETTE stosowany w europejskim przemyśle motoryzacyjnym.

Przypisy

1. ↑ Federal Information Processing Standards Publication 161-2, NIST 1996.

Planowanie Zasobów Produkcyjnych ang. MRP II - Manufacturing Resource Planning. W celu odróżnienia od zwykłego MRP konieczne jest dodawanie rzymskiej liczby II, gdyż rozwinięcie tego skrótu jest inne.

Model MRP II w stosunku do MRP został rozbudowany o planowanie zdolności produkcyjnych (CRP) oraz o elementy związane z procesem sprzedaży i wspierające podejmowanie decyzji na szczeblach strategicznego zarządzania produkcją. Poza materiałami związanymi bezpośrednio z produkcją, MRP II uwzględnia także materiały pomocnicze, zasoby ludzkie, pieniądze, czas, środki trwałe i inne.

Amerykańskie stowarzyszenie sterowania produkcją i zapasami (APICS), które opracowało w latach 60. algorytm MRP i następnie rozwinęło go do tzw. MRP w zamkniętej pętli (MRP closed loop), a dalej do MRP II, oficjalnie ogłosiło w roku 1989 dokument „MRP II Standard System”. Dokument ten opisuje funkcje, jakie powinien realizować system klasy MRP II:

• Planowanie biznesowe (Business Planning) - tworzony jest tu ogólny plan działania przedsiębiorstwa.
• Bilansowanie produkcji i sprzedaży (Sales and Operation Planning - SOP) - w wyniku tych działań powstaje plan produkcji i sprzedaży mające na celu realizacji planu biznesowego. Plany te określają wzajemne zbilansowane wielkości sprzedaży, produkcji oraz poziomu zapasów magazynowych w poszczególnych okresach. Plany te będą wyznaczać plany wszystkich innych planów operacyjnych w przedsiębiorstwie.
• Zarządzanie popytem (Demand Management - DEM) - obejmuje prognozowanie i planowanie sprzedaży oraz potwierdzanie zamówień klientów. Jej celem jest określanie wielkości przyszłego popytu i ciągła aktualizacja tej wartości.
• Harmonogramowanie planu produkcji (Master Production Scheduling - MPS) - funkcja ta służy do zbilansowania podaży w kategoriach materiałów, zdolności produkcyjnych, minimalnych zapasów względem popytu wyrażonego prognozami, zamówieniami odbiorców, promocjami.
• Planowanie potrzeb materiałowych (Material Requirements Planning - MRP) - dzięki tej funkcji określone są harmonogramy zakupów, produkcji oraz montażu wszystkich części składowych wyrobu wraz z priorytetami dla zaopatrzenia i produkcji.
• Wspomaganie zarządzania strukturami materiałowymi (Bill of Material Subsystem) - dostarcza informacji koniecznych do obliczania wielkości zleceń produkcyjnych i zaopatrzeniowych oraz ich priorytetów.
• Ewidencja magazynowa (Inventory Transaction Subsystem - INV) - wspiera prowadzenie ewidencji gospodarki magazynowej, dostarcza do innych funkcji informacji o dostępnych zapasach elementów.
• Sterowanie zleceniami (Schedule Receipts Subsystem - SRS) - kontroluje spływ (przyjęcie na ewidencję) elementów zaopatrzeniowych i produkowanych, w tym zaplanowanych przez MRP i MPS.
• Sterowanie produkcją (Shop Floor Control - SFC) - umożliwia przekazywanie informacji o priorytetach między osobą planującą produkcję a stanowiskami roboczymi.
• Planowanie zdolności produkcyjnych (Capacity Requirements Planning - CRP) - służy do badania, czy opracowane plany produkcji i sprzedaży oraz harmonogramu są osiągalne.
• Sterowanie stanowiskami roboczymi (Input/Output Control) - wspomaga kontrole wykonania planu zdolności produkcyjnych. Służy do kontroli kolejek na poszczególnych stanowiskach roboczych, wielkości prac na wejściu i wyjściu stanowiska.
• Zaopatrzenie (Purchasing PUR) - funkcja ta wspomaga czynności związane z nabywaniem towarów i usług od dostawców. Pozwala ona tworzyć zlecenie zakupu czy harmonogram przyjęć dostaw.
• Planowanie zasobów dystrybucyjnych (Distribution Resource Planning - DRP) - wspomaga czynności związane z harmonogramowaniem przesunięć wyrobów pomiędzy punktami sieci dystrybucyjnej oraz planowaniem produkcji międzyzakładowej.
• Narzędzia i pomoce warsztatowe (Tooling) - służy do planowania dostępności właściwych narzędzi specjalnych, aby można było bez przeszkód wykonać plan produkcji.
• Planowanie finansowe (Financial Planning Interface) - zadaniem jego jest umożliwienie pobierania z systemu MRP II danych o charakterze finansowym, ich przetworzenie i przekazywanie do osób odpowiedzialnych za planowanie finansowe.
• Symulacje (Simulation) - umożliwia ocenę wpływu wprowadzonych zmian do poszczególnych elementów MRP II na plany finansowe, potrzeb materiałowych i zdolności wykonawczych.
• Pomiar wyników (Performance Measurement) - jest to forma ciągłej kontroli efektywności wykorzystania systemu MRP II. Związane jest to z ustalaniem celów, które MRP II ma osiągnąć i sprawdzaniem, jak udaje się te cele osiągnąć.

Koncepcja MRP II została później rozbudowana do MRP II+ oraz ERP. Obecnie pod pojęciem MRP II rozumiemy zarówno rozbudowany algorytm do planowania produkcji i zapotrzebowania na zasoby, jak i standard opracowany przez APICS, w którym centralne miejsce zajmuje algorytm MRP II.

Zobacz też

• MRP
• ERP
• MPS
• Algorytm MRP

Przypisy

1. ↑ Darryl V. Landvater, Christopher D. Gray „MRP II Standard System. A Handbook for Manufacturing Software Survival” wyd. Oliver Wight Limited Publications, Inc., Essex Junction, Vermont, USA, 1989r.