In this blog, I will be discussing some distinct types of data involved in feedback. The types that I will be covering are as follows: 1) structural; 2) event; 3) quantitative; 4) contextual; and 5) systemic. In 2014, I recall reading a number of blogs about three types of data: prescriptive, descriptive, and predictive. There was a data scientist apparently on tour lecturing extensively about these three types. I don't recall the individual's name. Well, prescription, description, and prediction are actually "applications" of data rather than data types. In my own blogs focused on prescriptive and descriptive data, I made some effort to describe the nature of the data - particularly its organizational role - since I recognized that the conversation was mostly about role or application. However, in this blog, I will be discussing actual types of data: e.g. boolean, byte, int, double, long, char, and String are types of data. Perhaps some readers that program are comfortable describing objects as data. Certainly the five types that I will be describing should be considered objects in relation to the example below.
I will be using a single example throughout: a technician, Rose Reliable, has submitted a stack of completed work orders to administration; unfortunately, the server that normally handles the record-keeping went up in flames. Jerome Pensive is responsible for constructing a new data system from scratch primarily to help the company make better decisions but also to determine proper compensation levels.
Overview of the Five Types of Data
#1 Structural - Pensive normally receives stacks of completed work orders from all sorts of staff in many different departments. Pensive decides that - apart from handling the submitted records - he has to start maintaining a record of the source of the records. For many companies, the source might be the department and name of the person submitting the documents. Pensive has something more elaborate in mind. He wants to keep track of the setting that brought about the data - details pertaining to the "environment." He wants to know the locations that Reliable worked at, handling which types of appliances, and during what hours. Since Reliable is one of the few female technicians working for the company, Pensive is interested in what work conditions seem to contribute to the following: high levels of production; superior quality; and excellent customer satisfaction. He reasoned that some male technicians might exhibit less teamwork when working with Reliable; this can adversely affect her stats. Although Reliable might be affected by gender bias and harassment, Pensive reasoned that all workers probably have settings, situations, and conditions where they operate best. Consequently, Pensive would like to start keeping "structural data" about the entire staff.
There isn't necessarily a single way to form structural data. Consider the relational-neural structure that I discussed in an earlier blog as shown below, which clearly can hold a lot and all sorts of data.
Reliable/destination/324 Fielding St./basement/Lennox/High-Efficiency/3500=offline
Reliable/team leader/Samuel Peters/assignment/time=20:00-21:00
#2 Event - In terms of the actual work orders, there is a need to extract production metrics. If only the documentation itself said something like, "Hey, this is a production metric." Alas, specific criteria need to be established in order to establish what is or is not something. I am describing an ontological exercise. Pensive notes that Reliable, like most of the other technicians, has preferences in terms of what work gets done, under which circumstances, and using parts from which suppliers. There are certain "combinations" that the company frequently promotes. The company is aware that certain combinations seem to work poorly, resulting in complaints. Pensive decides that the new system has to maintain a record of combinations in terms of the parts used and services provided for which appliances. In effect, Pensive wants to work towards a system that evaluates the judgment and level of skill of the technician - along with his or her willingness to take directives. He therefore intends to collect "event data" pertaining to each completed job. Event sequences can be used to record combinations.
In my own projects, event data is simply made up of fieldless and non-relational strings as shown below. Again, this is not necessarily the only way to form the data. An argument can be made that event data seems similar to structural - differing only in application - and maybe the use of "[ ]" rather than "/" parsers. Such an observation would be fundamentally incorrect. Structural data contains information about setting while event data is concerned about the existence of conditions. The data types do not "contain" the same kind of information: the setting is unlikely to represent criteria leading to scorable events - although I suppose sometimes it might.
#3 Quantitative - So far, none of the data that Pensive will be collecting is quantitative in nature. The attachment of quantity to something does not mean that the quantity fully or even slightly represents both structural and ontological event data. It is a bit like attaching a price to stock that, in the trading days to follow, might fluctuate dramatically even if the company itself remains essentially the same. Nonetheless, quantities can be attached to structures and events for example in relation to a formal process of performance evaluation. After using criteria to set the defining events, a method of value attachment becomes possible. Pensive decides to use an elaborate scoring table so each type of event or sequence of events results in a particular score. In this way, he gains access to a running total of important operational metrics or "quantitative data." While quantitative data might be the most familiar to most people particularly data scientists, it represents a small fraction of the data from the three types mentioned up to this point.
A table can be used for the quantitative form. A table externally defines the meaning of data - making it seem that only the numbers make up the data. But internally defined quantitative data might be expressed more like the contents of an .ini file. (The use of brackets is my own practice in order to reliably perform rapid tests: e.g. if(line.indexOf("[quoted_cost]") != -1) preventing a false-positive if the line contains something like quoted_cost_today.)
[quoted_cost] = 89.95
[completed_charge] = 92.50
[cc_charge] = 92.50
#4 Contextual - Assume that Pensive has successfully implemented the new data management system. He has large amounts of data pertaining to each worker, the work he or she has performed, and in what workplace settings and circumstances. One morning he receives a call from Reliable's manager: it seems that Reliable has been absent on a number of occasions during the busy season. The manager would like some stats to get a better sense of Reliable's overall performance. Pensive has an enormous amount of data. Although absenteeism is at issue, it is a fair bet that the manager wants something more elaborate than attendance data. What data makes the most sense to send? It is illogical to send everything. However, it would be unfair and non-constructive to provide data about Reliable in isolation - for example, not comparing her to coworkers. Consequently, to some extent, Pensive is responsible for setting the parameters in which decisions will be made. I call the fourth types of data "contextual data," which is the data that is sent to address "in context" a particular request. This might not strongly resemble the data that is gathered, forming the underlying basis of the response. For example, I consider data returned in plain language a type of contextual data since language itself can serve to set the context of interpretation. Context is something that is attached to the base ontology and environment similar to the attachment of a quantity. Contextual data addresses the question, "What is this supposed to mean to me?"
The contextual data form shown below might not make sense without some preamble. Assume that a [325C] event is thrown after a job is successfully completed. With the [325C] criteria satisfied, there are a number of comments possible in different contexts. Contextual data is a tangible concern rather than something I just invented for this blog. The data in a computer is destined for two entities: humans and computers. Within these two groups, there are major partitions that prevent the direct conveyance of meaning. It would be a mistake for instance to directly transfer data from an HRMS to a GIS; from a GIS to people in accounting; from logistics to the board room. The English translation is as important as the original German manuscripts, one might say.
[325C][hr_type] Excellent work
[325C][time_type] 0.5 hours
#5 Systemic - I call the fifth form of data "systemic data." Pensive maintains data resources regardless of whether or not he expects to receive calls from managers. In any large organization, there are many potential data recipients or clients. Thinking of the organization as a system, the signals that are sent to different parts can trigger particular responses. Data that is sent to the right places and posed in the proper context might lead to more desirable outcomes than data sent to the wrong places in bizarre contexts. A system is a living thing. Organizations are alive. People are moving around. Their roles change. Departments are constantly adapting along with functions and resources. The marketplace is dynamic with competitors springing up constantly. What data to send, where, and in which contexts are questions that can never have the same answers for long. I would compare the established connections within organizations as cultural niches of migrant populations. The question of data relevancy really depends on this perpetual process of internal reconstruction. Systemic data is organizational data in a literal sense although contextualized in informational terms.
I consider it difficult to paste the contents of anything resembling a system here. But I offer a few lines of how data formed by the handler [hr_type] might be distributed to HR, accounting, and Reliable's manager.\
Role of Feedback
It is common in relation to "systems" to emphasize the following basic pattern: inputs, processes, and outputs. Businesses talk about production systems where raw materials are processed into finished products. In environmental studies - reflecting my background - a system also involves feedback. The processes of an organization might change according to feedback. In an example a professor once shared with me, exposing water to heat can cause the water to boil; the water responds to energy by becoming more complex. (Consider this more of an analogy than conceptual explanation.) In society, social structures may have emerged in response to hostile natural and man-made environmental conditions. In business, restructuring is common in the face of changing market conditions. Transformations also occur within the workplace - for example, after the introduction of computers. For individuals given performance feedback, there is often an expectation of behavioural restructuring.
I suggest that data types for feedback can affect both the message being conveyed and the dimensions of any response. Consider a scenario where the data structures cannot convey meaning adequately to ensure an effective response. For example, perhaps the company is incapable of expressing seasonal fluctuations in labour demand. In order to address over- and under-capacity, it is necessary for specific individuals in operations to know where labour is needed, when, doing what specific jobs, to achieve what particular outcomes. What if the company only kept sales data? Sales data provides little guidance on labour requirements except for the broadest trends. There are opportunities in feedback to support structural initiatives for organizations assuming there is adequate sophistication in the types of data used.
I believe that in the rush to incorporate changes to workplaces, it has been tempting to use computers to handle processes in the same old ways. Traditional data forms reinforce patterns of behaviour and existing conventions. I am referring primarily to externally-defined data, often quantitative - for example, the sort that might be found on a relational database. This type of data is not necessarily part of a coherent indigenous "system." The use is merely customary or prescribed. Production might be unaffected by such data. However, feedback would likely be impaired. If an organization has to adapt to challenging conditions - if it is already losing its war - efficiently performing the same behaviours can lead to certain defeat. The cornerstone of organizational adaptation is its data: not just what it collects but what it "can" collect - what the data is capable of conveying - through different structures.