An Inquiry into ERP systems from an ”activity” perspective Lars Taxén

[There is a] need to research the design, implementation, use and evaluation of ES [Enterprise Systems] … within and across contexts so that we can examine the ways that such systems shape and are shaped by individual and group interests (Howcroft et al., 2004, pp ) Point of departure - context “activity” (Leont’ev, 1981) – Activity Theory “social world” (Strauss, 1985) “communities of practice” (Lave & Wegner, 1991) “thought world” (Dougherty, 1992) “knowledge domain” (Boland & Ramkrishnan,1995) “work situation” (Bannon & Bødker, 1997) “workpractice” (Goldkuhl & Röstlinger, 2002) “work system” (Alter, 2002) “activity domain” (Taxén, 2003)

A conceptualization of human activity

Context Norms Means Actions Object, Motive Other contexts Actors

Capability Individual-acting-with-mediational-means (Wertsch, 1991) Resource Resource – always with respect to motive and context

Why start from activity (Activity Theory)? Object and Motive shaping the activity Focus on meaning construction Originally a psychological theory (Vygotsky) –Grounding in individual, innate faculties Meaningful context for individual actions Based on interesting Marxian concepts –Dialectical relations –Praxis –Mediation Have been elaborated –Cultural Historical Activity Theory (CHAT) –Activity Domain Theory

Organizations

Norms Actions Other contexts Actors Object, Motive Context Means

Activities in product development Courtesy Siemens PLM Software Same Object, different Motives, in various contexts

Coordinative mode Object: coordination Transformative mode Object: product Two modes of actions in an activity Enacts coordination capabilities Information models Process models Rules IS support.... Draws on coordination capabilities

Work object A Activity A Transformative capabilities A Coordinative capabilities A Activity a1 Work object a1 Transformative capabilities a1 Coordinative capabilities a1 Activity a2 Work object a2 Activity a3 Work object a3 Activity a4 Work object a4 Transformative capabilities a2 Coordinative capabilities a2 Transformative capabilities a3 Coordinative capabilities a3 Transformative capabilities a4 Coordinative capabilities a4

Example from Ericsson

Sales Customers, Tenders Design Product Supply Orders Customer needs Product

Customer needs IT department IT infrastructure Sales Customers, Tenders Service & Support Installed Base Service Design Product Supply Orders Dependencies between activities ERP consultants ERP application [Coordination is] managing the dependencies between activities (Malone & Crowston, 1994, p. 90)

ERP systems

Observations ERP-system impacts several activities –Valid for other systems as well, e.g. Product Lifecycle Management (PLM) systems Basically a coordinative means –Activities need to be coordinated Coordination in focus for ERP initiatives

Insights

Tones! Tons! Context

Design HSC HSD APX 1 SubS Block SWU HWU APT SubS Block SWU HWU APZ APX 2 SubS Block LMHWU APR Supply Product Package Site Common Power Cooling Additional mtrl Installation mtrl Product Package Other Deliverables SW ‘dump’ LZY /1 Product Package HW Platfom FAP Cabinet BFE /12 Mounting Set BAY /1 Connection Cable RPM /12 CPI LZN /1 Sales SSI Services FGC HW Platform FGC SW Features FGC Product packge FAP Product packge FAP SSI Service FAP Node Release FGB System Solution FGA Context

Sales Customers, Tenders Design Product Supply Orders Customer needs Product Commonality “One Company”

Sales Customers, Tenders Design Product Supply Orders Customer needs Product Commonality “War-lords”

Sales Customers, Tenders Design Product Supply Orders Customer needs Product Commonality “Federated”

Transitions

Sales Customers, Tenders Design Product Supply Orders Customer needs Product Transitions

DS- DS4 PR-PR1PR2PRA HW Design PRB DS1DS2 DS3 PSAPSN PS- PSSPSF PSB CS- CSA Define Product Content Define Business Opportunity Create Business Sales Design Market Offer Prepare Deployment Specify Product Design & Verify Product Supply Solution Implement Solution In- Service Support Exhibit Product in Service Design Supply Sales PC0 SC1 PC4 SC6 PC2 SC5 PC1 SC2 PC5 PC6 SC7 PC3 SC4SC3

Sales Customers, Tenders Design Product Supply Orders Customer needs Product Adaptation and emergence ERP system Vendor

Implementation

Implementation guidelines Identify activities from Objects Define dependencies between activities

Create Business Sales Supply Solution Implement Solution In-Service Support Define Business Opportunity Define Product Content Design Market Offer Prepare Deployment Exhibit Product in Service Specify Product Design & Verify Product Performance Fulfillment Solution Fulfillment Product in Service New Standards & Technology Changes & Expectations & Gap Solution Need Performance Need or Incident PC0 PC1 PC2 SC8 PC6 SC7 SC5 SC1 SC2 SC6 PC3 PC4PC5 SC3SC4 TTC flow states PC0: Offer requested PC1: Order / Contract PC2: Product arrived PC3: Ready for Acceptance PC4: Customer Acceptance PC5: Product in service PC6: Solution fulfillment TTM states SC1: Market offer intent SC2: Product release intent SC3: Product model approval SC4: Design Implementation Decision SC5: Market offer SC6: Product quality approved SC6.5: Product ready for deployment SC7: Market release decision SC8: Full deployment acknowledged IS/IT InfrastructureBusiness rules Human ResourcesFinancingSourcing SC6.5 ERP System

Identify activities from Objects Define dependencies between activities Agree on provisional least acceptable commons –Business rules –Master data –Overall business process –Transitions between major activities Implementation guidelines Consider context specific needs –E.g. different product structures in Sales, Design, and Supply Take heed of emergence –Capabilities of actors and ERP-system evolve during implementation –Small steps, validation of each step –Joint effort: users, ERP vendors and organizational architects Flexible ERP system –User interfaces –Generating reports –Activity specific terms and symbols –Data entry –Processes –Transitions between activities

Summary and conclusions Activity the building block of organizations –Frames meaningful contexts based on Object and Motive Organizations integrate / coordinate activities Coordination – managing dependencies between activities ERP systems are seen as coordinative means Theoretical framework guiding inquiries into –Contexts and ERP-systems –Transitions between activities –Balancing between commonality and locality –Adaptations between ERP built-in capabilities and activity needs –Emergence of capabilities (human and non-human) –“Best practice” –Integration and coordination –Implementation guidelines