Public Sector is under pressure to meet rising expectations of its constituents – citizens, businesses and employees. This affects areas like constituent services to be made available in the same consumer friendly way as we are used to from the commercial world, but goes far beyond. It requires re-thinking of its entire infrastructure including the many specific software applications in place today, in order to be able to collaborate, make better use of data, derive decisions, predict, increase efficiency etc.
The “Make” approach
The existing infrastructure and software is in some cases 30-40 years old, created by a pure Make approach: Large IT departments or IT services companies have designed custom-built systems that exactly fit to the specific needs, with very limited standardization, reuse and synergies between systems. With this approach, maintenance of IT systems has become more and more difficult and expensive, partially because of rare skill sets in old technologies (e.g. Cobol). The architectures do not support the required modernization. So new software and infrastructure is often the only way to really modernize and support transformation.
The “Buy” approach
A key question is what type of approach to take for this. Standard COTS (commercial off-the-shelf) software is available in the market today and has the flexibility to meet the needs of Public Sector agencies. E.g. SAP offers solutions for Public Sector administration, but also solutions for specific agencies such as social protection, tax & revenue management or investigative case management. These solutions can be tailored to the specific needs of the organizations through configuration. But COTS solutions are not available for everything across the Public Sector.
So which of the two approaches is the best one?
Make is still dominating many areas in Public Sector today. Now, with the challenge of increasing maintenance efforts, shrinking resources and increasing expectations from stakeholders, Public Sector is increasingly considering standard software as a basis for its core areas in the various agencies. Standard software that is designed in an open way can be extended through own customer specific developments to make it fit to their specific needs where necessary. This means that the organizations do not need to start from scratch, but can pursue a Make strategy based on standard software and platform technology which they Buy, resulting in a Make AND Buy strategy. Those organizations that already have standard software in place in certain areas can leverage their existing investments and can expand their solutions based on what they already have. Those that do not have standard software in place benefit from introducing standardization while meeting their individual needs.
Which benefits can I expect from a Make AND Buy strategy?
There are many. First of all, building on existing standards reduces time & efforts to come up with a ready solution. Development projects become smaller and more predictable, resulting in a reduced risk to fail. Overall, the willingness to invest in large and long running projects is getting less and less, so an approach to reduce risks and make outcomes more predictable is welcome. However increased efficiency during the build phase is only one benefit. An even bigger benefit comes during the maintenance phase: Re-used standard components are maintained by the software vendor and get thus modernized without an organization needing to invest in limited own resources. This may mean for example that the next required innovation, e.g. to mobilize your application, is already supported by the overall architecture and the re-used components.
What are the key enablers of a successful Make AND Buy strategy?
From my view, two things are required – a strong technology platform and a comprehensive set of re-use capabilities on different levels.
- Let’s start to look into the technology platform. The technology platform does include a database, but goes far beyond – it is a set of tools, technologies and engines that have been designed to provide robust solutions to run in a business environment. SAP has more than 40 years of experience in designing platforms for the development of business applications - these experiences result in capabilities such as application lifecycle management, monitoring, security, scalability, flexibility, openness etc. that have a crucial contribution to the enterprise readiness of our customer’s applications. All those now are coming together in the SAP HANA platform – you find more information here.
- Re-use capabilities. You benefit from technical capabilities as well as from more application level capabilities. Both are important and powerful to standardize application development, take away commodity tasks from developers and to enable focus on the business problem to solve.
Re-use capabilities on a technical level are included in the underlying technology platform and do not provide a business process or parts of on their own. Examples are user&access management, data management, application logs, business object frameworks, output management, error message concepts, etc.
Re-use capabilities on an application level provide business functionality and related UIs. Examples are Business Process Management, Case Management, Document Management, Workflow, Payment engine, Pricing engine, Collaboration, Identity Management, Rules Management, etc.
SAP provides a portfolio for 25 industries in more than 100 countries, so it is highly probably that you can find re-use capabilities which you can use as a starting point to solve YOUR problem.
What do YOU think?
I am very much interested in your thoughts about the Make AND Buy approach. What do you think in general? Where is this a beneficial approach, and are there situations where it might not be? May be you have already successfully applied a Make AND Buy strategy somewhere, and have identified key enablers that made the Make AND Buy a successful strategy for you?
- SAP Managed Tags:
1 Comment
