The Business of Being a User: How Reference sites ﬁgure in the new poli9cs of so:ware acquisi9on Neil Pollock University of Edinburgh, UK Sampsa Hyysalo Aalto University, Finland
OrganizaCon wide InformaCon systems (IS): ERP, CRM etc. • Used to be built for an organizaCon, sCll clunky • “Octopus” that spreads its tentacles throughout an organizaCon (AccounCng, HR, Manufacturing, Sales, Procurement, R&D…) • Code recycling: packages – Generic core e.g. SAP r3 – Higher educaCon module – InstallaCon … with hundreds of conﬁguraCons, customizaCons, add-‐on SW, bolt-‐on SW – Evolving and being updated at each level
Background: Pollock & Williams: SoXware & OrganizaCon. Routledge, 2008 • AccumulaCon of funcConality… win-‐win..then • From “generiﬁcaCon” by requirements workshops – Management by community • Witnessing diﬃculty and conﬂicCng needs – Management by content • Process alignment • Working the Acetate etc social tricks • …To generiﬁers – To get your requirement accepted by supplier … it needs to appeal to many sites (otherwise you need to maintain and upgrade it at your own expense). – Et voilá users seek generalizability in and among themselves – Those willing to change their organizaCon the most to ﬁt the technology and/or commission addiCons to become heard more
Business of being user – Why would IT users carry out what are oXen highly burdensome, Cme-‐consuming tasks on behalf of vendors? – What exactly is the role they are performing in the doing of these acCviCes?
Findings in brief: what reference sites do Marketing • writing formal recommendations on behalf of vendors assuring prospective customers about the abilities, resources, commitment, and so on, of the vendor • presenting ‘success stories’ at various industry forums (industry conferences, user group meetings, and the like). • providing feedback to the vendor about how its sales efforts are progressing and how they could be improved Demonstrating • demo the newly installed software to prospective customers beyond the system what is mandated by the contract and despite the fact that the suppliers compensation does not cover the full cost of demos. • striving to become “flagship” installation that would run the whole suite of vendors’ modules, despite itself not necessarily having use for all of them. Designing parts • providing their own programming as part of the package, many of the system times without gaining any royalties or other compensation for it Constructing • helping to construct the value of functions for prospective customer the value of the organizations system • educating (lobbying) the vendor about the market, where they are located and how the package ought to be further developed within this market.
Data & Analysis • MulCple data sources over a ten year Cme span: – IT Director of ‘Big Civic’ University gave us full access to his email for over the period of a year: ConversaCons with the vendor, his university colleagues, other reference sites and prospecCve customers. (several large ring binder folders) – We were also able to interview members of the ‘Big Civic’ IT project team and observe them in meeCngs with each other and with vendor staﬀ – Focus group with university managers involved in the project where we presented iniCal ﬁndings from our study: further debates about their experiences as reference sites. – Interviews with a number of SoXCo employees about their relaConship with speciﬁc customers. – Interview other reference sites and customers involved with SoXCo. – Ahendance at various industry forums & SoXCo user group meeCngs & industry events where SoXCo was ahempCng to market its soluCons. • Analysis: – InducCve data-‐handling step by step a kin to open, axial and theoreCcal coding in Grounded Theory (Glaser & Strauss, 1967; Clarke, 2005) – Themes elaborated within the length of the ﬁnal arCcle a) illustraCve of larger bodies of data as well as b) ones that were not suﬃciently discussed previously within IS research
Not asking requirements, but sales value potenCal “What would be the potenCal beneﬁts or (measurable) value in implemenCng a soXware soluCon to address these pain points? For example: Improve responsiveness now, and retenCon rates later, by having a single view of all student data. • * Improve student experience by 20%. Improve eﬀecCveness of recruitment using all channels (including self-‐service). • * Enhanced recruitment eﬃciency & producCvity 10-‐20% • * Increase retenCon by 10% Improve compeCCveness in the prospecCve student "market".. • * Improve response rate by 20% • * Reduce costs by 10-‐20% Maximize use of resources to support insCtuConal recruitment and retenCon goals. • * Enhanced standing of University (email sent from a SoXCo ExecuCve to BigCivic IT Director).”
…and in response within Bic Civic Thank you for delivering such a comprehensive and professional report. I would suggest a couple of addi9onal points should be added on the Beneﬁts sec9on:-‐ 1). How much Time/Resource was consumed in processing an ApplicaCon under the "old" system. How much Time/Resource is consumed under the "new" system? I now understand that 50% of applicaCons are being received electronically now. How much admin Cme has been saved across the University? 2). Now that consistent and accurate management informaCon is available immediately (via the BW reports), what is the VALUE of this informaCon? How much management/admin Cme is saved in the creaCon and distribuCon of this informaCon? How can this be quanCﬁed? 3). How can [BigCivic] get a reasonable comparison between the numbers/quality of the applicaCons which we are processing this year compared to what might have happened if we were to have conCnued with the "old" systems? 4). What is the value (if any?) of our new posiCon as the [SoXCo] ‘lighthouse’ HE insCtuCon? Can we extract any beher value from this (and our IPR within the E2R applicaCon)? Please note that I would ﬁnd it diﬃcult to place a value on this or give any evidence that it has/will be of beneﬁt, but it might have a substanCal payback if managed properly (email from BigCivic IT Director to BigCivic accountant).
Contradictory Logics: Tensions and gameswithin user and vendor organizations
Selling vs. day job Although clearly we wish to help other universiCes and [SoXCo], I feel I need to make the point that if were out promoCng e2r to others, were not focusing on the day job here, and the consequences of this for the University could be signiﬁcant. Unfortunately, there is no evidence that our budgets will increase to provide us with a lihle more capacity. Maggie, for example, has a huge job outwith e2r and shes had to put a lot of it on the back burner for the last few months. I dont think it can stay there in the longer-‐term. If we answered Malcolms [from So:Co] queries in any real depth, it would take quite a lot of 9me, and if this request is followed by similar ones, we could be in some diﬃculty.
Ambiguity over inﬂuencing the vendor What I ﬁnd it hard to know, perhaps I should do some more reading or whatever, is exactly how important we are to them. How that relaConship is, I know Paul is always saying ‘this is the market they are moving into they really need you to know. But they are a great big global company and Higher Educa9on is a miniscule liNle bit of what they do. They might just as easy say ‘oh, we’re not going to concentrate on that’. I mean I don’t have a grasp of that so I am just buﬀeted around by diﬀerent arguments depending on who I have just heard (taped discussion of BigCivic project team meeCng).
Monetizing the Reference Site Relationship: The Standard Package or a Special Partner in Value Creation?Please note IF [IvyLeague] want to visit us then I need to see a resource plan for the visit. I have given an assurance to [the Student Registrar] and the Vice Chancellor that we will NOT divert [BigCivic] resources in [So:Co] marke9ng eﬀorts without prior approval. Therefore I need to know:-‐ a) How many FTE days will be required prior to, during and aXer the [IvyLeague] visit -‐ note that these days must also include key Users (eg Maggie…Colin…etc); and b) What [SoXCo] will be oﬀering to us in recompense. Note that the MINIMUM So:Co compensa9on must be "one-‐hour for one-‐hour". If they do not agree then you must inform [IvyLeague] that we will NOT be available for anything other than telephone conference calls (email from the BigCivic IT Director to the SoXCo Account Manager).
The standard package … binds the hands of front line collaborators Hi Paul:…I appreciate your understanding regarding the compensaCon for the customer references. I certainly appreciate all you do to support us, but as you can see we have a standard ‘package’ for this which we have to adhere to. I will go ahead and give the ‘green light’ to the visit from the Norwegian customer ([LoanFirm]) based on our standard reference bonus (which I believe is £1,000 per visit to be paid on consulCng and/or training) (email from a SoXCo ExecuCve to the BigCivic IT Director).
yet… user organizaCon not reduced but sought to enhance their role as a reference site. ….Im not sure if this is an appropriate 9tle, but the concept should be that [BigCivic] set up a server containing ALL [So:Co] modules and populated with real University data. This would then be useable as a demonstrator environment for any University wishing to see So:Co products (we would also be happy to undertake a support role if [So:Co] wanted to demonstrate their products to prospec9ve customers). We are very aware that we are disappoinCng visiCng UniversiCes when we demonstrate the funcConality which we have bought and are using but we can not demonstrate the func9onality which we have bought but dont use (eg CRM and Business Warehouse) and we cant demonstrate the func9onality which we havent bought (eg ESS and others). I appreciate that [BigCivic] will need to devote signiﬁcant resources -‐ Im guessing that it may take 1 Full Time Equivalent person to ensure that this system is kept up to date, that the data is refreshed and that we know how to use the parts of the system that we do not have in produc9on (eg ESS, Grants Management etc). However, I think that the investment by [BigCivic] will be well worthwhile -‐ especially if it helps [SoXCo] gain more Campus Management customers (its very lonely AND worrying to be the only University in the UK with CM!).
& symmetrically at SoXCo Paul, Thanks for this note & the senCments embodied. Your email is helping me to apply pressure within [So:Co] UK (and AG) to get adequate resources to: 1) Compile a compelling CRM/CM proposal (Im trying to get Joachim to [BigCivic] -‐ unfortunately hes on hols at present -‐ watch this space); 2) Sell Campus eﬀecCvely in UK HE. If we can organise 20/21st Id appreciate the opportunity to meet up on the 20th to explain where we are at in resourcing terms.
MulC-‐level games within and between user and vendor organizaCons • the BigCivic pressure (lehers, emails etc.) had an eﬀect. In parCcular, it was put to use by the SoXCo Higher EducaCon team to argue for more resources within the global SoXCo organizaCon. • As a result, SoXCo has seemingly ﬁnally decided to direct more resources towards the higher educaCon sector. • However, these resources will in turn require further eﬀort by BigCivic as a reference site (in training up the new SoXCo person on the parCculariCes of the higher educaCon terrain). • … and even though some within the BigCivic organisaCon may be disgruntled about commizng even more Cme and resource to help SoXCo, they are seemingly not in a posiCon to refuse the oﬀer.
Discussion: why reference sites do it • Users have relaCvely lihle control over the future evoluCon of packaged enterprise soluCons, developed for swathes of customers • Even their own addiCons and customizaCons need to be redone (at their expense) upon upgrades and version • User organisaCons are increasingly segmented according to the size of the market they represent • “Angry Orphan” – “Favourite relaCon” • They can legiCmate this qua mulCple modes of valuing
To Conclude • ParCcipaCon as a means for a producer – Gain knowledge it cannot access or create – Create needed collaborators in design and markeCng – Manage the diversity of user collaborators – Educate / domesCcate its customers, IT professionals in user organizaCons – Gain legiCmaCon and credibility in the market • ParCcipaCon/cooperaCon as a means for users – To wield inﬂuence over package development – Gain some programming eﬀort – ProacCvely retain the package more suited for themselves – Increase the say of “community” they belong to – Hamper some of their compeCtors requirements being met • MulC-‐level games / ecology of games … at a cost
QuesCons for Discussion • What other “grey zone” forms of parCcipaCon have you encountered? • What other perspecCves would be viable for understanding parCcipaCon processes? • When does parCcipaCon cease to be parCcipaCon ? (re: e.g. expoitaCon, poliCcal tacCcs…)