Information Technology: Commodity or Strategic Resource (2)

Posted on 09. jul, 2010 by in Information Technology, Operational Excellence and Strategy & Innovation

(versión en español en los próximos días)


In the previous post, we brought out the controversy about IT being a commodity or a strategic resource.   Depending on what side you take, IT management could be about administering costs and risks (commodity) or about envisioning and making the most of the business value of IT (BVIT).  

In that post, we already commented on the first dimension of BVIT, related to the role IT (technology + content) plays on supporting decision processes.   Another dimension of BVIT is linked to the role of IT in automating and coordinating business processes, which in turn can be intra-organizational (involving internal activities) or inter-organizational (concerning interactions with markets and partners).

In this post, let’s explore IT’s value automating and coordinating internal business processes.  Since we want to discuss the business value of the technology, I will not emphasize the means (IT functionality), centering attention on the ends (business impact).  Thus, let’s start by digging into the process paradigm, which is relatively recent in the business world, as compared to the functional paradigm.

The functional paradigm

A little history is useful here.  When Adam Smith proposed the functional division of labor, back in 1776, he insisted that by dividing complex work in small tasks and assigning each one of them to a specific worker, greater productivity will result from the underlying specialization (learning + repetition).    Of course, functional division of labor had been around for centuries.  Early civilizations recognized that as the human species keeps producing knowledge, it becomes quite difficult for people to master an ever broadening and deepening set of skills.  Trades, crafts, professions, all resulted from individuals learning to align their natural talents and inclinations with a specific subset of human knowledge.    Individuals became economic agents exchanging the fruits of their labor, first through barter, and later through currencies, leading to price-mediated markets.  Peasants, artisans, shoemakers, barbers, blacksmiths, and so on: functional division of labor defined the identity of economic agents.  

Renaissance, scientific method, and finally the industrial revolution enter the picture.    Technological innovations create new production machines that increasingly automate certain manual tasks.    Industrialists set up complex mass-production systems around these new machines.   Simple products that had been manufactured by craftsmen for centuries now face strong competition by cheaper mass-produced goods.  As the nascent industrial companies learn to impose their technology-driven cost advantage, they face an organizational challenge: how to configure a complex productive work-system within the firm?   This is the context where Adam Smith’s proposal of functional division of labor comes in.   

Previous to the industrial revolution, functional division of labor created identity for economic agents, as a combination of technological (know-how) and psychological (talent and personality type) factors.   After the industrial revolution, functional division of labor appears within industrial organizations as an economic driver of productivity.  The technological and psychological factors are still there, but now they create identity for organizational roles and positions.   Over the last two centuries, the functional paradigm has evolved, from its micro-level origin, to the macro-structuring level, so that nowadays it is noticeable in the way complex firms have structured themselves around organizational units specialized to perform functions.    

Modern industrial organizations have become so large that workers have a hard time fitting in and identifying themselves with such broad and complex social systems.  We, human beings have a strong tribal orientation.  We tend to look for small social systems where we feel we do belong.   This is a socio-cultural driver of functional division of labor.  Salespeople, plant workers, marketers, and IT specialists may work for the same company and share some corporate values, but at the end, they “belong” to their functions, and this explains while many companies are better understood as a federation of loosely-coupled units as opposed to an integrated organization.   

In summary, the functional paradigm to work configuration is very strong because it has several underlying mutually-reinforcing support forces: technological (know-how specialization), psychological (alignment between task, talents and personality types), economic (productivity associated to learning and specialization) and socio-cultural (“my tribe”).  Thus, the silo-mentality is not so easy to dismiss as some authors would like to dictate; the strong forces behind the functional approach to work are very strong and will not disappear any time soon from modern organizations.

The process paradigm

Back in the 1980s, the western world watched with surprise and disbelief how emergent Japanese multinational companies were able to supply products of great quality at much reduced prices.   Toyota competed with cars that used to cost around half of the “equivalent” General Motors´ car, without compromising quality, features and performance.   It took some time for the western companies to recognize that whereas they were competing with a functional approach to work configuration, their Japanese counterparts used a process approach.

The process paradigm is a systemic approach to work configuration:

a) It considers the individual tasks, but it goes beyond, to the integration of those tasks into a meaningful whole: “the process” 

b) It recognizes that workers are key stakeholders in the execution of work, but it goes beyond, and includes the clients/customers for whom the work is performed and “delivered” via a product or service.

c) It is aware of time and costs incurred in the execution of individual tasks, but it goes beyond, and reflects on the total time and cost incurred to execute the process, deliver the product or service, and satisfy the customer/client.

In contrast, the functional approach to work configuration, tends to emphasize individual tasks at the expense of the whole process.   It tends to have an inward-looking perspective to work, being less sensitive to the external stakeholders.  And it tends to think that the total time and cost incurred can be computed by adding the individual tasks´ time and cost.

Western companies expected their larger volume would translate into economies of scale and cost advantages at diverse functions.  So they had a hard time figuring out where the competitive advantage of their Japanese counterparts came from.   If you want to know what is the source of the competitive disadvantage of the functional approach compared to the process approach, then look at the coordination costs for the answer.  

Coordination costs occur at the interfaces between functions.    As work flows across functions and interfaces, three elements add up: value (to customers and other stakeholders), cost and time.  Of course, we want to accumulate value, while controlling the accumulation of cost and time; that is what productivity is all about!    At interfaces between functions, there are unfortunately abundant opportunities for exactly the opposite to happen: time and cost increase while value may even decrease.  Think of it as a 4×100 relay run.   You may have the best runners in each of the four segments; however if the interfaces don’t work right, time accumulates, or even worse, somebody may drop the baton, and your team loses.    In a working environment, dropping the baton at the interface creates defects, quality mishaps that reach the final customer as an inferior value and/or products and services that have to be re-processed again, adding costs.

We know there is a problem with coordination when these symptoms are prevalent: a) high defect rates, b) long end-to-end time to execute work, c) over-abundance of people in charge of making sure the baton is not dropped at each side of interfaces, and d) use of buffers, inventories and other slack resources to connect activities.   These four symptoms decrease value and increase costs, a dual negative impact on competitiveness.

But, why do these coordination costs tend to escalate under the functional approach to work configuration?   It is explained by the way costs behave with scale and task variety.   If the company supply one product or service, as market share and volume increases, economies of scale and learning (scale accumulated over time) reduce unit cost at each task in the work-system.  Scale dilutes fixed costs at the unit level.   Learning reduces mostly variable costs.  In this scenario, task variety is low (remember: one product or service).

However, after successful companies saturate their initial markets, they tend to add business by diversification: new products, customer segments, geographies and distribution channels.   Obviously, management wishes that each diversification thrust can be accomplished by leveraging most of the current business model; at least that would be great for financial results!   Though, as the complexity of business diversification is deployed over the existing work-system, task variety escalates.  Each new product, segment, geography or channel, needs a “little” adaptation at the work-system.   Eventually, as diversification continues, efficiency drops at the task level because variety introduces switching and set-up times, and economies of scale and learning may weaken.  But the greater effect tends to occur at the interfaces.

A functional work configuration subject to a diverse product-customer-geography-channel mix has a hard time juggling with so much variety at the interface level.   Imagine heavy traffic trying to cross a bridge: cars, trucks, motorcycles, and bicycles of different size and speed, coming from a four-lane highway, converging into a one-lane bridge.   At the other side of the bridge another four-line highway is available.  You could expect a real mess at that bridge.   

In an organization with a functional work system, functions are strong (remember the four forces underlying the silo mentality) and interfaces are weak; they do no have many friendly management sponsors, except for high level executives who always seem to wonder why they do not work!  When weak interfaces are challenged with the complex “work traffic” that is typical of a highly diversified company, defect rate increases (collisions), more buffers and inventories are required (long waiting lines) and more interface people are used (traffic officers).  Coordination costs escalate and eventually mask scale and learning efficiencies resulting from specialization at the functional task level.    These are the direct consequences of fragmented business process.

There are also some indirect consequences of fragmented business processes that have not been designed to deal with variety and exhibit weak interfaces.    When a business process does not work properly at the operational level, exceptions grow.  So we hear: “How do we handle this case?”, or:  “People at function xyz do not care about not letting the baton drop, so who fix this?”    The problem with process exceptions is they end up being solved by the most expensive coordination mechanism a company has: its management hierarchy.    Coordination mishaps ascend the hierarchy looking for someone with the authority to handle the exception.  The larger the process scopes, the higher in the hierarchy process exceptions tend to climb.   Organizations where key business processes are fragmented use up an important fraction of management time handling operational process exceptions.  No wonder, their management hierarchies are taller and fatter.   This is not only costly, it slows down the capacity to react to the environment and adjust to changing conditions.     Higher management costs and slow management processes are two indirect effects of business process fragmentation.

In summary, when a corporation faces a large and diversified business mix with a functional approach to work-systems, it ends up with less quality, larger process cycle time, higher costs at interfaces, a tall, fat, costly and slow management hierarchy.   This whole deterioration in competitiveness is sometimes called diseconomies of scale; although they are really caused by scale associated to excessive variety and fragmented business processes.  

That is why, back in the 80s, GM’s cars cost almost twice as much to produce compared to Toyota’s.  GM responded by heavily investing in further automation at the task level, but the challenge was not there, but at the interfaces.  Toyota, on the other hand, used a process perspective considering how value (quality), cost and time were simultaneously affected as work flowed through the whole process, and instead of creating local optimal configuration at each task, it designed for global optimal configuration at the process level, and they did not stop at their boundaries but included the whole supply chain in the definition of process.  That is why the process approach is systemic.   Starting with the voice of the customer (grater value at lesser price), Toyota’s workers and managers got involved to design a process-optimized work-system.

It is very important to notice that the (effective) process approach is not anti-functional, and it is not naïve ignoring the strong psychological and socio-cultural forces that make functions strong and interfaces weak in most organizations.    It does recognize the economic benefits of the functional division of labor, but it does no look for local optimal configuration at the task level.  It does recognize that people at the functions have a hard time getting out of the “please the boss” mentality to the “please the customer mentality”; thus process methodologies start with the voice of the customer and involve functional people in the design of the overall process.   Respecting the pros and cons of functional division of labor, the process approach concentrates on creating coordination capabilities at the work-system that match coordination needs of the business model, always with the customer in mind.   This translates into interfaces with higher “work bandwidth”.   Sometimes, this entails building a four-lane bridge and other times the whole highway system needs to be reconfigured.

IT as a key enabler of the process paradigm:

IT is not the only enabler of coordination capabilities that the process approach demand.    There are several organizational arrangements that can enhance coordination.  Physical layout improves coordination when “tangibles” flow through interfaces (including people!).  Flow configuration, considering sequencing, concurrent parallel work, control points, reciprocal interdependence, all of them dependent on business policies and rules, are key enablers of coordination.    These “other” coordination enablers are very relevant and deserve separate posts to talk about of them.    But here we are exploring the fundamentals behind the business value of IT.

In our first post in this series, we explore IT as an enabler of decision processes.  This is the world of business intelligence, multidimensional databases, data warehouses, data marts, decision support systems, smart analytical agents, and so on.

When IT support business processes, that is the world of enterprise systems (ERPs) and their relatives core systems (as they called them in the financial service sector), customer or supplier relationship management systems (CRMs, SRMs), workflow systems, groupware, web-based (internet, intranet, extranet) systems, enterprise architecture integration (EAI) and the emerging and promising business process management systems (BPMs)

These categories differ in flexibility (for example, workflows and BPMs are more flexible than ERPs), richness of functionality which affect the degree of automation (ERPs and CRMs being strong in this aspect), scope of the value chain covered (broad vs. focused).   Whatever the differences, they all share a common trait: process orientation.  They provide coordination bandwidth because they were all conceived and designed under the process paradigm, allowing for both strong functions (automation) and strong interfaces (coordination).    They are prepared to handle the effect of business diversification on process variety (task + interfaces).  In particular, BPMs + EAI represent the most promising category in terms of flexibly digesting process variety.

Of course, flexible coordination capabilities are not limitless.  Thus, although investing in these information technologies will help organizations deal with increasing variety, diseconomies of scale will eventually appear, although at a much larger level of variety than the non-IT-supported business process.

In conclusion, a key business value of IT is to improve process integration and flexibility, reducing defects, compressing process-cycle-times, reducing costs and buffers at interfaces, decreasing operational exceptions that climb through the management hierarchy, and freeing up management time for decision making.    If a company develops a superior strategic capability for identifying the key processes where cost and value drivers lie, and deploy the right IT system to those processes, it will improve efficiency and effectiveness.

As I also mentioned in the first post in this series, this does not mean any IT investment aimed to improved process integration will create economic value.    Sound IT management directs such investment to those initiatives with a positive business case.   A good starting point is to create a process architecture for the business, and identify critical processes, those with the greatest sensitivity to financial and strategic goals.  These are the leverage points for investments, where small improvements in process integration create greater value for fundamental stakeholders.

In the next post, I will comment on business value of IT associated to inter-organizational business processes, as well as the implications on IT management.


Tags: , , , , , , , , ,

Comments are closed.