Flexibility In the Modern Organisation (part 2)


(Click here for part 1)

Automated roles and flexibility

If on an abstract level there is not a great difference between the traditional manual process and the modern automated one, why should there be a difference in flexibility? Is it actually the case that effecting organisational change is getting more difficult?

Compare the previous, traditional process with todays, computerised equivalent:

The warehouse delivery process involving the use of a stock control system.

Looking at the ‘Update stock records with loaded goods process’ more closely, we see:

To reiterate and drive the point home, the processes of updating the stock records with loaded goods are in each case fundamentally the same. For the non-technical reader those specifications of the stock level update in ‘pseudo-code’ (a slightly more readable, informal rendition of a computer program) might be hard to understand, but that does not impact the execution of the process because they must only be understood by the computers themselves.

The key difference between the two processes is in the impact on the processes needed to change those processes themselves. In the past, changing processes involved telling people the new rules. Now they involve telling people to tell computers the new rules.

Changing processes where tasks have been automated requires the construction of specifications for software developers. Depending on the specific software development methods employed (and there are many), new tasks for analysts, architects, developers and whoever else needs to be involved need to be created. This becomes increasingly prohibitive. The very act of automation results in a loss of control over the processes themselves. The processes get carried out, allowing high throughput, but they cannot be easily stopped and changed. Not only that, but the areas of the business the processes cover after time become lost and forgotten to the business itself. Over time the IT specialists become the domain experts, but effecting change in the domain is beyond their remit.

Let’s assume that our warehouse only ever stocked items in units. A new requirement to receive liquids into tanks then arrives. Tanks and vats are installed in the warehouse, each with its own label. The tanks and vats are general purpose but it is not permitted for liquids to be mixed, and each container requires a proper cleaning when they become empty or product contents are changed. The process of changing the processes themselves, before automation, might look like this:

1) Plan with warehouse manager for the change.

2) Warehouse manager introduces a new stock ledger called ‘liquid products’, which describes products in terms of containing vat or tank and volume in litres.

3) Test the receipt of stock and reporting from the new ledgers and approve the new ledgers.

4) Update standard procedure documentation, if it exists.

5) Warehouse manager simply adapts his behaviour in response to the change, updating the correct ledgers on receipt of either liquid or unit based goods.

After automation, well the process of introducing such a change can be so elaborate and complex that an entire book could be dedicated to it. The software development processes chosen by an organisation, or in operation in an organisation, involving the various approval processes, coordination with networking infrastructure, liaison with suppliers, datacenter and storage capacity planning, software design, business analysis and so on and so on, can be mind bogglingly complicated.

How the experience of age can make the organisation set in its ways

As changes that focus on growth at the expense of flexibility are made, the organisation gets more rigid. Perhaps this is symptomatic of all aging, living things. However, as the fitness trainer says, it is never too late to start exercising.

Here I look in more detail at how companies age, with the aim of helping to regain some of that lost agility.

Overwhelmed by increasing volumes, frightened by mounting costs, attracted by the need for monitoring and higher information processing capacity, and perhaps motivated to keep technical pace with competitors, organisations rushed to automate and deploy systems. As business objectives emerged, in a keenness to fulfil these objectives, systems were extended, customised and complemented with yet more automated systems.

It has been said that this early phase of rapid growth is a hallmark of youth and eventually a successful organisation is bound to reach equilibrium where it can no longer expand organically, its internal complexity reaching the limits for its earning potential. While this may characterise the evolution of many companies, it is somewhat defeatist in that it makes no attempt to find an underlying mechanism of that organisational aging process in an attempt to resist it.

Indeed, rapid growth with unmanaged increase in complexity can lead to confusion and quality reduction at any stage in a company’s history. This is clearly illustrated in the recent example of Toyota’s overemphasis on expansion, followed by the unfortunate recall of several million vehicles.

Viewing the organisation as a set of processes, involving activities assigned to roles, we have seen that change itself often leads to decreasing ability to effect further change, primarily because the detailed process of effecting change is not itself included in the process model under change, or is just ignored. In other words, change is made without really understanding the consequences. Standard techniques like the “gap analysis” show you the difference between the now and the expected, but do not include future gap analyses, or the ease and effectiveness of future gap analyses, as a subject of change. Immediate savings or growth opportunities from automating or ‘improving’ something can be perceived with some clarity, but the cost of future changes to the deployed result is uncertain and often simply ignored.

The consequences of ignoring the impact on detailed change processes are manifold:

Automating an area introduces communication barriers
As soon as something is removed from a department to the world of software then change to that process now involves at least two departments instead of one.
For example, when the process of updating the record of stocks was done manually and managed by a single department, it was not too difficult to add a new attribute to the stock books describing some new feature should it have been required. If it would have become necessary to make records of when shelves were last cleaned in the stock control books, it could have been managed by the employees responsible for the stock room or warehouse themselves. Once it is automated, it is no longer trivial to make procedural changes. Changes to the stock processes now involve a more elaborate software development process.
This software development procedure involves a prohibitive communication overhead such that small changes are often simply abandoned.
Another consequence is that the details of the processes become lost to the business. Those who really ought to know about how, when and why the stock levels are recorded often only do so for a duration of time around about the time the software is being designed and deployed. As months and years go by, people leave, software changes, and the precise mechanisms might become forgotten. Although not frequent, it is common across companies to see investments in system rediscovery, essentially re-learning how their business really works.

Automating an area can cause dependencies on specialised technical knowledge

Now that the warehouse information process has been automated, the company is now the proud owner of “Commercial Third Party System X.” Although “System X” met ninety five percent of functional requirements out of the box, it required some customisation by one or more external consultants. The external consultancy was selected on the basis of competency and likelihood that they would as a company remain around for the next five or ten years. It is now not possible to make changes to the system or its integration with other systems without involving these consultants. Also there is Mr. Woodworm, an in-house technician with knowledge of “System X,” who is the last remaining employee in the company who understands key areas of the installation.
This is a typical scenario for many companies. It has become the norm to perceive line of business systems as fragile, indispensible and critical, while those who keep these systems propped up are treated in precisely the same way.
Further, as more changes are introduced, the stovepipe system can evolve. Smaller systems are developed to compensate for deficiencies in the larger ones. Processes evolve to simply move data from one system to the next, as for some reason they cannot talk to one another. These in turn require automation. Efforts are made to consolidate things and cut down in complexity (such as attempts at SOA integration), only to discover that half way through the project the budget dries up or the obstacles become insurmountable, leaving a mixture of systems aligned with either the new or the old paradigm. This evolution of complexity results in ever granular domains of specialisation, each with its own experts, and each a stakeholder in any future project for change.
Both internal and external specialists monopolise their knowledge as a job security strategy, and make sure that changes come at a high price.

Costs and risks associated with staff turnover increase

Processes have been changed without regard for the impact on the process of achieving further change. This manifests itself in yet another way: that staff turnover, a type of change that is not always given proper consideration, may require additional costs. This may be because of a need for specialised knowledge, or that the environment has increased in complexity or technicality and requires a steeper learning curve. It may be that the knowledge of how and why things are the way they are is simply no longer there, or so disparate between teams that takes longer to compile and learn it.
I have seen the almost humorous situation of technology being selected for its capability, without regard for the software’s popularity, only to find that after deployment internal staff trained in its upkeep and use actually left the company to set up external consultancies for multiples of their original income. On occasion the consultants sold their services back to the same former employer. Needless to say, change that produces specific solutions to specific problems results in artefacts such as Mr.Woodworm above, who represent their own type of risk and cost in loss of expert knowledge.
Personnel or human resources departments often cannot cope with hiring or firing. In the past, recruitment for a particular field meant finding personable candidates with appropriate education and experience in the business area. Today the business processes are automated and hiring is more about looking for familiarity with software applications and the various techniques required to customise or operate them. HR departments are not usually conversant with the plethora of technologies in use. This encourages them to push the responsibility of hiring and firing onto the relevant managers, washing their hands of it to some extent. However, this is not the main reason.
Prior to computerisation, where those responsible for induction, training, hiring and firing needed most importantly an understanding of the business area, costs associated with candidate performance, and hence HR department performance, were reasonably easy to measure. HR, recruitment, or personnel departments could be held accountable, at least partially, for costs associated with training, learning curves and so on. In contrast, today it is practically unheard of for companies to maintain correlations and studies of learning curve, training, hiring or other HR related costs and the impact on them as a result of technology choices. Today, managers insist they need some rare skill, are prepared to pay through the nose for them, make technology decisions without any involvement of the HR department, and the end result is an apathetic HR team who leaves management to deal with training, hiring and firing, while they become little more than paper-pushers in an organisation that seems to be more dominated by machines than people.

Use of third party systems means more business critical processes are outsourced

The most accessible example of this is perhaps the small online shop. Many today who would like to or already participate in trade of goods and services find themselves in the situation that traditional knowledge of commerce no longer suffices. In the past one learnt about bookkeeping, stock keeping, buying, selling and the laws and lore of their particular business domain. Today it is somewhat different. There are three options for the simple shop owner that wants to sell online: learn to program, hire programmers (external or internal) or use a third party software package with some limited customisability.
Historically businesses have always been dependent on third parties for provision of infrastructure, but the actual orchestration of internal operations was very often the responsibility of the business’s key decision makers. Today however it seems that more and more are willing to let software run their business. Online marketing, ordering, accounting, stock keeping, bookkeeping, tax calculation and more, can all be done by machines. Simply purchase the system, host it somewhere, add liberal sprinklings of creative design and personal connections, then spend the next few years running around at the behest of the system making sure that the physical order and delivery processes keep up with what the system demands.
When a change becomes necessary, such as adding an entirely new product category, suddenly the business “owner,” must either become an adept programmer and web designer, manage programmers, or pay through the nose for application customisations. I can clearly imagine the multitude of modern-day shopkeepers lamenting these very same problems and I wonder why there is not more of a backlash against the hijacking of their profession.
In larger corporations the same kind of difficulty applies. Entire sections of critical business processes become effectively owned by a third party supplier. In my experience the costs of internally developed systems versus externally supplied and customised systems often vary wildly from expectation. Sometimes companies invest so much into a system, only to discover that it lacks the customisability they need, that the entire business folds. Sometimes huge systems that would take years to develop by huge teams can be substituted by smarter systems developed in house at orders of magnitudes cost reductions (and vice versa). The main problem with outsourcing business processes, particularly by purchasing applications, is that they meet a need, but flexibility in those areas becomes minimal. Further, these systems can become quickly obsolete and/or require frequent upgrades.

Technical solutions to problems of organisational complexity miss the point

To reiterate: the business is a set of processes; businesses change and adapt through processes for change; the business is a set of processes including those processes of realising change. A change to the business results in a change to those processes for change – a change to the business means a change to how it can change. As changes occur, how flexible or how rigid the organisation becomes is determined by the impact on those processes for change. In order to maintain flexibility, the impact on change management and realisation processes must be considered.
The problem is methodological and cultural. Business processes must first be recognised as real artefacts, identified, described and maintained. They must be as descriptive as possible, as opposed to prescribed dogmas, so that the business can be well understood and remain understood. Without this knowledge, there is no governance, only the illusion of governance. Once this knowledge is available, it must be made to include identified processes for effecting change. Any proposed change to the organisation would have an effect on the steps necessary to realise yet further change and so this total impact must be grasped holistically. With the necessary approach and mindset, it should become possible to take control of organisational flexibility, anticipating what changes lead down the path of ossification and age, and which paths can lead away from it.
Consequently, any attempt to address organisational flexibility through technical ideals, such as enterprise SOA integration, homogenised platforms, monolithic packages (including even our online shop software above) and so on, can not come with any guarantee of success because they completely miss the point. These company-wide architectural panaceas are attempts at serving technical solutions to problems of structural complexity, but with no obvious connection to organisational flexibility. The assumption that one must follow from the other is naïve, and without this connection it is difficult to understand why there should be any return on investment at all.
For example, the decisions involved in centralising a system of redundant sub-units and ad-hoc ‘glue layer’ data-flows into a SOA workflow engine do not usually address the costs associated with specialised consultancy in the specific workflow engine; do not calculate the risks involved in centralisation into a hub-and-spoke model; do not properly account for the resistance to be expected from domain fiefdoms and expertise monopolies; and most importantly, they do not address the cultural aspects of the organisation that led to the inflexible solutions in the first place.

Loss of quality

Both cause and effect of rigidity is loss of knowledge about systems and processes. People become tentative and hesitant to make changes, but when they do they cannot effectively test systems. For various reasons the test processes become lax, circumvented, perceived as too costly to maintain. In some companies experiencing growth, it is the necessity for expedience that causes systems to be deployed without retention of testability, and so quality suffers.
A climate of uncertainty is established when quality and testability is secondary. This uncertainty is accompanied by a resistance to change. This resistance to change can also often result in ‘patches’ and supplementary systems, put in place out of fear of upgrading or replacing the original, resulting in an increasingly complex and less understood stovepipe of an organisation.
De-emphasis of quality results in failure, and organisational rigidity results in poor quality. For some it may seem counterintuitive that stringent Quality Assurance could result in flexibility. That very emphasis was the key ingredient in the rise of Japanese manufacturing processes:
Ford Motor Company was simultaneously manufacturing a car model with transmissions made in Japan and the United States. Soon after the car model was on the market, Ford customers were requesting the model with Japanese transmission over the USA-made transmission, and they were willing to wait for the Japanese model. As both transmissions were made to the same specifications, Ford engineers could not understand the customer preference for the model with Japanese transmission. Finally, Ford engineers decided to take apart the two different transmissions. The American-made car parts were all within specified tolerance levels. On the other hand, the Japanese car parts had much closer tolerances than the USA-made parts – e.g., if a part were supposed to be one foot long, plus or minus 1/8 of an inch – then the Japanese parts were within 1/16 of an inch. This made the Japanese cars run more smoothly and customers experienced fewer problems.”

The worst organisation in the world

Here I present a fictional case study of a large organisation, demonstrating all the problems of rigidity identified above. This also serves as a summary of the problems I have identified to be addressed in solutions presented later.

For the sake of familiarity, let our stricken company be a shop. So that the example is non trivial, it has a central, shared warehouse, some branches around town, and each branch has its own small warehouse. All ordering for replenishment of the central warehouse is done from a central department at HQ, and all local ordering is placed on the central warehouse. The shop currently sells a narrow range of products from a small selection of suppliers. All sales are brick and mortar. No online ordering is supported.

Up until recently the branch cash tills generated a spreadsheet of daily sales, which was sent by email as soon as available to HQ for processing. It was decided however that this process could be automated to save some branch staff time. The end result was that the HQ accounts package was integrated with a web service, and custom software was created by in-house technicians to send till data via the web service to the accounts system. The custom software was not completely trivial: there was some cleaning of the data to be done, some recorded sales were not actual sales but goods returns or item cancellations, the till data was expressed in terms of bar codes and had to be matched with a file of product descriptions, and sometimes the data was not available at the expected time and had to be merged with data from the previous day. These are just some of the complications previously handled manually that had to be automated.

Time passed and the technicians who originally wrote that software left the organisation. The software ran with few hiccups, and was usually left alone by newer programmers. If on the rare occasion that something needed changing, it was tentatively patched with little in depth understanding and left to continue sending data to HQ.

Much later, as sales volumes picked up, two things became apparent: the selection of products needed widening, and predictive ability would be improved if the sales data could be available to HQ hourly. Suddenly it was realised that the task of simply identifying what work would be involved in realising this change was complicated. No clear answers were immediately available, and it became obvious that investments would need to be made to discover how the business actually operated. Adding insult to injury, putting the change into effect involved much more than just telling someone what to do. It became clear that an elaborate and expensive set of methods would need to be followed in order to successfully document, change, test and deploy a system that was now critical to the operations of the business.

To the dismay of the business owners, it slowly dawned on them that this kind of piecemeal automation of business tasks had been going on now for some time in various other parts of the business too. It was even discovered that one enthusiastic technician had implemented a simple stock control system to help manage the small stock room at one of the branches, while another store manager with some knowledge of macro programming in spreadsheet programs had created yet another system to do the same thing for another branch. As these hand-crafted solutions migrated to the auspices of the technicians, the knowledge of the business operations slowly drifted away.

In a desperate attempt to regain some semblance of control of the business, the bosses decided that all stock control for the central warehouse and stock rooms would be dealt with using a single third party system. Cutting a long story short, the implementation of this third party stock control system ended up costing much more than anticipated, because of customisations necessary, integrations necessary, and all the reverse engineering that had to be done just to discover what needed replacing at all. This was further complicated by the resistance put up by the technicians who had grown attached to these home-baked systems their jobs depended on.

Pleased with the results, the shop management, after a significant investment of time and money, became the proud owners of a reasonably obscure system that they did not understand, and which their company was dependent on, and cost consultant rates for changes or advice. Granted, they had a system that was ‘configurable,’ but then those who did the configuration were trained experts in that third party system. They take the place of the previous technicians as expertise monopolies. In short, for an illusory sense of control, the management had just overspent and solved nothing.

The HR department is now perplexed. Interviewing for new hires over the last six months has been complicated. Those doing the interviewing no longer understand the skills being advertised. In the past it was simple: you had to have common sense, industry experience, personable approach and knowledge of the basic administrative systems and processes. Suddenly that is all by the by. The processes are automated, the systems are obscure, the skills are technical and it is hard to gauge what kind of soft skills are really needed. More importantly, some staff members with a negative influence are hard to change – they command higher salaries and more important areas of expertise. Further, the learning curves expected are much longer. New hires typically spend three months before even grasping the basics. There are trainings in these new systems that need to be scheduled and completed, and then all the local customisations need to be learnt. Trial periods become longer. The HR department in essence washes its hands of hiring and firing and becomes the paper-pushing team it is today typically recognised as. Nobody in management seems to be officially tracking and correlating costs associated with hiring and retention in relation to technology choices, so HR cannot offer real metrics about itself and becomes somewhat apathetic.

Finally, through inadequacies in understanding of the systems and processes, the approach to introducing change becomes tentative and reticent. This is a self-reinforcing situation because in such circumstances it is difficult to test that changes really work, and it is difficult to see the unintended consequences. This leads to yet further hesitance. Glitches in business operations appear frequently. Quality suffers for both the staff members and the customers.

The company exhibits all of the problems identified in the previous sections. It is now a paralysed entity. At worst, no real long term growth is possible and the only way for it to go is down. At best, it will get lucky, generate sales, and in the long term learn to change somehow.

Small organisations

It no longer makes sense to talk about large and small organisations in terms of numbers of employees. An online shop processing thousands of transactions per day can, in theory, operate with only a handful of employees. However, the uncomplicated business with a small number of staff running their business by word of mouth can be seen as flexible and unburdened by management overhead. This type of company is either a seminal venture or it is a long-established firm that occupies a niche and has peaked in terms of growth. In the former case it can follow only three paths: to become another old niche firm; to collapse for one reason or another; or to undergo the kind of fundamental transformations described earlier in order to allow it to scale.

Basically this type of company must either remain a fixture in a small niche, fold, or reform itself entirely in order to scale. This is not a picture of flexibility.

The best organisation in the world

Here I attempt to present a situation in which every problem of flexibility above has been eliminated. This serves to exemplify possible solutions.

First, let us revisit what went wrong with the ‘worst company in the world:’

  • Automation of consolidating sales data took an understanding of the sales data and consolidation process away from the general staff awareness.
  • The knowledge of the software itself diminished, and so in effect the whole company forgot about how this area really worked.
  • Introducing change to that area became expensive and uncertain, as it always involved rediscovery.
  • Introducing change required complex software systems development processes, which are expensive and risky.
  • Similar automations had gone on unnoticed, with these ad-hoc results being understood and manageable only by a handful of people.
  • Ad-hoc automated solutions drifted to the technicians for supervision, resulting in an overall drain on the knowledge of processes and some repetition of the problems above.
  • The consolidation of ad-hoc systems into third party systems resulted in expensive dependencies on third party suppliers for business critical processes, and increased the costs related to hiring, training and so on.
  • The HR department became apathetic, their responsibilities were diminished, and they were held accountable for cost increases that were not their doing, because management were not correlating technology choices with personnel costs.
  • Lack of system quality and lack of knowledge of those systems resulted in further lack of quality. Internal processes became fragile, the atmosphere at the office worsened and customer service suffered.

Now let us look at the same picture in negative to start to get some idea of the “Best organisation in the world”:

WORST

BEST

Automation of consolidating sales data took an understanding of the sales data and consolidation process away from the general staff awareness.

It was possible to reduce long term headcount and increase transactional throughput by improving the way sales data was consolidated from tills to HQ, while at the same time keeping this process under the supervision of and fresh in the minds of the relevant business staff.

The knowledge of the software itself diminished, and so in effect the whole company forgot about how this area really worked.

The knowledge of the processes was always fresh in the minds of those business line managers responsible for their oversight. The overall picture of the business operations was readily available to anyone who needed to know.

Introducing change to that area became expensive and uncertain, as it always involved rediscovery.

Nothing more than trivial rediscovery was ever needed to implement any kind of procedural or structural change.

Introducing change required complex software systems development processes, which are expensive and risky.

Introducing change involved lightweight processes that minimised costs.

Similar automations had gone on unnoticed, with these ad-hoc results being understood and manageable only by a handful of people.

Either processes were entirely maintainable by anyone with knowledge of the business area, or the process was not automated.

Ad-hoc automated solutions drifted to the technicians for supervision, resulting in an overall drain on the knowledge of processes and some repetition of the problems above.

While technicians may have remained involved, at least for infrastructure, no knowledge of processes was lost from the business.

The consolidation of ad-hoc systems into third party systems resulted in expensive dependencies on third party suppliers for business critical processes, and increased the costs related to hiring, training and so on.

All systems purchased had to meet the criteria of being well understood, popular platforms.

The HR department became apathetic, their responsibilities were diminished, and they were held accountable for cost increases that were not their doing, because management were not correlating technology choices with personnel costs.

Any technology choice was carefully monitored for its long term impact on the HR processes, including hiring, firing, training, etc. A scientific approach was adopted to help ascribe costs appropriately, and to help the business learn from its decisions. The HR department was made a stakeholder in key technology decisions, and was asked for estimates in any technology purchasing decision concerning long term costs.

Lack of system quality and lack of knowledge of those systems resulted in further lack of quality. Internal processes became fragile, the atmosphere at the office worsened and customer service suffered.

Change processes always involved necessary testing processes. Processes were transparent, which helped towards a culture of flexibility.

Each one of these possibilities in the ‘Best’ column raises the question, “How?” I will now address each item and present a general answer, and it will become apparent where these solutions are heading.

It was possible to reduce long term headcount and increase transactional throughput by improving the way sales data was consolidated from tills to HQ, while at the same time keeping this process under the supervision of and fresh in the minds of the relevant business staff.

How? The business processes automated and coordinated by machines must be clearly readable and understandable by business process participants and their execution must be clearly visible, just as it was before automation.

The knowledge of the processes was always fresh in the minds of those business line managers responsible for their oversight. The overall picture of the business operations was readily available to anyone who needed to know.

How? The business processes automated and coordinated by machines must be clearly readable and understandable by managers. They must be able to change the automated processes themselves. When processes are changed, the changes must remain clearly readable and understandable by process participants.

Nothing more than trivial rediscovery was ever needed to implement any kind of procedural or structural change.

How? The business processes automated and coordinated by machines must be clearly readable and understandable.

Introducing change involved lightweight processes that minimised costs.

How? Minimisation of costs means understanding what all the costs would be, for each possible change or outcome of change. This is infeasible. What is necessary is to be able to test the impact of change easily, to permit some freedom to experiment. The processes should be clearly readable, understandable, as above, and changes to them should be as simple as directly altering them, just as prior to automation, but testing is necessary because there will always be unforeseen consequences. Testing should always be part of the change process, making the change process itself more bulky, but reducing the overall cost and cultivating an atmosphere of safety and freedom to play.

Either processes were entirely maintainable by anyone with knowledge of the business area, or the process was not automated.

How? First, the incentive structures need to be such that people always incorporate company wide flexibility into their decision making. When someone decides to create a spreadsheet macro to save time on a daily task, if most of the rest of the organisation is not familiar with spreadsheet macros then they should be aware of the cost to the company of their action, rather than the personal benefit to themselves. The next response is in the same vein as above: any automated business process must be clearly readable, understandable and changeable by all relevant parties.

While technicians may have remained involved, at least for infrastructure, no knowledge of processes was lost from the business.

How? The business processes must be clearly readable and understandable by all relevant parties, including those managing the data storage and transmission facilities. Introducing changes to processes that are clearly readable by everyone might be fine, unless the volumes of data simply exceed the capabilities of the network and databases. Planning for changes needs quick assessments by those who manage IT infrastructure. Indeed, IT infrastructure would have its own internal processes subject to the same requirements.

All systems purchased had to meet the criteria of being well understood, popular platforms.

How? The platform must be very popular with an abundance of open documentation, like Windows or Unix for example. The processes automated on these platforms must be readable and understandable by everyone relevant, without creating dependencies on third party suppliers or internal knowledge monopolies.

Any technology choice was carefully monitored for its long term impact on the HR processes, including hiring, firing, training, etc. A scientific approach was adopted to help ascribe costs appropriately, and to help the business learn from its decisions. The HR department was made a stakeholder in key technology decisions, and was asked for estimates in any technology purchasing decision concerning long term costs.

How? The comment is self explanatory, but it I feel it is important to emphasise this point: most businesses simply do not understand the personnel related costs that automation or technology choices have had on them. Most executives fail miserably to put these two aspects of the business together, and the end result is poor decision making. It is all too common to hear of ROI for an IT choice or ‘strategic technology investment,’ and yet even more common to see a business fold, a department close or an IT project fail for the simple reason that organisations do not and cannot understand the actual cost.

Change processes always involved necessary testing processes. Processes were transparent, which helped towards a culture of flexibility.

This is covered above.

Conclusions

All the above can be summarised:

  • Flexibility is strength and health, the broad ability to respond to changes and adapt, to withstand shocks and survive.
  • Automation of business processes permitted a continuation of organisational growth by allowing increases in transactional throughput.
  • Automation of business processes has resulted in a separation between the business domains and specialised technical domains, where knowledge critical to the decision making of both lies across a difficult division.
  • Any organisation can be described purely in terms of business processes.
  • Business processes have not dramatically changed. What has changed in response to automation is the roles assigned to the execution of tasks are increasingly machines.
  • The main change in response to automation is the process of introducing further change. In response to automation, this increasingly involves the processes found in the acquisition or development of software, and is often poorly executed by organisations whose core skill is not software acquisition and development.
  • Automation of business processes very often has all kinds of unwanted side effects – including causing dependencies on external suppliers, causing expertise monopolies, loss of business knowledge, introducing communication barriers, aggravating the costs and risks in personnel management, baffling and confusing decision makers with technical concerns, degrading quality of service and products.
  • A major issue is that costs cannot be ascribed to personnel or personnel management. Accountability of individuals and consequently HR departments is practically impossible to achieve. HR departments suffer apathy and delegate responsibilities away to departmental managers.
  • Almost all of the above problems are caused by describing processes in ways that only specialists can understand. Process oriented thinkers have been pushed into IT, and processes have been pushed to IT.

If the basic functions of management are staffing, planning, organising, leading and monitoring, then in most cases automation of business processes has helped with monitoring at the expense of all other functions.

Finally, the solution to all these problems is a cultural emphasis and understanding of flexibility and its benefits, coupled with the right technologies that allow processes to be described and prescribed in ways that all can understand.

Such technologies and initiatives are coming into maturity. It is not my aim here to promote specific instances of these, so I will not mention them. The aim is neither to kill the business architects nor the software architects but to kill the distinction between the two. The ‘two cultures’ of business and information technology needs to end, so we can all reap the rewards of a flexible workplace, a flexible supply chain, and a working life that is happier and more creative.

Advertisements

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