Sick Pay: Systems, Objects, Execution and Procedure

For those of you who don’t know or just wondered generally, I am not a full-time student but part-time. I actually work (almost) full-time for a non-for-profit charity that specialises in rehabilitation. It’s actually quite a rewarding job that I happened to fall into whilst moving back to Devon to concentrate on my PhD.

I rarely mention it, mainly as it isn’t of interest to anyone and I doubt anyone will be bothered to read the goings on of what we do as an organisation. However whilst working here for a number of years, alongside blogging about academic work in my spare time, examples always crop up that elucidate the complexity of theory I am reading at the time. I think it is time I shared these examples as it helps me and others. Using real examples also adds a concrete flavour that you are unable to find with abstract examples.

(Especially now, considering the usual round of blog-squabble recently, here, here, here and here pertaining Whitehead and OOO. For what it’s worth, I don’t believe this to be the fault of the people involved, but the properties of the blog-medium itself. There is usually plenty of room for narrowcasting and instantly posting responses; not much for listening and absorbing.)

The relationship between systems and objects is above all complex. If you seriously uphold the idea of an Unit Operation as Ian does, you start to see why. One cannot discount relational systems by all means, they are valuable and worth paying attention to; however there are limits to their flow and meandering properties as an ontology, that fail to correspond with reality. Here’s one example that I’ve noticed.

At work we have many systems in place to do all manner of charitable events and fundraisers, some systems are relied on, or considered as more critical than others;

  • A system for volunteers to be reimbursed by cheque which is reliant on managers filling a financial Word document, which is emailed on Outlook express, administered on a financial software program, that allocates money from an assigned financial expenditure code.
  • Two huge NTC servers in London that hold all of our data, coupled with the CITRIX login system that allows our office in rural Devon to log in and access those our files and programs on a 1.0 GBPS connection.
  • A payroll software system programmed on SQL that requires the generation of a monthly XML file, which is sent electronically as a universal instruction to banking systems, so that employees and reimbursed volunteers are paid on time.
  • The production and amendment to an Excel spreadsheet that calculates holiday entitlement, including bank holidays. It also calculates when an employee can take that holiday entitlement off.
  • A photocopier that sends packages of data representing the numerical volume of its toner cartridges to a leased company, who in turn posts a replacement when the volume is low.

In all of these cases, common sense tells us that these are systematic procedures not objects. They contain objects for sure, pulled apart and related to in different ways; NTC servers bleep remorsefully hundreds of miles away, SQL databases allow reports to be made on it from any angle, liquid magenta ink is pulled from a nozzle and spread laboriously onto a colour A4 photocopy.

The point OOO makes is that each object or unit, is unified as one independent from its interior and exterior relations. Each of the mentioned systems are worth a shout in comparison, but lets consider one more. Sick Pay.

Sick Pay is important because as a society, the historical legal standing view (considering they can afford to do it) is for an employer to look after their employees when they sick short-term or long-term. This can be done a multitude of ways, but above all there needs to be an algorithmic system in place to process those employees who are sick. If you are sick for 4 months you will receive ‘X’ amount of months full pay and ‘X’ amount half way until such time that the system decides to stop. Until the employee is sufficiently ill, an algorithm is built to calculate at any one time, the amount of sick pay delivered.

But the system has to be built to do this, even if it only exists in the minds of the executive management and the employees. Above all, it has to have independence as a system, otherwise if anyone decides it can be changed, it is not the same system as before and it is a different algorithm. (You cannot actually even do this according to employer law in this country, you have to launch a consultative discussion process; two more systems that ground the current Sick Pay one). Every employee who earns enough to pay National Insurance can rely on another system, Statutory Sick Pay, which is Government system.

Even if the system is an unfair biased one that fully supports an ideological position, it is still not reducible to it. It has an intrinsic logic that only the system can release in the form of a result. The result may not be fair, but the formal Being of the algorithm is independent regardless of the change in individual employer, company name, and death of employee or even a change of Government. We often praise systems that work when they are ‘meant’ to work, but it only works if it relates to us in a pleasing consistent way. In fact it does the same when it has bugs or works inefficiently; it just does what it does. The algorithm proper has no meaning, it is just procedurality.

For me, this single reason explains why a wholly relational system cannot account for discrete entities. Systems exist, but it is the inner unity of the execution that is the object, not the other way round. This is clearly important for Ian as well.  He describes in Process vs Procedure;

“The mismatch between process and procedure in philosophy exemplifies a more general confusion in the world at large. When the topic of “procedure” arises, it’s usually met with scorn and distaste, understood as an established, entrenched way of doing things […] But such a perspective is wrong for two reasons. For one, it reeks of correlationism, and relegates process and procedure to the realm of human culture alone. But for another, it mistakes outward processuality for inward procedurality.” p7

The important thing to consider is that for Ian and Levi, procedure is behaviour, and what we view as process is only procedural. I’m not entirely sure whether Ian’s procedure means exactly the same as the way I use ‘execution’, I can only presume it must be. Ian of course terms operation as taking one or more units and executing a transformation on it/them. Famously, dodging traffic is an operation, brewing tea is an operation. This operation can only be executed on a number of other operations that build up the units needed, such as the construction, packaging and fiscal operations of getting a teabag into a kitchen cupboard, or the operations of a piloting a manual transmission.

This presents the problem of reflecting agency away to a primordial flux outside essential entities; the independence of the thing is relegated to a ‘somewhere else’ and fails to take account of the discrete independence of execution embedded within, on and around the ontological workbenches of metaphysics.

One thought on “Sick Pay: Systems, Objects, Execution and Procedure”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>