U SAPu více než kde jinde platí, že není ani tak důležitý ten program, jako spíše tým, který ho implementuje. V ČR to na přelomu století byla docela tragédie, většinou jste koupili SAP a implementaci dodávala firma typu "Patočka, syn a šikovný bratranec". Implementace se táhla, nic nefungovalo, všechno se řešilo nějak divně a složitě. Pak jste vyrazili na referenční návštěvu do Německa a tam to fungovalo. Po pár hodinách u tamního zákazníka vám došlo, že to není o tom, že "SAP to neumí", ale o tom, že "Patočka to neumí". Software, kde každá věc jde udělat deseti způsoby. Ale pokud pro tu první věc použijete způsob A, tak na tu druhou se vám počet možností omezí na osm. A pak tu máme ty věci tři, čtyři až tisíc. Vyznat se v tom, co lze použít s čím a co se naopak najednou použít nesmí, to je na roky studia. "Vy u položek nenastavuje exspiraci? Pak nemůžete použít FEFO. Optimalizace skladby zásilky? Není problém, ale je nutné zapnout FEFO."
Osobně mám SAP rád. Pracoval jsem pro konkurenční firmu a bývalí zákaznící SAPu byli vděční a pokorní. Prakticky vždy byl ten příběh stejný: "ztratili jsme dva roky marnou snahou implementovat SAP. Už nemáme čas ani peníze a potřebujeme rychle něco, co alespoň trochu funguje."
Každopádně když se vám podařilo na implementaci sehnat firmu, co to uměla, a tým lidí, co už to dělali, tak SAP dával výborné výsledky. V ČR jste na takové firmy také narazili, ale zjistili jste, že drtivá většina z nich měla jen "rollout" z nějaké jiné zahraniční pobočky. Protože v Německu nebo Holandsku to uměli. Nejhůře dopadaly firmy, které se snažily si to naimplementovat vlastními silami. Jak se situace za posledních deset let změnila už nevím.
Je to možný, nevím, jak to chodí v ČR. Jednalo se o zahraniční firmy, imlplementovali to nějací zahraniční experti...
[ironie]Každopádně UX je naprosto super. To byla taková krása, když třeba na řádku v tabulce dal člověk tečku místo čárky nebo naopak, ono to při ukládání vyběhlo s chybou v úplně jiným poli, který bylo OK a zablokovalo UI, dokud to člověk nenašel a neopravil... Pak potvrdit tlačítkem pod tabulkou (hot keys nevedeme), pak kliknout v nástrojové liště, pak zase tlačítko dole...[/ironie] Kam se hrabe metro.
Také by mne zajímalo co jsou „hotkeys“ pokud se pamatuji, tak klávesové zkratky SAP měl už v době kdy jsem s ním začínal asi 16 let nazpět, ale byly kompletně odlišné od toho co se používalo na Windowsech.
Co se UI týče, tak docela zaspali. Stále používají SAP Gui, co je ve Windows založeno na ActiveX a OLE2 technologiích (i nejnovější verze 7.40) a spoustu věcí uděláte jen pod Windowsy, což je v dnešní době dost omezující.
Sice se pomalu ale jistě začínají odrážet „od dna“ a tak alespoň jejich WWW rozhraní konečně začíná stavět na něčem „standardním“ a to OpenUI5 (můžete navrhnout, že jsou lepší knihovny a modernější, ale po bastlech typu BSP a WebDynpro jsme o století blíže přítomnosti). Hlavně alespoň některé věci budou multiplatformní a ne IE/Firefox only (v Chrome/Safari například správa Solmana funguje dost divně).
Ale abych jen nehaněl, třeba to co zmiňujete: „To byla taková krása, když třeba na řádku v tabulce dal člověk tečku místo čárky nebo naopak, ono to při ukládání vyběhlo s chybou v úplně jiným poli, který bylo OK a zablokovalo UI, dokud to člověk nenašel a neopravil...“
Je pro uživatele oser a dost záleží, jak se k tomu programátor postaví (lze to udělat elegantněji, ale člověk si musí pohrát), ale tenhle UX byl na svou dobu dost geniální, protože programátor nemusel moc řešit prvky a místo aby se věnoval práci s GUI, jenom ladil aplikaci. To, že to tak funguje prakticky dodnes, je tak trochu ostuda a je to krásný příklad toho, jak to dopadá, když firma usne na vavřínech...
Nerozumim. Zazil jsem nekolik implementaci SAP. Problem nikdy nebyl v IT, tj. konzultacni firma to vzdy dokazala implementovat, aby nebyly napr. vykonnostni problemy. Problem ale pokazde byl, ze se lide zevnitr te firmy nedokazali dohodnout, co a jak ma fungovat (chybejici, nepresna nebo primo chybna specifikace).
S tím se jako programátor (pro jiný ERP) setkávám často. Nejen při původní implementaci, ale i následně v zadání. Lidi nedovedou pořádně vyjádřit co chtějí a jak to chtějí (nejčastější problém je "Ale já myslel že když chci A a B, napadne vás že k tomu budu chtít i C, D a E."). Často to podchytí konzultant, ale občas to prostě uhodnout nejde.
To asi funguje napříč odvětvími, ale nejvíce mne baví to, že když tedy konzultant navrhne nějakou rozumnou cestu, tak se vyrojí tuna „věcí“ proč to zrovna tak nejde... Je to těžký... Chceme systém, ale nechceme upravovat svoje procesy, byť je občas dělají dost zvláštně (třeba Indická společnost a inventura, která probíhala tak, že se vzaly stavy skladů k poslednímu dni a přelily se do dalšího roku a pak se divili, že jim materiály přebývají nebo na skladě prostě nejsou) a takhle bych mohl pokračovat :-/
U patnácté implementace se to zlomí. Jakmile máte 10+ referenčních zákazníků, tak je to rázem jiný styl práce. Vezmete nového zákazníka na několik referenčních návštěv. A rázem se bavíte v rovině "chceme výrobu jak to měli v TOSu, údržbu jak v UE a expedici jak u Pla*ka".
První implementaci JDE E1 jsme dělali před pěti lety. Trvala dva roky a byla to katastrofa. Dnes šel do ostrého provozu šestý závod a jde to hladce. Zabral nám jen šest měsíců. Ještě nás čekají tři. Zkušenosti a možnost podívat se, jak to používají jinde, je prostě obrovský rozdíl.
I když ještě nemáte takové zkušenosti a takové portfolio, tak se dá implementace zvládnout dobře. Jen se holt nevyplatí začít "sběrem požadavků". Mnohem lepších výsledků dosáhnete, když začnete tím, že jim tam nainstalujete "vanilla" verzi a vyškolíte je na základy ovládání. Teprve pak se s nimi bavte o požadavcích a maximum jim rovnou ukazujte. Ve chvíli, kdy uživatelé něco vidí, tak je rázem diskuse mnohem produktivnější. Dokud jen sedíte v zasedačce, malujete na flipchart a donekonečna přepisujete zápis z jednání, tak je produktivita mizerná. Byli jsme schopni utopit přes 80 hodin v diskusi o plánování výroby polotovarů. V průměru 8 lidí na každém meetingu, celkem 640 člověkohodin ztraceného času. Pak jsme je vzali k jinému zákazníkovi. Následoval meeting, kde nám řekli "chceme to tak jak oni, ale forecast jen jednou mesíčně, stav skladu denně a chceme v reportu vidět i varování, že je něco zpožděné". Zadání sepsáno a podepsáno za dvě hodiny.
No a se SAPem je problém v tom, že nic jako "vanilla" verzi nemá. Takže tam to chce zkušenosti z desítek projektů a referenční návštěvy. 15 let zpátky takové portfolio v ČR mělo jen minimum firem implementujících SAP.
Jo, implementace jsou zábavné.
Ve firmě to dostanou na starosti "klíčoví" zaměstnanci daného oddělení - tedy např. hlavní účetní, která o konceptu fungování SW / databází nemá a ani nechce mít žádné tušení (oblíbená věta: "chci to podle zákona". Nebo "minulý program to uměl sám, nevím, co chcete.");
konzultant - člověk s prezentačními schopnostmi, který má o účetnictví matnou představu ze školy, něco málo ze školení a hlavně prakticky žádnou praktickou zkušenost s procesy z reálného provozu firmy v daném oboru;
programátor - jedinec, že má z těch podivně definovaných požadavků od předchozích dvou něco programovat.
IMHO je nejdůležitější ta první osoba - pokud firma nemá někoho vlastního s dostatečným mezioborovým přehledem a znalostmi, tak je implementace marná snaha. Zaměstnavatelé externích spolupracovníků chtějí poslat fakturu, je jim v podstatě jedno, zda to bude nebo nebude fungovat. (Důvody, proč to nefunguje, se najdou vždy.)
Důležitý je celý řetězec. Toho konzultanta bych nezavrhoval, je styčným důstojníkem mezi zákazníkem (kde by měl nastudovat procesy) a programátorem (kterému může "selsky" vyjádřené požadavky přeložit do konkrétnějšího "chci aby ta a ta funkce brala ty a ty data a dělala s nima to a to". Programátor pak nemusí luštit co že to vlastně klient chce. (což je pochopitelně ideální případ)
Typicka implemantace (cehokoli) vypada tak, ze si sedne managor s obchodakem. Managor zvasta tuny plku o tom, jak jeho firma potrebuje to ci ono, aniz by vzivote videl, co firma vlastne aktualne pouziva. Bezne se stava, ze poptavany produkt davno ma. Obchodak prozmenu slibuje, ze nic neni problem, a vsechno bude zitra, nepozdejs vcera ...
Pak se sejde ITk s implementatorem, a cumej na sebe jak dve telata, protoze ani jeden z nich nechape, co se po nich vlastne chce aby delali. Kdyz ty hovadiny nejak spolecnejma silama dekryptujou, tak dojdou k zaveru, ze to je tak na pristich 10 let prace, ale podle harmonogramu na to maj 3 nedele ...
Ti tzv "klicovi" zamestnanci jsou prevazne vsemozni sefove oddeleni, ktery prevazne netusej, co jejich podrizeni delaj, natoz proc a jak.
Ostatne ... http://projectcartoon.com/cartoon/2
... videl sem in natura, jak kompletne otestovany (cca rok testovaciho provozu) system prestal po 2 hodinach spusteni naostro fungovat a to tak ze uplne. Proste se to totalne slozilo ... at zije SAP. S nicim jinym sem neco takovyho nikdy nevidel.
Druhej zazitek s touhle firmou je registrace jedhoho z jejich softu ... 3 ITci koumali TYDEN, jak to udelat ... = jak vypacit z jejich webu SN. V asi 10 ruznych manualech meli popsanych minimalne 20 rucnyzh postupu ... a spravne nebyl ani jedinej.
nechapem, to museli byt nejaki jelimani, "vypacenie" SN je tak na 5 klikov
ad "zlozenie SAPu" - opat, ked to niekto zle nakonfiguruje, najlepsie asi taki "odbornici" co pacili SN, tak sa zlozi akykolvek system
prave SAP je v tomto maximalne transparentny, vsetky profily su v textakoch na filesysteme, ziadne skryte binarne blbosti ako inde
Mno profily bych do toho netahal. Jedna věc je nastavení a druhá je kernel. Tak nějak jsem pochopil, že to fungovalo, dokud to nenasadili produktivně, takže maximálně nebyly parametry optimalizované (ale třeba se pletu, vařím z vody).
Jak jsem psal, zajímalo by mne proč jim to zhučelo. Pasivně jsem sledoval, kdy se složila hlavní instance, která se starala o load balancing a to tak, že umřela, ale když se pak pátralo co a jak, tak se zjistilo, že před tím, než umřela, tak nakopala zálohy a nakonec to řešil i SAP, takže ne vždy to musí být chyba adminů a uvědomme si, že každý SW píše jen člověk. Na druhou stranu, pokud třeba poddimenzovali server, tak se ani nedivím, že to umřelo, když se tam všichni přihlásili, ačkoliv se to nezdá, SAP si docela vezme a nepřijde mi, že by nějak hospodárně pracoval s přidělenými prostředky :-/
ale ved jasne, posledne som tiez riesil preco sa nam jeden system polozil do par hodin vzdy ked sa na neho naraz prihlasilo 500 userov, proste isty externy konultant jaksi pozabudol ze po upgrade na nw 7.40 ja jaksi trochu zmeneny memory model a nechal vsetko pri starom, samozrejme ze sa system do par hodin polozil ked mu dosla extended global memory
a neboj, tiez mam uz na pazbe par zarezov kedy odpoved od supportu bola "it's a new bug, thank you for your notice, we will soon create a new OSS note with correctiion" :)
jj, vis o tom howno, hlavne ze zvanis ... ten sap confili lidi od SAPu ... pro takovou pidifirmu jako je CEZ.
Jinak se muzes klidne predvist ynteligente ... https://support.sap.com/home.html a ne, ta ikona request key nefunguje.
Já jsem v bývalé práci nasazení SAPu zažil a nedopadlo to úplně nejhůř. Sice se v celém podniku vtipkovalo a místo PR sloganu "<jméno firmy> najede na SAP" se říkalo "<jméno firmy> dojede na SAP", firma to ale přežila. Skončila až o mnoho let pozděj z úplně jiných důvodů (koupila ji a zrušila konkurence).
https://www.youtube.com/watch?v=nYli9aHqhFI
Scheisse Auf Plate
Sorry About Production
Software Aus Pakistan
System against people
Schreibs auf Papier
Suffer after Purchase
https://chistesinformaticos.wordpress.com/2008/10/12/funny-facts-sap-employees-about-sap-software/
a mnoho dalsich...
Žádné takové nemohu najít. Kde je?
Velice výjimečně hlásím chybu. Vzhledem k tomu, že ani teď, když jsem byl upozorněn, tlačítko nevidím, pochybuji, že až si za 5 let zase všimnu chyby, budu si pamatovat, že mám první hledat tlačítko. Tedy v mém případě lze buď chybu ignorovat, nebo ji poslat do komentáře. Čímž nechci říct, že vím, jak lépe to řešit. Jen vysvětluji, že je pro mě momentálně prakticky nemožné zmiňované tlačítko použít.
V roce 96 se do místního SAPu Praha navezlo asi 6 unixovýxh serverů IBM. Zadarmo a s vééélkým prosíkem, že občas můžou zákazníkům říci, že to taky jede na HW IBM (Oracle jako databáze. Na IBM DB2 SAP taky jel, ale v čr nevím o jediné implementaci). Takže myslímže tato firma nikdy neměla problém se železem.
Sap prave jede kdovikde. SAP for finance nam bezi na mainframech. Trh v CR az na par pripadu jako schade wagen,tsechische stromgeselshaft, tsechische reichkasse neni zajimavy. Neb i takovy CEZ neni co se tyce ceskeho imperia nijak pro ne zajimava firma.
skutečnost je ale taková, že největší procento velkých společností světa v posledním desetiletí jednoudše „jede“ na SAPu
Velké společnosti světa obecně dělají ze setrvačnosti a/nebo bezdůvodně spoustu nesmyslných věcí. Prostě nějakou dobu tam trvá než se přijde na to, že to je na nic, jen to přidělává starosti a stojí to neskutečné peníze.
Ta statistika je trošku zavádějící. Byť správná. SAP je v jedné věci nejlepší a nemá v ní konkurenci. Tím je finanční reporting. Pokud jste velká nadnárodní korporace, kde potřebujete vykazovat úplně všechno a ještě několika způsoby (pro americké úřady, britské úřady, pro indické úřady, pro české úřady atd.), tak SAP je to nejlepší řešení. A proto ho tolik velkých firem má. Ale u mnoha to také financemi končí.
Pokud jste výrobní firma, tak je lepší místo SAPu použít něco jiného (nevím jak teď ale kdysi býval dobrý například Baan). Pokud máte jadernou elektrárnu, opravujete auta nebo děláte údržbu letadel, tak opět sáhněte po nečem jiném (tam býval lepší IFS). Pokud potřebujete správu majetku, plánování údržby atd., tak opět jsou lepší věci než SAP. Jste stavební moloch, který má mraky projektů a potřebujete sledovat každý hřebík? Opět jsou lepší věci než SAP.
Potřebujete tohle všechno dohromady? Pak máte v zásadě dvě možnosti. Zaprvé použijete SAP. Nic z toho (kromě financí) neumí nijak zvlášť slavně, ale umí to všechno. Zadruhé použijete více systémů, každý na to, na co je dobrý. Například Oracle applications na výrobu a IFS applications na údržbu. No a SAP na finanční vykazování. A takhle SAP získává další zářezy na pažbě. Plno firem ho skutečně používá, ale ne na všechno. Ovšem oficiálně se to prezentuje jako "firma XY používá SAP". V jiném letáku se zase uvede, že používá Baan, v jiném že Oracle, atd.
Takže se v jedné zprávě dočtete, že americká armáda zvolila IFS Applications pro údržbu. A v jiné se dozvíte, že zvolili Oracle Applications pro správu majetku. Tak co zvolili? Oboje. Schválně se podívejte na ty největší firmy, co mají SAP. A zeptejte se, zda to používají na všechno. V drtivé většině případů bude odpověď "probůh jasně že ne!"
otazka je ci riesenia "SAP ako centrum pre financie, na ostatne veci ine", v skutocnosti nevyjde ovela drahsie prave pre vytratenie synergickeho efektu all-in-one... pretoze casto je prepojenie a hlavne udrzba prepojeni a hlavne master-dat medzi tymi systemami peklo na zemi...
ale tak, zase aspon mame pracu, ze? :)
tak tak. Pracuji v megapodniku, kde, jak píšete, jedou na všem možnym, SAP nevyjímaje... Kdyby jen SAP, fuzovali s Italama a Nemcema a sice se privohnuli procesy, ale ponechali dosavadni implementace. To je moje prvni pracoviste za 10 let, kde je fakt vsechno, a to 5x. V DB poolu sedi lide od Oraclu, MS SQL, DB2, Teradaty a jini. Na storage se pouziva 3 reseni EMC, pak IBM TSM, a spousta platform dependent udelatek (privohnuty RMAN a pod.). Na evidenci software ma kazde oddeleni vlastni nastroj a pak nekolik nadrazenych "spolecnych" . Komedie...
Musím se vzpovídat:
po 2 pokusech najit lepsi IS nez stavajici ( DIALOG f Altnet )
byl přijat nový ředitel iT, s tím že to protlačí.
bohužel K2.
na finance asi OK
ale kdyžmuseli doprogramovávat výrobu
( aniž s ni měli víc zkušeností )
večer před ostrým startem:
- kde je prosím tato položka ?
- tady v tom políčku
- a jak ji system vypocitava ? to je minimalni vyrobni davaka. S tou se plánuje.
- co to ? polozku jsme naimportovali. ale nepocita se. Stejne je to vzdycky na jeden kus
odhlasovani vyroby:
- když svou práci do systemu odhlasovali > 2 dělníci,
celý nejnovejsi server šel do kopru ( tedy nepouzitekbe pomale )
musela se kvuli tomu upravovat jejich pracovni doba.
kusovniky:
- proc je rozpad kusovniku tak pomaly ?
( 4 procesorovy server, m$ sql )
muj rozpad, ve FANDU, na bezdiskove 386, je 10x rychlejsi ?
- no ja tady pri programovani pouzivam testovaci data ( asi 50 polozek, 2 urovne )
customizace:
mnoho veci museli upravovat / dodelavat
po roce, nova verze K2
jen tak diffuji program, co museli customizovat,
s tím co je ve std. verzi:
- vidím tady několik oprav, které v naší verzi nejsou !?
- no dyk. Dopoirucujeme pouzivat standardni verze.
custom verze neudrzujeme
s novou verzi K2 buď budou, nebo nebudoufungovat.
dal jsem výpověď ( po 15ti letech )
Heh, kolega resil jak budou v K2 delat tu babisovo ptakovinu s DPH, protoze do pole pro (dodavatelsky) cislo faktury prej nejde dat nic jinyho nez cisla ... takze kdyz jim zakos posle fakturu s pismenama, sou v <>. A kdyz sem videl postup na tisk faktury, tak sem premejslel z kteryho ustavu choromyslnych tvurce utek.
Internet Info Root.cz (www.root.cz)
Informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2021 Internet Info, s.r.o. Všechna práva vyhrazena.