When Enterprises Adopt AI, the First Hurdle Isn't the Model—It's the Data Scattered Across Excel Files

When discussing enterprise AI adoption, people tend to ask first: "Which model should we choose? ChatGPT, Claude, or build our own?" But after years of talking with enterprises, we've often found that the first real question isn't about model rankings — it's something more fundamental and more easily overlooked: Where exactly is the company's data? Who knows what it means? And can it be organized in a trustworthy way so that different departments and different tools can reuse it?

Many enterprises aren't actually short on data. Quite the opposite — there's so much data that every department has its own version. There's one copy in the ERP, one in the POS system, one in the e-commerce backend, and another Excel file sent over by a sales colleague; HR, customer service, inventory, and accounting each maintain their own familiar spreadsheets. When it's time to make a report, people first have to gather all the files together, then manually clean up the columns, remove subtotal rows, cross-check codes, and confirm date formats — only then can they start actually answering business questions. The data already exists, yet a huge amount of manual labor is still needed to translate it into something machines can understand and colleagues can trust.

This gap isn't just something we've observed in individual client cases. Statistics related to Salesforce's "State of Marketing" report indicate that 84% of surveyed marketers use first-party data, but only 31% are fully satisfied with their ability to integrate data across sources. These two figures are interesting when placed side by side: enterprises increasingly recognize how important their data is, yet many teams still can't organize data scattered across different places into a consistent, usable whole. 1

A 2026 PwC survey of 767 U.S. operations and supply chain executives reveals a similar reality. 89% of respondents said their technology investments have not fully delivered the expected results; 87% noted that poor data quality has hampered the ability of digital initiatives to create value. This isn't saying every company's data is a mess — it's a reminder that if you buy new systems and set up AI accounts without simultaneously addressing data quality, system integration, and workflow design, investment won't automatically translate into results. 2

So, starting last year, we began investing our skills in a task that may not sound glamorous but is actually critical: helping AI assist enterprises in cleaning and organizing their data. A year later, with the product gradually maturing, we launched AotterClam AI. This isn't about building yet another chat window — it's about helping enterprises organize data scattered across legacy systems, reports, and files into a data foundation that can be governed, kept up to date, and used by downstream AI and BI tools.

Why does talking about AI so often end up stuck on Excel?

Aotter has spent over a decade doing data-related work, and we're familiar with the daily realities of data engineering and data governance. People outside the company may know us starting from AotterGirls, but Aotter's journey — from creative tools and content products, into data advertising and first-party data applications, and now into enterprise AI — has always revolved around the same core issue: how to shorten the time it takes for information to become value. Having worked with user behavior data for a long time in media and ad tech, we know that collecting data is only the beginning. The real difficulty lies in organizing it, defining it, managing permissions and use cases, and being able to keep it updated going forward. 10 11

Discussions about first-party data used to center mainly on marketing and advertising, but they're now increasingly central to core enterprise operations. It's not just about member or transaction data that brands collect directly — it also includes orders, inventory, customer service interactions, and service records accumulated through legitimate, reasonable business relationships. Whether this data can be properly harnessed determines whether an enterprise can build analytical capability within its own operational context, rather than relying every time on vague answers provided by external platforms.

This trend isn't complete just by slapping the label "first-party" on things. eMarketer, citing a 2024 survey, notes that in one survey of B2B marketers, 67% listed data compliance and accuracy as important priorities; another global survey of marketers found that 84% said they use customer, first-party, and transactional data to understand their audiences. These figures reflect specific survey populations and the market conditions at the time — they don't mean every company already has mature data governance capabilities. But they clearly show that enterprises are increasingly concerned not just with whether data can be used, but whether the way it's used is compliant and accurate. 3

We also want to specifically point out that first-party data doesn't mean "data we obtained ourselves can be used however we like." Where the data came from, what was disclosed at the time of collection, what uses are permitted, who can view it, how long it's retained, and whether it can be linked with other sources — all of this must be clearly governed. Truly valuable first-party data is a data asset accumulated through legal and transparent relationships that the organization can continuously manage — not over-collection or unlimited tracking under a different name.

Once we move into the context of enterprise AI, the data bottleneck shows up in very practical ways. Many companies' core systems have been running for years. ERP, POS, warehouse, or order systems may each have their own databases, but there's no suitable API connecting the systems — or even if an API exists, the company lacks the budget, permissions, or dedicated staff to properly connect it. In practice, the most commonly used external output is still Excel or CSV: a weekly sales export, a daily emailed report, or month-end merging of spreadsheets from different departments by a colleague.

Data shouldn't be considered worthless just because it's delivered in Excel format. These spreadsheets often carry years of operational experience — it's just that the table design was originally meant to serve people, not data pipelines. The first row might be a merged-cell title, with actual column headers only appearing in the second row; a single column might contain dates, text, and notes all mixed together; a single sheet might blend line items, subtotals, totals, and remarks. Different departments might even use different names for the same field, or use the same name to mean different things.

For example, "amount" might mean the pre-tax amount, the tax-included amount, the net amount after deducting discounts, or simply the total order amount before refunds are deducted. Tables may all label a column "amount," but summing them up can lead to completely different operational conclusions. Similarly, a row might represent an entire order, or it might represent a single product line item within an order. If the system doesn't understand the granularity of the data, and the order total gets copied into every product row, total revenue can easily be double-counted. These aren't minor glitches caused by AI not being smart enough — they're root causes of errors that can occur in any report or model whenever business definitions haven't been clearly written down.

Since last year, we've been exploring many Generative BI, data lakehouse, and semantic layer solutions. These tools can help enterprises query, analyze, and present data, but most usage scenarios generally assume the data has already been cleaned and placed into an analyzable database or data warehouse. In other words, they're very good at handling "data that's already ready" — they don't necessarily solve the upfront work of inventorying data, cleaning fields, defining rules, establishing relationships, and scheduling updates.

This is a common sequencing problem in enterprise adoption: everyone rushes to see AI question-answering before the data has even been prepared. In reality, data is scattered across systems, attachments, and various versions of spreadsheets, so an implementation project first has to spend time locating data, asking people questions, confirming fields, and then figuring out how to get it all into the same analyzable environment. Traditional approaches often require consultants and system integration teams to inventory data case by case, investing weeks or even longer before a first usable data warehouse can be established. This doesn't mean consultants or SIs have no value — it's that enterprises often need to complete a lengthy round of data engineering before they can even start discussing what AI can do for the business.

Local surveys in Taiwan make this problem even more concrete. The 2025 Manufacturing AI Adoption Survey by the Institute for Information Industry's Digital Transformation Research Institute and the AI Foundation examined traditional manufacturing and ICT industries separately. The report found that among traditional manufacturing respondents, 35.8% had adopted information systems such as ERP or MES, while the rate of cross-system API integration was only 13.2%; 22.7% of traditional manufacturing respondents had reached the AI validation or scaling stage, lower than the 39.1% figure for the ICT industry. This study's sample size is limited — 53 traditional manufacturing companies and 74 ICT companies respectively — so it shouldn't be directly extrapolated as a precise census of Taiwan's entire industry. But it clearly illustrates a structural gap: having systems doesn't mean the systems can talk to each other; having data doesn't mean the data is ready to support AI. 4

When enterprises come to us to discuss data cleaning, a common answer we hear is: "First find someone to extract the data, do ETL, clean it up, and then load it into the warehouse." ETL — extract, transform, load — is indeed a core part of data engineering. However, if every type of report requires a custom-built processing program from scratch, any change in data format requires a rewrite, and bringing in new staff means they have to relearn all the past rules — implementation costs are very hard to bring down. What enterprises need isn't to pretend data cleaning is simple, but to turn the large volume of repetitive, describable, verifiable steps into reusable rules.

So we began asking a seemingly simple question: even though Excel formats vary endlessly, are there still some stable "atoms" of data processing that can be clearly described? How should a sheet be read, which rows should be excluded, what type should each field be converted to, how do you identify a single record, how do you establish a relationship with another table, and how should things be updated when new files arrive? These tasks don't naturally become risk-free just because AI is added, but they can be broken down into definitions, rules, validation, and execution — rather than always relying on some colleague remembering "that's roughly how we used to do it."

After months of research, we organized the recurring processing patterns found in data science and data engineering into a declarative syntax. "Declarative" means clearly writing out the goals and rules — for example: "this column represents the order date," "subtotal rows should be excluded from the line-item detail," "a record is identified by order ID plus item ID," "amount is calculated as the net value after deducting discounts" — rather than leaving behind a manual process that's hard for anyone else to pick up. AI can first analyze an Excel file it's never seen before and propose an initial understanding of the columns, formats, and relationships; a person familiar with the business then reviews and corrects it, and the approved definitions are saved and handed off to a fixed process for handling future files.

Incoming data doesn't have to rely solely on colleagues manually uploading files. If an enterprise's existing ERP can regularly export reports, it can continue using its existing schedule to send Excel or CSV files; if the system has an API, direct integration is also possible. Once an exported file arrives, the system cleans, validates, updates, and loads it into the warehouse according to the approved definitions. According to AotterClam AI's official product documentation, currently listed methods include Excel and CSV file import, API and scheduled synchronization, and automatic processing of report email attachments; the actual available sources, formats, and deployment methods still need to be confirmed case by case according to each enterprise's environment. 5

The core idea behind this design isn't to have AI permanently replace human judgment — it's to put AI's best use at "helping to understand unorganized data and propose candidate rules"; to put business confirmation at "determining the meaning of fields and metrics"; and to hand fixed rules off to a reproducible data pipeline for execution. Done this way, data engineering won't lose stability from having to re-invoke the model and re-guess every time data is imported, and business staff won't need to re-explain the entire table's background every time they run a query.