Eight to Late

Routines and reality – on the gap between the design and use of enterprise systems

with 7 comments

Introduction

Enterprise IT systems that are built or customised according to specifications sometimes fail because of lack of adoption by end-users. Typically this is treated as a problem of managing change, and is dealt with in the standard way: by involving key stakeholders in system design, keeping them informed of progress, generating and maintaining enthusiasm for the new system and, most important, spending enough time and effort in comprehensive training programmes.

Yet these efforts are sometimes in vain and the question, quite naturally, is: “Why?”  In this post I offer an answer, drawing on a paper by Brian Pentland and Martha Feldman entitled, Designing Routines: On the Folly of Designing Artifacts While Hoping for Patterns of Action.

Setting the context

From a functional point of view, enterprise software embodies organisational routines - i.e. sequences of actions that have well-defined objectives, and are typically performed by business users in specific contexts.   Pentland and Feldman argue that although enterprise IT systems tend to treat organisational routines as well defined processes (i.e. as objects), it is far from obvious that they are so. Indeed, the failure of business process “design” or “redesign” initiatives can often be traced  back to a fundamental misunderstanding of what organisational routines are. This is a point that many system architects, designers and even managers / executives would do well to understand.

As Pentland and Feldman state:

… the frequent disconnect between [system or design] goals and results arises, at least in part, because people design artifacts when they want patterns of action…we believe that designing things while hoping for patterns of action is a mistake. The problem begins with a failure to understand the nature of organizational routines, which are the foundation of any work process that involves coordination among multiple actors… even today, organizational routines are widely misunderstood as rigid, mundane, mindless, and explicitly stored somewhere. With these mistaken assumptions as a starting point, designing new work routines would seem to be a simple matter of creating new checklists, rules, procedures, and software. Once in place, these material artifacts will determine patterns of action: software will be used, checklists will get checked, and rules will be followed.

The fundamental misunderstanding is that design artifacts, checklists, and rules and procedures encoded in software are mistaken for the routine instead of being seen for what they are: idealised representations of the routine. Many software projects fail  because designers do not understand this.  The authors describe a case study that highlights this point and then  draw some general inferences from it.  I describe the case study in the next section and then look into what can be learnt from it.

The situation

The case study deals with a packaged software implementation at a university. The university had two outreach programs that were quite similar, but were administered independently by two different departments using separate IT systems. Changes in the university IT infrastructure meant that one of the departments would lose the mainframe that hosted their system.

An evaluation was performed, and the general consensus was that it would be best for the department losing the mainframe to start using the system that the other department was using.  However, this was not feasible because the system used by the other department was licensed only for a single user. It was therefore decided to upgrade to a groupware version of the product. Since the proposed system was intended to integrate the outreach-related work of the two departments, this also presented an opportunity to integrate some of the work processes of the two departments.

A project team was set-up, drawing on expertise from both departments. Requirements were gathered and a design was prepared based on the requirements. The system was customised and tested as per the design, and data from the two departments was imported from the old systems into the new one. Further, the project team knew the importance of support and training: additional support was organised as were training sessions for all users.

But just as everything seemed set to go, things started to unravel. In the author’s words:

As the launch date grew nearer, obstacles emerged. The implementation met resistance and stalled. After dragging their feet for weeks, [the department losing the mainframe] eventually moved their data from the mainframe to a stand-alone PC and avoided [the new system] entirely. The [other department] eventually moved over [to the new system], but used only a subset of the features. Neither group utilized any of the functionality for accounting or reporting, relying instead on their familiar routines (using standalone spreadsheets) for these parts of the work. The carefully designed vision of unified accounting and reporting did not materialize.

People in the department that was losing the mainframe worked around the new system by migrating their data to a standalone PC and using that to run their own system. People in the other department did migrate to the new system, but used only a small subset of its features.

All things considered, the project was a failure.

So what went wrong?

The authors emphasise that the software was more than capable of meeting the needs of both departments, so technical or even functional failure can be ruled out as a reason for non-adoption. On speaking with users, they found that the main objections to the system had to with the work patterns that were imposed by it. Specifically, people objected to having to give up control over their work practices and their identities (as members of specific) departments. There was a yawning gap between the technical design of the system and the work processes as they were understood and carried out by people in the two departments.

The important thing to note here is that people found ways to work around the system despite the fact that the system actually worked as per the requirements. The system failed despite being a technical success. This is a point that those who subscribe to the mainstream school of enterprise system design and architecture would do well to take note of.

Dead and live routines

The authors go further: to understand resistance to change, they invoke the notion of dead and live routines. Dead routines are those that have been represented in technical artifacts such as documentation, flowcharts, software etc. whereas live routines are those that are actually executed by people. The point is, live routines are literally living objects – they evolve in idiosyncratic ways because people inevitably tweak them, sometimes even without being conscious that they are making changes. As a consequence live routines often generate new patterns of action.

The crux of the problem is that software is capable of representing dead routines, not live ones.

Complementary aspects of routines

Routines are composed of people’s understandings of the routines (the authors call this the ostensive aspect) and the way in which they are actually performed or carried out (the authors call this the performative aspect). The two aspects, the routine as understood and the routine as performed, complement each other:  new actions will modify one’s understanding of a routine, and the new understanding in turn modifies future actions.

Now, the interesting thing is that no artifact can represent all aspects of a routine – something is always left out. Even though certain artifacts such as written procedures may be intended to change both the ostensive and performative aspects of a routine (as they usually are), there is no guarantee that they will actually influence behaviour.  Managers who encounter resistance to change will have had first-hand experience of this: it is near impossible to force change upon a group that does not want it.

This leads us to another set of complementary aspects of routines. On the one hand, technology puts in place structures that enable certain actions while constraining others – this is the standard technological or material view of processes as represented in systems. In contrast, according to the social or agency view, people are free to use technology in whatever way they like and sometimes even not use it at all. In the case study, the former view was the one that designers took whereas users focused on the latter one.

The main point to take away from the foregoing discussion is that designers/ engineers and users often have very different perspectives on processes.  Software that is based on a designer/engineer perspective alone will invariably end up causing problems for end users.

Routines and reality

Traditional systems design proceeds according to the following steps:

  • Gather requirements
  • Analyse and encode them in rules
  • Implement rules in a software system
  • Provide people with incentives and training to follow the rules
  • Rollout the system

Those responsible for the implementation of the system described in the case study followed the steps faithfully, yet the system failed because one department didn’t use it at all and the other used it selectively.  The foregoing discussion tells us that the problem arises from confusing artifacts with actions, or as I like to put it, routines with reality.

As the authors write:

This failure to understand the difference between artifacts and actions is not new…the failure to distinguish the social (or human) from the technical is a “category mistake.” Mistakenly treating people like machines (rule-following automata) results in a wide range of undesirable, but not entirely surprising, outcomes. This category difference has been amply demonstrated for individuals, but it applies equally (if not more so) to organizational routines. This is because members’ embodied and cognitive understandings are often diverse, multiple, and conflicting.

The failure to understand the difference between routines and reality is not new, but it appears that the message is yet to get through: organisations continue to implement (new routines via) enterprise systems without putting in the effort to understand ground-level reality.

Some tips for designers

The problem of reconciling user and designer perspectives is not an easy one. Nevertheless, the authors describe an approach that may prove useful to some. The first concept is that of a narrative network – a collection of functional events that are related by the sequence in which they occur. A functional event is one in which two actants (or objects that participate in a routine) are linked by an action. The actants here could be human or non-human and the action represents a step in the process. Examples of functional events would be:

  1. The sales rep calls on the customer.
  2. The customer orders a product.
  3. The product is shipped to the customer.

The important thing to note is that the functional event does not specify how the process is carried out – that can be done in a myriad different ways. For example, the sales rep may meet the customer face-to-face or she may just make a phone call. The event only specifies the basic intent of the action, not the detail of how it is to be carried out. This leaves open the possibility for improvisation if the situation calls for it. More importantly it places the responsibility for making that decision on the person responsible for the carrying out the action (in the case of a human actant).

Then it is useful to classify a functional event based on the type of actants participating in the event – human or (non-human) artifact. There are four possibilities as shown in Figure 1.

Figure 1: Human-artifact grid

Figure 1: Human-artifact grid

The interesting thing to note is that from the perspective of system design, an artifact-artifact event is one over which the designer has the strongest control (actions involving only artifacts can be automated) whereas a designer’s influence is the weakest in human-human events (humans rarely, if ever, do exactly as they are told!). Decomposing a routine in this way can thus serve to focus designer efforts in areas where they are likely to pay off and, more importantly, help them understand where they are likely to get some push back.

Finally, there are some general points to consider when designing a system. These include:

  1. Reinforce the patterns of the routine:  Much as practise makes an orchestra perform better, organisations have to invest in practicing the routines. Practice connects the abstract routine to the performed one.
  2. Consider every stakeholder group’s point of view: This is a point I have elaborated at length in my posts on dialogue mapping so I’ll say no more about it here.
  3. Understand the relationship between abstract patterns and actual performances:  This involves understanding whether there are different ways to achieve the same goal. Also consider whether it is important to enforce a specific set of actions leading up to the goal, or whether the actions matter less than the goal.
  4. Encourage people to follow patterns of action that are important:  This involves creating incentives to encourage people to carry out certain important actions in specified ways. It is not enough to design and implement a particular pattern within a routine. One has to make it worthwhile for people to follow it.
  5.  Make it possible for users to become designers: Most routines involve decisions points where actors have to choose between alternate, but fixed, courses of action. At such points human actors have little room to improvise. Instead, it may be more fruitful to replace decision points with design points, where actors improvise their actions.
  6. Lock in actions that matter: Notwithstanding the previous point, there are certain actions that absolutely must be executed as designed. It is as important to ensure that these are executed as they should be as it is to allow people to improvise in other situations.
  7. Keepan open mind and invite engagement:  Perhaps the most important point is to continually engage with people who work the routine and to be open to their input as to what’s working and what isn’t.

Most of the above points are not new; I’d even go so far as to say they are obvious. Nevertheless they are worth restating because they are often unheeded.

Conclusion

A paradox of enterprise systems is that they can fail even if built according to specification. When this happens it is usually because designers fail to appreciate the flexibility of the business process(es) in question. As the authors state, “…even today, organizational routines are widely misunderstood as rigid, mundane, mindless, and explicitly stored somewhere.”  This is particularly true for processes that involve humans.  As the authors put it, when automating processes that involve humans it is a mistake to design  software artefacts while hoping for (fixed) patterns of action. The tragedy is that this is exactly how enterprise systems are often designed.

Written by K

November 13, 2013 at 8:55 pm

7 Responses

Subscribe to comments with RSS.

  1. Insightful and useful essay, as usual!

    One minor criticism: I suspect that Pentland and Feldman may be making their own category error in their analysis of the cause of system design failure. This passage caught my eye:

    “… people objected to having to give up control over their work practices and their identities (as members of specific) departments. There was a yawning gap between the technical design of the system and the work processes as they were understood and carried out by people in the two departments.”

    That first sentence reminds us that there are two dimensions of work: doing (‘work practices’) and being (‘identities’). In my experience the aspect of being is actually more fundamental, and gives rise to the character of the doing. So when workers rebel against the new system, it may be due to the system’s failure to acknowledge aspects of differences in being, like the identity of their group within the organization or their identity within the group, in addition to its failure to take differences in doing (e.g. ‘live routines’) into account.

    I suspect the importance of the being aspect of systems design is nicely illustrated by the case study of the university departments. Apparently the design goal of integrating the outreach-related work of the two departments resulted in an implementation that essentially treated users from both departments as if they were all the same, perhaps even interchangeable – getting their work done within the same social structure with the same set of roles and the same power relations among roles. Collapsing the users identities across departments might be just a corrosive, if more subtle, as collapsing their routines across departments.

    I would suggest that system design will be even more effective if it distinguishes between being and doing, and well as between doing dead routines and doing live ones.

    Cheers,
    Jeff

    Jeff Conklin

    November 14, 2013 at 4:41 am

    • Hi Jeff,

      Thank you for reading and for making an excellent point: indeed, the problem with enterprise systems is that they attempt to “uniformise” identities by treating users from a single function (say, finance) but different work contexts (say, Australia and Singapore) in the same way. As you mention, collapsing identities in this way is likely to be just as corrosive as uniformising routines.

      That said, it is important to note that workplace identities constantly evolve via negotiation (between employers and employees), improvisation (doing something different at work) and, yes, even through the deployment of new enterprise systems. The reality, unfortunately, is that such systems are here to stay, at least in the corporate world. So, what can we do to make life better for those who are on the receiving end?

      My take on Pentland and Feldman’s work is that they are suggesting that designers “loosen up” and allow flexibility where possible, especially at human-human interfaces (see figure above). The idea is to lock in actions that are important but also enable users to improvise wherever possible (points 5 and 6 in the section. “Some Tips for designers”). Of course, this is easier said than done…but I guess they intended it more as food for thought rather than practical advice.

      Thanks again for your insightful comment!

      Regards,

      Kailash.

      K

      November 14, 2013 at 8:40 am

  2. […] Kailash Awati examines the gap between the idealized representations of business processes we design into our enterprise systems and actual day-to-day work patterns. […]

  3. The mistake that the system people made, and I think that its easy for any of us to make, is hinted at in the line “treating people like machines”; Taylorism dogs all organisations, and leads us to forget that work is a social system: a complex of culture, joint objectives, social influence and negotiation, with the diverse sets of motives and objectives we all bring to work and all contribute to its social system. Any change has thus to be negotiated as a social adjustment through a set of conversations that both express and resolve the ‘problem’.

    Along these lines I worked in the NSW Government construction system where Checkland’s ‘soft systems methodology’ had been influential. The approach it lead to moved project development from a mechanistic set of routine responses, to an evolving conversation of interest groups; usually producing a richer and more beneficial result with fewer disputes and misfits of artifact to purpose.

    David

    November 18, 2013 at 7:13 pm

    • Hi David,

      Thanks for reading and for your comment.It is especially appreciated because this is a long piece, even by my verbose standards :-)

      Your observation regarding Taylorism is spot on. Indeed, as I have discussed in a recent post, Taylorism is on the rise again; this time manifesting itself in sneaky ways, often aided by technology.

      As you say, change (if it is to succeed at all) must be negotiated as a social adjustment. I’m curious about your experiences in using soft systems methodology (SSM) for this. Most people report that it is difficult to put SSM into practice. Some problems cited include – politics, hidden agendas and power relationships.If you have the time, it would be terrific if you could share some of your experiences in addressing these.

      Thanks again for taking the time to read and comment – much appreciated!

      Regards,

      Kailash.

      K

      November 19, 2013 at 4:32 pm

      • Kailash,
        I agree SSM is complex; I think Checkland has ‘over scienced’ it. But it has influenced colleagues in NSW public service in developing a value management approach in the 90s to large project procurement and then the ‘gateway review’ system; both of which I’ve been directly involved in. The VM system used SSM as the basis for its system of ‘enquiry’ into the basis for a project and the project strategy and objectives. It s not the full SSM which fails on having too many categories and reference points to the world outside. The VM system, however, does ask participants to cast their minds widely, in a structured methodology. Both approaches take a conceptual approach that aligns with the IBIS approach you have written about, although structured differently.

        Links:

        http://www.treasury.nsw.gov.au/__data/assets/pdf_file/0009/5112/value_management.pdf

        http://www.procurepoint.nsw.gov.au/policy-and-reform/gateway-review-system

        David

        November 26, 2013 at 6:56 pm

        • Hi David,

          Thanks for the links – I see the connections between Value Management and SSM/IBIS-based approaches.

          Regards,

          K.

          K

          November 27, 2013 at 6:55 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 250 other followers

%d bloggers like this: