Automation means software taking over one step of a job that somebody does by hand today. The step does not vanish: its output is still produced and written down, and only the side producing it changes. Which kind is open to a step is settled by what that step takes as its input: a measurable value, another record the system holds, the image of a document, or the calendar itself.
What automation means: software doing one step instead of a person
Everything in that opening sentence hangs on one word, and the word is step. A job is not what gets automated; one step inside it is: a figure worked out, a record opened, a value brought up to date. An owner may say the word while picturing a program, and the decision belongs far below a program, at the level of a single step. Set the unit wrongly and the next question comes out wrong too, because it turns into a question about which product to buy. Naming the step costs nothing but attention: ask who performs it today, where, and what they look at while doing it. Write the answers down and you hold a list of steps instead of a list of products.
The change that follows is a narrow one. The step comes out the same way each time, because the rule being applied is written down rather than remembered. The same input returns the same result whoever happens to be at the desk, and completion stops waiting for one particular person to be there. Nothing about speed or productivity is being claimed here: who performs the work, and whether it comes out the same twice, are what moved.
Removal is not what happens to the step. Whatever it produced before, it produces still: that output used to come out of somebody’s hands, a spreadsheet or a sheet of paper, and afterwards it comes out of the software. The place where the output is made moves, and the output does not. A reader who pictures steps being deleted will put forward a step that cannot change hands as a candidate, so the distinction is worth holding on to.
One precondition sits in front of all of this. Where the same step is performed by a different rule each day, there is no single step available to hand over; what sits in that place is a decision taken afresh on each occasion. The condition itself is set out in the article on how many programs one job’s record passes through.
The same word is used for different jobs
Type the word into a search box and a different industry comes back with it. That is the word’s own breadth rather than a mistake. On a factory floor, automation describes machinery, a line and a control panel running without a hand on them, and what passes to the machine is physical movement. Inside business software the same word describes a calculation or a record leaving somebody’s hands, and what passes to the software is an entry in a system. Sorting out which sense you are reading about is the first thing to do with any result the search returns.
A third use travels with the Turkish word rather than the English one. In Turkish, the whole management program of a hospital, a university or a public body is itself called automation, so the word names a program and not a step at all. A reader who arrived from a search for an automation program may be holding that sense, which is why the closing section of this piece is built on it.
Behind each sense stands a different decision. Passing physical movement to a machine is a hardware decision; passing a record to software is a data-model decision; using the word for a whole program is a question about scope. Keep them apart and a search result is either about your decision or about somebody else’s, and you can tell which from its opening lines.
One disclosure belongs here before the sections that follow. Algoriel has no hardware or production-line automation work in its portfolio, and every example below sits on the record side of the word. Some jobs do hold both senses at once, as when a machine produces a value that then gets written into a system; only the record half of such a job falls inside what follows. If control panels, sensors and equipment on a floor are what you came for, we are not the people to call, and saying so here saves you the rest of the page.
Recognising the third sense is worth something to you directly. A search for an automation program can turn out to be a search for the system that will hold the record of the work, and in that case the question to answer is where the record will sit rather than which step changes hands.
Software takes a step over in one of four ways
This classification turns on the input, not on what the software ends up doing. What settles the case is the material sitting at the start of the step. Inputs arrive in four shapes: a measurable value, another record the system already holds, the image of a document, or the calendar itself. Turn the axis that way and the diagnosis belongs to the reader: look at your own step, name what goes into it, and the kind it belongs to names itself without a vendor’s feature sheet in front of you.
An axis built the other way round would have collapsed into a feature list, and every supplier writes that list differently. All four kinds share one condition, and it is the condition worth checking first: the input has to be written down somewhere. Where it lives only in one person’s head, the step begins outside the system and nothing in it can be automated, whichever kind it looks like.
The table below sets the kinds beside one another. Its last column describes what a business looks like while the step is still being done by hand.
| Kind | The step’s input | What software takes on | What the business looks like beforehand |
|---|---|---|---|
| calculating | A measurable value describing what the job itself needs | Applying the rule and producing the result | The rule sits in one person’s experience, and the same input can come back with different answers |
| deriving | Another record the system already holds | Producing the second record from the first | A value is entered, then waits to be typed again on another screen |
| reading | The image of a document or a form | Turning a mark or a character on that image into a value | A figure on paper is retyped by looking at it |
| scheduling | The calendar itself; a date passing | Moving the record on to its next behaviour | A value whose date has passed sits on screen, and clearing it is on somebody’s reminder list |
Kinds are properties of steps, not of businesses. Inside one job a figure gets worked out at one step, a record gets produced from another at the next, and the calendar takes the step after that. So the useful question is never which kind are we; it is which kind is this step, asked once per step on the list you wrote earlier.
Reading stays a table row here. Turning the image of a document into a value is a subject of its own, and this piece names the shape without opening it. The other kinds each get a section, in the order the table sets out.
Calculating: when the input is a measurable value
The condition for this kind is that the rule can be written down. If which input produces which result can be set out, exceptions included, software can apply it. A hard sum and an unwritable rule are not the same obstacle: difficulty does not block the work, and a rule that never made it onto paper does.
A second condition sits on the input side. The value asked for has to be one the user can give in their own language. Ask them for something they do not already know and the calculation has not changed hands; the step has only moved, and the screen has turned into a form. It looks built and it is not.
The misreading to avoid here is looking at how complicated the arithmetic is. A long calculation does not become something that cannot be handed to software just because it has many steps; what resists is a calculation that runs slightly differently on each occasion. Complexity lengthens the work for whoever builds it, while whether there is one rule decides if the work is possible at all.
In the Resterm heater selection software the engineering calculation is done by software, which then picks the electric heater that matches. Why the entry asks for a need rather than a product code, and how the result of the calculation reaches a priced line, is set out in the article on turning a calculation into a quote.
The case where the kind fails is easy to state. Where the rule is renegotiated with every customer, there is no single calculation for software to apply, and what happens at that table is a decision rather than a sum.
Where this kind stops depends on where the result goes. Show the result on a screen and leave it there, and the job is half done: the output of the step sits in nobody’s record, and whoever performs the next step carries it across by hand. That is exactly the line between calculating and deriving, with one producing a result and the other attaching a result to a record.
Deriving: when the input is a record the system already holds
Nothing arrives from outside in this kind. The second record draws its input from a record the system is already holding, so the work is attachment rather than arithmetic: as the second record comes into being, it already carries which first record it answers to. The limit comes from the same place. A first record created where the system cannot reach it leaves the second one nothing to read.
This kind is easy to overlook. Keying the same value onto a second screen a few times a day never shows up on a task list, so nobody puts it forward as something software could take on. Its input is sitting in the system all the while, which means the condition for deriving was met at that step long before anyone looked for it.
A second decision follows and is easy to leave open. Once a derived record exists, something has to say what happens when its source changes later: does the second record move along with the source, or does it keep the state it had at the moment it was made. Leave that unsettled and the arrangement still looks finished, while the records quietly stop agreeing with each other.
In AlgoCar service management software a part written onto a work order is seen by the stock side as it happens. AlgoCar is our own product and it keeps gaining features. Why the split between a derived record and a re-entered one is an architectural decision is set out in the article on why architecture comes first.
A boundary belongs here as well. Automating one step and closing a whole chain are separate pieces of work, and the ERP scope that closes a work order, a stock movement and an invoice on one chain carries limits of its own: production planning, supply chain and consolidated finance fall outside it. This piece describes one step, not the chain.
Scheduling: when a date, not a person, starts the step
Start with what a business looks like before this kind is in place: the work left behind is a reminder rather than a task. Somebody has to put the update, or the closing, on their own calendar, and on the day they forget, a value whose date has passed is still sitting on screen. The symptom is not slowness; it is a record whose upkeep has been left to a person’s memory.
Nobody starts this one. The trigger is a condition on the calendar rather than a click, and a date passing is enough to fire it. The other kinds wait for an input to arrive and then process it; here the input is time, and time needs no event to announce it.
Building it means deciding, in advance, what behaviour the record moves into. Is the same record updated when its date passes, or does it become a record that will never change again. Those behaviours cannot share one record, because one of them requires being overwritten and the other requires never being overwritten.
On Günlük Hava Durumu a forecast whose date has passed becomes an archive row that will not change again, and the climate summary refreshes itself out of that archive. The site is published and its updates continue. Why forecast, archive and summary were set up as separate behaviours is covered in the article on why a page’s update rhythm decides how it is published.
There is an inverse worth naming. Tie a record that should never change to the calendar and the fault runs the other way: the system keeps remaking a result that was always going to come out the same. Deciding where not to build this kind matters as much as deciding where to build it, since not every record has a next behaviour waiting on a date.
Finding candidates in your own work takes little effort. Anything remembered at month end, anything gone through when a season turns, anything that has to be closed because a period ran out: each of those is a candidate, and the input is already available, because a calendar is written the same way in every business.
An automation program, or the system that holds the record
For a reader who began with a search for an automation program, the answer gathers here. In every business described above, the step software took on is not a separately bought product; it is a behaviour inside the system that already holds the record. The calculation sits beside the product and quote records, the stock movement beside the work order, the archive beside the forecast.
Those businesses also share a decision that is easy to miss: the old route was not left open as a fallback. At Resterm nobody picks the heater out of a catalogue once the calculation has run; in AlgoCar the stock movement never waits to be keyed in on a separate screen; on Günlük Hava Durumu the climate summary never waits to be updated by hand. Closing the old route is a decision in its own right, taken separately from automating the step.
Leave the fallback open and the whole thing becomes optional. On a busy day somebody takes the old route, that day’s entry is made outside the system, nothing in the software breaks, and the guarantee quietly lapses. Hence the last question worth asking: is the old route closed.
So an automation program and a system that holds the record differ in order rather than in kind. Stand up the system that holds the record and the steps that can change hands appear along with it; add automation to a system with no record underneath and every one of the four kinds runs into the same wall. The first question is therefore which step, not which program: a program question is about scope, a step question is about input, and the second gets answered first.
A reader holding a list of products will want to reverse that order, and the impulse is understandable: a list is something you can hold. The order still runs the other way, because what decides whether a program is any use is which step it has to take on, and the list cannot be read until that step has a name. Once the step is fixed, what remains is where its input and its output will sit.
Where the rule gets written is the question waiting after that. Once the input of a step has told you what is possible, the next thing to settle is where that step’s rule will live. Our management software page covers how a rule is defined at setup rather than decided in the moment.
