Information technology has been readily deployed to support simple, process-oriented work. Far less has been done to support the other types that exist.
As we transition from a focus on standard processes and data handling systems alone, to a rich information environment, the other forms of work are coming to the fore.
The first uses of group technologies were often to facilitate complicated work, a domain where agreement must be reached amongst a group of practitioners none of whom hold sufficient authority to control the outcome.
An IT example of this include the enterprise architecture team at work devising the future state business architecture, or building the technology roadmap.
Elsewhere in the enterprise, departments like product marketing often have this work style.
Indeed, it is the common work style of academia, professional service firms, law firms, and other collegiate bodies.
Group technologies — perhaps in tools like Lotus Notes, or as wikis, or in Sharepoint — tend to become electronic means for “continuing and refining the discussion”.
But there are action-oriented pieces of work that need this capability, starting with inter-enterprise linkages. Business partners don’t set terms for each other in the same way a decision can be “rendered” within the organization.
These may, in turn, lead to order scenarios having to be managed (rather than the simple process of managing orders).
A prime example of this sort of thing (for it’s not new) is the Asian business view of a relationship. The contract is an indicator: real partners work to allow both to succeed. Contracted quantities, prices, etc. may be set aside “for the good of the relationship”. The details are worked out around the agreement, not via it.
IT systems typically do not handle these chains of manoeuvres well. But the need to undertake them is growing.
Then there’s situations where there is no process established, yet work must take place. Depending on how much is understood, these can be considered chaotic (no one is in control and team formation doesn’t really make sense yet), or complex (teams to probe an opportunity or problem self-form and undertake action to be evaluated later).
From an IT point of view, there is an underlying substrate of information that needs to be made available — and a slew of results from analysis and investigation captured, organized, made useful (curated) and circulated — from work in these domains.
Today much of this type of work gets trapped in individuals’ notebooks, or in emails. Yet it is the heart of new organizational learning, and of innovation.
It’s also not entirely “form-free”: it’s not, in other words, disordered effort. It’s just not a form of order that our existing systems, methods of problem analysis, etc. are designed to deliver.
Meanwhile, in the simple process order, there are increasing moves to uncouple process elements to allow for barely repeatable service actions, or to increase flexibility on the part of the organization.
Even here, therefore, we’re moving away from the “one size fits all” or “best practice” approach to work.
Since software emulates work processes, software that rigidly imposes a process order (for instance) works against this.
We can’t just expect to set up a parallel information order using data warehouses, business intelligence tools, social media, apps designed for the “brought my own device” approach to personal technology … we need to fundamentally rethink how we think about problems.
First, a high-value-add IT function needs to be able to respond to all of these types of work.
That means also being able to respond at the speed of the work, if the people doing it need services. Chaotic and complex work, for instance, moves very rapidly, relative to complicated and simple work orders.
You can’t succeed by tying the innovation work, for instance, to a year-long architectural review process, waiting for a consensus to emerge.
So CIOs must ensure that some pre-work occurs aimed at keeping the cost of delivering service, and the ability to do so at the right speed, in line with enterprise needs.
There must also be a clear understanding of what pieces of each type of work are able to seen as “commodified” (in which case standard tools can be provided) and where it requires a “differentiated” solution to support differentiating the enterprise in its markets.
Those pieces are likely to be composed from subcomponents, bridges, bespoke code. It’s what makes your enterprise lead in some competitive fashion; by definition, standard packages, no matter how configurable, are for situations where the value-add has been turned into a commodity and now cost leadership or market share are the sole differentiators left.
When building a portfolio for the future — an architectural future state — these are the considerations that should underlie renovation changes, new service introductions, and the balance of the portfolio between business requests and required underpinnings for the long haul.