Diplomityö - Antti Turpeinen
Lappeenrannan teknillinen yliopisto School of Business and Management Tietotekniikan koulutusohjelma Diplomityö Antti Turpeinen Markkinointikampanjoiden ja -aineistojen työnkulun automatisointi Työn tarkastaja: TkT Uolevi Nikula DI Petri Helin Työn ohjaajat: TkT Uolevi Nikula DI Petri Helin TIIVISTELMÄ Lappeenrannan teknillinen yliopisto School of Business and Management Tietotekniikan koulutusohjelma Antti Turpeinen Markkinointikampanjoiden ja -aineistojen työnkulun automatisointi Diplomityö 2015 72 sivua, 31 kuvaa, 2 taulukkoa, 1 liite Työn tarkastajat: Hakusanat: Keywords: TkT Uolevi Nikula DI Petri Helin digitaalisten aineistojen hallinta, markkinointi, projektinhallinta digital asset management, marketing, project management Markkinointi on liikevoittoa tavoitteleville yrityksille yksi tärkeimmistä asioista. Sen avulla yritykset voivat houkutella asiakkaita ostamaan tuotetta tai/ja palvelua. Jotta yritykset onnistuisivat markkinoinnissa nyt ja jatkossakin, on niiden kehitettävä jatkuvasti markkinointiprosessiaan. Markkinointiprosessit ovat digitalisoituneet tietoyhteiskuntien kehittyessä yhä enenevässä määrin. Markkinointikampanjoihin liittyvien digitaalisten aineistojen määrän kasvaessa niiden hallinta on tullut hankalammaksi. Hallintaongelmien ratkaisuksi on kehitetty tietojärjestelmiä, joiden avulla pystyy hallitsemaan suurempia määriä aineistoja. Tässä diplomityössä tutustutaan markkinointikampanjoiden ja -aineistojen työnkulkuprosessiin. Tapauskohtaisessa työssä tavoitteena oli toteuttaa jo olemassa olevan digitaalisten aineistojenhallintajärjestelmän rinnalle uusi järjestelmä, jonka avulla pyrittiin tehostamaan prosessia. Markkinointikampanjoita varten uuteen järjestelmään tehtiin projektinhallintatoiminnallisuuksia. Markkinointiaineistojen kommentointia ja hyväksyntää varten työssä tutustuttiin kahteen aineistojen kommentointi- ja hyväksyntäjärjestelmään. Ne integroitiin alustavasti osaksi järjestelmää, minkä jälkeen niitä testattiin ja arvioitiin. Paremmin käyttötarkoituksiin sopiva järjestelmä otettiin lopullisesti käyttöön. Tässä diplomityössä raportoiduista tuloksista on hyötyä vastaavien järjestelmien suunnittelussa. ii ABSTRACT Lappeenranta University of Technology School of Business and Management Degree Program in Computer Science Antti Turpeinen Automating workflow of marketing campaigns and digital assets Master's Thesis 72 pages, 31 figures, 2 tables, 1 appendix Examiners: D.Sc. (Tech.) Uolevi Nikula M.Sc. (Tech.) Petri Helin Keywords: digital asset management, marketing, project management Marketing is one of the most important things for organizations which try to make profit. By doing marketing, organizations try to tempt customers to buy their products, ideas or services. To be good at marketing now and in the future, companies need to improve their marketing process continuously. At the Age of Information, the marketing processes have digitized more and even more. Count of digital assets, related to marketing campaign, has increased to such amount that managing them has become more difficult. Management problems have been attempted to solve by using different kind of information systems which enable users to handle more assets more easily. This Master's thesis studies workflow processes of marketing campaigns and marketing assets. Case by case basis the knowledge of processes is used to create a new system alongside the existing digital assets management system, in such a way that process execution becomes more efficient. The new system will contain features which are typical in campaigns and also in project management systems. Thesis will also study two similar software which are designed to manage content review and approval. Those systems are partially integrated to a new system to be able to evaluate them. After evaluation, the better suited software will be finally integrated to be part of the new system. iii SISÄLLYSLUETTELO 1 2 JOHDANTO..................................................................................................................4 1.1 Tausta.....................................................................................................................5 1.2 Tavoitteet ja rajaukset............................................................................................6 1.3 Tutkimusmenetelmät..............................................................................................8 1.4 Työn rakenne..........................................................................................................9 KIRJALLISUUSKATSAUS.......................................................................................11 2.1 Aikaisempi tutkimus............................................................................................11 2.2 Markkinointiprosessit..........................................................................................12 2.2.1 Tehokkuus markkinoinnissa.....................................................................13 2.3 Markkinointikampanjat........................................................................................14 2.3.1 Kampanjan elinkaari................................................................................15 2.3.2 Kampanjan aineiston työnkulku...............................................................16 2.3.3 Kampanjan hallinta ennen kehitysprojektia.............................................17 2.3.4 Markkinointiteknologiat...........................................................................19 2.3.5 Kampanjan aineistonhallinta....................................................................20 3 TYÖNKULKU-MODUULIN TOTEUTUS..............................................................23 3.1 Tekniikoiden valinta.............................................................................................23 3.1.1 .NET Framework.....................................................................................23 3.1.2 Adam........................................................................................................24 3.1.3 Asynchronous JavaScript and XML........................................................26 3.1.4 Model-View-Controller............................................................................27 3.2 Kommentointi- ja hyväksyntäsovellukset............................................................28 3.2.1 ProofHQ...................................................................................................29 3.2.2 ConceptShare...........................................................................................30 3.3 Ohjelmistokehitys................................................................................................32 3.3.1 Käyttötapaukset........................................................................................34 3.3.2 Ympäristökuvaus.....................................................................................37 3.3.3 Integraatio................................................................................................38 1 3.4 Käyttöliittymä......................................................................................................38 3.4.1 Päänäkymä...............................................................................................39 3.4.2 Kalenterinäkymä......................................................................................41 3.4.3 Jäsennäkymä............................................................................................42 3.4.4 Sisältönäkymä..........................................................................................43 3.4.5 Tehtävänäkymä........................................................................................45 3.4.6 Keskustelunäkymä...................................................................................45 4 5 TULOKSET JA POHDINTA.....................................................................................47 4.1 ProofHQ ja ConceptShare vertailu......................................................................47 4.2 Mittarointi............................................................................................................49 4.3 Asiakastyytyväisyys.............................................................................................52 YHTEENVETO...........................................................................................................60 LÄHTEET...........................................................................................................................62 LIITTEET LIITE 1: Tyytyväisyyskyselyn lomake 2 SYMBOLI- JA LYHENNELUETTELO AJAX Asynchronous JavaScript And XML AMA American Marketing Association AMS Asset Management System API Application Programming Interface BOM Browser Object Model CMS Content Management System CSS Cascading Style Sheets COM Creative Operations Management DAM Digital Asset Management DMS Document Management System DOM Document Object Model ECM Enterprise Campaign Management EMM Enterprise Marketing Management HTML HyperText Markup Language HTTP HyperText Transfer Protocol JSON JavaScript Object Notation LUT Lappeenranta University of Technology MAM Media Asset Management MEP Marketing Execution Platform MOM Marketing Operations Management MVC Model View Controller OMG Object Management Group™ PDF Portable Document Format REST REpresentional State Transfer SWOT Strengths, Weaknesses, Opportunities, Threats UML Unified Modeling Language UI User Interface UX User Experience Design WCM Web Content Management XML Extensible Markup Language 3 1 JOHDANTO Historiallisesti katsottuna markkinointi alkoi kehittyä vasta viime vuosisadalla. Erityisesti Internetin ja digitaalisten teknologioiden kehitys on mahdollistanut tekemään perinteisiä asioita uusin menetelmin, sen lisäksi teknologiat ovat mahdollistaneet tekemään täysin uusia asioita. Kehityksien myötä esim. geologisen sijainnin asettamat rajoitukset ovat vähentyneet ja siten markkinoinnista on tullut yhä globaalimpaa [1]. Globaali ympäristö ja teknologiat ovat synnyttäneet sosiaalisia medioita, jotka puolestaan ovat muokanneet entisestään tapoja tehdä markkinointia. Teknologiat ovat mahdollistaneet monien manuaalisten prosessien automatisoinnin. Onnistuessaan automaation uskotaan esim. parantavan toistettavuutta, kasvattavan tuotantokapasiteettia, vähentäen työvoiman tarvetta, inhimillisten virheiden määrää ja kustannuksia. Frenkelin tekemän tutkimuksen mukaan jopa 98% tietojohtajista kertoi liiketoiminnan automatisoinnin johtavan liiketoiminnallisiin hyötyihin, mutta toisaalta vain 68% kertoi automaation vähentäneen kuluja ja 59% kertoi tuottavuuden parantuneen [2]. Tässä diplomityössä tutkitaan tapauskohtaisesti miten markkinointikampanjoiden ja niiden aineistojen hallintaan tietokoneellisesti. liittyviä Työssä prosesseja suunnitellaan ja voitaisiin helpottaa toteutetaan ja automatisoida yrityksen A kehittämään järjestelmään sellaiset toiminnallisuudet, joiden avulla kyseisen järjestelmän käyttäjät voivat hallita markkinointikampanjoita ja -aineistoja entistä tehokkaammin. Työssä arvioidaan keskenään kahta aineistojen kommentointiin ja hyväksyntään tarkoitettua sovellusta. Molemmille sovelluksille toteutetaan yhtenäinen rajapinta, jotta vastaavien sovelluksien integrointi osaksi järjestelmää olisi mahdollista vähin muutoksin. Sovellusten arviointia varten molemmat sovellukset integroidaan alustavasti osaksi järjestelmää. Lopulliseen käyttöön otetaan vain paremmin käyttötarkoituksiin soveltuva sovellus. Vaikkakin markkinointitoiminnallisuudet ja integraatiot tehdään tapauskohtaisesti yksittäisen järjestelmän päälle, on työn tuloksista silti hyötyä myös muiden vastaavien järjestelmien kehittämisessä. 4 1.1 TAUSTA Diplomityö tehdään yritykselle A. Diplomityön aihe on lähtöisin yrityksen A ja sen asiakasyritysten tarpeista. Edellä mainituilla yrityksillä on markkinointikampanjoita ja niihin liittyviä aineistoja. Asiakasyritykset ovat pystyneet hyödyntämään aineistojensa hallinnassa yrityksen A kehittämää verkkosovellusta. Kuvassa 1 on esitetty kuvakaappaus kyseisen sovelluksen ”Media”-nimisestä moduulista, joka mahdollistaa esim. aineistojen säilytyksen, kategorisoimisen ja jakamisen Internetin välityksellä. Kuvakaappauksen vasemmassa laidassa on puunäkymä aineistojen luokitteluista. Puunäkymä vastaa tiedostojärjestelmille tyypillistä hakemistopuuta, mutta hakemistojen sijasta käytetään klassifikaatioita. Klassifikaatiot poikkeavat tiedostojärjestelmille tyypillisistä hakemistoista eli kansioista siten, että ne näyttävät myös alempien kansioiden sisällön. Vastaavasti aineistot poikkeavat tiedostoista siten, että ne voivat olla jaetusti useamman eri klassifikaation sisällä. Puunäkymän oikealle puolelle on piirretty aineistonäkymä, jossa esitetään puunäkymästä valitun klassifikaation alaiset aineistot esikatselukuvina. Kuva 1. Kuvakaappaus ”Media”-moduulista. 5 Yrityksen A kehittämän verkkosovelluksen toiminnallisuudet eivät ole olleet täysin riittäviä markkinointikampanjoiden ja -aineistojen hallintaan. Erityisesti ongelmia on aiheuttanut vedoksien eli kehitysvaiheessa olevien aineistojen kommentointi, hyväksyntä ja versiointi. Jotkin asiakasyritykset olivat käyttäneet vedoksien kommentointiin ja hyväksyntään kolmannen osapuolen ohjelmistoja, joiden käyttö edellä mainitun verkkosovelluksen kanssa ei ole ollut sulavaa. Esim. vedoksien siirtämiset ja kopioimiset eri ohjelmistojen välillä piti tehdä manuaalisesti. Vedoksia ja niiden eri versioita oli lähetetty sähköpostitse muille kommentoitaviksi. Kommentoiminen sähköpostitse oli ollut hankalaa ja toisinaan keskustelu oli paisunut lähes hallitsemattomiksi. Sen lisäksi sähköpostit olivat täyttyneet eri vedoksista. Kaikkia vedoksia ei oltu voitu edes lähettää sähköpostitse johtuen joidenkin sähköpostipalvelimien liitetiedostojen kokorajoituksista. Sähköpostien täyttymiset ja kokorajoitukset oli voinut kiertää jakamalla linkin Media-moduulissa olevaan aineistoon. Kaikilla käyttäjillä ei kuitenkaan ollut riittäviä käyttöoikeuksia Media-moduuliin. Eli aineistojen jakaminen Media-moduulin kautta ei ollut mahdollista jokaiselle käyttäjälle. Koska kommentointi ja hyväksyntä tapahtui muualla, siitä ei jäänyt tietoa yrityksen A kehittämään verkkosovellukseen. Yrityksen A kehittämän verkkosovelluksen moduulit eivät myöskään olleet sisältäneet markkinointikampanjoiden hallintaan liittyviä toiminnallisuuksia, joten asiakasyritysten oli täytynyt hallita kampanjoita ohjelmiston ulkopuolella. Aineistojen linkittäminen kampanjoihin ja keskusteluihin oli ollut hankalaa. Ylipäätänsä kampanjoiden hallitseminen oli ollut epämääräistä ja kommunikointi oli tuottanut ongelmia. Kommunikointia ei myöskään aina tehdä pelkästään yrityksen sisäisesti, koska kampanjoihin kuuluu usein myös ulkopuolisia yrityksiä tai henkilöitä. Markkinointikampanjoihin liittyvää kommunikointia hoidettiin pääasiassa esim. palavereiden, erinäisten sähköpostiviestien, puheluiden ja pikaviestiohjelmien avulla. 1.2 TAVOITTEET JA RAJAUKSET Työn päätavoitteena on suunnitella ja toteuttaa yrityksen A verkkosovellukseen uusi ”Työnkulku”-niminen moduuli, eli itsenäinen ohjelmisto-osa. Moduulin tavoitteena on 6 avustaa asiakasyrityksiä hallitsemaan heidän omia markkinointikampanjoita ja -aineistoja helpommin ja tehokkaammin. suunnittelemalla käyttöliittymä puolestaan pyritään automatisoimalla saamaan Helppokäyttöisyyttä pyritään yksinkertaiseksi suoraviivaiseksi. aikaiseksi manuaalisesti tehtäviä ja integroimalla prosesseja saamaan ulkopuolisia ja aikaiseksi Tehokkuutta järjestelmiä, toteuttamalla uusia toiminnallisuuksia. Diplomityössä tutustutaan markkinointikampanjoiden ja eri sovelluksien välisiin prosesseihin ja työnkulkuihin, jotta edellä mainituissa tavoitteissa onnistuttaisiin. Integrointia varten työssä tutustutaan tarkemmin kahteen sovellukseen, jotka on kehitetty aineistojen kommentointia ja hyväksyntää varten. Näitä sovelluksia pyritään vertailemaan keskenään ja alustavasti ne integroidaan osaksi Työnkulku-moduulia. Tavoitteena on siis myös luoda tietoa integroinnista. Toteutettavan moduulin päätavoitteena on ohjata kampanjoihin ja aineistoihin liittyvät epämääräiset ja ulkopuoliset kommunikoinnit koostetusti moduulin sisälle. Pääasiassa diplomityö keskittyy tutkimaan miten markkinointikampanjoita hallitaan ja miten niihin liittyviä aineistoja voidaan jakaa, kommentoida ja hyväksyä. Tutkimuksen tavoitteena on vastata seuraaviin kysymyksiin: 1. Miten markkinointikampanjoiden hallitsemista voidaan automatisoida? 2. Onko markkinointikampanjoiden automatisoinnista hyötyä? 3. Miten valita aineistojen kommentointi- ja hyväksyntäjärjestelmä? 4. Miten voisi toteuttaa aineistonhallintajärjestelmään markkinointiaineistojen luontia ja käsittelyä ja luontia tukevat toiminnallisuudet? Diplomityössä ei tutkita esim. seuraavia asioita: 1. Millainen aineisto on markkinoinnin kannalta hyvää, 2. markkinointikampanjoiden ja aineistojen taloudellisia kuluja, 3. sähköpostimarkkinointia, 4. sosiaalisen median hyödyntämistä markkinointikampanjoissa. 7 1.3 TUTKIMUSMENETELMÄT Diplomityön tutkimuskohteena on verkkosovelluksen uusien toiminnallisuuksien suunnittelu ja kehittäminen. Tutkimusstrategiana käytetään tapaus-, toiminta- ja kyselytutkimusmenetelmiä. Tapaus- ja toimintatutkimusmenetelmät ovat hyvin lähellä toisiaan [3]. Toimintatutkimusmenetelmissä työn tarkoituksena on vaikuttaa tutkimuskohteeseen, sen toimintaan ja ympäristöön [4]. Tapaustutkimukselle on ominaista yksityiskohtaisen tiedon tuottaminen tutkimuskohteesta tai -kohteista. Tutkimuksessa yleisesti puhutaan tapauksista (case), joilla viitataan tutkimuskohteisiin. Tapaustutkimusta voi toteuttaa monen eri analyysimenetelmän avulla [5]. Kyselytutkimuksen (survey) tavoitteena on koota tietoa tutkimuskohteesta kysely- ja haastattelumenetelmillä. Kyselyt ja haastattelut pyritään tekemään satunnaisotannalla mahdollisimman isolle osaa perusjoukkoa. Kyselyn tulokset usein yleistetään koko perusjoukolle [6]. Tässä diplomityössä kyselyillä on tarkoitus selvittää miten moduulia tulisi kehittää eteenpäin ja mistä ominaisuuksista on hyötyä. Toimintatutkimusmenetelmän työnkulkua on havainnollistettu kuvassa 2. Kyseinen menetelmä soveltuu hyvin tutkimustöille, joiden tarkoituksena on kehittää nykyistä tilannetta ja saada siitä tutkimustuloksia [7]. Aluksi menetelmässä asetetaan tutkimuksen tavoitteet ja tämän jälkeen tehdään toimintasuunnitelmat tavoitteiden saavuttamista varten. Kun toiminnan suunnittelu on valmis, pyritään toteuttamaan toimintaa suunnitelmien mukaisesti. Kun toiminnan toteutus on saatu valmiiksi, aletaan arvioimaan toteutusta asetettuihin tavoitteisiin nähden. Arvioinnista syntyy tutkimustuloksia. Jos tulokset ovat riittäviä tutkimukselle asetettuihin tavoitteisiin nähden, voidaan lopettaa tutkimusprosessi siirtymällä ”päätös”-vaiheeseen. Tarvittaessa tutkimustuloksia voi kerätä lisää siirtymällä takaisin ”toiminnan suunnittelu”-vaiheeseen suunnittelemaan toiminnallisuutta paremmin tietämyksin. 8 Kuva 2. Toimintatutkimusprosessin työnkulku vuokaaviona. [8] Tämän diplomityön kannalta katsottuna ”toiminnan suunnittelu” -vaiheessa kartoitettiin asiakkaiden vaatimukset ja asetettiin mittarit arviointia varten. Suunnittelua varten tutustutaan pikaisesti myös kolmannen osapuolen sovelluksiin, joita työssä hyödynnetään. ”Toiminnan toteutus” -vaiheessa tehdään sovellus, joka pyrkii toteuttamaan asetetut tavoitteet. Toteutuksen jälkeen arvioidaan sovelluksen toimivuutta asetettuihin tavoitteisiin nähden. Jos tavoitteita ei ole saavutettu, siirrytään takaisin ”toiminnan suunnittelu” -vaiheeseen. Kun haluttuihin tavoitteisiin on päästy, annetaan sovellus asiakkaille testattavaksi. Asiakkailta saatujen palautteiden avulla siirrytään vielä uudestaan ”toiminnan suunnittelu” -vaiheeseen ja kehitetään sovellusta lisää. Lopuksi tutkimustulokset raportoidaan tässä diplomityössä. Diplomityölle ei asetettu työn alussa tarkkaa aikataulua, eikä se olisi oikein ollut mahdollistakaan johtuen tutkimustyön kohteesta. Diplomityölle asetettu työosuus oli huomattavan suuri, jonka tavoitteiden saavuttamiseen meni loppujen lopuksi lähes kaksi vuotta lähes täysipäiväisenä työskentelynä. 1.4 TYÖN RAKENNE Ensimmäinen luku, ”Johdanto” antaa lukijalle yleiskuvan diplomityön aiheesta ja sen taustoista. Lisäksi luvussa kerrotaan työn tutkimusmenetelmistä, tavoitteista ja rajauksista. Toinen luku, ”Kirjallisuuskatsaus” käsittelee aiheeseen liittyvää kirjallisuutta ja tutkimuksia. Luvussa esitetään asiakasyritysten kampanjoiden ja aineistojen hallintaan liittyviä markkinointiprosesseja, joita pyritään automatisoimaan. Kolmas luku, ”Työnkulku-moduulin toteutus” kertoo tekniikoista ja menetelmistä, joilla työ tullaan toteuttamaan. Luvussa kerrotaan myös integroinnin toteutuksen tuloksista ja Työnkulkumoduuliin toteutetusta käyttöliittymästä. Neljäs luku, ”Tulokset ja pohdinta” kertoo ja 9 pohtii ohjelmistolle asetettujen tavoitteiden saavutuksista ja asiakastyytyväisyyskyselyn tuloksista. Viimeinen luku, ”Yhteenveto” lopputulokset. 10 käy läpi diplomityön keskeisimmät 2 KIRJALLISUUSKATSAUS 2.1 AIKAISEMPI TUTKIMUS Yleisesti katsoen markkinointia on tutkittu laajasti, mutta silti diplomityön aiheeseen suoranaisesti liittyviä tutkimuksia ei löytynyt. Markkinointikampanjoita on pääasiassa tutkittu teoreettisella tasolla, eikä tutkimuksissa ole juurikaan otettu kantaa ohjelmistollisiin ratkaisuihin. Tässä diplomityössä puolestaan keskitytään erityisesti markkinointikampanjoiden ja aineistojen hallintaan ohjelmistollisesti. Kattavia tutkimuksia digitaalisen markkinoinnin aineistojen kommentointiin ja hyväksyntään tehdyistä digitaalisista hyötyohjelmistoista ei löytynyt. Markkinointiaineistojen kommentointia ja hyväksyntää varten diplomityössä tutkittiin ConceptShare ja ProofHQ -nimisiä järjestelmiä. Kyseisistä järjestelmistä löytyi niukasti tutkimuksia, eikä niitä vertailtu missään tutkimuksessa keskenään – ainakaan niitä ei löytynyt ”ConceptShare” ja ”ProofHQ” -hakusanoilla. ConceptSharesta löytyi vain yksi aikaisempi tutkimus: • Underwoor vertaili yhteistyösovelluksia, jossa mukana oli seuraavat ohjelmistot: Nuospace, Daptiv Project Porfolio Management, Huddle, LiquidPlanner ja WebEx WebOfficen. Kyseissä vertailussa jokaisella ohjelmistolla oli parhaat puolensa, ConceptShare todettiin parhaaksi vaihtoehdoksi graafisten aineistojen tuottamiseen yhteistyöllä. [9] ProofHQ:sta löytyi kaksi tutkimusta, joissa arvioitiin kuinka paljon ProofHQ tehostaa vedosten kommentointia ja hyväksyntää: • Noosh -niminen yritys toteutti ProofHQ-järjestelmän integroimisen yrityksen webpohjaiseen projektien ja hankintojen hallintaohjelmistoon. Nooshin tutkimusten mukaan integraatio auttoi heidän asiakkaitaan saavuttamaan kustannussäästöjä yli 20 prosenttia parantaen tehokkuutta, yhteistyötä ja avoimuutta. Integraatio nopeutti sisällön arviointia ja hyväksyntää 56 %. [10] 11 • ProofHQ:n yhteistyökumppani CtrlPublishing toteutti Adobe Creative Suite ohjelmistoihin ProofHQ-integraation, joka teki mahdolliseksi aineistojen lähettämisen suoraan ProofHQ-järjestelmään jaettavaksi, arvosteltavaksi ja hyväksyttäväksi kaikille sidosryhmille. IntelliLinkin mukaan integraatio ansiosta projektien toimitusaika nopeutui 56 %, korjaus/tarkistuskierroksia tarvitsi 29 % vähemmän sekä aineistojen arvioinnin hallitsemiseen kuluva aika väheni 59 %. [11,12] Edellä mainittujen tutkimusten perusteella ProofHQ ja ConceptShare vaikuttavat lupaavilta ohjelmistoilta vedosten kommentointiin. 2.2 MARKKINOINTIPROSESSIT Alkujaan markkinointi terminä tarkoitti ”käydä markkinoilla”, eli käydä paikassa, jossa ostajat ja myyjät kohtaavat. Markkinointi (engl. marketing) -termiä alettiin käyttämään Amerikassa 1900-luvun alussa ja markkinointia alettiin opettamaan 1920-luvulla [13]. Markkinointi voidaan määritellä monin eri tavoin, esim. Heidi Cohen on listannut 72 markkinoinnin määritelmää sivuillensa [14]. AMA (American Marketing Association) määrittelee markkinoinnin seuraavasti: ”Marketing is the activity, set of institutions, and processes for creating, communicating, delivering, and exchanging offerings that have value for customers, clients, partners, and society at large” [15]. Bergström ja Leppänen puolestaan määrittelevät markkinoinnin näin: ”Markkinointi on vastuullinen, suhdeajatteluun pohjautuva ajattelu- ja toimintatapa, jonka avulla luodaan myyvä, kilpailukykyinen ja eri osapuolille arvoa tuottava tarjooma vuorovaikutteisesti viestien” [16]. Liiketoiminnassa tarjooma termillä [17] tarkoitetaan yrityksen valikoimaa tuotteista, palveluista ja ideoista, joita se tarjoaa asiakkaille. Timo Rope ja Maarit Rope puolestaan kertovat ytimekkäästi seuraavaa: ”Markkinointi on markkinoiden tuottamien mahdollisuuksien maksimaalista hyödyntämistä yrityksen toiminnassa kaikin käytettävissä olevin keinoin” [18]. Markkinointi on liikevoittoa tavoitteleville yrityksille yksi tärkeimmistä asioista. Sen avulla yritykset voivat houkutella asiakkaita ostamaan tuotetta tai palvelua. Jotta yritykset onnistuisivat markkinoinnissa nyt ja jatkossakin, on niiden kehitettävä jatkuvasti 12 markkinointiprosessiaan [19]. Kuvassa 3 on havainnollistettu markkinointiprosessia ja sen eri vaiheita. Ensin määritellään projekti ja sen kuvaus, ellei niitä ole jo määritelty. Tämän jälkeen kartoitetaan nykyiset markkinat ja sitten tehdään SWOT (Strengths, Weaknesses, Opportunities, Threats) -analyysi, jossa selvitetään projektin vahvuudet, heikkoudet, mahdollisuudet ja uhat. ”Analyysin pohjalta voidaan tehdä päätelmiä, miten vahvuuksia voidaan käyttää hyväksi, miten heikkoudet muutetaan vahvuuksiksi, miten tulevaisuuden mahdollisuuksia hyödynnetään ja miten uhat vältetään. Tuloksena saadaan toimintasuunnitelma siitä, mitä millekin asialle pitää tehdä” [20]. Tämän jälkeen määritetään markkinointikohde ja sitten asetetaan tavoitteet ja päämäärät. Tavoitteita varten suunnitellaan markkinointistrategia. Toimintasuunnitelmavaiheessa laaditaan toteutus menetelmät ja suunnitelmat. Toteutus vaiheessa toteutetaan suunnitelmaa ja suoritetaan projektiin liittyvät markkinointikampanjat. Suorituksen aikana tehdään mittausta ja lopuksi tehdään arviointi onnistumisista. [21] Kuva 3. Markkinointiprosessin elinkaaren vaiheet [21] 2.2.1 Tehokkuus markkinoinnissa Tehokkuutta (efficiency) voi mitata monin eri tavoin. Käsitteenä tehokkuus saatetaan toisinaan sekoittaa sen alikäsitteisiin vaikuttavuuteen (effectiveness) tai tuottavuuteen 13 (productivity). Tuotannollisesti katsottuna tuotteen tai palvelun tuottavuus voi olla suuri, mutta toiminta ei ole tehokasta, jos tuotetta ei mene kaupaksi. Vastaavasti toiminta voi olla vaikuttavaa, jos tuotetta tai palvelua menee paljon kaupaksi. Prosessi ei kuitenkaan ole tehokas, jos myyntitulot eivät kata tuottamiskustannuksia. Yleisesti ottaen prosessi on tehokas, jos sen tuottavuus ja vaikuttavuus ovat molemmat hyviä. [22] Markkinointistrategiat voivat olla tehokkaita, mutta silti niiden hyötysuhde voi olla erittäin huono. Markkinointistrategia on tehokas, kun se saavuttaa asetetut tavoitteet. Markkinointiprosessi on tehokas, kun tavoitteet saavutetaan mahdollisimman vähin resurssein. ”Doing the right things (effectiveness) and doing things right (efficiency)” – Peter Drucker, Management expert 1966 [1]. Diplomityön kannalta katsottuna työssä ei kiinnitetä juurikaan huomiota oikeiden asioiden tekemiseen vaan pelkästään siihen, että miten asiat tehdään oikein markkinointikampanjaprosesseissa. Eli Työnkulku-moduulin tavoitteena on yrittää tehostaa markkinointikampanjan prosesseja siten, että asiat tehtäisiin nopeammin ja vähemmin resurssein kuin aikaisemmin. Tähän tavoitteeseen pyritään pääasiassa prosessien automatisoinnin avulla. Se vähentää manuaalisesti tehtäviä asioita ja siten nopeuttaa prosessia, sekä mahdollisesti myös vähentää inhimillisten virheiden määrää. 2.3 MARKKINOINTIKAMPANJAT Markkinointikampanjat ovat tärkeä osa markkinointia ja monille yritykselle ne ovatkin yksi tärkeimmistä tavoista lisätä asiakkaiden tietämystä yrityksen liiketoiminnasta, tuotteista, palveluista ja ideoista. Kampanjoiden hallinta on markkinointitaktiikoiden ja -ohjelmien sarjoja, jotka on suunniteltu saavuttamaan määritetty liiketoiminnallinen tavoite [23]. Diplomityöhön liittyvien asiakasyritysten markkinointikampanjat ovat usein luonteeltaan lyhytkestoisia projekteja, jotka kestävät yleensä noin parista viikosta pariin kuukauteen. Jotkin kampanjat ovat luonteeltaan toistuvia ja saattavat toistua uudestaan tietyin väliajoin. Asiakasyrityksille on markkinointikampanjoiden kokonaisuus. 14 tärkeätä pystyä hahmottamaan 2.3.1 Kampanjan elinkaari Markkinointikampanja voidaan jakaa eri vaiheisiin. Kuvassa 4 on hahmoteltu markkinointikampanjan elinkaarta, joka on jaettu kuuteen eri vaiheeseen. Markkinointikampanjan ensimmäisessä vaiheessa päätetään kohde, jolle idean, tuotteen tai/ja palvelun markkinointia kohdistetaan. Toisessa vaiheessa suunnitellaan mahdollisia aineistoja kampanjaa varten. Kolmannessa vaiheessa tehdään aikataulutus ja jaetaan tehtäviä tekijöiden kesken. Seuraavassa vaiheessa tehdään aineistot ja arvioidaan niitä, jonka jälkeen ne hyväksytään tai hylätään. Kun aineistot on saatu valmiiksi, ne julkaistaan ja jaetaan eteenpäin. Julkaisun jälkeen kerätään tietoa siitä, että onko tuotteen tai palvelun kysyntä noussut kampanjan johdosta. Myöhemmin sama kampanja voidaan aloittaa uudestaan, jolloin voidaan hyödyntää aikaisempien kampanjoiden tuloksia. Kuva 4. Markkinointikampanjan elinkaari. (Kuvan idea Alexandra Gibsonilta [24]) Kampanjapäälliköllä on erittäin tärkeä rooli markkinointikampanjoissa. Päällikön tehtävänä on ohjata kampanjaa alusta loppuun asti. Tehtäviin kuuluu esim. kampanjan suunnittelu, aikatauluttaminen, tehtävien jakaminen muille kampanjan jäsenille, aineistojen kommentointi ja hyväksyttäminen, kampanjan tiedottaminen, aineistojen julkaiseminen, tulosten analysoiminen ja raportointi [25]. Erityisen tärkeätä on tehdä toimintaohjeet 15 muille ja myös kertoa kampanjan tavoitteista, jotta muut tietävät mitä pitää tehdä ja mitä varten. Toimintaohjeiden pohja voidaan usein kopioida aikaisemmasta vastaavasta kampanjasta. 2.3.2 Kampanjan aineiston työnkulku Markkinointikampanjaan voi osallistua monia henkilöitä, joista jokaisella on usein oma tehtävänsä. Useimmiten henkilöt voidaan jakaa rooleittain muutamaan eri ryhmään. Kuvassa 5 kampanjaan osallistuvat henkilöt on jaettu neljään eri ryhmään ja siinä on kuvattu aineiston kommentointi- ja hyväksyntätyönkulkua eri henkilöryhmien välillä. ”Johtajat”-ryhmään kuuluvat esim. projekti- ja markkinointipäälliköt, jotka ohjaavat muiden henkilöiden tekemisiä. ”Tekijät”-ryhmään kuuluvat henkilöt, jotka tekevät vedoksia ja niiden uusia versioita. ”Hyväksyjät”-ryhmään kuuluvat henkilöt, joiden annetaan päättää siitä, että onko vedos hyväksytty vai ei. ”Tarkastajat”-ryhmään kuuluvat henkilöt, joilta halutaan palautetta ja kommentteja aineistoista. Kuvassa suorakulmioilla kuvataan toimintoja ja suunnikkailla toiminnoista syntyneitä tuloksia. Kuvasta voi todeta, että kommunikaatio on tärkeä osa työnkulkua. 16 Kuva 5. Hahmotelma kampanjan työnkulusta tekijöittäin. 2.3.3 Kampanjan hallinta ennen kehitysprojektia Moni asiakasyrityksistä käytti jo entuudestaan kolmannen osapuolen ohjelmistoja hallitsemaan markkinointikampanjoitaan. Osa asiakasyrityksistä käytti kolmannen osapuolen sovelluksena ProofHQ:ta tai BaseCamp:iä. Joillakin asiakkailla oli käytössä molempien sovelluksien integraatio. Asiakasyritykset kuitenkin totesivat, ettei Basecamp soveltunut satojen, ellei jopa tuhansien markkinointikampanjoiden hallintaan. Erityisesti moitittiin projektilistanäkymää, joka ei sellaisenaan soveltunut käyttötarkoituksiin. ProofHQ:ssa puolestaan koettiin hankalaksi käyttäjien hallitseminen, koska siinä jokaisella vedoksella oli omat käyttäjät, eikä eri vedoksien käyttäjiä voinut hallita yhtäaikaisesti. ProofHQ-verkkosovelluksesta kerrotaan enemmän luvussa 3.2.1. Basecamp on projektinhallintaohjelmisto, joka toimii verkkoselaimessa. Basecamp sisältää kalenterinäkymän, josta käyttäjät näkevät projekteihin ja tehtäviin liittyviä aikatauluja. Basecampin käyttäjät voivat kommunikoida toisilleen projektikohtaisesti käyttäen Basecampin sisäänrakennettua keskustelujärjestelmää. Käyttäjät voivat tuoda järjestelmän 17 ulkopuolelta tiedostoja ja liittää niitä keskusteluissa oleviin viesteihin liitetiedostoina. Basecampin sisällä käyttäjät voivat myös luoda yksinkertaisia verkkopohjaisia tekstidokumentteja. [26] Alempaan kuvaan 6 on hahmoteltu ProofHQ ja Basecamp sovelluksia hyödyntävien asiakasyritysten pelkistettyä prosessinkulkua eri sovellusten välillä. Käyttäjän kannalta epämiellyttävää kyseisessä prosessissa oli se, että käyttäjällä tarvitsi olla kirjautumistunnukset ainakin kolmeen eri järjestelmään. Sen lisäksi aineistojen siirtäminen ja linkittäminen eri järjestelmien välillä piti tehdä manuaalisesti. Käyttäjien piti opetella ”Media”-moduulin lisäksi kahden muun järjestelmän käyttäminen, jotta he pystyivät hallitsemaan kampanjoita. Käyttäjien ylläpitäminen aiheutti paljon vaivaa. 18 Kuva 6. Aineistoon liittyvän prosessin kulku eri ohjelmistojen välillä aikaisemmin. 2.3.4 Markkinointiteknologiat Real Story Group on hahmotellut kuvaan 7 markkinointiteknologiaan liittyviä myyjiä ja järjestelmiä metrokarttamaisesti [27]. Järjestelmät ja myyjät on luokiteltu yhdeksään eri kategoriaan, jotka on piirretty metrokarttaan eri raiteina. Järjestelmät ja myyjät on sijoitettu metrokartan raiteille siten, että ne ovat mahdollisimman lähellä toisia vastaavanlaisia järjestelmiä/myyjiä. Real Story Group on pyrkinyt listaamaan karttaan vain merkittävimmät tekijät, mutta tekijöiden ja järjestelmien sijainnit ovat tulkinnanvaraisia. Kartta kuitenkin helpottaa ymmärtämään sen, että markkinointia tukevia järjestelmiä on 19 todella paljon. Yrityksen A kehittämä verkkosovellus hyödyntää ohjelmiston taustalla Adam Softwaren kehittämää teknologiaa, joka löytyy suunnilleen metrokartan keskiosasta [27]. Kuva 7. Hahmotelma digitaalisista työpaikoista ja teknologiamarkkinointimyyjistä. [27] 2.3.5 Kampanjan aineistonhallinta Markkinointikampanjan aineistoja voi hallita monilla erilaisilla järjestelmillä, kuten esim. CMS (Content Management Systems), DAM (Digital Asset Management), DMS (Document Management System), MAM (Media Asset Management), WCM (Web Content Management) -järjestelmillä. Ne kaikki on luotu sisällön hallitsemista varten, mutta ne käsittelevät erilaista sisältöä eri tavoin. Niillä on siis omat vahvuutensa ja heikkoutensa sisällöstä ja lähestymistavasta riippuen. 20 Monet WCM (Web Content Management) -järjestelmät väittävät virheellisesti itseään CMS-järjestelmiksi, vaikkeivät ne sisälläkään kaikkia CMS-järjestelmälle ominaisia toiminnallisuuksia. WCM on osakokonaisuus CMS-järjestelmästä, joka mahdollistaa sisällön hallitsemisen verkkoympäristössä [28]. WCM-järjestelmien päätehtävänä on mahdollistaa aineiston julkaiseminen Internetissä ilman teknistä osaamista [29]. CMSjärjestelmissä tekstuaalinen sisältö luodaan usein järjestelmän käyttöliittymää käyttäen, kun taas DMS-järjestelmissä tekstuaalinen sisältö tuodaan usein muualta. DMS onkin tarkoitettu dokumenttien keskitettyyn tallentamiseen. [30] MAM (Media Asset Management) -järjestelmät on kehitetty alun perin pääasiassa televisio- ja elokuvateollisuutta varten. Alkuperäinen toiminnallisuus oli keskittynyt aineistojen tallentamiseen ja arkistointiin ja myöhemmin myös levittämiseen. Pääasiassa aineistoina ovat olleet digitaaliset videot, joiden tiedostokoot voivat olla suuria. Tyypillisiä MAM-järjestelmän käyttäjät ovat esim. radio- ja televisiolähetysten toimittajat, ohjelmien tuottajat, urheiluverkostot, valtiolliset edustustoimistot ja uskonnolliset instituutiot. [31] DAM (Digital Asset Management) on luotu digitaalisten aineistojen hallintaan. CMS on puolestaan sisällönhallintajärjestelmä, joka on luotu sisällön hallitsemista varten. DAM ja CMS ovat hyvin lähellä toisiaan, mutta niillä on kuitenkin omat eronsa. CMS keskittyy tasapuolisesti kaikenlaisen sisällön hallitsemiseen, kun puolestaan DAM keskittyy pääasiassa kuvien, videoiden ja äänien hallitsemiseen. DAM järjestelmälle on ominaista myös se, että ne pystyvät muuntamaan aineistoja toisiin tiedostomuotoihin ja kuvakokoihin. [29] Toisinaan vastaavia järjestelmiä nimetään AMS (Asset Management System) nimellä. Kyseiset järjestelmät mahdollistavat tiedostojen jakamisen, muokkaamisen, versioinnin ja työnkulkua ohjaavan toiminnallisuuden. Kaupallisia tuotteita ovat esim. Alienbrain [32] ja TACTIC [33], jotka on erityisesti kehitetty kolmiulotteisten mallien suunnittelua varten. [34] Yrityksen A kehittämä verkkosovellus koostuu monista eri moduuleista, jotka yhdessä pyrkivät muodostamaan EMM (Enterprise Marketing Management)-järjestelmän, eli 21 verkkosovellus pyrkii hallitsemaan täysivaltaisesti markkinointiprosesseja [35]. Verkkosovelluksen tärkein moduuli on asiakkaiden kannalta ”Media”-moduuli, joka toteuttaa DAM toiminnallisuudet. Kuten jo aikaisemmissa luvuissa todettiin, DAM ei sellaisenaan riitä, vaan verkkosovellus tarvitsee uuden moduulin, Työnkulku-moduulin. Työnkulku moduuli pyrkii hallitsemaan markkinointikampanjoita ja niiden aineistoja. 22 3 TYÖNKULKU-MODUULIN TOTEUTUS Tässä luvussa kerrotaan mitä tekniikoita työnkulku-moduulissa käytettiin hyväksi ja millaiseen ympäristöön moduuli kehitettiin. Lisäksi luvussa kerrotaan miten Työnkulkumoduulia lähdettiin kehittämään ja mitä muita sovelluksia siihen päätettiin integroida. 3.1 TEKNIIKOIDEN VALINTA Uusi moduuli tehtiin järjestelmän päälle, jonka kehityksessä oli käytetty Microsoftin tarjoamia kehitystyökaluja ja -ympäristöjä. Ohjelmiston alustan taustaosana (Back-End) oli käytetty Adam Softwaren kehittämiä tekniikoita. Järjestelmän toteutustekniikoista johtuen myös tässä työssä hyödynnettiin pääasiassa Microsoftin ja Adam Softwaren tekniikoita. 3.1.1 .NET Framework .NET Framework on Microsoftin kehittämä ohjelmistokomponenttikirjasto, joka koostuu kahdesta osasta: luokkakirjastoista ja ajoympäristöstä eli CLR:stä (Common Language Runtime) [36]. .NET Frameworkista on kehitetty myös avoimen lähdekoodin versioita, kuten Mono [37] ja DotGNU Portable.NET [38]. Monoa käyttäen on mahdollista tehdä .NET ohjelmistoja eri käyttöjärjestelmille. Mono ei kuitenkaan ole täysin yhteensopiva Microsoftin .NET Frameworkin kanssa [39], eli samat lähdekoodit eivät välttämättä käänny suoraan eri ympäristöissä. DotGNU Portable.NET on puolestaan huomattavasti keskeneräisempi toteutus .NET:stä. CLI (Common Language Infrastructure) on Microsoftin kehittämä avoin spesifikaatio, joka on standardisoitu ISO (International Organization for Standardization) ja ECMAorganisaatioiden (European Computer Manufacturers Association) toimesta [40,41,42,43]. Spesifikaatio määrittää CIL-välivaihekoodin (Common Intermediate Language) ja sen ajonaikaiseen suorittamiseen liittyvän CLR-virtuaalikoneen, joka kääntää CIL-lähdekoodin koneen ymmärrettävään muotoon suorittaakseen sen [40]. Korkeamman tason kielet käännetään siis ensin CIL-kieleksi. CIL on pino- (stack-based) ja oliopohjainen (object oriented) kieli, joka muistuttaa huomattavasti assembly-konekieltä [40]. Kuvassa 8 on hahmotettu kääntämisen työnkulkua. 23 Kuva 8. Lähdekoodin kääntäminen CLI-spesifikaation mukaisesti. 3.1.2 Adam Adam on yhteisnimitys joukolle markkinointisovelluksia, jotka Adam Software -niminen yritys on kehittänyt. Adam on siis Adam Softwaren luoma ohjelmistokokonaisuus. Se sisältää erilliset ohjelmistot tuotteiden, aineistojen, kampanjoiden, työnkulun ja julkaisun hallintaan. Ohjelmistot ovat osittain toisistaan riippumattomat, mutta ne kuitenkin kykenevät tekemään yhteistyötä keskenään rajapintojensa kautta. Adam Softwaren mukaan Adam on Marketing Execution Platform (MEP). Kuvassa 9 on hahmoteltu ohjelmistokokonaisuuteen liittyvien ohjelmistojen liitoksia toisiinsa nähden. [44] 24 Kuva 9. Adam ohjelmistokokonaisuuden ohjelmistot ja niiden liitokset. [44] Adamin ohjelmistot rakentuvat ADAM Engine -nimisen ytimen päälle. Pääohjelmistoina toimivat Assets, Products ja System, joita Adam Software kutsuu studioiksi. Assets studio on luotu digitaalisten aineistojen hallintaa varten, Products studio on luotu tuotteiden hallintaa varten ja System studio on luotu järjestelmän hallintaa varten. Adam on luonut studioiden päälle omia moduuleja, jotka täydentävät pääohjelmistojen toiminnallisuuksia. Kuvassa 10 on esitetty Adam ohjelmistokokonaisuuden arkkitehtuuria kerroksittain [45]. Kuvassa olevaan Custom Studios -kohtaan voi luoda oman moduulin tai studion. 25 Kuva 10. Hahmotelma Adamin kerrosarkkitehtuurista. [45] 3.1.3 Asynchronous JavaScript and XML AJAX (Asynchronous JavaScript and XML) on erittäin tärkeässä roolissa nykypäivän websovelluksissa. AJAX on joukko web-sovelluskehityksen tekniikoita, joiden avulla on mahdollista päivittää verkkosivun sisältöä asynkronisesti lataamatta koko verkkosivua uudestaan. Alun perin AJAX:illa tarkoitettiin tekniikkaa, jossa JavaScriptin ja HTTP (HyperText Transfer Protocol) -pyyntöjen avulla ladattiin palvelimilta pelkästään XML (Extensible Markup Language) -muotoista tietoa. Nykyään sitä käytetään hakemaan myös muun muotoista tietoa. AJAX käyttää hyödyksi useimmissa selaimissa toimivaa JavaScript-skriptikieltä, joka koostuu kolmesta erillisestä osasta: • ECMAScript:stä, • DOM:sta (Document Object Model) ja • BOM:sta (Browser Object Model) [46] 26 ECMAScript on skriptikieli, jonka päätoiminnallisuudet on määritetty ECMA-262 [47] standardissa. Kielen alkuperä on kotoisin JavaScript (Netscape) ja JScript (Microsoft) kielistä [47]. DOM on oliopohjainen malli, joka sisältää metodit ja rajapinnat verkkosivun XML- tai HTML (HyperText Markup Language) -sisällön muokkausta varten. BOM on myös oliopohjainen malli, joka sisältää rajapinnat ja metodit selaimen toiminnallisuuksien käyttämiseen. Käytetyimmät selaimet, eli Chrome, Internet Explorer, FireFox, Safari ja Opera [48] tukevat JavaScriptin kolmea eri osaa vaihtelevasti. Yleisesti ottaen kaikki selaimet tukevat ECMAScriptin kolmatta versiota varsin hyvin. DOM on standardoitu, mutta kaikki selaimet eivät kuitenkaan tue kaikkia toiminnallisuuksia. BOM on lähes täysin selainkohtainen, eikä sitä ole standardisoitu. [46] Työnkulku-moduulin tapauksessa XML:n sijasta käytetään pääasiassa JSON (JavaScript Object Notation) tiedonsiirtomuotoa. JSON muotoa on helppo käyttää JavaScriptin kanssa johtuen siitä, että se on syntaksiltaan ECMAScriptin mukaista. JSON on myös yleisesti ottaen nopeampaa ja käyttää vähemmän resursseja. [49] 3.1.4 Model-View-Controller Uuden Työnkulku-moduulin toteutuksessa käytetään pääasiassa hyväksi MVC (ModelView-Controller) -ohjelmistoarkkitehtuuria. Sen perusajatuksena on erottaa sovelluksen käyttöliittymä varsinaisesta sovelluslogiikasta ja -datasta, jotta käyttöliittymän muuttaminen olisi helppoa [50]. Järjestelmä jaetaan kolmentyyppisiin osiin; malliin (Model), näkymään (View) ja ohjaimeen (Controller). Kuvassa 11 on hahmoteltu MVC-arkkitehtuuria verkkoympäristössä. Kuvassa tietokone kuvastaa käyttäjän selainta, joka keskustelee verkkopalvelimen kanssa. Verkkopalvelin reitittää selaimelta tulleet kyselyt oikealle ohjaimelle, joka käsittelee kyselyt. Kyselystä riippuen ohjain tarvittaessa päivittää tai hakee tietokannasta näkymää varten tarvittavat tiedot ja tekee niistä tietomallin, jonka se antaa oikealle näkymälle piirrettäväksi. Näkymä piirtää annetun tietomallin esim. HTML-muodossa. Lopulta palvelin palauttaa uuden näkymän käyttäjän selaimelle. Kuvasta 11 voi päätellä, että näkymän ei tarvitse tietää juuri mitään ohjaimen toiminnasta. Näkymän tulee kuitenkin sisältää tieto siitä, miten selain voi 27 käskyttää ohjainta. Työpöytäsovelluksissa näkymä piirretään suoraan käyttäjän ruudulle, mutta verkkosovelluksissa näkymä pitää lähettää verkon yli HTML-kuvauskielenä ja muina sisältöön liittyvinä tiedostoina. Kuva 11. MVC-arkkitehtuuri verkkoympäristössä. 3.2 KOMMENTOINTI- JA HYVÄKSYNTÄSOVELLUKSET Digitaalisten aineistojen kommentointiin ja hyväksyntään (commenting & approval) tehdyillä tietokoneohjelmilla ei ole lyhyttä, yhtenäistä ja vakiintunutta suomenkielistä nimeä – jos edes englanninkielistäkään. Niitä saatetaan toisinaan kutsua esim. tarkistustyökaluiksi, kollaboraatio-ohjelmistoiksi eli yhteistyösovelluksiksi, online- vedostusjärjestelmiksi (online proofing software tool) [51] tai COM (Creative Operations Management) -alustoiksi [52]. Nimestä huolimatta yhteistä kyseisille sovelluksille on se, 28 että niiden avulla voi tehdä aineistojen päälle merkintöjä piirtäen tai kirjoittaen. Niiden avulla voi myös merkitä aineiston hylätyksi tai hyväksytyksi tai pyytää aineistoon muutoksia. Järjestelmien tarkoituksena on pyrkiä helpottamaan aineistojen parissa työskentelevien henkilöiden välistä yhteistyötä. Työssä otettiin lähempään tarkasteluun kaksi kommentointiin ja hyväksyntään tarkoitettua sovellusta; ProofHQ ja ConceptShare. Päällisin puolin tarkasteltuna molemmat sovellukset vaikuttivat soveltuvan hyvin yrityksen A kehittämän verkkosovelluksen rajapintoihin ja käyttötarpeisiin. ProofHQ oli jo entuudestaan tuttu joillekin asiakkaille. Adam Software puolestaan tarjosi ConceptSharen käyttöön omaa studiota ja yksinkertaistettua rajapintaa. Muita mahdollisia sovellusvaihtoehtoja olisi voinut olla esim. Copper Project [53], Concept Feedback [54] tai Kommentoi.com [55] -sovellukset. 3.2.1 ProofHQ ProofHQ on yrityksen nimen lisäksi myös kyseisen yrityksen online-vedostusjärjestelmän nimi [56]. ProofHQ:n mukaan online-vedostusjärjestelmällä tarkoitetaan verkkosovellusta, joka mahdollistaa digitaalisten aineistojen kommentoinnin ja hyväksynnän. Eli ProofHQ on digitaalisten aineistojen, asiakirjojen, kuvien, äänitteiden, videoiden ja vastaavien tiedostojen kommentointia ja hyväksyntää varten luotu verkkosovellus [57]. Sovelluksen avulla käyttäjät voi ladata digitaalista aineistoa ProofHQ:n palvelimille ja jakaa sitä muille henkilöille. Henkilöt, joille aineistot on jaettu voivat käydä ProofHQ:n verkkosivulla kommentoimassa ja mahdollisesti myös hyväksyä tai hylätä niitä. Palautteiden perusteella vedoksesta voidaan tarvittaessa luoda uusi versio uutta kommentointia ja hyväksyntää varten. ProofHQ on julkaissut API (Application Programming Interface) eli ohjelmistorajapinnan avoimesti. Rajapinnan avulla ProofHQ:n voi integroida muihin ohjelmistoihin. Valitettavasti ProofHQ:ta ei voi asentaa paikallisesti omalle koneelle, vaan sitä voi käyttää vain rajapinnan kautta. Rajapinta on toteutettu WSDL (Web Services Description Language) ja SOAP (Simple Object Access Protocol) -tekniikoilla. [58] Kuvassa 12 on kuvakaappaus ProofHQ-sovelluksesta, jossa vertaillaan aineiston kahta eri 29 versiota keskenään. Käyttäjien antamat kommentit aineistosta ja niiden versioista esitetään keltaisissa laatikoissa. Oikeanpuolimmaisessa versiossa käyttäjä kirjoittaa uutta kommenttia. Käyttäjä voi pyörittää tai zoomata kuvaa ja piirtää sen päälle kommentteja. Sovellus mahdollistaa myös videoiden ja monisivuisten PDF (Portable Document Format) -asiakirjojen kommentoinnin. Kuva 12. Kuvakaappaus ProofHQ:n versioiden vertailu- ja kommentointinäkymästä. 3.2.2 ConceptShare ConceptShare on yrityksen nimen lisäksi myös kyseisen yrityksen sovellusalustan nimi [59]. ConceptShare-yrityksen kuvailee sovellustaan sanoin: ”ConceptShare is a Creative Operations Management (COM) platform that structures and streamlines review and approval workflows for enterprise marketers, creative teams and their external stakeholders.” [52]. ConceptShare-yrityksen mukaan COM mahdollistaa seuraavia asioita: 30 • ohjaamaan luovaa työtä oikeille ihmisille oikeaan aikaan, • työn arvostelun ja palautteen antamisen tavalla, joka on nopeaa, helppoa ja selkeätä, • antamaan hyväksynnän tai muunlaisen päätöksen luovasta työstä yksin tai ryhmässä, • hallitsemaan huomautuksia, projekteja ja työnkulkuja ja • esittämään satojen tai tuhansien luovien töiden informaation UI (User Interface) / UX (User Experience Design) optimoidulla käyttöliittymällä. [52] Se ei kuitenkaan tarkoita seuraavia asioita: • Aineiston loppusijoitusvarastoa • Resurssienhallintajärjestelmää • Aikaseurantajärjestelmää • Rahoitusselvitysjärjestelmää [52] ConceptShare-ohjelmisto on siis tehty suunnilleen samaa tarkoitusta varten kuin ProofHQohjelmisto, mutta se ei ole rajapinnan suhteen kuitenkaan niin avoin. ConceptShare antaa ohjelmiston rajapinnan käyttöön vain yhteistyöyrityksille. ConceptSharen vahvuuksiin kuuluu se, että sen voi asentaa samalle palvelimelle missä aineistoa käsitellään, eikä tarvitse käyttää ulkoisessa verkossa olevaa palvelinta. Kuvassa 13 on esitetty kuvakaappaus ConceptSharen kommentointinäkymästä. 31 Kuva 13. Kuvakaappaus ConceptShare-ohjelmistosta. 3.3 OHJELMISTOKEHITYS Ohjelmiston kehitystyö voidaan jakaa eri vaiheisiin ja se voidaan kuvata vaihejakomallin avulla. Vaihejakomallin avulla prosessin etenemistä on helpompi seurata. Tavallisin kuvaus vaihejakomallista on ns. vesiputousmalli [60]. Kuvassa 14 on hahmoteltu vesiputousmallin mukainen vuokaavio, jossa prosessi etenee ideaalitapauksessa vaiheittain ylhäältä alaspäin pudoten. Käytännössä prosessissa pitää kuitenkin usein palata takaisin aikaisempiin vaiheisiin, koska aikaisemmissa vaiheissa ei ole osattu huomioida kaikkia ohjelmistoon vaikuttavia asioita. Vesiputousmallissa pyritään aluksi tekemään tarkat suunnitelmat alusta loppuun asti, minkä tavoitteena on välttää väärien toteutuksien tekeminen. Valitettavasti suunnittelu alusta loppuun asti voi olla erittäin hankalaa, ellei jopa mahdotonta. Joidenkin määrityksien tai ratkaisujen ongelmia huomataan vasta myöhemmissä vaiheissa, mikä saattaa aiheuttaa vesiputousmallissa kaikkien määrittelyjen ja suunnittelujen uudelleen läpikäymistä. 32 McConnelin mukaan varhaisessa vaiheessa huomatut suunnittelu- ja määrittelyvirheet on yli kymmenen tai jopa sata kertaa halvempaa korjata kuin myöhäisemmässä vaiheessa huomatut virheet [61]. Kehityksen edetessä on kuitenkin riski, että dokumentaatiosta poikkeavia toteutuksia ei jakseta tai muisteta päivittää dokumentaatioon. Jos näin tapahtuu, niin dokumentaatioon ei voi enää täysin luottaa. Kuva 14. Vesiputousmallin vuokaavio, joka perustuu Haikalan esittämään kuvaan. [60] Vesiputousmallin ongelmana on usein se, että ohjelmistoa ei pystytä suunnittelemaan täydellisesti etukäteen. Suunnitteluun liittyviä ongelmia voi kiertää pilkkomalla ohjelmiston kehityksen pienempiin palasiin, iteraatioihin. Diplomityön tapauksessa alkusuunnitelmia ei pystytty tekemään tarkasti, koska kolmannen osapuolen, ADAM Softwaren, kehittämä rajapinta ConceptShareen ei ollut valmis. Myöskään asiakkaat eivät osanneet alussa kertoa kovinkaan tarkasti mitä he oikeasti halusivat. Diplomityö päätettiin tehdä iteratiivisilla menetelmillä, jossa ensimmäisen iteraation tavoitteena oli toteuttaa minimaalisilla toiminnoilla toimiva sovellus ilman kommentointia ja hyväksyntää. Kehitysmenetelmänä ei kuitenkaan käytetty prototyyppimenetelmää, jossa ensin tehdään prototyyppisovellus ja sen jälkeen aloitetaan sovelluksen suunnittelu ja tekeminen täysin alusta. Ensimmäisen iteraation sovellusta siis jatkokehitettiin muissa iteraatioissa, eikä kaikkea aloitettu alusta. 33 Moduulin kehityksen loppuvaiheessa käytettiin ketteriä (agile) menetelmiä, kun haluttiin julkaista asiakkaille päivityksiä nopeampaa tahtia [60]. Eli iteraatiot pidettiin pieninä, vain noin kahden viikon mittaisina. Iteraatioita ei välttämättä tehty valmiiksi täysin alkusuunnitelmien mukaan, vaan niiden suunnitelmiin ja toteutuksiin tehtiin muutoksia kehityksen aikana. Moduulin uusia toimintoja tehtiin pääasiassa suunnittelemalla ensin käyttöliittymä, jolloin toimintojen toteutukset hahmotettiin paremmin ja niiden käytettävyydestä saatiin nopeammin palautetta. Usein vasta käyttöliittymää katsomalla ymmärrettiin, että suunnitelmista puuttui joitakin olennaisia asioita. Useimmiten muutokset oli nopeampi tehdä käyttöliittymään kuin taustalla olevaan koodiin. Kun käyttöliittymä näytti riittävän hyvältä, viimeisteltiin taustalla oleva logiikka. 3.3.1 Käyttötapaukset Ohjelmiston vaatimuksia voidaan kuvata käyttötapauskuvauksilla, joissa ohjelmiston toiminnallisuuksia kuvataan käyttäjän näkökulmasta katsottuna [62]. OMG (Object Management Group™) on määritellyt standardissa (Unified Modeling käyttötapauskaavioiden Language), joka on kuvaukset kehitetty UML- pääasiassa ohjelmistokehitystä varten [63]. Käyttötapauskaaviossa ohjelmiston eri käyttäjät, käyttäjäryhmät ja muut toimijat selitetään kuvatekstein käyttäen tikku-ukkoja. Ohjelmiston käyttötapaukset puolestaan kuvataan ellipsien muotoisilla kuvateksteillä, joiden sisälle on ytimekkäästi kirjoitettu käyttötapauksen nimi. Käyttötapauksien ja toimijoiden väliset relaatiot voidaan kuvataan viivoin ja nuolin. UML-kaavioille on määritetty standardisoituja tapoja siitä, että miten niitä tulisi käyttää. UML-kaavioiden rinnalle on hyvä myös pistää selite siitä mitä eri komponentit tarkoittavat, jotta kaaviot tulee ymmärretyksi oikein. [62] Kuvassa 15 on selitetty kuvan 16 käyttökaaviossa käytettyjen komponenttien semantiikka eli merkitys. Toimintoja kuvataan ellipseillä ja toimintojen suorittajia eli käyttäjiä tikkuukoilla [62]. Kuvaan 16 on hahmoteltu vain Työnkulku-moduulin yleisimmät ja tärkeimmät käyttötapaukset, jotta se olisi helpommin hahmoteltavissa ja mahtuisi paremmin A4-paperille. Kuvassa pääkäyttäjät perivät kaikki toiminnot johtajilta, johtajat puolestaan perivät toiminnot tekijöiltä jne. Eli pääkäyttäjät voivat tehdä kaikkea mitä johtajat, tekijät ja tarkastajat voivat tehdä. Käyttäjille voidaan antaa erikseen oikeus hyväksyä aineistoja. Vierailijat pääsevät kommentoimaan ja mahdollisesti myös 34 hyväksymään, jos heille on se oikeus annettu. Kuva 15. Käyttötapauskaavion legendat eli kuvatekstien selitykset. 35 Kuva 16. Käyttötapauskaavio yleisimmistä toiminnoista, joita Työnkulku-moduulin tulisi toteuttaa. 36 3.3.2 Ympäristökuvaus Kuvassa 17 esitetään pelkistetysti laitteistot ja niiden väliset rajapinnat. Palvelimet on piirretty harmain tietokonein. Ohjelmiston käyttäjät on hahmoteltu tietokoneruudulla. Ohjelmistorajapinnat on hahmoteltu laatikon muotoisilla komponenteilla. Tietokantapalvelimet on piirretty lieriöinä. Internet on piirretty pilvenä. Käyttäjät pääsevät Internetin kautta käyttämään verkkopalvelimella olevaa verkkosovellus A -ohjelmistoa, joka sisältää Media- ja Työnkulku- moduulit. Yrityksen A asiakkaat saavat ProofHQ- ja ConceptShare-ohjelmistojen kommentointi- ja hyväksyntätoiminnallisuudet käyttöönsä Työnkulku-moduulin integraation kautta. Aineistoja ei tarvitse enää ladata erikseen kolmannen osapuolen palvelimelle kommentoitavaksi ja hyväksyttäväksi. Kuva 17. Laitteisto- ja rajapintakaavio. 37 3.3.3 Integraatio Ohjelmistojen myyntipuheet ja spesifikaatiot eivät aina kerro totuutta ohjelmistosta. Integroitavien ohjelmistojen rajapinnat eivät välttämättä toimi siten, miten ne on dokumentoitu. Rajapinnoista saattaa myös puuttua integroinnin kannalta tärkeitä toiminnallisuuksia. Tapaustutkimuksen mukaisesti integrointia päätettiin tutkia integroimalla Työnkulku-moduuliin alustavasti kaksi samankaltaista ohjelmistoa: ProofHQ ja ConceptShare. Molempia ohjelmistoja käytetään samoihin tarkoituksiin, mutta niiden rajapinnat ovat kuitenkin hiukan erilaiset. Esim. ProofHQ:ssa käyttäjät ovat vedoskohtaisia, kun puolestaan ConceptSharessa ne ovat ConceptShare projektikohtaisia. ProofHQ:ssa vedokset lisätään työtiloihin (workspace), jotka ovat tavallaan kansioita. Käytännössä ProofHQ:n työtiloja voi pitää kampanjoina. Työnkulku-moduuliin tehtiin yhtenäinen rajapinta, jonka kautta molempia ohjelmistoja voi käyttää. Yhtenäiseen rajapintaan kuitenkin tehtiin sovelluskohtaisia lisäyksiä, jotta molempien ohjelmistojen erilaisia ominaisuuksia saatiin hyödynnettyä. Työnkulku-moduuliin pohdittiin myös Basecamp-projektinhallintaohjelmiston integroimista. Basecamp tarjoaa integrointia varten REST (Representational State Transfer) -pohjaisen rajapinnan, joka toteuttaa Web Servicelle tyypilliset toiminnallisuudet käyttämällä vain HTTP-protokollaa [64]. Basecamp käyttää REST:in tiedonsiirtomuotona JSON:ia. Dokumentaation mukaan Basecampin rajapinta mahdollistaa projekteihin liittyvien tietojen lukemisen, muokkaamisen ja poistamisen [65]. Rajapinnan kautta ei kuitenkaan saa valmiita HTML-näkymiä, vaan ne pitäisi tehdä itse. Näkymien ja niiden toiminnallisuuksien tekeminen ei sinänsä olisi ollut vaikeata REST-rajapintaa käyttäen. Tämä olisi mahdollisesti hyvä vaihtoehto, mutta diplomityössä päätettiin olla käyttämättä Basecampin ohjelmistorajapintaa, jotta Työnkulku-moduuli ei olisi liian riippuvainen Basecampistä ja sen tietorakenteista. 3.4 KÄYTTÖLIITTYMÄ Koska kyseessä oli verkkosovellus, tehtiin käyttöliittymän kuvaus HyperText Markup Language (HTML) -kuvauskielellä ja tyylit tehtiin Content Style Sheets (CSS) -tyyliohjeilla. Käyttöliittymän animaatiot ja tietojen päivitykset sisältöön tehtiin 38 JavaScriptin avulla. Huomioitava asia on se, että käyttöliittymänä toimi vain yksittäinen verkkosivu. Verkkosivun kaikkia osia ei kuitenkaan ladattu kerralla käyttäjälle vaan vasta kun käyttäjä tarvitsi valinnaisia osia, vastaavasti myös käyttöliittymän osia poistettiin muistista, kun niitä ei enää tarvittu. Valinnaisia osia olivat esim. dialogit ja välilehdet, joita ei oltu vielä avattu. Sivusta päivitettiin vain sitä aluetta, jossa tapahtui muutoksia. Eli selaimen ei tarvitse ladata turhaan koko sivua uudestaan, tämän avulla pystyttiin myös vähentämään palvelimen kuormaa. Tietojen muutoksista kerrottiin käyttöliittymän eri komponenteille tapahtumaviestein käyttäen julkaise-tilaa (publish-subscribe) -suunnittelumallia [66]. Malli soveltuu hyvin sovelluksiin, jossa on paljon komponentteja, jotka ovat löyhästi sidoksissa toisiinsa. Komponentit voivat tilata (subscribe) viestejä, joista ne haluavat tietoa. Vastaavasti komponentit voivat julkaista (publish) viestejä, joista ne haluavat kertoa muille komponenteille. Komponenttien ei tarvitse tietää mitä muut komponentit tekevät tiedoilla. On kuitenkin pidettävä huoli siitä, että komponentit eivät mene päättymättömään viestisilmukkaan. [67] 3.4.1 Päänäkymä Päänäkymä on yksi tärkeimmistä näkymistä Työnkulku-moduulin käyttäjille. Näkymästä käyttäjät voivat nähdä miten vedoksia on kommentoitu ja millaisia päätöksiä ne ovat saaneet. Kuvassa 18 on esitetty kuvakaappaus moduulin päänäkymästä. Kun kansio on valittuna, se näyttää automaattisesti kaikki kansion ja sen sisällä olevien projektien vedokset, tehtävät ja tapahtumat. Näkymän avulla käyttäjien ei tarvitse selata sähköposteja ja etsiä niistä tietoja esim. siitä, mitä tehtäviä pitäisi tehdä tai mitä vedoksia heidän pitäisi mennä kommentoimaan tai hyväksymään. Näkymässä olevat taulukot sisältävät suodatukseen perustuvan hakutoiminnallisuuden, joka helpottaa käyttäjää löytämään tietynlaisia vedoksia, tehtäviä tai projekteja. 39 Kuva 18. Kuvakaappaus päänäkymästä, kun kansio on valittuna. Projektinäkymä on samanlainen kuin kansionäkymä, mutta kansion sijasta näytetään projektiin liittyvät tiedot. Käyttäjä voi myös valita näkymästä, että haluaako näyttää pelkästään kyseisen projektin tiedot vai myös sen sisältämien kansioiden ja projektien tiedot. Projektin tietojen muokkaus onnistuu erillisellä dialogilla. Jokaista markkinointikampanjaa varten luodaan oma projekti. Kuvassa 19 on esitetty kuvakaappaus projektinäkymästä. Asiakasyrityksillä projektit olivat enimmäkseen markkinointikampanjoita. Aikaisemmassa prosessissa markkinointikampanjoihin liittyviä tietoja piti etsiä erillisistä asiakirjoista, sähköposteista ja muista kolmansien osapuolien sovelluksista, esim. ProofHQ:sta. Työnkulku-moduulin päänäkymässä koostettuja tietoja ProofHQ:ssa olevista kampanjoista ja niiden vedoksista. 40 näytettiin Kuva 19. Kuvakaappaus Työnkulku-moduulin päänäkymästä. Näkymässä näytetään joko kansion tai projektin tiedot riippuen siitä, että onko kansio vai projekti valittuna. 3.4.2 Kalenterinäkymä Kalenterinäkymä on yksi tärkeimmistä näkymistä kampanjan johtamisessa. Sen avulla kampanjapäälliköt voivat hahmottaa mitä kampanjoita ja muita projekteja on käynnissä ja mitä pitää milloinkin tehdä. Kalenterinäkymän kautta voi luoda projekteja maalaamalla kursorin avulla useampia päiviä. Yksittäisen päivän maalauksella voi luoda tehtävän kyseisellä päivälle. Kalenterissa on suodatustoiminto, jonka avulla käyttäjä voi piilottaa/näyttää haluamansa tehtävät/projektit tyypeittäin. Kuvassa 20 on kuvakaappaus kalenterinäkymästä. Projekteille voi määrittää värin, jolla ne näkyy kalenterissa. Tehtävät näkyvät ilman taustaväriä. Aluksi värit olivat vapaasti valittavissa, myöhemmin tietyt värit haluttiin sitoa tietyn tyyppisiin projekteihin, jotta niiden hahmottaminen kalenterista olisi helpompaa. 41 Kuva 20. Kuvakaappaus kalenterinäkymästä. 3.4.3 Jäsennäkymä Kuvassa 21 on esitetty jäsennäkymä, jonka kautta johtajat voivat lisätä kampanjaan johtajia (managers), muokkaajia (editors) tai/ja tarkastelijoita (observers). Taulukoissa oleva jäsenten lisääminen aukaisee ponnahdusikkunan, josta voi valita lisättävät käyttäjät. Vaihtoehtoisesti voi myös valita, että lisätäänkö uudet jäsenet kaikkiin ylä- ja/tai alakansioihin. Projektia luodessa jäsenet voidaan periyttää automaattisesti yläkansiosta. Jäseniä ei siis tarvitse lisätä jokaiseen projektiin yksitellen, mikä säästää huomattavasti aikaa. Aikaisemmassa prosessissa kampanjoiden jäsenet piti lisätä ProofHQ:n hallinnointisivustolla yksitellen jokaiseen työtilaan (workspace) eli kampanjaan. Koska 42 ProofHQ:ssa pitää maksaa sitä enemmän mitä enemmän on käyttäjiä, piti käyttäjätilien käyttöä välttää. ProofHQ:ssa piti suosia vieras-käyttäjiä (guest), koska niiden käyttö oli ilmaista. Niiden huonona puolena oli se, että vieraat piti lisätä jokaiseen vedoksen versioon manuaalisesti yksitellen. Kuva 21. Kuvakaappaus jäsennäkymästä. 3.4.4 Sisältönäkymä Sisältönäkymä on päänäkymän jälkeen yksi tärkeimmistä näkymistä. Kuvassa 22 on kuvakaappaus kyseisestä näkymästä. Sen avulla käyttäjät voivat lisätä uusia aineistoja ja vedoksia kampanjoihin. Vedoksien kommenttien ja erityyppisten päätöksien määrät on piirretty numeroina eri väristen laatikoiden sisälle. Esim. kommenttien määrät on piirretty harmaiden laatikoiden sisälle ja vedoksen hyväksyntöjen määrä vihreiden laatikoiden sisälle. Projektipäällikkö voi katsoa tarkemmat tiedot kommenteista ja hyväksynnöistä klikkaamalla laatikoita tai menemällä kommentointi- ja hyväksyntäsovelluksen sisään klikkaamalla ”avaa”-linkkiä. ”Avaa”-linkki siis aukaisee joko ProofHQ tai ConceptShare -sovelluksen riippuen siitä kumpaan sovellukseen kampanja on integroitu. 43 Aikaisemmassa prosessissa käyttäjien piti erikseen kirjautua ProofHQ-palvelimella ja ladata sinne yksitellen uudet vedokset ja versiot, sekä lisätä niihin yksitellen käyttäjät. Kun käyttäjät olivat kommentoineet ja hyväksyneet vedokset, piti ne manuaalisesti ladata Media-moduuliin jaettaviksi. Uudessa prosessissa pystyy lataamaan kerralla kaikki uudet vedokset ja versiot. Klikkaamalla ”Luo vedos” -näppäintä ja sitten valitsemalla uudet tiedostot tiedostojärjestelmästä tai yksinkertaisesti raahaamalla tiedostot tiedostojärjestelmästä edellä mainitun näppäimen päälle. Työnkulku-moduuli tunnistaa automaattisesti uudet versiot tiedostojen nimien perusteella, uusista tiedoston nimistä se luo automaattisesti uudet vedokset, ellei käyttäjä määrittele toisin. Tallennusvaiheessa se lataa vedokset Työnkulku-moduuliin ja myös ProofHQ:n palvelimelle. Vedoksien ja versioiden käyttäjät määräytyvät automaattisesti projektiin liitettyjen käyttäjien mukaan. Vedoksien versioita voi halutessa jakaa ulkopuolisille käyttäjille lisäämällä ne vedoksen version vieraslistalle. Vierailijoille lähetettiin sähköpostitse linkki, jonka avulla he pääsivät ProofHQ:n kommentointi- ja hyväksyntätilaan. Vedoksien valmistuttua ne voitiin siirtää Media-moduuliin jaettavaksi. Kuva 22. Kuvakaappaus sisältönäkymästä. 44 3.4.5 Tehtävänäkymä Tehtävänäkymässä on listattu kaikki projektiin liittyvät tehtävät. Kyseinen näkymä on tarkoitettu lähinnä projektipäälliköille, muiden käyttäjien näkyvyysasetukset saattavat estää näkemästä ja muokkaamasta tietoja. Muille käyttäjille lähinnä riittää etusivulla oleva tehtävälista. Diplomityön toteutuksessa tehtävien tekijöiksi sallittiin vain yksi tekijä, jotta ei jäisi epäselväksi kenen tulisi tehdä tehtävä. Asiakkailta tuli kuitenkin palautetta, että olisi tarvetta antaa useampi tekijä tehtävälle. Kuva 23. Kuvakaappaus tehtävänäkymästä. 3.4.6 Keskustelunäkymä Kampanjoissa kaikki keskustelu ei aina liity aineistoihin, vaan itse kampanjaan ja sen toteutukseen. Toisinaan aineistoistakin haluttiin keskustella yleisesti, eikä haluttu tehdä keskustelua kommentointijärjestelmän kautta. Keskusteluja ja muita kommunikaatioita varten ohjelmistoon luotiin erillinen keskustelunäkymä, jonka tavoitteena on mahdollistaa keskustelujen tallentaminen projektiin. Sen tarkoituksena oli myös tuoda keskustelu pois epämääräisistä sähköpostikeskusteluista. Siirtämällä henkilökohtaiset sähköpostit moduulin, saadaan projektiin myös enemmän läpinäkyvyyttä. Kuvassa kuvakaappaus keskustelunäkymästä. Tarvittaessa keskustelunäkymässä voi 24 on tehdä viittauksia projektin aineistoihin ja vedoksiin. Vedoksiin liittyvä kommentointi ja hyväksyntä tehtiin kuitenkin kommentointi- ja hyväksyntäohjelmistojen sisällä. 45 Kuva 24. Kuvakaappaus keskustelut-näkymästä. 46 4 TULOKSET JA POHDINTA Työn tavoitteena oli tehostaa markkinointikampanjoiden ja niiden aineistojen hallintaan liittyvää prosessia. Aineistojen kommentointia ja hyväksyntää varten työssä tutustuttiin ProofHQ ja ConceptShare -sovelluksiin integroimalla ne osaksi Työnkulku-moduulia. Sovellusten integroinnista ja niiden testaamisesta kerättiin tietoa, jotta niitä voitiin vertailla keskenään. Arviointi tavoitteiden saavuttamisesta tehtiin työlle asetettujen mittareiden ja asiakastyytyväisyyskyselyn avulla. Seuraavissa aliluvuissa kerrotaan vertailuista ja arvioinneista enemmän. 4.1 PROOFHQ JA CONCEPTSHARE VERTAILU ConceptSharen integroinnissa käytettiin Adam Softwaren kehittämää Teamwork 1.1 -nimistä rajapintaa, joka myöhemmin vaihtoi nimensä Collaboration 2.0:ksi. Kyseisen rajapinnan kanssa oli huomattavasti ongelmia. Suurin ongelma oli se, että rajapinnan ensimmäiset versiot sisälsivät kehitystyön edistymistä estäviä ohjelmistovirheitä. Ohjelmistovirheiden takia vedoksien ja projektien linkitykset ConceptShareen lakkasivat toimimasta, eikä niitä enää voinut aukaista. Ongelmia aiheutti myös se, että käyttäjätunnukset oli pysyvästi sidottu sähköpostitunnuksiin, eikä niitä voinut muuttaa jälkeenpäin – ainakaan helposti. ProofHQ:n integrointi tehtiin käyttämällä ProofHQ:n omaa rajapintaa. ProofHQ:ssa käyttäjätunnuksina toimi myös sähköpostit, mutta niitä ei sidottu pysyvästi yrityksen A kehittämän järjestelmän käyttäjätunnuksiin. Integroinnin yhteydessä ProofHQ:sta löytyi myös ohjelmistovirheitä, mutta ne eivät estäneet ohjelmiston kehittämistä. ProofHQ:n käyttö oli kuitenkin nopeudeltaan hiukan hitaampaa johtuen siitä, että rajapinta sijaitsi ulkopuolisella palvelimella. Suurikokoisten tiedostojen lataamisessa ProofHQ:n palvelimelle saattoi kestää useita minuutteja, ja sen lisäksi monimutkaisten vedoksien luontiprosessointiin meni huomattavasti aikaa. Vedoksia pääsi kommentoimaan ja hyväksymään vasta sitten, kun ProofHQ oli prosessoinut ne sopivaan muotoon. ProofHQ ja ConceptShare integraatioiden ensimmäiset versiot otettiin testikäyttöön. Testikäytön aikana huomattiin, että kuvien pyörittäminen näytöllä oli erittäin tärkeätä 47 joillekin asiakkaille. Kyseisillä asiakkailla oli käytössä paljon aineistoja, joissa oli tekstejä monissa eri kulmissa. Esim. sivulla 30 olevassa kuvassa 12 on esimerkkikuva pakkausaineistosta, jossa tekstejä on moniin suuntiin. ProofHQ:lla onnistui kuvien pyöritys 90 astetta kerrallaan, ConceptShare ei tukenut kuvien pyörittämistä. Pyörityksien lisäksi tekstien valitseminen selaimen kursorilla koettiin tärkeäksi, koska niitä haluttiin kopioida annettaviin kommentteihin. ConceptSharessa tekstit piirtyivät kuvina, joten niitä ei voinut kopioida tekstimuotoisena annettaviin kommentteihin. Taulukon 1 ensimmäiseen sarakkeeseen on listattu kommentointi- ja hyväksyntäohjelmistoille ominaisuuksia ja toimintoja, joiden tarpeellisuutta on arvioitu asiakastarpeisiin nähden tärkeysarvona taulukon viimeisessä sarakkeessa. Taulukoon on myös arvioitu kuinka hyvin ProofHQ:n ja ConceptShare:n rajapinnat toteuttavat listattuja ominaisuuksia ja toiminnallisuuksia. Arviointia on tehty integroinnista ja testauksesta saadun kokemuksen sekä asiakkailta saadun palautteen perusteella. Arvioinnissa on käytetty kuusiportaista 0-5 -asteikkoa, jossa suurempi arvo tarkoittaa parempaa toteutusta/tärkeyttä. Rajapintojen toteuksissa 0 tarkoittaa, ettei toteutusta ole tehty. Tärkeysarvossa 0 puolestaan tarkoittaa, ettei toiminnallisuus/ominaisuus ole tarpeellinen. Taulukon alaosaan on laskettu pisteytyksien keskiarvot ilman tärkeyspisteiden painotuksia ja niiden kanssa. Painotetussa keskiarvossa x on käytetty kaavaa 1. n n 1 ∑ ω x , jossaW =∑ ωi , W i=1 i i i=1 ω :tärkeysarvon painotus , x :toiminnallisuuden pisteytys x= (1) Painotettu keskiarvo on tärkeämpi tuloksen kannalta, koska siinä on otettu huomioon ominaisuuksien ja toiminnallisuuksien tärkeydet. ProofHQ sai paremman keskiarvon molemmilla tavoilla laskettuna kuin ConceptShare. ConceptSharen vahvuuksia oli nopeus ja parempi liiketoiminta yrityksen A kannalta katsoen. ConceptSharea ei oltu hinnoiteltu resurssien, eli esim. vedoksien, levytilojen ja käyttäjämäärien mukaisesti. 48 Taulukko 1. Kommentointi- ja hyväksyntäjärjestelmien vertailutaulukko. Ominaisuus/toiminnallisuus ProofHQ v13.8 ConceptShare Collaboration API 2.0 Tärkeysarvo Pyöritys 4 0 5 Zoomaus 5 3 4 Palvelun saatavuus (availability) 4 5 5 Nopeus 3 5 5 Kommentointi tekstein 5 5 5 Kommentointi piirtäen 5 5 5 Versioiden vertailu 5 3 5 Tekstin valitseminen 4 0 5 Kommentteihin vastaaminen 5 3 2 Versioiden eroavaisuuksien korostus 5 5 3 Integroinnin helppous 3 2 5 Ohjelmistorajapinta integrointia varten 4 3 4 Videoiden kommentointi 4 4 4 Arkistointi 4 3 4 Palautus 4 0 2 Virheettömyys 4 2 5 Dokumentaatio 4 2 4 Ohjelmistotuki 4 3 3 Asennus ja käyttöönotto 3 3 2 Ylläpito 4 3 5 Kustannus 2 4 5 Monisivuisten aineistojen kommentointi 4 4 5 Pisteiden keskiarvo: 4,05 3,05 Painotettu keskiarvo: 4,02 3,11 4.2 MITTAROINTI Diplomityön alkuvaiheissa työosuudelle asetettiin ja kirjattiin tavoitteita, jotta myöhemmin voitiin kertoa missä onnistuttiin ja missä epäonnistuttiin. Työlle asetettuja tavoitteita voidaan käyttää niin sanottuina mittareina. Tässä työssä mittareiksi asetettiin pääasiassa 49 vain ohjelmistovaatimuksia, jotka liittyivät projektinhallintaan, kommunikointiin ja integrointiin. Valitettavasti aivan projektin alussa ei kuitenkaan tajuttu laatia kovinkaan tarkkoja vaatimuksia ja tärkeyksiä diplomityötä varten, vaan niitä tarkennettiin projektin etenemisen myötä. Suurin osa vaatimuksista, tavoitteista ja niiden tärkeyksistä on kuitenkin luotu projektin ensimmäisten iteraatioiden aikana. Diplomityön mittareiksi asetetut vaatimukset ja niiden toteutusasteet on listattu taulukkoon 2. Suurin osa mittaroitavista asioista saatiin toteutetuksi. Kalenterinäkymään toteutettiin vain kuukausinäkymä, eli vuosi-, kvartaali- ja viikkonäkymät jäivät toteuttamatta. ConceptSharen integrointi tehtiin lähes valmiiksi, mutta sen toteutus päätettiin jättää kesken. Syinä keskeyttämiseen oli ConceptSharen puutteet ja Adamin rajapinnan rajoitukset sekä niihin liittyvät ohjelmistovirheet. Vaatimukset on määritelty tärkeyspisteillä, joista jokainen piste vastaa mittarin pistettä. Tärkeysasteikkona toimii numerot nollan ja viiden väliltä, jossa numero kertoo suuremmasta tärkeydestä. Taulukon oikeaan laitaan on merkitty toteutusprosentti diplomityön aikana. Tärkeysarvoja on arvioitu yrityksen A sisäisesti sekä asiakkailta saatujen palautteiden ja toteutuspyyntöjen avulla. Taulukko 2. Työnkulku-moduulille asetetut vaatimukset ja tavoitteet sekä niiden saavuttaminen. Vaatimus/Tavoite Tärkeys Toteutus % Käyttäjän ei tarvitse kirjautua useampaan järjestelmään 5 100 Käyttäjän tarvitsee ladata vedos vain yhteen järjestelmään 5 100 Useamman vedoksen lataus kerralla 5 100 Useamman vedoksen version lataus kerralla (version tunnistus tiedoston nimestä, vaatimus lisätty projektin loppuvaiheessa) 3 100 Aineistonäkymä (aineistojen ja vedoksien hallinta) 5 100 Aineistojen Drag & Drop -tuki 3 100 Vedoskohtaiset vieraat (yksittäisen vedoksen jakaminen) 5 100 Vedoslinkitykset keskusteluihin 3 100 Vedoksien etsiminen (sanahaku puittain) 5 100 Projektitietojen muokkaus (nimi, kuvaus, aikataulu...) 5 100 50 Vaatimus/Tavoite Tärkeys Toteutus % Projektikohtaiset käyttäjäryhmät (3 ryhmää + vieraat) 5 100 Ryhmäkohtaiset oikeudet eri toimintoihin 5 100 Käyttäjien hallinta yksittäisiin projekteihin 5 100 Käyttäjien hallinta useampaan projektiin kerralla (puurakenteen avulla) 5 100 Projektikohtaiset keskustelut (ei näy vieraille) 5 100 Projektikohtaiset tehtävät 5 100 Projektin arkistointi 3 100 Projektin palautus arkistosta takaisin käyttöön 2 100 Projektin kopioiminen 3 100 Projektien kategorisoiminen (siirtäminen puurakenteessa) 5 100 Projektien etsiminen (sanahaku puittain) 5 100 ProofHQ integraatio (yleisimmät toiminnot) 5 100 ConceptShare integraatio (yleisimmät toiminnot) 5 75 Hälytyksien asettaminen ja huomautukset 2 0 Tapahtumahistoria projektikohtaisesti 5 100 Tapahtumahistoria puukohtaisesti 4 100 Sähköpostihuomautukset suodatuksilla 5 100 Media-moduulin kaltainen käyttöliittymä 3 100 Kalenterinäkymä (projektien ja tehtävien aikataulut) 5 100 Kuukausinäkymä 5 100 Viikkonäkymä 3 0 Vuosinäkymä 1 0 Kvartaalinäkymä 3 0 Tehtävänäkymä (tehtävien hallinta ja jakaminen) 5 100 Tehtävien etsiminen (sanahaku puittain) 5 100 n Suht . toteutus=( ∑ i=1 n Tärkeysi Toteutusi )/( ∑ Tärkeysi )∗100 %=93 % 100 % i=1 51 (2) 4.3 ASIAKASTYYTYVÄISYYS Asiakastyytyväisyyttä mitattiin diplomityön lopussa olevalla LIITE 1 -liitteen mukaisella kyselylomakkeella. Kysely suoritettiin verkkokyselytutkimuksena, jonka vastauslinkki lähetettiin sähköpostitse yli kahdelle sadalle Työnkulku-moduulin käyttäjälle. Kysely lähetettiin huhtikuussa 2015. Kyselyä ei lähetetty niille käyttäjille, jotka osallistuivat prosessiin pelkästään integroitujen kommentointi- ja hyväksyntätyökalujen kautta. Eli kysely lähetettiin vain niille käyttäjille, jotka pääsevät Työnkulku-moduulin käsiksi. Kyselystä haluttiin ytimekäs, jottei asiakkaita vaivattaisi liian usealla kysymyksellä. Kysymyksiin vastasi loppujen lopuksi vain 14 henkilöä, vaikka kyselyssä oli yhteensä vain kuusi kysymystä. Alun perin ideana oli toteuttaa sama asiakaskysely tietyin aikavälein, jotta olisi nähnyt kuinka ohjelmistoon tehdyt muutokset olisivat vaikuttaneet tuloksiin. Valitettavasti kysely saatiin toteutettua vasta projektin loppuvaiheissa. Kyselyn lähettäminen asiakkaille myöhästyi huomattavasti kiireiden ja erilaisten syiden takia. Työnkulku-moduuli oli yrityksen omassa sisäisessä käytössä jo projektin alkuvaiheista lähtien, minkä ansiosta Työnkulku-moduulista saatiin nopeata palautetta. Ohjelmistoon tehtiin muutoksia saatujen palautteiden perusteella. Sisäisesti ohjelmistoa käytettiin samoihin käyttötarkoituksiin kuin asiakasyrityksetkin. Kyselyä tehdessä Työnkulku-moduuli oli sisäisen käytön lisäksi jo useamman asiakasyrityksen käytössä. Kyselyn aikana Työnkulku-moduuliin oli luotuna yli 7239 projektia, 2332 kansiota, 8439 vedosta, 20066 aineistoa, 34448 kommenttia ja 3379 tehtävää. Eli Työnkulku-moduulia oli käytetty jo varsin ahkerasti. Luvut eivät sisällä poistettuja aineistoja, vedoksia, tehtäviä, kansioita ja projekteja. Arkistoidut kansiot ja projektit ovat kuitenkin luvuissa mukana. Asiakastyytyväisyyskyselyn ensimmäisen kysymyksen tarkoitus oli selvittää, mitä kyselyyn vastaava henkilö tekee töikseen ja mitä rooleja hän käyttää Työnkulkumoduulissa. Työnkuvan avulla pystyi hahmottamaan mitä vastaaja tekee työkseen, roolien avulla puolestaan pystyi hahmottamaan mitä ohjelmiston toiminnallisuuksia vastaaja on voinut käyttää. Kuvassa 25 on esitetty ensimmäisen kysymyksen tulokset. 52 9 8 7 6 5 Käyttää roolia (henk.) 4 3 2 1 0 Pääkäyttäjä Johtaja Muokkaaja Tarkastaja Roolit Kuva 25. Monivalintakysymys Työnkulku-moduulin rooleista, joita moduulin käyttäjät käyttävät. Asiakastyytyväisyyskyselyssä pyydettiin ottamaan kantaa seuraaviin väittämiin: 1. Projektien/markkinointikampanjoiden suorittaminen on nopeampaa Työnkulkumoduulin kanssa kuin ilman sitä. 2. Työnkulku-moduuli on helpottanut markkinointiaineistojen käsittelyä, kommentointia ja hyväksyntää. 3. Ota kantaa väittämään: Työnkulku-moduuli on parantanut ja tehostanut projektien ja markkinointikampanjoiden tiedonkulkua. 4. Työnkulku-moduuli on intuitiivinen, looginen ja helppokäyttöinen. 5. Työnkulku-moduuli on vähentänyt prosessissa syntyvien virheiden määrää Kuvassa 26 on esitetty vastausten tulokset ensimmäiseen väittämään. 79% vastaajista oli sitä mieltä, että Työnkulku-moduuli on nopeuttanut ainakin jossain määrin heidän työskentelyään. Työnkulku-moduulin odotettiin nopeuttavan kampanjoiden suorittamista, joten tämän kyselyn tulos ei yllättänyt. Tulos oli toivottu. 53 7% 14% 43% Samaa mieltä Jokseenkin samaa mieltä En osaa sanoa Jokseenkin eri mieltä Eri mieltä 36% Kuva 26. Markkinointikampanjoiden suorittaminen on nopeampaa Työnkulku-moduulin kanssa kuin ilman sitä. Kuvassa 27 on esitetty vastausten tulokset toiseen väittämään. 43% käyttäjistä oli sitä mieltä, että Työnkulku-moduuli on helpottanut markkinointiaineistojen käsittelyä, kommentointia ja hyväksyntää. 36% oli jokseenkin samaa mieltä. Eli yhteensä 86% vastauksista oli positiivisia. Tämän kysymyksen positiivinen tulos oli myös odotettavissa. 54 7% 7% 29% 57% Samaa mieltä Jokseenkin samaa mieltä En osaa sanoa Jokseenkin eri mieltä Eri mieltä Kuva 27. Työnkulku-moduuli on helpottanut markkinointiaineistojen käsittelyä, kommentointia ja hyväksyntää. Kuvassa 28 on esitetty vastaukset kolmanteen väittämään. 78% vastaajista oli samaa mieltä tai jokseenkin samaa mieltä siitä, että Työnkulku-moduuli on parantanut ja tehostanut projektien ja markkinointikampanjoiden tiedonkulkua. Kyselyn positiiviset tulokset oli odotettavissa, sillä esim. sähköpostitse kommunikointi usean henkilön kesken oli todettu hankalaksi. Parannettavaa kuitenkin jäi, sillä vain 21% oli eri mieltä tai jokseenkin eri mieltä. 55 7% 21% 14% Samaa mieltä Jokseenkin samaa mieltä En osaa sanoa Jokseenkin eri mieltä Eri mieltä 57% Kuva 28. Työnkulku-moduuli on parantanut ja tehostanut projektien ja markkinointikampanjoiden tiedonkulkua. Kuvassa 29 on esitetty vastausten tulokset neljänteen väittämään. 64 % vastaajista oli samaa mieltä tai jokseenkin samaa mieltä, että Työnkulku-moduuli on intuitiivinen, looginen ja helppokäyttöinen. Väittämässä sinänsä pyydetään ottamaan kantaan kolmea eri asiaa, mutta kaikki ovat tärkeitä asioita hyvässä käyttöliittymässä. Ne olisi ollut hyvä kysyä erikseen, mutta kyselystä haluttiin tehdä ytimekäs, minkä johdosta ne pistettiin samaan kysymykseen. 56 14% 21% Samaa mieltä Jokseenkin samaa mieltä En osaa sanoa Jokseenkin eri mieltä Eri mieltä 21% 43% Kuva 29. Työnkulku-moduuli on intuitiivinen, looginen ja helppokäyttöinen. Viimeisessä väittämässä haluttiin selvittää, että onko Työnkulku-moduuli vähentänyt prosessissa syntyvien virheiden määrää. Kuvassa on 30 esitetty vastausten tulokset. Jopa 72% käyttäjistä oli samaa mieltä tai jokseenkin samaa mieltä, että virheiden määrä on vähentynyt. Tulokset yllättivät positiivisesti, sillä noin kuukausi ennen kyselyä koko järjestelmän saatavuuden kanssa oli huomattavan paljon ongelmia, järjestelmä kaatuili, eikä Työnkulku-moduuli kyennyt synkronoimaan kaikkia tietoja ProofHQ-järjestelmän kanssa, jonka seurauksesta osa aineistojen kommentointiin ja hyväksyntään kuuluvista viesteistä jäi lähettämättä. Tuloksesta voisi päätellä, että ohjelmiston automaatio on onnistunut vähentämään inhimillisiä virheitä enemmän kuin tuottamaan ohjelmistollisia virheitä. 57 7% 21% 36% Samaa mieltä Jokseenkin samaa mieltä En osaa sanoa Jokseenkin eri mieltä Eri mieltä 36% Kuva 30. Työnkulku-moduuli on vähentänyt prosessissa syntyvien virheiden määrää. Ensimmäisessä kysymyksessä kysyttiin mitä Työnkulku-moduulin rooleja kysymykseen vastaaja käyttää. Kuvassa 31 on vielä esitetty aikaisempien väittämien vastauksien keskiarvot rooleittain. Ensimmäinen kysymys oli monivalintakysymys, eli osa vastaajista on siis vastannut useampaan rooliin kerralla. Kuvan perusteella voisi sanoa, että henkilöt jotka käyttivät muokkaaja-roolia olivat hiukan tyytymättömämpiä kuin muut. Kyselyyn ei kuitenkaan vastannut niin moni henkilö, että voisi varmuudella niin väittää. Harmaa palkki kertoo kaikkien kysymykseen vastanneiden keskiarvon. Keskimäärin kaikkien kysymyksien vastaukset olivat positiivisia, mutta parannettavaakin jäi. Moduulin toteutukseen voi silti olla tyytyväinen, sillä se on kuitenkin vasta ensimmäinen tuotantokäytössä oleva versio. 58 Samaa mieltä Jokseenkin samaa mieltä pääkäyttäjä johtaja muokkaaja tarkastaja keskiarvo En osaa sanoa Jokseenkin eri mieltä Eri mieltä Väittämä 1 Väittämä 2 Väittämä 3 Väittämä 4 Väittämä 5 Kuva 31. Vastausten keskiarvot kysymyksittäin ja rooleittan. Asiakastyytyväisyyskyselyn lopussa käyttäjiä pyydettiin myös antamaan vapaata palautetta. Osa asiakkaista valitti, etteivät olleet saaneet minkäänlaista koulutusta ohjelmiston käyttöön. Myös koko järjestelmän hitaudesta ja aikaisemmista kaatuiluista tehtiin valituksia. Kuukausikalenterinäkymään ei oltu tyytyväisiä. Kyselyn jälkeen kuukausikalenteri-näkymän rinnalle toteutettiin vielä Gantt-kaavio-näkymä menossa olevista kampanjoista ja niiden tehtävistä. Uuden näkymän uskottiin kuitenkin helpottavan kampanjoiden aikatauluttamista ja suorittamista oikeassa järjestyksessä. Asiakkailta saatiin positiivista palautetta uudesta näkymästä. 59 5 YHTEENVETO Diplomityössä lähdettiin ratkomaan asiakasyritysten markkinointikampanjoiden ja niiden aineistojen hallintaan liittyviä ongelmia. Asiakasyritykset käyttivät yrityksen A toteuttamaa Media-moduulia hallitsemaan heidän aineistojaan. Media-moduuli toteutti kuitenkin vain aineistonhallintajärjestelmille tyypillisiä toiminnallisuuksia, eivätkä ne riittäneet markkinointikampanjoiden ja niiden aineistojen hallintaan. Tämän johdosta Mediamoduulin rinnalle toteutettiin diplomityössä Työnkulku-moduuli, jonka tavoitteena oli toteuttaa projektinhallintajärjestelmille tyypillisiä toiminnallisuuksia. Markkinointiaineistojen kommentointia ja hyväksyntää varten diplomityössä tutkittiin ProofHQ ja ConceptShare -nimisiä järjestelmiä. Aluksi molemmat järjestelmät integroitiin osaksi Työnkulku-moduulia, jotta niistä saatiin enemmän tietoa. ConceptSharen vahvuuksiin kuului mahdollisuus asentaa se paikallisesti, minkä ansiosta se ei vaatinut yhteyttä ulkopuoliseen palvelimeen, se oli myös testattavalla kokoonpanolla nopeampi kuin ProofHQ. ProofHQ oli kuitenkin ominaisuuksiltaan huomattavasti edistyneempi ja se soveltui paremmin asiakasyritysten käyttötarpeisiin. Erityisesti ProofHQ:n aineistojen pyöritys, zoomaus ja tekstinvalinta toiminnallisuudet koettiin tarpeellisiksi, jotka puuttuivat tai olivat puutteellisia ConceptSharessa. Lopulta ConceptShare järjestelmän käytöstä luovuttiin puutteellisten toiminnallisuuksien ja Adam Software:n kehittämän Collaboration 2.0 -rajapinnan ohjelmistovirheiden ja rajoituksien takia. Pääasiassa tavoitteena oli tuoda markkinointikampanjoiden ja niiden aineistojen hallitseminen yksittäisen järjestelmän sisälle, jottei kampanjaan osallistuvien henkilöiden tarvitsisi käyttää toisistaan irrallisia sovelluksia ja tehdä epämääräistä kommunikointia ja tiedostojen jakamista sähköpostitse. Tavoitteena oli siis tuoda markkinointikampanjoihin liittyvä keskustelu, aineisto ja vedoksien hallinta samaan yksittäiseen paikkaan, Työnkulku-moduuliin. Kun markkinointiaineistot saatiin valmiiksi, voitiin ne helposti siirtää samassa järjestelmässä olevaan Media-moduuliin. Tavoitteiden saavuttamista tutkittiin asiakastyytyväisyyskyselyn avulla. Kyselyyn vastasi 14 henkilöä. Vastaukset olivat pääosin positiivisia ja niiden perusteella voidaan todeta, että 60 markkinointikampanjoiden avustaminen ohjelmallisesti ja automaation lisääminen prosessin eri vaiheissa helpottivat markkinointiaineistojen hallintaa, nopeuttivat markkinointikampanjoiden suorittamista, vähensivät inhimillisten virheiden määrää ja paransivat tiedonkulkua. 61 LÄHTEET [1] Jansen, R., Riemersma, F., 2008, Marketing Resource Management; The noble art of getting things done in marketing. Efficiently., MRMLOGIQ, ISBN: 978-90-8133051-0, First Edition, s. 54-55, 74-75, 109. [2] Frenkel, K.A., 2014, Automation of Business Processes Drives Benefits., CIO Insight, ISSN: 15350096, s. 1, URL: http://search.ebscohost.com/login.aspx? direct=true&db=bth&AN=99574395&site=ehost-live [viitattu 1.12.2014]. [3] Lähdesmäki, T., Hurme, P., Koskimaa, R., Mikkola, L., Himberg, T., Menetelmäpolkuja humanisteille - Tutkimusstrategiat, 2009, Jyväskylän yliopisto, humanistinen tiedekunta, Internet WWW-sivu, URL: https://koppa.jyu.fi/avoimet/hum/menetelmapolkuja/menetelmapolku/tutkimusstrateg iat [viitattu 12.2.2014]. [4] Jyväskylän yliopisto, Menetelmäpolkuja humanisteille - Toimintatutkimus, 2009, Jyväskylän yliopisto, humanistinen tiedekunta, Internet WWW-sivu, URL: https://koppa.jyu.fi/avoimet/hum/menetelmapolkuja/menetelmapolku/tutkimusstrateg iat/toimintatutkimus [viitattu 12.2.2014]. [5] Jyväskylän yliopisto, Menetelmäpolkuja humanisteille - Tapaustutkimus, 2009, Jyväskylän yliopisto, Humanistinen tiedekunta, Internet WWW-sivu, URL: https://koppa.jyu.fi/avoimet/hum/menetelmapolkuja/menetelmapolku/tutkimusstrateg iat/tapaustutkimus [viitattu 12.2.2014]. [6] Anttila, P., Tutkimisen taito ja tiedonhankinta, 1998, Metodix, Internet WWW-sivu, URL: http://www.metodix.com/fi/sisallys/01_menetelmat/01_tutkimusprosessi/02_tutkimis en_taito_ja_tiedon_hankinta/09_tutkimusmenetelmat/21_survey_eli_kyselytutkimus [viitattu 1.12.2014]. [7] Tolvanen, J-P., et al., 1998, Incremental Method Engineeringwith Modeling Tools, University of Jyväskylä, ISBN: 951-39-0303-6, s. 218-220. [8] Kemmis, S., 1980, Action Research in Retrospect and Prospect., ERIC, URL: http://files.eric.ed.gov/fulltext/ED200560.pdf [viitattu 1.12.2014]. [9] Underwood, R., 2008, OK, EVERYBODY, LET'S DO THIS!.,Inc., s. 40-42, URL: http://search.ebscohost.com/login.aspx? 62 direct=true&db=bth&AN=33118248&site=ehost-live [viitattu 1.12.2014]. [10] Marketing Weekly News, 2014, Computers, Software; Noosh Extends Its Project and Procurement Platform With ProofHQ Integration,NewsRX, s. 205, URL: http://search.proquest.com/docview/1567561872?accountid=136582 [viitattu 1.12.2014]. [11] Fernandez P., ProofHQ Bolsters Adobe Creative Suite Users With Online Proofing, 2012, MarketWired, Internet WWW-sivu, URL: http://www.marketwired.com/pressrelease/proofhq-bolsters-adobe-creative-suite-users-with-online-proofing1668840.htm [viitattu 22.2.2015]. [12] Wireless News, 2012, ProofHQ Provides Online Proofing for Adobe Creative Suite Users,Close-Up Media, Inc., URL: http://search.proquest.com/docview/1020917266? accountid=136582 [viitattu 22.12.2014]. [13] Bergström, S., Leppänen, A., 2009, Yrityksen asiakasmarkkinointi, Edita Publishing Oy, ISBN: 978-951-37-5447-1, s. 10. [14] Cohen, H., 2013, Internet WWW-sivu, URL: http://heidicohen.com/marketingdefinition/ [viitattu 3.1.2014]. [15] American Marketing Association, Definition of Marketing, 2013, AMA, Internet WWW-sivu, URL: http://www.marketingpower.com/AboutAMA/Pages/DefinitionofMarketing.aspx [viitattu 4.6.2015]. [16] Bergström, S., Leppänen, A., Yrityksen asiakasmarkkinointi, Edita, ISBN: 978-95137-5447-1. [17] Kotimaisten kielten keskus, Onko tarjooma oikein?, 2011, Kotimaisten kielten keskus, Internet WWW-sivu, URL: http://www.kotus.fi/index.phtml?i=532&s=2630 [viitattu 27.11.2014]. [18] Rope, T., Rope, M., 2010, Utilitaarinen markkinointi: markkinoinnin tuloslaskenta, Infor, ISBN: 978-952-5123-93-7. [19] Leventhal, R., 2005, "The importance of marketing", Strategic Direction, Emerald Insight, ISSN: 0258-0543, Vol. 21, Iss: 6, s. 3-4, URL: http://dx.doi.org/10.1108/02580540510594084 [viitattu 1.12.2014]. [20] Lindroos, J-E., Lohivesi, K., 2010, Onnistu strategiassa, Talentum, ISBN: 978-95263-2798-3, s. 219, 220. 63 [21] Kennedy, M., 2011, "Collaborative marketing for electronic resources", Library Hi Tech News, Emerald Insight, ISSN: 0741-9058, Vol. 28, 6, s. 22-24, URL: http://dx.doi.org/10.1108/07419051111173892 [viitattu 29.9.2015]. [22] Bengt, K., Lundgren, K., Froment, M., 2001, Benchlearning : good examples as a lever for development, Chichester : John Wiley & Sons, 2001, ISBN: 0-470-84200-8, English Edition, s. 34. [23] Salesforce.com, Best practice campaign management for marketing, 2009, Salesforce, Internet WWW-sivu, URL: http://www.slideshare.net/Shelly38/bestpractice-campaign-management-for-marketing [viitattu 6.4.2014]. [24] Gibson, A., 6 Stesps for a Successfull Marketing Campaign, 2011, UNDER30CEO, Internet WWW-sivu, URL: http://under30ceo.com/6-steps-for-a-successfulmarketing-campaign/ [viitattu 30.9.2014]. [25] Beth Lambert, Definitions of Common Marketing Roles, 2014, Eloqua Best Practices, Internet WWW-sivu, URL: https://community.oracle.com/community/topliners/knowit/blog/2014/03/28/definitions-of-common-marketing-roles [viitattu 31.5.2015]. [26] Basecamp, Last year alone, Basecamp helped over 285,000 companies finish more than 2,000,000 projects., 2014, Internet WWW-sivu, URL: http://basecamp.com/ [viitattu 10.6.2014]. [27] Real Story Group, Digital Workplace & Marketing Technology Vendor Map, 2013, Internet WWW-sivu, URL: http://www.realstorygroup.com/VendorMap/ [viitattu 17.02.2014]. [28] AIIM, What is Web CMS (or WCM)?, 2014, Association for Information and Image Management, Internet WWW-sivu, URL: http://www.aiim.org/What-is-Web-CMSWCM-System-Content-Management [viitattu 9.3.2014]. [29] Nath, M., Arora, A., 2010, Content management system : Comparative case study, Software Engineering and Service Sciences (ICSESS), 2010 IEEE International Conference on, IEEE, (viitattu 1.12.2014) [30] BusinessDictionary, document management system (DMS), WebFinance, Internet WWW-sivu, URL: http://www.businessdictionary.com/definition/documentmanagement-system-DMS.html [viitattu 9.3.2014]. [31] Regli, T., DAM vs. MAM - what's the difference?, 2012, Real Story Group, Internet 64 WWW-sivu, URL: http://www.realstorygroup.com/Blog/2455-DAM-vs.-MAMwhats-the-difference [viitattu 23.2.2014]. [32] Avid Technology, Alienbrain - Asset Management for Artist, 2014, Avid Technology, Internet WWW-sivu, URL: http://www.alienbrain.com [viitattu 7.7.2014]. [33] Southpaw Technology, Open Source Digital and Workflow Management - TACTIC by Shoutpaw, 2014, Shoutpaw, Internet WWW-sivu, URL: http://www.southpawtech.com [viitattu 7.7.2014]. [34] Youtsukura, T., et al., 2014, Asset Management for Digital Production Workflow, ACM, SIGGRAPH ASIA '09, URL: http://doi.acm.org/10.1145/1666778.1666792 [viitattu 1.12.2014]. [35] Sutton, D, Klein, T., 2006, Enterprise marketing management: the new science of marketing, John Wiley & Sons, ISBN: 0-471-26672-4, s. XIV. [36] Inkinen, V., 2003, ASP.NET, Docendo, ISBN: 951-846-145-7, s. 4. [37] Mono, Cross platform, open source .NET development framework, 2014, Xamarin, Internet WWW-sivu, URL: http://www.mono-project.com [viitattu 27.5.2014]. [38] DotGNU Portable.NET, DotGNU Project - GNU Freedom for the Net, 2014, GNU, Internet WWW-sivu, URL: http://www.gnu.org/software/dotgnu/pnet.html [viitattu 27.5.2014]. [39] MONO, Mono Compatibility, 2014, Mono/Xamarin, Internet WWW-sivu, URL: http://www.mono-project.com/Compatibility [viitattu 27.5.2014]. [40] INTERNATIONAL STANDARD, 2012, Information technology — CommonLanguage Infrastructure (CLI), ISO/IEC, URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c058046_ISO_IEC_23271_2 012(E).zip [viitattu 8.6.2015]. [41] ISO, We're ISO, the International Organization for Standardization. We develop and publish International Standards., International Organization for Standardization, Internet WWW-sivu, URL: http://www.iso.org/iso/home.html [viitattu 15.12.2013]. [42] Ecma International, Ecma International, Ecma International, Internet WWW-sivu, URL: http://www.ecma-international.org/ [viitattu 15.12.2013]. [43] Ecma International, 2012, Common Language Infrastructure (CLI), Ecma International, URL: http://www.ecma-international.org/publications/files/ECMAST/ECMA-335.pdf [viitattu 8.6.2015]. 65 [44] Adam Software, Marketing Execution Platforms (MEP), 2014, Adam Software, Internet WWW-sivu, URL: http://adamsoftware.net/en/knowledge-base/businessinformation/dam-information/marketing-execution-platform/ [viitattu 5.12.2014]. [45] ADAM Software, Products, 2014, Internet WWW-sivu, URL: http://adamsoftware.net/en/what-we-do/software-products/ [viitattu 14.5.2014]. [46] Zakas, N., 2009, Professional JavaScript for Web Developers, 2nd Edition, Wiley Publishing Inc, ISBN: 978-0-470-22780-0, 2nd Edition, s. 11. [47] ECMA International, 2011, Standard ECMA-262, ECMAScript Language Specification, Ecma International, URL: http://www.ecmainternational.org/publications/files/ECMA-ST/Ecma-262.pdf [viitattu 8.6.2015]. [48] StatCounter, StatCounter Global Stats - Top 5 Desktop, Tablet & Console Browsers from Sept 2013 to Sept 2014, 2014, StatCounter Global Stats, Internet WWW-sivu, URL: http://gs.statcounter.com [viitattu 20.10.2014]. [49] Nurseitov, N., et al., 2009, Comparison of JSON and XML Data Interchange Formats: A Case Study, URL: http://www.cs.montana.edu/izurieta/pubs/caine2009.pdf [viitattu 8.6.2015]. [50] Koskimies, K., Mikkonen, T., 2005, Ohjelmistoarkkitehtuurit, Talentum, ISBN: 95214-0862-6, s. 142-144. [51] ProofHQ, What is online proofing?, ProofHQ, Internet WWW-sivu, URL: http://www.proofhq.com/html/what-is-online-proofing.html [viitattu 25.2.2014]. [52] Nish, ConceptShare is Creative Operations Management (COM), 2012, ConceptShare, Internet WWW-sivu, URL: http://www.conceptshare.com/2012/11/conceptshare-is-creative-operationsmanagement-com/ [viitattu 23.2.2014]. [53] Element Software Pty Ltd, Great project management done right, Element Software Pty Ltd, Internet WWW-sivu, URL: http://www.copperproject.com [viitattu 19.5.2014]. [54] Concept Feedback LLC, Concept Feedback, Concept Feedback LLC, Internet WWW-sivu, URL: http://www.conceptfeedback.com [viitattu 19.5.2014]. [55] FILECOM OY, Kommentoi.com, FILECOM OY, Internet WWW-sivu, URL: http://www.kommentoi.com [viitattu 19.5.2014]. [56] ProofHQ, About ProofHQ, ProofHQ, Internet WWW-sivu, URL: 66 http://www.proofhq.com/html/about-us.html [viitattu 23.2.2014]. [57] ProofHQ, What is online proofing?, 2014, ProofHQ, Internet WWW-sivu, URL: http://www.proofhq.com/html/what-is-online-proofing.html [viitattu 2.6.2014]. [58] ProofHQ, ProofHQ API, Internet WWW-sivu, URL: http://api.proofhq.com [viitattu 11.2.2014]. [59] ConceptShare, About Us, ConceptShare, Internet WWW-sivu, URL: http://www.conceptshare.com/aboutus/company/ [viitattu 23.2.2014]. [60] Haikala I., Märijärvi J., 2004, Ohjelmistotuotanto, Talentum Media Oy, ISBN: 95214-0850-2, Kymmenes, uudistettu painos, s. 35-37, 47. [61] McConnell, S., 1996, Rapid Development: Taming Wild Software Schedules, Microsoft Press, ISBN: 1-55615-900-5, s. 72. [62] Pilone, D., 2003, UML Pocket Reference, O'Reilly & Associates, Inc., ISBN: 978-0596-00497-2, First Edition, s. 4, 49-55. [63] Object Management Group, 2012, UML Superstructure Specification, ISO. [64] Fielding, R., Representational State Transfer (REST), 2000, Internet WWW-sivu, URL: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm [viitattu 10.6.2014]. [65] Basecamp, The new Basecamp API, 2014, Basecamp, Internet WWW-sivu, URL: https://github.com/basecamp/bcx-api/ [viitattu 10.6.2014]. [66] Souleiman, H., O’Riain, S., Curry, E., 2012, Approximate semantic matching of heterogeneous events. In Proceedings of the 6th ACM International Conference on Distributed Event-Based Systems (DEBS '12)., ACM, ISBN: 978-1-4503-1315-5, s. 252–263. [67] Bai, F., Tao, W., 2010, Message Broker using Asynchronous MethodInvocation in Web Service and its Evaluation, IEEE, ISBN: 978-1-4244-6773-0, s. 265-273. 67 LIITTEET LIITE 1: Tyytyväisyyskyselyn lomake LIITE 1
© Copyright 2024