slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Lecture 4, IS 904 Genre-Based approach and method: Planning for organizational information requirements PowerPoint Presentation
Download Presentation
Lecture 4, IS 904 Genre-Based approach and method: Planning for organizational information requirements

Lecture 4, IS 904 Genre-Based approach and method: Planning for organizational information requirements

162 Vues Download Presentation
Télécharger la présentation

Lecture 4, IS 904 Genre-Based approach and method: Planning for organizational information requirements

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Lecture 4, IS 904Genre-Based approach and method: Planning for organizational information requirements Tero Päivärinta University of Agder 17.9.2010

  2. Agenda • Genre concept • Role of genre in the organizational modelling landscape • A method for recognizing and analyzing genres (+ some experiences) • Exercise

  3. Genre of organizational communication • Bakhtin (1952) - >Yates & Orlikowski (1992): a recurrently instantiating communicative action • identified by its communicative purpose and form(s) (medium/media, language, structural elements) • identified within a normative scope among a certain group of stakeholders within a certain community • e.g. lutheran marriage ceremony, invoice, requirements specification, sales report, project plan, budget, R & D meeting, ”The Diary” of papermill maintenance... • various levels of abstraction vs normative scope: specific genres recognized in a group of employees ... globally recognized abstract genres : memo of our group meeting ... memo • Genres can be ”emerging” or (to some extent) ”designed” • …or even ”given” by a 3rd party technology / application • -> assumption: a design made elsewhere fits also to us

  4. Genre system / repertoire / ecology • genre system (Bazerman, 1994) • A set of interrelated genres in a wider communicative context (e.g. the genres for project mgmt: plan, memo, meeting, budget, report...) • Genre system for a meeting: scheduling (calender), invitation, agenda, (possibly document genres), meeting communications, minutes of the meeting • genre repertoire (Orlikowski & Yates, 94) • The set of genres recognized within a certain community of interest • E.g. genre repertoire of ”Aker Business Services” • genre ecology (Erickson, 2000) • Communicative practices facilitated by the use of a certain technological infrastructure/environment... e.g. Lotus Notes or virtual reality -applications • E.g. ”Genre ecology ”which can grow in” SharePoint” or ”MS Office 2007 Pro”

  5. Genre systems for (e-) Collaboration F2f- genres (e)Communication genres Document genres Document genres F2f- genres Document genres Document genres Document genres Document genres Awareness genres (Awareness of repositories, workspaces and users) Document / Data repositories/workspaces


  7. Enterprise Model Objectives Impacts Content Infrastructure Administration Change Management Reminder 2… People / Culture Communication /

  8. The genre-based method • focus: identifying organizational information / communication requirements for varying IS development initiatives • ECM, KM, DW, BI... • concepts: (become concrete in the organizational language) • genre (document types, types of meetings, reports, forms...) • property (of genre) • metadata (about genre, e.g. about its implementation, dev. needs,) • PUI entity = producer/user of information (structure, task, people etc.)

  9. Overview of the method’s process

  10. Identify stakeholders • I.e., those who should be involved in the development process & req analysis • For instance: Chief information officer, Chief executive officer, ISP champion, IS coordinator, Information technology manager, Information systems developer, Information security coordinator, Consultant, Researcher, Outside facilitator of ISP, Facilitator (from inside the company), Representative of a PUI entity in the ISP domain (including practically every identified work role in PUI entities), External stakeholder (affected by ISP decisions:customer, supplier, and subcontractor) • Just list them & their contact information

  11. Identify PUI entities • List of the PUI entities with which to start • Examples • processes • Sales process, Purchasing process, … • organization units & roles • Accounting department, Research & Development dept., Financial manager, Regional managers • individual people? • ”Pekka Toivonen” • external PUI entities (with which ECM system exchanges information) • Customer, Subcontractor, Trade union, Department of Defense • existing databases?? (sales transactions…) • to be put in the diagonal matrix -model

  12. Identify & name genres • I.e., those meaningful recurrent information objects shared between at least two PUI entities • note: to identify genres within PUI entities, the PUI entities could be structured further • > the diagonal matrix -technique • or otherwise (interviews, mind maps - important, remember to document the PUI entities!!!!)

  13. The diagonal matrix Direction of communication ”flow”: clockwise

  14. Diagonal matrix (2)

  15. Identify relevant properties to be analysed • I.e., those things which we want to analyse further about genres in connection to this particular ECM initiative -> genre list • …tens of them possible • those describing further production & use • those describing related technologies & applications • those describing development needs / problems • those describing relationship to other information resources

  16. A general-level set of analysis questions: 6W1H:s • …when need to discuss the organizational purpose & implementation of a new or elaborated genre or genre system • Why? (Purpose(s) of communication) • Who? (Who communicate to whom?) • Whose? (Who ”owns” the communication – who can stop it?) • What? (Subgenres of a genre system, content/communication elements of the related genres) • When? (Any time-related issues between subgenres and about particular ones) • Where? (Where does the content /communication reside) • How? (How is it technically implemented – or should be?)

  17. Genre list (unanalysed) -> 10-20 (>50) PROPERTIES METADATA -> 300-800

  18. Analyse & redefine genre-based metadata • …to constitute an IS/IT implementation plan for ECM in the modelled domain applications to produce / distribute / publish / communicate • technological functionalities • Useful to scrutinize, which useful in which context • consultants representing particular solutions -> those functionalities in their solutions • About Content: From genres to ”technical content types” and elements • Content genres sharing (almost) exactly the same technical metadata / flexible structure -> same technical content types • …the more tailored content systems -> the more genre-specific content types supported • give some examples? • Technical content types = aggregations of technical content elements • figure, text, formatted data field, etc. • the more tailored system -> the more semantically specific content elements / content structure models

  19. Genre list (analysed) (also: reference to specific content structure definitions about more tailored content types)

  20. …until gap-fit analysis • Product analyses to be done in parallel with / after genre-based requirements analysis • with regard to the functionality of a product of interest • The genre-based analysis provides a basis to see, which functionalities of the available products would be highlighted in the selected domain • e.g. which existing meeting genres would fit to be replaced / elaborated with ”Live Meeting with Round Table” best, which with more advanced video meetings with ”presence feeling”. • …and would we able to envision new meeting genres now made possible with the technology?

  21. Side-jump to the other article • What did you think about analysing the meeting genres at the level recommended by Antunes et al. 2006?

  22. Background of g-b method • Dev. of electronic document management in industry (3-yr.METODI project, end of 1990s) • heterogeneous document resources -> the problem is first of all about IS planning • Need to delve deeper into doc resources • people tend to recognize genres rather naturally • IS developers were uncommon with the most genres in big organizations (although they must decide on IT implementation issues) -> practical need for a collaborative approach, genre repertoire forms an easily comprehensible, still comprehensive, conceptual ground for the stakeholders to collaborate

  23. Experiences from action research • The reported method version elaborated in collaboration with industry • from the development of EDM to ISP in general • easy to find hundreds of genres in organizations • IT people recognize their lack of knowledge and need for closer collaboration • ”end users” can express their problems and requirements in a detailed way, with a language familiar to them • e.g cf. to ”entity-relationship” modelling of data

  24. Experiences from action research (2) • managers get insight into the actual practices of communication (by themselves they, too, are rather incapable of discussing the development of IT use for effective communicative practices) • help discuss, identify, and demarcate potential targets for development and prioritize them • ”The method works too well. I dare not to analyze our other departments with my current dev. resources, people would expect fast improvements to the now defined needs in vain...” (A CIO).

  25. Experiences from consulting • A consulting company has used the method in the business for specifying requirements for ECM since 1999 • > 100 customer organizations 1999- • independently of the original method engineers • sizes vary 40-600 employees, interorg. domains • manufacturing, engineering, financing, consulting, interorganizational domains...

  26. Observations from consulting • genre-based approach works in practice (as illustrated also by the earlier action research –based efforts) <– req. anal. • simple, communicative, efficient, sometimes emancipatory? • genres & PUI entities useful as robust ”metaconcepts” of analysis • practical language = customers’ terminology for genres and PUIs • speak of ”what kind of documents, meetings etc.” does the customer have • socio-org. vs technology-oriented concepts • genres can bridge req. eng. and implementation issues of EDM • Here we are (still) at the beginning in terms of research!!!!

  27. Observations from consulting (continued) • participative debate on genres is efficient and effective in requirements engineering for ECM • technology-oriented consultants tend to adopt the ”technology language” of a particular application -> genres represent still the customer business view better • a quick basis for analysing work processes • it seems for many to be easier to identify genres first and then to discuss about the processes which they relate to (than to start directly with a business process analysis)

  28. (Very brief) comparison to some other modelling concepts • Data modelling / relational databases • Genres correspond roughly to reports (i.e. report types, not individual instances) and forms • (actually, the method has been used for clarifying possibilities of data warehouses in another consulting firm, occasionally) • Object-orientation, object classes • A genre can be an object class • which describes aggregations of content objects and sets of functionalities in use, production, and interaction contexts of the application under analysis • an instance document genre = a permanent object • an instance of an interaction genre = a run-time object (which may become a permanent object if stored)

  29. Exercise • Let us do individually a diagonal matrix about ”the course communication” • for the virtual eCollaboration course at UiA • use the excel-sheet given for this purpose • …you can use the wikisite: • …as the basis (OBS! this does not involve all of the genres!) • -> Move 3-4 genres of communication to a ”genre list” • The second task is to suggest ways to improve collaboration in a virtual eCollaboration course at UiA… • …discuss about each of those • improvement ideas • functionality requirements etc. • 45 minutes… -> coming back to present the model(s) • (if no time – do this exercise before the next lecture)