A data quality project almost always begins as a technical cleanup task and ends as an organisational conflict. Consider a food packaging manufacturer in Konya, Turkey, with 312 employees. Last year, the IT team ran a six-week standardisation sprint across customer data spread between their ERP, a basic CRM, and a logistics module. Duplicate records were merged, missing fields were filled, address formats were normalised. The project closed on schedule; reports started working correctly. Four months later, the same data degradation had returned. The reason was straightforward: the process that generated dirty data — each department filling order entry fields according to its own notation habits — was still running, unchanged. The technical cleanup had been a coat of paint applied over an organisational fault. This article addresses the loop that keeps companies trapped there, and the three pillars that break it.My thesis is this: any company that launches a data quality programme before establishing an ownership model will repeat the cleanup within six months at most. The process producing dirty data is still in place, and there is nobody whose job it is to stop it. This is not a failure of IT capability; any data domain operated without defined ownership will degrade by default. The most common misapplication of ‘Data First’ in Turkey is that companies begin with technical tools — a quality scan, an MDM platform, a data catalogue — while postponing the questions of who is accountable, who defines the standard, and how success is measured. When the sequence is wrong, it is not the tool investment that is lost; it is the process investment.The correct sequence is: ownership first, quality programme second, data product third. The ownership model begins by naming a single ‘data owner’ for each critical data domain. This person does not come from IT; they come from the business unit whose outcomes depend on that data. The customer domain belongs to the sales director, the product master to the production planning manager, the supplier file to the procurement lead. ‘Ownership’ here means definitional authority, not technical access rights. The data owner must be able to answer three questions: what is the correct value of this field, who is permitted to write to it, and how is quality measured? Until those three questions are answered, any quality project is a cleanup campaign without a caretaker. Back to the Konya manufacturer: order data had no owner. Sales, logistics, and finance each populated the same fields according to their own local convention. Once ownership was assigned, consistent entry rules were written and held within two weeks. Nothing else in the technical stack changed.With an ownership model in place, a quality programme becomes meaningful rather than ceremonial. Quality is typically measured across four dimensions: accuracy, completeness, consistency, and timeliness. These four dimensions do not carry equal weight in every company. For a cold-chain logistics operator in Izmir, timeliness is a survival question — delivery time data that is sixty minutes stale causes direct revenue loss. Consistency in customer address formatting is, for the same company, a secondary concern. To calibrate a quality programme correctly, each data domain needs a ‘quality dimension weight’ assigned and that weight needs to be tied to a business impact. A practical starting point is a weekly automated control report pulled from existing ERP output, built together with the data owner. The field observation that matters here is this: the majority of mid-size Turkish companies either do not measure data quality proactively at all, or do so only retrospectively when a complaint surfaces. Proactive quality monitoring — where the alarm fires on smoke, not fire — is what separates a real programme from a cleanup cycle. A data warehouse or specialised tooling is not a prerequisite; the ERP’s standard reporting module is enough to begin, provided the thresholds were written with the data owner in the room.The third pillar, the data product, is still underused in Turkey but is appearing with increasing frequency in enterprise ERP transformation discussions through 2024. A data product is a data asset packaged for a specific use case, with defined quality thresholds, a named owner, and a predictable delivery contract. The difference from a classic data warehouse is this: a data warehouse stores, a data product delivers. A mid-size pharmaceutical distributor in Ankara has defined separate data products for its sales team and its finance unit: one is a weekly regional sales performance summary, the other is a supplier-level payment cycle report. Each product has an owner, a service-level expectation, and a refresh cadence. When the sales team opens their morning view, they can rely on the data being no more than two days old. The technical infrastructure behind that reliability is not complex — automated extraction, a simple transformation, a timestamp check. But without the ownership definition and the delivery contract, the exact same technical setup produces just another report, not a data product. With the EU AI Act formally adopted in April 2024, a further dimension is added for Turkish companies operating in EU markets: for high-risk AI applications, the quality provenance of input data is now entering audit scope. The data product approach provides a natural foundation for that documentation obligation, because quality thresholds and ownership are already recorded by design, not reconstructed after the fact.The real obstacles to building these three pillars in Turkey deserve honest attention. The first is that an ownership conversation quickly becomes a political one. ‘Whose data is this?’ slides into ‘who holds power over this data?’ and departments resist. Managing this requires framing ownership as accountability, not privilege: being named data owner means being the first point of contact when quality breaks, not receiving additional authority or resources. The second obstacle is the absence of realistic quality thresholds. A KOBİ operating in Turkey cannot and should not aim for perfect quality across every ERP field. Treating every field as equally important is functionally the same as treating none of them as important. Prioritisation is the discipline, not comprehensiveness. The third obstacle is IT team capacity. In most Turkish SMEs, a one or two-person IT team cannot carry proactive quality monitoring as a daily operational task without automation support. That support is legitimate to seek — from platform tooling or a solution partner — but the sequencing rule still applies: define the owner before automating the check. Automating a quality control for a data domain that has no owner only produces faster confirmation of the same degradation.What does a practical start look like on a Monday morning? First, list the five most business-critical data domains in your company — sales orders, customer master, product definition, supplier record, and stock movements cover most starting points. Second, write one name next to each domain: who in the relevant business unit is primarily responsible for keeping this data correct? That name cannot be an IT staff member. Third, schedule a thirty-minute meeting with each named owner and ask one question: ‘What is the acceptable quality threshold for this domain, and how do we measure it?’ Record the answer. Pull a single weekly control report from your ERP. Fourth, review that report in the same meeting for six weeks. If ownership engagement holds across six weeks, the core of a quality programme is operational and you are ready to define your first data products. The sequence looks simple. But had the Konya food packaging company run these four steps before opening its first technical cleanup sprint, the second sprint would not have been necessary. Most data problems are organisational before they are technical, and any Data First initiative that buys tools before acknowledging that fact will accumulate infrastructure without accumulating results.
This article was originally published in Turkish by Gökhan MERCANOĞLU on July 1, 2024. The English edition has been reviewed and edited by the author.