Megszűnik a PerformancePoint Server


A hír: A Microsoft bejelentette, hogy a PerformancePoint Server, mint önálló termék megszűnik. A PerformancePoint szerver három komponense közül kettő, a haladó elemzések készítését támogató ProClarity és a mutatószámok megjelenítését támogató Scorecard Manager átkerül a SharePoint portál szerverbe, az üzleti tervezőeszköz Planning-et pedig kivezeti a piacról. Idén még lesz egy javítócsomag Planning-hez, de ezután a Microsoft nem invesztál többet a termékbe.

Eddig a hír, a vélemény most következik.

Amikor egy ilyen nagy horderejű eseményről hall az ember, akkor először csak annyit tud mondani, hogy „hoppá".

Aztán elkezd tűnődni azon, hogy vajon sejthető volt-e vagy csak nem vette észre, vagy egyáltalán nem lehetett még sejteni se. Így utólag talán sejthető lett volna, hiszen a Microsoft szokásos éves BI konferenciáján nem hangzott el egyetlen szó sem a PerformancePoint következő verziójáról. Ez azért elgondolkodtató nem? No de azért azt kevesen gondolták, hogy ez lesz a vége.

Aztán jöttek a találgatások. Vajon mi állhat a döntés a hátterében? Vajon mi lesz azokkal akik milliókat invesztáltak eddig a Planning-be akár partner, akár ügyfél oldalon? Vajon ezek után mi lesz a Microsoft BI stratégiája?

Aztán ahogy távolodik az esemény az ember egyre hidegebb fejjel tud a történtekre gondolni és egyre tisztább képet lát az okokról, és arról hogy miért csinálhatta mindezt a Microsoft.

Az első dolog, ami óhatatlanul eszébe jut az embernek, az az, hogy a Microsoftot is elérte a gazdasági válság. Nincs mese, nekik is meg kell húzniuk a nadrágszíjat. Olvastuk, hogy ötezer embert el kell küldeniük. A január 22-i gyorsjelentésben olvastuk, hogy csökkent a nyereségük. Aztán január 23.-án már közlik is, hogy megszűnik a PerformancePoint szerver, mint önálló termék. Itt a gyors válasz a gazdasági környezet változásának hatásaira. A részvényesek megnyugodhatnak.

Csakhogy, ha megnézzük a gyorsjelentést az nem annyira rossz ám. Igaz, hogy a Microsoft üzemi eredménye 8 százalékkal csökkent 2008 utolsó negyedévében, de ha megnézzük a Server and tools üzletág nyereségét, akkor bizony azt láthatjuk, hogy az 29! százalékkal növekedetett az előző év hasonló időszakához képest. Ez azért nem olyan rossz egy ilyen válságos környezetben nem? Persze tudjuk, hogy egy ekkora anyahajónak hatalmas a tehetetlensége és még viszi előre a lendület minek következtében a veszteségek jelentős része majd csak később fog jelentkezni, de azért akkora probléma messze nem látszik kirajzolódni, mint amekkorát lefestenek nekünk. Mert oké, hogy csökken a nyereség, de azért a Microsoft még így is masszívan nyereséges.

Bár sok blogban lehet erről olvasni, mégis úgy gondolom, hogy nem a gazdasági válság volt az, ami a PerformancePoint megszűnéséhez vezetett. A válság csak egy lehetőség volt arra, hogy Microsoft átgondolja, és egy kicsit letisztítsa portfólióját. Ezt most, egy ilyen környezetben fájdalom-mentesebben meg tudta tenni, mint egy konjunkturális szakaszban, ahol valószínűleg nehezebben bocsátották volna meg a döntést azok, akik a PerformancePoint Planning mellett döntöttek. Akár partnerekről, akár ügyfelekről legyen szó. És az sem utolsó szempont, hogy míg most a piac - mármint a részvénypiac - valószínűleg pozitív hírnek veszi a döntést, addig egy konjunkturális periódusban valószínűleg negatív hírként értékelték volna mindezt.

Az igazi okok tehát nem itt vannak. Az igazi ok véleményem szerint az, hogy a Planning sehogy sem illet bele a Microsoft „Üzleti intelligenciát a tömegeknek" stratégiájába. Sem architektúráját, sem felhasználóit tekintve.

A PerformancePoint Planning architektúrája

Azt gondolom, hogy a PerformancePoint Planning kivezetésének egyik legfőbb oka az volt, hogy a termék túlságosan bonyolult architektúrára épült. Mivel erős szavak ezek, hagy magyarázzam meg miért gondolom mindezt. A PerformancePoint Planning nem egy tisztán többdimenziós (OLAP) és nem is egy tisztán relációs tervező eszköz volt, hanem egy hibrid megoldás. Volt, amit a relációs oldalon oldott meg, és volt amit a többdimenziós oldalon számolt röptében.

Ha például a tervet készítő modellező azt akarta, hogy az idei terv legyen egyenlő a tavalyi tény 1,25 szeresével, akkor írt PEL-ben (A Planning modellező nyelve) egy kifejezést, ami nagyjából így nézett ki: Terv = Tény(tavalyi)*1,25. Miután felküldte a tervet a központi adatbázisba, a Planning motorja először megírta az azt a relációs tárolt eljárást, amely allokálja a tavalyi tényt az idei tervbe, majd lefuttatva ezt az eljárást feltöltötte az idei terv elemi szintű számait a relációs táblákba, majd felösszegezve visszatette az OLAP kockába is. Az OLAP adatbázis és a relációs adatbázis tehát mindig szinkronban volt. Ha módosítok valamit a terven, akkor az két helyen is végig kellett vezetnie a Planning-nek. De dönthettem úgy is, hogy a Terv = Tény(tavalyi)*1,25 formulát az OLAP oldalon hagyom, és akkor nem tárol semmit, mindent röptében számol

És ez baj? Nem. Ez az architektúra lehet jó is. Igaz, hogy kell hozzá jó néhány év, amíg kiforrja magát, de ha egyszer üzembiztosan működik, és funkcionálisan teljes körű lesz, akkor értő kezekben igazi kinccsé válhatott volna. A kulcs azonban az „értő kezek"-en van. Ehhez az eszközhöz ugyanis olyan ember kell, aki professzionálisan ért az OLAP-hoz, a relációs adatbázisokhoz és rendelkezik a szükséges üzleti kompetenciával is. De ne szaladjunk ennyire előre. Beszéljünk még egy kicsit az architektúráról.

Az említett nyelv, amiben a modelleket (szabályokat) meg kellett írni egy MDX-hez nagyon hasonló nyelv volt. Az MDX nyelv pedig nem könnyű. Tudom és láttam magamon is, hogy nehezen tudja megtanulni az ember. Namost egy ilyen nehezen tanulható nyelven írt modellt odaadni egy közgazdász felhasználónak, hogy módosítsa, finomítsa vele az elkészített modellt, az kész öngyilkosság. Pláne úgy hogy semmi irodalom nem létezik hozzá. A kifejezetten a Planning - ről írt The rational Guide to Planning with Microsoft Office PerformancePoint Server 2007 című könyv összesen 28(!) oldalon foglalkozott az üzleti tervezéssel. Ez nem sok. És ebbe a 28 oldalba csak két primitívecske modell fért bele.

Aztán itt van még a performancia kérdése. A Planning-re specializálódott SolverUSA tanácsadó cég minimum 3 szerveres (1 SQL, 1 OLAP és egy a Planning szolgáltatásait futtató szerver) architektúrát javasol a Planning futtatásra. Ez árban sem kevés, de komplexitását tekintve sem a legegyszerűbb megoldás.

A PerformancePoint Planning ára

A PerformancePoint server listaára látszólag nagyon kedvező volt a maga 20 ezer dolláros szerver és 200 dollár körüli kliens listaárával. A valóság azonban az, hogy a PerformancePoint működéséhez szükségünk van még egy SQL Szerverre is (ráadásul egy Enterprise változatra, ami hozzáad a költségekhez újabb kb. 25 ezer dollárt. Ha mindezt összeadjuk és kivetítjük, egy magyarországi középvállalatra akkor könnyen kaphatunk listaáron 9 millió forintos szoftverköltséget a szerverre plusz 150 ezer forintot felhasználónként a kliensre (SQL+PPS+Excel 2007). És akkor még bele sem számoltam szoftverköltségekbe azt, hogy ha az eredményeket publikálni akarjuk, akkor bizony már szükséges a SharePoint portál szerver is, ami újabb minimum 1 millióval növeli a szoftverköltségeket. Ez a listaáron cirka 10 milliós belépési költség szintén nem illik az „üzleti intelligenciát a tömegeknek" stratégiába.

Az ár azonban csak egy tényező. Nekünk sok, de a nyugati világban, ahol több tervező munkaállomásra van szükség ezzel az árral igenis lehetett versenyezni. Amiben azonban külföldön is nagy hiány volt, az a vertikális kompetencia

Vertikális kompetencia

A Microsoft évek óta küzd a megfelelő BI kompetencia kialakításával, hiszen jelenlegi partnerhálózatát nehezen tudja alkalmassá tenni üzleti intelligencia rendszerek vagy adattárházak bevezetésére. Egy BI rendszer bevezetése ugyanis vertikális kompetenciát igényel. (Informatikai és közgazdász kompetenciát egyszerre) Namost ennek a vertikális tudásnak a hiánya rendkívül kicsúcsosodhat a Planning bevezetése kapcsán. Egy-egy egyszerű BI rendszert még be lehet vezetni pusztán a forrásadatbázisok ismerete alapján, pusztán józan paraszti ésszel is, de egy üzleti tervezőeszközt már aligha. Ehhez ugyanis ismernünk kell a vállalat üzleti folyamatait, tudnunk kell minek lesz hatása az eredményre, melyek azok a driver adatok, amelyek befolyásolják az eredményt, pontosan meg kell értenünk, hogy hogyan kívánja modellezni az üzleti terület a gazdasági események hatásait, stb. Ez pusztán technikai ismeretekkel lehetetlen. Itt az üzleti igényeken kívül nem nagyon van más támpont. Nem lehet leülni a gép mellé és csinálni „valamit" az üzleti területnek. Vezetőket, kontrollereket kell faggatni, és a kapott válaszokból felépíteni a vállalat tervezési modelljét.

Ezzel a vertikális kompetenciával azonban nem rendelkeznek sem a tömegek, sem az alkalmazásfejlesztésekre specializálódott, főleg technikai kompetenciával rendelkező partnerek.

És még egy dolog: Az értékesítés

A Microsoft doboztermékek értékesítésében jó. Nagyon jó. Amikor a tömegeknek kell eladni valamit, akkor is jó. De valahogy nem találja meg a hangot a tömegen kívüliekkel. Nem tudja megszólítani a pénzügyi-, gazdasági vezetőket, üzleti döntéshozókat. A célzott marketing, a jó kommunikáció pedig különösen fontos lett volna egy olyan termék esetén, amelyik életciklus görbéje kezdeti szakaszán áll. A tervezőeszközök piaca is, de a Corporate Performance Management eszközök piaca is eléggé koncentrált: viszonylag kevés, ám nagyméretű, és érett (értsd legalább 10 éve piacon levő) szereplője van, akikkel versenyezni egy elsőverziós termékkel agresszív marketing nélkül nagyon nehéz.

...

Személy szerint nagyon sajnálom, hogy megszűnik a Planning. Egészen biztos, hogy egy jó ideig nem lesz helyette általános célú tervezőeszköze a Microsoftnak. És ez baj, mert nagyon nagy szükség lenne egy, a középvállalatokra méretezett többdimenziós tervező alkalmazásra. Ehelyett valószínűleg az lesz, hogy a Microsoft leporolja a 2001-ben vásárolt FRx-et, amit odaad a Dynamics-os ügyfeleknek, akik az összesen 4 előredefiniált modell mentén tervezhetik vele költségeiket, bevételeiket, beruházásaikat és humán erőforrásaikat. (Egyébként, ha jól meggondolja, akkor ez az irány teljesen jól illeszkedik az üzleti intelligenciát a tömegeknek stratégiába.)

Másik alternatívaként marad még az Analysis Services. Az Analysis Services-zel is lehet tervezni, ám a jelenlegi architektúra véleményem szerint nem alkalmas bonyolultabb tervezési modellel kiszolgálására. Az is megérne egy cikket, hogy miért nem, de most legyen elég annyi, hogy a Planning fejlesztői sem véletlenül tároltak mindet elemi szinten a relációs adatbázisban és az Analysis Services helyett sem véletlenül maga a Planning osztotta szét a tervszámokat. Hiába volt meg a ProClarity-ben és az Analysis Services-ben is a képesség a tervezésre, a PerformancePoint fejlesztői mégsem ezt az utat választották.

ProClarity és Scorecard Manager

És végül essen még néhány szó a másik a PerformancePoint másik két komponenséről, a Scorecard menedzserről és a ProClarity-ről. Ezek a termékek nem szűnnek meg csak PerformancePoint Services néven átkerülnek a SharePointba. Idézem: „Based on customer feedback, we are moving the scorecard, dashboard, and analytic functionality from Microsoft Office PerformancePoint Server into Office SharePoint Server Enterprise, making these capabilities available throughout the organization at a lower TCO" Azaz az ügyfeleink visszajelzései alapján úgy döntöttünk, hogy áttesszük a ProClarity-t és a Scorecard Managert PerformancePoint szerverbe, hogy így alacsonyabb legyen a szoftver teljes birtoklási költsége. Lehet, hogy tényleg ez áll a döntés mögött, de ha most megkérném, hogy tegye fel az az olvasó a kezét, aki azt akarja, hogy ezek a termékek épüljenek be a SharePoint szerverbe, akkor szerintem senki sem jelentkezne.

A döntés hátterében inkább az állhat, hogy a Microsoft ugyanolyan platformot akar teremteni a SharePoint-tal a webes alkalmazások piacán mint amilyen platformot kialakított az asztali pc-k piacán a Windows-zal. Ennek mi standard BI és adattárház kultúrán nevelkedett tanácsadók nem örülünk, de maximálisan egyetértek Johan Pellicaan-nal azzal kapcsolatban, hogy mint minden éremnek, ennek a változásnak is két oldala van. Az egyik az, hogy az Enterpirse SharePoint felhasználók ingyen megkapják majd a Microsoft BI eszközkészletének kliens oldalát, így egyre többen fognak mindenféle kiértékelés nélkül áttérni a Microsoft BI platformjára. Ha figyelembe vesszük, hogy az Enterprise SharePoint felhasználóinak száma 30-40 millió között mozog, akkor ez nem kis húzóerőt jelenthet majd a Microsoft üzleti intelligencia platformjának. Ezt támasztja alá az az elemzés is, amit Nigel Pendse publikált tavaly, a BI Survey 7-ben. Eszerint a Microsoft OLAP-ot és az SAP BW választók fele nem vizsgálja meg a konkurens BI termékeket, hanem mindenféle kiválasztási eljárás nélkül dönt az adott technológia mellett. Ebből kiindulva akár lehet pozitív hatása is a Scorecard Manager átkerülésének a Sharepoint-ba.

Az érem másik oldalán pedig ott állunk mi, akik a BI és adattárház oldalról jövünk, és akik nem használnak SharePoint-ot. Nekünk sajnos egyre inkább tudomásul kell vennünk, hogy SharePoint nélkül nincs Microsoft üzleti intelligencia. Ha használni akarjuk a Microsoft BI-t, akkor vennünk kell/telepítenünk kell SharePoint-ot is. Pont.

Most még az SQL Server programcsomag része a Reporting Services, de ha a jelenlegi változásokat figyelembe vesszük, akkor már nem is értjük, hogy mit keres még itt az SQL szerver programcsomagban. Tisztán látszik, hogy a Reporting Service-nek is hamarosan át kerülnie a SharePoint Portal szerverbe, a többi üzleti intelligencia kliens komponens közé

A vékony kliensek mennek a SharePoint-ba. De mi lesz a vastag kliensekkel?

Annak idején eléggé felforgatta a BI front-end piacot a Microsoft azzal, hogy felvásárolta a ProClarity-t. Sajnáltam is azokat, akik Analysis Servives-hez front-end fejlesztésbe kezdtek, hiszen a Microsoft saját partnerei esélyeit rontotta ezzel a lépéssel. Korábban azt hangoztatták, hogy mi csak a szervert adjuk a front-endek fejlesztését partnereinkre bízzuk. Jó sokan rárepültek ekkor a témára - köztük mi is még a 90-es évek végén. Nekünk szerencsénk volt, mert nem volt annyi pénzünk a marketingre, hogy kinőjünk a garázstermékből. De a Panorama például, aki a ProClarity talán legnagyobb versenytársa volt, csúnyán megégethette magát. Szerintem dollármilliókat költött marketingre egy olyan piacon, ahol hasonló kaliberű cégekkel versenyzett. A ProClarity felvásárlása után azonban a Microsoft is belépett erre piacra, és innentől kezdve az erőviszonyok nagyon felborultak. Ettől a pillanattól kezdve ugyanis a Microsofttal kellett versenyeznie a Panoramanak és más BI front-end gyártóknak. Jó néhányan be is dobták a törölközőt.

Most már azonban elég erős a sansz arra, hogy a ProClarity Desktop-ot is utoléri a vég. A hivatalos közleményből ugyanis kitűnik, hogy egyre több ProClarity funkciót fognak átültetni az Excel és a SharePoint következő verzióiba és ez szerintem azt jelenti, hogy a Microsoftnak egyetlen vastag kliense lesz: ez pedig az Excel.

Legyen így. Megmondom őszintén, hogy tényleg nagyon örülnék, ha a ProClarity elemzést támogató funkciói átkerülnének az Excel-be. Ezzel kaphatnánk egy olyan BI front-endet, ami mindentvivő lenne a piacon. És itt most nem a Microsoft front-endek piacára gondolok, hanem a magára a BI piacra, ahol az IBM, ORACLE, SAS, ... versenyzik. Egy ilyen front-enddel ugyanis könnyebben lehetne érvelni az üzleti(!) döntéshozóknak.

Zárszó

A Microsoft az elmúlt 2 évben iszonyatosan felkavarta az üzleti intelligencia piacot azzal, hogy új, integrált(!) CPM megoldást dobott piacra, és véleményem szerint a tavalyi, soha nem látott mértékű felvásárlási lázat is elsősorban ez fűtötte. Emlékezzen vissza: az SAP felvásárolta a Business Objects-et, majd az ORACLE megvette a Hyperiont, hogy legyen neki is professzionális tervező eszköze. Aztán a Cognos is megvette az Applix TM1-et, mert neki nem volt memória alapú tervezőeszköze, majd az IBM kisgömböc módjára bekebelezte mindkettőt. Egy pillanat alatt végbement az üzleti intelligencia piac konszolidációja és sokáig úgy tűnt, hogy hosszútávon ez a négy cég fogja uralni a piacot.

Aztán jött a Microsoft és a mostani bejelentéssel azt mondta, hogy én leszállok erről a vonatról és másfelé megyek. De hogy pontosan merre, azt még nem árulta el...

Elválasztó

Már készül a következő cikk. Kérjen értesítést a megjelenéséről itt.

|

Kővári Attila
2009. január 28.
Címkék:

2 Hozzászólás

Nekem ez nagzon hasznos

Nekem ez nagzon hasznos volt, meg akkor is ha 20 honappal a poszt keletkezese utan olvastam. Erdekelne mi tortent azota.

Mi történ a PerformancePoint kivezetése óta?

Szia Péter,

Köszönöm a hozzászólást!

Nézzük mi történt a PerformancePoint kivezetése után 20 hónappal. Kezdjük a Performance management eszközökkel (Scorecard manager, ProClarity)

Az elmúlt 20 hónapban megtörtént ezen eszközök integrálása a SharePoint Portal szerverbe. Történtek fejlesztések ezen a téren is, de inkább csak régi sérelmeket orvosoltak és tiszta erővel az integrációra koncentráltak. Ezen a területen tehát az elmúlt 20 hónap a SharePoint integrációról szólt.

Planning

A performancePoint másik ágán, a tervezési oldalon viszont minden leállt. Tavaly nyáron megjelent egy sajtóközlemény arról, hogy a SharePoint Enterprise licensszel rendelkező ügyfelek megkaphatják a Planning forráskódját, de itt vége a történetnek. (Erről Financial Planning Accelerator címszó alatt találsz több infót a weben) . Frx? Megmondom őszintén előtte sem, és azóta sem hallottam róla.

Ami érdekes és elgondolkodtató lehet tervezési kérdésben, az a Microsoft új, Excel mögé bújtatott memória alapú adatbáziskezelője. (PowerPivot) A PowerPivot jelenleg még eléggé read-only módon működik, de az a tény, hogy többtízmillió sorral is megbirkózik, és az hogy van saját kalkulációs motorja, eléggé arra hajtja a vizet, hogy előbb utóbb kiforrja magát egy memória alapú tervező eszközzé. Vagy ha azzá nem is, de legalább egy jó modellező eszközzé. (Tervezem, hogy kitesztelem a PowerPivotot ilyen szemüvegen keresztül is, és ha ez megtörtént, megírom itt a BI projekt blogon)

Üdv, Attila