Forskningsprocessen Kap 3 Kunskapsprojektering syftar till att ta fram en plan för detta Kunskapsanalys Design av genomförande Kunskapsprojektering är en plan för genomförandet av denna process
Design-oriented IS research - Kap 8 Design and Creation - Exempel på Design Science Forskning ü Eriksson och Goldkuhl (2012) - Design-oriented IS research, Hevner, March, Park, Ram (2004)
Kunskapsprodukter som resultat av design research (Kap 8, Kursboken) Constructs Models Methods Instantiations
Constructs Utveckling av grundläggande begrepp och ontologier, t.ex. vad menas med objekt, identifierare, attribut och vad de representerar
Models Detta kan vara modeller på meta eller problemlösningsnivå Modeller på Metanivå t.ex. utveckling av ett modelleringsspråk (UML, ER-diagram) och modelleringssymboler Modeller som ger förslag på hur olika modelleringsproblem bör lösas
Methods Hur ska man gå tillväga för att kunna skapa modellerna Formella metoder (t..ex. normalisering) Kommersiella metoder (RUP, Soft Systems Methodology
Instantiations IT-artefacts Syftet med att utveckla en IT-artefakt i forskningsarbetet är att på ett konkret sätt visa hur begrepp, ontologier, teorier, modeller och metoder fungerar i praktiken
IT-artefakten kan spela flera olika roller i designorienterad forskning Själva IT-artefakten i sig är fokus för forskningen IT-artefakten är ett medel att studera något annat Fokus är själva utvecklingsprocessen
Själva IT-artefakten utgör kunskapsbidraget (Exempel) En IT-artefakt som används i en verksamhet som inte tidigare varit datoriserad En ny teori från ett annat ämnesområde tillämpas genom design av IT-artefakten Psykologi teori Ekonomisk teori Pedagogisk teori En IT-artefakt utvecklas som uttrycker artistiska idéer
En IT-artefakt utvecklas men syftet är att användas som medel för att studera något annat Exempel: Man bygger en prototyp för att illustrera principerna för hur en webbplats bör vara uppbyggd som befrämjar ett visst syfte t.ex. politisk demokrati IT-artefakten som ett medel att studera ett förändrat beteende i en organisation Två olika typer av programvara används för en och samma applikation och sedan utvärderas programvarorna med utgångspunkt från vilken som är mest användbar En teoretisk studie som presenteras med hjälp av en IT-artefakt
En IT-artefakt utvecklas med det är utvecklingsprocessen som är mest intressant Exempel: Man kan använda sig av två olika metoder för att utveckla en ITartefakt och sedan jämför man vilken av dessa som passade bäst att använda En IT-artefakt utvecklas för studera hur användbar en viss metod är för att utveckla den här typen av IT-artefakt, är t.ex. objektorienterade systemutvecklingsmetoder användbara i samband med webb-utveckling Man utvecklar en IT-artefakt där man kombinerar och anpassar olika befintliga metoder Man utvecklar helt nya metoder och designprinciper för IT-arbetet kan bedrivas Man utvecklar nya perspektiv och ny kunskap om vilka förutsättningar som gäller för utvecklingsarbetet
Forskningsprocessen i samband med design reserach Awarness ü En beskrivning av problemet som ska lösas med IT artefakten Suggestion ü Förslag på lösning presenteras Development ü Utveckling av artefakten Evaluation ü Utvärdering av IT artefakten. Lyckades eller misslyckades man? Conclusion ü Slutsatser, sammanfattning av kunskapsbidrag.
Systemutvecklingsmetodikens roll i samband med designi science I samband med en designorienterad ansats är systemutvecklingsmetoden en del av viktig metodologi tillsammans med andra metoder för datainsamling och dataanalys valet av systemutvecklingsmetod är därför viktigt. Tänk på att: Systemutvecklingsmetoden ska hjälpa dig med att skapa spårbarhet från problembeskrivning till färdig IT artefakt Välja rätt systemutvecklingsmetod till rätt problem
Systemutvecklingsprocessen 1. Conception (Förstudie, Förändringsanalys, Verksamhetsanalys) 2. Analysis (System analys) 3. Design (System design) 4. Construction (Programmering och test) 5. Implementation (Implementering (acceptanstest, utbildning, driftsättning))
Samband mellan systemutvcklingsmetod och forskningsmetod
Måste en IT-artefakt utvecklas fullt ut för att det ska räknas som design science? Det beror naturligtvis på vilka kunskapsbidrag som man hävdar Det är inte nödvändigt när det gäller C-uppsatser Det viktiga är att ni har ett akademiskt kunskapsbidrag och inte bara uppvisar en praktiskt förmåga
Fördelar med designorienterad forskning Du har något konkret att visa upp Det trovärdighet till intressenter som uppskattar en kreativ förmåga Inom vissa områden t.ex. CS och SE utgör detta ett förväntat resultat Det finns många nya IT användningsområden
Tänk på att Det krävs en god teknisk och kreativ förmåga kombinerat med en akademisk förmåga Det tar tid Om du har en uppdragsgivare gör klart med att du också måste skriva en uppsats
Design orienterad forskning sker ofta i kombination med andra ansatser Inom computer science utvecklas IT-artefakten många gånger under labbliknande förhållanden Designorienterad ansats kombineras med exprimentiell ansats Inom informatik ingår ofta design science ansatsen som en del i Fallstudier Aktionsforskning Skälet till detta är att vi inom informatik vill studera hur ITartefakten används av människor samt den kommunikation och informationsbehandling som sker via IT-artefakten löser verksamhetsproblem och andra problem i samhället
Det praktiska problemet Handläggare på socialkontoren av ekonomiskt bistånd har skyldighet att kontrollera huruvida den sökanden redan har ekonomist stöd från andra myndigheter och om man utnyttjat möjligheter till stöd från andra myndigheter Detta tar orimlig tid idag genom att man måste sitta i telefonköer, svårt att få en samlad bild av detta Uppdraget är att skapa en e-tjänst som möjliggör detta
Exempel Eriksson och Goldkuhl 2013 Forskningsproblemet The central problem is how to integrate existing applications which are locally controlled by different organizations into an interoperable distributed e- infrastructure of IT-components (Edwards et al., 2009). The knowledge how to accomplish this is still limited, to quote Sahay et al. (2009, p. 400) we have little empirically based knowledge about the interplay of the political and technical configurations that arise during attempts to integrate multiple ICT systems.
Exempel Eriksson och Goldkuhl 2013 Syftet The main purpose is to investigate the process of e- infrastructure development in e-government from a design action perspective, and clarify different enabling and constraining pre-conditions in the context of the public sector. This will contribute with knowledge distinctly for e-government but also knowledge that is valuable for e-infrastructure development in general.
Resultat En djup fallstudie som ökar förståelsen för det sammanhang i vilket e-infrastruktur utveckling bedrivs Gateway (e-tjänst) Förutsättningar (kategorier) för e-infrastruktur utveckling En ny modell som beskriver e- infrastrukturutvecling
Result En modell för e-infrastrukur utveckling Legal, organizational & economic preconditions Public Agencies, IT vendors, other organisations Deliberation stage e-infrastructure (technical, informational, contractual preconditions) Decision to engage in design e- infrastructure evolution Design results Adapters, Standardized messages and Gateways Inter- & intraproject teams Descision and planning for engaging in operations Design stage Enhanced e- infrastructure Use in information exchange IT service providers & clients Operational stage
Exempel: Utveckling av einfrastruktur för informationsutbyte mellan stat och kommuner inom egovernment
Utveckling av gateway
Kunskapskaraktärisering Kategoriell kunskap, precisering av begreppet einfrastruktur Förståelseinriktad kunskap, vad utmärker designkontexten i samband med utveckling av einfrastruktur inom egovernment Handlingsinriktad förklaringskunskap, vilka förutsättningar möjliggör respektive hindrar utveckling av einfrastruktur Värdekunskap, vad känntecknar goda resp. dåliga förutsättningar för e-infrastruktur utveckling Kritisk kunskap, lagarna förhindrar informationsutbyte
Forskningsstrategi The research approach comprising both action research (AR) and design research (DR).
The action/design process Diagnoses (Awareness) Action planning (Suggestion) Action taking (Development) Evaluation and learning (Evaluation and Conclusion)
Diagnoses In order to perform the design activities the installed base had to be considered. Municipali- ties use different enterprise systems for their social welfare case handling. There are 7 differ- ent types of systems (from external vendors) installed in most of the 290 municipalities, which means that each type of application is instantiated at several municipalities. The inves- tigation of the case handling process and applications used at the municipalities also revealed that there was no single standardized work process among the 8 municipalities. A number of ambiguities in the conceptual models implemented in the enterprise systems were also detected. For example, important concepts like open case and household were ambiguously defined and identified. This was a major obstacle for the information exchange, because the new statue (SFS 2008:975) was very clear that the social welfare officers could only ask for information about members of households with open cases.
Action planning In order to analyze which type of gateway that should be developed the project contacted the state agencies and the IT vendors in the beginning of the project. The vendors of the case handling systems used at the municipalities did not present any exact plans when and how to implement the demanded infor- mation exchange. This led the Sambruk project group to start developing their own gateway ( the Multi-Query gateway ) according to the infrastructural model in figure 2. The Multi- query was intended to be a temporal solution until the vendors had catched-up. This implies that the Multi-query should be simple and easy to implement, in order to get a pay-off of the investment since it will be used for a limited period of time.
Action taking The specification work of the Multi-query started in March 2009. This work included: a further refinement and standardization of work processes and conceptual models; negotiations with the state agencies about the meaning of the statue (SFS 2008:975) and other statues that govern the information exchange; design of XML-files; and the design of the user interface of the Multi-query gateway, which was carried out through building a prototyp the programming and test activities.
Evaluation and learning The fourth and fifth steps of action research (evaluation, reflection and learning) have taken place continuously during the whole project. On site evaluation at the municipalities is in pro- gress and two onsite visits to the municipalities have already been made. The users assert that they save a lot of time using the gateway although not all state agencies are connected to the gateway, because they do not have to make so many telephone calls to SIA and BSS as they used to. It is also a great advantage for the case handling process that social welfare officers can get the answers without delay. This is also in line with the statements made by the repre- sentatives in the project group. These results will be more deliberatively presented in further research.
Methods for data collection The main source of the data collection has been 18 project meetings, and all the activities and interactions performed in the design process (see section 4.2 below). There have been 14 pro- ject meetings until now, 13 one-day and 1 two-day physical meetings, and 4 twohour tele- phone meetings. The data collection has been performed through discussions and interactions with social welfare officers and systems administers. At some of these meetings representatives of vendors and state agencies have participated. These meetings have been recorded on tape and documented through minutes, which describe the main events and decisions taken at the meetings. On site visits have been made at SIA, BSS and FUIF. The interaction in the design process also includes hundreds of telephone conversations and about 1200 recorded e-mails. All documentation generated through the development process and the different versions of the Multi-query application constitute also key data as a basis for data analysis.
Methods for data analyses Our data analysis strategy is mainly inductive, following principles of grounded theory GT (Glaser & Strauss, 1967; Corbin & Strauss, 2008). We have studied the e-infrastructure literature prior to our empirical design work (section 2.2-3 above). However, in spirit of GT we have bracketed extant categories of enablers and obstacles in order to have fresh and open minds in the data analysis and category generation. We have applied an inductive way of data analysis, but not applied a strict GT coding.
Methods for data analyses The data analysis strategy was designed to describe and understand the design situation and to investigate the pre-conditions for e-infrastructure development in e-government (see section 1). During the development the main categories emerged as the design team experienced that some state agencies were willingly to co-operate in the design process while others seemed to be uninterested. Thus during the design process it became clear that there were certain preconditions that enabled respectively hindered the design process, and these pre-conditions were identified in the actual development work. Repeatedly the project team recognized that the actors put forward similar arguments explaining why they wanted to participate or not, and that these arguments were categorized into four main categories: legal, economical, organizational and e-infrastructure. During actual design of the information exchange in co- operation with two state agencies, the project team also realized how it was impossible to make certain design decisions dependent on how the laws were written and interpreted by the state agencies.