ITKE54 Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa

Transkriptio

1 ITKE54 Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa Jukka Heikkilä Ville Seppänen Elektroninen liiketoiminta Tietojenkäsittelytieteiden laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto tel:

2 ITK E54 v Tietojärjestelmien haasteet Monikanavaisen liiketoimintamallin mukainen toiminta Kuvaaminen, tapahtumanhallinta ja sessionhallinta Integrointi olemassaoleviin järjestelmiin Integrointi sisäisiin ja ulkoisiin tietojärjestelmiin Ohjelmistoarkkitehtuuri ja komponentit Kuvausten ja versioiden hallinta Järjestelmän suunnittelun haasteet prosessi (suunnittelu ja käytönaikainen kehittäminen) kuvaaminen johtaminenjaarviointi Demot 2

3 Kertaus: Integraattorille hommia? (esim. IBM extranet -konsepti) Business Value Business Strategy + Process E-Commerce Services Knowledge Management Suppliers SCM ERP CRM Customers Outsourced development, operation, security, etc. Business Intelligence Enablement Services Web + IT Integration Technology Value E.g. data mining I.e., tailoring 3

4 Kertaus: Toimialat eri asemassa (Porra, 1999) Perinteiset toimialat: materiaalisten tuotteiden tuotanto, markkinointi ja toimitukset (esim. autoteollisuus) Tietoverkot tukena em. toiminnoissa ja asiakaskontaktin hallinnassa Muuntuvat toimialat: materiaalisten mutta digitalisoitavissa olevien tuotteiden tuotanto, markkinointi ja toimitukset (esim. kustantaminen, elokuvateollisuus) Tietoverkot mahdollinen jakelukanava Digitaaliset toimialat: digitaalisten tuotteiden kauppa Internetissä (esim. ohjelmistot, digitaaliset palvelut, viihde) Tietoverkot ensisijainen toimintaympäristö 4

5 Kertaus: Monikanavamalli TV set CATV DVB Kiinteä pääte PSTN, ISDN, xdsl Gateways? Router GSM, GPRS, UMTS Mobiilipääte Muut oheis- laitteet (maksut,, ID, tulostimet, WLAN, LON) Router Router Portaalit Router IP-Network (IPv6) Router Palvelun tuottajat

6 Kertaus: 3-tier arkkitehtuuri 6

7 Kertaus: The components of Complex, Integrated Systems (c.f. Porra, 1999) 7

8 Olemassa oleva infrastruktuuri Tj:t on kehitetty eri tarkoituksiin eri tavoittein eri näkökulmien intressit mielessä viisi arkkityyppiä

9 Arkkityypit arvoketjussa 3. Support activities / functions 4. Inbound logistics Infrastructure Management / Personnel administration R&D and Innovations Purchasing Production Outbound logistics Basic activities/functio ns Marketing & Sales Service Valueadded 5.??? 9

10 1. Automatisoidut toiminnot Selkeä, määrämuotoinen kohde (esim. kirjanpito, laskutus, henkilöstöhallinto, varastonvalvonta) Vertikaalinen toiminnon näkemys liiketoimintaan Tavoitteet: kustannusten karsiminen kapasiteetin lisäämien virheiden vähentäminen kommunikointi tietokannan välityksellä Ongelmia: tietojärjestelmä ei kata kaikkea, poikkeuksien käsittely hankalaa hidas kehittää, nopea ostaa -> riippuvuus toimittajasta tietojen pilaantuminen (degeneroituminen) jämähtäminen ja puutuminen informaatio- ja päätöksentekokustannukset kasvavat helposti

11 2. Työkalupakki Osaavan käyttäjän tuottavuusvälineistö Yksittäisen käyttäjän näkökulma Tavoitteet: oman tuottavuuden parantaminen ja järkiperäistäminen osaavissa käsissä lisätuottavuutta yhteensopivuus: työn joustava jakaminen ja organisointi tietojärjestelmien tilkkiminen joustavilla työkaluilla Ongelmia kokonaisuus unohtuu helposti kustannukset karkaavat versionhallinta lyhyt elinkaari ylimielisyys ja osaamattomuus tuen tarve kasvaa korkeat koordinaatiokustannukset

12 3. Ryhmätyön ja org.muistin tuki Ryhmänvälineistöajastajapaikastariippumattomaan (etä-)työskentelyyn (esim. työkalut, rakenteiset dokumentit ja kommunikaatio) Ryhmän näkökulma yhteisen tuloksen tekemiseen Tavoitteet: Asiantuntemuksen kertymisen tukeminen Ideasta markkinoille kuluvan ajan lyhentäminen Yhteistyön ja koordinaation parantaminen (myös organisaatioiden välillä) Työn kehittäminen Ongelmia Työläitä kehittää ja ottaa käyttöön Monimutkainen, osin epäluotettava tekniikka Työskentelytapojen oppiminen ja poisoppiminen Yhteensopivuus muihin tietojärjestelmiin

13 4. Liiketoimintaprosessin kehittäminen Asiakaslähtöinen keskittyminen olennaiseen (esim. SAP, BAAN, PeopleSoft, IBS, Visma yms. räätälöitävät ohjelmistopaketit) Palvelu- ja tuotantoprosessi asiakkaan saaman lisäarvon näkökulmasta Tavoitteet: Toimintojen yksinkertaistaminen ja virtaviivaistaminen Vastuiden siirtämisen vähentäminen Tuotteen/palvelun läpimenoajan lyhentäminen Laadun ja toimitusvarmuuden parantaminen Ongelmia: Kivuliaita muutosprosesseja Hitaita toteuttaa Riskialttiita Liiallinen laihduttaminen

14 5. ebusiness Asiakkaan/toimittajan kohtaaminen tietojärjestelmässä (esim. WWW-kauppapaikat, supplywebit) Liiketoiminnan näkökulma Tavoitteet: Keskittyminen liiketoiminnan tukemiseen Lisäarvoa asiakkaalle Asiakaskontaktin hallinta Asiakkaasta tietojärjestelmän käyttäjä Ongelmia Liiketoimintariski ja tietojärjestelmäriskit yhdistyvät samassa hankkeessa Yksi markkinointi-/jakelukanava lisää Maailmanlaajuiset markkinat globaali kilpailu ja erilaiset markkina-alueet

15 Miten 5. sopii yhteen 1-4:n kanssa? Esim. std-kaupankäynnin vaiheet ja poikkeukset? Ostaminen Tarjous / vastatarjous Tilaus Tilausvahvistus Toimitus Maksaminen Valittaminen Reklamaatio Palautus Hyvitys Esim. vaikutus asiakassuhteeseen ja maksamiseen Mitätehdään? peritään, lykätään, tyrkytetään luottoa? Mitä ei saa tehdä ja mitä tekemättä jättäminen tarkoittaa? 15

16 Keskeiset kysymykset: Miten hallita transaktioita? Teknisesti Pystytäänkö implementoimaan nopeasti ja tehokkaasti mitä tehdä itse, mitä ostaa ulkoa? millä ansaintalogiikalla pitääkösopimus Asiakkaan prosessin välittyminen suunnitelmaan Miten saada oikea tieto ja kuvata se? Mistä tietoa asiakkaan ongelmasta/sykleistä sitoumukset Käsikirjoituksen puutteet kauppapaikat, huutokaupat, pörssit, yhteisostaminen Eri osapuolten järjestelmien integroiminen palvelemaan asiakkaan prosessia 16

17 Liiketoimet yli kanavamallin Business relation (Pre-Transactional) Capability & Needs Supplier Proposals Customer Capability & Needs Commitments Provision Sales & Delivery Fullfilments Assessments Procurement Usage Business relation (Post-Transactional) 17

18 Tasapainoilua strategian, prosessin ja komponenttien välillä (Allen & Frost, 1998) 18

19 Strategia erityisesti verkostot ->ITKE50 Prosessit Kuluttajan/asiakkaan näkökulma -> ITKE59 Rakentajan näkökulma -> ITKE54, ITKE51, ITKT57 Komponentit Erityisesti arkkitehtuurinäkökulma -> ITKE54 19

20 Prosessi (Turban et al., 2002) 20

21 And the suggested solution is: Business Models, Architectures and Platforms Business Model makes the relationship between constituents of business visible (see e.g. Osterwalder & Pigneur, 2001) -> ITKE50 The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. (Bass, Clements, and Kazman) But an architecture for ebusiness -system is a subset, or superset of offerings services applications 21

22 Viitekehyksiä prosessien ja komponenttien yhteensovittamiseen 22

23 Yleise mmin: ISAframe work: Zachman,

24 Complete ISA: Sowa & Zachman, 1992 Three additional dimensions: People Agent Work Time Time Cycle Motivation Ends Means 24

25 Compl ete ISA (Sowa & Zachman, 1992) 25

26 Extension to ISA: Information FrameWork (IFW) Change of focus: from systems to corporatewide information to reusable industry-specific components from systems development to information utilization from rigid to flexible functionality, faceting i.e., multiple views Change of metaphor: from construction of buildings to city planning Used originally for Information management in financial services in Europe 26

27 Component based architecture Architecture is the foundation for the swproduct line. Architecture forms the organizational plan for component development. Architecture is the root of system qualities. Architecture ensures that variability across products can be accomplished by changes confined to one or a select set of components. 27

28 Komponentit arkkitehtuurissa (Häkkinen, 2000) There is a gap in here! Tieto Toiminto Verkko Aika Ihmiset Motivaatio Soveltamisala Yritysmalli Järjestelmämalli Teknologia -malli Komponentit Toimiva järjestelmä Ohjelmistoarkkitehtuuri Sovelluskehys & k i lli komponenttimalli OHJELMISTO- KOMPONENTTI 28

29 Komponenttityypit (Häkkinen & Peltola, 1998) Räätälöidyn komponentin: tietty toiminta tietyssä ympäristössä räätälöitynä valmistajalta Valmiskomponentti on ohjelmistojen kehittäjille uudelleenkäytettäväksi suunnattu komponenttituote. Standardoitu rajapinta määrää käyttöympäristön. Lisäkekomponentti on täydentävä, loppukäyttäjille suunnattu valmiskomponentti (esim. Plug-init) Sovitekomponenttia käytetään, jos valmiskomponentti ei täytä kaikkia ohjelmistonkehittäjän asettamia vaatimuksia, niin se voidaan sovittaa näihin erityistarpeisiin. Muutokset tekee komponentin valmistaja (esim. Toimialakohtainen adapteri) 29

30 Sovitekomponentti Helppoa, komponentti sovitettu asiakkaan tarpeisiin Helppoa, sillä komponentti toteutettu sopimaan asiakkaan ympäristöön Voidaan määrittää itse laatukriteerit Toteutus suhteellisen edullinen, käyttö ja ylläpito edullista Komponenttityypit soveltajan näkökulmasta (Häkkinen, 1999) Ongelma Valmiskomponentti Räätälöity komponentti Komponentin Perustuu toimittajan Helppoa, käyttökelpoisuuden tarjoamaan komponentti arviointi dokumentaatioon toimitettu asiakkaan Komponentin käyttöönotto Komponentin laatu Komponentin kustannukset (toteutus, käyttö ja ylläpito) Juridiset seikat ISA-mallin Motivaatio-sarake Perustuu toimittajan tarjoamaan dokumentaatioon Toimittaja takaa, mutta varmistettava itse Kaikki kustannukset edullisia verrattuina perinteiseen ohjelmistoon ja muihin komponenttityyppeihin Toimittajalla avainasema sopimusten määrittämisessä Asiakkaan varmistettava itse dokumentaation avulla, hyvin hankalaa tarpeisiin Helppoa, sillä komponentti toteutettu sopimaan asiakkaan ympäristöön Voidaan määrittää itse laatukriteerit Toteutus valmiskomponenttia ja perinteistä ohjelmistoa monta kertaa kalliimpi, käyttö ja ylläpito edullista Asiakas avainasemassa sopimuksen määrittämisessä Asiakas voi vaikuttaa kehityksen aikana, hankalaa Toimittaja ja asiakas neuvotteluissa tasavahvoja Asiakas voi vaikuttaa kehityksen aikana, hankalaa 30

31 Architecture-Based Product Line Development Domain requirements Changes, Unsatisfied constraints, Errors, Adaptations Product Requirements Domain Modeling Product Reqt Defn Product Line Ref Arch Spec Unsatisfied constraints, errors Reference Architecture Imported Components Reusable Component Acquisition Executable Model Product Spec Product Constraints Product Design Product Architecture Reuse Library and Generator Components & Glueware Product Implementation Application Unsatisfied constraints, errors, adaptations System 3/25/98 twc SSEP 31 Source: Frank Belz TRW

32 Architecture functions (Youngs et al., 1999) Breaking down the complexity of the IT system so that developers can analyze and design components that are relatively isolated from one another Analyzing the functionality so that required technical components (or infrastructure) can be identified Assisting in the analysis of service-level requirements so that the means of delivering them can be designed Providing a basis for the specification of the physical computer systems on which the IT system will execute and the mapping of components onto these computer systems 32

33 Integrated Architecture Fwk (Maes et al p. 11; c.f. Mustikkamaa 2001) Business As Is Vision, Strategy Architectural design Development, Change Operation, maintenance Business Vision Integrated Architecture Framework Business and IT Transformation IT Enabled Enterprise IT Vision IT As Is 33

34 1) Terminal domain Mobile phones Computers PDA s 2) Network domain Telecom Network Mobile Network IP Network Service Gateways Produc t 3) Enabling technology/ platform domain Application Management User, Service & Security Management System Management Product Platform Content & Data Management archite cture 4) Application domain Self-care concept Trading concept Application Gateways Communi cation concept Business support concept Entertain ment concept Informati on concept bluepri nt (Mustikkamaa, 2001) 5) Content domain 6) Business domain Content 1 Content provider 1 Content Gateways Content 2 Content 3 Content 4 Content 5 Content N Content provider 2 Content provider 3 Content provider 4 Content provider 5 Content provider 34 N

35 1) Terminal domain Mobile phones Computers PDA s 2) Network domain Telecom Network Mobile Network IP Network IS Service Gateways architecture blueprint (Mustikkamaa, 2001) 3) Enabling Technology/ platform domain 4) Application domain 5) Content domain Application Management Management applications Product Development applications User, Service & Security Management System Management Information Systems Platform Product Delivery & Development applications Business data Product data Operation & manitenance data Sales & Marketing applications Product Data Management Business Data Management Content Gateways Customer data Content & Data Management Customer Care a plications Operation Data Management Billing applications Customer Data & Event Management Event data 6) Business domain Management process Product Delivery Management process Delivery and Production process Sales & Marketing process Customer Care process Billing process 35

36 Liiketoimi-, prosessi- ja ICTarkkitehtuurit Business Architecture Supply Chain Business Domain Business Process Outsource Contract (SLA) Business Function Business Object Application Architecture Process Architecture Process decomposition Functional Architecture Function decomposition Data decomposition I T - supply domain Service Application Subprocess Function Object Shared Usable IT-Unit 36

37 Liiketoimi-, prosessi- ja ICTarkkitehtuurit Business Architecture Supply Chain Business Domain Business Process Outsource Contract (SLA) Business Function Business Object Application Architecture (macro flow predefined) Webservices server Generic Thin Client (browser) Interfacing Layer (Dynamic appl. Builder: SOAP, UDDI, WSDL) Dedicated Application Client (eg Siebel) Dedicated application (requestor control processes) Adapters Process automation Control & Aggregation Layer Service Application Classic Application Client (legacy) Workflow engine Case handler Process Architecture Process Service Business Event Workflow scripts Business Actor / Role Event (e.g. message) Process decomposition Business Procedure Business Activity (macro flow caseoriented) Business Use Case Task OPS supply domain I T supply domain Process Architecture Function decomposition Function Data decomposition Object (micro flow) IT-Service System Use Case Service 37

38 And in inter-organizational setting, everything gets more complicated!!! ITKE50 38