The Complexity of Cost (Pt.1): problems with ICT cost reduction Reply

cost reduction

In a crisis the company P&L statement can be a useful starting point for cost reduction programs.  Over the long term, however, general ledger entries do not have the required level of detail to garner the requisite per unit analysis (McKinsey, May 2010).  Unfortunately, few companies do not have systems which can analyse the complexity of cost and spend in order to make accurate and detailed changes.

In the following series of blogs we will highlight the problems with standard ICT cost reduction & management programs and detail how to structure and run one effectively.

The key to an effective ICT cost reduction & management program is detailed cost modelling.  Most financial systems do not capture costs at the right level of detail for businesses to perform accurate and detailed cost reductions.  Businesses need to perform intricate spend analyses and build up intricate cost models for ICT which highlight the following:

  • The capabilities which various ICT components support (and where in the Value Chain they lie).  Only through this level of visibility can the business consolidate their ICT spend.
  • The HR and process dependencies which are indirectly attributed to various ICT elements.  Only with this level of detail can ICT remove duplication and redundancy.

In the absence of this granularity, cost reduction programs invariably fail or fail to stick.  In fact, McKinsey & Co note that 90% of cost reduction programs fail.  Only 10% of these programs actually succeed in realising sustained cost management three years on.

In a typical IT cost reduction cycle the following happens:

  • Headcount is reduced.  The remaining people then have to work harder (but with fewer skills, because tasks are pushed to the lower pay bands) to achieve the same amount of work.
  • Many, often unique, soft skills are also removed (from experienced people in the higher pay bands) in the redundancies.
  • Overall service levels decrease.
  • Further cost reductions are then required and some applications and services are axed.

In simple businesses this is not a problem.  In large and complex businesses the outcome usually follows a vicious cycle, namely:

  1. The firm still needs to retain a significant management overhead in order to deal with complexity.
  2. In these cases, poor transfer pricing and high overhead allocations mean that perfectly good, competitive core business process seem cost-ineffective.
  3. Critically, Kaplan notes in his seminal work “Relevance Lost: The Rise and Fall of Management Accounting” that the increased costs of  processes leads to outsourcing of perfectly good processes.
  4. Capability suffers and the  business loses competitive advantage.
  5.  The business is no longer able to deal with the level of complexity and complexity reaches an inflection point.  The business outsources the whole problem (eg, large ERM programs with much customisation),  getting locked into  horrific terms and conditions.
  6. Core business is lost and competitive advantage is reduced. Remaining managers pad out their budgets with excessive risk and contingency in order to shield themselves from further cost reductions.
  7. Overheads increase again and the business eventually prices itself out of the market.


In a recent (2010) Accenture survey on general cost reduction effectiveness in the banking industry, 40% of  respondents noted that the program has reduced overall ICT effectiveness and impacted adversely on both customer service and general management.

in order to reduce costs effectively without impinging on capability as well as making new costs stick, it is essential to view costs and spend at the most granular level possible.

In our next blogs we will go into detail how to structure and run an effective ICT cost reduction and cost management program including effective ICT cost modelling.


The Social Enterprise: what will business 2.0 look like? Reply


If Andrew McAfee‘s book “Enterprise 2.0: New Collaborative Tools for your Organization’s Toughest Challenges” is to be believed then:

“We are on the cusp of a management revolution that is likely to be as profound and unsettling as the one that gave birth to the modern industrial age. Driven by the emergence of powerful new collaborative technologies, this transformation will radically reshape the nature of work, the boundaries of the enterprise, and the responsibilities of business leaders.”

Most pundits believe that Enterprise 2.0 is the full adoption of Web 2.o by an organisation.  In the next few years, therefore, we will see:

  • Cloud technologies and better enterprise application security enable bring-your-own-device and with it the greater fragmentation of organisational information.
  • Greater transparency of organisational work through social media leaks (i.e. people advertising their work and mistakes on the internet)
  • The decomposition of many more business processes into micro-tasks (much of which can be outsourced or contracted out).
  • The improvement of distributed working practices enabled by better collaboration tools, devices and connectivity.
  • Increased pace of business through improved self-governance and, in turn, empowered by better oversight (from GRC and finance software to more pervasive CRM implementations).
  • Shorter time-to-market cycles driven by improved idea generation and organisational creativity (so called – ‘ideation’).

So, is Enterprise 2.0 the social enterprise?  Are the benefits of Enterprise 2.0 merely social?  Simply a more hectic work schedule enabled by greater ease of using mobile devices and tighter communities of practice?

McKinsey Social Enterprise

A 2010 survey by McKinsey & Company found that most executives do believe that this is the sum total of Enterprise 2.0 benefits.  Most simply believe that (i) knowledge flow and management will improve.  Many believe that (ii)  their marketing channels will be greatly improved whilst only a few believe that (iii)  revenue or margins will increase in the networked enterprise.

If this is the dawn of the new enterprise then why do so many large businesses find it difficult even to implement Microsoft SharePoint?

The most likely truth is that this is not the dawn of Enterprise 2.0.  We are probably not on the cusp of a grand new age of information work.  Our businesses are unlikely to change significantly, although the hype will be re-sold by IT vendors for some time. One only has to hearken back to the ’80’s to remember to cries of the ‘paperless office’ to realise the low probability of Enterprise 2.0 materialising.

Whether it will be Enterprise 2.0 is debatable but we are entering the age of  The Social Entreprise.  It has ushered in a new age of commercial culture but it will unlikely herald a paradigm shift in commercial structures.  The truth is that human networks and communities operate in parallel to corporate reality.  Networks are how humans interact  – they are not how humans are paid.  Ask anyone who has ever been through or performed a cost reduction exercise.  In short, emerging social software platforms (ESSPs) are fun and sexy but the do not currently affect operations in most businesses.  Emerging social software platforms will make a difference internally when they affect cost structures and not just when they show up in sales figures.  This means that ESSPs need to be able to track and apportion innovation; they need to actively manage workflow (not just passive engines); they need to engage dynamically in governance and highlight good corporate participation and collaboration.   Only once these elements are incorporated into scales of remuneration and talent sourcing will both the enterprise and the workers benefit.

Maybe then we can move to Enterprise 3.0.

Enterprise Architecture:why EA programs fail to deliver Reply

Enterprise architecture has long promised the alignment of the technical ICT of the organisation with its business strategy.  For the same length of time it has steadfastly failed to deliver this.  In order for enterprise architecture to (a) deliver alignment, and (b) execute strategy it must incorporate commercial concepts within the metamodel so that it may directly use both financial analysis as well as legal parameters.

Enterprise architecture has never been solely about infrastructure.  Enterprise capacity can easily be catered for in data centre management.  Enterprise architecture has been largely focused on enterprise applications integration.  Integrating data models and their schema across the distributed enterprise to create harmonious workflows for the fewest people promises to realise the goal of reducing labour whilst purchasing the cheapest software.  Enterprise architecture should be about driving the development of ICT architectures and business process directly from the value chain.

Enterprise architecture still provides businesses and departments with the greatest hope for the harmonious analysis and development of the enterprise.  It fails largely, however, for the following reasons:

  1. Complexity of Metamodel.  Financial language is not generally incorporated in the language of metamodels.  It is possible but not generally done.  When I was at EDS Value Management was an architectural discipline within the Agile RightStep® architectural framework.  Whilst at Serco a number of us tried to incorporate value against the various objects in architectural models withing the MEGA® modelling suite.  However, in order to take advantage of financials modelling tools would need to incorporate stochastic simulations and not just discrete event simulation into their analytical capabilities.  This explains the disparity, often large, between architectural models and financial models.
  2. Systems Engineering.  EA still remains largely focused on enterprise systems engineering.  It needs to shift its focus to enterprise engineering systems.  Where the former focuses on the minutiae of systems interaction the latter is concerned with the integration of one engineering system to another.  If the enterprise sees the financial function as an engineering system then enterprise architects should be able to use their ontological skills in metamodelling to create seamless pull-through of analysis from Finance to Design.  Some of these concepts will be explored in a later blog.
  3. Complexity of Programs.  EA still remains an ICT skill used to support large programs.  In order to capture enterprise relevance it needs to elevate itself from the technically complicated to the organisationally complex.  Given that information systems largely exist to reduce organisational entropy, one of EA’s greatest benefits will be to realise the harmonisation of working practices and not merely implementing monolithic technology.
  4. Lack of Financial Relevance.  EA needs to support value management and not just technology management.  This is as much a problem of program selection as it is the extension of the metamodel.  Automating the Balanced Scorecard  still remains one of the best initial EA programs there is.  It is relevant to both the C-suite as well as providing a direct and tangible impact on the measurement of strategy execution and financial management.

The answer, therefore, is to focus on capabilities and not on architectures.    The former delivers measurable commercial value but the latter will consume the enterprise in a needless pursuit of perfection.  In our next blog we will examine how to architect capability directly from the value chain.

How will enterprise Architecture Reduce Legal Costs? Reply

In mid 2009 I received an e-mail from Mark Hurd, then CEO of Hewlett Packard.  This wasn’t unusual because I was at EDS UK and we all got an e-mail from our new CEO.  He wanted to explain that over and above the 26,000 people he was already getting rid of in the new enterprise there would be further reductions.


He went on to write that earnings were down 20% so his investors wanted to know when he was getting rid of another 20% of his workforce.  He went on to add that he was resisting their advice as it would hurt us on the rebound.

Clever Mark.

The point of the story is how one determines, precisely and effectively, what are the right parts of your cost structures are the ones to get rid of?  Typical commercial reasoning suggests that the best cost structures to cut are: headcounts, marketing, training, procurement and travel.  These are the easiest but you don’t have to be Lou Gerstner to realise that you shouldn’t cut marketing or travel in a downturn.  Pick up any edition of HBR and you’ll know that you need to focus on core business and cut the rest.

So how do we find core business and what on earth does it have to do with my legal costs?

Have you ever done a push-up?  What muscles do you think are used? Chest? Yep. Triceps? Oh yeah.  What about anterior deltoid? What about the supraspinatus or the infraspinatus or the teres minor? What about the teres major and the suprascapularis? These are all synergistic muscles in the push up that help hold your shoulder girdle stable and stop you toppling over to one side.  Likewise with business.  There are an enormous number of synergistic activities which assist core processes.

Don’t worry we’re getting to the bit about legal costs.

Your core business will be the fundamental raison d’être of your company.  For instance.  You might think that you own a network outsourcing company but when you ask yourself why your company really exists and what it seeks to really achieve, you might find the answer being that it transforms the customer relations of client companies? Now you need to determine what are all the essential processes which support transformation (which we’ll look at another time)After that one must discover the dependent, people, information, systems and infrastructure for these processes.

That’s the easy bit.

Now you need to architect it into some form of commercial reality and make it happen.  Once this beautiful strategy is executed in a new and improved operating model you will be left with a pile of paper which enshrines the agreements you have made with partners to make this reality.  Contracts – and they don’t come cheap.

Did you notice a theme?  I talked thereabove about the seamless architectural process which blends to bring synergy to the design and form of your new business.  The realistic amongst us will know there is always a great crash as the momentum behind any deal brings it into contact with the immovable object of the law.  The beautiful deal we created is then mangled through lawyers until what we wanted is barely recognisable.

What if this horrid legal process was an integrated part of the architectural process?  What if our business architects, our technicians and deal-makers were all joined in a common, collaborative architectural process which derived legal clauses directly from the technical and commercial detail of the deal?  Wouldn’t the contract then become a dynamic and fluid document which formed part of the management of the program?  Wouldn’t the contract(s) be lean, precise and swift to negotiate and put in play?

Welcome to Citadel, where enterprise architecture meets the law.

Strategies for Increasing Return-on-Information Reply

The key to gaining more financial return from corporate IT systems is to increase the value added by management.

Technology which is implemented by profit centres and is specifically designed to support operational, revenue raising workflows (such as in the financial services or insurance sectors) may be measured through standard Net Present Value calculations.  If it directly increases cash flow then there is little problem in measuring its value.

In corporate systems which are generally considered ‘overhead’ it is much harder to assess whether a system has been worthwhile let alone profitable.  How does a business assess the value of the company portal?  How do they assess the value of information management systems?  In most of these instances the business case for a new portal can simply be justified on the basis of (a) better user interface (often classed as the ‘user experience), (b) need to upgrade the current application, and (c) need for greater compliance.  A cost analysis does not need to be run because the business needs some sort of portal and is not going to get rid of it, so the point is moot.

This is an appalling way to buy large corporate IT.  Companies which purchase systems without rigorous cost analysis and a commitment to longer term cost reduction may reduce the lifetime costs for the simple capital purchase but massively increase the overall cost of IT throughout the enterprise in 3 ways:

  1. Increased Support Costs.  The cost of support, training and change per user is colossal for corporate IT systems.  Not only are support staff expensive but management increases to control support staff and management costs are infinitely more expensive and harder to control.  With non-transactional systems such as portals and information management systems, management’s variable expenses also increase as the business tries to make the system work and fit into the business.  In such circumstances, CFOs should monitor variable expenses in cost centres as such costs would not have appeared in the cost model for the initial business case.
  2. Increased Transactional Costs.  Corporate transactions (the train of workflow) increases the further away information is from the customer.  Portals and information/knowledge management systems are about as far away from customers as information can get.  With each ‘transaction’ comes increased ‘setup’ costs as information is passed from management to management.  Imagine, as a customer request is passed from the service centre to management it gets closer to a portal system and passes into almost a corporate black-hole as management attempts to find answers to questions which loop endlessly.  Uncontrolled corporate workflow which increases transactions not only has the ability to increase management costs but it also has the ability to increase management.  Management needs to ensure that transactional costs are minimised by keeping workflows as close to customers as possible.  This is enabled by empowering service representatives to resolve customer disputes and queries themselves.  Management should, ideally, not seek to micromanage but rather train well and guide through detailed, flexible policy.
  3. Increased Vertical Integration.  With the complexity of modern systems, businesses have a propensity to duplicate roles or application functionality from shared service centres.  Companies can reduce vertical integration by (i) ensuring that non-operational workflows are stripped out of profit centres, and (ii) cost centres have a lower management-to-capital ratio.  Surveys have shown that companies can spend less than 10% on ICT budgets whilst still delivering 2% better productivity results.

Information is an incredibly valuable commercial asset.  In many cases, companies hold vast reserves of ‘intellectual capital’ which can be commercialised and valued with a modicum of effort.  In fact, companies should seek to understand the value of their information by constantly assessing the viability of divesting discrete parts of the business (for more on the value of an M&A approach,  follow this link).  Unfortunately, most businesses burn most of the value of their information through clumsy and blanket approaches to managing it.  By purchasing systems which can be directly associated with higher transactional workflow and reduced variable management costs the return-on-information is vastly increased.

Develop Capability Not Architecture: the next frontier in ICT delivery Reply

In our previous blogs we outlined the key problems facing enterprise architecture, namely:  (a) overwhelming complexity, (b) poor integration of concepts, (c) lack of financial relevance, and (d) poor program choice.  The real problem with enterprise architecture is, however, architecture.  Rather it is the focus on architecture, equipment, kit or stuff which is the real problem.  Engineers do what engineers like to do best – build things.  Yet, in focusing on structures enterprises fail to take heed of the things that matter financially – functions.

In order to deliver benefit and value enterprise architecture must create a language whereby the ‘objects’ of financial analysis may be moved directly to the design community within a single model.  This may be as simple as the numbers on a spreadsheet or as complex as objects within a UML model.

One solution is through capability.  Capability provides us with the means to bridge the gap between the design structures of an organisation/enterprise and its functions – the primary functional model being the value chain.

The first level of decomposition from the value chain is the set of Value Activities (Porter provides no further guidance on decomposition and cost allocation).  A value activity is the key to differentiation, i.e. by arranging value activities in a unique way companies achieve a competitive advantage through differentiation of their value chains.  The specification of a value activity, however, is a capability.

Capability is already accounted for within defence architectural frameworks such as MoDAF and is defined as “the specification of an enterprise’s ability to do something.” Capability is the sum total of all people (roles), processes, systems and infrastructure necessary to perform a function.

Companies and government departments/agencies have many capabilities but all of them should be described at the same level (i.e. primary capabilities) and seen as the instantiation of value activities.  Otherwise, the term capability may inspire higgledy-piggledy capability and sub-capability definition.  It is our experience that deriving them directly from value activities is the easiest and most efficient means of capability definition.

Once performed, capability definition may be visualised similar to Figure 1.  Capabilities stretch over many functions and may not necessarily include all in between.  Moreover, once performed, capabilities mustbe checked against financial cost allocation to ensure that they match.  There is little point coming up with an ontologically correct definition of an operational asset if the finance department have assigned its costs elsewhere.  Given that the primary means of a capability model is for the efficient investment of capital it is best that the work is performed in conjunction with the CFO’s office.

Capabilities are powerful concepts yet poorly understood and implemented worse.  Capabilities have the ability to empower enterprise architecture and finally make it commercially relevant.

Enterprise architecture will fail to gain any traction within the corporate environment so long as it cannot achieve a meaningful link between finance and ICT.  When it does, enterprise architecture will hold the key to dealing with commercial complexity and organisational entropy.

Top 4 Ways to Assess the Viability of a Deal Reply

Does a deal have architecture?

The simple answer is:  Yes.  If a deal is to be viewed holistically with a view to assessment or organically with a view to development then it must have architecture.   More importantly, if a deal is to be assessed then some form of structure must be found.

Stop focusing on the system

Therefore, focus on the revenue model NOT the architecture.  The architecture is absolutely vital but the fact that you’re going to deliver a fantastic, value-adding system is a given.  It’s the reason you were invited to tender. Stop patting yourself on the back for being so good at your core business and now focus on how you’re going to make money out of it.  Critically, how you are going to sell transformation to the client?  Why should they buy into a target-architecture plan and why is it going to take so long to transform their business?

The first dimension of a deal, therefore, is “throughput”:  the ability for the deal to be able to process business and create revenue.  More importantly, it is possible to have a fantastic system and not make money (just ask Fujitsu ref their NHS UK deal).

The key to answering these questions is in assessing the 12 key variables of system viability.  Here at Precision we adapted them from Jamshid Gharajedaghi’s system dimensions and variables in his seminal work “Systems Thinking” (Butterworth-Heinemann, 2006).

1.   Capacity.  Can the system cope with the expected demand and use? This is purely structural question:  are the “pipes” big enough?  More importantly, is the architecture able to expand and contract cost effectively  to accommodate demand?  Do the ‘joins’ and ‘bends’  suffer from fragility?  Are the components ubiquitous enough?  Scalable business models seem great but the architecture to empower them is more complex.

2.   Performance.  Will the system outputs always be of the highest quality? Many longer term outsourcing contracts are 5+5 years so this addresses whether the system will function as designed, well into the future.

3.   Access & Demand.  Are your assumptions of access to markets and customer demand correct?  As the deal progresses will the business be able to expand and take advantage of peripheral value chains?  Will it be able to turn cost centres into profit centres once they are mature? Can the business protect its intellectual property as it becomes more valuable?

4.  Throughput Capability.  Does your organisation have the know-how to keep developing the capability at the optimal rate?  Does your business have the information management skills to be able to develop the knowledge to retain a very high capability?  Take BP, for example, they outsource most things but their information productivity remains very high.  They are still able to access the knowledge needed to develop their core capabilities.  Many companies, however, outsource but cannot take advantage of the better employee-to-revenue ratio.

In summ, a deal is far more than the technical architecture, products or physical structures on which it is built.  Focusing on these 4 key elements of a revenue model well into the future will give the business a realistic view of a deal’s viability.

CONTRACT ACCOUNTING: Squeezing more profit out of in-flight accounts Reply

Most large accounts suffer from the same problem:  The variation between the crazy thing a business promised the customer and the ability to deliver it within profit margins.  In the multi-divisional organisation most departments and teams understand this.  Most senior executives understand the need to win bids versus the need to keep their jobs through sensible estimation and know it is a fine line to tread.

In many cases, the solution to this problem is often not better cost and schedule estimation.  In one global outsourcing company some accounts were run as loss-leaders (although this wasn’t the actual intention).  Had the business actually estimated the cost and schedule properly they would never have been able to deliver the solution with the requisite profit margin.  With this knowledge these projects would have been No-Bids.  Large companies need to build brand equity in various solution sectors (in this case, local government ICT outsourcing).  They can afford to break into the market at a loss and then create profitable new accounts through economies of scale.

There is another solution for larger, multi-divisional accounts.  The architecture of such agreements often aggregates risk premiums.  For instance, each team, unable to account precisely for the value of risk creates a risk ‘slush fund’ within their team’s section of the overall cost model.  In total, the final risk premium may be significant (and even price a business out of a bid).

The solution is a 4-step (4Rs) process:

  1. Re-Model.  First of all, the entire contract needs to be modelled as a single architecture.  Creating a single parametric model can be done in one of two ways.  Firstly, the firm can use the same quantitative factors (here we use financial data) across the model.  The firm may prefer to use quantitative factors multiplied by qualitative coefficients (e.g. the Defense sector).  In this case it is best to use existing models which are statistically correct, such as COSYSMO or COSYSMOR.
  2. Re-Package.  Risk needs to be re-packaged and sold to those who are most capable of dealing with it should it be realised.  This means creating an internal hedge market within the capability community to buys and sell risk.  There is a critical lesson to learn from the current crisis: (a) The financial markets are the most mature in their approach and maturity towards risk, but (b) risk needs to be dealt with operationally.  The lesson is clear.  Financial incentives provide the only means to truly motivate businesses to deal with risk but when it comes to actually performing those contingent actions there must be a realistic plan to do it.  Most risk plans are farcical and do not take into account office politics, organisational structures, technical difficulty, information for decision making and compressed time frames.  So, when selling risk ensure that the buyer has an adequate contingency plan to deal with the risk and is not just paying the highest price.
  3. Reduce.  Once these contingencies have been identified and the risks re-packaged the cost of the overall solution should be significantly lower.  If the risk contingencies are not significant then the main cost reduction should be in insurances to cover indemnities, warranties and general liabilities.
  4. Re-Negotiate.  Once the technical detail is calculated the hardest part is realising the gains.  In order to realise financial gains in an in-flight account the contract, or sections thereof, will most likely need to be renegotiated.  Lawyers are loathe to renegotiate contracts.  Despite the additional fee-earning capacity there are two institutional problems, namely:  (a) it may be seen as an admission of defeat that the initial contract is unsatisfactory, and (b) lawyers do not generally understand the financial maths behind the individual risks in the contract architecture.  However, the best way to renegotiate certain clauses is to (i) got through the sales/operational side of the customer’s business, and (ii) offer them money.  For instance, if the business stands to make 3% on its current margin then it could easily offer 0.25% to cover the legal fees of renegotiation or as a good faith payment.  It will, however, be critical to renegotiate the content with the operational/architectural teams as most lawyers only deal in absolutes (i.e. no liability or uncapped liability).

The difficulty with most accounts is seeing them holistically as an integrated architecture.  Most large deals are seen as separate pieces of a larger jigsaw puzzle.  Instead, it is advantageous to see the deal as a single system; all parts operating synergistically.  Modelling the system parametrically fulfils this goal.  Modelling it within financial parameters, in the manner shown above, empowers all departments and teams to work together to create high-performing accounts.

Cloud Computing: The answer or another problem? Reply

Cloud computing has been hailed as the answer to a company’s ICT needs.  In brief, the financial benefits are:

  1. Reduced cost of infrastructure, and
  2. reduced labour.

Fulfilling The Dream

At first glance this is brilliant.  By taking advantage of someone else’s expertise and economies of scale a company has the ability to reduce their infrastructure costs significantly.  Not only do they pay less for the same equipment, they pay less for maintenance and also regain valuable office space.  Now, potentially, a firm can actually capitalise on the age-old promise of ICT by not only substituting technology for labour but actually reducing both.

So What Is The Problem?

The problem is that cloud services can require higher integration costs and longer setup times between transactions.  Although the answer is better data integration between applications to improve workflow, I don’t see open source code changing this situation any time soon.  Firms will still need programmers or technical integration specialists to assist.  One only need look at the plethora of Microsoft specialists to see that integration is a bourgeoning cloud industry.

SaaS is rigid by its very nature.  For reduced cost it offers certain parameters on integration.  ERP solutions where integration costs can be astronomical are a testament to this.  The increased costs don’t just stop with integration, however.  Transactional costs (which cannot be attributed to the cost of good sold) also increase as setup times between workflow tasks rise.  The management burden is also greater as additional decision making is required to make sense of isolated data (this may come in the form of downstream consulting or upstream meetings etc). Companies which are unable to take advantage of service/platform/infra outsourcing will notice an overall increase in both their overhead costs and total employment of information workers.  This will not happen in the ICT cost centre where the costs will largely decline.  However, it is likely that ICT will largely pass on a greater and more expensive problem to the business.

The solution is not greater vertical integration of shared services.  It may reduce the overhead in the short term but in the long term the increase in the cost of goods sold will price products out of the market.  One part of the solution is a greater focus on data for decision making through the expert use of case workers (information workers covering multiple transactions).

A key factor is that along with outsourcing our platforms we also outsource our decision making/support.  Don’t forget to retain the information management function and your company won’t succumb to the siren song of cloud applications.

Big Data is Big Nonsense 3


Big Data is the next big solution looking for a problem.  Faced with falling revenues from lower ICT spends and clients with reduced consulting budgets Big ICT looks to Big Data for Big Revenue.  Customers will be left as Big losers if they fall for this parlour trick.


The central premise of Big Data is thisCompanies, organisations and government can spend a lot of money cleaning and storing data through traditional means.  This takes a long time and costs a lot of money.  On the other hand, the same bodies can buy a supercomputer and software to crawl over their data and run sophisticated algorithms and come up with the same answer.  The answer will be about 80% correct and based on statistical analysis rather than absolute truths but it’s still a good answer.  Therefore, don’t worry about information management.  Just buy really expensive hardware and get a bunch of clever people to use it and voilà! instant brilliance.


There are 2 problems with the aforementioned premise, namely: (a) Most businesses cannot do small data well, let alone big data.  Secondly, (b) there is no proven link between ICT spend and business productivity.


IT companies would have you believe that businesses are drowning in data.  Well, to continue their analogy, a person can drown in 6 inches of water.  To go even further, an infant can drown in 2.  The point is clear.  If management do not know what they wish to do with the data then no amount of computing power will save them.  In the absence of clear action companies should structure their important information so that it can be stored and found easily.  ERP systems do a good job of this and there are plenty of EDRM systems which are convergent.  More sophisticated users need more sophisticated solutions and this is where Big Data can assist.  More importantly, with the capital costs of Big Data solutions it will not be feasible (at least in the short term) to use it on standard management information.  Big Data solutions will only be cost effective for advanced business intelligence-type analyses.  If a business is looking for mainstream solutions to support business intelligence it will need to look for the more mundane.


Secondly, the link between ICT spend and business productivity is not made out for any other sector other than Financial Services & Insurance (FS&I).  This sector is now so heavily automated in its business processes that there is a clear dependency between IT and profitability.


For the rest of industry and government nothing much has changed since Strassmann’s work in the mid-90’s (see below).  This is to say that there is no point buying ICT to automate a bad process.  Expensive IT will not help poor management.  This is why banks, Tier-1 consultancies and advanced process oriented firms (such as GE) will likely be the only beneficiaries from Big Data.


Big Data is somewhat of a misnomer because it is not like standard ICT spend.  The Big Data will almost inevitably be run in conjunction with technical services because part of the benefit is determining veracity through market sentiment.  For instance, if an investment bank is trying to determine the initial share price for an IPO they would like to run trend analysis on similar companies but also see how this fares against potential investor sentiment.  Big Data used in this way is certainly a unique offering if not a competitive advantage for smaller companies.


Big Data is not a game-changer.  As computing power and processing speed increase (according to Moore’s Law), along with ubiquity, then the benefits and services of Big Data will become mainstream.  In the meantime, however, Big Data will be a competitive advantage for many of the smaller and 2nd Tier businesses.