Case LähiTapiola Miten valmisohjelmisto sovitetaan arkkitehtuuriin? Janne Ruuska

Transkriptio

1 Case LähiTapiola Miten valmisohjelmisto sovitetaan arkkitehtuuriin? Janne Ruuska 1

2 Sisältö 1. LähiTapiola asiakkaidensa omistama finanssitalo 2. Case CRM hankinta, arkkitehtuurin näkökulmasta toimita, tieto, järjestelmä, teknologia 3. Havainnot, opit kuinkas sitten kävikään 2

3 Fuusio Lähivakuutus ja Tapiola fuusioituvat vuonna Prosessi kestää 2 vuotta. Uudeksi nimeksi LähiTapiola Fuusion jälkeen vieläkin lähempänä asiakasta. Aiempaa kattavampi paikallinen palveluverkosto, paremmat verkkopalvelut, hyvät tuotteet ja kilpailukykyiset hinnat. LähiTapiola-ryhmä / Etunimi Sukunimi 28/09/2012

4 LähiTapiolasta Suomen johtava vahinkovakuuttaja vahinkovakuuttamisen markkinaosuus on 30 prosenttia vahinkovakuutuksen maksutulo on noin 1 miljardia euroa omistaja-asiakkaiden määrä on noin 1,5 miljoonaa henkilöstömäärä on noin 4 000, joista työskentelee alueyhtiöissä maksettujen korvausten määrä on noin 690 miljoonaa toimipisteiden yhteismäärä on yli alueyhtiötä, jotka tarjoavat kokonaispalvelua vakuutuksissa, pankkipalveluissa ja sijoittamisessa. LähiTapiola-ryhmä / Etunimi Sukunimi 28/09/2012

5 Tapiola järjestelmäkokonaisuus =IT Arkkitehtuurin näkemys yrityksen toimintoihin, järjestelmäarkkitehtuuri Case CRM LähiTapiola-ryhmä / Etunimi Sukunimi 28/09/2012

6 Liiketoimintamalli =Liiketoiminnan näkemys yrityksen toimintoihin Ydin toiminnot CRM asiakkaat Kumppanit Tuote- ja palvelutarjoama Asiakas- Segmentit, Markkinat Avain resurssit Jakelukanavat Kulut Tulot Asiakassuhteen hoitaminen, uusien asiakkaiden saaminen, lisämyynnin generointi, cross-selling tukeminen on ydinkomponentti liiketoimintamallissa. Ja tämän toiminnan tukemiseen hankinta kohdistui! Case CRM. 28/09/2012 Lähde: A. Osterwald, Y. Pigneur (2010). Business Model Generation. Wiley

7 CRM Fuusion keskeinen järjestelmä Fuusion valmistelussa korostettiin asiakassuhteen tärkeyttä Kummallakin yhtiöllä oli jo omat tapansa ja välineensä hoitaa ja kehittää asiakassuhdetta, analyysia ja yhteydenpitoa Asiakasta lähestytään kokonaisasiakkuutena, ei vakuutettavan omaisuuden kautta; keskittämisen edut saadaan etuohjelman kautta Asiakaskohtaamisessa oltava kokonaisnäkemys asiakkaan kokonaisturvasta, riippumatta kumman yhtiön asiakas hän on ollut aikaisemmin (sekä yksityis- että yritysvakuutukset) LähiTapiolan uudet tuotteet tulevat myöhemmin omalla aikataulullaan Ainoa uusi järjestelmä, joka fuusion ensimmäisessä vaiheessa toteutetaan hankinnan kautta (RFP huhtikuu 2012) 7

8 Asiakaskokemus ja asiakkuuden palvelumalli Asiakkuuden palvelumallin uudistus Toiminta Tieto Hankinnassa korostettiin liiketoiminnallisia tavoitteita - toimintakulttuurin ja ajattelu tapojen muutos - asiakkuuden hallinta tehokkaasti ja tuloksellisesti - asiakastietojen haltuunotto - työvälineiden saattaminen ajan tasalle -> crm-järjestemän ohjattava prosessia ja mahdollisesti myös automatisoitava rutiinitehtäviä (esim. sähköisessä korvausprosessissa automatisointiasteen nostaminen, vakiokirjeet, jne) Palvelumallin suunnittelu käynnistyi ennen järjestelmähankintaa Valmisohjelmiston hankinnassa annettiin vaatimukseksi vain liiketoimintavaatimukset ts. toiminta-arkkitehtuurille Järjestelmä Teknologia 8

9 Asiakastietojen yhdistäminen Tiedon laadulliset tavoitteet Yhtiöillä hieman toisistaan poikkeavat asiakaskäsitteet, tulevalla crm-järjestelmällä luonnollisesti oma malli Haaste: miten tunnistetaan yhteinen asiakas, ja otetaan se hallintaan kokonaisuutena? Varsinkin kun asiakaskäsite päivitetään? - Asiakas (yksityinen, yritys, perheenjäsen, yrityksen työntekijä ), sopimussuhde (vakuutettu, meklari, korvauksensaaja) jne, Pakettiratkaisulla oma asiakasmalli, miten olemassa oleva tieto yhdistetään malliin niin, että se on jatkossakin ylläpidettävä ja pystyy hyödyntämään olemassa olevia valmismoduleita? Perustetaanko asiakas crm-järjestelmään vai edelleen taustajärjestelmiin? Asiakastietojen päivitys crm:ssä ja miten ne synkronoidaan? Verkossa tapahtuva päivitys? LähiTapiola-nryhmä / Janne Ruuska Toiminta Tieto Järjestelmä Teknologia 9

10 Microsoft Case-Contract Entity Model Toiminta Tieto Järjestelmä Teknologia 10

11 Integrointi vakuutusjärjestelmiin Tapiolalla ja Lähivakuutuksella omat vakuutustenhoitojärjestelmät Ensimmäiset ajatukset integroinnista ennen hankintaa - Tapiolalla WebService rajapinta valmiina osaan tiedoista, osa DB2 proseduurien takana - Lähivakuutuksella ESB valmiina, mutta kaikkia tarvittavia asiakastietoja ei ole saatavilla väylän kautta Alkulataus eräsiirtona Toiminta Tieto Järjestelmä Teknologia 11

12 CRM-järjestelmän integraatio OutLook AD Suomen Asiakastieto Toimeksiantojen synkronointi? Verkkopalvelun hallinnointityökalu Merlin puhelinjärjestelmä Myynti-Winsure CRM Orange Contact puhelinjärjestlemä Verkkoviestien käsittelyjärjestelmä Winsure Palvelukanta Tehtävienhallinta Asiakasjärjestelmä Hakupalvelut Webdoku Arkisto Vakuutusjärjestelmät Vakuutustietojen haku Yhdistysten arkistot Digiarkisto Asianhallinta Asiakastietojen haku Tehtävien / viestien / toimeksiantojen synkronointi Toisen järjestelmän avaus (haluttu asiakas / vakuutus / dokumentti yms) Piirros: Jari Tietäväinen/Sofigate

13 Integrointi vakuutusjärjestelmiin Toimittajien erilaiset ehdotukset MS CRM integroinnista Toiminta Tieto Järjestelmä Teknologia Dynamics CRM vakiorajapinnat Oma tuotteistettu tietojen yhdistäjä MS SQL Server 2012 (SSIS) Integration services MS SQLServer 2012 Master Data Services + SSIS Asiakastiedon MDM Asiakastiedon koontitietokanta Tiedosto Tiedosto Haku- ja siirtopalvelut (WS, SP) Haku- ja siirtopalvelut (WS, SP) Tapiola Lähi Tapiola Lähi Tapiola Lähi Toimittaja A Toimittaja B Toimittaja C 13

14 XaaS palveluiden hankinta, mistä keskustelimme? Pilvipalveluiden hyödyntäminen - Laajojen referenssien puute CRM-ratkaisuissa - Organisaation kypsymättömyys käsitellä XaaS palvelun tietoturvallisuutta - Paikallinen asennus antoi enemmän rajapintoja hyödynnettäväksi integraatiossa - Rekisteripitäjän vastuut, miten muuttuu? - Tietojen palautus sopimuksen päättyessä? - Toimittajan oikeus keskeyttää palvelu? - IT-yritysten keskimääräinen ikä USA:ssa? Päätös toteuttaa tuotanto ja testausympäristö omiin palvelimiin, kehitystyö tehdään pilvessä Toiminta Tieto Järjestelmä Teknologia 14

15 Arkkitehtuurilausunto Arvioinnin kohde ja päiväys A ja Bn CRM-tarjouksien arkkitehtuuri, Arvioijat Yhteensä 9 henkilöä Arvioinnin perusteena olevat dokumentit A:n ja B:n tarjoukset sekä B:n myöhemmin toimittamat integrointia koskevat lisätietodokumentit. CRM-projektin projektikuvaus ei ollut käytettävissä arviointia tehtäessä, eikä arviointi siis koske sitä. Vaikutus tulevaisuuden järjestelmäkokonaisuuteen B:n MDM-pohjainen integraatioratkaisu tarjoaa paremman ja joustavamman perustan tulevalle kehittämiselle. Muita esiin tulleita huomioita Huomioitava sopimuksissa, että integraatioon tehtävien toteutustöiden IPR-oikeudet kuuluvat LähiTapiolalle, jotta varmistetaan toimittajariippumattomuus. Huomioitava CRM:n käyttäjähallinta, esim. organisaatiomuutoksissa ei saa joutua ylläpitämään organisaatiotietoja manuaalisesti CRM:ään. Suositukset B:n ratkaisu on integraation kannalta parempi ja varmistaa paremmin tietojen eheyden. Lisäksi ratkaisu on enemmän toimittajariippumaton. Arkkitehtuuriryhmä suosittelee B:n ratkaisun valitsemista. Liiketoiminta-arkkitehtuuri Molemmat perustuvat samaan tuotteeseen, ei eroja Järjestelmäarkkitehtuuri Molemmat perustuvat samaan tuotteeseen, ei eroja Tietoarkkitehtuuri A:n integraatio vaikuttaisi olevan enemmän tietokenttien vastaavuuden kuvaamiseen ja eräsiirtoihin suunniteltu työkalu. B:n ehdottama täysiverinen MDM (Master Data Management) tuote on toiminnoiltaan kattavampi ja sopii paremmin usean tietomalleiltaan erilaisen tietokannan ajantasaiseen synkronointiin ja tukee näin paremmin tietojen eheyden varmistamista. MDM-tuote luo paremman perustan tulevalle kehittämiselle. Tietoarkkitehtuurin ja etenkin tietojen eheyden varmistamisen näkökulmasta B:n ehdotus on parempi. Teknologia-arkkitehtuuri Microsoft Dynamics CRM sopii sekä Lähivakuutuksen että Tapiolan teknologialinjauksiin ja tuotteella on oletettavasti pitkä elinkaari. B:n MDS-ratkaisu on enemmän toimittajariippumaton. A:n ratkaisu on itse tehty, sillä on vähän käyttäjiä ja sitoo yhteen toimittajaan. A:n integraation toimivuus usean asiakastietokannan synkronoinnissa jäi dokumenteissa epäselväksi. B:n ratkaisu tarjoaa paremman perustan tulevalle kehittämiselle eikä sido samalla tavalla yhteen toimittajaan Teksti: Jari Tietäväinen

16 Oppeja, huomioita jne i 28/09/2012

17 Oppeja, huomioita 1/3 Koko arkkitehtuuripinon käsittely yhteisissä tilaisuuksissa haastavaa - liiketoimintaa ei juurikaan integrointitekniikat kiinnosta - it-tekijöitä kiinnostaa enemmän teknologia kuin liiketoimintaprosessin tarpeet tai tavoitteet -> kummatkin osaamiset pitäisi vahvistaa toisia, eikä toisen osaamista pidä väheksyä. Myy itsesi! Ostajalta odotetaan MacGyver taitoja - toimittajalla varaa tuoda neuvottelupöytään iso legioona eri asiantuntijoita, eri arkkitehtuurinäkökulmasta - ostajalla oltava monta osaamisaluetta: hankintaosaaja, arkkitehtuuriosaaja, projektiosaaja, liiketoimintaosaaja, teknologiaosaaja, rahoitusosaaja, juridiikan osaaja, (Togaf, ITIL, Cobit ) 17

18 Oppeja, huomioita 2/3 Ohjausryhmätyö aloitettava jo ennen projektointia - miksi antaa ohjausryhmälle valmis ratkaisu ohjattavaksi?? Jatkuvuus taattava kehitysideasta käyttöönottoon - projektipäällikkö nimettävä aikaisessa vaiheessa, myös arkkitehdeille annettava hankinnassa tavoitteet. Toiminnan mallinnus on vain oltava, tai ainakin näkemys tulevista toiminnallisuuksista seuraaville vuosille. Korostuu valmisohjelmiston hankinnassa! 18

19 Oppeja, huomioita 3/3 Kokonaisarkkitehtuurimalli auttaa myös hankintojen arvioinnissa Painotukset kokonaisarkkitehtuurin eri näkökulmissa tärkeitä, mutta soveltuvuus toiminta-arkkitehtuuriin (ja palvelukarttaan) on kaikkein oleellisin liiketoiminnan kannalta - Muut näkökulmat sovitetaan/sovitettava - Kustannus/hyöty laskelma mittaa liiketoimintahyötyjä Toiminta? Tieto Järjestelmä Teknologia 19

20 Kiitos, kysymyksiä? Janne Ruuska (FM, MBA) Suunnittelupäällikkö LähiTapiola, tietohallinto S-posti: 28/09/2012