This article was translated from the original Korean source.

What I Think About When Designing IoT Data and Services

I see designing data and services for IoT as a process of examining and integrating workflows and governance.

When I consider what data to collect, I also wonder whose decisions it will support and what work will follow. I find myself asking who can view it, what criteria guide those decisions, and who is responsible for taking action and checking the results.

I am not a data governance expert. This article shares my thoughts on the work and people’s roles that I find myself considering when designing IoT data and services.

Even when defining data points such as temperature, operating status, and usage counts, I first picture the situations in which those values will be used. The information that needs to be connected differs depending on whether a field operator needs to check the equipment’s condition, a service representative needs to investigate a cause, or a product manager needs to assess whether an improvement has been made.

Connecting data to decisions and actions within the context of customers, products, and field conditions, and making it possible to check the results: that is what I consider the core of IoT data and service design.

Start with the Work That Will Use the Data

Suppose, for example, that an abnormal temperature is detected in a piece of equipment.

The field operator wants to know whether it is safe to keep using it. The service representative needs to determine whether settings or the operating environment are contributing factors, or whether a component needs inspection. The product manager may look into whether similar problems occur in products with the same configuration.

Even when looking at the same measurement, they are likely to have different questions. Reviewing the product model and settings, operating history before and after the symptom, installation environment, and recent maintenance records together may help answer those questions.

So when deciding what to collect, I also write down these questions:

• Who will use this data to make what decision?
• Where is the product, customer, and field information needed for that decision?
• Under what conditions does the next task begin, and who takes it on?
• What confirms that the action has been completed?

I try to use these questions to narrow down the scope of information to collect. Examining changes before and after a failure will likely require earlier measurements. When considering maintenance timing, I would want to look at cumulative usage alongside the date of the last component replacement.

Think in Familiar ERP Business Terms

One way to explain these relationships is through the business functions commonly used in ERP: order management, production planning, purchasing and inventory, production and quality, shipping, and after-sales service. Here, I use them as a shared vocabulary for describing the work.

This table provides examples for thinking about the connections between each business function and IoT data. The actual sequence of work and scope of responsibility vary by organization.

Separating business functions into a table helps establish the overall scope. But when I think about how data is used, I am curious about the connections between those functions: where a task waits when it is not ready, where it returns if it fails inspection, and which records people revisit when investigating a problem in the field.

The full diagram below captures these relationships. I want to follow the work stages, branches, rework paths, and information connections together.

View the full diagram at a larger size · Original Graphviz DOT file

Solid lines indicate workflow, blue dotted lines indicate information connections, orange dotted lines indicate rechecking and rework, and pink dotted lines indicate improvement reviews. This is a conceptual diagram explaining relationships between tasks; it does not represent the current implementation or imply that every stage is automated.

Rather than reading every line at once, I would like to break the questions down in this order:

1. Customer requests and product and production criteria: How do customer requests feed into product configuration and production planning?
2. Material availability and task execution: How do we distinguish work that can proceed with available materials from work that must wait? Once purchasing or in-house assembly is complete, which tasks need to be checked again?
3. Inspection and dispatch: If a product fails inspection or the links between the customer, installation site, and product are incorrect, where should these be checked before proceeding again?
4. IoT operations and after-sales support: When investigating an anomaly in the field or a customer inquiry, how can product, production, and operating histories be reviewed together? Which records should be updated after maintenance or replacement?
5. Follow-up and improvement: Where are the results of an action recorded, and how can they inform a subsequent review of the product or production plan?

Following these connections may reveal not only where data is collected, but also the work and people waiting for that data.

I try to identify how data can be used within these business functions. Usage history can provide a basis for considering maintenance, and recurring anomalies can be a starting point for a quality review. This naturally leads to the next questions: what information should be passed along, and what will the recipient use it to decide?

The Context I Want Alongside the Numbers

The outcomes customers expect, the functions a product provides, and the conditions in which it is actually used are all part of the background needed to interpret data.

The same status value can be interpreted differently depending on the environment and purpose of use. That is why I also want to understand the difficulties customers experience, the product’s characteristics, and conditions in the field.

When designing a service, I try to start by identifying who understands this context. I look at which tasks require access to information held by the people who speak with customers, understand the product, and support the field.

This also leads me to consider who should see which information. I want to work with the people responsible to clarify what information their work requires and who manages it.

I also think about how circumstances change over time. Could today’s information cause us to misunderstand a past event? What records should we keep to understand the circumstances at the time?

Who Takes on the Next Task?

As I follow the workflow, I wonder what happens after someone checks the data: whom they should ask when further investigation is needed, and who will take action.

This is also where I connect these questions to governance: agreements about who views information, who makes decisions, and who takes on the next task. I would like to start by discussing questions like these with the people responsible:

• Who needs to see this information?
• Who decides whether action is needed, and what information informs that decision?
• Once a decision has been made, who takes on the next task?
• Who checks whether the issue has been resolved successfully?

The person who views information may be different from the person who changes settings. These are difficult matters to decide alone, so I try to listen to the people who actually do the work and reflect their perspectives in the design.

From Detecting an Anomaly to Checking the Results

Let us think a little more about the hypothetical temperature anomaly mentioned earlier.

Suppose the person receiving the alert has checked the measurement and operating environment. If further inspection seems necessary, whom should they pass the issue to? What additional information would the person performing the inspection need?

Questions remain even after action has been taken. Has the condition actually improved? How long should it be monitored? Who can confirm the result? I would like the service to support this sequence of questions as well.

In this process, I look at whether work moves smoothly between the person receiving the alert, the person making the decision, the person taking action, and the person checking the result. One person may fill several roles, but I want to understand where any gaps remain.

Checking the results may also reveal recurring difficulties or gaps in guidance. If these findings inform product and service improvement reviews, lessons from operations become a basis for the next decision.

What I Try to Check When Designing Data and Services

Alongside a list of data to collect, I try to check whether I can explain the path of decisions and tasks through which that data will pass.

Who needs the information, in what context they make decisions, who acts afterward, and who checks the results. By following these connections, I want to gradually make the necessary data, records, and individual roles more concrete.

Understanding the context of customers, products, and field conditions, connecting data to decisions and actions, and designing so that the results inform the next decision.

That is what I consider IoT data and service design.