{"id":20583,"date":"2026-05-18T12:11:09","date_gmt":"2026-05-18T12:11:09","guid":{"rendered":"https:\/\/www.sapcloudone.de\/?p=20583"},"modified":"2026-05-18T12:11:09","modified_gmt":"2026-05-18T12:11:09","slug":"why-most-sap-business-one-projects-fail-before-implementation-even-starts","status":"publish","type":"post","link":"https:\/\/www.sapcloudone.de\/en\/why-most-sap-business-one-projects-fail-before-implementation-even-starts\/","title":{"rendered":"Why Most SAP Business One Projects Fail Before Implementation Even Starts"},"content":{"rendered":"

Here is something most SAP Business One partners will not tell you upfront: a lot of ERP projects are already in trouble before the first workshop takes place.<\/span>\u00a0<\/span><\/p>\n

Not because the software is wrong for the business. Not because the implementation team is incompetent. But because the business signing the contract has not yet done the internal work that makes implementation possible. They have selected a system before understanding their own processes. They have started a project without deciding who inside the business\u00a0actually owns\u00a0it. They have agreed to a go-live date based on a feeling rather than a realistic assessment of what needs to happen first.<\/span>\u00a0<\/span><\/p>\n

The research on this is blunt. According to Gartner, more than 70% of ERP implementations\u00a0fail to\u00a0reach their original business case goals. A separate analysis found that only 23% of companies complete their ERP project on time and within budget. And when researchers look at where exactly these projects go wrong, the answer is\u00a0almost always\u00a0the same: the failure was baked in before the technical work began.<\/span>\u00a0<\/span><\/p>\n

70%+<\/span><\/b>\u00a0<\/span><\/p>\n

of ERP projects\u00a0fail to\u00a0reach their original business case goals \u2014 Gartner<\/span>\u00a0<\/span><\/p>\n

At Ingold Solutions, we have worked with businesses across the DACH region and beyond as a certified SAP Business One partner for years. The projects that struggle are rarely the ones where the software proves difficult. They are the ones where the business turned up to implementation without having genuinely prepared. What follows is an honest account of the five pre-implementation failures we see most often \u2014 and what addressing each one\u00a0actually looks\u00a0like in practice.<\/span>\u00a0<\/span><\/p>\n

    \n
  1. \n

    The Process Map That Does Not Exist<\/span><\/b><\/h3>\n<\/li>\n<\/ol>\n

    Ask most business owners to describe how a purchase order moves through their organisation and they will give you a confident answer. Ask four different people in that same organisation the same question and you will get four different answers. None of them will be wrong, exactly. But none of them will be the same.<\/span>\u00a0<\/span><\/p>\n

    SAP Business One implementation begins with configuring the system around your actual business processes. If those processes are not documented \u2014 not \u2018roughly understood\u2019 or \u2018mostly consistent,\u2019 but\u00a0actually written\u00a0down and agreed upon \u2014 the configuration work cannot happen properly. The\u00a0implementation team ends up configuring the software around what different people think the process is, rather than what it should be. That produces a system that works for no one department particularly well and creates arguments at go-live about why things do not behave as expected.<\/span>\u00a0<\/span><\/p>\n

    The most common version of this problem is the gap between documented policy and actual practice. A business might have a three-level purchase approval policy on paper.\u00a0In reality, the\u00a0operations manager approves everything themselves because the system that was supposed to enforce the policy was too slow. Implementing SAP around the documented policy produces a system that clashes with how people\u00a0actually work. Implementing it around actual practice means building in a workaround as the foundation.<\/span>\u00a0<\/span><\/p>\n

    Pouring modern technology over bad processes is a recipe for failure. If you\u00a0don\u2019t\u00a0fix underlying processes first, technology will simply accelerate existing inefficiencies.<\/span><\/i>\u00a0<\/span><\/p>\n

    A good SAP Business One consulting engagement insists on process mapping as a prerequisite, not a deliverable. That means sitting with the people who do the work \u2014 not just the managers who describe it \u2014 and building a shared understanding of what the process\u00a0actually is\u00a0before any configuration begins. It is slower upfront. It avoids months of rework later.<\/span>\u00a0<\/span><\/p>\n

      \n
    1. \n

      Nobody Has Decided Who Owns the Project<\/span><\/b><\/h3>\n<\/li>\n<\/ol>\n

      ERP projects need an internal owner. Not a sponsor who attends the steering committee. Not a project manager who books the meeting rooms. Someone with real authority over business decisions, adequate time\u00a0allocated\u00a0to the project, and the seniority to resolve internal disagreements when they arise.<\/span>\u00a0<\/span><\/p>\n

      In practice, what often happens is that ownership is assumed rather than decided. The IT manager assumes it is a technology project. The finance director assumes it is an accounting upgrade. The operations lead assumes someone else is handling it. The result is a project that moves at the speed of whoever can be assembled in a room at any given moment, with decisions deferred because the right person is not available, and scope changes slipping through because nobody is formally accountable for saying no.<\/span>\u00a0<\/span><\/p>\n

      According to industry data, 72% of failed ERP projects can be traced back to poor stakeholder management. That statistic covers everything from absent executive sponsorship to conflicting departmental priorities \u2014 but at its core, it reflects the same problem: nobody was clearly in charge.<\/span>\u00a0<\/span><\/p>\n

      72%<\/span><\/b>\u00a0<\/span><\/p>\n

      of failed ERP projects are attributable to poor stakeholder management \u2014\u00a0WorldMetrics\u00a02024<\/span>\u00a0<\/span><\/p>\n

      A capable SAP Business One partner will make internal ownership a non-negotiable condition of the project structure. The internal project owner needs to be named, their time commitment confirmed, and their authority over decisions made explicit before the engagement begins. Without that, even the best-planned implementation will stall at the first disagreement between departments.<\/span>\u00a0<\/span><\/p>\n

        \n
      1. \n

        The Expectation That Software Fixes Broken Processes<\/span><\/b><\/h3>\n<\/li>\n<\/ol>\n

        Lidl spent \u20ac500 million and seven years trying to implement SAP before abandoning the project entirely. One of the core reasons cited was a refusal to adapt internal processes to the way SAP was designed to work. The retailer wanted heavy customisation to replicate what their old system did rather than rethinking the process itself. After\u00a0nearly half\u00a0a billion euros, the project was scrapped.<\/span>\u00a0<\/span><\/p>\n

        That is an extreme example. But the underlying assumption \u2014 that the ERP should bend to match existing habits rather than the business adapting to better-designed processes \u2014 is one of the most common reasons SAP Business One implementations run into difficulty.<\/span>\u00a0<\/span><\/p>\n

        The expectation usually surfaces in discovery workshops. A department head says: \u2018Our current system does X this way, so SAP will need to do X the same way.\u2019 Sometimes that is reasonable. Often, the current system does X in a particular way because it was designed in 2009 around a specific limitation that no longer exists. The workaround has become the process, and nobody has questioned it in fifteen years.<\/span>\u00a0<\/span><\/p>\n

        SAP Business One is an opinionated system. It has a logic to how financial postings work, how inventory moves, how purchasing approvals flow. That logic is based on decades of accumulated best practice across thousands of SMB implementations. Businesses that come into the project willing to understand that logic and adapt where it makes sense have significantly better outcomes than businesses that treat every configuration decision as an opportunity to replicate what they have always done.<\/span>\u00a0<\/span><\/p>\n

        Unrealistic expectations also show up in project timelines. Businesses\u00a0frequently\u00a0anchor on a go-live date that was set before anyone understood what the implementation would require. When the actual scope becomes clear, there is reluctance to adjust the date. That reluctance leads to rushed configuration, skipped testing cycles, and go-live on a system that has not been properly\u00a0validated.<\/span>\u00a0<\/span><\/p>\n

          \n
        1. \n

          The Data Quality Problem Nobody Wants to Look at Directly<\/span><\/b><\/h3>\n<\/li>\n<\/ol>\n

          Almost half of all ERP implementations \u2014 48% according to published research \u2014 experience significant data migration problems. Given how consistently this figure appears across studies, it deserves more attention than it typically gets in pre-sales conversations.<\/span>\u00a0<\/span><\/p>\n

          The data quality problem tends to follow a predictable pattern. A business has been running on a legacy system for several years. During that time, supplier records have been duplicated, product codes have been applied inconsistently, cost prices are missing or incorrect on older stock items, customer accounts contain outdated contact information, and historical transaction data has accumulated errors that nobody has ever needed to resolve because the old system could tolerate them.<\/span>\u00a0<\/span><\/p>\n

          Moving this data into SAP Business One does not clean it up. SAP will accept what it is given. If you migrate 3,000 business partner records and 400 of them are duplicates, you will have 400 duplicate business partners in SAP from day one. If your product master data has cost prices missing, your margin reporting will be wrong from the first week of operation. If your opening stock balances are inaccurate, every inventory report you produce for the first several months will be unreliable.<\/span>\u00a0<\/span><\/p>\n

          One manufacturing company discovered their inventory data was so corrupted they\u00a0couldn\u2019t\u00a0trust basic stock levels. Products listed as available\u00a0didn\u2019t\u00a0exist.\u00a0Items marked as discontinued were their best sellers. The ERP worked perfectly \u2014 with garbage data.<\/span><\/i>\u00a0<\/span><\/p>\n

          Addressing this requires a data audit before the migration project begins, not during it. That means extracting the current data, reviewing it systematically, cleaning and standardising it, and only then planning how it maps into the SAP data model. Ingold Solutions treats this as a distinct workstream within every SAP Business One implementation, not a task to squeeze into the final weeks before go-live.<\/span>\u00a0<\/span><\/p>\n

          48%<\/span><\/b>\u00a0<\/span><\/p>\n

          of ERP implementations experience significant data migration issues \u2014\u00a0WorldMetrics\u00a02024<\/span>\u00a0<\/span><\/p>\n

            \n
          1. \n

            Departments That Have Not Been Part of the Conversation<\/span><\/b><\/h3>\n<\/li>\n<\/ol>\n

            SAP Business One touches every part of the business. Finance,\u00a0purchasing, inventory, sales, warehouse operations \u2014\u00a0all of\u00a0these functions interact with the system and with each other through it. Yet it is remarkably common for the implementation scoping conversations to happen primarily with the finance director and the IT manager, while the warehouse team, the purchasing team, and the sales department find out what has been decided when the training sessions begin.<\/span>\u00a0<\/span><\/p>\n

            The result is a system configured around the priorities of the people who were in the room rather than the requirements of the people who will use it daily. The warehouse team discovers that the picking workflow does not match the way they\u00a0actually operate. The sales team finds that the quotation template does not include a field they have always used. The purchasing team realises that the approval matrix is configured for how the finance director thought purchasing worked, not how it\u00a0actually does.<\/span>\u00a0<\/span><\/p>\n

            These problems are entirely fixable \u2014 but fixing them after go-live is far more expensive and disruptive than addressing them in the design phase. Change requests after go-live carry cost, delay, and the frustration of staff who feel the system was built without them.<\/span>\u00a0<\/span><\/p>\n

            Proper stakeholder alignment means bringing every affected department into the scoping conversation before configuration begins, even if those conversations are difficult. It means surfacing the differences in how each team understands a shared process and resolving them in a document rather than in a live system. It means defining what \u2018success\u2019 looks like for each department, not just for the project sponsor.<\/span>\u00a0<\/span><\/p>\n

            What a Serious SAP Business One Partner Does Differently<\/span><\/b>\u00a0<\/span><\/h3>\n

            The five failures above share a common thread: they are all decisions made, or avoided, before any technical work begins. The partner selection conversation therefore matters enormously, and it should be evaluated not just on cost and timeline but on how much the partner is willing to push back.<\/span>\u00a0<\/span><\/p>\n

            A partner that tells you implementation can begin in four weeks without asking how your processes are documented, who your internal project owner is, or when you last looked seriously at your data quality is not saving you time. They are deferring the problems to a moment when they will be much harder to solve.<\/span>\u00a0<\/span><\/p>\n

            At Ingold Solutions, our approach to SAP Business One consulting begins with a structured discovery phase that covers process mapping, project governance, realistic timeline assessment, and a data readiness review before a single system configuration decision is made. We are a certified SAP Business One partner with ISO 9001 and ISO 27001 accreditation, and our implementation\u00a0methodology\u00a0is built specifically around the SMB context \u2014 businesses where a failed ERP project does not just miss a milestone, it genuinely threatens operations.<\/span>\u00a0<\/span><\/p>\n

            The businesses that get the best outcomes from SAP Business One implementation are not necessarily the ones with the most sophisticated technical requirements. They are the ones that do the unglamorous internal work before the project starts: mapping their processes honestly, appointing a genuine owner, setting realistic expectations, cleaning their data, and making sure every affected team has been in the room.<\/span>\u00a0<\/span><\/p>\n

            Getting that groundwork right is not the partner\u2019s job alone. But it is absolutely the right partner\u2019s job to insist on it.<\/span>\u00a0<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

            Here is something most SAP Business One partners will not tell you upfront: a lot of ERP projects are already in trouble before the first workshop takes place.\u00a0 Not because the software is wrong for the business. Not because the implementation team is incompetent. But because the business signing the contract has not yet done […]<\/p>\n","protected":false},"author":2,"featured_media":20584,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-20583","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unkategorisiert"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/posts\/20583","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/comments?post=20583"}],"version-history":[{"count":1,"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/posts\/20583\/revisions"}],"predecessor-version":[{"id":20598,"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/posts\/20583\/revisions\/20598"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/media\/20584"}],"wp:attachment":[{"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/media?parent=20583"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/categories?post=20583"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sapcloudone.de\/en\/wp-json\/wp\/v2\/tags?post=20583"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}