Tag Archives: digital governance

  • -

Manage the bill of IT as a service

Category:EA,Services Tags : 

While some stakeholders focus on outcomes of IT and how to deliver strategic planning to innovate new business models, there is also the ‘other’ operational perspective: the large mundane of existing IT-related processing which often needs ‘just to continue’. For that second perspective it is of interest to increase the transparency and decision measurability: how can you support the business operations in a more efficient way?

Even today in most organisations, the cost of supporting the business operations is the major cost pool within IT. And to make the bill of IT cheaper and more transparent, it does require some standardisation and framework. While it is harder to compare new strategic stuff, the maturity of financial IT spend models like TBM has matured to provide sound comparable measures of the bill of IT. But what is the ‘bill of IT’? Reflect a little over questions like:

  • What is the border of IT? (if IT is being used outside of the IT department, which is likely what happens most places) – then what share is the bill of IT?
  • Where does the cost of IT stop, and when is it cost of another department, cost of another project or cost that we don’t calculate?
  • What does cost mean to talk ‘bill of IT’ when we pay upfront, but depreciate over many years?
  • What about digitalisation and disruption catalysed by new IT and technologies – where does this fit into the ‘bill of IT’?

These questions are all relevant and easily solved when TBM becomes an instantiated process with transparency to stakeholders. It is not only about a tool, but typical a service provided enabling managers to see the inside of IT spend leading to decision makers getting meta-data and facts to rely on when discussing where to cut and where to invest more.

A over the last years, there has become almost a cross-standard to the taxonomy of how to deal with this. The answer is moving towards an open standard called ‘TBM’ where TBM stands for Technology Business Model. There are hundreds of organisations that now move into the three-layered structure of the TBM to get a comparable measure of the bill of IT.

The TBM concept is not new; Large accounting companies worked with the practice years before the TBM Council started, but the standardisation, the scale and the maturity of digital platforms offering the bill of IT is ramping up. The TBM perspectives of the bill of IT provides a clear view on IT spend, offering a model to get transparency to unit cost and cost drivers, consumption and performance – helping CIOs, CTOs and CFOs to get aligned views of where to cut cost and where to invest more.

Who are the stakeholders of TBM and the transparency of the bill of IT?

‘Many’ is the simple answer. Just to touch a few:

  1. Managers in Business Operations: Who can finally get a fact-based overview of cost pools, contracts, systems that aggregate to the spend of running the IT within the business operations.
  2. DevOps: Application owners who can better understand the application cost, quality and value. Help to decide future spend profiles.
  3. Service Owners: What is the cost of certain infrastructure components such as servers and software, supplier by supplier, and how to estimate end-of-life cost.
  4. CIOs and CTOs: People who are asked to invest in the future and cut cost on operations. Where to look for the savings?
  5. Business Relationship Managers: Helping the business to get more value to the business planning, what is the priorities to take.

What is the process of the TBM when implemented?

The TBM is based on single-loop learning of implementing an annual learning cycle where IT Spend is aggregated from managed architecture meta-data, stripped into pools, and aggregated with the IT landscape as systems and services, before aggregated to business capabilities or Business Units.

We typically advocate to master the meta-data not just to crunch numbers without clear ownership. It typically implies TBM to be solved by finance people and enterprise architecture teams to unite the task of managing the overview, often solved by information management tools like MooD or similar.

The integrations between an information management tool like MooD and a financial system like SAP or similar is required. The MooD system will then manage the collaboration with end-users, IT managers, service managers helping to get meta-data correct. Then the SAP or similar financial system will provide the cost centers, the daily bookings, the different accounts. However, if no solution is in place, bookings often follow financial account numbers, where as the mapping to IT is typically done within the architecture system.

Once a solution is configured and set alive, the budget cycle will start as an ongoing process, relying on the master data from the information management system, typically, it is based on last year’s consumption providing input to the budgets and forecast numbers. The TBM is the model or taxonomy of this data crunching.

 

What is the basic concept of TBM?

Irrespective of the digital platform, the bill of IT is simply structured into three layers, like almost three different architecture layers:

  1. Business layer: To describe the business capabilities and value chain of the technology supported IT spend. This should provide an enterprise perspective of the business and future looking cost perspective. The logical grouping and allocation of cost should be mapped to business applications or business initiatives – using the language of the business.
  2. IT Ops layer: To describe IT products and IT towers of IT assets which is technology groupings of units and unit cost within functions. As evolving the solution, then also IT Dev as part of the layer.
  3. Financial layer: Describing services procured in some currency, by terms, depreciations, cost, to understand cash versus cost perspectives of the agreed bills.

The benefit of the TBM model is that it translates between the layers. Solutions typically can provide the what-drives-what view between the different perspectives, typically build on some degree of allocations or apportions, handshakes and cost agreement splits. However, without the assumptions and structures of TBM, no-one will be able to communicate clearly what the cost of a project or a service really is.

How to get started with TBM?

If you are interested in getting a clear view of the Bill of IT, this is something that is hard to solve without technology and advice. Try to outline the end process; then start with the  information management to establish the digital governance. We have seen too many project implementations that suffer from not aligning the governance early enough, creating poor data and too restrictive assumptions. This typically happens when financial tools are introduced without focus on digital governance and data quality. So to succeed you need to form a project charter with enterprise architecture and financial managers involved. A transparent view of IT should include the above layers:

If you are interested in knowing more about TBM and cost models, please seek advice of how to implement this on a modern digital platform.

We help to align long-term planning with short-term planning, which is an ongoing process – and a digital process of information management. Long-live the digital planning. If you have questions, please make contact. We are a consulting house with senior profiles and business solutions; we provide deep expertise in digital planning, digital governance and process automation. We power your digital mood!


  • -

Digital governance & agility – getting it right this time!

Category:EA,Services Tags : 

According to both Gartner & Mckinsey that statistics state more than 75% of the agility and digital transformation projects fail. Going through the details, it is also noticed that many still believe these transformation programs could be solved by applying EA tooling or BI tooling. However, these technologies are quite different in philosophy, and there are certain shortcomings and limitations of using using this type of tecnique to solver such programs:

  1. The BI “approach” is typically led by financial people and with a reporting perspective; nothing wrong with this, but it is just very different from the agenda of providing large change, interactions and planning. If you try to fry using a pot rather than a pan, it will take longer, and with a lower chance of success.
  2. However, what about the magic quadrant of EA Tools then? Quoting one of our customers, “EA Tools are like lemons, sour and very hard to eat on their own” … The magic quadrant seem populated with tools that have a very narrow view of enlightening the architect herself/himself that puts effort into modelling. How can that in any way help the corporate agility?

Agility is the ability to change direction at higher pace, it is not about the speed! For a company to be agile, it needs to provide a foundation where people share an understanding of change, and eventually, share the interest to change course when needed. This is partly culture, partly getting people to buy into to the strategy, often helped by a digital platform to help building a digital governance of managing the business processes, systems, and offerings.

“Agility is the ability to change direction at higher pace, it is not about the speed!”

As humans we encourage people to be proactive, thinking, questioning, – however – it also means if we don’t all buy into the strategy or direction, we will act differently as individuals. For a company to succeed to change course at a higher pace, we need to promote the idea and federate the updates –  and every day! Managing the agility is about carrying out many small steps where people can relate and buy into the updates of helping the bigger enterprise with transparency and regular feedback.

So almost paradoxically, what agility means at a corporate perspective is that we need the shared value of helping each other to federate updates and insight to make a company agile, by this, removing some of the individual freedom to avoid new ad-hoc ways of doing stuff. This is a very different perspective than to allow a few architects to analyse and build models on their own. Agility is about getting to the digital platform where decisions and changes can be made faster, with lower risk and based on federated input; otherwise the platform is just for architects, and then you can have a look in the magic quadrant: how to fail yet another time…

Now, as an example… an old one: “What is an application?”. As simple as the question is, who is interested in the answer? Why do we need the answer? How would we as a company ever get to the answer?

To answer it partially, we would advise you to take the enterprise perspective, that if users and people of the organisation cannot see the “calculation” and updates of what we believe is an application, you will never get to more than a point-tool perspective, so in an agile context, you will fail. If your approach is to model it for the architects, using a tool only the architects can handle, please look for the bin!

Back to the former question, applications can only be of relevance if they relate to the processes, the inner game or outer game of the business planning.

  1. If in context of the outer game, it is relevant to carve out what to shut down, what to procure to deliver the new business model – this is the sweet spot of corporate agility where the business model is transformed into a new form.
  2. If the inner game, then we talk efficiency or changes to way of working, then operational efficiency and processes are the sweet spot where business is being digitized.

If you ask in your organisation, the business leaders might say we have a few systems, if you ask the IT managers, they may say many processes, so many applications, and if you meet people from IT Operations, they have their own definition, and they say approximately 20 per device. To solve such a simple question with a modelling tool will not succeed. The entire wrapping of use-case, interaction and planning is required, and it is often motivated by having a label on that wrapping called “agility”, where the benefit of classic EA tools and BI technology seem limited.

The technology required to build the digital platform for improving the agility requires a flexible model, that can be changed again and again over time. It also requires people to use the outcome, daily, every day by loads of people to get the metadata correct. And it needs to look like the corporate web portal with colours, fonts, etc. to get the attractiveness that people buy into.

If you are in doubt on how to build a digital platform in order to succeed with the digital governance and agility, try to look at the organisational usage, then identity the interactions and flexibility. Try to avoid pre-built one-size-fits-all solutions, we mostly see that the can demonstrate value only on the first mile. With the right collaboration, each employee or team is accountable for their own part, they like to contribute to the bigger picture, and the management can avoid attachments and PowerPoints. This is what digital governance is all about.

In practice, this also means the digital platform will be a combination of human input, and online data like CMDB data (Cherwell, Service Now, etc.), PMO data (Project Server integration, or similar), people data (AD or HR data), finance data (SAP, etc.). A modern digital platform is where decisions and agility moves can be made from – it pulls the data into the single source of connected insight.

We help to align long-term planning with short-term planning, which is an ongoing process – and a digital process of information management. Long-live the digital planning. If you have questions, please make contact. We are a consulting house with senior profiles and business solutions; we provide deep expertise in digital planning, digital governance and process automation. We power your digital mood!


  • -

Start your digital service integration – introducing SIAM

Category:EA,UK Blog Tags : 

As we force ourselves into even higher gears of technological innovation, the trend in the market is to move closer to multi-sourcing and high-end services from best-of-breed suppliers; e.g. one supplier might be good at delivering People Performance Management, while another provider is excellent at providing Information Management. So instead of outsourcing all infrastructure and databases to one supplier, it may be attractive to partner with that vendor, who is e.g. leading in cutting edge solutions to People Performance Management and Information Management –  including all operations, maintenance and development.

For the organisation procuring such services from still more high-end providers there is a challenge of how to succeed with the management and administration of services, which doesn’t necessarily fit with each other. How to manage the multi-sourcing setup providing insight and accurateness of the information management of the different service providers.

The term to manage the multiple vendors to provide consistent services to the end-users is denoted Service Integration and Management (SIAM). The objective is to provide a single business-facing IT organisation, however, as these vendors deliver different types of services, the term services often gets blurred in discussions – and can often be quite different things! Hence, there is a pitfall in trying to establish a huge services framework as a theoretically based exercise. To succeed, we recommend building the services step-by-step as the digital governance is established in the  living architecture.

According to the research paper by Goldberg et al, SIAM is the discipline to procure and blend services from multiple external and internal providers. As the SIAM management eventually will have a cost, and the best-of-breed providers may be hard to compare with more traditional outsourcing providers, there may be a challenge on cost.

Many clients face different issues implementing and getting the SIAM layer to perform satisfactory. Simply to succeed with SIAM, the organisation needs to understand the architectural structure of the IT landscape, and how it is managed by delegating accountabilities of a digital governance. However, the main pitfall is still that most stakeholders are reluctant to buy ‘services’, e.g. if they have a preference for certain vendors, certain products, certain solution patterns. There is this paradox, as to succeed with service integration, you might have to go around services as a term. To establish an end-to-end SIAM solution you need to work on the digitalisation of the metadata and information management of the different vendors. To succeed with SIAM, you need to manage your sourcing assets with all the relevant dependencies as part of managing the digital governance. This is almost a prerequisite to manage SIAM as an ongoing digital process.

Before moving into SIAM, an organisation should consider many factors. We have listed 7 pieces of advice to succeed with digital services integration:

  1. Map out your Business Capability Map so you have a consistent view of ‘what does the business do’, and what is done where in the business

 

  1. Then map the business applications and business projects and other sourcing deliverables. This allows a direct coupling from IT to Business, and allows in parallel the business services construction. Try to avoid layers of academia and ‘noun services’, start building the typical orderings and offerings requested from stakeholders and end-users.

 

  1. Enable a digital solution of the management of the service integrator; managing the information exchange between own organisation and external providers. What is the live information you get from the providers to secure your information is up to date.

 

  1. Enable a digital solution of the management of the service integration, managing the information between the different providers. What is the alive information you need to manage the vendor?

 

  1. As the SIAM solution evolves there will be a living representation of how infrastructure relates to business applications, and development, and further into the business. Make sure this end-to-end model is clear, alive and governed using terms common for end-users (not the academics).

 

  1. Align the vendor management with the information management to align scope and expectations across the provider contracts. The information management should be an online living architecture which at heart supports the SIAM solution. Ensure silo-services and non-silo services are experimentally approached, validated, and approved.

 

  1. Get yourself an advisor who can help you to build the SIAM portal with an agile mindset. Most of the services and groupings of a SIAM solution must mature, the fastest route is to experiment, validate and grow. It is like a restaurant, where the services menu card is not ready day 1, but testing a menu card, you will see which services are asked for, in what type or spiciness, and what other meals could be composed from some of the same ingredients.

 

The integration of interdependent multi-sourcing services is difficult for many clients, but for those clients who manage the information management as a  living architecture with digital governance, it is a minor step. The challenges of assuming this is done by IT Service Management is often a too simplified picture, and the challenges to solve the services enabling before building the SIAM portal seems often academic with limited success and low impact. We advise to bring alive the digital platform using interaction in the planning and definition of the SIAM solution. This is the safest way to enable your digital services transformation.

We power your digital MooD.