L OPUKSI - Tietojohtaminen vaatimusmäärittelyn tukena ICT-alan yrityksen toimintaympäristön muu

Tämän työn puitteissa on tehty seuraavia vaatimusmäärittelyprosessiin liittyviä työvaiheita:

- pohdittu mitä tietojohtamisella on annettavaa kyseiseen vaatimusmäärittelyyn - tutustuttu AinaComin toimintaympäristöön ja mallinnettu se

- kartoitettu toimintaympäristön nykytila järjestelmien osalta - visioitu tavoitetilaa kahden eri vaihtoehdon avulla

- kartoitettu vaatimuksia käyttäjiltä

- analysoitu, yhdistelty ja selvennetty käyttäjien vaatimuksia - tehty vaatimusten perusteella käyttötapaus-kaavio

- valittu tarkempaan kuvaukseen yksi keskeinen ja monia toimintoja sisältävä käyttötapaus (CTX-palvelun tilaus)

Tehtyjen työvaiheiden perusteella toimintaympäristön muutosprojektia varten voidaan nähdä tärkeimpinä asioina asiakastietojen parempi hallittavuus sekä sidosryhmien monipuolisempi huomioiminen uudessa toimintaympäristössä. Jatkotoimenpiteisiin vaatimusmäärittelyn osalta kuuluvat muun muassa vaatimusten ja käyttötapausten jatkoanalysointi sekä tarkempi kuvaus.

7 YHTEENVETO

Työn tavoitteena oli selvittää miten tietojohtaminen voidaan ottaa osaksi toimintaympäristön muutosta ja vaatimusmäärittelyä. Aihetta tutkittiin kirjallisen materiaalin sekä esimerkkiyrityksen AinaCom Oy:n toimintaympäristön muutos -projektin vaatimusmäärittelyn puitteissa.

Perinteinen vaatimusmäärittely ei ole ongelmatonta, ja siihen ei edelleenkään panosteta ohjelmistoprojekteissa tarpeeksi. Muuttuvat vaatimukset luovat painetta vaatimustenhallinnalle, ja esimerkiksi jäljitettävyyden ja yksiselitteisyyden aikaansaamiseksi tarvitaan uusia toimintatapoja tai työkaluja. Tietojohtamisen avulla voidaan paremmin hallita mitä tahansa yritykselle arvokasta tietoa (sen taiteenottamista, luomista, siirtämistä jne.), mutta sen avulla voidaan myös parantaa vaatimusmäärittelyn laatua sekä tehostaa toimintaympäristön muutos-projektia.

Toimintaympäristön muutos on enemmän kuin pelkkä uuden järjestelmän käyttöönotto, ja esimerkkinä käsitelty toiminnanohjausjärjestelmän (ERP) käyttöönotto on mittava projekti monin tavoin, ja on ensisijaisen tärkeää saada kaikki tieto suunnittelusta lähtien talteen.

Tieto on lisäksi saatettava sellaiseen muotoon ja paikkaan, että se on hyödynnettävissä kaikkien osallisten kesken, ja jossa sitä voidaan jalostaa ja jakaa taas uudelleen. Tämä onnistuu omaksumalla ERP-tiedon Ba sekä tiedon spiraali jokaiseen ERP-prosessin vaiheeseen välivaiheena.

Vaatimusmäärittelyprosessiin voidaan vaikuttaa positiivisesti tietojohtamisen keinoin, esimerkiksi omaksumalla vaatimusmäärittely yhdeksi tietojohtamisen prosessiksi. Tiedon spiraalin avulla esimerkiksi vaatimusten kartoitus- ja analysointivaihe voidaan toteuttaa hallitummin. Tietojohtamisella on paljon annettavaa sekä toimintaympäristön muutokseen että vaatimusmäärittelyyn. Tietojohtamisen näkökulma huomioimalla voidaan varmasti vaikuttaa IT-projektien parempaan onnistumiseen, kuten aiempi tutkimus on osoittanut.

Mitään informaatiotulvaa aiheesta ei ollut vielä saatavilla, joten lisätutkimukselle varmasti on jalansijaa.

Vaatimusmäärittelyprosessiin perehtymätön saattaisi kuitata prosessin tyyliin, ‖no kirjataas nyt ne vaatimukset‖, mutta ihan se ei riitä. Suurin syy miksi se ei riitä, on järjestelmien aikaansaamiseksi vaaditut työtunnit ja sitä myöden kustannukset.

Lisäksi järjestelmä halutaan saada joskus käyttöönkin, joten myös aikataulu on tärkeä huomioonotettava asia. Ohjelmistotuotannon prosessi, metodit ja vaiheet ovat olemassa syystä, ja samoin vaatimusmäärittelyn metodit, vaiheet ja laatuattribuutit.

Vaatimusmäärittelyä ei kannata lähteä tekemään ellei muun muassa yksiselitteisyydestä ja jäljitettävyydestä ole tarkoitus pyrkiä pitämään kiinni.

Vaatimusmäärittely on järkevää tehdä alusta asti kunnolla. Koska valitettavan usein kuulee epäonnistuneista IT-projekteista, joiden aikataulu on venynyt suhteettomasti, kustannukset ovat karanneet pilviin, tai koko projektista on jouduttu luopumaan, on aiheellista panostaa tähän ohjelmistoprosessin tärkeään alkuvaiheeseen. Ja mikäli siihen on saatavilla työkaluja ja auttavia näkökulmia, ne olisi syytä ottaa huomioon.

Tietojohtaminen tarjoaa näitä työkaluja ja näkökulmia, joten miksei yrittäisi niiden avulla saada vaatimusmäärittelyprosessia paremmin haltuun.

Tässä työssä on esitelty sekä toimintaympäristön muutokseen, ERP-järjestelmä esimerkkinä, sekä vaatimusmäärittelyprosessiin liittyen tietojohtamisen tarjoamia apukeinoja. Niiden myötä on tullut tutuksi tiedon spiraali, SECI-malli, jonka avulla tieto muuttuu ja tietoa voidaan sen avulla hallita. Esitellyssä McGuinnisin mallissa jokaiseen ERP-projektin vaiheeseen otetaan mukaan tiedon spiraali, ja tämän lisäksi luodaan tukiryhmä, Ba, jonka avulla tietoa hallitaan ja koordinoidaan. Näiden avulla kriittisen tärkeä ERP-tieto saadaan talteen ja jalostettua aina projektin ensi hetkestä alkaen.

Vaatimusmäärittelyprosessiin avuksi esiteltiin KARE, tiedolla rikastettu vaatimusmäärittely-malli sekä vaatimusmäärittelyn ottaminen yhdeksi tietojohtamisen prosessiksi. Molemmissa käsitellään tärkeimpiä vaatimusmäärittelyn vaiheita, kartoitusta, analysointia, määrittelyä ja hallintaa, ja esitetään niihin tietojohtamisen ratkaisuja.

Työn käytännön osuus käsitteli ICT-alan yrityksen, AinaCom Oy:n toimintaympäristön muutosprosessia. Yritykselle tehtiin tietojohtamispainotteinen vaatimusmäärittely asiakkaan näkökulmasta, ja sitä voidaan hyödyntää myös ulkoisen toimittajan apuna.

Teoreettinen viitekehys sekä käytännön osuus osoittavat tietojohtamisen tarjoamien näkökulmien, menetelmien ja työkalujen hyödyllisyyden vaatimusmäärittely- ja ERP-projektin tueksi.

Aiheen puitteissa olisi mielenkiintoista tehdä lisäksi tutkimus siitä, miten vaatimusmäärittelyjä ylipäänsä tämän päivän ohjelmistoalan yrityksissä ja mahdollisesti asiakasyrityksissä tehdään, mihin vaatimusmäärittelijät kaipaavat parempia käytäntöjä tai työkaluja, ja niiden perusteella tehdä toimintamalli tietojohtamispainotteisesta vaatimusmäärittelyprosessista, joka kiteytyy alan sen hetkisiin käytöntöihin ja nimenomaan niihin asioihin joihin helpotusta kaivataan.

Summa Summarum:

1. Toimintaympäristön muutokseen valmistautuvan yrityksen olisi hyvä päivittää oma materiaalinsa niin, että ohjelmistontarjoajalle on tarjota sisäänpääsy yrityksen toiminnan ymmärtämiseen. Ainakin nykyinen tila tulisi olla kuvattuna.

2. Tietokartan (knowledge map) ylläpitäminen palvelee myös toimintaympäristön muutoksessa, ja sen avulla projektiryhmä voidaan koota täsmällisemmin tiedoin ja ulkoinen toimittaja saa sisäänpääsyn myös organisaation tiedon lähteille.

3. Vaatimustenhallintaan uppoaa helposti mikäli sitä toteutetaan taulukoilla tai tekstitiedostoilla. Vaatimustenhallintatyökalut auttavat varmasti, ja mitä enemmän tietoa pystytään käsittelemään ilman manuaalisia vaiheita, sitä varmemmin tieto on ajan tasalla ja virheetöntä.

4. Projektissa oikeat ihmiset sekä asiakkaalta että toimittajalta ovat ensisijaisen tärkeitä. Tämän ryhmän tai muiden asiaankuuluvien tehokkaat kokoukset sekä epämuodolliset keskustelut vahvistavat yhteistä näkemystä tavoitellusta toimintaympäristöstä, ja vaikuttavat projektin onnistumiseen.

5. Iteratiivisuus vaatimusten kartoitus- ja analysointivaiheessa yhdistettynä tiedon spiraaliin tuottavat laadultaan parempia vaatimuksia, ja pienentävät huonojen vaatimusten pääsyä projektin loppuvaiheisiin, jolloin virheiden korjaaminen on moninkertaista.

6. Toiminnanohjaus- (ERP) projekti ei lopu käyttöönottoon, vaan siitä alkaa jatkuva kehitysprosessi. Tätä prosessia on mahdollista hallita paremmin omaksumalla tiedon spiraali jokaiseen ERP-projektin vaiheeseen (analyysi, suunnittelu, toimeenpano, tuotanto).

8 JOHTOPÄÄTÖKSET

Käytän työni viimeisen kappaleen vahvistamaan lukijan käsitystä siitä, miten tietojohtamisella voidaan tukea vaatimusmäärittelyä?, joka on tutkimukseni pääkysymys.

Tietojohtaminen ei ole vain joukko sääntöjä toteutettavaksi tietyissä kohdissa vaatimusmäärittelyprojektia, vaan se on ennen kaikkea ajatustapa, josta on hyötyä koko projektin ajan, ennen sitä ja sen jälkeen. Tietojohtamisen hyödyntäminen vaatii onnistuakseen avoimen mielen sen hyötyjä kohtaan, ja yhteisen/jaetun käsityksen tietojohtamisen hyödyllisyydestä sekä yleisesti projektin tavoitteista. Tietojohtaminen tarjoaa myös yksityiskohtaisempia tapoja, joita voidaan hyväksikäyttää ennen projektia ja projektin alkaessa/sen aikana.

Erityisesti vaatimusmäärittelyn alkuvaiheissa (kartoitus ja analysointi) tietojohtaminen tarjoaa toimintatapoja menestyksekkäämpään toteutukseen. Nämä alkuvaiheet ovat myös projektin kannalta kriittisimmät, sillä kuten aiemmin on todettu, virheenkorjaus on sitä kalliimpaa mitä myöhäisemmässä vaiheessa se havaitaan, ja nimenomaan vaatimustenkirjoitus ja niiden ymmärtäminen on koettu merkittäväksi vaatimusmäärittelyprosessin ongelmakohdaksi.

Tietojohtamispainotteisen ajatusmallin sisäistämisestä on hyötyä ennen projektin alkua:

Kun yrityksessä ymmärretään selvittää, mikä tieto on yritykselle tärkeää, eli mitä erityisesti tulee ottaa tulevan järjestelmän suunnittelussa huomioon, edessä olevalla vaatimusmäärittelyprojektilla on paremmat lähtökohdat kuin jos näin ei olisi tehty.

Kun yritys on mallintanut nykyisen toimintaympäristönsä ja järjestelmänsä niin, että kolmas osapuoli ymmärtää minkälaiseen ympäristöön järjestelmää ollaan rakentamassa. Lisäksi yrityksestä on löydyttävä henkilö tai henkilöitä, jotka ymmärtävät toimintaympäristön niin hyvin, että he pystyvät tukemaan sanallisesti tehtyä kuvausta.

Tietojohtaminen vaatimusmäärittelyprojektin aikana:

Vaatimusmäärittelijän perusteellinen perehdyttäminen toimintaympäristöön (ei voi ymmärtää vaatimuksia jos ei ymmärrä toimintaympäristöä). Tällä vaikutetaan suoraan paremmin kirjoitettuihin vaatimuksiin.

Tietokartan tekeminen projektin avuksi. Kirjataan kuka tietää mitäkin, joten jos vaatimusmäärittelijä tarvitsee lisätietoa esimerkiksi vianselvitys-prosessiin liittyen, hän löytää henkilön kartan avulla.

Tiedon spiraalin (sosialisaatio, ulkoistaminen, yhdistäminen, sisäistäminen) hyödyntäminen vaatimusten analysoinnissa. Esimerkiksi AinaComilla seuraavasti:

Vaatimusten kartoitus käyttäjiltä sähköpostikyselyllä (ulkoistus), vaatimuksen kirjaus joko yhdistämällä aiempaan vaatimukseen tai kirjaamalla uusi (yhdistäminen), vaatimuksen varmistus muokkauksen jälkeen alkuperäisen vaatimuksen kirjoittajalta (sosialisaatio), lopullisen vaatimuksen ymmärtäminen ja kirjaus (sisäistäminen).

Tekemässäni vaatimusmäärittelyprojektissa tietojohtamisesta oli erityisesti hyötyä ymmärtämällä tietojohtamisen periaatteet yleisellä tasolla. Koska vaatimusmäärittelyprosessi koetaan tutkimusten perusteella hankalaksi ja usein epäonnistuvaksi, mutta ensisijaisen tärkeäksi, en näe mitään syytä olla ottamatta vaatimusmäärittelyprojektiin tietojohtamisen näkökulmaa. Se vahvistaa kokonaisvaltaista ymmärrystä, ja sitä myötä mahdollisuutta ymmärtää ja kirjata (sekä analysoida) vaatimuksia oikein. Tekninen toteutus etenee kuten perinteisessäkin vaatimusmäärittelyssä, mutta laatu on parempaa.

LÄHTEET

Lähteet ovat aakkosjärjestyksessä. Kaikki sähköiset lähteet on tarkistettu tammikuussa 2013.

1. Aina Group Oyj, Yhtiötieto, Tammikuu, 2013

http://www.ainagroup.fi/konserni/yhtiot

2. Alavi, M., Leidner, D., ―Review: Knowledge management and knowledge management systems: Conceptual foundations and research issues‖, MIS Quarterly, Vol. 25. No.1, Maaliskuu, 2001, pp. 107-139,

http://www.jstor.org/stable/3250961

3. Alivuori-Pöyry, T., Fallström, M., Mara-Puumalainen, M., Mutka, S., Palmroth, A., Valtanen, J., ‖Tietopääomaraportti: AinaCom Oy‖, Lappeenrannan teknillinen yliopisto, AC50A0200 Tietojohtaminen ja tietopääoman mittaaminen, harjoitustyö, 2010

4. Avison, D., Fitzgerald, G., Where now for development methodologies?.Commun.

ACM, Vol. 46, No.1, 2003, pp.78-82, http://doi.acm.org/10.1145/602421.602423 5. Barclay, R., Murray, P., ―Knowledge praxis: What is knowledge management?,

1997,

http://www.imamu.edu.sa/Scientific_selections/abstracts/Abstract%20%20IT%20%

203/What%20Is%20Knowledge%20Management.pdf

6. Birk, A., Surmann, D., and Althoff, K.-D. "Applications of Knowledge Acquisition in Experimental Software Engineering", 11th European Workshop on Knowledge Acquisition, Modeling, and Management, 1999, pp. 67-84

7. Blomqvist, K-M., Kyläheiko, K., ―Main challenges of knowledge management:

Telecommunications sector as an example, 8 th International Conference on Management of Technology (IAMOT), Miami, USA, Helmikuu 21-25, 2000, pp.10 8. Boehm, B., ―A spiral model of software develeopment and enhancement‖,

Computer, Vol. 21, No. 5, Toukokuu 1988, pp. 61-72, http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=59&isnumber=6

9. Gacitua, R., Ma, L., Nuseibeh, B., Piwek, P., de Roeck, A. N., Rouncefield, M., Sawyer, P. Willis, A., Yang, H., ―Making Tacit Requirements Explicit‖, Proceedings of the Second Int Managing Requirements Knowledge (MARK) Workshop, 2009,

pp. 40-44,

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5457349&isnumber=54 57335

10. Curtis, B., Krasner, H., Iscoe, N., ―A field study of the software design process for large systems‖, Communications of the ACM, Vol. 31, 1988, pp. 1268-1287, http://cs.njit.edu/~kirova/BC-SDP.pdf

11. Dalkir, K., ―Knowledge management in theory and practice‖, Elsevier, 2005.

12. Davenport, T., Prusak, L, ―Working knowledge: How do organizations manage what they know‖, Harward Business School Press, 1998.

13. Davis, A., ―Software Requirements: Objects, Functions, and States‖, Prentice-Hall, Inc., Upper Saddle River, USA, 1993

14. Davis, A., Dieste, O., Hickey, A., Juristo, N., Moreno, A., ―Effectiveness of requirements elicitation techniques: Empirical results derived from a systematic review‖, Proceedings of 14^th IEEE International Requirements Engineering

Conference, Syyskuu 11-15, 2006, pp. 179-188 Information Science and Knowledge Management, Vol. 12, 2007, pp.21-63

17. Haikala, I., Märijärvi, J., ‖Ohjelmistotuotanto‖, Talentum Media Oy, Gummerrus Kirjapaino Oy, Jyväskylä, 2006

18. Haumer, P., Pohl, K.,Weidenhaupt, K., "Requirements elicitation and validation with real world scenes," Software Engineering, IEEE Transactions on Software

Engineering, vol.24, no.12, 1998 pp.1036 – 1054,

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=738338&isnumber=159 27

19. Hickey, A.M., Davis, A.M., "Requirements elicitation and elicitation technique selection: model for two knowledge-intensive software development processes," System Sciences, Proceedings of the 36th Annual Hawaii

International Conference, Tammikuu 6-9, 2003,

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1174229&isnumber=2 6341

20. Johnson, W., Feather, M., "The KBSA Requirements/specification Facet: ARIES‖, Proceedings of the 6^th annual Knowledge-Based Software Engineering Conference

(KBSE), Syyskuu 22-25, 1991, pp.48-56,

URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=638020&isnumbe r=13857

21. Kaindl, H, Svetinovic, D., ―On confusion between requirements and their representations‖, Requirements Engineering, Vol. 15, No. 3, 2010, pp. 307-311 22. Kasvi, J., Vartiainen, M., Hailikari, M., ―Managing knowledge and knowledge

competences in projects and project organizations‖, International Journal of project

Management, 2003, pp. 571-582,

http://ejournal.narotama.ac.id/files/Managing%20knowledge%20and%20knowledg e%20competences%20in%20projects%20and.pdf

23. Kauppakamariverkko, Yritysesittely, AinaCom Oy, Tammikuu, 2013, http://www.kauppakamariverkko.fi/index.php/kkverkko/Yritysesittely/AinaCom-Oy 24. Kianto, A., ‖Tietojohtaminen: mitä, miksi ja miten?‖, Johtamisen käsikirjat,

Kauppalehti, 2011

25. Lintula, H., ‖Vaatimusten validiointi ja verifionti‖, Pro gradu-tutkielma, Kuopion yliopisto, Informaatioteknologian ja kauppatieteiden tiedekunta,

Tietojenkäsittelytieteen laitos, 2004,

http://cs.uef.fi/uku/tutkimus/Teho/helingradu.pdf

26. McGuinnis, C., Huang, Z., ―Incorporation of knowledge management into ERP continuous improvement: a research framework‖, Issues in Information Systems, 2004, pp. 612-618, http://iacis.org/iis/2004/McGinnisHuang.pdf

27. McGuinnis, T., Huang, Z., ―Rethinking ERP success: A new perspective from knowledge management and continuous improvement‖, Information &

Management, Vol. 44, No. 7, Lokakuu, 2007, pp. 626-634, http://www.sciencedirect.com/science/article/pii/S0378720607000705

28. Lindvall, M., Sandahl, K., ―Practical implications of traceability‖, Software - Practice and Experience, Vol. 26, No. 10, 1996, pp. 1161-1180

29. Loucopoulos, P., Karakostas, V., ―System requirements engineering‖, McGraw-Hil, Inc., New York, NY, USA, 1995

30. Nonaka, I., Takeuchi, H., ―The Knowledge-creating company: how Japanese companies create the dynamics of innovation‖, Oxford University Press, New York, USA, 1995

31. Nonaka, I, Konno, N., ―The concept of ‗Ba‘: building a foundation for knowledge creation‖, California Management Review, Vol. 40, No. 3, 1998, pp. 40–54, http://km.camt.cmu.ac.th/mskm/952701/Extra%20materials/Nonaka%201998.pdf

32. Nuseibeh, B., Easterbrook, S, ―Requirements engineering: A roadmap‖, Proceedings of the ACM Conference on the Future of Software Engineering, 2000, pp. 35-46

33. CT20A4000, Ohjelmistotuotanto, Vaatimusmäärittelydokumentti, kevät 2011 34. Pilat, L., Kaindl, H., ―A knowledge management perspective of requirements

engineering‖, Research Challenges in Information Science (RCIS), 2011 Fifth International Conference, , 19-21 Toukokuu 19-21, 2011, pp.1-12, http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6006849&isnumber=60 06819

35. Ratchev, S., Urwin, E., Muller, D., Pawar, K.S, Moulek, I., ―Knowledge based requirement engineering for one-of-a-kind complex systems‖, Knowledge-Based Systems, Vol. 16, No. 1, Tammikuu, 2003, pp. 1-5, http://www.sciencedirect.com/science/article/pii/S0950705102000278

36. Rajagopal, P., ―An innovation—diffusion view of implementation of enterprise resource planning (ERP) systems and development of a research model‖, Information & Management, Vol. 40, No 2, 2002, pp.87-114, http://www.sciencedirect.com/science/article/pii/S0378720601001355

37. Regnell, B., ―Requirements engineering with use cases – A basis for software development‖, Lund university, Department of communication systems, Lund institute of technology, 1999, http://uml.org.cn/RequirementProject/pdf/thesis.pdf 38. Robertson, S., Robertson, J., ―Mastering the requirements process‖, Addison

Wesley, Inc., Harlow, England, 1999

39. Rus, I., Lindvall, M., Sinha, S., ―A state of the art report: Knowledge management in software engineering‖, The University on Maryland, Defence Technical Information Center, 2001

40. Sarvary, M., ―Knowledge management and competition in the consulting industry‖, California Management Review, Vol. 41, No. 2, 1999, pp. 95–106, http://csnet.bsru.ac.th/~nisakorn/Ph.D%20Subject%20Knowledge%20Managemen t%20/KM/Package/Class%2010/sarvary%201999.pdf

41. Sommerville, I., ―Software engineering‖, Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1995

42. Sommerville, I., Sawyer, P., ―Requirements engineering: A good practice guide‖, John Wiley & Sons, Inc., New York, NY, USA, 1997

43. Vandaie, R., ―The role of organizational knowledge management in succesfull ERP implementation projects‖, Knowledge-Based Systems, 2008, pp. 920-926, http://lpis.csd.auth.gr/mtpx/km/material/KBS-21-8.pdf

44. Webster, J., Brown, G., Zweig, D., Connelly, C. Brodt, S., Sitkin, S., ―Beyond knowledge sharing: Withholding knowledge at work‖, Research in Personnel and Human Resources Management, Emerald Group Publishing Limited, Vol. 27, 2008, pp.1-37

45. Wielinga, B. Sandberg, J. Schreiber, G. ―Methods and techniques for knowledge management: What has knowledge engineering to offer?‖, Expert Systems with

Applications, Vol. 13, No. 1, 1997, pp. 73-84,

http://www.sciencedirect.com/science/article/pii/S0957417497000237

46. White, S.M., "Application of cognitive theories and knowledge management to requirements engineering," Proceedings of the 4th annual IEEE Systems

Conference, Huhtikuu 5-8, 2010, pp.137-142,

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5482489&isnumber=5 482314

47. Wiig, K., ―Knowledge management foundations‖, Schema Press, Arlington, 1993.

48. Zave, P., Jackson, M., ―Four dark corners of requirements engineering‖. ACM Transactions on Software Engineering and Methodology, Vol. 6,, No. 1, 1997, pp.

1-30, http://doi.acm.org/10.1145/237432.237434

LIITE 1. Vaatimuskysely 14.6.2012

Hei ja hyvää alkanutta kesää! Jos et käytä työssäsi PUHTI- tai CRM-järjestelmää, voit unohtaa tämän viestin, mutta kuittaatko kuitenkin minulle jotain, jotta tiedän viestin tulleen perille.

Tämä viesti on siis sinulle, joka käytät jollain tavalla työssäsi joko PUHTIa tai CRM-järjestelmää. Teen lopputyötäni AinaCom/Tietohallinnolle ja tarkoituksenani olisi kerätä tässä vaiheessa ajatuksia/odotuksia käyttäjiltä tulevaisuudessa PUHTI:n korvaavalle järjestelmälle.

Tarvitsisin siis apuasi seuraavalla tavalla.

Mihin tarkoitukseen käytät PUHTIa?

1. Listaa ranskalaisilla viivoilla kaikkia toimintoja mitä teet?

esim. Teen tilauksen, perustan asiakkaan, tulostan laskun jne

2. Ideoi ja listaa toimintoja joita haluaisit tehdä, tai jotka ovat ongelmakohtia ja huonosti suunniteltuja toimintoja? (vain mielikuvitus on rajana!)

Mihin tarkoitukseen käytät CRMää?

1. Listaa ranskalaisilla viivoilla kaikkia toimintoja mitä teet?

2. Ideoi ja listaa toimintoja joita haluaisit tehdä, tai jotka ovat ongelmakohtia ja huonosti suunniteltuja toimintoja? (vain mielikuvitus on rajana!)

Kaikki ja kaikenlaiset vastaukset ovat enemmän kuin tervetulleita.

Kiitos etukäteen! Aurinkoisin terveisin, Anna Palmroth (p. 0404511788)

LIITE 2. Vaatimukset

Asiakastietoihin liittyvät vaatimukset

1. Asiakkaan/asiakkuuksien tietojen (perustiedot, yhteystiedot, vastuumyyjä, laskutustiedot, tilaukset, sopimukset, työnkierto, palvelut, tuotteet etsiminen asiakasnumerolla, sopimusnumerolla, laskun numerolla, vikatilausnumerolla, osoitteella, tilausnumerolla, puhelinnumerolla, nimellä

2. Asiakkaan/asiakkuuden perustaminen ja tietojen (osoitteet, vastuumyyjä, yhteystiedot, asiakasluokittelu) ylläpito

3. Asiakaspalautteen kirjaus

4. Asiakaskontaktoinnin seuranta ja kirjaus

5. Asiakkaisiin liittyvät poikkeussäännöt selkeästi esille (esimerkiksi poikkeava hinnoittelu)

6. Asiakkuuksien määrän hakeminen 7. Reklamaation kirjaus + käsittely

8. Tarjousten, asiakastapaamisten, kontaktien, tärkeiden soittojen ja tapahtumien kirjaus/selailu

9. Myyjien asiakaslistojen seuraus

10. Asiakastapahtumien seuraus historiasta enemmän kuin viimeiset 30 päivää

11. Asiakkaiden yhteystietojen haku sähköpostijakeluihin ja sms-jakeluihin (vikailmoitukset+markkinointi-ilmoitukset

12. Asiakkaan kaupparekisteritietojen ja SLA-tasojen tarkistus

Tuotetietoihin liittyvät vaatimukset

1. Tuotekohtaisten yhteystietojen ylläpito/selailu 2. Tuotemäärien hakemien

3. Varastotuotteiden hintojen tarkistus 4. Varastotuotteiden määrien tarkistus

5. Tuotteiden tili-kustannuspaikkojen selvittely 6. Tuotteen perustaminen

7. Tuotteisiin liittyen inventointi, tuotekoodit, varastosaldot, laskutus 8. Varastosaldojen ja hintojen selailu

(jatkuu)

LIITE 2. (jatkoa)

9. Asiakkaan käytössä olevien tuotteiden listaus /vanhojen tuotteiden listaus 10. Varastosiirrot

11. Toimitettavan tuotteen saatavuustiedot tilausnäkymälle 12. Tuotteiden, varastosaldojen ja hintojen etsiminen

13. Tuotteen hinnan tarkistus (vrt. sis.osto hinta ja myyntihinta)

14. Varastotoiminteet jotka integroituvat tukkureihin ja esim Onnisen palveluvarastoon

Tilauksiin ja sopimuksiin liittyvät vaatimukset

1. Tilauksen avaaminen, muokkaaminen, peruminen 2. Tilauksen tuotteiden/palveluiden päivittäminen

3. Tilausten tarkistelu/selailu/hakeminen puhnrolla, tilausnumerolla, nimellä, osoitteella ja päivämäärällä

4. Luopumistilauksen tekeminen

5. Samaa tilausta pitää pystyä katsomaan usealta koneelta yhtä aikaa 6. Asiakas- tilaus- ja sopimusnumeroiden selkeys (nyt sekavat)

7. Sopimusten hakeminen puhnrolla, tilausnumerolla, nimellä, osoitteella ja päivämäärällä

8. Uuden sopimuksen tekeminen 9. Sopimusten selailu

10. Vanhojen sopimusten oikeellisuuden tarkistus

11. Selkeämpi sopimusnumerointi, yksi sopimusnumero/sopimus 12. Sopimusten tarkistaminen

13. Sopimustuotteiden ja sopimusaikojen/hintojen etsiminen 14. Sopimusten päättäminen

15. Asiakkaan kaikki sopimukset yhteenvetona

Laskutukseen liittyvät vaatimukset

1. Hetilaskun tekeminen/tulostus 2. Käteismyynti

(jatkuu)

LIITE 2. (jatkoa)

3. Laskujen haku tili- ja kustannuspaikkatietojen perusteella (esim. palautetut takuumaksut, poikkeaville tileille kirjatut tulot, esim kulujen oikaisut)

4. Laskujen haku 23 % alvista poikkeavan hinnaston mukaan laskutetut (esim vanhat 22 % tai 0 %)

5. Operaattorilaskujen toteuman tarkkailu 6. Laskujen selailu ja tarkistus

7. Laskun tekeminen

8. Laskutuksen oikeellisuuden tarkistus

9. Laskun selkeys sekä asiakkaalle että meille. Pitää näkyä samanlaisena molemmille.

10. Koontilaskulla pitäisi olla hakukenttä niin, että voi hakea esim nimellä käyttäjää.

(kuten Enfon arkistossa)

11. Järjestelmä laskee päivähinnan kk-maksulle.

12. Rinnakkaishyvityslasku ei saa olla summaltaan 0 euroa, vaan -laskunsumma, esim -700 eur.

13. BCCS laskuilla pitää näkyä numerot + niiden liikenne. Samoin kuin esim matkapuhelinliittymissä.

14. Kertalaskut ja hyvityslaskut myös verkkolaskuina 15. Yksi lasku kaikista palveluista

16. Laskujen korjaaminen vaivatonta ja mahdollisuus lähettää korjatut hetilaskutkin verkkolaskuna saman tien.

Raportointiin liittyvät vaatimukset

1. Erilaisia raportteja: Avattujen vikatöiden kehitys, UCX-laskutus, työn alla olevat aston tilaukset eur/kpl, valmistuneet tilaukset eur/kpl/kk, data- lanka- ktv-liittymien seuranta

2. Viestintävirastolle raportti hmv-laskentaa varten 3. Monipuolinen raportointi, tarkastelu eri näkökulmista.

4. Puhti + cognos ovat yhdessä hyvä ratkaisu raportointia ajatellen (sisäinen laskenta näkökulmasta)

(jatkuu)

LIITE 2. (jatkoa)

5. Helposti raportteja asiakkaan sopimuksista ja laskutuksesta sekään omaan että asiakkaan käyttöön

6. Yksinkertaiset tarkistusajot ja virhelistat 7. Automaattitarkistuksia

8. Tuotteiden ja tapahtumisen (esim vikatyöt) kappalemäärät ja niiden muutokset 9. Tuotantokustannusten yhdistäminen samaan järjestelmään, asiakaskannattavuus 10. Kaikki tapahtumahaut ja raportit myös graafeina

11. Raporttien joustavuus ja muutosmahdollisuus raportointityökalulla (esim.

kuutiotarkastelu)

12. Loppulunastusten läpikäynti kuukausittain jotta tuotot saadaan kannattavuuslaskennassa oikeille tuotteille ja liiketoiminnoille

13. Kirjanpidon valmistuessa analyysi kyseisen kuukauden laskutuksen oikeellisuudesta lähinnä tuotteen ja liiketoiminnan näkökulmasta.

14. Mistä tuotteista kyseisen tilin ja kustannuspaikan tuotot muodostuvat ja poikkeamien seuranta

Myyntiin liittyvät vaatimukset

1. Myynnin kirjaamiset ja niiden seuranta tavoitteiden osalta 2. Myynnin johdolle myynnin seurantaa varten Dashboard-malli, 3. jossa myyjille asetetaan tavoitteet+seuranta, näkyy reaaliaikaisena.

4. Nyt tehdään manuaalisesti: haetaan itse luvut ja muokataan myyntitiimeittäin suhteessa tavoitteisiin"

5. Voitettujen kauppojen ja niiden summien kirjaus 6. Voitettujen kauppojen välitys tuotantoon

7. Rahoitustaulukon ja tarjousten tarkistus 8. Uusien kauppojen välitys tuotantoon 9. Tarjouskannan ylläpito

10. Raportointi: myynti/asiakas/seurantajakso, käynnit/asiakas/seurantajakso, tarjouskanta.

11. Tarjouksen tekeminen

(jatkuu)

LIITE 2. (jatkoa)

12. Tarjousten selailu 13. Vain yksi tarjouslaskuri

14. Automaattisesti tarjous.pdf, jossa on selkeästi eroteltu pyydetyt tuotteet + tarjouksen kaupalliset ehdot sekä liitteenä valittujen tuotteiden tuotekortit,

In document Tietojohtaminen vaatimusmäärittelyn tukena ICT-alan yrityksen toimintaympäristön muutoksessa (sivua 78-102)