SAP-implementeringsresultater. SAP implementeringsmetoder. Bedrift B: Internasjonal bilprodusent

Hilsen!

Som lovet gir jeg i dag en annen nyttig informasjon for utviklingen din.

Skal prøve med enkle ord få frem poenget SAP ASAP metodikk, som den dag i dag er hjørnesteinen på veien til vellykket implementering av SAP ERP-systemet i bedrifter.

Først litt bakgrunn.

Selv om allsidigheten og fleksibiliteten til SAP-systemer gjør det mulig å møte kravene til en lang rekke bransjer, er en rimelig tidsramme for implementering av SAP en av de viktigste faktorene som et selskap må ta i betraktning når de vurderer muligheten for å implementere SAP ERP. Ettersom den høyteknologiske, verdifulle systemsektoren kommer inn på markedet informasjonsteknologi ble stadig mer mettet på 90-tallet, begynte SAPs potensial i SMB-sektoren å dukke opp. Denne typen kunder har ikke tilstrekkelige ressurser og tid til å gjennomføre ERP-implementeringsprosjekter, som kan vare fra to til tre år.

I 1996 introduserte SAP AcceleratedSAP (ASAP)-metodikken, med sikte på å akselerere implementeringsprosjekter betydelig. ASAP-metodikken har gjort det mulig for nye kunder å dra nytte av erfaring og ekspertise gjennom et stort antall implementeringer rundt om i verden.

Hva er ASAP?

ASAP – en metodikk for rask implementering og kontinuerlig optimalisering – består av en Roadmap-metodikk, som er knyttet til verktøy som IMG (implementation Guide), og ASAP ble utviklet spesielt for mellomstore og små bedrifter som ikke kan ta lang tid å implementere.

ASAP-metodikken består av en rekke sjekklister, tabeller, spørreskjemaer, svar, dokumentmaler, retningslinjer osv. I tillegg tilbyr ASAP guider, opplæringsverktøy og akseleratorer på et stort spekter av tekniske problemstillinger knyttet til infrastruktur, installasjon og drift av SAP. De ulike gjennomgangene og sjekklistene som er tilgjengelige hos ASAP overvåker ikke bare fremdriften i selve prosjektet, men også stabiliteten og integreringen av systemet i alle stadier av prosjektet.

Metodikk Nettverksgrafikk(Roadmap) inkluderer også endringshåndteringsoppgaver og akseleratorer som er nødvendige for å håndtere bedriftsendringer forårsaket av SAP-implementering.

I denne artikkelen skal jeg ikke fordype meg i teorien den er ikke så viktig og interessant nå. La oss se på selve ASAP-komponenten - Roadmap eller Nettverksdiagram, slik den ble oversatt i Russland.

Nettverksdiagram(Roadmap) fungerer som en prosjektveileder som avklarer stadier, nødvendige milepæler og setter det overordnede tempoet i hele prosjektet for å få et brukbart system på kortest mulig tid, med maksimal kvalitet og innenfor budsjett. ASAP nettverksdiagrammet består av neste trinn: prosjektforberedelse, konseptuell design, implementering, endelig forberedelse, lansering og støtte, optimalisering.

Prosjektforberedelse

Hensikten med denne fasen er å sikre planlegging og forberedelse av SAP-implementeringsprosjektet. Blant nøkkeloppgavene som må løses under prosjektforberedelsesprosessen:

Bestemme målene og utsiktene for prosjektet,

Den mest nøyaktige vurderingen av implementeringsvolumet,

Bestemme implementeringsstrategien,

Bestemme den overordnede arbeidsplanen for prosjektet og sekvensen for systemimplementering,

Definere prosjektets organisasjonsstruktur og komiteer,

Ressursfordeling.

Nøyaktige svar på disse spørsmålene i begynnelsen av implementeringen sikrer effektiv implementering av prosjektarbeid og er nøkkelen til vellykket SAP-implementering.

Konseptuelt prosjekt (Business Blueprint)

Målet med denne fasen er å lage et konseptuelt prosjekt (Business Blueprint), som representerer kundens detaljerte tekniske og forretningsmessige krav til systemet, og dermed oppnå en fullstendig forståelse av kundens forståelse av organiseringen av forretningsprosesser i SAP-systemet. På det konseptuelle designstadiet bestemmes opprettelsesstrategien informasjonssystem, som gir rask avkastning på investeringen. Utviklingen av et konseptuelt prosjekt gjør det ikke bare mulig å ha et handlingsprogram for trinnvis implementering, men også å oppnå betydelige økonomiske fordeler ved å forbedre det eksisterende bedriftsstyringssystemet.

Innenfor rammen av konseptuell design løses følgende oppgaver:

Definisjon og analyse av forretningsprosesser,

Formalisering og dokumentasjon av krav til fremtidens system,

Detaljering og godkjenning av det endelige omfanget av prosjektet,

Utvikling av systemarkitektur og fastsettelse av grunnleggende designløsninger,

Analyse og utforming av treningsstrategi,

Deretter utvikles en arbeidspakke for å lage en prototypeløsning. I dette tilfellet fokuseres innsatsen på prosesser som kan konfigureres uten ytterligere programmering eller utvidelser til SAP-systemet. Implementering av krav som krever tilleggsprogrammering eller utvidelser skjer i separate arbeidspakker i implementeringsfasen.

Realisering

På prosjektimplementeringsstadiet konfigurerer prosjektteamet systemet under hensyntagen til kravene til det konseptuelle designet ved hjelp av IMG (implementeringsguide), nødvendige modifikasjoner og testing av systemet.

Systemtesting for etterlevelse av kundekrav utføres i et eget SAP-system for kvalitetskontroll og utføres i to trinn:

Funksjonstesting

Integrasjonstesting

På funksjonsteststadiet kontrolleres funksjonene til hvert delsystem. På integrasjonsteststadiet kontrolleres funksjonaliteten til ende-til-ende forretningsprosesser.

Testresultatene registreres i protokollen, og på grunnlag av dem identifiseres manglende overholdelse av systemet med kravene og kommentarene elimineres.

Resultatet av denne fasen bør være et fullt konfigurert og testet SAP-system som oppfyller alle bedriftens krav.

Endelig forberedelse

Som en del av dette stadiet forberedes systemet for industriell drift. Alle eksepsjonelle situasjoner er løst og inkonsekvenser elimineres.

Gjennomført belastningstesting, når systemets motstand mot høy serverbelastning kontrolleres. Data blir også migrert fra de historiske systemene til kundebedriften til SAP-systemet.

SAP-konsulenter gir opplæring til nøkkel- og sluttbrukere i hvordan systemet skal brukes. Spesielt er brukerveiledning under utvikling undervisningsmateriell, sammensetning av grupper og opplæringsperioder planlegges, og på slutten gjennomføres en endelig sertifisering av brukere.

Lansering og støtte (Go Live Support)

Dette er fasen for å løse problemer knyttet til lansering av systemet. Beredskap for lansering kontrolleres og mulige problemer elimineres.

SAP-konsulenter gir daglig brukerstøtte og eliminerer også tidligere skjulte feil og inkonsekvenser i systemet.

Ved behov kan systemet, etter avtale med Kunden, suppleres med funksjoner som ikke er tilrettelagt av det tidligere avtalte omfanget av prosjektet. I dette tilfellet gjøres endringer i prosjekteringsdokumentasjonen i henhold til de nye kravene til utvikling av det ferdige systemet og systemet er ferdigstilt.

Optimalisering (Kjør SAP)

Hovedmålet med denne fasen er å sikre påliteligheten og optimaliseringen av løsningen. Supportsenteret gir kundestøtte og systemovervåking for å identifisere prosesser som må optimaliseres. For eksempel:

Optimalisering av løsningsdokumentasjon

Optimalisering av løsningsimplementering

Maloptimalisering

Optimaliseringsteststyring

Optimalisering av vedlikehold, oppgradering m.m.

Her er i korte trekk alle stadier av implementering av SAP ERP i bedrifter. Forhåpentligvis forstår du nå hvorfor ASAP-metodikken er så viktig ved implementering.

Ved å bruke denne klare og trinn-for-trinn-skjema lar deg redusere implementeringstiden, redusere kostnader og minimere prosjektrisiko, noe som er så viktig for kunden.

Vi ses i kontakt,

Nikita.

Var det nyttig? Lik og les neste nyttig informasjon akkurat nå:

Bedriftsressursstyringssystem SAP ERP dekker alle områder innen økonomisk og ledelsesregnskap, personalledelse, operativ virksomhet og selskapstjenester. Gir full funksjonalitet som er nødvendig for implementering av selvbetjente informasjonstjenester og analyser.

Automatisering i industrien har lenge blitt en vanlig prosess. Smarte kontrollere kontroller teknologiske prosesser på moderne bedrifter alle bransjer, overføring av informasjon til datamaskiner for menneskelig analyse og beslutningstaking.

Automatiser ledelsesbeslutningerå bruke en kontroller er umulig, derfor har integrerte systemer blitt utviklet og implementeres med suksess over hele verden, for eksempel, som er en designer av sammenkoblede moduler for å kontrollere produksjonsprosessen.

Litt om selskapet og produktet

I 1972 i Tyskland, fem tidligere ansatte SAP ble grunnlagt av IBM Corporation Systemanalyse og programvareutvikling). Målet deres var å utvikle standard programvare som integrerer alle forretningsprosesser i en bedrift i sanntid.

Etter 25 år har selskapet blitt den utvilsomt ledende innen automasjonsnisjen for enterprise resource planning (ERP). I dag er det et selskap med filialer og datterselskaper i alle industrialiserte land.

I Russland går selskapets historie 20 år tilbake. Det første kontoret til dette internasjonale selskapet ble åpnet i Moskva tilbake i 1992. I dag opererer kontorer i St. Petersburg, Novosibirsk, Jekaterinburg, Rostov-on-Don; Russisk har blitt et av hovedspråkene for lokalisering av programvareprodukter; mer enn 1000 russiske ansatte er involvert i implementeringen av grunnleggende programvareløsninger.

Hva er det

SAP ERP er et bedriftsinformasjonssystem basert på ERP-metodikken (enterprise resource planning) og rettet mot å oppnå optimale forretningsprosesser.

For store statseide industrigiganter er stabil utførelse av offentlige ordrer innenfor en strengt spesifisert tidsramme nødvendig for private industribedrifter, fortjeneste og tilbakebetaling av utstyr er viktigere.

Prosjekter implementert ved hjelp av SAP hjelper både offentlige og private strukturer med å optimalisere kostnadene og nå målene sine i alle trinn produksjonssyklus. Samtidig er grunnlaget for å ta ledelsesbeslutninger basert på individuelle metoder og prinsipper som kun er relevante i en konkret sak. Flere detaljer om.

SAP ERP - lar lederen se produksjonsprosessen i sanntid, mens han, uten å fordype seg i essensen av problemene, korrekt vurdere dynamikken i bevegelsen av prosesser i bedriften.

Video: SAP ERP - Introduksjon

Hovedmoduler i programmet

Regnskap og kontroll er nødvendig i enhver virksomhet, i virksomheten står hver prosent av overskuddet, derfor innføring av informasjonssystemer som kan redusere rutinedrift med mer enn 50 %, vise åpenhet i produktproduksjonsprosesser og gi enkel tilgang til evt. nødvendig informasjon– Dette er veien til effektiv drift av organisasjonen. Den nye generasjonen SAP-arkitektur lar deg effektivt løse en rekke problemer bedriften står overfor.

Alle viktige aktivitetsområder:

operativ produksjonsstyring;
regnskapsområder (regnskap, finans, lager, transport);
planlegging og kontroll;
rammer.

Som et resultat: det er ikke bare bred funksjonalitet, men også fullstendig integrasjon mellom moduler.

Et sett med standardmoduler designet for å administrere alle aktivitetsområder er gitt nedenfor.

Tillegg til pakken

Behovet for programvareoppdateringer er forårsaket av livet selv, den konstante fremadgående bevegelsen av menneskelig tanke. Det som var bra for 10 år siden i dag krever forbedringer med tanke på dagens realiteter. Derfor har SPA-spesialister utviklet en ny leveringsstrategi programvare for dine prosjekter.

Dette er utvidelsespakker som gir nye funksjonalitet innenfor en bestemt brukergruppe, uten å påvirke prosjektarkitekturen som helhet.

I dag er den fjerde oppdateringspakken utgitt, som gir ytterligere muligheter innen økonomistyring, innkjøp, salg, personell, etc. Den inkluderer alle tidligere oppdateringer, har tilleggsfunksjoner og tjenester for arbeid med WEB-grensesnittet, og inkluderer nye bransjeløsninger.

Et eksempel er RCM-modulen – dette er elektronisk dokumenthåndtering. Det kalles ellers Enterprise Content Management-modulen. Et praktisk element for arbeid med dokumentasjon.

Implementeringsstadier

Implementeringen av enhver informasjonsprosess er en vanskelig, steg-for-steg, lang og kostbar vei. Men enhver fase av prosjektet som implementeres må ha et sluttprodukt med en beskrivelse.

Prosessen med å starte et prosjekt kan deles inn i følgende stadier:

opprettelse av prosjektledelsesdokumentasjon (ordre, charter, tidsplan);
inspeksjon av automatiseringsobjektet;
konseptuell design. (oppretting av en bedriftsstyringsmodell);
trinnvis implementering;
brukerstøtte og opplæring.

For å øke kunnskapsnivået og forbedre arbeidsferdighetene er det nødvendig å gi brukerne opplæringslitteratur.

Fordeler med å implementere en ERP-pakke

I tillegg til at dette er et svært kostbart prosjekt, endrer det også ledelsesstrukturen i selskapet. Derfor er det umulig å evaluere hvordan prosjektet fungerer uten å analysere og vurdere effektiviteten av endringer i arbeidet.

Og likevel...Innføringen av programmer i denne klassen gjør det mulig å fjerne de mest "smertefulle punktene" i virksomhetens arbeid. Disse inkluderer "gjennomsiktighet" i produksjonen og ineffektivitet. For å forstå "hvor det gjør vondt", må lederen av en organisasjon studere "symptomene". Det er dette et slikt system bidrar til.

Det eliminerer også problemet med menneskelig faktor ineffektivitet ved å automatisere et stort antall funksjoner. Der en person brukte mer enn en dag på å utarbeide en rapport, genererer systemet data på noen få minutter.

Hva er SAP R3: beskrivelse

SAP R3-programmet får mest popularitet på det russiske markedet. Hva er det? Dette er en pakke med forretningsapplikasjoner som i siste versjon 4.0 støtter full Internett-tilgang, tilgjengelig for små og mellomstore bedrifter basert på prisegenskaper. Pakken tillater standardisering av interne forretningsprosesser og øker effektiviteten til virksomheten.

Alle viktige områder innen planlegging, produksjon, kontroll er inkludert i systemet. Bygget på klient/server-prinsipper, har den blitt tilgjengelig for mellomstore bedrifter.

Innføringen av slike systemer siden 1995 gjør at vi kan slå fast at de i dag opererer i mer enn 40 land. I Russland er det veldig mye brukt for å generere bestillinger og foreta leveranser.

Flere og flere representanter for mellomstore og små bedrifter innser behovet for integrert automatisering av sine bedrifter, dette tilrettelegges av innovasjonene til SAP, som utvikler prosjekter som er rimelige og tidsriktige for implementering for denne markedsnisjen, for eksempel "Finansiering" .

I følge statistiske undersøkelser stemmer allerede 76 % av gründerne at IT er deres assistent i næringslivet. Konkurranseprosessen tvinger ledere til å komme til riktig avgjørelse: engasjere seg i implementeringen av SAP-prosjekter.

I denne kolonnen lærer du hvorfor SAP-prosjekter er mer enn bare tekniske programvareprosjekter. SAP er en integrert, prosessorientert programvare som har stor innvirkning på vår virksomhet. Bruken endrer alvorlig måten vi nærmer oss prosjekter på, så vel som ideen om hvordan implementeringen skal se ut.

1.1. Dagen jeg ble 10 år

Jeg husker den spesielle morgenen i 1997 da jeg ankom vårt filippinske kontor. Tre uker tidligere feiret vi overgangen til produktiv drift av SAP med champagne. Manila-prosjektet vårt var vårt syvende i Asia Pacific-regionen (APAC), noe som gjorde lyden av flasker som åpnes til en hyggelig daglig begivenhet for oss som regional programvareleder. Målet med prosjektet vårt var å implementere modulene Sales and Distribution (SD), Materials Management (MM), Production Planning (PP) og Quality Management (QM) på alle produksjonsanlegg i APAC-regionen. På det tidspunktet var vi ganske sikre på at vi hadde dekket alle mulige hindringer for en vellykket implementering, og denne saken ville ikke være annerledes. Vår overvåking noen dager tidligere viste imidlertid at salget på Filippinene gikk ned 40 % for måneden og produksjonen var ned 50 %. Vi er vant til å se en topp i salg og produksjon før produksjonen settes i gang, vanligvis etterfulgt av en nedgang på samme størrelse de første ukene etter produksjonsstart. Vi har sett fra tidligere prosjekter at denne potensielle nedgangen kan ha stor innvirkning på den daglige driften, med økte lagernivåer og problemer med kundeservice. Nedgangen på 40 % var alarmerende, så jeg dro personlig til kontoret for å undersøke ting på stedet.

Rundt klokken 09.00, da jeg gikk inn på kontoret, traff jeg Pedro, som fortalte meg at de hadde problemer med produksjonsordrer på grunn av mangel på råvarer. Årsaken lå i arbeidet til mottaks- og planleggingsavdelingene: i den første ble innkommende materialer ikke behandlet riktig, og i den andre ble feil lagerdata brukt til prognoser. Det kunne forventes at situasjonen ville forverres ytterligere dersom vi ikke løste problemet umiddelbart. Carlos fra innkjøpsavdelingen var ansvarlig for prosjektets kvitteringsprosess. Dessverre sluttet han på grunn av en storstilt omorganisering som skjedde umiddelbart etter overgangen til SAP-produksjon. Jeg ble forvirret over å høre dette, for bare en måned tidligere hadde Carlos blitt forfremmet til leder for anskaffelser.

Mens jeg drakk kaffen min, forklarte de meg det regionsjef Mr. Da Silva var på fabrikken og tok seg av presserende saker. Det virket ikke riktig for meg. Forlot Da Silva kontoret for å avklare status for produksjonsordrer? Da jeg var der, innså jeg at denne saken ikke handlet om enkle nødsituasjoner eller små problemer. Nøkkelbrukere var ikke på kontoret, lokale personer som var ansvarlige for prosessen jobbet ikke lenger for selskapet, og brukere, som ga etter for panikk, vendte tilbake til papirarbeidsflyten.

Rundt middag var jeg vitne til en telefonsamtale mellom Da Silva og selskapets hovedkvarter. Vår globale nøkkelklient i Detroit klaget over at Manila-anlegget mottok feil, forsinkede leveranser og produksjonslinjen ville stenge om to dager hvis situasjonen ikke ble rettet opp umiddelbart. Jeg kjente et sus av adrenalin. I løpet av de neste timene fikk jeg vite at Da Silva satte fart på et initiativ for å lage en sentralisert tjenesteplattform for våre tre forretningsområder på Filippinene umiddelbart etter at SAP ble publisert. "Nå som det nye systemet er i produktiv modus, vil vi kunne realisere konseptet vårt servicesenter", sa han. "Vi trenger ikke å vente og redusere antall støttepersoner akkurat nå." Flere nyansatte prosesseiere, samt godt trente nøkkelbrukere som jobber med prosjektet, ble sagt opp uten endringer i forretningsprosessene.

Omtrent klokken 15.00 rapporterte jeg observasjonene mine til direktøren min i Hong Kong. Jeg ble overrasket over tonen i min egen stemme: «Waynie, dette selskapet er i ferd med å slutte å operere. Leveranser til kunder skjer nesten tilfeldig, produksjon er i konflikt med planer basert på feil prognoser, materialbevegelser registreres ikke, dokumenter skrives ikke ut, og vi vet ikke engang hvilke bestillinger som ble sendt forrige måned! Hvordan kan vi utstede fakturaer?»

Hvordan kunne alt ha forfalt? Etter seks vellykkede prosjekter der systemet fungerte stabilt og pålitelig, og forretningsprosesser ble utført på et høyt nivå, trodde vi at vi forsto endringene som skjedde i prosesser. Kanskje ligger problemet hos folk?

Ovennevnte er en veldig reell situasjon som skjedde i en stor multinasjonal organisasjon. Av vår erfaring vet vi at dette skjer veldig ofte. I de fleste tilfeller av SAP-implementering (uavhengig av installert versjon), settes systemet i drift med fullstendig fravær eller svært lavt kunnskapsnivå om selve organisasjonen og konsekvensene implementeringen av systemet vil medføre i den. Endringer må gjennomføres i nøyaktig det tempo som ansatte kan oppfatte og forstå dem i. Det er ikke migreringen fra eldre systemer til SAP som forårsaker irritasjon hos personalet, men snarere prosessendringen som kreves for å få disse systemene til å fungere. Mer presist er det prosessintegrasjon.

1.2. Prosessintegrasjon

Effektiviteten til en organisasjon avhenger av relasjonene som bygges mellom prosesser, systemer og mennesker. Derfor, enten vi liker det eller ikke, er implementeringen av SAP ledsaget av aktiviteter i tre tilsynelatende ikke-relaterte aktivitetsområder: programvareutvikling, bedriftsadministrasjon og organisasjonspsykologi. Hvis ett av disse tre elementene blir stående uten tilsyn, vil de to andre ikke kunne erstatte det. Som vist i Ris. 1.1, organisatoriske endringer i SAP-implementeringsprosessen er i skjæringspunktet mellom disse tre komponentene: mennesker, teknologi og prosesser. Implementering av SAP krever ikke bare endringer i systemer (teknologi), men også grunnleggende endringer i arbeidsmetoder (prosesser) og som et resultat tilegnelse av ny kunnskap og ferdigheter, endringer i atferd (ansatte).

Ris. 1.1 Skjæringspunktet mellom tre komponenter

Du vet sikkert at ikke alle SAP-prosjekter er vellykkede, og at avkastningen på investeringen noen ganger ikke er tilstrekkelig. På den annen side er det organisasjoner som har økt lønnsomheten mange ganger takket være implementeringen av SAP. Et rimelig spørsmål dukker opp: "Hva skiller vellykkede organisasjoner fra mislykkede?"

Hvis vi ser nærmere på hva som skiller organisasjoner som har vellykket implementert SAP fra organisasjoner som har implementert SAP uten hell, vil vi se at sistnevnte feilaktig mente å installere programvaren med hensikten med implementering. Selv om enkel implementering støttes av noen endringer i ledelsesaktiviteter, er dette ennå ikke nok til å gjøre SAP-implementering vellykket. Organisasjoner som drar nytte av SAP-implementering drar nytte av nettopp fordi de ser på prosjektet som et grunnleggende gründerinitiativ som forvandler hele bedriften. Selvfølgelig er installasjon av programvare en del av denne prosessen, men bare en liten del. Med andre ord forstår vellykkede organisasjoner at roten til problemet er organisatorisk, ikke teknisk. I de følgende avsnittene vil vi prøve å se nærmere på denne situasjonen.

1.2.1 Prosessfragmentering

Michael Hammer, som først fremmet ideen om omstrukturering av forretningsprosesser, påpeker at hovedårsaken til feil ved implementering av SAP er å ignorere noen av funksjonene i den funksjonelle organisasjonsstrukturen, når hver forretningsfunksjon blir uavhengig og uavhengig, snur inn i en egen "festning". Han kalte denne situasjonen «prosessfragmentering».

Ris. 1.2 Funksjonell organisasjonsstruktur (Hammer, 1998)

Som man kan se av Ris. 1.2, inndelinger i det funksjonelle organisasjonsstruktur skilt fra hverandre. Deres kunnskap om ende-til-ende forretningsprosesser og kundebehov bestemmes av informasjonen som samles opp i deres egne systemer. I en slik organisasjon vil enhver selger gjerne akseptere en ordre fra en kunde, men så snart det gjelder å informere kunden om produksjonsplanen, vil han være maktesløs. Produksjonsdata akkumuleres i produksjonsstyringssystemet. Veggene mellom disse "festningene" vil ikke tillate produksjonssjefen å svare på spørsmålet om når bestillingen vil bli levert. I følge den funksjonelle organisasjonsstrukturen er dette ikke hans jobb. I dette tilfellet vil ikke salgsrepresentanten kunne forklare kunden når han vil få tilbakebetalt den returnerte bestillingen. Denne informasjonen er sikkert beskyttet finanssystemet regnskap.

1.2.2 Konsekvenser av å bruke en funksjonell organisasjonsstruktur

I den funksjonelle organisasjonsstrukturen vist i avsnitt 1.2.1 er livssyklusen til en kundeordre fragmentert av informasjonssystemer som akkumulerer informasjon om den trinn for trinn. På hvert trinn i prosessen funksjonell informasjon Ordren sendes videre til neste avdeling, noe som medfører forsinkelser i behandlingen hver gang. I tillegg oppstår misforståelser og misforståelser på grunn av det faktum at innkommende informasjon ikke alltid tolkes på den måten som er tiltenkt med "funksjonsstyrken" som overfører den (se. Ris. 1.2). Hver avdeling bruker sin egen terminologi og "koder" meldinger i henhold til lovene i sin subkultur.

Overraskende nok er faktorene som mest hindrer en kundesentrisk funksjonell organisasjonsstruktur også hjørnesteinene i lean management, beskrevet som følger:

Kompetanse. Det er trygt å si at våre organisasjoner ikke ville vært i stand til å oppnå suksessene de har oppnådd hvis våre ansatte ikke var kompetente. Imidlertid setter kompetente medarbeidere grenser rundt sine kompetanseområder og begynner å identifisere seg med disse grensene. I stedet for å si «Jeg jobber for ABC Company», sier ansatte: «Jeg kommer fra FoU/Produksjon/Finans/Innkjøp.» Kompetente medarbeidere liker å forbli kompetent. Det er for denne egenskapen de ble ansatt og det er de identifiserer seg med.

Automasjon. Administrasjon og rapportering bør automatiseres i størst mulig grad, og IT-systemer bør støtte virksomheten. Tidligere betydde dette å fokusere tradisjonelle informasjonssystemer på «festninger». Tradisjonelle systemer ble utviklet i henhold til spesifikasjoner mottatt fra kompetente "festnings"-forvaltere. De behandler kun de dataene som er relevante for deres avdelinger og lager kun de rapportene som bekrefter deres kompetanse. Denne tilnærmingen øker fragmenteringen, noe som gjør prosessen ugjennomsiktig, tungvint og ineffektiv.

Belønninger for forbedret ytelse. Rasjonell ledelse hevder at belønninger, insentiver og målesystemer er utformet for å oppmuntre til høye ansattes ytelse. I en funksjonell organisasjonsstruktur måles imidlertid ikke effektivitet ved effektiviteten til hele prosessen, men ved effektivitetsnivået til hver avdeling. Nøkkelindikatorer ytelsesindikatorer (KPIer) som brukes til å belønne profesjonelle prestasjoner (for eksempel for kompetent utvelgelse av personell, redusere avdelingskostnadene med 10%) kan faktisk redusere effektiviteten til hele "ende-til-ende"-prosessen (for eksempel, fra bestilling til betaling).

1.2.3 Hva endres med implementeringen av SAP?

SAP er en integrert programvare som retter seg mot alle festningene i en organisasjon og kobler dem sammen med vanlige data og sømløse grensesnitt. Målet med SAP er ende-til-ende-integrasjon av prosessfragmenter, det være seg regnskaps- og rapporteringsprosessen, syklusen fra anskaffelse til betaling, fra ordre til betaling, eller fra ansettelse til oppsigelse.

Å integrere en fragmentert prosess er en stor rekonstruksjonsutfordring. Prosessen blir transparent fordi transaksjonsutførelse er i forkant av SAP-systemutvikling. SAP tilpasser også den utførte dataflyten til utførelsen av transaksjonen. Dette er veldig viktig poeng, siden på denne måten blir arbeidsmetodene til ansatte radikalt endret, så vel som metodene for å distribuere informasjon og prinsippene for tilgang til den. Mer presist vil du oppleve følgende implementeringsresultater som vil tvinge deg til å revurdere de vanlige måtene å nå målene dine på:

Oppgaver er ikke lenger begrenset til informasjonssystemet til en bestemt avdeling. Ikke bare vil du ha tilgang til data fra andre festninger, du vil også kunne sjekke egnetheten til dataene du legger inn for videre bruk. Dette betyr at du må bedre forstå arbeidet til den ansatte som følger deg på oppgaven.
Organisasjonsgrenser forsvinner ettersom sømløse grensesnitt gir synlighet på tvers av alle organisasjonsfunksjoner. Faktisk forårsaker dette "kultursjokk" blant ansatte, siden all den akkumulerte kunnskapen og forvirringen i andre avdelinger plutselig blir tilgjengelig for dem. Vanlig vertikal kommunikasjon og informasjonsstrømmer elimineres og erstattes i prosessens funksjon med horisontale.
Vanlige ansatte får en viss makt, fordi... få tilgang til et univers av data. Informasjon er makt, så denne omfordelingen er en stor sak, og tar noe av den makten fra ledere og distribuerer den til menigheten. Det er imidlertid ingen vits i å fordele myndighet blant ansatte hvis de ikke holdes ansvarlige for sine handlinger. Rettidig inntasting av korrekte data er kritisk. Så kanskje den største endringen er holdningsskiftet: ansatte går fra å være kontrollerte databehandlere til å bli ansvarlige individer med en dyp forståelse av prosessene for hånden. SAP fungerer kun når ansatte er personlig ansvarlige for informasjonen de legger inn i systemet.
Prosesser blir standardiserte og systemet integrerer deg i strengt definerte arbeidsflyter. Fakturaer betales ikke uten tilsvarende innkjøpsordrer, lagernivåer oppdateres ikke uten korrekt produksjonsordrebekreftelse, og produkter sendes ikke uten fakturaer og materielle problemer. Dette gjør heroiske handlinger («La oss bare gjøre dette og forberede papirene senere») umulig. Dette er et reelt problem dersom det daglige arbeidet består av usystematiske intervensjoner. Standardprosesser påvirker også måten informasjon legges inn på og endrer støttekrav. Siden alle avdelinger må jobbe på samme system med samme data, blir systemtilgjengelighet og responstid mer kritisk enn noen gang før.

1.2.4 Hva er essensen av SAP-implementering: personalledelse

SAP forblir tro mot løftet om å øke effektiviteten til forretningsprosesser. Dette kan endre måten du driver forretning på. SAP-implementering tillater datadeling og øker tverrfunksjonell kommunikasjon. Disse resultatene får du uansett, enten du ønsker det eller ikke, så det er bedre å få kontroll over disse prosessene så raskt som mulig. Når vi implementerer programvare, tar vi hensyn til følgende punkter:

behovsanalyse
konfigurasjon/utvikling
maskinvarekrav og systemytelse
lastplanlegging
datarensing
brukeropplæring
akseptkontroll av utstyr og brukere

Disse faktorene er nødvendige, men ikke tilstrekkelige for vellykket SAP-implementering. Suksessen til SAP-implementering avhenger i stor grad av ledelsen av en ikke-teknisk ressurs - personell. I følge Michael Hammer (2005) er følgende faktorer nøkkelen til suksessen med SAP-implementering:

posisjonere SAP-implementering som et strategisk forretningsproblem
prosjektteam med dedikerte ressurser fra alle avdelinger i organisasjonen
overføring av beslutningsmyndighet til de som er ansvarlige for prosessen (dette punktet må spesielt understrekes, siden det i mange organisasjoner ikke alltid er de som er ansvarlige for prosessen). Disse ansatte må ha det nødvendige autoritetsnivået og være forberedt og forstå sin rolle.
kontinuerlig arbeid på metodisk basis i samsvar med prosjektplanen
bruke systemet til å ta beslutninger raskt og unngå å undersøke problemer på nytt
konsentrasjon av innsats og bevaring av energi
tidsstyring og planlegging fra realistiske og uforanderlige tidsfrister
sikre gjennomføringen av prosjektet gjennom full deltakelse fra selskapet
sikre en balanse mellom innsats innenfor realistiske evner og omfang
programvarekontroll som kombinerer alt det ovennevnte
tar hvert skritt på alvor
non-stop bevegelse langs veien for endringsledelse: menneskelig faktor
ansvar i handling og ledelse.

Merk at ingen av disse kritiske faktorene for suksess er av teknologisk natur. Alt dette er organisatoriske problemer. Derfor er Michael Hammers populære uttalelse sann: "Personalet er det største problemet."

1.2.5 Eksempler på at virksomheter tar prosesser på alvor

endret sine prosesser og strukturer før de implementerte SAP. Du må sørge for at mennesker og strukturer er organisert på en slik måte at de sømløst kan gå over til å arbeide i full integrering med hverandre. Først da kan du begynne å tenke på å øke effektiviteten til organisasjonen din ved å bruke SAP.

Bedrift A: internasjonalt selskap i kjemisk industri

Som en global aktør innen kjemisk industri har dette selskapet en komplett vertikal kjede fra produktproduksjon til salg til publikum. Historisk sett har forretningsvekst ført til fremveksten av mange lokale salgssteder, hver med små produksjonsanlegg og begrenset lagerkapasitet. Hvert av disse punktene hadde en viss uavhengighet, noe som bidro til et høyt nivå av desentralisering. Lokale punkter samlet sine egne praktiske erfaringer, produserte og introduserte sine egne

sine egne data og basert sitt arbeid på dette. Det var i utgangspunktet svært vanskelig å overbevise ansatte om fordelene med standardisering og sentralisering. De organiserte sin verden på en kjent måte og alt fungerte bra: lokale distribusjonssentre med lokal kundestøtte; lokal innkjøpsmyndighet over et stort område; lokal planlegging og gjennomføring av transport; lokal fakturering og lokale delelager for vedlikehold av utstyr.

På grunn av økt konkurranse og redusert fortjeneste på grunn av stigende priser på energi og råvarer, besluttet selskapets ledelse å sette i gang et standardiseringsprosjekt i internasjonal skala. Resultatet ble et integrert SAP-miljø med geografisk inndeling i regioner, som igjen inkluderte mange salgssteder.

Hvert salgssted sentraliserte sine forretningsfunksjoner og begynte å utføre dem under hensyntagen til hele regionen. Hver region fikk et servicesenter for hver av følgende funksjoner:

distribusjon og lager er sentralisert på ett punkt. Lokale varelager eksisterer fortsatt, men alle varelager i én region styres sentralt av ett senter.
På innkjøpssiden ble det etablert godkjenningsarbeidsflyter for hele regionen, og én enkelt hovedkatalog ga bedre innkjøpsbetingelser enn tidligere.
det har dukket opp et enkelt kontaktpunkt for ordrehåndtering og kundeservice.
i tillegg til distribusjon ble transportplanlegging sentralisert.
kontroll over forsyningen av reservedeler ble oppnådd gjennom konsolidering til ett sentrallager som betjener hele regionen.

Bedrift B: Internasjonal bilprodusent

I dette selskapet, som har kontorer over hele verden, ble alle regnskapsprosesser støttet av lokale systemer som først og fremst fokuserte på å støtte lokale lovkrav. I tillegg til dette ble systemene i de fleste tilfeller installert på lokale servere. Dette resulterte i følgende:

fragmentert miljø regnskap
utvikling av regnskapssystemer kun for lokale (juridiske) krav
mangel på standardisert eller felles praksis (regnskapsprinsipper og regler)
sammenslåing på gruppenivå tok for lang tid
fragmentert informasjon
systemfragmentering: enormt beløp grensesnitt til andre lokale systemer (dvs. ordremottakssystemer)

Hele denne situasjonen forårsaket en reduksjon i effektivitet, noe som resulterte i at prosesser tok for lang tid å fullføre. I tillegg begynte den tekniske infrastrukturen å kreve for store kostnader fra selskapet. Selskapets ledelse besluttet å implementere SAP. Følgende resultater ble oppnådd:

mer integrert miljø
globalt regnskapsmiljø
standardiserte arbeidsmetoder, hovedsakelig ved bruk av konsernregnskapssystemer; én global kontoplan
erstattet eldre systemer
optimalisering av informasjonsflyten i organisasjonen, forenkling av foreningsprosessen

I tillegg, ved å introdusere en global struktur, gjorde det nye systemet det mulig å optimaliseren.

Luke Galoppen

Luc Galoppen - administrerende direktør for Reply Management Consulting, konsulentselskap, med spesialisering i organisasjonsendringer. Din erfaring innen organisasjonsendring når du arbeider med SAP-programmer han har samlet gjennom å jobbe innen ulike felt og samhandle med brukermiljøer, samt ulike mens han har utført ulike oppgaver innen ledelse. Kundene deres opererer innen kjemisk, gass og kosmetikkindustri. I tillegg foreleser han om temaet organisasjonsendring og kommunikasjon ved ulike bedrifter og ved flere handelshøyskoler. Mr. Galoppen har en mastergrad i anvendt økonomi fra det katolske universitetet i Leuven og en mastergrad i europeiske industrielle forhold fra Warwick Business School.

Denne spalten publiserer noen kapitler fra boken " Organisatorisk endringsledelse for SAP®-implementering ". Denne boken er oversatt og utgitt av vårt forlag. Du kan kjøpe den ved å klikke på lenken .

Dette notatet er rettet til bedrifter, kunder som begynner å tenke på implementering nytt system, enten det er SAP eller ikke-SAP. Jeg fikk jobbe på kundesiden, på konsulentsiden (ikke bare SAP), noe som gir meg en litt bredere forståelse av problemene på begge sider. Jeg vil også merke meg at problemene, eller la oss kalle dem utfordringer, er de samme for alle land. Jeg kan bedømme ut fra mitt arbeid med prosjekter i USA, Norge, Ungarn og Russland. Utelukkende min erfaring.

Nesten alle kunder erklærer at hovedoppgaven med å implementere systemet er forening av prosesser, dokumentflyt og metodikk. Implementeringen av systemet bør løse problemet med forening, siden det innenfor rammen av prosjektet dukker opp eksterne insentiver i form av konsulenter og et begrenset prosjektbudsjett, når det er nødvendig å raskt endre seg og bli ensformig. Kunden forventer som standard beste praksis fra konsulenten, som ikke eksisterer. La oss være ærlige – beste praksis er hvordan en bedrift allerede har vokst til sin nåværende tilstand. Det er umulig å overføre praksisen til ett selskap til et annet, dette vil ikke være den beste praksisen, men praksisen til det andre selskapet. Men dette er praktisk, siden det lar deg se, eller snarere spionere, på hvordan andre har gjort det. Menneskelig nysgjerrighet, når du ikke kan komme opp med ideer selv, så går du til naboen din for å få ideer og forbedre dem selv.

Innenfor prosjektet er konsulenter avhengige av prosjektets mål og krever virksomhetsforening. Resultatet er en situasjon der en bedrift blir bedt om å slå seg til ro på egenhånd og gi penger til fremmede for det. På et tidspunkt motiverte jeg også meg selv til å gå på treningssenteret - når jeg betalte, så "går jeg." Ensretting i seg selv er heller ikke en veldig klar prosess. Tenke stor virksomhet, hvor det er mange selskaper, ulike funksjoner, ulike ledelseshierarkier. Enkelt eksempel: stor plante for titusenvis av personell og et bittelite selskap med selgere av produkter for eksport. Og alt dette er innenfor ett omfang av prosjektet, hvor det skal være enhetlige prosesser, dokumenter og metoder. For noen vil den minste endring komme tilbake for å hjemsøke oss i antall, midler og effektiviteten ved å stenge perioden, mens andre ikke vil merke det i det hele tatt. Og avskaffelsen av en av bonusene for førstnevnte vil ganske enkelt være en annen type opptjening, mens det for sistnevnte kan begrave motivasjonen til selgere. Fordi forening.

Rapportering, spesielt intern rapportering, er en annen kritikk for begge sider. Virksomheten sier at rapporter er nødvendig, vanligvis i etablerte former, og konsulenter tilbyr "noen merkelige nedlastinger fra systemet i et skjevt format." Det oppstår en konflikt mellom grunnlag og fremskritt, der den etablerte praksisen i en dokumenthåndteringsbedrift vanligvis vinner. Hvis et sertifikat for fysiske volumer skulle ligge på verkstedlederens skrivebord hver morgen, vil ikke noe system hjelpe før sjefen begynner å åpne systemet om morgenen. I Vesten er denne praksisen mindre vanlig når kunden krever generering av papirrapporter. Folk jobber med moderne teknologier lengre og lengre, slik at papirløs dokumentflyt utvikles og prosjekter igangsettes enklere. Dette gjelder selvsagt ikke lovrapportering.

Metodikk er den største mengden arbeid på prosjektet. Jeg skal fortelle deg en hemmelighet at de ofte snakker om behovet for å forene prosesser, men i praksis tar prosesser opp 10 prosent av det faktiske arbeidet med ensretting. Hovedsaken er papirarbeid og beregninger, og dette er ofte knyttet til lovkrav, mens prosessene praktisk talt ikke er lovregulert. Med metodikk mener jeg algoritmer for å beregne bestemte mengder, regler for utfylling av rapporter og utdataskjemaer. Ved inngangen til prosjektet liker kunden å operere med tallene 80/20, 70/30 eller andre spesifikke verdier som måler resultatet av forening. På den ene siden, hvilken forskjell gjør det hvor mange betalingstyper det blir, fordi dette bare er en oppslagsbok? På den annen side er det nødvendig på alle nivåer å forstå hva lønnsfondet er, hva personalkostnader er (dette konseptet er vanligvis bredere enn lønnsfondet). Etter min forståelse har ideell forening en tendens til null, til forenkling til det maksimale nivået som ikke er i strid med loven og forretningsmål.

Innenfor rammen av prosjektet, når det gjelder å forene metodikken, oppstår mange HR-relaterte problemstillinger innen skatteregnskap, bedriftsøkonomi, regnskap og juridisk. Ofte har disse områdene ikke en eneste innehaver som fra sin høyde kan bestemme enhetlighet. Hver avdeling koker i sin egen juice, noe som avsløres under diskusjoner om den samme katalogen over betalingstyper (jeg beklager det banale eksempelet, men dette er det mest såre punktet i alle SAP HCM-prosjekter).

Jeg har sett denne tilnærmingen i vestlig praksis. Det er hoveddelen av lønn - lønn eller tariff. Dens dannelse er etablert i henhold til en enkelt algoritme for alle kategorier av ansatte, uavhengig av regnskapsmetoden og arbeidets art. Alle avdelinger forstår denne grunnleggende delen på samme måte. Motivasjonsdelen (bonuser, godtgjørelser, tilleggsbetalinger) er dannet av flere hovedtyper av periodiseringer, som kalles i generelle ord (for eksempel "Bonus for resultater", "Bonus for kvalitet", "Bonus for arbeidsforhold", etc. .), og det som er inne i disse periodiseringene, overføres til hver avdeling. Dermed har "Resultatbonus" én betydning for selgere, en annen for arbeidere og en tredje for toppledere. Og det spiller ingen rolle hvordan denne verdien beregnes. Fra et personalledelsesperspektiv er dette ett beløp som skal beregnes og oppgis av ansvarlig avdeling. Ingen bryr seg om hvordan denne avdelingen beregner og forvalter denne periodiseringen, siden dette er det direkte ansvaret til lederen for samme avdeling. Denne løsningen passer perfekt inn i konseptet med forening: antall algoritmer innen HR-oppmerksomhet er minimal, motivasjonen til hver gruppe personell bestemmes i området for den tilsvarende virksomheten eller divisjonen, alle har det samme forståelse av fondet, har HR-hodepine en tendens til null, siden funksjonen er desentralisert. Mangel på automatisering? Ikke i det hele tatt. Siden hver avdeling eller virksomhet lever i sitt eget tempo (sitt eget motivasjonssystem, sine egne indikatorer, sin egen arbeidshastighet og evaluering av resultater), er hver avdeling uavhengig opptatt av verktøyene for å effektivt utføre denne funksjonen. For noen er Excel en gang i året nok, mens andre trenger nettbasert integrasjon med produksjonssystemer. Men disse oppgavene faller inn under denne avdelingens ansvar, og den vet bedre enn HR hvordan denne oppgaven skal utføres effektivt.

Handlingsplan for å forberede SAP HCM-implementeringsprosjektet

Pause for å bygge. Denne tilnærmingen brukes ofte i problemer med å bygge integrasjon mellom systemer. Deaktiver ett system og se hva som skjer. Hvis ingenting skjer, er dette systemet eller tilkoblingen ikke nødvendig. I praksis betyr dette systematisk å deaktivere (eliminere) trinn for overføring av rapporter fra en avdeling til en annen, redusere bruken av visse oppslagsverk (betalingstyper, tidsplaner, tidsdata, stamdata). Svært ofte, når et nytt system implementeres, ønsker en virksomhet å overføre alt den har. Men ingen kan si hvorfor. Mange analyser ble implementert av en eller annen grunn for år siden for en spesifikk sak som ikke lenger er relevant, men disse analysene fortsetter fortsatt å bli fylt ut av treghet. Hvilke ledelsesbeslutninger tas i dag basert på denne analysen?

Genereringen av rapporter og dokumenter skyldes ofte at personene som mottar disse dokumentene ikke er utstyrt automatiserte arbeidsstasjoner. Det mest typiske eksemplet er passkontoret og sikkerhetstjenesten. Evige søknader på papir signert av ansvarlig person offisiell. Kanskje vi burde gi dem muligheten til noen ganger å spille kabal på PC? Kostnaden for en automatisert arbeidsstasjon kan være billigere enn papirdokumenthåndtering.

Prosesser. Dette er kanskje det mest populære ordet under implementeringen. Alle ønsker å forenkle og forene prosesser. Ser man på prosessene etter implementeringen av SAP og før, vil det ikke være like mange forskjeller som det var støy rundt. Det er veldig enkelt å forene prosesser uten å være bundet til systemet. Vi tar den enkleste versjonen av prosessen og den mest komplekse (som ovenfor i eksempelet med anlegget og selgere). La oss se på hvordan de skiller seg (med en høy grad av sannsynlighet vil forskjellene være i antall kommunikasjons- og utdataformer), og bringe prosessene til det mest komplekse nivået for alle virksomheter. Og så biter vi av trinnene i henhold til det første prinsippet "pause å bygge." Det er ingen grunn til å bygge vakre diagrammer og dikt - i den virkelige hverdagen ser ingen inn i disse flerbindsbøkene. En enkel tabell i Excel vil hjelpe.

Papirer. Det andre såre emnet etter metodikk. Papirer er alt loven ikke trenger. Ett selskap gjennomførte et eksperiment med fjerning av skrivere. Folk var fysisk ute av stand til å skrive ut dokumenter. Etter seks måneder, antall dokumenter e-post redusert betydelig. I stedet for "Hvor er rapporten?" Spørsmålet begynte å dukke opp: "Hvor kan jeg se?" Jeg mener at det er dokumenter som ikke kan forenes. For eksempel tilleggsavtaler Til arbeidskontrakter. Det er nok å behandle dokumenter for de vanligste sakene og samle og automatisere dem. Ta alt annet utenfor rammen av prosjektet og samlingen, som i en situasjon med bonus for resultater. Med masseutvelgelse og ansettelse i detaljhandelen, blir dokumenter enkelt samlet og automatisert, men hvorfor gjøre dette for industrigiganter?

Mennesker og prosjekt. Dette er det mest sensitive temaet. Enhver leder vet at folk er følsomme for endringer. Selv omorganisering av bordet på kontoret kan betraktes som en krigserklæring, manglende respekt for de beste årene av ens liv viet til bedriften. Når du starter et prosjekt for å implementere et slikt system, og dette er et stort prosjekt, føler hver forretningsdeltaker moralsk at dette er midlertidig og mot ham. Selv prosjektlederen har frykt for at rollen hans slutter etter prosjektet, og at han ikke lenger vil være nødvendig for bedriften. Før du starter et prosjekt, bør folk ha en klar forståelse av hva som vil skje med dem etter at prosjektet er fullført. Ethvert prosjekt er stressende ekstraarbeid, som er forskjellig fra den vanlige. Mange prosjektdeltakere ser på dette som en ekstra belastning som ikke kan kompenseres for på noen måte. Det er verdt å tenke på forhånd om å motivere folk til å jobbe effektivt i prosjektet, og ikke under pisket «ellers sparker vi deg».

Kommunikasjon eller "la oss snakke". Mange ledere ble ledere fordi de begynte eller kunne snakke. Formuler og formidle tankene dine riktig til samtalepartneren din. Når prosjektet starter, glemmer de det. Prosjektet innebærer involvering av flere enn vi er vant til å se til daglig. En ny barriere dukker opp som må overvinnes for å oppnå resultater. Men her er problemet - det er ingen motivasjon. Hvorfor gå og snakke med noen hvis det ikke gir meg noe personlig. Med din leder eller underordnede - du er alltid velkommen, siden insentivene er klare. Og her er helt forskjellige mennesker (både i virksomheten og eksterne konsulenter), resultatene av kommunikasjon med hvem gir ingen motivasjon. Som et resultat ser vi en konstant mangel på informasjon blant alle prosjektdeltakere på alle nivåer. For å redusere potensielle risikoer på grunn av kommunikasjon, må du etablere kommunikasjonsregler før prosjektet. Ikke formelle bestemmelser om hvem, hvor, hvorfor og når, men noe annet. I praksis kan dette være organisering av prosjekttiltak som i en strategisk plan skal lede deltakerne selv til å forstå behovet for å implementere et nytt system. Tidligere hadde bedrifter slike ting som "ratsuhi" - rasjonaliseringsforslag, hvis implementering vil gjøre bedriften eller prosessen bedre på en eller annen måte. Dette er et prosjekttiltak som kan involvere et stort antall mennesker uten å kunngjøre prosjektet, og dermed forberede både teamet og virksomheten på endring.

Det viktigste, fra mitt ståsted, som gjentatte ganger har blitt bemerket i andre artikler, er dette for å formidle målet om implementering så nøyaktig som mulig til det største antallet personer i selskapet.

Det er kjent at leverandørenes markedsføringsuttalelser noen ganger avviker alvorlig fra virkeligheten. Det er imidlertid generelt akseptert at anerkjente markedsaktører ikke tyr til slik praksis. Imidlertid var prosjektlederen for implementeringen av SAP Business One i et lite russisk selskap overbevist fra personlig erfaring om at "ingenting menneskelig er fremmed" for respektable selskaper.

Edge of Survival

For flere år siden begynte nesten alle verdens utviklere av ERP-systemer å bevege seg mot SMB-segmentet, som ble erklært nesten som det mest lovende og prioriterte. Nye produkter ble introdusert på markedet rettet mot små bedrifter med små IT-budsjetter. Det russiske markedet for forretningsapplikasjoner var intet unntak. Overbevisende artikler har dukket opp i den innenlandske pressen som informerer russiske forretningsmenn om at under forhold med økende konkurranse (inkludert tiltredelse til WTO), vil de ikke være i stand til å overleve hvis de ikke har et moderne, automatisert system for administrasjonsregnskap, planlegging og kontroll. Argumentene som ble presentert var ganske overbevisende. Som et resultat tenker ledelsen av mange mellomstore og små bedrifter i Russland seriøst på å bytte til "noe bedre enn Excel og 1C." Vårt firma tilhører også SMB-segmentet, og på grunn av faktorene ovenfor aksepterte tilbudet fra en av partnerne til SAP Corporation om å introdusere et produkt som da var nytt på markedet - SAP Business One (B1).

Som det følger av reklamebrosjyrene, har moderne programvareprodukter som oppfyller allment aksepterte internasjonale standarder endelig blitt tilgjengelig for små bedrifter i Russland. Vi snakket om bred funksjonalitet, rimelig pris og flere måneders implementering. Bare én ting ble holdt taus - at små bedrifter risikerer mye mer når de går inn i spillet om "implementering av bedriftsprogramvare", fordi, til tross for det beskjedne budsjettet sammenlignet med høyprofilerte prosjekter, er investeringer i IT for et lite selskap en betydelig post i sine utgifter. Og fra et forretningsmessig skalasynspunkt kan introduksjonen av en "vakker oversjøisk boks" virkelig sette selskapet på randen av å overleve.

Her er en ny vri

SAP var intet unntak i det globale kappløpet om SMB-bedrifter og annonserte for flere år siden «store endringer i selskapets produktportefølje» og beslutningen om å gjøre en «total vending mot SMB-markedet» og inkluderer bl.a. produktlinje en løsning rettet mot små utviklingsbedrifter. Dessuten ble det annonsert at markedet for SMB-løsninger er en av prioriteringene for SAP. Administrerende direktør, SAP CIS Alexey Shlykov Deretter kommenterte dette trinnet som følger: "SAP anerkjente i tide øyeblikket da det store bedriftsmarkedet, som selskapets forretningsapplikasjoner primært var rettet mot, var nær metning, og det var på tide å se etter de neste salgsmarkedene."

Som et resultat ble det i 2003 lansert en lokalisert versjon av SAP Business One på det russiske markedet – en løsning som var fundamentalt forskjellig fra det SAP hadde gjort før. SAP Business One er imidlertid ikke en utvikling av et tysk selskap: produktet ble kjøpt fra israelske utviklere. Det er merkelig at utgivelsen av SAP Business One ikke ble ledsaget av storskala reklamekampanjer- all salgsfremmende innsats resulterte i flere informasjonsartikler i pressen og en serie regionale seminarer organisert av SAP-partnere for potensielle kunder. Det ble også offisielt kunngjort at kostnadene for én nøkkelferdig arbeidsplass (lisenser pluss implementeringsrådgivning) vil være €2 500–3 000 €, og varigheten av implementeringen vil ikke overstige 8 uker. I tillegg var det kjent at produktet har én betydelig fordel sammenlignet med alternative tilbud - det kan tilpasses, trenger ikke å programmeres, i motsetning til 1C-løsninger, og det inneholder allerede ferdige forretningsprosesser.

Faktisk, under direktesalget av selskapet vårt, ble følgende uttalt: "Om 2 måneder vil vi implementere produktet, og du vil ha et fullverdig regnskapssystem som fungerer." Vi lærte senere av egen erfaring at markedsføringsinformasjonen om produktet ikke samsvarer med dets virkelige essens. Så langt hørtes alt veldig overbevisende ut. Vi ble også imponert over demovideoene av løsningen presentert av partner SAP (et respektert, veletablert selskap i vår region). I tillegg ble det mest overbevisende argumentet fremsatt - "du er under vingen til et pålitelig SAP-merke." Og dette fjernet all vår tvil.

Barsk virkelighet

Etter tre måneders implementering ble det klart at funksjonaliteten til SAP Business One ærlig talt ikke er tilstrekkelig til å drive selv en liten (70 ansatte) virksomhet i Russiske forhold. Hvorfor forsto vi ikke dette tidligere? Det er et vanskelig spørsmål.

Produktet, som vi ble fortalt, er rettet mot SMB-markedet, for ikke å trekke selskaper inn i en lang fase av undersøkelse etterfulgt av en teknisk spesifikasjon med flere volum. Som et resultat, etter stadiet med å teste det konfigurerte produktet, ble vi møtt med en liste over "feil" på mer enn tre ark, og uten å fikse dem var det rett og slett meningsløst å sette systemet i fungerende stand. Noen av dem var spesifikt relatert til feil i produktets drift, mens andre var relatert til problemer med utilstrekkelig funksjonalitet til løsningen. I henhold til listen vi kompilerte, var implementeringsselskapet klar til å "modifisere" omtrent 30% av kravene, men det var umulig å endre resten uten deltakelse fra SAP, fordi produktkoden er stengt. Gjennomføringen av disse "justeringene" som partneren er i stand til å utføre på egen hånd, doblet umiddelbart kostnadene for prosjektet. Dette var motivert av det faktum at "produktet må modifiseres i samsvar med spesifikasjonene til forretningsprosesser." Samtidig var det faktisk nødvendig med forbedringer, men ikke for våre "spesifikke detaljer", men ganske enkelt for å implementere, generelt, en standard forretningsmodell i produktet. Det var ingen uvanlige krav fra vår side.

I tillegg, som det viste seg, er ikke SAP Business One et trelagssystem, men bygget på en klient-server-arkitektur. Samtidig behandles informasjon ikke på serveren, men på klienten, noe som direkte påvirker ytelsen. Forresten, da vi lanserte systemet i testmodus under hensyntagen til maskinvarekravene som er angitt i de offisielle heftene som beskriver SAP Business One-løsningen, ble ikke de deklarerte intil systemet materialisert.

Det er også nødvendig å merke seg flere alvorlige mangler ved SAP Business One, som ikke er åpenbare ved de første presentasjonene, men "dukker opp" bare under prosessen:

semantikken til databasesystemet er praktisk talt ikke beskrevet;
det er praktisk talt ingen lagrede prosedyrer;
systemet er tregt og ressurskrevende;
ingen trykte skjemaer, i samsvar med russiske regnskapsstandarder;
Reservasjonsfunksjonen (for eksempel produkter) er ikke implementert;
anleggsmiddelregnskap er ikke implementert;
regnskapsføring av oppgjør med ansvarlige personer er ikke implementert;
betalingsregnskap er ikke implementert riktig;
det er ingen mulighet for å henføre direkte og indirekte kostnader til produksjonskostnadene;
støtte for et mobillager er ikke implementert, det er umulig å føre varepartier;
muligheten til å administrere batch-ankomster til forskjellige priser er ikke implementert;
MRP fungerer ikke i sammenheng med et lager.

Samtidig beregner SAP Business One beløpsforskjeller kun i nasjonal valuta. Rapporten om beløpsforskjeller er satt sammen basert på gjeldende valutakurs, noe som fører til feilberegning av beløpsforskjeller for betalinger.

De oppførte «manglene» gjør det generelt umulig å gi korrekt informasjon om selskapets virksomhet. Samtidig er det ikke helt klart hvordan SAP Business One i dette tilfellet kan posisjoneres som et regnskapssystem. Detaljhandel, engroshandel og andre raskt voksende virksomheter vil ikke kunne jobbe med dette systemet på grunn av begrensninger i dets produktivitet. Lagring av et dokument med 40-50 posisjoner bringer systemet i stupor. Hvis det er minst 200-300 slike dokumenter om dagen, slutter alt rett og slett å fungere.

Vi ble tilbudt å "optimalisere" forretningsprosessene til selskapet vårt, noe som i hovedsak er en restrukturering av nøkkelpunkter for oss og snarere ser ut som å "klemme" en allerede eksisterende velfungerende virksomhet inn i det rigide rammeverket til en løsning. Dersom vi ikke ønsker å bygge om det eksisterende systemet i vårt selskap, ble vi tilbudt å ferdigstille løsningen. Dessuten snakker vi her om å utvide funksjonaliteten til løsningen og krever programmering ved hjelp av den såkalte SDK (Software Development Kit).

Fra en samtale med det implementerende selskapet fikk vi vite at SAP generelt sett tvinger partnere til selvstendig å finpusse funksjonaliteten og skrive såkalte add-ons (tilleggskomponenter). Disse komponentene kan også fås kommersielt fra andre partnere som allerede har implementert denne funksjonaliteten. For eksempel, for å gjøre rede for transaksjoner med anleggsmidler, må du kjøpe passende tillegg, det samme, hvis vi ønsker å holde styr på faktiske og planlagte kostnader, er en annen separat modul designet for å koble løsningen med banken- klientsystem. I tillegg til at kostnadene for prosjektet øker, er det en side til: hvis vi kjøper et tillegg fra et annet selskap, må vi enten involvere dem i implementeringen for, igjen, ekstra penger, eller vår implementeringspartner vil håndtere det uavhengig, men heller ikke gratis. Faktisk viser det seg å være en slags "pyramide", som vokser jo mer, jo bredere funksjonalitet som kreves av bedriften.

Selge og glemme?

Det er logisk å anta at retting av tekniske og teknologiske mangler skal håndteres direkte av SAP. Her dukket det opp flere interessante punkter i kommunikasjonen med Moskva-kontoret til SAP. La meg nevne at vi betalte for årlig teknisk støtte og hadde rett til i det minste å regne med oppmerksom behandling som klient og rask respons.

Jeg vil si med en gang at ingen av punktene vi nevnte har blitt korrigert. I stedet var det en lang korrespondanse mellom partneren og SAP-tjenestemenn, som partneren til slutt viste oss. De fleste svarene (høflige, men korte svar med en ukes pause) kokte ned til det faktum at de er godt klar over denne eller den "feilen" og jobber aktivt med den, siden vi ikke er de eneste som klager på dette. Nesten alle punktene vi ba om ble angivelig rettet i den nye versjonen av SAP Business One. Som vi har ventet på i ca et og et halvt år.

Som et resultat har vi den oppfatning at de demonstrerte " teknisk støtte"reflekterer leverandørens generelle tilnærming til forretninger med SMB-bedrifter. SAP i Russland er spesifikt fokusert på store kunder, fordi de har muligheten til å investere en ubestemt mengde tid og penger i prosjektet. Men SMB-er kan ikke vente i det uendelige og "mate" SAP-konsulenter hele denne tiden også. I tillegg ser det ut til at SAP bare er interessert i å selge lisenser, etter "hurtigheten" og "innholdet" i svarene på våre forespørsler, og ingenting blir gjort spesifikt angående produktet. Det er også bemerkelsesverdig hvor ofte de ansvarlige for SAP Business One-klienter endrer seg hos SAP. Noen av dem, etter starten av SAP-prosjektet for SMB, byttet veldig raskt fra å løse problemer med å promotere SAP Business One til å skape sine egne karrierer innen SAP, mens den andre delen flyttet til andre selskaper.

Markedsføringsaritmetikk

Utsagnet "SAP Business One er et regnskapssystem" gir SAP-markedsførere en spesiell sjarm. Jeg gjentar, hva slags regnskap kan det være hvis systemet ikke er i stand til å gi sann informasjon om virksomheten til virksomheten? Hvis systemet blir "knirkende trukket inn i virksomheten" av ulykkelige partnere som rett og slett blir tvunget til å tvinge selskapet inn i rammen av denne "løsningen"?

Helt fra starten av lanseringen SAP-produkt Business One ble annonsert på det russiske markedet som en løsning for mellomstore og små bedrifter. Er dette virkelig sant? SAP-selskapet selv annonserte i media kostnadene for 1 nøkkelferdig arbeidsplass (det vil si lisens + implementering) - ca €2,5-€3 tusen I tillegg ble det kunngjort (som en fordel med produktet) at prisen er endelig .

For å virkelig automatisere viktige forretningsprosesser i et lite selskap, for eksempel med en stab på 100-200 personer (økonomi, salg, lager, innkjøp), er det nødvendig å kjøpe rundt 10-15 arbeidsstasjoner. Det vil si at du må regne med et beløp på rundt €30-€45 tusen Som praksis viser, vil eierne av små russiske selskaper som tjener hver krone "med svette og blod" ikke så lett betale 30 tusen euro/dollar for. "programvare". Dessuten er det umulig å opprettholde skatteregnskap og regnskap i systemet, og som et minimum vil "1C: Regnskap" fortsatt være nødvendig. Dessuten, hvis du ser nøye på de allerede annonserte implementeringene, vil du se at fullverdige prosjekter er et sjeldent unntak, og som regel snakker vi om 3-5 lisenser. Konklusjonene tyder på seg selv.

Derfor kan, etter vår erfaring, SAP Business One fungere hvis det ikke er mer enn 10 brukere, i et selskap som ikke har et fullverdig produktlager, og i realiteten kan ikke mer enn 2-3 produktordrer behandles per dag . Spørsmålet oppstår: «Trenges et slikt system for et lite utviklingsselskap til mer enn to tusen euro pr arbeidsplass? Hvorfor, hvis det på dette nivået er nok å bare bruke Excel?"

For det første, ifølge representanter for SAP-partnere, er Business One-utviklere lokalisert i Israel, og det er ikke noe klart produktutviklingsprogram for russisk marked. Mer presist har slik utvikling på global skala av SAP-virksomhet lavest prioritet. Og uansett hvor aktive partnerne er, kan de rett og slett ikke fysisk takle hele denne maskinen og "slå ut" de nødvendige forbedringene av produktet direkte (og Moskva-representantkontoret til SAP, ifølge øyenvitner, er inaktivt). Denne situasjonen er ganske vanlig for bedrifter når et selskap som har gjort seg bemerket, begynner å produsere produkter i en mye lavere priskategori. Ledelsen er allerede på en uoppnåelig kosmisk høyde med "kosmiske tanker" skilt fra virkeligheten.

Hvis vi snakker spesifikt om russisk virkelighet, så er kanskje årsaken at SAP de siste 10 årene har eksistert her under for komfortable forhold? Det er nok å huske selv de offisielle investeringsbeløpene i IT til våre industrielle monstre. Og når det gjaldt faktisk handling, normal utvikling og promotering av et bestemt produkt, kreves det kanskje ferdigheter og kompetanse som ikke var påkrevd før? Og prosjekter har blitt mer transparente og det er ikke lenger like lett å dempe problemer som i storskala implementeringer, der det er for mange interesser involvert til å avsløre skjemmende resultater for publisitet.

Det er klart at målene med å implementere et ERP-system i det store og hele industribedrift er ofte langt fra selve automatiseringen (og dette er også stort spørsmål i hvilken grad slike implementeringer har hatt en positiv innvirkning på russisk industri), men i SMB-segmentet vil ikke denne tilnærmingen fungere. Jeg vil bemerke at forhåndssalget skjer på et høyt faglig nivå, noe som ikke er overraskende, gitt kompetansen til SAP-ansatte og partnere. Men er det etisk å utnytte inkompetansen til russiske ledere og manipulere den på en dyktig måte? Dessuten snakker vi om et produkt som er designet for å "lukke" alle nøkkelspørsmålene i selskapets ledelse. Leverandørens posisjon må her være upåklagelig.

Forresten, i tillegg om denne posisjonen til SAP: ved rundebordet 15. november 2006 ble nye tilnærminger til samarbeid med partnere som jobber med SMB-er offisielt annonsert. SAP sier at produktimplementeringen vil være helt partnerdrevet. Og leverandøren selv "vil gi generell styring og plassering av bestillinger." Vel, posisjonen er ganske logisk, fra synspunktet om å fullstendig fjerne ansvaret for resultatet av prosjektet. Det vil si, på den ene siden, for russiske ledere, når de tar en beslutning om å kjøpe programvare, vil det være et argument om soliditeten til utviklerens merkevare, på den andre siden vil kundene forbli "en-til-en" med partneren sin . Og sistnevnte er på sin side "en mot en" med produktet. Hvis du fortsatt er i tvil om du skal implementere SAP Business One eller ikke, prøv å snakke direkte med eieren av selskapet der denne løsningen angivelig fungerer. Prøv også å spørre SAP Business One-salgssjefen din i det minste noen av spørsmålene i denne artikkelen.

Vladlen Tatarsky