Pavlos Hatzopoulos
First Event: The mobile phone of an assistant manager of Cosco subsidiary, Piraeus Container Terminal (PCT), rings while he is guiding two journalists around Piers II and III of Piraeus port. The assistant manager is urgently called by his interlocutor to solve a crisis. A client company is complaining that its reefer container has been damaged and the goods stored inside are endangered. The container has to be emptied of what seem to be bananas, and reloaded to another, unimpaired reefer. The assistant manager gives instructions to his interlocutor over the phone of the exact location within the terminal yard where the operation should take place. There is insufficient space at the current location of the damaged container for it to be stacked at the optimal angle so that its cargo can be emptied without the bananas spilling out into the yard.
Second Event: A regular passenger car is circling around the neighboring container terminal operated by the Piraeus Port Authority (OLP). Its passenger makes a stop below a quay crane where a party of four – an OLP trade unionist and three researchers – are standing. The passenger greets the OLP trade unionist and after a brief colloquial conversation, he gets back to his car and leaves. As the trade unionist confides to the researchers, he is looking for a lost container. The container seems to have moved between the Chinese operated PCT and Greek operated OLP piers, and no one is certain about which side it has been stacked.
These events do not register as usual in related event logs recorded by the Terminal Operating Systems (TOS) employed in the Piraeus Container terminals. These TOS profess to offer an all-encompassing handling of the totality of planning, operational and monitoring work performed in the terminals. CATOS, the TOS platform used by PCT and developed by Korean-based maritime logistics solution company Total Soft Bank Ltd (TSB), is designed to command and control all movement of machinery, things and people within the space of the container terminal. According to the description of its capacities as presented in TSB’s website: ‘Once you plan berth allocation, human resource allocation, vessel operation and yard operation using CATOS Planning, you can supervise and control the whole operation in real time using CATOS Operation. CATOS Management then will provide analysed reports on its performance to help you with better planning next time. These three modules are shared as one database, therefore, the data integrity can be surely guaranteed’.
The sheer inability of CATOS (or of employed in the OLP Pier) to register the two events described above does not, however, attest to its failure of omnipotently commanding and controlling the mobility of people, things and machines in the container terminal, but instead signals the presence of more complex regimes of control that manage terminal operations.
Investigating such dynamics, it is important to critically reflect on the notion of protocological systems (Galloway) as synonymous with digital networks in general. Protocological control is only one among various organisational logics that produce the complex software regimes that are in place at the Piraeus terminals.
Protocols are central to the control of all information and data exchanges that organise the real-time operation of the terminal. In the semi-automated environments of the Piraeus container terminals, there are several types of protocols that are instituted to govern data flows within the Terminal Operating System and to ensure interoperability with other software systems. Radio link protocols enable data exchange between handling equipment, human agents and the TOS within the terminal. Electronic Data Interchange (EDI) protocols enable the interfacing of the TOS with information and transactions about containers, routes, quality controls, customs procedures and so on that involve the entire user community of the port. In spite of their centrality in managing these data exchanges, protocols are not critical to the organising principle of the software-driven promise of continuously boosting productivity in conjunction with the perpetual optimisation of container terminal operations. These processes are built into the software architectures of terminal operation systems, and their management relies much more on the control of machinic behaviour rather than on the regulation of data flows within the network as a whole.
We have to note, here, that the digital networks in the terminals have different topologies to other types of digital networks using the internet. CATOS is designed, for instance, as a decentralised system with a few central nodes and limited access to authorised users only. These central nodes include a radio server, a database server, a dispatcher server and a communication tower channeling radio messages. Apart from their privileged position within the CATOS network’s architecture, these nodes play a critical role in the processes that spur the promise for the continuous reconfiguration of the mobilities of things, machines and people within the terminal. These nodes are where all operation data sets are stored and are then mined for producing performance analytics and subsequent proposals for the optimisation of terminals operations. The main anxiety haunting optimisation models is machinic idleness.
The ongoing research of IT companies involved in the container terminal business is increasingly driven towards data mining. Total Soft Bank, for instance, has been experimenting recently with the utilisation of process mining as an optimisation method offered to terminal operators as an additional service. Process mining, in comparison to other data mining techniques, is focused more on events and timing rather than the clustering of containers by cargo type or operator and is based on the mining and processing of detailed event logs registered by the TOS.
The embeddedness of process mining in terminal operations is not based on a series of flexible hierarchies, but on rigid hierarchies of machines, things and people. In an excerpt from a NAVIS report titled ‘The Road to Optimization’, such hierarchisation of terminal operations becomes evident: ‘For most terminals the key to achieving higher productivity is not to operate equipment faster, but to make the operation more consistent, with fewer delays while equipment is waiting for containers or other equipment’. The minimisation of equipment waiting time is thus prioritised over the acceleration of equipment operation. In this sense, it is equipment that comes first, with (as explained in another optimisation report) quay cranes coming before other types of equipment as the most expensive and the least flexible machinery.
Software regimes, along this line of analysis, are based on a combination of flexible and rigid hierarchisations of events, tasks and processes. Through these different logics of order that are in place in Piraeus, human bodies and labour become appendages to the primary task of the control of machinic behaviour.
Returning to the two events mentioned earlier: How do they fit or interact with these software-driven optimisation models? Both events are paradigmatic of human intervention in container terminal operations at the point of contingency scenarios that existing software systems have not as yet integrated into their algorithmic architectures. But can we comprehend these recurring contingencies when software command is disrupted as instances where regimes of control can be eluded?
Perhaps, surprisingly, the position of human labour within optimisation regimes is marginal. Although all human-machine interactions are recorded and analysed by the two TOS employed in Piraeus, the only usage of this data is related to human resource allocation in the terminals. In both Piers, for instance, the salaries of the workers are not tied to performance: in the OLP side, a rigid wage system ties salaries to the stipulations of the Memorandum agreements between the Troika and the Greek government, while even overtime is remunerated on an hourly basis and within a certain salary ceiling; in the PCT side, the more flexible salary system is tied to a complex system of subcontracting where labour is rewarded on a day shift basis and the remuneration of overtime is contingent upon management decisions.
Instead of merely noting this marginality of human labour, it is important, to trace the figurations of labour (Tsing) that are produced within the regimes of control in the Piraeus container terminals. One such figure that emerges is that of the ‘remote operator’. The remote operator is typically a machine operator – of a crane, a truck, a straddle carrier. Her/his role is that of sustaining the spectacle of the informatised, machine-enabled efficiency of the container terminal. Her/his body thus occupies semi-visible positions that provide a bird’s eye view of the container terminal; confined within small cubicles appended to container handling machines, her/his body is fixed within the cubicle in order to ensure that the machine operates in an optimal fashion.
The ‘remote operator’ becomes the protagonist in a very telling episode of collective rebellion inside the terminal (the only recorded collective rebellion against the labour regime enforced by PCT, based on the prohibition of unionisation and collective bargaining and the use of subcontracted labour). Rebellion is sparked by a machine failure, albeit the failure of an inferior machine. Some PCT workers decide to form a five-member workers’ committee to complain about working conditions. These workers, mainly rail mounted gantry crane operators, are prompted to act as the heating and air conditioning system at the operators cabin is broken. The broken machinic supplement becomes the straw that breaks the camel’s back since, as they claim, their sensitive job is dependent on ‘optimal temperature conditions’.
Although this episode can be inscribed in the framework of traditional labour struggles for better working conditions, it simultaneously exceeds this interpretation. The demand of fixing the heating and air-conditioning in the operator’s cabin is simultaneously inscribed in the discourse of the optimisation of terminal performance, where the workers’ claim takes optimisation to its limits and demands optimisation everywhere.
Another figure of labour emerging in the Piraeus container terminals is that of the ‘gamer-programmer’. The gamer-programmer usually inhabits a desk in the operations department of the terminal operator and s/he is the worker more persistently exposed to the graphical user interface of the TOS. S/he might be involved in vessel planning, or yard planning and so on. These personnel tend to attribute the emergence of contingencies that cannot be handled by the software system to human errors, usually made by remote operators. The remote operator can, however, easily step in to the figure of the game-programmer, assisted by virtual reality training simulators and intelligent remote control stations.
This brief description of some of the key figurations of labour emerging in the Piraeus container terminals only serves to highlight the limitations of imagining social struggle through a human-centric approach. The opening up of militant research to the entanglement of software, machines, things and people as ‘tangled species’ (Haraway) inhabiting the container terminals can be a productive starting point for a research inquiry focusing on struggles against logistical capital. This research direction will be taken further in the next phase of the Logistical Worlds project study of the site of Piraeus container terminals.