4.12.2019 / Jędrzej Furmann

Tekst jest tłumaczeniem artykułu, który w oryginale napisał Samuli Sikanen.

Oszacowanie właściwej ceny rynkowej dla konfigurowalnych produktów może być trudne. Odpowiednia cena niekoniecznie jest tą samą kwotą, którą na podstawie cennika oraz określonych zniżek wylicza system ERP, CRM albo CPQ. Zamiast tego można ją zdefiniować jako najwyższą cenę, jaką określony klient jest gotowy zapłacić za dany produkt.

Przez lata pomagaliśmy firmom przewidywać, analizować i utrzymywać ceny przy pomocy aplikacji opartych na danych.

Inteligentne narzędzie może pomóc sprzedawcy pracującemu nad złożoną ofertą np. poprzez znalezienie odpowiedzi na następujące pytania:

  • W jakiej cenie sprzedawano wcześniej podobne produkty lub rozwiązania?
  • Jaki jest odpowiedni poziom ceny, biorąc pod uwagę wszystkie właściwości i parametry produktu?
  • Jakie jest prawdopodobieństwo, że klient zaakceptuje ofertę o pewnej ustalonej cenie?
  • Jak szybko produkt zostanie sprzedany po zaproponowanej cenie?

 

Znajdź odpowiednią konfigurację

Punktem wyjściowym ustalania ceny może być przejrzenie historycznych ofert lub zamówień z „odpowiednio wysokim stopniem podobieństwa zawartości”. W przypadku produktów konfigurowalnych, które mają dużą ilość parametrów wpływających na cenę (dziesiątki, setki czy tysiące zmiennych), ręczne szukanie wcześniejszych i wystarczająco podobnych transakcji przekracza ludzkie możliwości. Aby to rozwiązać, stworzyliśmy narzędzie, które pozwala sprzedającemu wyświetlić oraz uszeregować poprzednie transakcje według pożądanego stopnia podobieństwa poszczególnych parametrów. Poszczególne zmienne mogą otrzymać mniejsze lub większe priorytety podczas wyszukiwania.

Oszacuj cenę na podstawie cech produktu

Następnym krokiem jest nauczenie algorytmu uczenia maszynowego (machine learning, często zwane również „sztuczną inteligencją”) wyceny produktów złożonych na podstawie istniejących danych.

Dzięki danym pochodzącym z ofert oraz zakończonych projektów, algorytm uczenia maszynowego może wskazać podobieństwa między cechami produktów oraz zależności cen od atrybutów. Bez programowania wszystkich cech po kolei, algorytm uczy się rzeczy, które człowiekowi zajęłyby lata albo są wręcz dla niego niewykonalne. Dla przykładu – związek między marką samochodu, stanem licznika, rokiem produkcji i ceną da się zauważyć. Dostrzec jednak, jak wpływa na siebie sto różnych opcji w bardziej zaawansowanym projekcie – niemożliwe.

Gdy dane treningowe zawierają również informacje o tym, którzy klienci interesowali się którymi ofertami, model może również nauczyć się segmentować klientów po ich zainteresowaniach, obszarze geograficznym, etc.

 

Zoptymalizuj cenę, marżę i czas realizacji

W różnych sytuacjach sprzedawcy mają różne cele. Wyprzedać szybko cały zapas? Czy może zmaksymalizować marżę kosztem czasu? Cena często jest czynnikiem, przy którym można pójść na kompromis, ale jak bardzo cenę należy dopasować, aby osiągnąć cel i jednocześnie pozostać na racjonalnym poziomie? Przy takich dylematach przyda się wytrenowany model ML. Może on dać wskazówki dotyczące takich kwestii, jak:

  • Jak bardzo prawdopodobne jest, że klient dokona zakupu w danej cenie?
  • Jak dużą zniżkę mogę dać, by uzyskać jak największy wzrost prawdopodobieństwa w stosunku do utraconego zysku?
  • Jaka będzie marża przy danych przewidywanych kosztach produkcji dla tej konkretnej konfiguracji?

Czy masz to, czego potrzebujesz?

Aby rozpocząć korzystanie z rozwiązań dla inteligentnej wyceny, firma powinna upewnić się, że ma niezbędne dane uzyskane w ramach sprzedaży. Jeśli chcesz dowiedzieć się, co optymalizacja ceny może oznaczać w Twoim przypadku lub jak zacząć zbieranie danych bądź tworzenie procesu sprzedaży, skontaktuj się z nami!

Bilot Polska: Mariusz Papiernik, mariusz.papiernik@bilot.pl, +48 690 540 522

Bilot Finland: Mika Laukkanen, mika.laukkanen@bilot.fi, +358 40 845 8432

Bilot Sweden: Mathias Hjelt, mathias.hjelt@bilot.se, +46 70 625 346


18.11.2019 / Arto Pihlaja

Zeszłej wiosny miałem przyjemność uczestniczyć w hackathonie BilotGo.ai, w teamie który wyszedł z zawodów zwycięsko! Chcę podzielić się kilkoma przemyśleniami – co sprawiło, że osiągnęliśmy sukces? Myślę, że te wskazówki mogą być przydatne również przy innych projektach, które opierają się na danych.

1.   Znalezienie odpowiedniego pytania

Wszyscy słyszeliśmy fascynujące przykłady zastosowania sztucznej inteligencji oraz uczenia maszynowego. Te przypadki są często wynikiem długoletniej, zorientowanej na konkretny cel pracy. Przede wszystkim nasz cel musi mierzyć odpowiednio wysoko, nawet gdy praca postępuje etapowo. O wiele łatwiej jest najpierw podjąć decyzję o projekcie pilotażowym i następnie iść do przodu małymi krokami niż starać się o zatwierdzenie projektu, który potrwa wiele lat, kosztuje miliony, a jego wynik jest niepewny. Jest jednak ważne, by każdy krok przynosił rezultaty korzystne dla biznesu.

Nasz zespół z BilotGo.ai razem ze zleceniodawcą poświęcił dużo czasu na zidentyfikowanie i określenie konkretnego wyzwania do rozwiązania z użyciem technik uczenia maszynowego. Musieliśmy postawić problem, na który odpowiedź miałaby istotne znaczenie dla biznesu oraz który można było rozwiązać z pomocą danych, do których mieliśmy dostęp, jak również zmieścić się w wyznaczonym czasie. Nasz pierwszy pomysł polegał na zbudowaniu modelu, który ustala jak karmienie krów wpływa na ilość i jakość dawanego przez nie mleka, ale wraz z postępem prac byliśmy zmuszeni przedefiniować pytanie. Zdecydowaliśmy, że przygotujemy prognozy ilości dawanego mleka przez krowy na podstawie ich wieku i ocielenia, a pozostałe problemy zostawiliśmy innym projektom.

2.    Zebranie danych

Kiedy wiadomo, jaki jest cel projektu, zaczyna się zbieranie danych, które będą potrzebne do wytrenowania modelu uczenia maszynowego dającego rozwiązanie. Oczywiście początkowo może się okazać, że trzeba przedefiniować pytania i szukać informacji na nowo, ponieważ ilość i jakość danych bywa rozbieżna z oczekiwaniami.

W BilotGo.ai podjęliśmy najpierw zadanie przygotowania modelu prognozy na podstawie przykładowych danych. Kiedy minęła połowa czasu na wykonanie projektu, okazało się, że pliki były zbierane ręcznie z pojedynczych źródeł. W rzeczywistości dane miały zupełnie różną strukturę, a najgorsze, że informacje nie były do końca zrozumiałe. Musieliśmy więc cofnąć się do etapu definiowania problemu. Ustaliliśmy też, że po zawodach przygotujemy plan zbierania i przetworzenia danych.

3.   Przygotowanie danych

Mówi się, że projekt uczenia maszynowego w 80% składa się z przygotowania danych i zaledwie w dwudziestu procentach z rozwinięcia modelu ML. Podobnie było i w tym projekcie, gdy doszło do implementacji! Gdyby wziąć pod uwagę etap przygotowań do pracy oraz później do startu, czas spędzony na pisaniu algorytmów był proporcjonalnie krótki.

Główną częścią naszych danych były wyniki pomiarów uzyskane od robotów, więc można było założyć, że były one odpowiednio uformowane i konsekwentne. W praktyce roboty różniły się i wysyłały dane w różnych formach. Poza tym trudno było zinterpretować dane odstające. Przykładowo, jeśli zawartość tłuszczu w mleku według pomiaru wynosiła 30 procent, błąd w wyniku był oczywisty, ale co jeśli wartość wskazywała między 6 a 12 procent? Przygotowanie informacji wymaga dogłębnego zrozumienia ich znaczenia. Z tego powodu intensywnie współpracowaliśmy z klientem.

4.    Przedstawienie

Nawet najlepsza innowacja może spalić na panewce, jeżeli grupa docelowa jej nie zaakceptuje.

Hackathon zakończył się prezentacją przez zespoły swoich rozwiązań przed jury złożonym z zewnętrznych ekspertów. Nasz zespół poświęcił tydzień z łącznego czasu ośmiu tygodni na ulepszenie interfejsu użytkownika oraz przygotowanie końcowego demo na 15 minut. Zastanawialiśmy się nad nośną opowieścią do prezentacji i sprzątaliśmy zawartość, aby podkreślić innowację i jej korzyści. Tak jak powiedział nasz coach, Antti Apunen: „grupa docelowa nie jest zainteresowana algorytmem, którego użyto – oni ufają waszym zdolnościom i chcą zobaczyć rezultat oraz korzyść”.

W świecie biznesu projekt rzadko da się zamknąć w piętnastominutowym wystąpieniu przed jury, ale nawet w innych projektach launch jest często krótki, a zarazem kluczowy – niezależnie czy jest to wewnętrzny system czy web service. Klienci rzadko dają drugą szansę i nie można spodziewać się zbyt dużej pobłażliwości ze strony użytkowników. Korzyść z rozwiązania musi być wyraźnie podkreślona a zastosowanie jak najłatwiej przedstawione. W końcowym etapie projektu należy więc postawić na komunikację zamiast na dopieszczaniu strony technicznej. Jeśli start się powiedzie, zagwarantuje to możliwość dokończenia rozwiązania w kolejnych etapach.

Myślę, że w hackathonie to właśnie przemyślana prezentacja przechyliła szalę zwycięstwa na naszą korzyść i dała nam nagrodę. Wierzę również, że staranne wykończenie zapewnia sukces każdego projektu.

Więcej o idei stojącej za hackathonem BilotGo.ai można przeczytać tutaj.


14.11.2019 / Antti Lyytikäinen

Noniin! Olet lukenut edelliset blogikirjoitukseni ja tullut siihen tulokseen, että tietovarastosi haisee kellarilta ja on ehkä aika tehdä jotain.

Mikäli olet SAP-asiakas, sinua varmastikin askarruttaa mihin SAP:n tietovarastotarjooma on menossa ja mitkä olisivat aikaa kestäviä valintoja esimerkiksi kolmen vuoden aikajänteellä. Suunta vaikuttaa hyvin selvältä – SAP keskittyy isoin satsauksin pilvitarjoomansa kehittämiseen.

Pilviratkaisut tuovatkin niitä tuttuja hyötyjä: nopeutta, joustavampaa hinnoittelua, yksinkertaisuutta ja skaalautuvuutta. Uusimpaan tietovarastotuotteeseen SAP Data Warehouse Cloudiin on luvattu juuri tätä ja ajatuksena tämä tietenkin kutkuttaa, varsinkin kun perinteisesti on-premise-pokerin hinta on ollut jotain aivan muuta kuin nyt luvattu käytettyyn tallennustilaan ja prosessoriaikaan perustuva kuukausihinnoittelu.

Tarkempia hintatietoja varmaan saadaan lähiaikoina, niitä odotellessa voi tutustua SAP Data Warehouse Cloudin ilmaiseen kokeilujaksoon.

Onko tuote sitten valmis itsenäisesti korvaamaan esimerkiksi ikääntyvän SAP Business Warehouse 7.x :n vai tulisiko harkita esimerkiksi SAP BW/4HANA-projektia?

Otin osaa SAP Data Warehouse Cloudin beta-ohjelmaan ja vaikka osa toiminnallisuuksista ei ollut beta-vaiheessa kokeiltavissa, uskoisin että yksinkertaisempiin tarpeisiin pilviratkaisu soveltunee varsin nopeasti. Lisää kokemuksia uudesta tuotteesta sain SAP TechEdissä ja varsinkin mallinnuksen helppous sekä suoraan tietovarastovälineeseen integroitu  SAP Analytics Cloud yhdessä teki vaikutuksen jopa kaltaiseeni vanhaan kyynikkoon.

Spaces-konseptin myötä tietomallinnus on toteutettu siten, että mennään aika paljon lähemmäs visiota itsepalvelu-BI:stä, jossa myös loppukäyttäjät pystyvät yhdistelemään tietoja joustavasti. SAP HANA Cloud -alustalla toimiva SAP Data Warehouse Cloud tuo uutta myös persistenssiin: tietoa voidaan säilöä usean tehoisella ja hintaisella medialla aina muistista data laken kautta hadoopiin asti ja lisäksi ratkaisuissa voidaan käyttää myös virtualisointia, jossa tiedot luetaan lähteestä säilömättä niitä erikseen tietovarastoon. Kaiken kaikkiaan olen pitänyt näkemästäni tähän mennessä.

Tuote on kuitenkin uusi ja ominaisuuksiltaan vielä rajattu ja varmasti juuri tästä syystä SAP tarjoaa lähitulevaisuuteen hybridimallia on-premise-sovellusten ja pilvimaailman välillä. Siirtymävaihe on varmaan arkitodellisuudessakin juuri tätä, eli nykyratkaisua kehitetään ja ylläpidetään ja pilviratkaisua kokeillaan uusiin tarpeisiin ja laajennetaan tarvittaessa. Toisaalta kilpailijoiden ratkaisutkaan eivät ole 100% verrattavissa esimerkiksi ominaisuuksilla kyllästettyyn BW:hen. Yhdellä hyppäyksellä pilvitietovarastoon ei siis ehkä vielä mennä, mutta ajateltavaa riittää, mikäli vanhan uusiminen on kovinkin ajankohtaista.

SAP Data Warehouse Cloudin kehitystahti on uskottavan ripeä – uusia iteraatioita uusine ominaisuuksineen julkaistaan muutaman viikon välein. Samalla vauhdikkaalla metodilla kehitetty SAP Analytics Cloud on melko lyhyessä ajassa kasvanut hyvinkin uskottavaksi tuotteeksi raportoinnin, analyyttisten sovellusten,  visualisoinnin ja suunnittelutoimintojen saralla.  Tämän vahvistaa esim. BARC BI Survey, joka on hyvin mielenkiintoista luettavaa.

Analytics Cloudin ottaminen integroiduksi osaksi lähes jokaisen SAP-pilvituotteen (S/4HANA Cloud, Successfactors, Cloud for Customer jne.) operatiivista analytiikkaa osoittaa myös SAP:n omaa uskoa tuotteeseen. Tästä kertoo myös se, että SAC on jatkossa SAP:n analytiikkatuotestrategian kärjessä, ks. tämä tuore  SAP Analytics & Business Intelligence statement of direction.

SAP Analytics Cloud onkin melko luonteva paikka aloittaa analytiikan pilvisiirtymä huokean hintansa ja tuotteen maturiteetin ansiosta. Seuraava askel voi olla sitten sen tietovaraston seuraaminen perässä.

Blogisarjan muissa osissa:

 


13.11.2019 / Aarni Vanamo

Lähtökohta

Uuden kehittäminen on hauskaa, mutta yhdessä kehittäminen on hauskempaa. Pari viikkoa sitten mietime tiimin kesken toimistolla, että mitä kivaa voisimme tehdä yhdessä. Pienen brainstorm-session jälkeen päädyimme ideaan, kuinka voisimme hyödyntää IoT -antureita tai koneoppimista meidän omassa toimistoympäristössä.

Demon tarkoitus

Halusimme tehdä demon ihan demomerkityksessä, niin itsellemme, kuin myös asiakkaillemme. Nyt kun IoT-pohjaisia ratkaisuja on tehty Bilotilla muutama, niin halusimme myös kokeilla, kuinka nopeasti ja helposti tällainen nousisi. Alkuvaiheessa kuuntelimme pari vinkkiä kokeneemmilta, mutta aika nopeasti demo-tiimimme pääsi ratkaisun kanssa vauhtiin.

Demon aihe ja rajaus

Päädyimme tekemään palvelun, joka erillisten sensoreiden kautta kerää mittaustietoja neuvotteluhuoneiden ilmasta kahden minuutin välein (lämpötila, kosteus, paine), ja näyttää nämä tiedot kätevässä yhteenvetomuodossa jatkuvasti päivittyvän web-applikaation kautta. Toteutettu versio demosta on katsottavissa täältä: Bilot IoT Demo, ensikäynnistyksellä pitää hetkinen odotella datan latautumista.

Tämän tyyppisen ratkaisun kohdalla tietoteknisiä arkkitehtuurivaihtoehtoja ei tarvinnut kauan puntaroida. Tässä tarvitaan jokin komponentti keräämään ja syöttämään dataa, toinen komponentti tallettamaan datat, kolmas palvelu jakelemaan tallennettu data, ja neljäs esittämään tiedot käyttäjälle kätevässä ja miellyttävässä muodossa.

Lähes yhtä nopeasti meille valkeni oikeat teknologiat: sensoreina käytetään suomalaisen Ruuvi -yhtiön IoT-sensoreita, paikallisena tiedonkeruualustana (ns. ”edge device”) käytetään Raspberry Pi -minitietokonetta, palvelimena meillä on Microsoft Azure ja applikaatio toteutetaan Reactilla.

Toteutus

Palvelin

Aloitimme palvelun rakentamisen keskeltä, eli tarvittavista Azure-palveluista. Pienen selvittelyn jälkeen Azuren tarjonnasta valittiin tähän ratkaisuun käytettäväksi:

  • Azure IoT Hub, jonka kautta määritettiin ulkoiset laitteet millä dataa kerättiin, ja joka ottaa ulkoa lähetetyn datan talteen.
  • Azure Stream Analytics, jota käytettiin lukemaan IoT hubin vastaanottamat mittaustiedot ja kirjoittamaan tiedot tietovarastoon sopivassa muodossa
  • Azure SQL Database, mihin mittaustiedot tallennettiin
  • Azure functions jota käytettiin välittämään haluttuja tietoja käyttöliittymään.

Isommassa ratkaisussa tietovarastona pelkkä Azure SQL Database ei ehkä olisi riittävä, mutta tähän käyttöön se kelpasi hyvin. Muista palveluista poiketen se ei ole ilmainen, mutta tässä tapauksessa edullisimmat versiot riittävät hyvin. Kustannus on alle 12 euroa kuukaudessa.

Varsinaiseksi palvelintoteutukseksi jäi siis IoT -hub -palvelun konfigurointi, SQL-tietokannan ja -taulujen perustaminen, Stream Analytics -palvelun ja siihen liittyvän kyselyn konfiguroiminen ja aplikaatiota palvelevan Azure-funktion laatiminen.

Mittausdatan kerääminen

Ruuvi-yhtiön Bluetooth-sensorit olivat lopulta helppo valinta, verrattuna muihin vastaaviin. Laitteiden saatavuus on hyvä, ne ovat edullisia, ja käyttäjäkunta on aktiivista, joten erilaisia foorumi- ja blogipostauksia oli sopivasti tarjolla.

Sensorit käyttäytyvät Bluetooth-majakoina, eli tällaisen lukemiseksi laitteita ei tarvitse erityisesti parittaa. Mittalaitteet vain lähettävät dataa yltympäriinsä, ja jokainen kantavuusalueella oleva Bluetooth-laite voi tätä signaalia kuunnella. Jossakin käyttötapauksessa tämä saattaa olla turhan huoleton käytäntö, mutta ainakaan demon tapauksessa emme tästä olleet murheissamme.

Lisäksi päädyimme käyttämään niin sanottua ”Edge deviceä”. Termille ei ole kovin vakiintunutta suomenkielistä käännöstä, mutta jonkinlainen ”Reunalaite” se on. Kyseessä on tietynlainen silta, internetiin kytketty laite, joka osaa keskustella Azure IoT Hubin kanssa, ja joka osaa kerätä mittaussensorien lähettämät tiedot. Edge devicen tarve on helppo nähdä tässä tilanteessa, jossa mittalaitteet lähettävät tietonsa vain Bluetoothilla, mutta tällainen välilaite on usein hyödyllinen silloinkin, kun mittaussensorit osaisivat itsekin kytkeytyä internetiin.

Meiltä kun sattui löytymään Raspberry Pi 3 valmiina ja sen käyttöön tässä tarkoituksessa löytyi hyvin ohjeita, niin se oli aika luonnollinen valinta tähän tarkoitukseen.

Seuraavaksi piti ohjelmoida Raspberry-tietokone ottamaan vastaan mittausdataa sensoreilta, ja lähettämään tämä data sopivassa muodossa Azure IoT Hub -palvelulle. Tämänkin olisi voinut tehdä monin keinoin, mutta tässä valitsimme pienimmän vastuksen tien, ja teimme Edge Device -ohjelman Pythonilla. Azuren IoT-palvelu olisi tarjonnut tähän hienompiakin konsteja, jotka olisivat mahdollistaneet Edge devicen etähallinnan ja muutakin, mutta demon vaatimustason kannalta nämä olivat tarpeettomia.

Pythoniin meille taas oli tarjolla valmis ruuvitag-sensor -kirjasto, joka tarjosi paljon aihepiiriin liittyvää toiminnallisuutta valmiina. Lisäksi tarjolle paljastui myös DeviceClient.py -kirjasto, joka tarjoaa metodit tietojen lähettämiseksi Azure IoT Hubille. Python-ohjelmalle syötettiin Azure IoT Hubista saadut tunnistetiedot, jotka toimivat tietojenlähetyksessä tunniste- ja pääsynhallintatietoina. Python-ohjelma ottaa kahden minuutin välein sensorien tiedot talteen, ja lähettää ne IoT Hubille.

(Raspberry Pi -koneeseen olisi voinut asentaa myös Windows 10:n IoT -version, mutta tätä emme kokeilleet. Koneen käyttöjärjestelmänä sai toimia oletuksena asentunut Raspbian.)

Mittausdatan tallentaminen palvelimelle

Koska palvelinpään toiminnallisuus oli tehty jo alkuvaiheessa, varsinaisen kerätyn datan tallennus ei vaatinut kuin pienen tarkastuksen. Raspberry Pi -tietokoneen Python ohjelma keräsi ja edelleen lähetti mittaustiedot aivan odotetusti, joten palvelimella lähinnä riitti todeta tilanne ja katsoa miten mittaustietorivejä ilmestyi tietokantaan.

Mittausdatan julkaiseminen

Palvelimen ja applikaation välinen tietoliikenne toteutettiin tämänhetkisen normaalikäytännön mukaisesti REST-palveluna. Azure-palveluun laadittiin ja asennettiin Azure-funktio, joka palauttaa mittaustiedot JSON -sanomana, kahdessa eri muodossa. Toinen muoto tuottaa suoraviivaisen mittausdatan: mikä lämpötila on milläkin hetkellä kussakin huoneessa ollut, toinen muokkaa mittausriveistä koostedataa, eli päivittäiset keskiarvot jokaisesta huoneesta.

Funktio toteutettiin Visual Studio 2019:lla, joka tarjoaa Azure-funktion valmiina projektityyppinä. Tietokantayhteyttä varten emme ottaneet käyttöön Entity Frameworkia, koska ajattelimme näin suoraviivaisen toteutuksen hoituvan nopsemmin suorilla ADO-kyselyillä. Todennäköisesti EF olisi kuitenkin ollut helpompi, mutta menee se näinkin. Palvelinfunktiota varten emme perustaneet CI/CD -putkea, funktio julkaistaan suoraan Visual Studiosta.

Rajapinnan hallinnan tähden otimme käyttöön Azuren API Management -palvelun, jonka kautta funktiota kutsutaan. API Managementilla pystymme rajoittamaan montako rajapintakutsua suostumme aikayksikön sisällä palvelemaan, ja täten kontrolloimaan resurssien käyttöä ja kustannuksia.

Applikaation suunnittelu ja toteutus

Kuten oikeissakin projekteissa, niin ennen kuin käyttäjäpuolen applikaatiota lähdettiin toteuttamaan, niin ensiksi se piti tietenkin suunnitella. Tässä tapauksessa käyttäjätarpeet kerättiin suoraan tiimistä, koska itsellemmehän me tätä pitkälti teimme. Kun post-iteja oli lätkitty tarpeeksi, niin alettiin sitten rakentelemaan designia Adobe XD:llä ja visuaalisia komponentteja Adobe Illustraattorilla.

Koska React on ollut viime aikoina ahkerassa käytössä, niin siihen Reduxin kanssa päädyttiin JavaScript kirjasto/framework vertailussa lähes automaattisesti.

Applikaation ulkoasun rakentamisessa lähdettiin ensiksi hyödyntämään suosittua React käyttöliittymä frameworkia, Material UI:ta, mutta jotenkin se vain tuntui epäkäytännölliseltä ja saikin poistua lähes saman tien perinteisen SCSS lähestymisen tieltä.

Joitain lisäpaketteja asenneltiin sitten vielä tarpeen mukaan:

  • Recharts osoittautui nopeaksi ja käteväksi graafi-työkaluksi
  • API-kutsut hoidettiin Axioksen avulla
  • Päivämäärien ja kellonaikojen esittämisessä hyödynnettiin js:ää

Yhteenveto

Demo valmistui jopa yllättävän sukkelasti. Azure-palveluiden asennus ja konfigurointi vei työaikaa parilta ihmiseltä noin päivän. Edge-laitteen konfigurointi ja ohjelmointi vei päivän sekin, sisältäen yllättäen eteen tulleen tarpeen opiskella Pythonia. Ensimmäisen toimivan version jälkeen molempia kohtia viimeisteltiin vielä jonkin verran, mutta voimme pää pystyssä todeta tällaisen syntyvän muutamassa päivässä.

Eniten aikaa kului applikaation toteutukseen. Tässäkin tapauksessa ensimmäinen versio syntyi parin päivän työllä, mutta suunnittelun iterointi, responsiivisuus ja käytettävyyden yksityiskohtien hiominen toivat muutamia päiviä lisää ja tuovat vielä jatkossakin, kun kerrankin on ratkaisu minkä käyttöliittymä kehityksessä ei ole mitään rajoitteita ja mihin voi palata aina yhä uudelleen, uusien ideoiden kanssa.

Alkuvaiheessa tehdyt arkkitehtuuri- ja teknologiavalinnat osoittautuivat kaikki hyviksi. Muutama pieni tyyliseikka jäi kaihertamaan, Azure-funktiota varten olisi kuitenkin kannattanut tehdä CI/CD -putki, ja olisi sen Entity Frameworkin voinut myös mukaan ottaa. Edge -laitteen Python-sovellus on myös hieman harrastusprojektihenkinen, tuotantokäyttöön tekisimme hieman viimeistellymmän ja vakaamman toteutuksen, mutta ei tämä nykyinenkään ole käynnistyksensä jälkeen mitään ongelmia tai poikkeuksia aiheuttanut.

Kaiken kaikkiaan ”projekti” oli onnistunut kokonaisuus, jossa muutaman ihmisen pienellä panostuksella saatiin hauska kokonaisuus aikaiseksi, opittiin hieman uutta ja luotiin pohja minkä päälle rakentaa lisää.

Jatkoakin on jo suunniteltu. Tarkoituksena olisi seuraavaksi integroida applikaatioon tieto neuvotteluhuoneiden varaustilanteesta, käyttöasteista jne.

Tämä blogi on kirjoitettu yhteistyössä Erkka Puustin kanssa.


13.11.2019 / Antti Lyytikäinen

Miksi valita BW/4HANA?

Ei ainakaan nimen takia. Kirjainlyhenteet, numerot ja kenoviivat samassa pötkössä, herra mun vereni. SAP tunnetaan talona, joka vaihtaa tuotteidensa nimiä, eikä se aina ole hyvästä. Tuoreessa muistissa on esimerkiksi työpöytien ja visuaalisen analytiikan luomisen välineiden SAP Design Studion ja Lumiran niputtaminen Lumira-nimen alle – entuudestaan hyväksi havaittu Design Studio sai tässä iholleen tatuoinnin, jota varmasti katuisi, jos omaisi tietoisuuden. Silti toivon, että nämä kenoviivatuotteet vaihtaisivat nimeään.

Ei nimi kuitenkaan itse tuotetta pahenna, sillä kyseessähän on robustiksi jalostunut tietovarasto-ohjelmisto, luonnollinen lisä SAP-merkkisen toiminnanohjausjärjestelmän kaveriksi. Tällä SAP ERP + Business Warehouse (BW) parivaljakolla useat yritykset ovat pärjäilleet oikein mukavasti pitkään. Moni BW-installaatio alkaa kuitenkin olla elinkaarensa päässä ja hyppy tutusta 7.x -ympäristöstä ”uuteen” BW/4HANAan arveluttaa jo senkin takia, että uusin iteraatio on erikseen lisensoitava tuote.

BW:n käyttöönottoa ja tunnettuutta onkin taatusti jouduttanut se, että sen on saanut aiemmin ikään kuin kylkiäisenä. Kolikon toisella puolella on kuitenkin se fakta, että monissa asioissa kilpailijoitaan parempi tuote ei ole tuottanut itsenäisesti pennin pyörylää toimittajalleen, kehityspanostuksista huolimatta.

Tätä rahareikää on sitten tilkitty erilaisilla lisenssikummajaisilla (OpenHUB-lisenssin tuntenevat kaikki BW-kiemuroissa pitkään painineet) ja rajoituksilla, jotka pääosin liittyvät datan vientiin ulos järjestelmästä. Ilmainen mutta suljettu järjestelmä.

BW/4HANA on datan loppukohteista vähemmän mustasukkainen: dataa saa viedä toisiin järjestelmiin, nimettyjä SAP-käyttäjiä ei tarvita ja analyytiikkavälineet tietovaraston saa valita vapaammin itse. Myös kolmannen osapuolen lähteistä tiedon tuominen sisään on aiempaa joustavampaa. Tämän päivän monitoimittajaympäristöissä nämä ovat käytännössä pakollisia vaatimuksia. Maksullinen mutta avoin järjestelmä.

Teknisesti BW/4HANAssa on paljon samaa kuin viimeisimmissä 7.x -sarjan versioissa. Mallinnus on kuitenkin siirtynyt käytännössä kokonaan SAP GUI:sta Eclipseen, joten kulmakerrointa on jonkin verran myös vanhoille BW-ketuille. Mallinnus itsessään on aiempaa yksinkertaisempaa, koska ”osattavaa” on vähemmän, sillä mallinnusobjektien määrä on tippunut radikaalisti. Napanuora 3.x: n antiikkisiin objekteihin on myös viimein lopullisesti katkaistu.

Ehkä suurin lisäarvo tulee kuitenkin uudistetusta Business Contentista. Business Content tarkoittaa SAP:n toimittamia valmiita malleja, joilla mahdollistetaan nopea tietomallien kehitystyö lähteestä raportille asti. Eli esimerkiksi talouden tai logistiikan osa-aluille on mahdollista aktivoida valmis sisältö, jolla perustarpeet tyydyttävä raportointiratkaisu on helppo toteuttaa. Tämä toki on ollut BW:n etu kilpailijoihin nähden jo vuosikaudet, mutta nyt sisältö on tehty uusiksi uudempia mallinnuskäytäntöjä hyväksikäyttäen. Esimerkkinä tästä on näkymien käyttö fyysisten objektien sijaan, kannan vaatima tila pienenee huomattavasti.

Viimeinen motivaattori voi olla käytännön pakko: 7.x -tuki loppuu joidenkin vuosien kuluttua, vanhan järjestelmän elinkaari voi olla jo turhankin pitkä, tietotarpeet pakottavat viemään tietoa muihin kohteisiin, ylläpito hankalaa, infran uusiminen liian suuri investointi suuren kannan vuoksi, heikko tai turhan monimutkainen toteutus, jossa häärännyt liian monta kokkia ja niin edelleen.

Miksi siis BW/4HANA?

  • Avoimuus
  • Aiempaa joustavampi ja helpompi mallinnus
  • Uusi Business Content
  • Tukea tiedossa 7.x -versioita pidempään
  • On jo korkea aika

Bilot tuntee SAP:n, BW:n, HANA:n ja näiden yhdistelmät sekä vaihtoehtoiset ratkaisut. Vyöllä komeilevat tosielämän toteutukset, joista kerromme mielellämme lisää.

Blogisarjan muissa osissa:


12.11.2019 / Antti Lyytikäinen

Seuraa täysin hypoteettinen skenaario, yhtymäkohdat todelliseen elämään ovat täysin sattumanvaraisia.

Otetaan yksi kappale keskisuuria tai suuria yrityksiä. Laitetaan sinut vastuuseen raportoinnista.

Yrityksen raportointi on rakennettu SAP Business Warehouse -tietovarastoalustalle, se kattaa ehkä ydintarpeet talousraportoinnista, ehkä logistiikkaraportoinnin ja muita osa-alueita. Tärkeä päivittäinen, viikoittainen tai kuukausittainen työväline.

Tietovarasto on rakennettu ERP-projektin jälkitöinä 11 vuotta sitten. Peruspäivitykset on tehty, mutta muuten tietovarastossa alkaa haista jo kellarilta. Tukitoimittaja on vaihtunut kolme kertaa ja se yksi taitava kaveri, joka aikoinaan teki paljon itse, on jo lähtenyt talosta.

Raporttien ajamiseen käytät raportointiportaalia, josta vartin tiimalasin jälkeen saat luvut ruudukkomuodossa selaimeesi. Äh, unohdit kuitenkin täyttää yhteen triviaaliin muuttujavalintaan oikean arvon.

Ajat uutta raporttia toisen vartin.

Tiputat luvut Exceliin ja teet taulukkoon käsin korjauksia, koska tiedät että osa luvuista ei näy uusimman organisaatiorakenteen mukaisesti. Olet korjannut sen käsin jo kahden edellisenkin organisatorisen mullistuksen jälkeen, menee jo rutiinilla.

Mutta hetkinen, kuluvan kuukauden tiedot puuttuvat. Avaat tiketin.

Palvelusopimustason mukaisesti saat iltapäivällä vastauksen, että asiaa tutkitaan.

Seuraavana päivänä tikettiin on ilmestynyt tekninen selvitys aiheesta: tiedot lähdejärjestelmältä lataava prosessiketju on jumittunut koska taulualue on täyttynyt, tulee virhettä ja monitorit ovat ihan punaisella. Tukiorganisaatiolla propellit pyörivät hatuissa niin että savu nousee, pitää soittaa Basis-asiantuntijalle joka työskentelee eri aikavyöhykkeellä, avata palvelupyyntö SAP:lle, tai jotain muuta mukavaa. Kuukausiraportoinnin takaraja alkaa uhkaavasti lähestyä ja tiedot pitäisi vielä visualisoida Powerpointilla johdoportaalle ymmärrettävään muotoon.

Tukipalvelun tarjoaja koittaa ratkaista ongelmaa. Muutaman, erittäin pitkään kestävän, uusintalatauksen jälkeen järjestelmäjumalat ovat suosiolliset ja uusimmat tiedot on ladattu. Huraa, pääsit käyttäjänä pälkähästä! Jupiset kuitenkin, kun kesti taas kauan.

Juurisyy jää kuitenkin epäselväksi, koska tukipalveluoperaattorin pitäisi sitä varten perata satoja rivejä dokumentoimatonta ja kommentoimatonta koodia siirtosääntöjen abap-rutiineista, ratkoa miksi osa ratkaisuista löytyy vain tuotantojärjestelmästä, keksiä miksi käytetään räätälöityä ratkaisua standardin sijaan, ymmärtää miksi tauluista toisiin ladataan tietoja loputtoman tuntuisissa loopeissa, ymmärtää miksi asiakkaan ympäristössä käytetään jatkuvassa tuotantokäytössä objekteja jotka on nimetty ”Do not use!!” ”OLD”, ”ZDELETE, ”, ”obsolete”, miksi käytetään vanhentuneita mallinnustapoja, miksi latausjärjestystä ei datan keskinäisen riippuvuuden takia voi muuttaa ja mitäköhän ihmettä se yksi taitava kaveri, joka on jo lähtenyt talosta, oikein on ajatellut tehdessään kymmenen päällekkäistä DSO-taulua tietomalliin…

No, jos se toimii, niin ei kosketa siihen, eikä tätä nyt voida ainakaan tukipyyntöihin varatulla ratkaisuajalla tehdä, aika ei riitä. Käyttäjäkin sai jo datansa ja tikettijonossa on jo viisi uutta tapausta ratkottavaksi.

Tuen näennäisen kalleuden ja historiallisten uponneiden kustannusten takia kukaan ei uskalla ajatellakaan, että tehtäisiin asiat uudestaan fiksummin. Ehkä uusitaan vain se-ja-se raportointialue nyt ja katsotaan puolen vuoden päästä, kun käyttäjät itsepintaisesti käyttävät sitä vanhaa versiota, kun ovat siihen tottuneet.

Pitkästä elinkaaresta, moneen kertaan vaihtuneista toimittajista, nopeista ratkaisuista, purkkavirityksistä, pitkistä latausajoista, mysteerikoodista, jo lähteneistä taitureista ja päällekkäisistä nimeämiskäytännöistä se iäkkäämpi tietovarasto aika usein koostuu.

Mikäli edellä mainittu soittaa kelloja, olisiko aika auditoida nykyiset ratkaisut ja käytännöt?…

Blogisarjan seuraavissa osissa syynissä:

• BW/4HANA – Tietovarastoinnin työjuhta
• SAP Data Warehouse Cloud – Tietovarasto pilvessä


30.10.2019 / Esa Vanhanen-Varho

A couple weeks ago Sulzer announced their new wireless condition monitoring system, Sulzer Sense. The service connected new hardware devices created by Treon to the existing SAP customer portal. Our team was responsible for designing and creating the backend to Azure. Naturally, when we are dealing with hardware under development, there came moments when we had to be very agile. But Azure as a platform proved once again to be very flexible.

The rest of this story concentrates on the part I know best – Azure. But naturally very big praise goes also to our SAP CX (E-commerce including Hybris that has been renamed lately) and mobile app teams together with analytics experts for making Sense (pun intended) of the raw…or a bit processed data. And thanks also to all the people at Treon and Sulzer – this was a fun journey together!

TL;DR

Below is the architecture which the rest of the blog discusses. And last week at SAP Finug event the team received the best possible praise from the customer: “If you are looking for partner who can handle SAP ERP, Hybris and Azure, Bilot is the natural choice.”

Solution is built on Azure PaaS & Serverless components which can be easily scaled based on usage. Actual compute section (Functions) scales automatically. And what already proved the scalability was the journey of implementing the solution. There is no maintenance overhead of any virtual machines etc. Some scaling options require currently manual operations, but on the other hand, they are related to growing service and easily monitored metrics & alerts. Naturally, this could be automated too, if the system load would be more random.

If you are interested in this kind of solution, we’d be glad to discuss with you here at Bilot.

Azure Architecture - Sulzer Sense

 

Developing architecture

In the beginning there were multiple choices to be made. Devices are not continuously streaming data but sending samples periodically or when an alert threshold is exceeded. Naturally we had a good idea on the number and size of the messages that the devices would be sending, but not actual data at hand.

Our main principle was that the data processing should be as close to real time as possible – even though this was not a direct requirement. Scheduled frequent runs would have been good enough. But then we would have had to think about how to scale the processing power up when more devices and data needs to be processed. So we decided to use serverless Azure Functions for the actual processing and let the platform scale up as needed and have one less thing to worry about.

The devices communicate to Azure through a separate gateway node that is connected to Azure IoT Hub service. In the first phase device provisioning was manual, but that is currently being automated in the second phase. Also, as only the gateways are directly connected to Azure, the number of gateways is not growing as fast as number of devices behind.

Devices send different types of messages, so next step was to separate these with Stream Analytics service. We had decided to use Cosmos DB as a temporary data storage, because that integrates well with Stream Analytics and Azure Functions and gives us a good access to debug the data. We were unsure in the beginning that would we actually need Cosmos DB in the final solution, but this proved to be exactly what was needed…

Surprise!

When we started receiving the data from devices under development, the first thing we noticed (and had misunderstood from the specifications) that the messages are actually fragmented – one whole message can consist of tens of message fragments. This is the reason why I, an old grumpy integration guy, insist on getting real data as early as possible from a real source – to spot those misunderstandings ASAP. But due to the nature of this development project this just wasn’t possible.

The Wirepas Mesh network the devices use has a very small packet size and the gateway just parses and passes all fragments forward. There is also no guarantee that the fragments are even received in order.

This was a bit of a surprise – but finally not a problem. As we had decided to stream all data to Cosmos DB for debugging, we already had a perfect platform to check and query on the received fragments. We could also use out-of-the-box features like Time to Live (TTL) to automatically clean up the data and prevent id overruns. Some test devices sent data much more often than planned, so this gave us a good insight to system loads. Thus we also used a couple of hours to manually optimize Cosmos DB indexing, after which the request unit consumption (read: price of Cosmos DB) dropped about 80 %.

Now that the data was streamed to Cosmos we tied Azure Functions to trigger on each received message – which turned to be every message fragment. What would be the cost implication on this. Well – only minor. First, we optimized the calculation in a way that we start processing only if we detect that we have received last fragment of a data packet for those data streams where only full data is useful. So most of the processing stops there. Actual calculation & storing of the data happens only for full valid packages. When we measured the used time and memory for the operation, we saw that 1 million message fragments would cost about 0,70 € to process – true power of the serverless! So we are basically getting compute power for free, especially when Functions offer quite a lot of free processing each month…

Naturally we had to add scheduled retries for those rare scenarios where packet ordering has changed. There we used Azure Storage Queues to store events we have to recheck later. Retries are processed with scheduled Azure Functions that just retrigger those messages that couldn’t be completed with first try by updating them in Cosmos DB.

In principle, this work could also be moved to IoT Edge as pre-processing there before sending to Azure would lower the message counts on IoT Hub a lot. In this case, hardware development schedule didn’t make it possible to place IoT Edge on gateway devices on the first phase.

Long term storage

Long term storage was another thing we thought a lot. Cosmos DB is not the cheapest option for long term storage, so we looked elsewhere. For scalar data Azure SQL is a natural place. It allows us to simply update data rows even if scalar data fragments arrive with delays (without having to do the same fragmentation check that stream data uses) and also make sure that some rolling id values are converted to be unique for very long term storage.

During development we naturally had to load test the system. We generated a stored procedure to simulate and create a few years worth of this scalar data (a few hundred million lines). Again this proved to be a great reason to use PaaS services. After we saw that our tester would run for a couple of days in our planned database scale, we could move to a lot more powerful database and finish the test data creation in a few hours – and scale back again. So we saved two development days and finished the data creation in one night by investing about 30 euros.

Part of the data is just a sequence of calculated numbers by the devices themselves. These were not suitable for storing in relational database. We could have used Cosmos, but as discussed, the price would have been probably a bit high. Instead, we decided to store this kind of data directly to Blob Storage. Then it was just a question on how to efficiently return the data for the customer requests. And that could be easily solved with creating a time based hierarchy on the blob storage to easily find the requested data. At least so far it works perfectly even without using Azure Search, which is kept as an option for later use, if needed.

Both long term storages can be easily opened up for data analysts and machine learning use cases.

API for users

So far we have discussed only what happened to the incoming data. But how to expose that to the end users then? In this case we had the luxury of already having a customer portal ready, so all we needed to do was to create APIs for the backend to get the data in a secure way. This was accomplished with API Management in front of more Azure Functions. API Management is also used as a proxy when we need to query some data from the portal’s data API to give serverless Functions platform a single outgoing IP address.

All the database queries, blob searches and different calculations, unit and time zone conversions are executed in the serverless platform, so scaling is not an issue. Functions may occasionally suffer from cold starts and have a small delay for those requests, but there is always the Premium Plan to mitigate that – so far there has been no need for this.

We have also planned for the use of Azure Cache for Redis if we need to speed up data requests and see from usage patterns that some data could be prefetched in typical browsing sessions.

Conclusions

What did we learn – at least we once again confirmed that using platform services is very suitable for this kind of work and leaves so much effort to more important things than maintaining infrastructure. It’s just so easy to test and scale your environment, and even partially automated.

Also the importance of tuning Cosmos DB was clear – that couple of hours tuning session was easily worth a few hundred euros per month in saved running costs.

And that the architecture is never perfect. New services appear and you have to choose the tools you use based on one point in time balancing between existing services and if you dare believe that some services come out of preview in time. But the key here is to plan everything in a way that can be easily changed later, if – and when – more efficient service comes available.

(PS. And really, always prioritize getting real data out of the systems you are integrating as early as possible if you can)


16.10.2019 / Nhu Kangasniemi

This article is a follow-up blog from my previous one for authentication with Azure AD in the front-end.

Link to post: https://www.bilot.fi/authentication-with-azure-ad-using-msal-react-app/

 

Src: Microsoft Documentation

 

Above is the process of securing your web app and web APIs using Azure AD. First, you need to register your Web APIs with Azure to make sure that it doesn’t allow anonymous requests. User then logins to authenticate him/herself and requests access token from Azure AD. Azure AD will provision access token for authenticated users, then you write codes to attach token to header before users call any APIs.

In your React app,  create a separate file for calling APIs, then import msalApp from ‘auth-utils’. msalApp is an object instance of UserAgentApplication, which comes with the built-in methods like getAccount() and acquireTokenSilent().  GetAccount() returns the account object, which contains account info, after user successfully login. Check if there is account info, then call acquireTokentSilent to acquire access token from cache or from hidden frames if not available before every call to API. Last but not least, attach the token in your request header.

 

import axios from 'axios'
import { msalApp, GRAPH_REQUESTS } from './auth-utils'
//Call AcquireTokenSilent to acquire token
async function getToken() {
  // grab current state
  const account = await msalApp.getAccount()
  const token =
    account && (await msalApp.acquireTokenSilent(GRAPH_REQUESTS.LOGIN))
  return {
    headers: {
      Authorization: `Bearer ${token.accessToken}`, // the token is a variable which holds the token
    },
  }
}
export const get = async (path, params = {}) => {
  const item = await getToken()
  return axios.get(`${BASE_URL}${path}`, item, params).then(res => res.data)
}
export const getUserInfo = () => {
  return get(`User`)
}

 

For further instruction on how to secure your APIs in Azure using OAuth 2.0 protocol, please follow the link here:

https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad


30.09.2019 / Toni Haapakoski

My past experience from over 20 financial and operational planning projects in Finland has shown that driver-based planning created by different business functions is rarely used to full extent. Most commonly, revenue is recognized from sales volume and sales price. Cost Centre personnel costs are often calculated from headcount and added with automated side costs. These are of course the main contributors to P&L, but it is still lacking connection to activities performed and the capacity required to fulfill the business targets.

Some recognized challenges with budgeting

With the target setting process, I’m referring to the annual budgeting process in which the high-level targets are usually set first. For example, the target for revenue may be + 12 % and for EBIT 10 % in comparison to previous year actuals. After this high level target setting (TOP), the allocation for the organization’s business units and departments budgets will be done (DOWN).

This does not mean that all the business units and departments should have the same targets, but the aggregate total should be.  One reason why budgeting takes such a long time often – even 3 months (Sep-Dec) – is that departments first estimate all their revenue and cost details into P&L, and when rolled up to an aggregate e.g. Business Unit and Enterprise level, the figures don’t match with the set high-level targets. It may also be that high level targets do not yet exist, or they might change and another too-detailed budgeting round will start again.

Another reason is that there is no direct connection from financial targets to business targets – something that an Enterprise, Business Unit and department are trying to achieve. These business targets can be e.g. penetration to new markets, increasing market share, developing and launching new products and services, growing brands, or strengthening partnerships. Businesses should realize what activities and resources are needed in order to achieve the business targets.

Let’s take the above example, where new financial revenue target was set to +12% compared with the previous year actuals. In order to improve sales, some activities e.g. more sales visits have to be done.

With the current customer lead conversion rates, it can be estimated that the number of sales visits has to be increased by 50%. With the current capacity, a.k.a. available salespersons, this cannot be achieved. More salespersons need to be hired, and eventually their salary costs will land to P&L personnel costs.

This is a closed loop scenario, where business drivers (# Sales visits, lead conversion rate-%, # FTEs) determine how the targets can be achieved, how much resources it will require, and how much it will cost.

Another example presented from another angle: If the financial target is to cut e.g. ICT costs by 20% or by 2.000.000€, this will then set the target amount for ICT resources: Headcount (#FTE), personal computers (#PC), office space (#m2) etc. from which the costs are occurring.

Reducing the ICT capacity will finally impact ICT service levels e.g. how many incidents can be solved? Is there onsite support available due to lack of office spaces? This kind of a closed loop planning process brings better understanding compared to pure financial budgeting about what has to be done in order to achieve something and what is the impact on business processes.

With forecasting, the planning process and objective is different

While in budgeting, the focus is on top-down target setting for one fiscal year, forecasting aims to bottom-up predict if the targets can be achieved and also what are the possible future outcomes (e.g. best and worst scenarios) within the next 12-16 months or even in the longer term.

The latter is called scenario planning and it can be fit to a purely financial planning context, but it still requires input from Business Units about their business environment, external drivers impacting on it, and the possible impact on business operations’ internal drivers and financials. Examples of external events that a company has no control on, but which impact business performance: Legislation, taxation, currency exchange and interest rates, loan market, competitors, economic growth, inflation and political crises.

The main purpose of scenario planning is to be able to understand magnitude and direction of changes in the market and to react faster. The closed loop model, where both internal and external key performance drivers have been linked to financials, provides a quick and easy way of getting a holistic view of an enterprise from both business and financials perspectives.

holistic enterprise view

 

Benefits of having driver-based planning in addition to financial planning

  • Easier to understand, explain and plan – more accurate forecasts – better quality and better informed decisions
  • Faster to update when changes in the business environment occur – helps to understand and react to external events
  • Increases the awareness about what drives the revenues and costs – Key Drivers of the Business
  • Enables Scenario and What-If planning
  • Facilitates more collaboration between the functions and organizations and increases the responsibility for and ownership of results