Integraatioiden merkitys talouden suunnitteluvälineessä

Uutta suunnittelujärjestelmää budjetointiin, rullaavaan ennustamiseen tai muuhun suunnittelutarpeeseen hankittaessa on asiakkaalla mielessä joukko erilaisia ominaisuuksia ja toiminnallisia vaatimuksia, jotka uuden järjestelmän toivotaan mahdollistavan. Tänä päivänä tarjontaa markkinoilla riittää ja useimmiten toimittajien tuote-esittelyissä korostuu loppukäyttäjän käyttöliittymän esittely – miltä ohjelmisto näyttää ja millaista ”silmäkarkkia” kukin toimittaja pystyy käyttöliittymään työntämään.

Pieneen osaan näissä tuote-esittelyissä jää kuvaukset tuotteen kyvykkyydestä integroitua erilaisiin lähde- ja kohdejärjestelmiin. Tämä ei ole se eniten seksiä tihkuva osa-alue nykyisessä datan visualisointihuumassa, mutta tämä on kyvykkyys, joka erottelee järjestelmät toisistaan. Jos järjestelmään halutaan syöttää budjetit, niin mihin siinä sitten integraatioita tarvitaan? Vastaus on, että todella moneen asiaan. Huonosti integroituva suunnittelujärjestelmä on todennäköisesti myös  huono liiketoiminnan suunnittelujärjestelmä, jonka käyttö rajoittuu ainoastaan budjettien ja ennusteiden keräämisen. Suunnitteluratkaisun integraatiovälineen avulla voidaan lisäksi toteuttaa paljon ylläpidollisia toimia, jotka muussa tapauksessa olisi tehtävä manuaalisesti. Muistettava on myös, että liiketoiminnan suunnittelujärjestelmässä data liikkuu molempiin suuntiin: järjestelmään ladataan pohjatietoja ja valmiit suunnitelmat voidaan viedä esimerkiksi toiminnanohjausjärjestelmään. Datan liikuttelun lisäksi suunnittelujärjestelmän integraatiovälineen tulee kyetä tekemään myös laskentaa ja tälle tulee käyttöä esimerkiksi kustannusten allokointimalleja rakennettaessa. Jos työkalusta löytyy tällaista kyvykkyyttä, ei sen hyödyntäminen rajoitu pelkästään suunnitteluun, vaan sille löytyy paljon käyttökohteita myös toteumaraportoinnin puolelta.

Integraatiovälineen merkitys suunnitteluratkaisun ominaisuuksien joukossa korostuu erityisesti pilvi-/SaaS-ratkaisuissa. Nämä ratkaisut ovat erillään asiakkaan omasta IT-infrasta ja pahimmillaan huonot integraatio-ominaisuudet tarjoava ratkaisu tarkoittaa paluuta manuaaliseen tekstitiedostojen liikutteluun palvelimelta toiselle.

Edustamassamme Jedox-ratkaisussa on varmuudella yksi markkinoiden paras integroituvuus erilaisiin lähde- ja kohdejärjestelmiin. Jedox pystyy lukemaan dataa relaatiotietokannoista, xml-tiedostoista, tekstitiedostoista, web-serviceistä, Salesforcesta, QlikView:n QVX-tiedosta, Tableausta ja niin edelleen. Mikäli valmista connectoria ei ole, on sen toteuttaminen räätälöidysti mahdollista. Näin menettelimme muun muassa yhden asiakkaamme kohdalla, joka haluasi ladata Jedoxiin kirjanpidon toteumatiedot pilvipohjaisesti Netvisor-kirjanpitoratkaisusta. Netvisor-liittymän toteutus räätälöitynäkään ei ollut kuin kahden päivän työ.

Jedoxin tietolähdevaihtoehdot

 

Tässä muutama esimerkki Jedoxin integraatiovälineen käyttökohteista:

  • Toteumatietojen lataus suunnittelujärjestelmään
  • Tilikartan, kustannuspaikkojen ja muiden laskentatunnisteiden/dimensioiden automaattinen lataus ja päivitys esimerkiksi tietovarastosta tai master data management -työkalusta.
  • Valuuttakurssien automaattinen päivitys Euroopan keskuspankin palvelusta.
  • Myynnin pipeline datan nouto Salesforcesta myynnin ennusteen pohjaksi.
  • Suunnitelmien versioiminen.
  • Tuotekohtaisen myyntiennusteen vieminen SAP:iin. Jedoxista löytyy myös erillinen SAP Connector SAP integraatioiden toteutukseen.

Jedoxin integraatiovälineen hyödyntäminen ei rajoitu pelkästään Jedoxin tarpeisiin. Sillä voidaan ladata dataa lukuisista lähteistä, tehdä dataan siivous- ja muokkaustoimenpiteitä ja lopuksi myös kirjoittaa data takaisin Jedoxin omien kuutioiden lisäksi esimerkiksi relaatiotietokantaan, tekstitiedostoon, xml-tiedostoon, JSON-tiedostoon, Qlikin QVX-tiedostoon tai Tableaun TDE-tiedostoon. Kyseessä on siis ihan täysiverinen ja teknologia-agnostinen ETL-työkalu, johon pääse loppu- ja pääkäyttäjät kiinni selaimella mistä tahansa. Unohtamatta, että sillä voi laatia myös budjetin.

Jedox ETL:n kohdevaihtoehdot

 

 

 

 



Johdon laskentatoimen suhde ulkoiseen laskentaan

Yrityksen laskentatoimi tuottaa lukuja eri tarkoituksiin. Klassinen kahtiajako laskentatoimen tehtävistä tehdään ulkoisen ja sisäisen eli johdon laskentatoimen välille. Ulkoinen laskenta (Financial Accounting) tähtää lakisääteisen tilinpäätöksen tuottamiseen, kun johdon laskenta (Management Accounting) palvelee nimensä mukaisesti yrityksen johtamista.

Asiakkaiden tarpeet ulkoisen ja johdon laskennan suhteen ovat hyvin erilaiset, ja niiden tekniset toteuttamistavat poikkeavat usein toisistaan. Heikosti johdettuna toiminnot voivat eriytyä yrityksen sisällä omiin lokeroihinsa ja antaa hyvin erilaisen kuvan yrityksen taloudellisesta suorituskyvystä. Tämä ero täytyy pystyä luotettavasti selittämään. Eron selvittäminen voi pahimmillaan olla tehotonta ja aikaa vievää, mikäli raportoinnin perustaa ja prosesseja ei ole mietitty kokonaisuutena. Tätä problematiikkaa sekä ulkoisen ja johdon laskentatoimen riippuvuussuhteita pohditaan tarkemmin tässä kirjoituksessa.

Kirjanpitoon perustuva johdon raportointi

Ulkoisen laskennan perustan muodostaa tilikartta, joka yksittäisenä laskentatunnisteena täyttää ulkoisen raportoinnin tarpeet melko pitkälle. Sen sijaan johdon laskentatoimi koostuu lukuisista eri näkökulmista kuten kustannuspaikka, asiakas, tuote ja markkina-alue. Silloin kun johdon laskentatoimen raportointi halutaan kytkeä tiiviisti kirjanpidon lukuihin, on järkevää tuottaa keskeisimmät laskentatunnisteet suoraan kirjanpidon saldoihin. Tästä voi syntyä kitkaa ulkoisen ja sisäisen laskennan välillä, koska kaikki tilitason laskennan päälle tuleva voidaan ulkoisen laskennan kannalta kokea hankalaksi ja työllistäväksi.

Tilikartan hallinta itsessään muodostaa monelle yritykselle oman haasteensa. Tilikartalla yritetään liian usein ratkaista johdon laskentatoimen tarpeita esimerkiksi lisäämällä uusi tili uuden tuotteen myynnin seurantaan. Järkevämpi ratkaisu olisi käyttää erillistä laskentatunnistetta. Radiomainonnan erittely internetmainonnasta tilitasolla voi tietyllä toimialalla olla liiketoimintakriittistä, mutta viimeistään suunnitteluvaiheessa liian pilkuntarkaksi paisunut tilikartta aiheuttaa usein ongelmia. Myös migraatiot perusjärjestelmien välillä voivat olla tuskaisia, mikäli tilikartta on päässyt rämettymään. Less is more pätee tässäkin.

Pääkirjasaldojen rikastaminen tarpeellisilla laskentatunnisteilla on syytä automatisoida mahdollisimman pitkälle. Integroiduissa toiminnanohjausjärjestelmissä kannattaa laittaa paukkuja tiliöintiohjauksiin, jolloin esimerkiksi laskutusmoduulin data ohjautuu pääkirjatasolle halutuissa laskentatunnisteissa tarkasti ja tehokkaasti. Tällöin ulkoisen laskennan raportoima myynti voidaan eritellä suoraan pääkirjatasolta esimerkiksi tuotteiden ja markkina-alueiden suhteen, ilman että tietoja tarvitsee erikseen kaivella laskutusmoduulista. Pääkirjan ja operatiivisen järjestelmän väliset mahdolliset erot voidaan selvittää nopeasti.

Valmistustoimintaa harjoittavan yrityksen myyntikate voidaan johtaa kirjanpidosta jopa asiakastasolla, mikäli yrityksellä on integroitu varasto- ja myyntitilausjärjestelmä. Ostolaskut kirjataan tällöin tasetilille, josta valmistustilauksen tulouttamisen kautta kirjautuu automaattisesti kustannus tulokseen. Asiakaskatteen raportointi kirjanpidosta ei kuitenkaan onnistu, mikäli yritys kirjaa varasto-ostot ensin tuloslaskelmaan ja kuukauden lopussa oikaisee varastosaldon varaston muutoksen kautta. Myydyille tuotteille ei kirjanpidossa voida tällöin kohdistaa valmistuskustannuksia asiakastasolle.

Vaikka tiliöintiohjaukset automatisoitaisiin mahdollisimman pitkälle, lopullinen raportointi vaatii saldojen oikaisuja ja täydennyksiä manuaalisilla kirjanpidon vienneillä. Näissä johdon laskentatoimen tarpeet tulisi miettiä tapauskohtaisesti. Usein kirjaustaso myyntikatteen yläpuolisille erille halutaan pitää johdon laskennan tarpeiden mukaisena. Useassa toiminnanohjausjärjestelmässä muistiotositteita voidaan ladata järjestelmään liittymällä esimerkiksi csv-tiedostoista. Tämä säästää kirjanpitäjän aikaa merkittävästi ja vähentää näppäilyvirheiden mahdollisuuksia. Oleellista on dialogi ja molemminpuolisten tarpeiden ymmärrys controlling-toiminnon ja ulkoisen laskennan välillä.

Johdon laskentatoimen erilliset järjestelmät

Yrityksen toimiala yhdistettynä johdon raportoinnilta vaadittuun tarkkuustasoon sanelee monessa tapauksessa johdon laskennan toteuttamistavan. Lentoyhtiön reittiliikenteen kannattavuuslaskenta ei onnistu ilman tietojen yhdistelyä useista eri järjestelmistä. Kaupallisen television mainosaikojen katteen selvittäminen ei myöskään ole johdettavissa suoraan kirjanpidosta. Myös eri varaston arvostusmenetelmät (esim. FIFO vs LIFO) voivat vaatia kustannuslaskennan eriyttämistä kirjanpitojärjestelmästä. Johdon laskentatoimen vastuulle jää tällöin kustannuslaskennan rakentaminen ja ylläpitäminen, missä myyntisuoritteille mallinnetaan ja kohdistetaan haluttu kustannus. Kustannuskomponenttien mallintaminen ja ylläpitäminen tulisi tällöin olla läpinäkyvää ja tarkoin johdettua, jotta siltalaskelmat kahden eri systeemin välillä voidaan toteuttaa luotettavasti ja tehokkaasti.

Kirjanpitoprosessin hitaus voi myös olla syy sille, että johdon raportointi eriytetään kirjanpidosta. Ulkoisen laskennan tuloksen valmistumista ei voida välttämättä odottaa vaan keskeiset tunnusluvut halutaan johdon saataville nopeammin. Tällöin tarvitaan edistynyt laskentajärjestelmä, jossa ylätason luvut allokoidaan halutuille laskentatunnisteille tiettyjen ajureiden ja jakaumien suhteen. Allokointitekniikkaa käytetään tyypillisesti epäsuorien kulujen kohdistamisessa laskentatunnisteille, mutta tietyissä tapauksissa se voi olla välttämätöntä myös suorien kustannusten osalta. Tekninen toteutus tarvitsee tällöin yleensä tietovarastointiratkaisun sekä laskentamoottorin allokointien tekemiseen. Jälkimmäinen voidaan toteuttaa sekä OLAP- että relaatiokantapohjaisilla ratkaisuilla.

Konsernilaskenta

Konsernirakenne ja siihen liittyvä konsernilaskenta voi kasvattaa kuilua johdon laskentatoimen ja ulkoisen laskennan välillä. Usein konsernilaskenta nähdään muusta laskennasta irrallisena toimintona, jonka ainoa tavoite on tuottaa laadukas konsernitilinpäätös ajallaan. Myös tytäryhtiö voi raportoida emoyhtiölle tavalla, joka on täysin irrallinen muusta yrityksen laskennasta. Väheksymättä konsernitilinpäätöksen tai tytäryhtiöraportoinnin sisällöllisiä ja teknisiä haasteita, nämäkin tulisi integroida yrityksen liiketoiminnan ohjaamista palvelevaan laskentaan. Tarkoituksenmukaiset laskentarakenteet ja -järjestelmät yhdistettynä osaavaan henkilöstöön on tässäkin tie kohti helpompaa elämää ja inhimillisiä työtunteja. Ennen konsernilaskentajärjestelmän käyttöönottoa tulisi miettiä sen sopivuus ja rooli laskentatoimen kokonaisarkkitehtuurissa.

Laskentatoimen johtaminen kokonaisuutena

Miten johdon laskentatoimi tulisi sitten organisoida suhteessa ulkoiseen laskentaan? Yrityksen toimiala, koko sekä rakenne vaikuttavat paljon johdon laskennan ratkaisun vaadittuun sisältöön ja toteuttamiseen. Näistä riippumatta seuraavat tekijät on kuitenkin hyvä pitää mielessä, kun tähtäimenä on kokonaisuuden järkevä johtaminen.

    1. Kulttuuri. Vahvista eri laskentaosastojen välistä kommunikaatiota ja yhteistyötä. Kaikilla laskentatehtävillä on oma tärkeä roolinsa ja yksittäisten osien optimointi ei välttämättä edistä laatua kokonaisuutena.
    2. Osaaminen. Ulkoisen laskennan asiantuntijan on ymmärrettävä johdon raportoinnin tarpeet ja tietotekninen perusta riittävän syvällisesti. Controllerin on puolestaan ymmärrettävä perusteet kirjanpidon järjestämisestä sekä tilinpäätöksen laadintaperiaatteista. Tehtävienkierto on hyvä keino osaamispohjan laajentamiseksi ja varmistamiseksi.
    3. Laskentarakenteet. Laskentarakenteiden omistajuus tulisi sälyttää taholle, jolla on riittävä ymmärrys koko talousohjauksen ketjun läpi.
    4. Lähdejärjestelmät. Ymmärrä lähdejärjestelmien mahdollisuudet ja rajoitteet. Pyri tekemään helpot liikkeet lähdejärjestelmissä erityisesti datan laadun parantamisessa. Toisaalta tiedon esittämiseen liittyvät rajoitteet on syytä ratkaista muualla.
    5. Fiksut työkalut. Hyödynnä teknologian tuomia mahdollisuuksia erityisesti raportoinnissa, suunnittelussa ja analytiikassa sekä tietovarastoinnissa. Hyvin rakennetusta perustasta on helppo lähteä mittaamaan hyötyjä edistyneemmän analytiikan avulla.
    6. Olennaisuus. Kokonaisuuden johtaminen ei tarkoita liiallista suunnittelua tai raskasta määrittelyä ennen muutokseen ryhtymistä. Oikeat ja riittävät tiedot -periaate kannustaa karsimaan lillukanvarret ja edistää tehokkuutta. Seuraava muutosta vaativa tarve on jo ovella, joten täydellisyyden tavoitteluun ei ole syytä pyrkiä.

 



Jedox ja Qlik yhteistyöhön

Näin heti elokuun alkuun saatiin meidän kannalta mukavia uutisia Saksan suunnalta, kun Jedox ilmoitti globaalin kumppanuussopimuksen solmimisesta Qlikin kanssa. Jo viime syksynä Jedoxin versioon 6 tuli oma connector, jonka avulla datan liikuttelu Jedoxin ja Qlikin välillä tuli mahdolliseksi QVX-formaattia hyödyntäen (katso aiheesta blogi-kirjoituksemme viime maaliskuulta).

Intito on ollut kuluvan vuoden kesäkuusta alkaen myös Qlik-kumppani, joten tämä uutinen otetaan meillä ilolla vastaan!



Gartner CPM Magic Quadrant 2016 – jakolinjat uusiksi

Vauhdikkaan kevätsesongin ja sitä seuranneen kesälomakauden vuoksi Intiton blogissa on ollut hiljaiseloa. Vaikka sesonki onkin vaihtunut syyskiireiksi, on näin lomakauden päätteeksi hyvä aktivoitua uudelleen myös tällä saralla.

Toukokuun viimeisenä päivänä julkaistiin uudistuneet Gartnerin Magic Quadrant -selvitykset CPM-ratkaisujen osalta (Corporate Performance Management). Tänä vuonna on puhuttava monikossa selvityksistä, koska Gartnerin entinen ”Magic Quadrant for Corporate Performance Management Suites” lakkautettiin ja tilalle tuli kaksi kokonaan uuttaa selontekoa: Magic Quadrant for Strategic Corporate Performance Management SolutionsjaMagic Quadrant for Financial Corporate Performance Management Solutions”.

(Huom: näistä dokumenteista on saatavilla kopiot likipitäen jokaisen selvityksessä mainitun ohjelmistotoimittajan sivustolta. Emme ole hankkineet oikeuksia näihin tutkimuksiin ja sen vuoksi emme valitettavasti voi suoraa linkkiä tähän kirjoitukseen laittaa)

Mikä CPM?

Vaikka CPM on käsitteenä kohtuullisen laajasti käytetty ja hyväksytty, ei sen sisältö ole alan toimijoiden markkinoinnissa ja viestinnässä vakiintunut. Kotimaisissakin palveluntarjoajissa on monia, joiden mukaan CPM on sama asia kuin budjetointi, rullaava ennustaminen tai muulla nimellä kutsuttu talouden suunnittelu. Kyllä budjetointi ja muut edellä mainitut menevät CPM-sateenvarjon alle, mutta näin määritelty CPM jää torsoksi. Intito on omaksunut kokonaisvaltaisen CPM-strategian, jossa yrityksen suorituskyvyn johtamiseen kuuluu paljon muutakin kuin budjetointi. Meille CPM on yrityksen johtamisjärjestelmä, jonka avulla niin strategisten kuin taloudellisten tavoitteiden jalkautus ja seuranta hoidetaan sekä varmistetaan, että yritys säilyttää joka hetki kilpailukykynsä. Tämä on todellakin paljon muuta kuin tilien saldojen arpomista budjetin syöttöpohjalle!

Tässä blogi-kirjoituksessa ei ole tarkoituksena ruotia yksittäisten toimijoiden sijoittumista Gartnerin nelikentissä tai hehkuttaa meidän edustamia teknologioita – nekin näistä nelikentistä löytyy. Sen sijaan haluamme avata ja analysoida näitä Gartnerin uusia selvityksiä ja näin toivottavasti auttaa lukijoitamme paremmin ymmärtämään tätä ilmiötä.

Suorityskyvyn johtamisen järjestelmien uudet jakolinjat

Gartner jakaa CPM-ratkaisut nyt siis kahteen segmenttiin ja tämä uusjako on heidän mukaan seurausta markkinoiden evoluutiosta:

  • Financial CPM (FCPM)
  • Strategic CPM (SCPM)

Englanninkielisestä terminologiasta puuttuu meidän kotimainen tapa jakaa yrityksen taloushallinto sisäiseen ja ulkoiseen laskentatoimeen. Tämä sama jakolinja näyttäisi kuitenkin soveltuvan myös FCPM- ja SCPM-segmenttien sisällön määrittelyyn.

Gartner määrittelee FCPM ratkaisuiksi sellaiset ratkaisut, jotka tukevat kauden vaihteen/kuukausiraportoinnin/tilinpäätöksen rutiineja sekä parantavat ja tehostavat yrityksen sekä ulkoista että sisäistä raportointia. Edellisiin CPM Magic Quadrant -selvityksiin verrattuna uusi FCPM Magic Quadrant on kokenut siltä osin suuren muutoksen, että sinne on otettu mukaan myös toimijoita, joiden ratkaisut ovat ennen kaikkea suunnattu ulkoisen laskennan prosessien tehostamiseen, kuten täsmäytyksen hallintaan (reconciliation management). Onpa FCPM nelikentän Leaders-kulmauksessa kaksi tuotetta (Blackline ja Workiva), joista puuttuu kokonaan konsernilaskennan konsolidointitoiminnallisuudet. Nämä edellä mainitut kaksi toimijaa on nostettu Leaders-kategoriaan erityisesti ”enhanced financial control and automation (EFCA)” ominaisuuksiensa ansiosta.  Tämän vuoksi esimerkiksi konsolidointijärjestelmän hankintaa suunnittelevan tulee lukea molemmat Gartnerin CPM-selonteot tarkkaan ja ymmärtää läpikotaisin selvityksissä esiteltyjen sovellusten ominaisuudet ja käyttötarkoitukset.

Gartner_MQ_2016_FCPM

 

Strateginen CPM (SCPM) puolestaan menee kotimaisen terminologian mukaisesti sisäisen laskennan puolelle ja tähän segmenttiin kuuluvat tuotteet edustavat enemmän sitä perinteistä CPM-osastoa, johon on aiemmassa Magic Quadrant selvityksessä totuttu. Tyypillisesti näiden SCPM-ratkaisujen avulla tuetaan yrityksen budjetointi-, ennuste- ja muita suunnitteluprosesseja. Lisäksi niissä on kannattavuuslaskentaa ja strategian hallintaa tukevia ominaisuuksia. Gartnerille täytyy antaa kritiikkiä tämän segmentin nimeämisestä. Mielestämme segmentin kutsuminen strategiseksi CPM:ksi ei täysin vastaa näiden ratkaisujen käyttötarkoitusta. Olemme omassa työssämme ja asiakaskunnassamme huomanneet, että näillä tuotteilla toteutettujen ratkaisujen operatiivinen luonne on nimenomaan se, joka on viime vuosina noussut yhä tärkeämmäksi. CPM-teknologioiden avulla on alettu yhä enemmän toteuttaa ratkaisuja, joilla paikataan ERP-järjestelmien puutteita. Melko tyypillinen CPM-järjestelmä ”use case” alkaa olla sellainen, jossa ennen monen megatavun Excel-tiedostossa tuotettu ja siitä toiminnanohjausjärjestelmään viety laskennan lopputulos korvataan CPM-järjestelmän tuottamalla aineistolla. Tästä yksi esimerkki voisi olla esimerkiksi tuotekustannusten laskenta, jossa vaaditaan monimutkaisia kohdistussääntöjä.

 

Gartner_MQ_2016_CPM

Pilvi itsessään ei ole tie onneen

Pilvi – ja SaaS-palvelut ovat tämän päivän mega-trendejä ja ne ovat korostuneesti esillä toimialan markkinoinnissa. Myös Gartnerin CPM-nelikenttiin on noussut ”Pure-play SaaS” toimijoita, joiden ratkaisut ovat saatavilla ainoastaan pilvipohjaisina. Gartnerin mukaan pilvi oli aiemmin CPM-markkinassa hyvä tapa erottua kilpailijoista, mutta sen merkitys on vähentynyt, koska käytännössä jokaiselta toimijalta on oma SaaS-ratkaisu saatavilla. Usein pilvipalveluita markkinoidaan ratkaisuna kaikkiin mahdollisiin ongelmiin ja taustalle häivytetään se tosiasia, että pilvi on itse asiassa ainoastaan tapa jaella ohjelmistoja. Pilvipohjaisuudessa on omat etunsa on-premises -asennuksiin verrattuna, mutta ei pilvipohjaisuus itsessään ratkaise liiketoimintaongelmia, vaan sen tekevät ratkaisun toiminnallisuudet ja ominaisuudet riippumatta ohjelmiston jakelutavasta.

Onko pilvipohjaisuus sitten juuri se mitä asiakkaat nimenomaan haluavat? Gartner kysyi SCPM Magic Quadrant vastaajilta, että mitkä ovat keskeiset valintakriteerit CPM-ratkaisun valinnalle ja seuraavat kolme vastausta saivat suurimmat osuudet:

  1. Ratkaisun toiminallisuudet (45% vastaajista)
  2. Helppokäyttöisyys (42 % vastaavista)
  3. Kyky ottaa sovellus käyttöön nopeasti ja kustannustehokkaasti (35 % vastaajista)

Yksikään näistä kolmesta yllä mainitusta ei ole millään tavalla riippuvainen ohjelmiston jakelutavasta, toisin sanoen onko sovellus tarjolla pilvestä tai omasta konesalista. Sen sijaan asiakkaat näyttävät haluavan ominaisuuksiltaan monipuolisia, helppokäyttöisiä ja kustannustehokkaista ratkaisuja, mikä kuulostaa ainoastaan loogiselle. Itse asiassa vain 9% Gartnerin vastaajista oli sitä mieltä, että tuotteen valinta tehtiin nimenomaan pilvipohjaisuuden perusteella. Yksi pilvipalveluihin liittyvä paradoksi on myös se, että niitä markkinoidaan kustannustehokkaina. Meidän omien havaintojemme, jotka perustuvat sekä asiakkailta kuultuihin että eri ohjelmistotoimittajien ilmoittamiin hintoihin, ei pilvipohjaiset CPM-ratkaisut ole itse asiassa kilpailukykyisempiä on-premise asennusten kustannuksiin verrattuna. Hankkiessaan SaaS-ratkaisun asiakas ostaa huolettomuutta ja avaimet käteen palvelua, jolla on varsin kova hintalappu. Varsinkin jos asiakkaalla on oma IT-organisaatio, on virtuaalipalvelinympäristössä pyörivä on-premise CPM-ratkaisu todennäköisesti kokonaiskustannuksiltaan edullisin vaihtoehto.

Pilvi- ja SaaS-palvelut ovat tulleet jäädäkseen myös CPM-ratkaisuihin ja luultavasti toimittajien tuotekehityspanokset laitetaan jatkossa mitä suurimmassa määrin näihin ratkaisuihin. Pilvipohjaisuus ei kuitenkaan ole jatkossa enää siinä määrin erottautumistekijä kuin se ehkä aiemmin oli, vaan siitä on tullut ominaisuus muiden joukossa.

Gartner hankintapäätöksen tukena

Gartnerin CPM selontekoja lukiessa kannattaa muistaa se, että selvitys on tehty pohjoisamerikkalaisten lasien läpi, jonka vuoksi niissä korostuvat toimijat, joilla on vahva jalansija Yhdysvaltain markkinoilla. Lisäksi on hyvä huomioida, että kun Gartner puhuu keskisuurista yrityksistä, niin suomalaisessa kontekstissa on kyse meillä jo suuryrityskategoriaan menevistä yrityksistä. Kaikki Gartnerin nelikenttiin päätyneet ratkaisut ovat hyvin suurella todennäköisyydellä vähintään hyviä tai jopa erinomaisia siinä, mitä niiden luvataan tekevän. CPM-ohjelmiston hankintapäätöstä ei koskaan tulisi tehdä pelkästään Gartnerin tai muun vastaavan analyysin perusteella. Tärkeintä on selvittää oman organisaatiosi tarpeet perinpohjaisesti ja käyttää Gartnerin ja muiden vastaavien selvityksiä ainoastaan tukemaan hankintapäätöstä. Yksi aivan keskeinen seikka, johon Gartner ei pysty suoraan ottamaan kantaa, on kunkin tuotteen paikallinen palvelukumppanien verkosto. Ostettiinpa CPM-sovellus pilvestä tai omaan konesaliin asennettuna, vaatii se hyvin todennäköisesti ainakin käyttöönottovaiheessa konfigurointia, koulutusta ja muuta tukea, jonka pystyy kaikkein parhaiten antamaan paikallinen kumppani. CPM-ohjelmistojen osalta erityisen tärkeää on kumppanin liiketoimintaosaaminen ja laaja ymmärrys laskentatoimen menetelmistä ja prosesseista.



Kytketty liiketoiminnan suunnittelu, osa 2 – myynnin suunnittelu

Myynnin suunnittelu on koko suunnitteluprosessin tärkein osa-alue – olipa sitten kyse integroidusta suunnittelusta, S&OP:sta tai ihan vaan budjetoinnista. Hyvin toteutettu myynnin suunnittelu on parhaimmillaan erinomainen johtamisväline, johon osallistuu laaja joukko ihmisiä organisaation eri osista. Myynnin suunnittelun tärkeyttä ei ole tarpeen erikseen korostaa, mutta lienee hyvä mainita, että se ei ole pelkästään myynnin tai ylimmän johdon asia. Se mitä myynnissä tapahtuu, vaikuttaa lopulta koko organisaation toimintaan ja kykyyn selviytyä kilpailun paineessa.

Mitä tapahtuu jos myyntiä ei suunnitella tai sen suunnittelu epäonnistuu? Viime kädessä se vaikuttaa siihen kuinka yritys onnistuu tasapainottamaan sen tuotteisiin ja palveluihin kohdistuvan kysynnän ja tarjonnan. Jos tämä tasapainotilanne järkkyy, on sillä dramaattiset vaikutus laajalti koko yritykseen:

  • Asiakaspalvelu huononee, kun yritykset eivät pysty toimittamaan asiakkaiden tilauksia.
  • Liian optimistisesti tehty myynnin suunnitelma paisuttaa yrityksen varastoja ja lisää varastoihin sitoutunutta pääomaa.
  • Vastaavasti alakanttiin suunniteltu myynti johtaa siihen, että raaka-aineita voidaan joutua hankkimaan huonommilla ehdoilla ja kalliimmalla hinnalla kuin normaalisti.
  • Kun kysyntä ylittää tarjonnan, on usein valitettavasti seurauksena laadun heikkeneminen. Tämä pätee sekä tuotteisiin että palveluihin.
  • Yläkanttiin suunniteltu myynti johtaa ylimääräisiin alennuksiin ja kampanjoihin. Hintaeroosio jyllää ja katteet ohenee. Pahimmillaan joudutaan vähentämään henkilöstöä, joka johtaa yrityksen ilmapiirin huonontumiseen ja työmoraalin laskuun.

Kysynnän ja tarjonnan tasapainottamisen lisäksi myynnin suunnittelussa on kyse sekä volyymin että tuote-mixin suunnittelusta. Volyymisuunnittelun avulla saadaan piirrettyä ”iso kuva” myynnin kokonaisuudesta – kuinka paljon ja mitä se tarkoittaa rahamääräisesti. Tuote-mixin suunnittelu sen sijaan ottaa kantaa enemmän yksittäisiin tuotteisiin ja asiakkaisiin. Tuote-mixin suunnittelu on se osa-alue, jonka parissa yritykset viettävät suurimman osan myynnin suunnitteluun käytetystä ajasta. Tuote-mixin suunnittelu on aikaa vievää, koska se kertoo käytännössä, mitä asiakkaalle myydään ja toimitetaan. Talousohjauksen kannalta tämä on myös tärkeä työvaihe, koska näillä tuote-asiakas–mix päätöksillä on suora vaikutus yrityksen kannattavuuteen.

Varasto-ohjattu vs. tilausohjattu

Yksi keskeinen seikka myynnin suunnittelumallin toteutusta pohdittaessa on yrityksen tuotantostrategia. Varasto-ohjautuvassa (engl. make to stock) tuotantostrategiassa korostuu talousohjauksen kannalta varastojen ja käyttöpääoman optimointi, kun taas tilausohjatussa (engl. make to order) mallissa on keskeistä hyvin toimiva toimitusketju. Varasto-ohjautuvassa mallissa yritys koettaa ennustaa tulevaa kysyntää mahdollisimman tarkasti omaa tuotantoa ja varastoja optimoiden. Tämä strategia sopii hyvin sellaisille toimialoille, joissa on isot ja ennustettavat volyymit ja tuotteiden räätälöinnin aste on pieni. Varasto-ohjautuva tuotantostrategia on myös otollinen erilaisten tilastollisten mallien hyödyntämiselle sekä myynnin että käyttöpääoman optimoinnissa.

Tilausohjatussa tuotantostrategiassa nimensä mukaisesti tuotantoa ohjaavat saadut tilaukset. Tässä mallissa tuotantoa ei aloiteta ennen kuin asiakkaan tilaus on saapunut, joka luonnollisesti johtaa pidempään toimitusaikaan. Lisäksi tilausohjaus tyypillisesti mahdollistaa tuotteen räätälöinnin paremmin asiakkaiden vaatimusten mukaan ja se nähdään pienempien volyymien tuotantomallina. Tilausohjatussa mallissa ei ole samaa varastojen ja käyttöpääoman optimointihaastetta, mutta se vastaavasti vaatii paljon toimitusketjun hallinnalta. Koska tässä mallissa ei tyypillisesti muodostu samanlaista volyymia ja aikasarjoja, ei tilausohjattu tuotantomalli ole niin otollinen maaperä tilastollisten mallien hyödyntämiselle kuin varasto-ohjautuva liiketoiminta.

Tuotantostrategian osalta on vielä syytä mainita, että yrityksen sisällä voi olla samaan aikaan käytössä useita strategioita. Yksi tuotantoa harjoittava divisioona voi olla varasto-ohjautuva, kun taas toinen liiketoiminta saattaa olla tilausohjautuva. Tämän vuoksi yksi harmonisoitu myynnin suunnittelumalli ei välttämättä pysty palvelemaan koko yritystä, vaan jokaiselle liiketoiminnalle joudutaan toteuttamaan omat mallinsa.

Myynnin suunnittelun tarkkuustaso

Usein talouden ja ylemmän johdon näkökulmasta tehdyissä kirjoituksissa painotetaan, että suunnittelun (budjetointi/ennustaminen) painopistettä tulisi siirtää yksityiskohdista karkeammalle tasolle ja suurempiin kokonaisuuksiin. Näitä kirjoituksia on usein tulkittu siten, että tämä koskisi myös itse suunnitelmien laadintaa. Karkealla tasolla laaditut suunnitelmat, kuten myynnin ennusteet, voivat toimia silloin, kun yrityksessä on useita päällekkäisiä/rinnakkaisia suunnitteluprosesseja – tuotanto tekee omansa, myynti ja talous antavat omat näkemyksensä ja niin edelleen. Integroidun suunnittelumallin näkökulmasta liiketoiminnan ohjaus ja seuranta voivat olla karkeammalla tasolla, mutta esimerkiksi myynnin suunnitelmat saatetaan tehdä hyvinkin tarkalla tasolla. Tämä johtuu muun muassa seuraavista seikoista:

  • joku sen yksityiskohtaisen myynnin suunnittelun tekee joka tapauksessa: myyntipäälliköt, tuotannon suunnittelijat ja niin edelleen ja heille ainoa oikea tarkkuustaso on yksittäinen nimike ja asiakas. Tämän vuoksi yksityiskohtainen myynnin suunnittelu ei lisää työmäärää, vaan se tehdään ”luonnollisella” tasolla ja integroidaan osaksi yrityksen kokonaisvaltaista suunnitteluprosessia.
  • jos myynnin ennusteita halutaan käyttöön tuotannon ohjauksen pohjana, on ne pakko lopulta viedä yksittäiselle nimikkeelle asti.
  • aggregaatit/keskiarvot eivät sovellu myynnin suunnittelun pohjaksi. Esimerkiksi tuoteryhmätasolla ja tuoteryhmän keskihinnoilla tehdyt myynnin ennusteet johtavat poikkeamiin, koska usein tuoteryhmien sisällä on suurta volyymivaihtelua tuoteryhmän nimikkeiden kesken. Tuoteryhmätasoisen myynninsuunnittelun sijaan järkevämpää voisi olla esimerkiksi ennustaa nimiketasolla tuoteryhmän volyymista 80 prosenttia edustavat nimikkeet ja loput könttäsummatasolla. Tosin silloinkin haasteeksi jää tuo könttäsumman keskihinnan laskeminen.

Hyvä myynnin suunnittelu on itse asiassa myös jo kannattavuuden suunnittelua. Tämä tarkoittaa, että myynnin suunnitteluun tulisi ottaa mukaan myös erityyppiset alennukset sekä myyntiä vastaavat kustannukset (engl. cost of goods sold, COGS). Kun nämä on mukana, niin ollaan varsin pitkällä tuote- ja asiakaskohtaisen kannattavuuden suunnittelussa.

Tarkkuustasopohdiskelua tarvitaan myön myynnin suunnittelun aikajänteen osalta. On varsin tyypillistä, että myynnin suunnitelmat rullaavat joustavasti kalenterivuoden yli ja saattavat kokonaisuudessaan kattaa jopa 18-24 kuukauden aikajänteen. Lisäksi lähitulevaisuuden osalta tehdään viikko- ja jopa päivätasolle ulottuvia myynnin suunnitelmia. Lisäksi kun otetaan mukaan yleinen toive, että suunnitelmia täytyisi pystyä muokkamaan ylätasoilla (vuosi, kuukausi, kvartaali ja niin edelleen), niin käytössä olevalta työkalulta aletaan vaatimaan suurta joustavuutta.

Myynnin suunnittelun haasteita

Kokemuksemme mukaan myynnin suunnittelumallit ovat usein varsin suoraviivaisia ja nopeita toteuttaa. Tämä jo sen vuoksi, että harvassa yrityksessä tätä tehdään täysin tyhjältä pöydältä. Myynnin suunnittelu on luonteeltaan sen kaltaista, että sen ensimmäiset versiot alkavat hahmottumaan exceleihin jo hyvin varhaisessa yrityksen elinkaaren vaiheessa. Tyypillisesti integroidun suunnittelumallin käyttöönottoon liittyy seuraavanlaisia haasteita:

  • Excelistä loppuu vääntö liian suuren volyymin edessä: onneksi näihin ongelmiin meiltä löytyy hyllystä täsmälääkkeet.
  • Myynnin suunnittelu vaatii hyvin toimiakseen integraatiot yrityksen ERP-järjestelmään/tietovarastoon. Integraatioiden lisäksi tarvitaan luonnollisesti, että ERP:stä löytyy tarvittavat tiedot myynnin suunnittelumallin toteutukseen.
  • Master datan merkitys ja erityisesti sen puutteet tulevat esiin usein myynnin suunnittelumallia toteutettaessa.
  • Yksiköiden (paketti, pussi, kilogramma jne) monimuotoisuus: missä yksiköissä tuotetta myydään asiakkaalle, missä yksikössä tuote valmistetaan, misää yksikössä tuotetta (raaka-ainetta) hankintaan.
  • Tuotteiden elinkaaren hallinta: kuinka ottaa tulevaisuuteen ulottuvissa suunnitelmissa huomioon nykyisten tuotteiden mahdollinen ”delistaus” (poistuminen valikoimasta) ja uutuustuotteet.
  • Hyvätkään työkalut eivät poista sitä tosi seikkaa, että onnistunut myynnin suunnittelu vaatii myös toimivan prosessin, johdon sitoutumisen asiaan sekä hyvän kommunikaation organisaation sisällä.



QlikView ja Jedox liiketoiminnan suunnitteluvälineinä

QlikView on Suomessa erittäin laajalti käytetty raportointiväline ja se soveltuu erityisen hyvin tiedon visualisointiin, dashboardien rakentamiseen ja muuhun graafiseen raportointiin. On kuitenkin kuitenkin muutama osa-alue, joita QlikView:ssä ei voi tehdä tai se ei suoriudu siitä erityisen hyvin. Tässä blogikirjoituksessa kerrotaan kuinka voit saada lisää irti QlikView:stä täydentämällä sitä Jedoxin avulla. Kirjoituksessa viitataan QlikView:hun, mutta kaikki esitetty on sovellettavissa myös Qlik Senseen.

Write-back: suunnittelu (budjetointi/ennustaminen), kommenttien kerääminen

QlikView on puhtaasti raportointiväline ja sillä ei voi kerätä käyttäjiltä syötteitä. Käyttäjien syötteillä voidaan tarkoittaa esimerkiksi talouden suunnitelmia, kuukausiraporttien kommentteja ja niin edelleen. Jedox on sen sijaan hybridiväline eli sillä voidaan kerätä käyttäjiltä dataa ja tuottaa raportteja sekä käyttäjien syötteistä ja muista lähteistä ladatusta datasta. No, mitä erityistä tässä on sitten Jedoxin eduksi muihin suunnittelujärjestelmiin verrattuna?

  • Jedoxilla tehdyt syöttöpohjat voidaan integroida osaksi QlikView-sovellusta ja QlikView-sovelluksesta voidaan välittää parametreja Jedox syöttöpohjiin. Esimerkiksi: käyttäjä valitsee QlikView:ssä listboxista kustannuspaikan '1001 Sales Finland' ja painaa sen jälkeen painiketta, jolla avataa myynnin syöttöpohja. Tämä käyttäjän valinta voidaan siis dynaamisesti välittää Jedox syöttöpohjalle.
  • Jedoxissa on QlikView Connector, jonka avulla suunnitelmat voidaan kirjoittaa QlikView:n QVX-tiedostoformaattiin. Tämä voidaan tehdä inkrementaalisesti eli esimerkiksi, kun käyttäjä vahvistaa kustannuspaikan '1001 Sales Finland' myyntiennusteen, muodostuu samalla hetkellä QVX-tiedosto '1001 Sales Finland_Sales budget.QVX', joka voidaan edelleen ladata QlikView:hun.

QlikView:n ja Jedoxin yhteistyö perustuu siis siihen, että Jedoxiin rakennettu suunnittelumalli voidaan upottaa osaksi QlikView-dokumenttia ja suunnittelumalliin voidaan välittää tietoa käyttäjän QlikView-dokumentissa tekemistä valinnoista. Loppukäyttäjän kannalta tilanne on miellyttävä, koska liikkumista eri sovellusten välillä ei tarvita, vaan kaikki tapahtuu tutusta QlikView-käyttöliittymästä.

Jedox verrattuna muihin

Markkinoilla on tarjolla useampia 'Planning with QlikView' –henkisiä tuotteita, jotka lupaavat saumatonta integraatiota QlikView:n kanssa. Kaikille näille on yhteistä se, että näiden integraatio ei todellisuudessa mene yhtään syvemmälle kuin Jedoxin tapauksessa: kyseessä on erillinen sovellus, joka kyllä kommunikoi QlikView:n kanssa käyttäjien tekemien valintojen välittämisen muodossa, mutta itse käyttäjän syöttämä data tallennetaan ensimmäisessä vaiheessa muualle kuin QlikView-dokumenttiin. Mikä ovat siis Jedoxin edut näihin'Planning with QlikView' –kategoria tuotteisiin verrattuna:

  • Jedoxin käyttö ei rajaudu pelkästään yksinkertaisten syöttöpohjien tuottamiseen ja datan keräämiseen. Jedox on monipuolinen ja tehokas laskentamoottori, jolla voidaan toteuttaa muun muassa monimutkaisia kustannusten allokointimalleja, joita ei näillä verrokkituotteilla voi tehdä.
  • Jedoxissa on hyvä Excel-integraatio, joka mahdollistaa datan tarkemman analyysin ja raporttien tuottamisen Excel-formaatissa, vaikka data kerrättäisiin QlikView:n avulla.
  • Jedox taipuu työkaluna lähes mihin tahansa suunnitteluprosessiin, olipa sitten kysymys talouden suunnittelusta tai operatiivisesta suunnittelusta. Jedoxin aikadimensiot ovat täysin vapaasti määritettävissä – suunnitelmia voidaan tehdä kuukausi-, viikko-, päivä- tai millä tahansa tasolla. Samon dimensioiden sisältö ja määrä on vapaasti päätettävissä.
  • Jedoxilla voidaan luoda helppokäyttöisiä ja näyttäviä syöttöpohjia ja raportteja. Eikä se vaadi ohjelmointitaitoja, vaan hyvät Excel-taidot riittää!

Jedox-QlikView -integraatio

Jedoxilla tehdyt suunnitelmat tallentuvat tuotteen mukana tulevaan in-memory OLAP-tietokantaan. Integraatio QlikView:n kanssa perustuu QVX-tiedostoformaattiin:

  • QVX on QlikView:n natiivi tiedostoformaatti, joka on tarkoitettu kolmannen osapuolen sovellusten integrointiin QlikView:n kanssa.
  • QVX-tiedostoformaatti on optimoitu QlikView:n suorituskyvyn kannalta.
  • Jedox voi muodostaa QVX-tiedoston automaattisesti, joko käyttäjän triggeröimänä (esim. käyttäjä painaa budjetin syöttöpohjassa olevaa 'submit' painiketta budjetin , joka muodostaa tiedoston) tai tämä tiedosto voidaan muodostaa QlikView dokumentin latauksen yhteydessä. Lisäksi nämä tiedostot on mahdollista muodostaa inkrementaalisesti eli optimoida QlikView:hun ladattavaa dataa myös tältä osin.

 

Lataa Jedox Whitepaper Extend the value of your Qlik investment ja tutustu kuinka voit johtaa liiketoimintaasi paremmin yhdessä Jedoxin ja QlikView:n kanssa.

Katso myös alla oleva video, joka havainnollistaa käytännössä kuinka nämä kaksi työkalua toimivat yhdessä.



Siirtyminen Cognos Planningista Cognos TM1:een

Suomessa on edelleen paljon IBM asiakkaita, joilla on käytössä vanha kunnon Cognos Planning/Cognos Enterprise Planning (EP). EP oli aikanaan uraauurtava väline yritysten budjetointiin ja ennustamiseen, mutta aika on ajanut tämänkin tuotteen ohi jo jonkin aikaa siten. EP:n manttelinperijä IBM:n tarjoamassa on IBM Cognos TM1. TM1 ei ole uusi versio EP:stä, vaan tuotteella on oma historiansa ja kehityspolkunsa. Tässä blogikirjoituksessa käsitellään niitä hyötyjä, joita siirtyminen Cognos Planningista TM1:een tuo tullessaan sekä käydään läpi migraatiovaihtoehtoja.

Cognos Planning vs. Cognos TM1

Mitä eroa sitten on Cognos Planningin ja TM1:n välillä? Todella paljon. Cognos Planning oli aikanaan ensimmäisiä aidosti moniulotteisia suunnitteluvälineitä ja siinä oli sen ajan mittapuun mukaan intuitiivinen käyttöliittymä. TM1 puolestaan on monipuolinen liiketoiminnan mallinnusväline ja väkevä sisäisen laskennan numeronmurskaaja. Kun Cognos aikanaan hankki Applixin (yhtiö, joka kehitti TM1:n) oli alusta asti melko selvää, että näiden sinänsä kahden eri tuotteen tiet tulevat yhtymään jossain vaiheessa. Näin on myös käynyt ja TM1 suunnittelusovellusten logiikka on tänä päivänä hyvin lähellä sitä mihin Cognos Planning käyttäjät ovat tottuneet. Sillä erotuksella tosin, että kaikki Cognos Planningiin liittyneet suorituskyky- ja muut haasteet ovat poissa.

TM1:stä on joskus tituleerattu controllerin sveitsiläiseksi linkkuveitseksi, jolla voi tosiaan tehdä myös paljon muuta kuin pelkästään budjetointia ja ennustamista. Käyttökohteita sille löytyy ihan perinteisestä johdon raportoinnista aina kustannuslaskentaan asti. Seuraavassa on käyty miten TM1:n eroaa perinteisestä Cognos Planningistä.

  • Cognos Planningin suorituskyky on heikko. Cognos Planning suunnittelumallia rakennettaessa kehittäjä joutuu koko ajan tasapainoilemaan mallin koon kanssa pyrkien pitämään sen mahdollisimman pienenä, jotta mallin suorituskyky pysyy edes kohtalaisena. TM1:ssä ainoa rajoite suunnittelumallin koon suhteen on käytettävissä olevan palvelimen muistin määrä. TM1:llä on toteutettu paljon operatiivisia suunnittelujärjestelmiä, joissa suunnitelmat laaditaan esimerksiksi SKU-tasolla ja yksittäisiä SKU:ta saattaa mallissa olla satoja tuhansia.
  • Cognos Planningissa jouduttiin suorituskykyrajoitteiden vuoksi pilkkomaan mallit pienempiin osiin. TM1:ssä ei suorituskyvyn vuoksi malleja tarvitse pilkkoa vaan isotkin suunnittelumallit voidaan pitää yhdessä paikassa. Tämä helpottaa huomattavasti järjestelmän ylläpitoa.
  • Lisäksi mallien ylläpitoa TM1:ssä helpottaa se, että dimensioita voidaan jakaa eri mallien kesken. Näin ollen esimerkiksi samaa organisaatiorakennetta ei tarvitse rakentaa ja ylläpitää jokaisessa mallissa erikseen, vaan yksi keskitetysti ylläpidetty rakenne on kaikkien mallien käytössä.
  • Cognos Planning on vain ja ainoastaan suunnittelujärjestelmä, jolla suunnitelmat kerätään ja sen jälkeen ne julkaistaan tietokantaan muilla välineillä raportoitavaksi. TM1 sen sijaan on teknologia, jolla voidaan tehdä paljon muutakin kuin pelkästään budjetteja ja ennusteita. TM1 konsolidoi kerätyn tai sinne ladatun datan reaaliaikaisesti ja TM1:stä pystyy raportoimaa suoraan ilman erillistä datan julkaisua.
  • TM1:ssä voidaan pitää rajoittamaton (palvelimen muistin rajoissa kuitenkin) määrä historiadataa ja suunnitelmien versioita. Cognos Planning puolestaan tyypillisesti on pidetty ainoastaan suunnitelman työversio ja korkeintaan vertailutiedot suunnitelman työversioon karkealla tasolla.
  • TM1:llä voidaan tehdä huomattavasti edistyneempää laskentaa.
  • TM1 dimensiot tukevat rinnakkaisia hierarkioita.
  • TM1 mahdollistaa paremmin simuloinnin ja what-if –skenaariot sandbox-toiminnallisuuden ansiosta.
  • TM1:ssä on hyvin toimiva Excel-integraatio.
  • TM1 on saatavissa myös pilvipalveluna. Tutustu tähän tarkemmin lukemalla aiempi kirjoituksemme IBM Planning Analyticista.

Siirtyminen Cognos TM1:een / Planning Analyticsiin

TM1 Performance Modeller (TM1:n mallinnustyökalu) versiossa 10.2. ja sitä uudemmat on olemassa “Import Cognos Planning Model”-toiminto, jonka avulla Cognos Planningilla tehty suunnittelumalli ainakin osittain saadaan vietyä sisään TM1:een. Lyhyesti kuvattuna import-toiminnossa luetaan sisään Cognos Planning Contributor -työkalussa luotu XML-tiedosto.  Tiedoston avulla TM1:een saadaan luettua dimensiot, kuutiot ja linkit Cognos Planningista. Dataa tämä sisäänluku ei siirrä, eikä myöskään linkkejä ulkoisista tietolähteistä ladattavaan dataan. XML-tiedoston sisäänluvun jälkeen malli tulee luonnollisesti vielä validoida TM1:ssä sekä mallin käyttäjäoikeudet asettaa uudelleen. Seikkaperäisempi kuvaus mallin sisäänluvusta löytyy löytyy täältä.

Import_Cognos_Planning_Malli

Ohjattu Cognos Planning -mallin tuonti TM1:een

Vaikka vanhan Cognos Planning -suunnittelumallin saisikin luettua varsin pitkälle TM1:een, kannattaa siinä yhteydessä vielä miettiä tuon vanhan mallin mielekkyys uudelleen. Kuten tämän blogi-kirjoituksen ensimmäisessä kappaleessa jo todettiin, oli Cognos Planningin kanssa suorituskykyhaasteita, jonka vuoksi malleja jouduttiin pilkkomaan useampaan pienempään kokonaisuuteen. Näitä suorituskykyhaasteita ei TM1:n kanssa enää tulee ja se tarjoaakin mahdollisuuden mallien yhdistelyyn. Tällä saavutetaan ensinnäkin etuja ylläpidon kannalta kuin myös käytettävyyden kannalta. Lisäksi siirtymä TM1:en on hyvä hetki muutenkin miettiä suunnitteluprosesseja uusiksi ja päivittää nekin nykytilanteen mukaiseksi.

Meillä on hyviä kokemuksia ja onnistumisia nopeista siirtymistä Cognos Planningista TM1:een.Vanhojen Cognos Planning-lisenssin hyödyntäminen on osittain mahdollista TM1:en kanssa ja samoin Planning Analytics on hinnoittelultaan kilpailukykyinen vaihtoehto jos SaaS-malli kiinnostaa. Ota yhteyttä niin kerromme niin kerromme kuinka siirtymä onnistuu mutkattomasti!

 

 

 



Budjetointi- ja ennustejärjestelmän ostajan opas

Näin kevään korvalla alkaa olla se aika vuodesta, jolloin yritykset alkavat miettimään vieläkö ensi syksynä jatketaan budjetointia samoilla mega-Exceleillä kuin aina aiemmin vai olisiko jo aika tehdä tälle kaavavirheiden ja epävireessä olevien tiedostojen suolle jotain?

 

Me Intitossa kasasimme yhteen vuosien varrella hyväksi havaitut vinkit budjetointi- ja ennustejärjestelmän ostajille ja jaamme ne nyt kaikelle kansalle.

1. Aloita itse prosessista – Suunnittelujärjestelmän hankinta on hyvä tilaisuus myös tuulettaa ja virtaviivaistaa itse suunnitteluprosessia. Usein vanhaa prosessia ei ole edes tarkoituksenmukaista täysin kopioda uuteen järjestelmään, vaan järjestelmän avulla koko suunnitteluprosessista on mahdollista saada enemmän irti.

2. Älä hanki järjestelmää pelkästään budjetointia silmällä pitäen – Hyvästä suunnittelujärjestelmästä on iloa muutenkin kuin pelkästään budjettia tehdessä. Parhaimmillaan suunnittelujärjestelmä on myös yrityksen suorituskyvyn johtamisen järjestelmä, josta löytyy niin toteumat kuin suunnitelmat sulassa sovussa rinnakkain.

3. Suunnittelujärjestelmän ei tarvitse näyttää rumalta – Samalla tavoin kuin raportoinnissa puhutaan paljon tiedon visualisoinnista, myös suunnittelujärjestelmässä tulisi voida visualisoida suunnittelmia graafisesti. Hyvässä suunnitelujärjestelmässä on web-käyttöliittymä, jolla voidaan tehdä suunnitelmien laadintaa tukevia graafeja ja mittareita. Siis ehdoton ei pelkille tylsille taulukoille!

4. Älä hanki suunnittelujärjestelmää kirjanpidon simuloimiseen – Kirjanpidossa kirjataan liiketapahtumia tileille, hyvässä suunnittelujärjestelmässä ei. Liian usein suunnittelujärjestelmänä myydään ratkaisu, jolla voidaan syöttää lukuja kustannuspaikoittain tileille. Hyvällä suunnittelujärjestelmällä täytyy pystyä mallintamaan varsinaista liiketoimintaa sen oikeita ajureita käyttäen. Lisäksi eri suunnitelmien tulee kytkeytyä toisiinsa ja riippua toisistaan. Ja kas – siinä sivussa se syntyy budjetoitu tuloslaskelma ja tasekin lähes itsekseen.

5. Hanki liiketoimintaa tukeva ratkaisu, älä osta tiettyä ratkaisua pelkästään siksi, että se sopii IT-arkkitehtuuriin – Tällä kommentilla saa IT-väen vihat niskoihin, mutta me tykkäämmekin asioida enemmän liiketoiminnan kanssa :). Vakavasti puhuen, suunnittelujärjestelmien konepellin alle nähneinä meidän mielestä ei kannata sokeasti tuijoittaa minkä brändin logo suunnittelujärjestelmästä löytyy. Kaikissa järjestelmissä on oma integraatiotyönsä ja edes saman brändin tuotteet eivät aina valitettavasti keskustele täysin saumattomasti keskenään.

6. Excelissä ei ole mitään vikaa työkaluna – Excel on ja pysyy maailman johtavana raportointi- ja suunnittelujärjestelmänä. Excelin käyttöön näissä asioissa liittyy kuitenkin paljon ongelmia: kaavavirheitä, tiedostoista on usein päällekkäisiä versiota, tietojen konsolidointin on hankalaa ja niin edelleen. Nämä kaikki ongelmat on mahdollista selättää hyvällä suunnittelujärjestelmällä, mutta säilyttää Excel yhtenä käyttöliittymänä. Hyvässä suunnittelujärjestelmässä itse liiketoiminnan logiikka on mallinnettu suunnittelujärjestelmään, mutta Excelillä voidaan tarvittaessa syöttää tai ainakin raportoida järjestelmään syötettyjä lukuja – Exceliin ne suunnittelmat joka tapauksessa päätyvät, halusimme me niin tai emme.

7. Muut sekalaiset ja tekniset toiminallisuudet joihin kannattaa kiinnittää huomiota:

  • Workflow-toiminnallisuus prosessin hallintaa
  • Sisäisten erien käsittely ja eliminoinnit
  • Valuuttakurssaus
  • Mahdollisuus syöttää suunnitelmia eri tarkkuustasoilla.
  • Mahdollisuus tehdä suunnitelmia eri aikahorisonteilla sekä myös rullaavasti yli kalenterivuoden
  • Hierarkioiden ja dimensioiden hallinta
  • Datan suojaaminen käyttäjäoikeuksilla
  • Kausien ja versioiden lukitseminen
  • Integroituminen lähde- ja mahdollisiin kohdejärjestelmiin
  • Simulointi- ja what-if -toiminnallisuudet

8. Ja lopuksi: muista koulutus ja oman osaamisen vahvistaminen – Jotta saat investoinnistasi kaiken hyödyn irti, niin varmista, että suunnittelujärjestelmälle löytyy omistaja ja pääkäyttäjä yrityksen sisältä. Vaikka me mielellään tuemmekin suunnittelujärjestelmän ylläpitoa ja jatkokehitystä, niin käytäntö on osoittanut, että tyytyväisin asiakas on se, joka osaa itsenäisesti ylläpitää ja pienkehittää suunnittelujärjestelmäänsä.

Mikäli yrityksenne on näiden asioiden äärellä tänä keväänä, olemme mielellään auttamassa teitä!

Tässä vielä pari esimerkkikuvankaappausta mille Intiton toteuttama suunnittelujärjestelmä voisi näyttää. Tämä sovellus on toteutettu Jedox-teknologialla. Tutustu tähän suunnittelusovellukseen ja muihin esimerkkisovelluksiin Jedoxin Solutions -sivustolla.

Toteutamme budjetointi- ja ennusteratkaisuja myös IBM Planning Analytics -teknologialla.

Cost Center Planning -sovelluksen Dashboard/aloitussivu

Cost Center Planning -sovelluksen Dashboard/aloitussivu

Myynnin suunnittelu

Myynnin suunnittelu

Kiinteiden kulujen suunnittelu

Kiinteiden kulujen suunnittelu

 



Integroitu liiketoiminnan suunnittelu – läpinäkyvyyden ja kommunikaation mahdollistaja

Integroitu tai kytketty liiketoiminnan suunnittelu on ollut koko ajan keskeinen konsepti Intiton ideologiassa. Olemme asiakkaillemme mielellään kertoneet tästä filosofiasta ja olemme sitä menestyksekkäästi myös asiakkaillemme implementoineet. Julkaisemme talven ja kevään 2016 aikana blogikirjoitusten sarjan, jossa avaamme tätä konseptia tarkemmin. Tässä sarjan ensimmäisessä blogikirjoituksessa käymme läpi integroidun liiketoiminnan suunnittelun konseptia, hyötyjä sekä siihen liittyviä haasteita.

Integroidun suunnittelumallin konsepti

Integroidun suunnittelumallin konseptin lähtökohta on, että useasti yrityksen operatiivisen, taktisen ja strategisen suunnittelun välillä on useita epäjatkuvuuskohtia, joissa kaikissa hukataan tärkeää informaatiota – tietoa konsolidoidaan ja tärkeitä yksityiskohtia katoaa. Lopputulokseksi saadaan kyllä jonkinlainen ylätason esitys asiasta, mutta läpinäkyvyys alla oleviin liiketoiminnan ajureihin on heikko. Toisaalta myös liiketoiminnan suunnitelmien lähtöoletusten muutoksien vaikutus on hankala hahmottaa – esimerkiksi valuuttakurssien ja raaka-aine hintojen muutoksen vaikutus tuloslaskelman riveihin. Integroidun suunnittelumallin keskeinen idea on vähentää tai poistaa kokonaan erillisen operatiivisen, taktisen ja strategisen suunnittelun tarvetta ja yhdistää ne yhdeksi ja samaksi suunnittelukokonaisuudeksi ja -prosessiksi, joka tukee niin yrityksen strategisia päämääriä kuin arkista operatiivisen toiminnanohjausta. On kuitenkin syytä vielä erikseen korostaa, että kytketty suunnittelumalli ei ole sama asia kuin perinteinen erp-järjestelmillä tapahtuva toiminnanohjaus. Integroitu suunnittelu jää karkeammalle tasolla, kun taan erp-lähtöinen toiminnan ohjaus menee yksittäiseen tilaukseen ja toimitukseen asti.

Vaikka yrityksen suunnittelusta puuttuisi läpinäkyvyys, ei se välttämättä tarkoita, etteikö suunnitelmia tehtäisi jo nyt liiketoiminnan lähtökohdista. Usein yrityksissä tehdään erinäisten exceleiden avulla hyvin pitkälle kehittyneitä liiketoiminnan mallinnuksia. Ongelma on, että niiden nerokkuus jää kyseisten työkirjojen vangeiksi. Integroidun suunnittelun jalkauttaminen ei useinkaan tarkoita lisää työtä tai uusien suunnitelmien laatimista, vaan jo tänäkin päivänä tehtävien yksityiskohtaisten suunnitelmien päivän valoon tuomista Excelin varjoista.

Integroitu suunnittelu ei ole sama asia kuin Sales & Operations planning

Joidenkin mielestä integroitu liiketoiminnan suunnittelu on sama asia kuin sales and operations planning. Meidän mielestä näin ei kuitenkaan ole. Integroitu liiketoiminnan suunnittelu kattaa samoja prosesseja kuin sales and operations planning, mutta siinä on muutama keskeinen ero verrattuna perinteiseen S&OP-prosessiin:

  • Sales and operations planning-ideologiassa on keskeistä kysynnän ja tarjonnan tasapainottaminen. Integroitu liiketoiminnan suunnittelu ei sen sijaan rajaudu pelkästään myynnin ja tuotannon suunnitteluun, vaan se on kokonaisvaltaisempi prosessi kattaen yrityksen funktiot laajemmin.
  • Integroidussa liiketoiminnan suunnittelussa on vahvempi taloudellinen kytkentä kuin sales and operations planning –lähestymistavassa. Koska kytketyn suunnittelun laajuus on suurempi, on sen avulla myös mahdollista mallintaa koko yrityksen taloudellista suorituskykyä paremmin.

Integroitu suunnittelu ei ole sama kuin perinteinen budjetointi

Budjetointi ja integroitu liiketoiminnan suunnittelu ovat molemmat johtamisjärjestelmiä. Filosofialtaan nämä kaksi ovat kuitenkin täysin erilaiset. Budjetoinnin keskeinen funktio on tavoitteen asetanta. Vaikka budjetointi tehtäisiin näennäisesti bottom-up –tyylisesti, on se kuitenkin todellisuudessa usein top-down prosessi, jossa ylin johto antaa tavoitteen ja lukuja ”iteroidaan” niin kauan, että budjetoidut luvut saadaan johdon asettamalle tasolle. Samalla budjettiin usein leivotaan sisään paljon odotuksia, joilla ei välttämättä ole todellisuuspohjaa.

Integroitu suunnittelu sen sijaan on jatkuva ja kalenterivuoden/tilikauden yli rullaava prosessi, jossa näkymä yrityksen taloudellisesta suorituskyvystä rakennetaan aidosti alhaalta ylös. Siihen ei liity tavoitteiden asetantaa, vaan integroidun suunnittelun ensijainen tarkoitus on antaa mahdollisimman totuudenmukainen kuva yrityksen taloudellisesta ja operatiivisesta suorituskyvystä tulevaisuudessa. Se ei myöskään ole tuloslaskelmakeskeinen, kuten budjetointi perinteisesti on, vaan fokus on liiketoiminnan mittareissa ja poikkeamien tunnistamisessa.

Integroidun suunnittelumallin hyödyt

Integroitu suunnittelumalli nimensä mukaisesti yhdistää eri suunnittelun osa-alueet yhdeksi kokonaisuudeksi, joka lisää ymmärrystä liiketoiminnallisten päätösten vaikutuksesta yrityksen taloudelliseen suorituskykyyn. Tyypillisesti integroidun suunnittelumallin käyttöönotto tuo seuraavia etuja ja hyötyjä:

  • Liiketoiminnan syy-seuraus –suhteiden ymmärrys lisääntyy.
  • Kommunikaatio yrityksen sisällä paranee, koska eri toimijoiden vaikutukset näkyvät välittömästi koko mallin läpi.
  • On vain yhteisesti hyväksytyt luvut.
  • Mallin lähtöolettamat ja parametrit ovat kaikkialla samat ja niitä voidaan hallita keskitetysti.
  • Suunnittelyprosessin läpimenoaika paranee manuaalisen työn vähenemisen vuoksi ja säästynyt työaika voidaan kohdentaan suunnitelmien analysointiin.

Integroidun suunnittelumallin keskeisiä etuja ja hyötyjä on, että siinä suunnitelmat laaditaan yhteisesti hyväksyttyjen periaatteiden ja lähtöoletusten mukaisesti. Näin myös suunnitelmien ohjausvaikutus paranee, koska suunnitelmien logiikka on paremmin liiketoimintapäätöksistä vastaavien tiedossa ja niihin sitoutuminen on näin helpompaa.

Business controllerin rooli integroidussa liiketoiminnan suunnittelussa

Tyypillisesti talous-/controller-funktio on ollut vastuussa suunnitteluprosessin läpiviennistä. Integroidussa mallissa controllerin rooli muuttuu enemmän toteuttajasta fasilitaattoriksi ja liiketoiminnan edustajien rooli korostuu. Parhaimmillaan tämä lisää myös yrityksen sisäistä kommunikaatiota ja osallistaa ihmisiä suunnitteluprosessiin useammalta organisaation tasolta verrattuna controller-keskeiseen malliin.

Integroidun suunnittelumallin jalkautus vaatii onnistuakseen sitä tukevan tietojärjestelmän. Muussa tapauksessa controlloreiden työkuorma ei kevene ja suunnitelmien analyysityö jää väistämättä pintapuoliseksi. Lisäksi integroidussa suunnittelumallissa controllereiden työaikaa täytyy saada ohjattua pois suunnitelmien käsin konsolidoinnista jo senkin vuoksi, että controllerin tärkein tehtävä kytketyssä suunnittelumallissa on tukea liiketoimintajohtoja ja kasvattaa heidän ”numerotietoisuuttaan” eli lisätä ymmärrystä liiketoimintapäätösten taloudellisista vaikutuksista.

Integroidun suunnittelumallin osa-alueet

Integroitu suunnittelumallin osa-alueet ovat riippuvaisia toimialasta, jolla yritys toimii. Jokaisessa yrityksessä on kuitenkin myyntiä ja henkilöstöä ja näin ollen likipitäen jokaisessa integroidussa suunnittelumallissa on omat moduulinsa myynnin, henkilöstön ja kiinteiden kustannusten suunnittelulle. Tämän jälkeen muiden osamallien tarpeellisuus on täysin yrityksen toimialasta riippuvainen. Palveluyrityksillä myynnin ja henkilöstön suunnittelu kattaa usein valtaosan yrityksen ”kulumassasta”, kun taas tuotannollista toimintaa harjoittavilla yrityksillä vaaditaan omat mallinsa tuotannolle ja hankinnalle. Lisäksi yrityksen toimialasta ja elinkaaren vaiheesta riippuen saatetaan tarvita erillinen mallin investointien suunnittelulle. Eri toimintokohtaisten mallien lisäksi usein integroidussa suunnittelumassa halutaan hallinnon ja tukitoimintojen kustannuksia vyöryttää varsinaiselle liiketoiminnalle, jolloin integroituun malliin tarvitaan jonkinlainen kustannusten allokointimalli.

Integroidun suunnittelumallin haasteet

Kytketty suunnittelumalli toimii hyvin paperilla, mutta sen käytännön implementointi on jo asteen verran hankalampaa. Malli on vaativa implementoida, koska siihen vaaditaan paljon erityyppistä osaamista ja resursseja. Lisäksi mallin käyttöönotto vaatii myös sitä tukevaan teknologiaan investoimista. Integroitu suunnittelumalli tarvitsee alustakseen teknologian, jolla pystytään mallintamaan hyvin yrityksen liiketoimintaa. Iso osa markkinoilla tarjolla olevista budjetointijärjestelmistä soveltuu huonosti tähän tarkoitukseen, koska niiden toimintalogiikka on ”tilikartta-orientoitunut”. Nämä järjestelmät soveltuvat kyllä tili-kustannuspaikka – tyylisen suunnitteluun, mutta täysiverisiksi liiketoiminnan suunnittelujärjestelmiksi niistä ei ole.

Lisähaaste integroidun suunnittelumallin käyttöönotossa, että se on luonteeltaan armoton ja raadollinen liiketoiminnan anturi – niin hyvässä kuin pahassa. Integroidun liiketoiminnan suunnittelun käyttöönotto vaatii sitoutumista ja ajattelutavan muutosta yrityksen johdolta. Iso muutos tarvitaan johtamisfilosofiassa siinä, että integroidun suunnittelun antamia lukuja ”ei voi palauttaa suunnittelupöydälle”. Luvut muuttuvat ainoastaan siinä tapauksessa jos taustalla olevat liiketoiminnan ajurit muuttuvat ja näistä ajureista vastuussa olevat ihmiset sitoutuvat muutoksen.



IBM Cognos TM1 Health Check – järjestelmän pullonkaulat selville

IBM Cognos TM1 on oikein implementoituna suorituskyvyltään hyvä, helposti ylläpidettävä ja liiketoiminnan kannalta relevantti suunnittelu- ja raportointijärjestelmän ydin. Joskus kuitenkin käy niin, että edellä mainittuja luonnehdintoja ei voi yhdistää yrityksen käytössä olevaan IBM Cognos TM1 toteutukseen. Sen sijaan käyttäjien mielestä TM1 on hidas ja ei palvele tarkoitustaan. Onko silloin todettava, että vika on ohjelmistossa ja ohjemisto ei vaan taivu suunniteltuun tarkoitukseen? Vastaus on useimmiten ei.

On periaatteessa kaksi syytä miksi asiakkaan TM1-ympäristö on ajautunut tilaan, jossa loppukäyttäjien hermoja koetellaan: TM1 on implementointu alun perinkin väärin tai sitten aikaa myöten järjestelmään on päässyt kerääntymään ”teknistä velkaa”, joka alkaa jossain vaiheessa painaa.

Tällaista tilannetta silmällä pitäen Intito palveluvalikoimasta löytyy TM1 Health Check -palvelu, joka on analyysi asiakkaan TM1-ympäristön nykytilasta. TM1 Health Check selvittää asiakkaan TM1-ympäristön läpikotaisin seuraavista näkökulmista:

  • Järjestelmän suorituskyky
    • Onko järjestelmän suorituskyky paras mahdollinen?
    • Mitkä ovat järjestelmän vasteajat?
    • Onko järjestelmäresurssit riittävät?
    • Onko TM1 mallit tehty parhaiden käytäntöjen mukaan?
  • Järjestelmän käytettävyys
    • Ovatko TM1 mallit loogisia ja liiketoiminnan kannalta järkeviä?
    • Ovatko TM1 mallit ja käyttöliittymät helppoja ja loogisia käyttää?
    • Onko järjestelmässä vielä hyödyntämätöntä potentiaalia?
  • Järjestelmän ylläpidettävyys
    • Kuinka paljon järjestelmän perusylläpitotoimet vievät aikaa?
    • Järjestelmädokumentaation kattavuus ja sisältö?
    • Asiakkaan omien pääkäyttäjien osaaminen ja ylläpidon riippuvuus ulkopuolisesta avusta?

TM1 Health Check –palvelu toteutetaan haastattelemalla asiakkaan keskeiset sidosryhmät sekä analysoimalla niin TM1:n käyttämä tekninen ympäristö kuin varsinaiset TM1 mallit. TM1 Health Check –palvelun lopputuloksena syntyy loppuraportti, joka sisältää kuvauksen TM1 Health Check löydöksistä sekä suositukset TM1 suorituskyvyn, ylläpidettävyyden ja käytettävyyden parantamiseksi.

TM1 Health Check metodologia pohjautuu Intiton asiantuntijoiden kokemuksiin kymmenistä TM1-toteutuksista niin Suomessa kuin ulkomailla.

Jos yrityksessäsi on käytössä IBM Cognos TM1 ja luulet, että järjestelmä ei toimi parhaalla mahdollisella tavalla, on TM1 Health Check ensimmäinen askel oikeaan suuntaa. Kysy lisää meiltä!