Since our inception in 2014, a significant portion of Embedded’s revenues has been Technology Procurement, advising or helping clients buy technology that best suits their requirements. Procurement is a well-defined profession, with multiple accreditation and trade bodies (such as CIPS), but it always amazes me that the majority of the teachings are on the process of buying rather than understanding what you are actually buying – which is where we tend to focus.
By definition, Procurement is a ‘commercial’ role. To successfully buy something, you need to understand how it commercially sits within a company’s policies and processes, confirming legal terms, pricing structure, performing supplier due diligence etc – and this is all extremely important. The context of the purchase however is you are buying something to fulfil a business need and buying something without fully understanding its purpose or function is highly likely to cause problems longer term.
As a result, a significant focus within the procurement discipline is on requirements gathering. Ensuring a clear specification for your purchase is critical to success. However, a number of Procurement departments that I have worked with tend to shy away from taking responsibility for defining the requirements for their purchase – they pass accountability of understanding what they are buying to (in our technology-focused case) the IT team, and if the wrong thing is purchased it’s not their issue.
This approach delivers clear accountability but makes it very difficult for Procurement to proactively add value. If Procurement professionals, especially those with a specific category responsibility, do not understand their category at least as well as their business counterparts, they are always going to be on the back foot for asking the right questions to drive out a detailed requirement. In Technology terms for instance, engaging to ask the questions about Target Operating Model (defining scope of service with suppliers’ resources), ITIL processes (defining scope of managed service SLA’s for a supplier / IT team) etc. both reassures the IT team that they are working with a peer, but also gives you the context on which to design commercial constructs that define success.
To consider all of the commercial aspects, you need to understand what something is doing and why. Measuring performance of technology (KPI / SLA / Outcomes) is, in my view, the most important aspect of ensuring your procurement is successful. Pushing accountability for that performance onto suppliers is key. Similarly, assessing and allocating risk of a procurement (second most important aspect) is entirely reliant on understanding what a product is doing and what it’s influence is on the outcome.
Procurement best practice process proposes a “category strategy” that defines the direction of travel for a given category / sub-category and aligns this to a given business strategy. Although usually the preserve of major corporates, having a category strategy for technology – no matter how light touch – is absolutely the right place to start to help Procurement understand context, build value and align objectives with their business counter parts, and move to a more proactive relationship – especially in Technology. With the constant changing environment within IT, getting your IT function to think about – and commit on behalf of the business strategy – to what the next five years of purchasing is likely to look like is an excellent thing to do.
Asking the following questions, and documenting the answers, will set the guard rails for all technology purchases and allow Procurement to engage suppliers on a longer-term basis, which massively helps with negotiation and consolidation strategies:
What is the business strategy on which the IT strategy has been defined?
What will IT look like in 5 years’ time? - Technology platforms (hardware / software) - Volumes of work (how many users, how many transactions, how “big” will things need to be, or small will they reduce to) - Organisational structures (team structures, roles)
Who are the key decision makers within the IT team and what is the boundary of their authority (spend, supplier decisions, technology changes etc.)
Based on the following category substructure (proposed), who has responsibility for each of these elements? And what is the technology strategy / volumes of work / organisational structure changes likely to happen at this level?
These are key (starter) questions for a Technology Category Strategy. Once defined, as a Procurement Professional you have a baseline against which you can assess technology procurement requests. “Buy me 100 Dell Laptops” is contradictory to a strategic move to Virtual Desktops – challenge. “Renew that hardware maintenance contract for 5 years to save 10%” is contradictory to a strategic move to 100% public cloud (assuming the hardware will be replaced) – challenge. Your agreed strategy for buying allows you as a Procurement professional to engage with the IT team in a way that supports the business strategy.
Once you have the above, you should use the same structure to define your current spend and contracts. Aggregate those contracts / spend into a report that shows key suppliers, key renewal events and other known projects. Agree that with the stakeholder responsible for the subcategory area. This is a basic category plan and aligns your activity to the IT team such that you are no longer reactive. You have a plan of what you are spending, what you are likely to spend, who your key suppliers are, and who they might be in the future.
Then use the same structure again to define market trends. Some ideas are below, but this is subject to change and should ideally be reflective of your business / industry specifically:
End User – Remote working driving higher volumes of laptops, printing no longer seen as a business service (from home), some businesses considering virtual desktop to reduce hardware costs, remanufacturing of equipment is key for environmental considerations
Application Software – largely moving to the cloud (Software as a Service); Artificial Intelligence and Data Analytics becoming major factor in purchasing. Integrations between applications are key to ensure services can talk to each other through automation
Middleware – Largely moving to services that support integration between applications internally and externally, in some cases having to support external API data services. Other middleware items should consider development / release tooling and automation
Database – Materially affected by Data Strategies, moving to platform based services (PaaS) and more recent database structures NoSQL etc are better suited to storage of certain unstructured data types (images / documents)
Security – likely to become most risk based area of IT spend, critical to the security of business as rise in cyber threats increases. Needs to be holistic (not just protecting networks or hardware) and updateable
Server / Storage – mostly moving to the Public Cloud (IaaS), costs are materially reducing as price / performance increases – avoid long term investment/lock-in and consider recycling / data destruction as part of any asset disposal
Data Centre – mostly moving to Public Cloud (IaaS), costs are directly related to energy costs in the main (electricity) and so becoming more expensive. Push for fixed energy prices / avoid indexation to pass risk onto supplier.
Data Networks – Becoming the defacto place to transmit everything, replacing Voice, bandwidth increases being driven by Video and Voice and Big Data projects. Consider mobile as an alternative now 5G networks are becoming more mainstream.
Voice Networks – Mostly being phased out in 2025+ (PSTN networks) and migrating to Data based network solutions (VoiceOverIP – VoIP)
Mobile Networks – Largely commoditised and consolidated into the 4-5 main carriers in the UK, mobile data is becoming the key battle ground (4G/5G/6G) and handsets need to be future proofed to support these changes. Consider extending life of handsets beyond 2 Year lifespan in context of improving environmental impact of hardware.
To finish the Category Strategy, use PESTEL (Political / Economic / Social / Technological / Environmental / Legal) analysis to determine any future changes in the broader macro-economic or regulatory environment, and Porters 5 Forces to determine competitive landscape in a given area. Some people don’t worry about this step so much as it can be quite onerous and subjective, but it does help build a perspective that considers broader market factors.
This all help should identify opportunities and tactics that are the key activities that will achieve the strategy, e.g.:
Consolidate all <£50k supply contracts into a single service contract to reduce management overhead.
Renegotiate [contract x] early to offer extension for a reduction in cost / improvement in terms / improvement in quality.
Perform market research for [project x] that is kicking off in 6 months such that we have a clear view of future suppliers etc.
Et voila – a category strategy plan that is documented and agreed with the IT team of your activities for the next few years.
We worked with CIPS a few years ago to create a template technology category strategy, which we’re more than happy to share if anyone wants a copy - just get in touch.
At Embedded we have consultants who have worked in technology industry for decades, who have a genuine appetite to learn (and continue to learn) new technology products and services. As consultants, we have the luxury of time to perform analysis or research into topics that interest us. More importantly, most of the consultants we work with have actually worked either in an IT Team, or on the Supply side of IT, both of which force you to not just understand technology but how it is used / deployed so you can consider the technical, operational and commercial aspects of a Procurement on a peer level with an IT team.