Loading in 2 Seconds...
Loading in 2 Seconds...
University or Universality:Designing Software Packages & User Communities Neil Pollock & Tasos Karadedos University of Edinburgh, UK Neil.Pollock@ed.ac.uk www.homepages.ed.ac.uk/npollock
Research Agenda on Virtual Universities • Theme 1 - ‘distance’ or ‘flexible’ teaching and learning technologies (‘polemical’) • Theme 2 - organisational technologies • ‘mundane’ but transformation from ‘cultural’ to ‘technological’ university (Readings) • adoption of industry standard software packages (Enterprise Resource Planning (ERP)) • universities as ‘unique’ organisations (highly idiosyncratic) • diversity Vs. uniformity, organisational change, institutional isomorphism • How Universities make use of software solutions
Research Agenda on Software Packages • Polarised Debate • Proponents argue that a software working in one setting can be adapted to work elsewhere and, in principle. ‘everywhere’ • STS writing on software focuses on localisation • many terms for how software is localised (work-arounds, appropriation, domestication, mutual adaptation, design in use…) • Yet, packages do work across many sites (how?) • Lack of research on how s/w packages are developed (need for concepts and terms)
Research Agenda on Software Packages • How suppliers manage tension between designing systems for a specific user & wider market • ERP suppliers build systems that can be applied in widest range of markets • design packages with generic or ‘ideal types’ of organisations in mind (even if no such organisations actually exists) • How does this process of ‘genericification’ occur (and what does it mean for users)?
Initially built for one pilot site - ‘Scotia University’ but now used by many UK universities Supplier (‘Razor Systems’) now intend to market the package globally Process of Genericification: How PAMS moves from being ‘locally specific’ to a ‘national’ and potentially ‘global’ system? Property & Accommodation Management Systems (PAMS)
The ‘Biography’ of a Software Package • Few software systems developed from scratch • they have an ‘accumulated history’ which continues to influence the structures and practices of later adopters. • Rather than ‘snap shots’ (or implementation studies) focus on evolution of Package • Biography pays attention to the way packages move around (ie across boundaries) • how they are adapted to the needs of each new setting • how organisational specificities influence evolution • Social Worlds Theory (boundary objects) & Actor Network Theory (artefacts as actors with histories)
Razor Systems small software house wanted to build a package little expertise in Higher Education saw an undeveloped market niche (no accommodation sys) had existing financial package (backbone of PAMS) found a willing collaborator... Scotia University wanted system to bring together its ‘idiosyncratic organisation’ “There were 4 different ways to book a room and 6 ways to make an offer letter” (manager) only software available was hotel package or ERP systems PAMS allowed them to have a package (and all its benefits) but built around their specific needs! royalties... The ‘Birth’ of PAMS
Two ways to develop a package: • base package on ‘text book’ understanding of the application area • Computer Aided Production Management (CAPM) • or, find a representative organisation and develop a system based on this organisation • make the system more generic by identifying those ‘universal’ aspects of the system whilst coding out specific user features • said to be ‘difficult’ or ‘impossible’ Source: Bansler & Havn, 1996
1st Stage: Flexible/Unstable • “Accumulative Functionality” • build in as much functionality as possible • every requirement found place in system library • Configurational Technology (Fleck, 1994) • give the user choices that provide closest fit
Accumulative Functionality When we first wrote PAMS for Scotia University they produced a payment schedule that gave the student the choice of paying in 3 equal instalments… The next customer, Bravo University, also offered the choice of paying in termly instalments but they massaged the amounts to take 40% in term 1, 40% in term 2 and 20% in term 3 as they wanted to get as much paid as possible before the student ran out of money. We therefore added a tick box on the payment plan to say ‘use ratios’ and this then gave access to an extra column that allows Bravo to enter the % against each instalment... Charles University came along and they offered students a discount if they paid by a certain date, so we had to add another column… Delta University on the other hand charges a penalty for late payments so we added a process that...
1st Stage: Flexible/Unstable • Increase in Complexity • increase in database of functions (but also number of screens, options, menus etc) • More configuration needed • Increased training for users needed • Accumulation of functionality cannot be sustained with increasing user base • from 1 to 41 user sites • increase in variety of demands (perceived homogeneity failed to appear)
2nd Stage: Reducing Flexibility • Razor have a choice: • continue to expand PAMS • no limit to amount of accumulated functionality • but limits to corresponding graphical menus • danger PAMS becomes ‘too local’ “We are not going to accommodate as much diversity as we have in the past because it constrains our ability to grow and resell” (MD) • or attempt to manage the user base
Segment User base Transactional (34) those who make demands but not prepared to pay Consultative (4) those willing to work with supplier and may contribute to new functionality Strategic (3) those active in development and willing to undergo risks as pilot sites Classification shapes their interactions with users “It reflects the type of relationship the customer wants to have with us” (SM) “It’s about where we perceive it’s worth putting the effort” (MD) Strategies to go from Stage 1 to Stage 2: Managing the User Base
Proximity of Users to Artefact Promote “Best Practice” Influence Decisions Razor Systems Strategic Transactional Test New Ideas Consultative Discuss Best Practice
Promote “Best Practice” encourage new (transactional?) users to draw on accumulated functionality “Would you like to pay £10,000 or make the student pay 4 days earlier?” (MD) “The ability to replicate is how we get great value for our development efforts” (SM) consultancy services (‘experts in HE’) “In the UK the market suffers from a lack of willingness to measure the returns they make on investment…they will simply sit on trying to replicate the way on which they work at the moment. Take online applications: despite us having it available for a while there’s a certain resistance even though they’ll make significant clerical savings” (MD) Strategies to go from Stage 1 to Stage 2:Managing the User Base
Strategies to go from Stage 1 to Stage 2:Managing the User Base • Promote Uniform Needs • Construct a Community • the User Group (facilitate meetings) • forcing them to look for similarities among themselves instead of proposing individual needs “...hands up who thinks this is a worthwhile development…?” (MD)
Genericification of Needs Differences Differences Differences Competition Competition User Group Search for equivalence across differences, process of working disparate ‘needs’ together emergence of ‘Generalised’ Differences leads to Standardisation
Strategies to go from Stage 1 to Stage 2:Managing the User Base • Support ‘good’ user innovation “Lima University have done a fair bit…80% of that has been incorporated into the standard package…They were willing to run ahead…they had the resources” (programmer talking about a Consultative User) • Reject ‘bad’ innovation “We make sure that it’s in the contract that they don’t do things like that. We have had customers manipulating the data…from the back-end…Very dangerous…They promised not to do it again” (programmer discussing a Transactional User)
Strategies to go from Stage 1 to Stage 2:Managing the User Base • With configuration (and user customisations) there there is a danger that there will be many different packages in use • and that the supplier will have to support many versions of the same system • Upgrade Pathways (coherent ‘biography’) • force user base to evolve with the package as ‘older’ versions of the system are not supported
PAMS is Mature/Stable “[Razor] is dedicated to the development of property and accommodation management systems and supplies 41 of the UK’s top universities and colleges. Our software is used to manage over 110, 000 beds, making us the largest as well as fastest growing supplier to this market” (Supplier Brochure) • 3rd Stage: The Future Global Market (USA, Australia, Europe, India...)
Promising Future… • Expansion Heuristics (competition, market size) • Organisational fit • in research look for similarities (ignore differences) • but key differences become important • recognition how locally specific the current system is “there are also big differences in the way the allocation is going on. There’s more matching going on booking online…there’s potentially a big functionality gap…students booking online, we don’t have that” (MD talking about the US market)
Package Evolution & Change of Identities PAMS Stage 1 Specific Razor Systems Users Reactive, Learn, Collaborate Demanding, Diversity Enriched Stage 2 Razor Systems Growing, Community, Configured, Uniformity Users Growing, Stabilise/Formalise Control Users Users Standardised Stage 3 Enlarged Community, Regional Users?? Isomorphism?? Users Razor Systems Reactive?? Learn?? Collaborate?? Users Global or Regional?? Users
Conclusion:University or Universality: • Supplier has choice between increasing package scope and specificity and increasing its market size • Increasing functions within PAMS gives benefits and value to users. • But embodying evermore local knowledge within software has implications for its applicability and fit in other settings. • Diversity is managed through search for ‘generalised differences’ which is amenable to standardisation