Insight

[Lecture] What Do We Want from AX?

IT DAILY ·

박현우 서울대학교 데이터사이언스대학원 교수

✦ AI Summary

AX is a shift from the DX-era model in which people entered data to match system formats to a model in which systems read traces of people's work and turn them into structured data.

The writer argues that chatbots, meeting summaries, and document-writing assistance alone may leave old form-filling and repeated input intact, keeping AI at the level of sentence polishing.

The starting point of AX is to examine procedures such as seals, signatures, and repetitive reporting, remove unnecessary steps, and convert documents into data so that AI can reduce labor that people used to do by hand.

[Lecture] What Do We Want from AX? is an article written by Professor Park Hyeon-woo of the Graduate School of Data Science at Seoul National University. The theme of the first installment (the August issue) was "AI models: How should we choose?" and the theme of the second installment (this issue) is "What Do We Want from AX?"

The article argues that, in order to understand today's AI Transformation (AX), we need to trace back the history of enterprise computerization. As a representative case to explain this, it turns to SAP's R/3.

SAP is a German software company, and SAP's R/3 was released in 1992. R/3 was ERP (Enterprise Resource Planning) software that integrated accounting, HR, production, purchasing, and inventory.

R/3 spread to companies around the world by enabling tasks that had been run separately to be handled in a single system. As a result, it helped drive the shift from companies centered on paper ledgers and verbal reports to data-centered companies, and became a symbol of Digital Transformation (DX).

During Digital Transformation, an implicit promise took shape, and that promise remains valid today. Systems accept data only in predefined screens and predefined formats, and computers have difficulty handling ambiguous reality. For that reason, turning reality into structured data falls to people, who must not only do their work but also break its results back down into a form the system can understand and enter them. This also creates a structure in which, whenever new work begins, one must learn not only how to do the job well but also how to dismantle it into a form the system can understand and input it.

This structure appears in many work settings. After a business trip, employees must scan and attach supporting documents, select expense items in a tabular entry form, and type in numbers and expense categories. When purchasing goods, they must also verify the relevant information and enter each required field one by one, and they cannot proceed to the next step in the input window until all required fields are filled out. The writer repeatedly encountered similar cases while entering research achievements and personnel-related documents at a university, and had to re-enter information that was already located elsewhere. There were also frequent cases in which, after clicking the submit button, a notice about missing required fields appeared, and the existing entries were erased during the return to the previous screen after that notice. Even necessary information was treated as nonexistent if it was not in the location the system required.

This is not an exceptional problem with a specific system. It is a common pattern across the overall way work has been done since Digital Transformation. The time spent on actual work and the time spent entering the results into system fields were separated, and actual work and system input turned into separate forms of labor.

The article points out the mismatch between the removal of paper documents and the persistence of procedures. When a seal is required, an image of the seal is created and inserted into the document; when a signature is required, a signature image is added, the file is reconverted to PDF, and then uploaded to the system. The screen-based reproduction of attaching paper receipts one by one and the digital equivalent of gluing paper also repeated. It adds that over the past 30 years of Digital Transformation, organizations accumulated large-scale data, but the labor and procedural formalities required to make data neat were not eliminated.

Then, amid the spread of AX as a hot topic in 2026, adopting chatbots, summarizing meeting minutes, and helping with document writing are cited as starting points for AX in many organizations, and the usefulness of chatbots, meeting-minute summarization, and document-writing assistance is also mentioned. However, if people continue filling out old forms, AI's role may remain limited to polishing sentences. In that case, the result is merely the addition of a convenience tool on top of an old process, and that limitation is offered as the reason for later remarks that not much has changed after a few months.

The writer defines AX as a shift in business processes and contrasts DX and AX by the direction in which information flows. DX is described as a method in which people generate data in a system format, whereas AX is a method in which people work in their usual way and the system reads the traces of that work and converts them into structured data. As an example, the writer points to the fact that the system is the one doing the organizing after meeting speech, notes, and receipt photos are captured. Figure 1 shows the difference in the direction of information movement between DX and AX, and the caption to Figure 1 presents DX as a method in which people generate data to match system forms and AX as a method in which the system reads people's work and accepts it as structured data.

The writer argues that the labor of finding blanks and entering them should be performed by AI. A metaphor of soft Lego is used to explain this change in direction. Existing software is compared to hard Lego that can only be joined when specifications match; connections between systems require interface alignment, and in connections with people, input forms were created to make people conform to the specification.

As the background for this shift, the writer presents LLM. LLMs have different characteristics from existing software, and the article explains that they can extract needed information from unstructured materials such as scanned contracts and meeting recordings, and then convert that extracted information into a fixed structure. In this sense, a soft piece that fills the gaps between rigid systems has appeared, and Figure 2 presents the soft-piece metaphor.

The condition for connecting existing software is that specifications must match, and traditional software shows the characteristic of the same input producing the same result. By contrast, LLMs can connect information across different formats, but that flexibility comes with the possibility that errors are mixed into interpretation results. For that reason, AI-based processes require human review and approval steps, and there is also a need to distinguish between verification and input.

In the efficiency comparison, the article says that it is better for AI to draft documents and then have a person check for missing items than for a person to search for and fill in numerous blanks from the start. Accordingly, the redistribution of roles is presented as machine organization and human responsibility. In the writer's view, the starting point can be working from the conversion of documents into data.

The proposed starting point is converting documents into data. Documents are a form in which data is packaged for people to view easily, and that packaging includes the cover, table of contents, font, table borders, and seal space. The purpose of this packaging is to accommodate human vision and administrative procedures, but when machines use documents, two problems arise: the need to dismantle the packaging and the need to infer the meaning contained in it. For that reason, the recommended format for AI work organizations is one in which titles, item fields, and numeric structures are visible, and markdown and JSON are given as examples. In the AI era, the concept of a document needs to be redefined, and the desired structure is one in which data is the original source and human-readable documents are outputs generated from that data when needed.

AI can read PDF and word processor files, but being able to read them is not the same as reading them reliably every time. To interpret a document, one must infer whether table borders are decoration or data structure, whether bold text is a heading or merely emphasis, and which item a merged cell belongs to. When summarizing a single document, this friction has little effect, but when extracting amounts and delivery dates from 500 contracts and passing them to the next system, the impact becomes large. A small error that occurs occasionally in an individual contract becomes a bottleneck that holds up the review staff.

Early web documents also had the characteristic that content and appearance were mixed within a single file, and the page had to be rewritten to display the same content on a different screen. Later, the principle of separating content into HTML and appearance into CSS became established, making it possible to reuse a single piece of content for PC, mobile phones, and print. This is not a matter of document decoration technology, but of the conditions for scalability that make repeated reuse of the same content possible. In this sense, the same principle is needed for business documents in the AI era.

AI can be used for the task of dismantling existing document packaging. AI can handle the first pass of extracting contract amounts and delivery dates from contracts from the past 5 years, and it can also handle the first pass of organizing scattered work records by fixed categories. People are responsible for reviewing and approving the AI results. In a previous article, the writer argued for the need to design AI token costs. However, document format is also a factor that affects AI cost. The more complex the form and the more uneven the structure, the more AI interpretation work increases, and if errors increase, people must recheck the results. Cost leakage exists beyond tokens. Costs are also incurred the moment a person looks at the document again to decide whether to trust the result. Clean data can move immediately to the next task, but dirty documents delay people by preventing them from moving on to the next step.

The writer said that the starting point of AX is not tool adoption but questions about procedure. The need for a seal should be reviewed, and the purpose of what it is meant to confirm needs to be identified. If the purpose of the seal is identity verification or a record of approval, it can be replaced by a system record of the approver and the time of approval. The method of attaching an image of the seal and then uploading a PDF does not strengthen the rigor of confirmation. The same principle applies to reports. If records are already accumulated in the system, the need to repeatedly copy the same numbers at the end of each month and rewrite them in report form should also be reconsidered. The goal is to preserve judgment and responsibility while reducing the repetitive actions needed to prove that judgment was made.

As examples of work scenes in organizations where AX has taken hold, the article presents the following: after a meeting ends, decisions and follow-up tasks are organized by person in charge and a person checks for incorrect entries; after returning from a business trip, a settlement draft is generated based on receipt photos; before various reviews, instead of presenting dozens of blank fields, records from the past few years are organized by item and only missing information is asked for; monthly reports are generated naturally from work records accumulated over the month rather than becoming an exercise in re-collecting materials. Imagining these scenes first makes it clearer what technologies are needed, and the criterion for evaluating new tools also becomes whether they reduce the work people have to enter. The comparison standard is whether they simply replace sentence writing while preserving old input procedures.

In this regard, the article recalls that companies learned a costly lesson during the ERP boom of the 1990s, and that the success or failure of ERP depended on business process redesign rather than software purchase. In the 1990 Harvard Business Review article "Don't Automate, Obliterate," Michael Hammer argued that useless procedures are not something to be tweaked a little for convenience, but something to be eliminated altogether. Hammer's choice of obliterate, a harsher term than "redesign," shows that unnecessary procedures should be removed before they are automated.

The starting point of AX is developing AI agents that speed up the attaching of seal images, but the goal is to eliminate the sealing procedure itself. If, 30 or so years ago, change took place in the direction of adjusting work so that people followed the system, now the transition is toward making the system better accommodate people's work. Accordingly, the goal after AX is also shifting away from improving human use of the system and toward reducing inconvenience for system users. The speaker's point is that AX aims not at accelerating existing procedures, but at eliminating procedures and adapting systems to humans.

Source: IT DAILY · Park Hyeon-woo
Original: https://www.itdaily.kr/news/articleView.html?idxno=241307

References

This article was produced with the help of an automated content generation algorithm.


Source: IT DAILY

View original

This article was summarized and organized by BizCrush based on the original article from IT DAILY. For exact quotations and full details, please refer to the original article.