For companies running SAP ERP and S\/4HANA, the role of the ERP as the system of record is central: master data, transactions, permissions and business rules are maintained here and must be consistently reused in procurement processes. If the real costs of integration with SAP ERP are not considered at an early stage when selecting additional solutions, complexity is pushed into the integration layer, with corresponding impacts on project timelines, process stability and TCO.<\/p>\n
Implementation and standard capability as cost drivers<\/strong><\/p>\n Implementation is one of the most visible TCO blocks \u2013 and at the same time one of the most variable. In practice, the range spans from projects that go live in around a hundred days to initiatives budgeted for several hundred or even a thousand consultancy days. What is decisive is less the abstract complexity of the company than the question of how powerful the solution is in its standard.<\/p>\n The more procurement processes \u2013 including company-specific particularities \u2013 can be mapped without additional development, the lower the implementation effort and future adjustments will be. Conversely, a strict \u201cfit-to-standard\u201d approach leads to deviations from the prescribed process quickly becoming individual enhancement projects. Many companies underestimate the development, testing and maintenance effort that results over the entire lifecycle of a solution.<\/p>\n For tender practice this means: it is not enough to rely on general statements about \u201cstandard capability\u201d. Procurement organisations should specifically probe which processes are supported in the out-of-the-box product, how department- or country-specific workflows are handled, and what experience exists regarding typical project durations in comparable environments. This typically requires early engagement with the provider, detailed product demonstrations, thorough requirement reviews and reference checks.<\/p>\n Integration architecture, middleware and data copies<\/strong><\/p>\n The second major TCO block is integration. Hardly any procurement solution runs in isolation; it must exchange data with an ERP such as SAP and with other systems. In classic architectures, an additional integration layer is built for this purpose: the ERP transmits master data, organisational structures and transactions to the procurement application. In turn, the application returns purchase orders, goods receipts or invoice data to the ERP \u2013 often based on periodic data copies.<\/p>\n Technically, reconciliation at very short intervals would be possible, but this comes with high infrastructure and licence costs. In practice, synchronisation therefore often takes place only once a day or less frequently. If data in the ERP changes between two runs \u2013 for example, when a supplier or a cost centre is deleted or a delivery address is adjusted \u2013 a break occurs: the procurement solution works with outdated information, integration processes fail and transactions get stuck in the middleware. Such errors have to be cleared manually in integration monitoring, consume time and also harbour compliance risks if purchases are made on the basis of incorrect data.<\/p>\n An architectural approach that consistently relies on the ERP as the leading system and manages without additional middleware between the procurement solution and SAP significantly reduces these effects. This not only eliminates licence and operating costs for an additional integration platform, but also a large part of the laborious integration monitoring. Data is not duplicated, updates take effect immediately in the leading system, and interface error-proneness decreases.<\/p>\n Outdated information in downstream systems increases not only operational effort but also the risk of failing to meet financial controls. ERP-centric approaches with minimal data duplication improve process reliability and reduce the need for corrective actions.[\/vc_column_text][\/vc_column][vc_column column_padding=”no-extra-padding” column_padding_tablet=”inherit” column_padding_phone=”inherit” column_padding_position=”all” column_element_spacing=”default” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” column_border_radius=”none” column_link_target=”_self” gradient_direction=”left_to_right” overlay_strength=”0.3″ width=”1\/2″ tablet_width_inherit=”default” tablet_text_alignment=”default” phone_text_alignment=”default” bg_image_animation=”none” border_type=”simple” column_border_width=”none” column_border_style=”solid”][vc_column_text]Operations, maintenance and skills: making day-to-day effort visible<\/strong><\/p>\n After go-live, the longest \u2013 and often the most expensive \u2013 phase of the software lifecycle begins. In ongoing operations, tasks arise that are often only accounted for in TCO calculations as a lump sum, such as monitoring interfaces, processing error messages, adapting to changed processes, testing and rolling out releases. The more components and technologies involved, the higher the ongoing effort.<\/p>\n Another factor is the required skills. Different technologies demand different qualifications \u2013 a person who administers SAP cannot automatically administer a separate middleware or proprietary platforms. A clear TCO advantage arises where implementation, setup, operations and further development of a procurement solution can be handled by the same teams that already look after the ERP.<\/p>\n For procurement organisations, it is therefore worthwhile to quantify the ongoing effort concretely: How many hours per week go into monitoring and error correction? Which tasks can the internal IT team perform, and where would external partners have to be permanently involved? Which new technologies are introduced \u2013 and which skills are required for them?<\/p>\n Selection processes and comparability: making TCO visible in RFPs<\/strong><\/p>\n Tenders often compare very different approaches: standardised, ERP-adjacent e-procurement solutions on the one hand, and largely bespoke developments on generic platforms or low-code stacks on the other. At first glance these paths can be contrasted via licence prices and feature lists. From a TCO perspective, however, it is often \u201capples and oranges\u201d: a high proportion of customer-specific development per project leads to correspondingly high implementation, maintenance and migration costs.<\/p>\n Later surprises \u2013 both in the project and in ongoing operations \u2013 can be significantly reduced if companies capture functional, technical and operational requirements in a detailed catalogue in their RFPs (Request for Proposals) and go through them point by point with potential vendors. In such selection processes, not only functions are discussed, but also integration principles, necessary additional software, data flows, maintenance effort as well as required knowledge and skills.<\/p>\n TCO questions should therefore be a fixed component of every tender: from the number of implementation days and the required integration architecture to the operating model, release management and skill profiles. What matters is not only the written answer but also discussing it together and critically questioning assumptions.<\/p>\n