Integrert administrasjonsprogramvare

En integrert administrasjonsprogramvarepakke eller ERP (på engelsk: Enterprise Resource Planning eller ERP ) er en programvarepakke som gjør det mulig å "administrere alle prosesser i et selskap ved å integrere alle dets funksjoner, inkludert personaladministrasjon, regnskap og økonomistyring, beslutning support, men også salg, distribusjon, anskaffelse og elektronisk handel ”.

Definisjon

Definisjonen gitt av CXP grupperer alle parametere for en ERP:

“For å bli integrert må en programvarepakke for administrasjon:

• kommer fra en enkelt designer;
• garantere brukeren den unike informasjonen som er gitt av tilgjengeligheten av hele databasestrukturen fra hver av modulene, til og med tatt individuelt;
• være basert på sanntidsoppdatering av endret informasjon i alle berørte moduler;
• gi revisjonsspor basert på garanti for full sporbarhet av ledelsesoperasjoner;
• dekker enten en ledelsesfunksjon (eller sektor), eller hele informasjonssystemet til selskapet. "

Når det gjelder konseptet med en enkelt forlegger, vil arbeidet til OAG (Open Application Group) bety at det i fremtiden sannsynligvis ikke vil være det samme.

Faktum er at "ERP" -objektet ikke er standardisert, og navnet forblir flytende: andre navn brukes som: programvarepakke, integrert programvarepakke, applikasjonsprogramvarepakke, integrert applikasjonsprogramvarepakke, administrasjonsprogramvarepakke, programvarepakke integrert administrasjon. ..

I møte med dette mangfoldet er de to grunnleggende dimensjonene som kjennetegner ERP-programvare:

1. ID eller grad av integrering: den definerer muligheten til å gi alle selskapets interessenter et enkelt, ærlig, sammenhengende og homogent bilde av all informasjonen de trenger for å kunne spille sin rolle.
2. CO eller operasjonell dekning: den definerer muligheten til å samle alle selskapets prosesser i hvert av dets sammensatte områder, i en tverrgående tilnærming som optimaliserer produktiviteten.

Historisk

Opprinnelsen til ERP kan bli funnet i metodene for planlegging av komponentkrav som er utviklet i sammenheng med en nødvendighet for i økende grad å integrere selskapets ledelsesfunksjoner. På 1960-tallet studerte Joseph Orlicky Toyotas produksjonsprogram og designet Material Requirements Planning ( MRP ). Deretter utviklet Oliver Wight og George Plossl MRP til produksjonsressursplanlegging (MRP2). Derav en utvikling i tre faser:

1. MRP0, på engelsk materialkrav planlegging null (bokstavelig talt " materialkrav planlegging 0"): metode for beregning av materialkrav, utviklet i 1965  ;
2. MRP1, på engelsk materialkrav som planlegger en  : første industrielle anvendelse av integrert produksjonsflytstyring, utviklet i 1971  ;
3. MRP2, på engelsk produksjonsressurser som planlegger to (litt. “Planning of resources for manufacturing 2”): i tillegg til beregningen av nettobehovet i råvarer og komponenter, gjennomfører en planlegging av lanseringene med tanke på kapasiteten til ressurser etter periode; utviklet i 1979 .

Fra rundt 1990 utvidet logikken som ble introdusert av MRP gradvis til alle selskapets funksjoner, for å gi “ERP” (E for selskap). Denne overgangen tilrettelegges av:

• Tilstanden til informasjonssystemer hvis “  grunnleggende applikasjoner er installert i forskjellige avdelinger (kundeservice, markedsføring, salg, regnskap, leverandører, produksjon, distribusjon, personell) og ikke tillater brukere å dele et felles språk. Hvis grensesnitt mellom disse forskjellige områdene i selskapet er satt opp, er de sjelden i sanntid, og eksempler der de samme dataene blir skrevet inn to eller tre ganger, eller enda mer, er ikke uvanlige. (...) kostnadene er uvurderlige: bortkastet tid, manglende effektivitet, dårlig synlighet, dårlig beslutningstaking, duplisering av innsats, høy feilrate. (...) Dysfunksjoner som resulterer (...) i dårlig kundeservice og tap av selskapets konkurranseevne  ”.
• "  Programvareutvikling er et felt (...) fremdeles på det kunsthåndverkede stadiet der komponenttilnærmingen - med andre ord objekttilnærmingen - fremdeles er i sin spede begynnelse  ". Programvareutvikling er sterkt avhengig av utviklerens individuelle kapasitet og er ikke drevet av det systematiske søket etter gjenbruk av det som har fungert bra tidligere. "  Programvarekomponenten (objektet) okkuperer ikke stedet som skal være mens en ny programvareindustri dukker opp som er inspirert av konseptene til produksjonsverkstedene i produksjonsindustriene: forskning, ingeniørarbeid, nomenklatur, montering, montering, versjon , reservedeler, varelager, gjenbrukbarhet, kvalitetskontroll  ”.
• Programvareobjekter er ikke de eneste tingene som må integreres bedre. Tekniske komponenter fra forskjellige og uavhengige leverandører letter ikke integrering: operativsystemer, kommunikasjonsprotokoller, database, grensesnitt for mennesker / maskiner, servermaskiner og klientmaskiner, lokalt og bredt nettverk, kontorautomatisering og multimediekomponenter, etc.
• Endelig har de dype endringene som er nødvendig av IT-overgangen til år 2000 og overgangen til euro (i eurosonen ) gjort at integrerte styringsprogramvarepakker har blitt ansett som en teknisk mulighet for å erstatte systemer som aldrer IT-systemer. som er vanskelige å konvertere på grunn av teknisk foreldelse. Den betydelige utvidelsen av denne programvaren på 1990-tallet forklares i stor grad av de tekniske forbedringene som ble gjort i utformingen og oppdateringen av informasjonssystemer, men også av de felles mulighetene til å revidere organisasjonene som ble åpnet ved denne anledningen.

ERP-problemer: bedre integrering

Konseptet med en ERP starter fra den enkle observasjonen at det er styrke i enhet.

• Integrering av komponenter: "  summen av optima er noen ganger mindre enn det optimale av summen  ". Med andre ord er fordelen med å ha en ERP at det totale bidraget til en ERP (naturlig integrert) alltid er større enn summen av bidragene til hver av modulene (av heterogen opprinnelse og konstitusjon) som utgjør den.
• Tilpassbar integrasjon: en ERP kan orienteres i henhold til virksomheten til organisasjonen. Ekte hjerne- og sentral organisasjonsstøtte for hele selskapet, en ERP tar sikte på en global, sammenhengende og forenklet ledelse.
• Brukerorientert integrasjon: for å gjøre dette, er valg av relevant programvare, konfigurasjon for å matche spesifisiteten til selskapets aktivitet, integrering i tjenester og reell tilegnelse av brukerne faktorene - nøklene til suksess. Oppsett og distribusjon av et slikt verktøy krever ofte en forsinkelse (ofte undervurdert) samt assistanse fra en spesialisert tredjeparts tjenesteleverandør som kalles en "integrator".

Industri

Industriell ERP stammer fra behovet for å planlegge produksjonen . Industriell ERP kan gjenkjennes av det faktum at den er basert på en sentral modul av CAPM- eller MRP- typen som gir mer eller mindre omfattende dekning av funksjoner som:

• ledelse av planleggings- og planleggingsprosessen;
• produksjon overvåking og produksjon sporbarhet ;
• lagerstyring, forsyning av råvarer, komponenter eller halvfabrikata;
• forvaltning av outsourcing , ledelse tjeneste , ledelse kvalitet .

Tjenester

ERP-er beregnet på å administrere tertiær aktivitet er ikke alltid oppført i ERP-kategorien. Et stort antall av dem retter seg imidlertid mot sektorer som er så varierte som helse, utdanning, distribusjon, detaljhandel og økonomi. Med forskjellige moduler som spenner fra prosjektledelse til veldig spesifikke forretningsfunksjoner (abonnementsadministrasjon, opplæringskurs, etc.). Tilbudet i feltet er mindre vanlig enn for industrien og mye mer fragmentert: ERP-utgivere ble forut i denne nisje og befinner seg i en situasjon med sterk konkurranse med GRC / CRM- programvareutgivere .

Det er imidlertid to familier av produkter:

• PSA-type verktøy ( profesjonell tjenesteautomatisering ) som er rettet mot serviceaktiviteter som krever en organisasjon i prosjektmodus: de er sentrert om tjenesten for prosjektledelsesfunksjonaliteter og muligens de av GRC / CRM , som derfor ikke dekker alle funksjonene av selskapet på samme måte som en ERP.
• ESA-verktøy ( enterprise service automation ) er mer i tråd med definisjonen av en ERP. ESA-løsninger er virkelig i stand til å betjene de vanlige funksjonene til et GRC / CRM- verktøy , (for eksempel å bestille eller utvikle et kommersielt forslag), men også de fleste av de administrative administrasjonsfunksjonene til et selskap.

Beskrivelse

Grunnprinsippet til en ERP er å bygge dataprogrammer (administrasjon av ordrer, aksjer, lønn, regnskap, etc.):

• på en modulær og integrert måte når det gjelder behandlingene som tilbys (de forskjellige modulene som komponerer den er uavhengige, men perfekt kompatible med hverandre);
• på en streng og sammenhengende måte når det gjelder dataene som administreres (deling av en enkelt og felles database ).

Dette fyller et viktig hull:

• I den allerede eksisterende situasjonen med ERP eksisterer skreddersydde applikasjoner , av forskjellige opprinnelser, best mulig, ikke deler eller lite data, og er ikke nødvendigvis alltid ment å jobbe enkelt og riktig sammen. IT-team har da mye å gjøre for å bygge og sette opp ad hoc- grensesnitt , hvis praktiske drift kan gi noen overraskelser.
• Kompatibiliteten mellom modulene som utgjør ERP garanteres av designeren: kompatibiliteten til innkjøpsmodulen med lagermodulen er garantert, som i seg selv er kompatibel med ordrehåndteringsmodulen. Dataene antas nå å være standardiserte og delte, noe som eliminerer flere oppføringer og (i teorien) unngår tvetydigheten i flere data av samme art (eksempel: firma TRUC, TRUC SA og Sté TRUC ...).

Det andre prinsippet som kjennetegner en ERP er systematisk bruk av det som kalles en arbeidsflytmotor (som ikke alltid er synlig for brukeren), og som lar, når data blir lagt inn i systeminformasjonen, spre det og tilby relevant logisk viser i alle modulene i systemet som trenger det, i henhold til en forhåndsdefinert programmering.

Dermed kan vi snakke om ERP når vi er i nærvær av et informasjonssystem som består av flere applikasjoner som deler en enkelt database, via et forhåndsdefinert automatisert system som kan konfigureres (en arbeidsflytmotor ).

Tilpasning til forretningssammenheng

ERP kan sjelden betraktes som et "nøkkelferdig" verktøy i den forstand at det ikke kan brukes direkte ved installasjon. Selv om det opprinnelig tilbyr datastyrte styringsprosesser som samsvarer med mye brukte standarder og beste praksis, er det noen ganger nødvendig å tilpasse dem til spesifikasjonene i selskapets organisasjon eller forretningsprosesser. Produktstandarddimensjonen og integrert integrasjon, som er viktige kjennetegn ved ERP-systemer, kunne ikke materialisere seg i en bestemt sammenheng uten den nødvendige tilpasningsevnen til standarden. Av denne grunn er ERP mer eller mindre konfigurerbare, dvs. det er mulig å tilpasse oppførselen til ERP (spesielt arbeidsflytmotorene som er nevnt tidligere) via dataverdier som kan administreres direkte av kvalifiserte forretningsbrukere eller av informasjonen systemavdelingen. Funksjonalitetene som ikke dekkes av produktstandarden, kan integreres i en eksisterende programvareversjon eller være en del av utgiverens veikart. Som en siste utvei kan bedrifter påkalle spesifikk utvikling for å dekke gjenværende hull mellom forretningsbehov og standard.

Organisasjonsstruktur

Strukturen er modelleringen i ERP av selskapets maske på alle ledelsesnivåer:

• Juridisk og finansielt nettverk: analytisk omfang, holdingselskap, selskaper, datterselskaper;
• Logistikknettverk: produksjonssteder, distribusjon ...
• Funksjonelle lenker: de fleste av selskapets funksjoner (innkjøp, salg, butikk osv.) Har sin egen organisasjonsstruktur. Eksempel: organisasjonsstruktur for salg inkluderer en eller flere kommersielle organisasjoner, distribusjonskanaler, aktivitetssektorer, kommersielle byråer, etc.

Organisasjonsstrukturen er grunnlaget for en ERP, bare definisjonsdataene (eksempel: definisjon av leverandøren inkludert identifikator, sosial adresse osv.) Kan være uavhengig av organisasjonsstrukturen, alle ledelsesdata er definert i en eller flere ledelse nivåer. I tillegg forutsetter organisasjonsstrukturen IT-prosessene til en ERP. For eksempel vil de fleste ERP-er gjøre det mulig å håndtere overføringsflyter mellom to nettsteder modellert som sådan i organisasjonsstrukturen. I tillegg, hvis disse to nettstedene tilhører to forskjellige selskaper i samme organisasjonsstruktur, vil en fakturaprosess mellom selskaper være knyttet til overføringsflyten.

Data

ERP-databasen inneholder all informasjonen som er nødvendig for selskapet, felles for de forskjellige modulene. Den første tabellen er produkttabellen. Så i henhold til selskapets orientering, inneholder nomenklaturer, områder, råvarer, produksjonskapasitet, mengder. På den annen side administreres kunder eller leverandører, så vel som deres bestillinger eller leveranser, opp til leverandørkatalogene. Et tredje aspekt vil inneholde lagre, lagringstider, transporttider for transportører. Til slutt, men listen er langt fra uttømmende, det er nesten alltid tabeller om de økonomiske aspektene ved selskapet.

De grunnleggende produktdataene er sentrale data for driften av ERP. Den inneholder et stort antall innstillinger på brukernivå (som skiller seg fra IT-innstillinger) som betinger ERP-behandlingen. Disse innstillingene må følge med endringer i produktstyringspolitikken eller innvirkningen av disse retningslinjene på endrede markedsforhold. De er derfor underlagt regelmessig overvåking og oppdatering under bruk av ERP.

Behandlinger

Godt programmert og underlagt tidligere avtaler, er en ERP også i stand til å kommunisere med leverandører for å anbefale vanlige råvarer eller med transportører. Børsen gjøres oftest med bud.

Evaluering av bruk av ERP

Implementering av ERP

Et ERP-prosjekt er et transformasjonsprosjekt. For at en ERP skal lykkes, må selskapet mobiliseres fullt ut.

• Konsernsjefen eller forretningsdivisjonene blir mobilisert fra fasen av å velge en ERP med utvikling av en business case som har som mål å dele mye i selskapet, årsakene til implementeringen, målomfanget og forventede gevinster.
• En valgfase gjør det mulig for selskapet å finne partnerne som vil støtte det, vanligvis en redaktør (av ERP), en integrator (eller et spesialisert IT-serviceselskap ) for implementeringen og noen ganger et konsulentselskap for redesign av prosessene. Og støtte for Endringer.
• ERPer er satt opp i organisasjoner i "prosjektmodus". Metodikken er basert på tilnærminger og verktøy for prosjektledelse til risikostyring og spesielt endringsledelse som kreves for transformasjonsprosjekter og derfor viktig for ERP-prosjekter.
• Den grunnleggende metodikken i et ERP-implementeringsprosjekt inkluderer følgende hovedfaser: generell design (samling av forretningsbehov, definisjon av IT-prosesser og identifisering av avvik fra produktstandarden), detaljert design (definisjon av funksjonaliteter brukt av prosess- og styringsregler), implementering (konfigurasjon, teknisk design og spesifikk utvikling), integrasjonstester (systemtester som gjør det mulig for integratoren å sikre at løsningen er i samsvar med det generelle + detaljerte designet), aksept (tester virksomhet, en valgt populasjon av fremtidige brukere spiller strømmer som tilsvarer selskapets operasjonelle aktivitet), produksjon (eller oppstart), støtte etter oppstart.
• ERP-oppstart av "Big Bang" (alle nettsteder startes samtidig) implementeres sjelden i store selskaper. Faktisk :
  • I løpet av designfasen av ERP er det vanskelig å ta hensyn til uttømmingen av behovene til hvert område. Nettstedene er ikke nødvendigvis alle på samme modenhetsnivå, og mangfoldet av involverte aktører kan være en brems.
  • Ledelsen av endringen og organisasjonen som skal implementeres for oppstarten kan være ekstremt belastende og risikofylt.
• Når de starter i et "Big Bang", foretrekker store selskaper ofte tilnærmingen til å bygge en "Core Model" og "Deployment" som består i å bygge og starte en første løsning for et pilotanlegg ("Core Model") og deretter starte de andre nettsteder etter hverandre i en definert rekkefølge ("Distribusjon"). Mesteparten av tiden gir en distribusjon et "Gap Analysis" -design for å identifisere forskjellene mellom forretningsbehovet til det distribuerte nettstedet og "Core Model" for å integrere dem i det for å starte nettstedet.

fordeler

ERP (i motsetning til dedikerte applikasjoner ) har flere fordeler:

Innfødte fordeler med ERP-er

• Integrering av styringsprosesser
• Konsistens og homogenitet av informasjon (en enkeltvarefil, en enkelt kundefil, etc.);
• Integriteten og unikheten til informasjonssystemet  ;
• Deling av det samme informasjonssystemet som letter intern og ekstern kommunikasjon;
• Pålitelighet. Et selskap som velger en ERP, drar generelt fordel av et verktøy som har blitt bevist av mange selskaper i sin virksomhetssektor og dermed kontinuerlig pålitelighet for vedlikehold av utgivere.
• Skalerbarhet, garantert av konsistensen av datamodellen som ligger til grunn for alle IT-prosesser / funksjonaliteter som ERP dekker. ERP tillater en tilpasset og progressiv implementering av disse prosessene / funksjonalitetene.
• Rasjonalisering av applikasjonen og teknisk arkitektur: reduksjon i antall verktøy og følgelig i grensesnittene mellom disse verktøyene, potensiell reduksjon eller optimalisering av maskiner og servere som støtter informasjonssystemet.
• Minimering av kostnader: ingen grensesnitt mellom modulene, synkronisering av behandlinger, forenklet korrigerende vedlikehold fordi det utføres direkte av forlaget og ikke lenger av selskapets IT-avdeling (sistnevnte er fortsatt ansvarlig for løpende vedlikehold: forbedring av funksjonalitet, utvikling av styringsregler osv.);
• Globalisering av trening (samme logikk, samme ergonomi);
• Nedgang i antall ansatte hvis hovedoppgave er å føre kontoer (bokholder);
• Kontroll av kostnader og tidsfrister for implementering og distribusjon;
• Tilgjengelighet og modenhet (når det gjelder kostnader, tidsfrister, kvalitet) på tjenester dedikert til ERP.

Muligheter knyttet til implementering av en ERP

• Fremme integrasjon mellom avdelinger, materialisere selskapets strategi og ledelsespolitikk i informasjonssystemet.
• Samle forretningsområdene og IT-avdelingen, tilegnelse av informasjonssystemet av forretningsområdene. Ettersom ERP-er er modellert av forretningsprosesser og fleksible, fremmer de fremveksten av en bedriftspopulasjon som er klar over de tekniske aspektene ved ERP, og en CIO-befolkning som er klar over sine forretningsaspekter.
• Utvide integrasjonen av informasjonssystemet til oppstrøms og nedstrøms logistikkjede (leverandører og kunder).
• Standardiser IS-prosesser og distribuer standarder på tvers av alle bedriftsorganisasjoner.

Dette siste punktet er viktig, og implementeringen av en ERP i et selskap er ofte forbundet med en grundig gjennomgang av organisering av oppgaver og en optimalisering og standardisering av prosesser, basert på det "normative rammeverket". Av PGI.

ERP-er vil være i stand til å administrere og ta ansvar for:

• flere enheter eller organisasjoner som HA ();
• flere foreninger som OAC (konferanse);
• flere valutaer  ;
• flere språk for brukere og klienter (tilfelle multinasjonale selskaper );
• flere lovgivninger;
• flere kontoplaner  ;
• flere analyseakser i kostnadsregnskap.

NB: Fordelen med å anskaffe en ERP, når det gjelder regnskap, er å opprette regnskapsoppføringer i sanntid, og automatisk. Det er et produktivitetsverktøy fordi det gjør det mulig å eliminere overflødige oppføringer, og å dele mer pålitelig informasjon. Bruken av en enkelt database gjør det mulig å samle alle dataene og dermed sikre konstant oppdatering av disse dataene. Det kan også kobles til et online salgsside for sanntids datasynkronisering.

Ulemper

ERP-er er imidlertid ikke fri for ulempene:

• Implementering kan vise seg å være kompleks hvis funksjonsomfanget er dårlig bestemt eller for flytende eller prosjektet er dårlig administrert;
• høye kostnader og kan raskt øke avhengig av bransje og kompleksiteten i prosjektet. For eksempel brukte det kjemiske selskapet Dow Chemical 500 millioner dollar og brukte sju år på å implementere ERP-programvare som viste seg å være foreldet før den til og med kunne brukes. Det funksjonelt rikt alternativet med gratis programvareløsninger hvis det reduserer lisenskostnadene, ikke eliminerer støtte- og opplæringskostnadene. Kostnadsparameteren er også en funksjon av tungvint og stivhet ved implementeringen av verktøyet, som kan økes av vanskeligheter med å tilegne seg av brukerne. Slike vanskeligheter kan til slutt føre til konkurs for det aktuelle selskapet. På slutten av 1990-tallet , FoxMeyer Drug Corp anklaget SAP gruppe av etter å ha kjørt den i konkurs på grunn av de utgifter og de vanskelighetene i å gjennomføre sine ERP.
• funksjonelt omfang som ikke er tilpasset organisasjonens reelle behov: programvarepakken kan være for stor og derfor underbrukt hvis den er større enn de faktiske behovene til organisasjonen, eller tvert imot være for stor hvis den ikke er ikke i stand til å dekke alle påviste behov;
• behov for god kunnskap om selskapets prosesser (for eksempel en liten ordre og en stor ordre krever to forskjellige prosesser: det er viktig å vite hvorfor, å vite hvordan man kan beskrive forskjellene mellom disse to prosessene for å kunne konfigurere dem riktig tilpasse standarddriften til ERP til bedriftens behov);
• fangenskap overfor utgiveren: den valgte programvarepakken kan ikke alltid tilpasse seg organisasjonen som er utstyrt. Valget av en løsning blir veldig strukturerende for selskapet, og utover en enkel konfigurasjon vil det være opp til organisasjonen å tilpasse seg programvarepakken (og ikke omvendt). I tillegg kan ERP-verktøyet være ekstremt tungt og kostbart å administrere, spesielt hvis det krever kontinuerlig vedlikehold og hvis det gjør det vanskelig å tilpasse (eller til og med forlate det for et annet produkt).

Et integrert tilbud vises med kontorinspirerte produkter basert på de mest brukte databasestyringssystemene på markedet: MSSQL , MySQL , Oracle , DB2 . Disse produktene distribueres vanligvis av forlag som spesialiserer seg på produksjonsledelse. Ulempene som er sitert her er da mindre.

I tillegg gjør den nylige fremveksten av flere gratis ERP-systemer det mulig å minimere ulempene med kostnad (knyttet til anskaffelse av programvarelisenser), stivhet og spesielt fangenskap. Bruk av åpne formater letter også utveksling av data, internt og eksternt.

Til slutt er bærekraften til utgiveren et viktig element å sjekke før du forplikter deg til et ERP-prosjekt. Den virkelige kostnaden er tiden som brukes internt, mer enn kostnaden for å kjøpe lisensene. Gyldigheten av den økonomiske modellen til den valgte partneren over tid er et grunnleggende kriterium. Uansett hvilket produkt som velges, med samme arbeidsmetode og identisk funksjonsomfang, er ikke kostnadene nødvendigvis veldig langt fra ett selskap til et annet når vi sammenligner de historiske aktørene som holder ut i dette svært konkurransedyktige miljøet.

Vurdering av bidraget

Integrerte programvarepakker for administrasjon har gjort det mulig for mange selskaper å få bedre kontroll over sine aktiviteter:

• En del av veksten kan forklares med den nødvendige utviklingen av informasjonssystemer for overgangen til år 2000 og deretter for innføringen av euroen . Faktisk har en rekke selskaper ansett det å foretrekke å erstatte et forskjellig og ikke-homogent sett med programvare med en integrert programvarepakke i forkant av teknologien i stedet for å sette i gang korrigeringer av eksisterende mer eller mindre gamle programmer.
• Hvis denne tilnærmingen noen ganger har gitt opphav til presserende oppstart, er utfordringen med å etablere en ERP i dag ikke lenger å passere år 2000, men å optimalisere styringen av logistikkstrømmer og økonomiske aspekter ved selskapet. Den paradigme på hvilken de er basert i det vesentlige på å optimalisere bruken av ressurser, både folk og materiell. ERP induserer derfor en strategisk orientering mot kostnadsreduksjon som en vesentlig vektor for verdiskaping og derfor for bedriftsvekst. Denne modellen har blitt kritisert siden tidlig på 1990 - tallet fordi den setter selskapet (og muligens dets leverandører) i sentrum av oppmerksomheten, til skade for kunden.

De viktigste ERP-utgiverne er gruppert sammen i foreninger som BASDA Business Application Software Developers Association  ;

Fremtiden for ERP

Store ERP-er tilbyr brukerne omfattende funksjonell dekning. Men rikdommen i dette tilbudet kommer raskt opp mot visse grenser:

• Ingen ERP kan hevde å tilsvare perfekt til alle handler eller aktiviteter. Når ERP-ene har kommet ut av kjernevirksomheten, har de det vanskelig å tilby visse funksjoner (bortsett fra å behandle dem på en mer kompleks eller til og med gjennomsnittlig måte). Programvare som dekker nisjefunksjonalitet er fortsatt konkurransedyktig.
• Den tekniske integrasjonen av prosessering og data når et kompleksitetsnivå som grenser til håndterbart (en korreksjon som kan ha innvirkning på et helt sett med funksjoner, ofte med forutsetninger, medforutsetninger og underkrevde korreksjoner). De fleste av disse programvarepakkene har nå en modul for å håndtere disse rettelsene (modulen som administrerer modulene).
• Markedskrav eller regulatoriske krav fornyes kontinuerlig, og de viktigste ERP-leverandørene må hele tiden strebe etter å integrere eller oppdatere nylig nødvendige funksjoner som kundeforholdsstyring , risikostyring , bærekraftig utvikling .
• Bedriftenes behov når det gjelder IT-løsninger har utviklet seg betydelig: økende samarbeid (internt, men også eksternt med partnere), økt dematerialisering som påvirker alle virksomheter, mobilitet og nomadisme for ansatte, økonomiske begrensninger, stadig strengere juridiske og regulatoriske miljø ..., ledelse verktøy som ERP-er som tidligere ble distribuert av selskaper, viser seg noen ganger å være begrensende og uegnet for denne nye konteksten, og deres utvikling er uunngåelig.
• Utviklingen av Cloud Computing som krever at utgivere tilpasser programvarepakkene sine slik at de er tilgjengelige online på Internett via delte plattformer (" multi-tenants "), fakturert månedlig av antall brukere og ikke via en høy lisens. Første år og en månedlig kostnad (15-20% avhengig av utgiver).

Derfor er en funksjonell og teknisk vending i ferd med å bli tatt med fakultetet for å distribuere mer spesifikke og / eller mer avanserte funksjoner i form av teknisk uavhengige applikasjoner som er grensesnittet med ERP-kjernen. Dette oppsettet er bygget i henhold til en IAE- arkitektur ( Enterprise Application Integration ). Denne artikulasjonen betyr at brukeren samtidig har:

• funksjoner som er i stand til å styre hele dybden av virksomheten;
• et bredt spekter av applikasjoner som dekker de fleste av ledelsesbehovene.

Noen av de spesialiserte applikasjonene som ofte kreves av brukerne inkluderer administrasjon:

• lager (IMS eller WMS );
• workshops ( MES );
• laboratorier ( LIMS );
• kundeforhold ( CRM );
• forsyningskjeden ( SCM );
• vedlikehold ( CMMS );
• anskaffelser ( e-anskaffelser ) .

Hvis tilnærmingen i dag er på et embryonisk stadium, både når det gjelder ytelsen til tekniske arkitekturer og funksjonelle konstruksjonsmetoder, er utviklingen av den tekniske strukturen til programvarepakker klart i gang og akselererer. Spesielt er det flere globale løsninger som kalles forretningsapplikasjoner (ERP, SCM, CRM, LPM, SRM, Sidetrade, etc.) og ERP basert på en bedriftsplattform Bestående av en serviceorientert arkitektur inkludert spesielt en forretningsprosess. administrasjon (BPMS) som gir stor fleksibilitet og respons på forretningsbehov.

Merknader og referanser

1. “  integrert administrasjonsprogramvarepakke  ” , på www.gdt.oqlf.gouv.qc.ca (åpnet 13. mars 2019 )
2. CXP-informasjon februar 1994
3. Jean-Louis Tomas, ERP og ERP: utvalg, distribusjon og operativ bruk: hvordan lykkes i endring , Paris, Dunod ,2005, 325  s. ( ISBN  978-2-10-049024-0 , OCLC  154659060 , les online )
4. "  Den sosialiserte programvarepakken Bruk av dataarkitekturer i avdelings sosialhjelp og handling  ", Regjering og offentlig handling ,februar 2015( les online )
5. Oliver W Wight, produksjonsressursplanlegging: MRP II; frigjøre Amerikas produktivitetspotensial ( les online )
6. MRP - Beregning av krav
7. ERP og integrert styringsprogramvare, Jean Louis Tomas, O1 Informatique, Dunod 2002
8. Jean Louis Tomas, op. cit.
9. Kilde: PGI-kurs Douai gruveskole - åpen lisens
10. (i) Alex Hill og Terry Hill, Essential Operations Management , Palgrave ,2011, 480  s. ( ISBN  978-0-230-23259-4 ) , s.  270.
11. VR, "  SAP blir saksøkt for 500 millioner dollar av et amerikansk selskap  ", Les Échos ,28. august 1998( les online , konsultert 11. mai 2018 ).
12. Les ERP , 26. mars 2004, M. Volle
13. Kilde: studie av Markess International - Repository of practices Selskapets forventninger til ERP / ERP integrerte styringsløsninger i møte med nye utfordringer, 2011-2013

Se også

Relaterte artikler

• Liste over ERP-programvare
• Kontorsuite online ( Collabora Online  (no) , Zoho One ...)
• Ledelse