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

2. [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. 272-273) 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)

3. A conceptualization of human activity

4. Context Norms Means Actions Object, Motive Other contexts Actors

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

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

7. Organizations

8. Norms Actions Other contexts Actors Object, Motive Context Means

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

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

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

12. Example from Ericsson

13. Sales Customers, Tenders Design Product Supply Orders Customer needs Product

14. 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)

15. ERP systems

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

17. Insights

18. Tones! Tons! Context

19. 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 216 123/1 Product Package HW Platfom FAP 130 123 Cabinet BFE 102 123/12 Mounting Set BAY 606 123/1 Connection Cable RPM 628 123/12 CPI LZN 314 123/1 Sales SSI Services FGC 101 125 HW Platform FGC 101 123 SW Features FGC 101 124 Product packge FAP 130 125 Product packge FAP 130 123 SSI Service FAP 130 126 Node Release FGB 101 123 System Solution FGA 101 112 Context

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

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

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

23. Transitions

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

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

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

27. Implementation

28. Implementation guidelines Identify activities from Objects Define dependencies between activities

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

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

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