Mastering Digitalization – Shaping the organisational model
Our World is changing faster and faster. Long successful business models are under attack. Marketing innovations occur in short periods. Technology has evolved to a point where organisations get lost in the ocean of innovations. Everyone claims he has the next service or business model, which will rule the world.
Traditional organisation models are too slow to keep the pace. Silo based organisation models already questioned. Agile Teams, Squads are proposed as the solution. The End-to-End view is sacrificed in favour of fast results for adopting technologic business innovation. Digital Labs produce proof of concept which will never materialise.
Business departments are requesting technology advice from IT departments, but support is limited. IT must keep cutting the service costs and should provide more support to business units. Business departments hire IT staff to build services for products in the cloud. The percentage of product-driven IT is dramatically increasing.
Does this picture sound familiar to you? Too many loose ends? Or is it for you like old wine in new skins?
This article will take you on the journey how to master the digital change and to knot these loose ends to a sturdy rope.
The Digitalization, as the word inherits, is based on information technology. Some years ago, IT was the only department to deal with information technology, besides the product development of tech companies. Now the world has changed, and every business unit would like to play in the field of information technology under the term digitalisation. Silo structured organisation models are still familiar to the majority of companies. However, within these silos, we see more and more IT topics coming up and occupied by business units. IT isn’t accepted as the innovator, because the role model of the IT organisation is one of a delivery organisation.
Agility is seen as the holy grail to solve the time to market and to deliver results.
This digital chaos leads to enormous costs to digitalise the business model and business support processes. “Chaos creates creativity” is one of the top management phrases about the digital chaos. They see this necessary to overcome the blocking minds. Does this approach deliver results? Or is not like plaster on the wound which needs to be stitched for fast healing.
What is for sure: The Demand Supply Pattern is dead! New collaboration patterns for interaction between business and the IT are needed.
The article tries to shed some light which roles and organisation structures are needed to have a digitalised enterprise. This article delivers the big picture where other articles in this series will detail the various aspects.
Managing Innovations
Digital Transformation is not when you put your existing business processes and business model in mobile apps. A digitally transformed organisation knows how improvements in technology can be leveraged by the business. The technology will continuously transform your organisation. For example, Analytic pattern-based work from humans can be replaced by AI. New roles are required to deal with the AI, as AI can’t acquire his work packages by himself.
Digital Transformation affects your organisational structure driven through the adoption of technology. It is no longer the case that technology has the support function to the business. Now technology is the enabler for new business processes and business models. Technology, as the driver, must be reflected in fundamental organisation changes. However, technology alone will not raise benefits. Experts from business domains and organisational change management are essential to delivering the opportunities given through the technology. Those people need to be in one organisational unit.
This new organisation unit manages innovation, transformation and organisational changes. All three topics are interconnected and splitting the responsibility will create this white void where innovations will be aborted early, transformation gets stuck, and organisation changes never happen. Therefore, the unit will be called ITOC (Innovation, Transformation, Organisation Change).
To manage innovations, you need the experts from:
IT Architecture – to market the technology benefit to the business
Process engineering experts – to bridge the gap from process technology to software technology
Organisation Change In House Consultant – to boost the business benefit on technology
Business Domain Experts – to bring in the valuation of the benefits, working closely with the business
The goal of this team is to bring innovation from ideas to the Minimum Valuable Product (MVP) concept stage. Whereas the MVP is a step on a long-term roadmap where the feasible and profitable ideas are put on. The motto of the ITOC must be: Think Big and act small. The big picture must be broken down in steps which will deliver business benefits and are fast to implement. A single MVP is one of the steps to implement the big picture.
The MVP is not like a Digital Lab initiative, which built as a proof of concept solution, which seeks business attention afterwards. The MVP here is a comprehensive approach where business units get a holistic picture of the effects of this innovation from technology changes, to user interaction, business process changes and not at least organisational changes. Depending on the use case of an MVP ITOC will manage the POC done by the Digital Lab. The Digital Lab is to proof business ideas. Therefore, it must allow the alignment software technology and process technology. ITOC hast to market this holistic picture to the business owner. Only the business owner should decide if he adopts the innovation.
The difference between ITOC and the squad approach is that the squad is a kind of vertical silo. The holistic picture is not within the scope of a squad, nor does it align all the initiatives touching the scope of the squad. The ITOC has the governance function to fulfil the lifecycle of innovation. The scope ranges from the decision which business services are replaced, which business processes are changed and what roles have to be defined. Implementing Innovations is not only to bring new stuff to work, declaring what becomes obsolete is the other side of the medal
ITOC has a vital role in the transformation of an enterprise. It takes up ideas, weighs them and builds, with the idea presenter, the MVP. Since this MVP will be part of a bigger picture, this bigger picture defines the Innovation Roadmap.
To enable a coherent enterprise transformation a Digital Innovation Board must be setup. This board requires participation from senior and executive management. This board has to align the Innovation Roadmap, provided by the ITOC, with its business strategy and vice versa.
The Digital Innovation Board should not be used to approve each MVP. The role of this board is to understand the main topics the Innovation Roadmap addresses and how it will affect business strategy, organisation and revenue. On the other side, this is the shortest path to get feedback to changed business strategies and to see the impact.
This board must even act as a clearinghouse if multiple business owners are affected by changes through innovations. The board must set the right performance indicators for the management to enable the potential of innovations. The ITOC must show to the board where the existing performance indicators are blocking innovations. Besides the changing performance indicators, large scale organisational changes require approval by the board. The board must communicate his commitment to adjustments based on the Innovation Roadmap into the organisation.
Implementing Innovations
As ITOC maintains the overall transition picture and defines the steps for transition, it is not responsible for getting the concepts applied. Business Owner must supply funding to implement the MVP and additional requirements. No change to the existing processes. The decision when the MVP implementation is planned will be determined between project portfolio management and the business owner. The project portfolio management must bridge the gap between funding availability and resources.
Project Portfolio Management (PPM) will extend his current role description to plan and steer active. PPM’s scope must be spread over the planning cycle to ensure that the overall budget will be placed to the right projects. It requires a proactive approach over project prioritisation, resource availability plus allocation and budget usage.
The current PPM process has its base on a quarterly adjustment of project prioritisation and resource availability. Resource allocation is done by the projects, which at the end often leads to problems that the required resources are not available in time and budget could not be spent or is used to pay resources which are not 100% productive. The gap in the overall budget spending, caused by projects over and under spending without getting to the finish line need to overcome. Otherwise, the roadmap developed by ITOC will not materialise, and the ROI will never within reach.
PPM must be the manager of project leaders to ensure a short communication path where reprioritisation and resource shift is required. Projects should work in an agile way to allow within the project to adjust the executed work packages. In a waterfall approach, this adjustment will have high impacts on project planning. In an agile project, this will shift only milestones but not the overall result.
PPM has to ensure that resources allocated where needed. The projects must raise their requests well in advance. The overall resource planning cycles are yearly and quarterly. Active steering is required to react to the project work reprioritisation. Agile projects must develop for them self a high- level time plan for the availability of resources. This plan will be the base for quarterly planning. The agile adjustment of work scope is where PPM must work with the projects to ensure the proper staffing for the executed work order. The proactive PPM will prevent any slack in the project execution when resources and task prioritisation are aligned. It does not free the project leaders from managing the resources allocation. The resource escalation path is with this approach more streamlined.
When we talk about resources, we first must clarify that a waterfall-based approach does not provide the flexibility needed to adjust to a fast-changing business environment. Agile is not always SCRUM other approaches are possible. The assumption that agile means every result must go into production is wrong. However, every outcome should be used for feedback by the business owner and key users to prevent missing the primary business benefit. The MVP plays a critical role as it defines the playground for implementation. If this playground does not fit anymore, ITOC and the business owner must adapt the MVP. ITOC will be involved in the project to adjust the MVP based on feedback from the project, business owner and key users. The project will detail this MVP with direct involvement of key users, domain experts and the relevant business experts. Only the mix of analysis, implementation and fast feedback will lead to an MVP which will supply the ROI.
Projects, which have achieved the MVP, can add additional requirements to the MVP solution but must keep their scope within the roadmap defined by ITOC. This roadmap is agile, and it must reflect on business requirements and market development. Projects play a vital role in the adjustment of this roadmap. They are the feedback loop and the review point for the strategic roadmap from ITOC.
Getting the project on the street is more than implementing the solution. At first, we focus on the implementation. As said on the first page, the demand-supply pattern is dead, but this does not mean that we do not track requirements. The initial set of requirements given through the MVP concept will not be enough to implement the solution. The MVP describes the playground with technology, IT architecture patterns, process changes and organisational challenges. However, this playground can only be brought to life if key users and business expert get together with the technology experts to define the solution in depth. Here the requirements detail the aspects from the MVP to a production stable solution.
Requirements must be understandable for any who must work with them. Requirements noted by requirements specialists are up to the interpretation by the developers, and this will lead to something different at the end. Getting the developers out of the darkroom onto the table with the business will speed up development. The language gap between business experts and software experts requires translation by the business domain experts.
Keeping the business experts and key users within reach for the software and UI/UX experts streamlines the projects budget spending and increases the overall acceptance of the results. The formed virtual team need its communication stream to move fast forward without waiting for decisions. The virtual team must be able to drive all the critical day by day decisions. Business Line managers must enable their representatives to make decisions in a sandbox-based approach. Only changes to the MVP are pushed back to the steering group and ITOC.
Documentation of requirements is up to the one who must implement the requirements. The documentation could be use cases, user stories or test cases. The domain expert must connect the documentation to a consistent picture, based on the MVP. We detail this approach in one of the next articles in this series.
This approach involves a tight coupling of IT resources and business resources. The dual faced IT organisation with mixed service delivery and requirements implementation, will not be the right place to host the technology experts. The problem here is that requirements are attached to services or service cluster, but in a dynamic and changing IT world this view will not enable innovation. Digital Labs high-level designed as an alternative to the IT approach but will act only as a lab and not a production line.
As we see in organisations, where software plays a business-critical role, like Amazon or Goldman Sachs, the technology experts are no longer attached to service delivery. More and more integration, customisation and user experience effort come from external solution providers, integrators or freelance resources. Overarching steering, control and compliance are required to ensure consistent results for the enterprise.
The Technology Experts Group (TEG) must coordinate all the technology-related resources. Their aim is a coherent picture of the solution based on technology standards defined within the project work. The enforcement of short communications path between with the different experts is key to the TEG. The TEG ensures that from UI/UX to software integration, common practices are applied. PPM uses TEG for staffing the projects. Integrators and solution providers get the right contact persons for integration into the enterprise landscape from TEG. Overall the TEG must ensure that the quality measures apply to the work of the technology experts.
Through TEG the split of hiring technology resources between business and IT will be obsolete. The focus of the TEG is to staff the projects and ensures that reusable standards are built and enforced. The definition of standards is based on project work and not on the work of a governance body. There is no service focus only a pure technology focus to fulfil the capacity requests from the projects. All work of the TEG is project committed.
The splitting projects into a business project and IT must be avoided. Otherwise, there is always a gap where insights from technology, which drive business process and organisational change opportunities, will get lost. The project management must foster a collective understanding across the team.
Governance Interaction
The role of the TEG is bound to the technology decisions of the ITOC. ITOC drive the governance about technology through their work on roadmaps and MVP. TEG must react on those decisions to fulfil the technology roadmap. PPM is interacting with the TEG managers to staff the projects. TEG must maintain the technology patterns which are developed with the projects.
The MVP concept was created with the support of the governance function Data Security and IT Security. The MVP concept got a sign off by Data Security and IT Security. In the project phase, they must support the project in getting the details nailed down. This approach prevents that projects fail late because of non-approval from one of the governance bodies. Changes to MVP have revised by Data Security and IT Security.
IT Security must directly be linked with the TEG, to keep IT security on the same level as the technology usage evolves. With the use of SaaS solutions across public clouds and integration into the existing On-Premise world of companies IT, IT Security has a vital role in keeping track with the opportunities these operation models offer and the risks involved with them.
The role of IT Security is still not proactive in terms of suggesting solutions. They must keep track with a constant change of technology, risks and opportunities. They should act as consultants to foster a “Secure by design” approach.
Data protection officers are always bound to the business. They support the business with the legal aspects of the data the business unit owns. Business units must have a clear picture of the type of data, where it resides, who is using it and not at last about the quality of the data. Delegating this responsibility to IT does not keep the monetary value of data aligned with the business. Only with well-defined data stewardship, which includes data protection and security, is the boost of the data value possible.
With defined stewardship, the monetarization of data will be possible and should be the driver for innovation. ITOC can fulfil his role as the innovation hub for raising the value of data if this stewardship is productive implemented. With named contacts for data stewardship, ITOC together with Business Development must provide use cases to monetarize data across the business units.
Service Management
Business Service Management
In the digitalised world, the challenges for Business Service Management will be multiple. Keeping the cost under control even with changes in usage and constant change in requirements. Business service now consists of a multitude of technical services, operated by different suppliers with different cost models. The lifecycle of service will spread over a broader spectrum of service providers. IT as the only source for service costs and lifecycle management would remove the necessary transparency of cost and lifecycle management.
To hide this complexity from the business will lead to in transparent cost management and overall cost increase without the possibility to directly influence the ROI of such composite services. Business Service Management must pick up the challenge to deal with this complexity to ensure that business process costs will be strictly controlled.
The transparency of the involved technical services is part of the work from ITOC and TEG. Booth must deliver the input to business service management. Delegating the coordination of the different services to IT service management will only redirect the effort and extend the communication line. A centralisation is useful on the level of business service and technical services used across independent business units. Together with the domain expert’s business service management has a direct link to the business owners to understand the business strategy and the impact on existing services.
Business service management keeps control over the business service profitability and seeks solutions together with ITOC if profitability is no longer given.
IT Service Management
IT Service Management is on the level of each single technical services. Here the ITIL patterns apply. The service management here must ensure that the service is cost-effective, patches are in place, and new development will not harm existing functionality.
This kind of service management must be done on all services, no matter if this is a Saas solution or an internal service.
For the internal IT will provide a substantial part of service integration. This integration layer is a service to the business. The evolution of the technical services in term s of technology is managed by ITOC, while the TEG maintains the integration patterns. If service management raises demand for integration patterns- or technology change for being more cost-effective, this demand must be placed to business service management. Business service management with ITOC or TEG will decide if this placed as a demand to PPM. Whereas PPM decides if this could be part of an existing project or a new project is required.
The infrastructure a service runs in, is in the complete domain of IT service management and operation, as long as the requirements for the service are fulfilled.
Summary
The digitalisation of enterprise requires a different model of collaboration and organisational structure to successfully manage digital innovations either for business process digitalisation or for digitalised business models.
The current model with Digital Lab or Squad are structures to kickstart the transformation, but they miss a holistic approach to the required transformation.
Bundling Innovation Management, Technology Marketing, Organisational change management together in one department provides a big holistic picture to get innovations applied to the enterprise. Using this department as a strategy enabler will provide fast feedback about the feasibility and adjustment needs for a business strategy.
To implement innovations into the organisation, all aspects, from development to business process changes and organisation changes, must be sorted out. Keeping IT tasks and business tasks together will prevent opportunities from technology are not overlooked.
Keeping the whole technology experts, from UI/UX to software development and process technicians together will enable a consistent implemented picture. No matter if the resources are external or internal to the enterprise.
Changing the role definition of project portfolio management and business service management to more proactive roles will provide the active steering of sustainable capital spending.
Establishing business domain experts as the connector from the business units to the new structures and proactive roles align the focus to business needs and will raise hidden opportunities.
The role of IT has to be rethought with these organisational changes. The IT role will be primarily engaged in technical service delivery. Current functions like demand management, IT architecture are moved to a great extent to the new structures.
The approach is scalable for companies from 100 employees to infinity. The picture sketched in this article is only a first outline of what is inevitable for a successful digital enterprise. Depending on company size and business operations, different detailed pictures will apply.