Medzi oznámeniami, ktoré vyšli minulý týždeň zo SAP Teched v Barcelone, bolo blížiace sa vydanie SAP HANA Cloud, kde bola databáza upravená špeciálne pre cloud. Aj keď SAP o tom nespomenul nič konkrétne, myslíme si, že cloudový dizajn HANA by mohol mať obrovský vplyv na to, ako SAP poskytuje svoje podnikové služby SaaS, počnúc S/4HANA.
SAP nedávno urobila jemnú, ale potenciálne významnú zmenu vo svojom slogane a posunula sa od samotného brandingu ako podnikovej digitálnej platformy k platforme obchodných technológií. Irfan Kahn, bývalý technický riaditeľ Sybase, ktorý nedávno preskočil na čelo globálneho predaja a marketingu, trval na tom, že zmena bola skôr o terminológii ako o ceste. Pre nás to však bol skôr posun od vágnych prísľubov digitálnej transformácie k hmatateľnejšiemu dôrazu na matice a skrutky, ktoré vás tam dostanú.
A súčasťou tohto posolstva je racionalizácia portfólia platforiem v cloude, aby boli výhody transformácie uskutočniteľnejšie a hmatateľnejšie.
Titulky, ako uvádza
Andrew Brust a Larry Dignan od Barcelonské podujatie SAP TechEd minulý týždeň zahŕňala všeobecnú dostupnosť Cloud SAP HANA a SAP Data Warehouse Cloud niekedy v 4. štvrťroku s možnosťami vkladania do cloudu DW od spoločnosti SAP Analytics Cloud.Pod týmito titulkami bol veľmi významný vývoj, SAP re-architektoval HANA pre svoju novú spravovanú cloud databázovú službu, aby sa stala tým, čo nazýva „cloud-native“. tým, hovoria o oddelení úložiska od výpočtov a o prevzatí Kubernetes, ktorých kombinácia umožní elasticitu a rýchle spustenie, zastavenie a zmenu veľkosti cloudu služby. A v kombinácii s postupným zavádzaním priebežných licencií, čo zjednoduší tvorbu cien a ponúkne viac ekonomické možnosti prevádzkovania HANA a jej sesterských služieb v cloude, výsledkom by mohlo byť zníženie prekážok adopcia.
V inom príspevku sa budeme venovať ďalšiemu vysielaniu o tom, čo sa myslí pod pojmom „cloud-native“ dátová platforma, keďže tento výraz sa v súčasnosti používa tak široko, že je definícia v očiach diváka. Nateraz to budeme označovať ako dátovú platformu, ktorá využíva elasticitu (používajte a plaťte iba za výpočet, ktorý používate) a horizontálnu mierku cloudu.
Podľa tejto definície je SAP HANA len najnovšou databázou, ktorá využíva cloudovú natívnu architektúru. Napríklad iné platformy ako napr Amazonská Aurora, Microsoft Azure Cosmos DB, a Google Cloud Spanner využívať aj rozsah cloudu. V niektorých prípadoch prinášajú nové prístupy k spracovaniu transakcií ACID, zatiaľ čo v iných umožňujú distribuovanú správu databáz. A zoznam pokračuje. Oracle Exadata v cloude tiež využíva abstrahovanú architektúru úložiska/výpočtov na podporu elasticity.
A ako o tom písal Andrew Cloudera minulý týždeň dokonca aj Hadoop konečne robí podobné oddelenie, ktoré znamená obrat o 180 stupňov od pôvodného predpokladu Hadoopu, ktorým je prinesenie výpočtov do údajov. V cloude je viac nasadenia a rýchlejšie gigabitové backplane cloudu spôsobili, že pôvodný dizajn Hadoop je zastaraný. Doba sa zmenila.
Späť k nášmu hlavnému myšlienkovému pochodu si myslíme, že ako dátový pilier portfólia podnikových aplikácií novej generácie SAP, vrátane S/4HANA a C/4HANA, prestavba HANA pre cloud predstavuje niekoľko jedinečných možností. Mohlo by to zmeniť samotnú architektúru a spôsob, akým prevádzkujeme a platíme za podnikové aplikácie. A mimochodom, pre záznam, SAP tu nie je sám. Oracle čelí podobnej možnosti, pretože jeho aplikácie Fusion SaaS bežia iba na Exadata.
Samozrejme, existuje dobrá otázka, prečo by sme sa tým mali vôbec zaoberať. Nebude transformácia cloudu dostatočne rušivá bez toho, aby ste sa pozreli na zásadnú zmenu v nastavení vášho ERP alebo iných back office systémov? Držte túto myšlienku.
Doteraz bola elasticita spojená s internetovými aplikáciami, ktoré zaznamenávajú výrazné nárasty návštevnosti. Oddelením úložného priestoru od výpočtového systému zákazníci platia iba za výpočtový výkon, ktorý používajú, a keď sa prevádzka mení, môžu upraviť výpočtové výkony smerom nahor alebo nadol, alebo dokonca vypnúť, ak sú v mŕtvom období. Vyhne sa tomu, aby sa musel zapojiť do praxe obstarávania kapacity „pre každý prípad“, ktorá bola bežná on-premise systémy, ktorým chýbal prístup k virtuálnej nekonečnej škále a elastickým schopnostiam cloudu výpočtový.
Naproti tomu tradičné podnikové aplikácie boli vnímané ako monolity. To dávalo zmysel, keď boli ERP systémy murovanými záhradami, ktoré spracovávali údaje zo štyroch stien podniku, pričom objemy spracovania boli relatívne predvídateľné. A ak jednoducho zdvihnete a presuniete svoju podnikovú aplikáciu tak, aby fungovala ako infraštruktúra ako služba (IaaS) v cloude, nič sa nezmení okrem toho, ako za to zaplatíte.
Dnes však podniky zaoberajúce sa B2B aj B2C pravdepodobne budú musieť prijať viackanálové transakcie a interakcie. A niet pochýb o vplyve obchodu v reálnom čase, ktorý poháňajú najmä spotrebitelia na ich mobilných zariadeniach a ktorý má zase vplyv na B2B. Okrem toho, vzhľadom na dnešnú spoločensko-politickú klímu, narušenie dodávateľských reťazcov sa pravdepodobne stane bežnejším ako preťahovanie lanom medzi globalizácia a znárodnenie predstavujú nepredvídateľné prekážky globálnym tokom zásob a racionálnemu rozhodovaniu o tom, kde čerpať a výroba.
Inými slovami, riešenie neistoty globálnych dodávateľských reťazcov si bude vyžadovať, aby podniky súťažili na agilnejšom základe, pričom ich systémy front a back office musia držať krok. Keďže podniky čelia generačnej zmene spôsobenej nielen meniacim sa konkurenčným prostredím, ale aj ich dodávateľmi (SAP verejne oznámili ukončenie vývoja starého systému ECC ERP do roku 2025), nové systémy, ktoré prijmú, musia podporovať novú realitu na zem.
Vzhľadom na takýto prevrat je pravdepodobné, že back office podnikové systémy začnú preberať určitú nestálosť spojenú s čisto digitálnymi obchodnými aplikáciami alebo procesmi. Presnejšie povedané, vzhľadom na obrovské funkčné rozšírenie systému ERP, rôzne moduly alebo procesy budú mať svoje vlastné rytmy, ktoré sa budú len stávať rôznorodejšími. Napríklad správa na konci obdobia mala vždy veľmi odlišné vrcholy a údolia aktivity v porovnaní s plánovaním, spracovaním faktúr, obstarávaním, výrobnými operáciami a dodávateľským reťazcom pohyby. Tieto vrcholy a údolia budú pravdepodobne ešte výraznejšie, keď ich podniky budú ďalej digitalizovať operácie, ako je zabalenie údajov IoT v reálnom čase do údržby, opráv a prevádzky (MRO) procesy.
Dá sa teda povedať, že by podniky nemali mať možnosť na čierny piatok alebo kybernetický pondelok navýšiť viac zdrojov špeciálne pre spracovanie zásob a prevádzku dodávateľského reťazca a potom to isté s plánovaním dopredu po vrcholnej dovolenkovej sezóne prechádza?
Je logické, že ak je základná dátová platforma prepracovaná tak, aby podporovala elasticitu, prečo by nemala byť úroveň aplikácií? Poskytuje spoločnosti SAP (a iným) príležitosť prehodnotiť svoje portfólio podnikových aplikácií SaaS, aby poskytovali schopnosť zvyšovať a znižovať výpočty pre špecifické obchodné procesy alebo moduly.
Pridanie elasticity na aplikačnej úrovni by však vyžadovalo, aby poskytovatelia SaaS preniesli kontajnerizáciu z balíka na úroveň modulov, čo prinesie novú zložitosť. SAP tu v súčasnosti podniká malé kroky. Zákazníci dnes môžu urýchliť nasadenie špecifickej pracovnej záťaže v cloude, ako je skupinové reportovanie alebo centrálne obstarávanie, bez toho, aby museli implementovať kompletný ERP systém.
Teraz prihodíme ďalšie komplikácie. SAP plánuje ponúknuť jadro svojho portfólia – S/4 a C/4 – lokálne, hybridne a v cloude ako riadené alebo nespravované služby; to pridáva ďalšiu výzvu na udržanie konzistentného aplikačného zážitku vo všetkých prostrediach. A pre podniky, ktoré čelia perspektíve generačnej výmeny vo svojich aplikáciách, by pridanie ďalšej úrovne architektonických zmien mohlo spôsobiť urážku zranenia. Potom nezabudnime na toto. Keď sme hovorili o elasticite, zvyčajne išlo o spustenie jedinej aplikácie, funkcie alebo programu, na rozdiel od niečoho zložitejšieho, ako napr. podniková aplikácia, kde môžu existovať zložité vzájomné závislosti medzi rôznymi modulmi, ako je plánovanie zásob, optimalizácia dodávateľského reťazca a výroby. Ak by SAP vyrobil rôzne kusy elastického materiálu S/4, bolo by to prelomové.
Takže nie, nie sú tu jednoduché odpovede.
Napriek tomu, ako je uvedené vyššie, podniky budú musieť prijať agilnosť a ich hlavné obchodné systémy by mali túto agilitu podporovať. Cestovná mapa produktov SAP bude v najbližších rokoch prinútiť zákazníkov, aby urobili niekoľko zásadných rozhodnutí. A hoci títo zákazníci nemusia vykonávať zmeny v statických procesoch s nízkou hodnotou (udržiavať ich v údržbe), pravdepodobne sa obrátia na spoločnosť SAP (alebo iných poskytovateľov riešení), aby zmodernizovali svoje kľúčové tlakové body operácií.
Keďže SAP robí krok k tomu, aby bol cloud z hľadiska nákladov prístupnejší prostredníctvom priebežného platenia ceny, je logické, že by toto myslenie mali preniesť do svojich hlavných podnikových ponúk SaaS. So SAP HANA Cloud robia prvý krok k tomu, aby to bolo mysliteľné.