Chapter 25 OrganizationalOriented Methodologies OrganizationalOriented Methodologies n n

Chapter 25 Organizational-Oriented Methodologies

Organizational-Oriented Methodologies n n 1. 2. 3. 4. 5. 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 (PRINCE 2) Renaissance 2

Overview of SSM n n n 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). 3

Soft Systems Methodology (SSM) n n n 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. 4

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

SSM stages 1. 2. 3. 4. 5. 6. 7. 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 6

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

Stage 2 : Problem Situation Expressed. n Building Rich Pictures : n n n 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! 8

Stage 2 : Problem Situation Expressed (cont…) n Structure : n n Process : n n those parts of the system that change slowly over time and are relatively stable. things that are in a state of change, such as activities within a structure (i. e. order processing). Climate : n 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. ). 9

Stage 2 : Problem Situation Expressed (cont…) n Extracting from Rich Pictures : n n n 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 10

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

Stage 4 : Conceptual Models n (Using the notion of systems) Conceptual Model 1 - Front-line activities Conceptual Model 2 - Back-up activities n 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. n Assemble the set of verbs which describe the most fundamental activities necessary for the achievement of the system. 12

Stage 4 : Conceptual Models (Cont…) Maintain one resolution level (i. e. avoid mixing activities with different levels of detail). n 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). n Connect the activities and activity groups (functions) by arrows which indicate logical dependencies. n Indicate any flows (concrete or abstract) 13

Stage 4 : Conceptual Models (Cont…) n n which are essential to the expression of what the system does. n Distinguish these flows from the logical dependencies identified in the previous step. n 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 : n What the system does. n How the system does it. 14

Stages 5 & 6 : Comparison & Identification of Desirable and Feasible Changes (Consider the output of Stages 3 & 4 with expression of Stage 2). n 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. n This stage may generate desirable and feasible changes for Stage 7 or require the reiteration of Stages 2, 3, 4, 5 & 6. n Problems encountered at this stage should not 15

Stages 5 & 6 : Comparison & Identification of Desirable and Feasible Changes (Cont…) 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. 16

Stage 7 : Action to improve problem situation. n n 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 17

Stage 7 : Action to improve problem situation (cont…) n 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. 18

Conclusion of SSM n n 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. 19

Conclusion of SSM (cont…) n n 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. 20

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 analyst is facilitator scientifically analytical analyst is expert participative analyst dominated organisational learning outcomes computer design outcomes several ambiguous outcomes one ‘correct‘ solution 21

Rich picture diagram – paramedical services 22

Conceptual model – monitoring and evalution system for community health 23

Model 2 SSM (mode 1) was introduced in 1981. It was developed through testing systems ideas in client organizations by doing socalled ”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. 24

MODE 2 SSM 1. Finding out about a problem situation, including culturally/politically. 2. Formulating some relevant purposeful activity models. 3. 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. 4. Taking action in the situation to bring about improvement. 25

ISAC: (Information Systems Activity and Change Analysis) Lundeberg et al, 1982 n 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] 26

ISAC – Major phases 1. Change analysis 2. 3. 4. 5. 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 27

Change Analysis n n n 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, Agraph) 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) 28

Activity studies n n n n Detailed description of all activities Identification of the information subsystems Classification of the information subsystems (not 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 29

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

Data system design n Development of solutions for the information subsystems independently of hardware Steps n n n 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 31

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

ISAC Modelling Techniques ISAC, Information Systems Work and Analysis of Changes (Lundeberg et al. 1981, Lundeberg 1982) A-graph I-graph Problem table Table of problem groups Table of needs for changes Table of interest groups C-graph D-graph 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. 33

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. 34

Detailed A-graph 35

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. 36

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. 37

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

1. Develop Business Vision and Process Objectives n n 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. 39

2. Identify Processes to Be Redesigned n 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 the business vision and process objectives (high impact approach). 40

3. Understand Measure Existing Processes n 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. 41

4. Identify IT levers n 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. 42

Table 1. IT capabilities and their organisational impact Capability Organisational Impact/Benefit Transactional IT can transform unstructured processes into routinized transactions Geographical IT can transfer information with rapidity and ease across large distances, making processes independent of geography Automational IT can replace or reduce human labour in a process Analytical IT can bring complex analytical methods to bear on a process Informational IT can bring vast amounts or detailed information into a process Sequential IT can enable changes in the sequence of tasks in a process, often allowing multiple tasks to be worked on simultaneously Knowledge management IT allows the capture and dissemination of knowledge and expertise to improve the process Tracking IT allows the detailed tracking of task status, inputs, and outputs Disintermediation IT can be used to connect two parties within a process that would otherwise communicate through an intermediary (internal or external) 43

5. Design and Build a Prototype of the Process n n 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 44

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/structural 45

Projects in Controlled Environments (PRINCE 2) n n PRINCE 2 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. 46

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

Components of PRINCE 2 48

Components of PRINCE 2 n n n n 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. 49

PRINCE 2 n PRINCE 2 defines 45 separate sub-processes and organizes these into eight processes as follows: 1. 2. 3. 4. 5. 6. 7. 8. Starting Up a Project Initiating a Project Directing a Project Controlling a Stage Managing Product Delivery Managing Stage Boundaries Closing a Project Planning 50

PRINCE 2 processes 51

Renaissance framework RENAISSANCE supports the transformation of a legacy software system to an evolutionary software system, that is a system which is able to evolve both in the short and log term RENAISSANCE defines three intuitive views and three intuitive role categories: 1. Technical View. This includes an understanding of the technologies used, along with documentation and maintenance processes. 2. Economic View. This includes an understanding of the business value of the system and cost and risk estimates for different evolution strategies. 3. Managerial View. Decisions based on the previous two views. 52

Renaissance role categories 1. Strategic. This role is concerned with defining market strategies and identifying future needs, aiming at cost reduction and quality improvement. There will be a focus on managerial and economic views. 2. Operational. This role is concerned with providing control over the evolution of legacy systems and negotiations with customers. 3. Service. This role is concerned with ensuring that the level of service required is achieved in the technical view. 53

Renaissance The RENAISSANCE three views and role categories of a system 54

Renaissance The RENAISSANCE methodology provides support to this paradigm. The RENAISSANCE domain and paradigm Source: http: //www. comp. lancs. ac. uk/computing/research/cseg/projects/renaissance/pdf/D 411. pdf 55

Renaissance The RENAISSANCE reengineering framework 56

Renaissance process model 1. Trade-off analysis. This is a thorough investigation of open technical issues, technical market trends, and business goals. This view of the legacy system as a business asset along with an understanding of present-day technologies will prove a good basis for further work. 2. Issue assessment. This looks at the scope and direction of the project and in particular ensuring that the legacy system is a good basis for evolution from a technical and business point of view. 3. Decision analysis. This involves choosing the best evolutionary strategy from a number of possibilities from the point of view of costs, benefits, and risks, and developing a project plan to carry out this strategy. One strategy will be to do little apart from required maintenance, but many will involve much greater change. 57

Renaissance process model 4. Solution implementation. This involves the design of a solution that satisfies the requirements set out at the earlier phases, having understood the extent and effects of the required change. It also includes creating a programme for validating the evolved system. 5. Solution deployment. This concerns the validation and acceptance of the evolved system ready for running it operationally. There may be a period of parallel running before the organization is fully dependent on the evolved system. 6. Kaizen improvement. This phase is based on the Japanese approach to business improvement and suggests continuous evaluation, incremental change, and improvement through tuning. Therefore, the legacy system is continually being refined. 58

Renaissance evolution strategies 59

Thank You for Your Attention 60