1 / 60

Chapter 25

Chapter 25. Organ izational-Oriented Methodologies. Organ izational-Oriented Methodologies. ISs are to be used in an organization thus they cannot be separated from the context, and, understanding contextual issues is essential for successful implementation Methodologies include

kandes
Télécharger la présentation

Chapter 25

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 25 Organizational-Oriented Methodologies

  2. Organizational-Oriented Methodologies • ISs are to be used in an organization thus they cannot be separated from the context, and, understanding contextual issues is essential for successful implementation • Methodologies include • Soft Systems Methodology (SSM) • Information Systems Activity and Change Analysis (ISAC) • Process Innovation (PI) • Projects in Controlled Environments (PRINCE2) • Renaissance

  3. Overview of SSM • SSM = Soft Systems Methodology • It applies Systems Thinking to Human Activity Systems (people working together to achieve something) including Information Systems. • It is developed by Prof. Peter Checkland (from Lancaster University).

  4. Soft Systems Methodology (SSM) • Addresses ill-structured situations. • Requires abstract/conceptual thinking on the part of the user. • Suitable for what type problems (analysis) rather than how type problems (design). • Requires a high degree of political and interpersonal skills from the user. • SSM grew out of action research in over 250 problem solving situations in industry, commerce, service sector and public corporations.

  5. SSM in summary (after Checkland, 1981) SSM is a seven-stage methodology

  6. SSM stages • The problem situation: unstructured • The problem situation: expressed • Root definition of relevant systems • Building conceptual models • Comparing conceptual models with reality • Assessing feasible and desirable changes • Action to improve problem situation

  7. Stage 1 - Problem Situation Unstructured • Notes : • The Systems Analyst is not an expert of particular information systems or problem types. Instead he/she acts as a facilitator. • The Client is the person who causes the study to happen. • The Problem Solver is the person who hopes to do something about the situation which is perceived to be problematical. • The Problem Owner could be one or several people. By considering each stakeholder in turn very different perspectives can be generated. • The Problem! Instead of trying to find the problem, the inquiry is directed to investigating the situations in which problems are perceived.

  8. Stage 2 :Problem Situation Expressed Problem Situation Expressed. • Building Rich Pictures : • Use any form or imagery (as demonstrated in Group 6 presentation). • Construct parts, actors, issues, concerns. • Do not use systems or represent situations in terms of systems. • Represent all elements considered to be relevant. • N.B. Although the ideal may be to avoid systems thinking at this stage, the pragmatic need to establish boundaries may be met!

  9. Stage 2 :Problem Situation Expressed (cont…) • Structure : • those parts of the system that change slowly over time and are relatively stable. • Process : • things that are in a state of change, such as activities within a structure (i.e. order processing). • Climate : • in which structures and processes interact. This has changed as a result of previous interaction and thereby influences its own development (i.e. business conditions, cultural aspects.).

  10. Stage 2 :Problem Situation Expressed (cont…) • Extracting from Rich Pictures : • Primary Tasks : which the organization was created to perform, or the tasks which an enterprise needs to perform in order to survive. • Issues : topics or matters of concern, those subjects which are open to debate or dispute (i.e. require justification). • This particular stage of the method can be iterated through on a number of occasions, at a number of levels, using the rich pictures generated from the first iteration to further clarify and identify issues within the situation of concern. qualitative rather than quantitative

  11. Stage 3 : Root Definitions (Descriptions of relevant notional systems). • Root definition guidelines, using the notion of systems : • A root definition must convey : C - Clients A - Actors T - Transformations W - Weltanschauung(en) O - Owners E - Environmental Constraint(s)

  12. Stage 4 : Conceptual Models • (Using the notion of systems) Conceptual Model 1 - Front-line activities Conceptual Model 2 - Back-up activities • From the root definition and its CATWOE elements, form an impression of the system as an autonomous entity carrying out a physical and/or abstract transformation process. • Assemble the set of verbs which describe the most fundamental activities necessary for the achievement of the system.

  13. Maintain one resolution level (i.e. avoid mixing activities with different levels of detail). If it can be justified from the root definition, structure the activities into groups which link together similar activities (i.e. the groups (functions) that will generate some output). Connect the activities and activity groups (functions) by arrows which indicate logical dependencies. Indicate any flows (concrete or abstract) Stage 4 : Conceptual Models (Cont…)

  14. which are essential to the expression of what the system does. Distinguish these flows from the logical dependencies identified in the previous step. Keep such links to a minimum (e.g. physical flows, material flows, data flows, etc.) Once the models have been created, further resolutions of detail will help to drive the possible hows for what is being done. Check the root definitions and the conceptual models map. Together they form a mutually informing pair of statements : What the system does. How the system does it. Stage 4 : Conceptual Models (Cont…)

  15. (Consider the output of Stages 3 & 4 with expression of Stage 2). This is one of the most important stages of the methodology. At this stage the intellectual ideas have to be reconciled with the real or action world ideas. This stage may generate desirable and feasible changes for Stage 7 or require the reiteration of Stages 2, 3, 4, 5 & 6. Problems encountered at this stage should not Stages 5 & 6 : Comparison & Identification of Desirable and Feasible Changes

  16. underestimated, which is why political and interpersonal skills on the part of the user are important. It is at this stage that the negotiations between the problem solver and the problem owners will take place, also as part of the iterative nature of the methodology. The purpose of these is to create the climate for change, to allow the desirable and feasible changes to be enacted in Stage 7. Stages 5 & 6 : Comparison & Identification of Desirable and Feasible Changes (Cont…)

  17. This stage is equivalent to the implementation stage of other methodologies (i.e. what steps should be taken to implement the desirable and feasible changes?) SSM is not prescriptive as to the nature of the implementation, though it has offered more guidance in recent times. However, this still just takes the form of the use of the problem solving techniques of SSM to Stage 7 : Action to improve problem situation.

  18. overcome any problems in the implementation. The underlying assumption in SSM is that the identification of the desirable and (culturally) feasible changes in the previous stage will have created a climate for change which will overcome any problems at this stage. As a result any appropriate implementation strategy can be adopted. Stage 7 : Action to improve problem situation (cont…)

  19. SSM is strong in systemic analysis (i.e. in the problem formulation phase). Clients concerns are used to determine the domain of inquiry. SSM considers the different Weltanschauungen of the participants to determine the rationale for the situation of concern. The reality of the expressed problem is questioned, and if necessary the problem is re-expressed. Conclusion of SSM

  20. SSM searches for different states/solutions, all of which can be relevant, and critically examines them. SSM seeks to consider all aspects of the organisational environment, not just the problem situation. SSM constructs a number of relevant notional systems, maps them against the current state and then discusses the most relevant solution with the client(s). SSM seeks to develop a relevant rather than a right system. Conclusion of SSM(cont…)

  21. understanding the differences between SSM and structured methods SSM structured methods subjective (interpretive) philosophy objective philosophy systems + sociological theory base computer science + systems theory flexible methodology rigid method organisational problem- solving focus data, process, database, technical focus creative/intuitive scientifically analytical analyst is facilitator analyst is expert participative analyst dominated organisational learning outcomes computer design outcomes several ambiguous outcomes one ‘correct‘ solution

  22. Rich picture diagram – paramedical services

  23. Conceptual model – monitoring and evalution system for community health

  24. Model 2 SSM SSM (mode 1) was introduced in 1981. It was developed through testing systems ideas in client organizations by doing so-called ”action research”. An alternative version (mode 2) was proposed in 1990. It was based on the results of further action research. This later version promotes a looser interpretation of mode 1. It suggests the SSM be seen as a framework, rather than as a methodology. This is the extent of the evolution of SSM, to date.

  25. MODE2 SSM • Finding out about a problem situation, including culturally/politically. • Formulating some relevant purposeful activity models. • Debating the situation, using the models, seeking from that debate both (a) changes which would improve the situation and are regarded as both desirable and (culturally) feasible, and (b) the accommodations between conflicting interests which will enable action-to-improve to be taken. • Taking action in the situation to bring about improvement.

  26. ISAC: (Information Systems Activity and Change Analysis) Lundeberg et al, 1982 • ISAC views an information system as organized co-operation between people in order to process and convey information to each other. "Our most important message is that information systems are built for people; to help people work more effectively. ..... It is our experience that the ISAC approach works only when you know what you want to achieve and when you feel that a systematic approach may help you." [Lundberg,1981:p.ix]

  27. ISAC – Major phases • Change analysis - accomplished via tables of needs, lists of interest groups affected and "activity graphs" showing flows of people, materials and information between activities. • Activity studies • Information analysis • Data system design • Equipment adaptation

  28. Change Analysis • Production of a problem listing (problem table) • Determination of interested groups, which are affected by indicated problems • Grouping of existing problems (table of group of problems) • Description of the current activities (actual condition, A-graph) • Determination and tuning of operational goals (goal table) • Evaluation of the given situation and analysis of the need and the extent at changes (table of the necessary changes)

  29. Activity studies • Detailed description of all activities • Identification of the information subsystems • Classification of the information subsystems (not formalizable, formalizable, automizable,…) • Delimitation of the information subsystems revise (A-graphs) • Analysis of the problem solution contributions • Determination of alternative realization degrees • Analysis of the realization degrees and selection

  30. Information analysis • Requirements for the systems are specified • necessary processes and data are examined and specified

  31. Data system design • Development of solutions for the information subsystems • independently of hardware • Steps • Study of processing philosophy (automation is based?) • Draft of the computer-based routines (relations of the subsystems - D-graphs, data structures and program Design - D-structures and P-structures) • Draft of the manual parts

  32. Equipment adaptation • Equipment study (E-graph) • Adjustment of the computer-based systems (draft of physical data structures, draft of the adjustment routines)

  33. ISAC Modelling Techniques An D-graph or Data system development graph describes the relationships between the data sets and the data processes of an data system. D-graphs can be used to describe manual and automated processes.

  34. A-graph An A-graph or activity graph is a picture of some activity. The symbols are of three kinds: (I) sets, (ii) activities and (iii) flows. A-graphs have a hierarchical structure in order to give an overview of complex activities and at the same time give details on lower levels.

  35. Detailed A-graph

  36. I-graph An I-graph or an Information precedence graph is a picture of some part of the information system. In principle, I-graphs describe information sets and precedence relations among information sets.

  37. C-graph C-graph or a Component relation graph describes the content and structure of an information set. An information set consists of a message type and a value part.

  38. Process Innovation (PI) An approach to implementing classic BPR, devised by Tom Davenport which suggests five stages as follows: • Develop the business vision and process objectives • Identify the processes to be redesigned • Understand and measure the existing process • Identify the IT levers • Design and build a prototype of the new process

  39. 1. Develop Business Vision and Process Objectives • During this step the objectives and the business vision of an organization are defined. A business vision implies specific objectives for process redesign, such as: Cost Reduction, Time reduction, Output Quality, the Quality of Worklife and the Quality of Learning. • The objectives are prioritized and stretch targets are set. A redesign effort does not aim at improving processes’ performance, so that they contribute to the fulfillment of the vision and the objectives of the organization.

  40. 2. Identify Processes to Be Redesigned • The most important processes are identified and prioritized according to their redesign potential. Key business processes are identified either by identification and prioritization of all processes (exhaustive approach) or by identification of important processes or processes in conflict with conflict with the business vision and process objectives (high impact approach).

  41. 3. Understand and Measure Existing Processes • The functionality of selected process is understood here and their performance is measured against the specific reengineering objectives. It is important that designers think in an innovative way and are not restricted or influenced by the analysis of current situation.

  42. 4. Identify IT levers • IT is a powerful tool not only for supporting processes but also for creating new process design options; therefore, it has its own step in process redesign. The authors suggest eight ways to think about IT capabilities and their organizational impacts, which are summarized in Table 1.

  43. Table 1. IT capabilities and their organisational impact

  44. 5. Design and Build a Prototype of the Process • The final step in a redesign effort is the design of the new process. The actual design of the new process should be viewed as a prototype and successive iterations should be expected. Three key factors and tactics are considered in process design and prototype: • using IT as a Design Tool • understanding generic design criteria • creating organizational prototypes

  45. Process Improvement versus Process Innovation (Davenport 1993) Improvement Innovation Level of Change Incremental Radical Starting Point Existing process Clean slate Freq. of Change One-time/continuous Continuous Time Required Short Long Participation Bottom-up Top-down Typical Scope Narrow, within Broad, cross- functions functional Risk Moderate High Primary Enabler Statistical control Info Technology Type of Change Cultural Cultural/structural

  46. Projects inControlled Environments (PRINCE2) • PRINCE2 is a structured method providing organizations with a standard approach to the management of projects. • It is a methodology for managing projects, there is no Hardware or Software (apart from supporting tools) just a best practice approach to running Projects in a consistent and referenceable framework.

  47. Projects in Controlled Environments (PRINCE2) Project aspects:- • Defined and unique set of products • Set of activities and their sequence to construct the products • Appropriate resources to undertake the activities • Finite lifespan, and an • Organizational structure with defined responsibilities

  48. Components of PRINCE 2

  49. Components of PRINCE 2 • Business Case – The justification behind the project. • Organization – The way in which the personnel involved in the project are structured. • Plans – Documents describing what the project should accomplish, how the work should be carried out, when it should be carried out and by whom. • Controls – The way in which the project manager and project board should exercise control over the project. • Management of Risk – The way in which the project should approach and manage risk. • Quality in a Project Environment – The way in which the project should ensure that a quality product is delivered. • Configuration Management – The way in which the project's products are identified and tracked. • Change Control – The way in which the project manages any changes to specification or scope of its products.

  50. PRINCE 2 • PRINCE2 defines 45 separate sub-processes and organizes these into eight processes as follows: • Starting Up a Project • Initiating a Project • Directing a Project • Controlling a Stage • Managing Product Delivery • Managing Stage Boundaries • Closing a Project • Planning

More Related