Expert consulting and managed services to help complex organisations to work flatter, faster and more dynamically.

      With the help of our trusted partners:


      Solutions Home




        BDQ Originals



          Other products








              Whether it's our own Atlassian Marketplace apps or the apps that we provide a value-added-reseller service for, you can trust BDQ for the best support, consultancy, training and implementation available.


              Products Home



                • We provide high quality technology training to customers in the UK, EU and US.

                • Our customers range from small companies to multi-nationals. They all want to maximise employee productivity.

                • We listen to what our customers want to achieve, and take this into account when delivering the courses.

                home-icon-300x300Training Home →


                  From webinar recordings to whitepapers, case studies to blog posts. Help yourself to our free content that will hopefully inform and inspire.

                  Resources Home →
                    2 min read

                    Always look on the practical side of life

                    My boss told me about a conversation he'd had with a developer friend last week that’s a great example of the dynamic between the functional capability of software products and the practical realities of projects.

                    They were talking about how a customer is using DataQA on a SAP standardisation project to show what legacy SAP data will not meet the load requirements of their new single, global instance. My boss' friend thought it was interesting but then said "...SAP already has data quality tools like LSMW (Legacy system Workbench) that can do this sort of thing..." and proceeded to explain how rules can be defined in LSMW to identify bad data that will fail the load process.

                    Both my boss and his friend could see the discrepancy: why use DataQA when LSMW seemingly does the same thing? The friend quickly put it down to either lack of awareness, or bad practice but my boss wasn't convinced. The team using DataQA are seasoned SAP consultants and they’d been very clear on it strengthening the client’s capability in this area of the project and reduce the risk of delay or budget over-run. So my boss asked his friend two simple questions: (1) LSMW can identify data that won't load into SAP and (2) Can think of an SAP project where the data migration / upload component has ever run smoothly?

                    The friend paused for a moment and answered 'Yes' to the first question, 'No' to the second. And then looked a little stumped. If LSMW can identify what data cannot be loaded into SAP, why is it migrations are still notoriously difficult to complete? My boss asked his friend how LSMW is used at which point things started to make a little more sense. The friend explained that first you need to have your SAP instance defined and implemented. Then LSMW can then be pointed at the instance, dq rules can be developed and so forth.

                    Whilst perfectly sensible, from a technical standpoint, this approach assumes the project is going to run in a linear fashion and that time or cost is no object. However, the running costs of a project mean time is always a concern and as a deadline looms activities come under pressure to compromise or are run, at risk, in parallel. These realities mean tools like LSMW, dependent on a final SAP solution, often cannot be fully utilised. In comparison, DataQA's template-based approach allows you to build rules using based on business / application requirements and so start assessing what data will not load way earlier into the project lifecycle - giving you more time to identify problems, fix issues and ensure the data will support the anticipated ROI of your SAP implementation.