ALIGNMENT: Building a Closer Relationship Between Business and IT Reply

alignment. team workjpgThe business gurus Kaplan and Norton describe “Alignment” as a state where all the units of an organisational structure are brought to bear to execute corporate strategy in unison.  When Alignment is executed well it is a huge source of economic value.  When it is executed badly it is a colossal source of friction which can cripple the business.  The authors go on to note:

Alignment

IT DOESN’T NEED ALIGNMENT, IT NEEDS BETTER UNDERSTANDING

IT and the Business speak of alignment in two radically different ways.  The Business talks about alignment between business units.  When speaking of tech they use words and phrases such as ROI and operational performance.  IT talks about alignment in a way that makes them feel as though they matter to the business.  That profitable, customer facing business units could achieve more if the corporate centre where to align business units under a single, cohesive strategy is one thing.  That IT depts fail to execute strategy or even deliver operational effectiveness through poor understanding of requirements, an inability to see the technical reality of commercial value or realise some of the social cohesion which enterprise software systems need is not mis-alignment – it is just bad practice.

THE RELATIONSHIP BETWEEN THE BUSINESS AND ICT IS DIVERGING

The increasing capabilities of a smarter, more mobile , more virtual workforce means a greater commoditisation of knowledge work.  With this comes the polarisation of Business and ICT.   A broader ICT function with a wider array of narrower and deeper areas of expertise will, increasingly, be incapable of coding the more subtle and complex social aspects of human collaborations.  In such a world the ICT agenda must be set by the corporate centre.

mis-alignment

ICT NEEDS TO FOCUS ON EXECUTION NOT ALIGNMENT

ICT’s economic value will be realised when it (and therefore Enterprise Architects) can support business units to reach across each other to create valuable products and services which justify the corporate overhead.  McKinsey & Co, for instance focus heavily on central knowledge management.  This enables research to drive service line improvement in relevant sectors.  IBM spends over 3 Bn GBP on R&D and the development of leading-edge products way beyond their years.  ICT needs to focus on the execution of corporate strategy and not alignment. Alignment is a structural issue whereas execution is a functional issue.  Stop tinkering with the structures and focus on the functions/operations.

GOVERNANCE – ALIGNMENT AT A PRICE

Moves to improve the business relevance of ICT usually result in heavier, more burdensome technical governance.  The finance function imposes capital project controls on technology projects and insists that benefits be quantified.  Although greater cost transparency will bring IT closer to the Business, heavier ICT governance only serves to drive ICT investment underground.  Pet-projects abound, useless apps proliferate and ICT costs continue to rise.  In the meantime, in a perverse inverse relationship, assurance becomes even lighter on larger programs. 

Alignment takes strong leadership and clear definitions of business intent.  A fancy set of IT tools are not necessary for alignment rather they are important when it comes to agilityMis-alignment is the fault of deep rooted cultural divisions which can only be overcome through the strict adherence to financial value and the use of a lingua franca engendered through a common architectural framework.   If ICT is to realise its potential and add real financial value then it must actively support the real-time execution of business operations.

BUSINESS PROCESS FAILURES: the importance of logical architectures Reply

business process risk. chart

In a recent 2012 survey by McKinsey & Co, IT executives noted that their top priorities were ‘improving the effectiveness and efficiency of business processes’.   One of the critical failings of IT, however, is to implement effective and efficient business process architectures in the first place.  The IT priorities to the left only serve to highlight what we already know:  that IT service companies implement processes badly.

Why?

Whether through a failing of Requirements or Integration (or both), IT service companies often implement inappropriate business process architectures and then spend the first 6 to 12 months fixing them.  This is why those companies ask for a 6 month service-credit holiday.  It is also the same reason those companies differentiate between Transition and Transformation.  The former is where they implement their cost model but the latter is where they implement their revenue model.

The failing is not within the design of the technical architecture.  Very few senior executives report that failed projects lacked the technical expertise.  Likewise, project management is usually excellent.  Requirements, too, are not usually the problem with business process implementations as most commercial systems implement standardised Level 1 or 2 business processes very well.

Logical Archtiectures instantiate the subtleties and complexities of social systems which the software must implement

The first failing in the development of a technical architecture to implement a business processes is the design of the Logical Architecture.  Logical Architectures are critical for two reasons: (i) because requirements are one hundred times cheaper to correct during early design phases as opposed to implementation, and (ii) because logical systems are where the social elements of software systems are implemented.  Requirements gathering will naturally throw up a varying range of features, technical requirements, operational dependencies and physical constraints (non-functional requirements) that Solution Architects inevitably miss.  Their focus and value is on sourcing and vendor selection rather than the capture of the subtleties and complexities of human social interactions and the translation of them into architect-able business constructs (that is the role of the Business Analyst).

The second failing is the development of Trade-Space.  This is the ability to make trade-offs between logical designs.  This is the critical stage before freezing the design for the technical architecture.  This is also vital where soft, social systems such as knowledge, decision making and collaboration are a core requirement.  However, trade-space cannot be affected unless there is some form of quantitative analysis.  The usual outcome is to make trade-offs between technical architectures.   Like magpies, executives and designers, by this stage have already chosen their favourite shiny things.  Energy and reputation has already been invested in various solutions, internal politicking has taken place and the final solution almost eschews all assurance and is pushed through the final stages of governance.

With proper development and assessment of trade-space, companies have the ability to instantiate the complex concepts of front and middle office processes.  Until  now, business analysts have hardly been able to articulate the complicated interactions between senior knowledge workers.   These, however, are far more profitable to outsource other than more mechanical clerical work which is already the subject of existing software solutions.  The higher pay bands and longer setup times for senior information work makes executive decision making the next frontier in outsourcing.

Service offerings

Logical architectures are not usually developed because there is no easy, standardised means of assessing them.  Despite the obvious cost effectiveness logical architectures most Business Analysts do not have the skills to design logical architectures and most Technical Architects move straight to solutions. Logical Architectures which are quantitatively measurable and designed within a standardised methodology have the potential to give large technical service and BPO organisations greater profits and faster times-to-market.

The future is already upon us.  BPO and enterprise services are already highly commoditised.  The margins in outsourcing are already decreasing, especially as cloud-based software becomes more capable.  If high cost labour companies (particularly those in based in Western democracies) are to move to more value-added middle and front office process outsourcing then they will need to use logical architecture methodologies to design more sophisticated offerings.

In the next blog we will show one method of quantitatively assessing logical architectures in order to assess trade-space and make good financial decisions around the choices of technical designs.

The Cost of Capability: a better way to calculate IT chargebacks Reply

IT_Profit_Centre

THE VALUE OF SHARED SERVICES

Almost every C-Suite executive will agree that shared services, done well, are a critical factor in moving the business forward.  The problem is that implemented poorly they can potentially overload good processes and profitable service lines with villainous overhead allocations.

IT chargebacks are important because, used well,  they can assist the business with the following:

  • help IT prioritise service delivery to the most profitable business units,
  • help the business understand which IT services are value-adding to the market verticals, and
  • reduce the overall vulnerability of IT-enabled business capability.

OVERHEAD ALLOCATIONS CAN RUIN GOOD PROCESSES

However, many shared service implementations are poorly received by the business units because they add little or no value and are charged at higher than the market rate.  As Kaplan pointed out in his seminal work “Relevance Lost: the rise and fall of management accounting” the result of poor overhead cost allocation is that perfectly profitable processes and services, burdened by excessive and misallocated overhead costs seem to be unprofitable.  Kaplan goes further and points out that all overhead which cannot be directly incorporated into the cost-of-goods-sold should be absorbed by the business and not charged back to the market verticals and service lines.  This is the fairest method but most businesses avoid this method because high SG&A costs has a negative impact on financial ratios and therefore investor attractiveness.

HIGGLEDY-PIGGLEDY 

In a recent article (shown below) McKinsey & Co pointed out a variety of methods which their client firms use to calculate IT chargebacks.   Even though they differentiated between new and mature models it is worth noting that very few companies charged their business units for what they used (Activity-Based Costing).   Rather, they used some form of bespoke methodology.  This is usually (i) a flat rate, (ii) a budget rate with penalties (for behaviour change), or (iii) a market rate (usually with additional penalties for IT R&D costs).

IT Chargebacks. McKinsey. IT Metrics

 

 

 

 

 

 

 

 

 

 

 

 

 

ALIGNMENT & ACCOUNTABILITY

Chargebacks are essential.  They are a critical means for companies to take charge of their IT costs.  Otherwise, a ballooning IT overhead can destroy perfectly good processes and service lines.  However, chargebacks can obscure accountability.  If they are not calculated transparently, clearly and on the basis of value then there will be no accountability of IT to the business and whose capabilities they enable.  Without  accountability there can also never be alignment between IT and the business.

CHARGEBACK AS AN INDICATOR OF MANAGEMENT-VALUE-ADDED

Traditional methods of IT cost modelling, on which standard chargebacks are calculated, only account for the hard costs of ICT,  namely infrastructure and applications.  It should be noted that chargebacks should only be applied for Management Information Systems (eg, knowledge bases, team collaboration sites such as MS Sharepoint, CRM systems, and company portals etc).  All other systems are either embedded (eg, robotics etc) or operational, (ie mission critical to a business unit’s operations).  MIS are largely used by overhead personnel whereas operational systems and the finance for embedded systems should be accounted for in the cost-of-good-sold.  The real question therefore, is: what is the value of the management support to my business?  The question underlies the myth that Use = Value, which it does not.  Good capability applied well = Value.

THE COST OF CAPABILITY

The cost model, therefore, needs to determine the cost of capability.  Metrics based on per unit costs are inappropriate because the equipment amortises so rapidly that the cost largely represents a penalty rate.  Metrics based on per user costs are unfair because each user is at a different level of ability.  In previous blogs we have outlined how low team capabilities such as distributed locations, poor requirements, unaligned processes etc all have a negative and direct financial correlation on project values.  We have also written about how projects should realise benefits along a value ladderdelivering demonstrable financial and capability benefits – rung by rung – to business units.

It is reasonable to say, therefore, that managers should not have to pay the full chargeback rate for software which is misaligned to the business unit and implemented badly.

It is unfair for under-performing business units to be charged market rates for inappropriate software which the IT department mis-sold them.  If that business unit where a company in its own right they be offered customisation and consulting support.  In large firms the business often scrimps on these costs to save money.  Given the usual overruns in software implementations business units are traditionally left with uncustomised, vanilla software which does not meet their needs.  The training budget is misallocated to pay for cost overruns and little money is ever left for proper process change.

In order to create a fair and accurate chargeback model which accounts for the Cost of Capability, use the following criteria:

  • Incorporate the COSYSMO cost coefficients into software and service costings so that low capability business units pay less.
  • Only charge for  professional services which the business doesn’t own.  Charging for professional/consulting serrvices which are really just work substitution merely encourages greater vertical integration.  This is duplication and duplication in information work creates friction and exponential cost overruns.
  • Watch out for category proliferation, especially where the cost of labour for some unique sub-categories is high.  Don’t let the overall cost model get skewed by running a few highly specialised services.  Remove all IT delivery personnel from the verticals.  Where there are ‘remoteness’ considerations then have people embedded but allocate their costs as overhead.
  • Do not allow project cost misallocation.  Ensure that cost codes are limited.

In order that businesses do not fall into the “Build and they will Come” trap a clear and precise chargeback model should be created for all IT costings.   Businesses should start by charging simple unit costs such as per user.  Everything else will initially be an overhead but firms may then move to a more complex chargeback model later.

It is important that low capability business units do not pay full price for their software and services.  As Kaplan is at pains to point out, where businesses do this they are at risk of making perfectly good processes and service lines seem unprofitable.  The only way to properly broker for external services is to account for the cost of capability.

 

The Complexity of Cost (Pt.2): a 3-tiered strategy for an effective ICT cost reduction program Reply

cost-reduction

In our last blog we recounted that most ICT cost reduction programs fail.  More to the point, we noted how they fail in larger businesses through a vicious cycle following increased overhead from poor process analysis.  All this stems from a limited view of direct and indirect ICT spend.

In summ, the answer is detailed cost modelling of ICT which analyses the firm’s technology in its place as a business capability enabler. This is vital in the current economic climate otherwise businesses will simply benchmark their costs against similar firms rather than try to pare ICT costs to the bone.

The results of traditional IT programs?

  1. ICT cost reduction programs usually only attack the easy and obvious.  For sustained cost management in ICT the cost reduction program needs to attack:  (i) soft costs (indirect spend), (ii) managerial costs and (iii) program costs as well as all the standard hard costs.
  2. Cost cutting reduces capability.  Traditional approach is to cut applications and services as well as heads but capability will eventually suffer.  Senior people are often made redundant was work is pushed from higher to lower paybands.  With them also goes much of the firm knowledge capital and goodwill of the firm.  If we want to quantify this cost of lost knowledge it is the difference between the market value and the book value of a business.

The problem is that IT is usually seen as a black box.  Few senior executives understand the subtle dependencies which stretch from technology throughout the business.  More importantly, few understand that actual capex and opex of ICT  just represents the hard costs of ICT.  In addition to the hard costs are the soft costs, the management costs and the program costs of ICT.  In more detail:

  • Soft Costs relate to all the indirect spend which flows from ICT procurement.  This may include travel for non-IT personnel involved in change, training and customisation or process change etc.
  • Managerial Costs is the accumulated cost of decision making from management.  This is pure overhead and is not accounted for in the Cost of Goods Sold but rather shows up in bloated Sales, General & Administrative (SGA) accounts.
  • Program Costs are the costs of running ICT programs beyond the costs accounted for in the various cost allocation systems.  These can be the cost of running distributed teams, the cost of low development capability etc.  Such cost coefficients are statistically generated.

On top of all these are the hard costs of ICT.

Borrowing diagrams from Accenture  the solution is to run a 3-tiered cost reduction strategy:

strategic cost management.accenture

After the easy stuff is done, the business must ultimately streamline its processes (and align cost structures accordingly) and then lower it non-discretionary spend.  The key is to (i) see the whole process, (ii) understand the dependencies, and (iii) engage locally.

  • Minimise (Hard Costs) –  Tactical Cost Reduction. Grab the low hanging fruit and take out the obvious costs; the costs in plain sight.  Engage locally with account managers and business unit leaders to reduce headcount but understand and model the dependencies by seeing the whole capability.  The Boston Consulting Group advise that managers proceed on third of a third rule, ie 1/3 of all FTEs are non customer facing and 1/3 of those can be removed without adverse impact on the business.
  • Optimise (Soft & Program Costs) –  Proactive Cost Governance.  This involves detailed spend analysis and process optimisation.  Indirect process costs grow like barnacles on a ship.  The longer they are there the more they are accepted but ultimately they increase the financial drag on a business.  Remove all the invented tasks by modelling the firm’s value chain and seeing where the processes fit into larger business capabilities.  Once this is done executives can optimise the key cost drivers and their inputs.  This improves the delivery model for ICT and enables better demand management.  Accompanying these operational actions the business should improve cost governance.  It can achieve this by removing the management structures around excessive process governance.  This requires a more active and dynamic GRC system but ultimately the business feels a lighter GRC touch.  Most importantly, simplify processes and remove the  ‘cost of complexity‘ ie vertical integration and convoluted workflows which increase process time and transactional costs.

cost reduction level.accenture

  • Re-design (Program & Managerial Costs) –  Strategic Cost Management.  In order to achieve significant and lasting cost reduction benefits the business must lower its discretionary spend.  However, managerial cost structures (which are significant) can only be made redundant when the overall complexity is reduced.  Once this happens shared services may be implemented and rationalised.  The ICT offering can be standardised and the business can create re-usable technology components.  Then the business can change its transfer pricing models and look towards offering the customer-facing SBUs a more sophisticated multi-channel mix of capabilities, ie give them the agility to increase their high-end customer offerings.   Only once this is achieved can the business look towards modernising and streamline technical architectures.

The key is to look at ICT as a capability enabler and not as a business unit in its own right.  ICT should have to justify its very existence.  However, once it does and develops full cost transparency then and only then can it move forward in real partnership with the business.

 

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.

cost reduction.accenture

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.