82,891
edits
Automation eliminates value but not risk: Difference between revisions
Automation eliminates value but not risk (view source)
Revision as of 11:21, 28 November 2022
, 28 November 2022no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{a|design|}}If you can [[Automated|automate]] something, you can’t monetise it. You automate, therefore, as a ''defensive'' strategy: because everyone else is automating, and if you don’t, your unit cost is higher. | {{a|design| | ||
[[File:Noughts and crosses.png|450px|frameless|center]] | |||
}}If you can [[Automated|automate]] something, you can’t monetise it. You automate, therefore, as a ''defensive'' strategy: because everyone else is automating, and if you don’t, your unit cost is higher. | |||
This plays to a pet theory of the [[JC]]’s: [[the quotidian is a utility, not an asset]]. If you believe you have [[intellectual property]] in your [[boilerplate]], you will waste precious resource defending an articulation of common knowledge.<ref>You didn’t ''invent'' the “[[rights cumulative]]” clause, now, did you?</ref> You will, accordingly, misprice that asset, and you may be disappointed in how much people will be prepared to pay for it. | This plays to a pet theory of the [[JC]]’s: [[the quotidian is a utility, not an asset]]. If you believe you have [[intellectual property]] in your [[boilerplate]], you will waste precious resource defending an articulation of common knowledge.<ref>You didn’t ''invent'' the “[[rights cumulative]]” clause, now, did you?</ref> You will, accordingly, misprice that asset, and you may be disappointed in how much people will be prepared to pay for it. | ||
| Line 5: | Line 8: | ||
Not much. | Not much. | ||
Proprietors of contract assembly tools, take note. The value is in ''what'' you assemble, not ''[[Secret sauce|how]]'' or ''with [[Boilerplate|what]]''. Neither “how” in the sense of your precious inviolate [[boilerplate]], or “how” in the sense of the “ingenious” application that you, and a [[ | Proprietors of contract assembly tools, take note. The value is in ''what'' you assemble, not ''[[Secret sauce|how]]'' or ''with [[Boilerplate|what]]''. Neither “how” in the sense of your precious inviolate [[boilerplate]], or “how” in the sense of the “ingenious” application that you, and a [[Bulgarian freelance coder|Java coder from Bucharest you found on ''UpWork'']] threw together over a mad weekend six months ago. You know how your software contraption was quite easy, in the scheme of things, to make? How it only cost you five thousand Romanian Leu? This should be your clue to understanding that ''this is no impregnable hillfort from which to launch your megacorn''. | ||
The ''what'' comes not from your friend’s elegant runes of JavaScript, nor from your cheeky user interface, but from your customer’s unique use-case. If you can explain what justifies your monetising ''that'', do write in and let us know. | The ''what'' comes not from your friend’s elegant runes of JavaScript, nor from your cheeky user interface, but from your customer’s unique use-case. If you can explain what justifies your monetising ''that'', do write in and let us know. | ||
| Line 13: | Line 16: | ||
But, while rigorous and well-executed automation can remove all the ''micro''-risks that are intrinsic/internal to the process being automated — logical lacunae, process inconsistencies, natural fallibility of the [[meatware]] who would otherwise be operating the process — it cannot, even in theory, manage the ''extrinsic'' risks arising from the inevitable interaction of the automated process with the inchoate and innumerable [[System|systems]] of the outside world. These contingencies present [[complex]], [[non-linear]] and potentially catastrophic risks. They are by nature impossible to see from within an automated process, let alone to predict in advance. | But, while rigorous and well-executed automation can remove all the ''micro''-risks that are intrinsic/internal to the process being automated — logical lacunae, process inconsistencies, natural fallibility of the [[meatware]] who would otherwise be operating the process — it cannot, even in theory, manage the ''extrinsic'' risks arising from the inevitable interaction of the automated process with the inchoate and innumerable [[System|systems]] of the outside world. These contingencies present [[complex]], [[non-linear]] and potentially catastrophic risks. They are by nature impossible to see from within an automated process, let alone to predict in advance. | ||
So: yes, standardise and automate by all means, but don’t expect it to lead to lasting revenue, or even cost savings and expect that you will need to monitor the interface between your closed logical system and the dirty, intractable world, like a hawk. | So: yes, standardise and automate by all means, but don’t expect it to lead to lasting revenue, or even cost savings and expect that you will need to monitor the interface between your closed logical system and the dirty, intractable world, like a hawk. This is the lesson of ''The Sorcerer’s Apprentice'', by the way. | ||
What do you mean? | |||
{{sa}} | {{sa}} | ||
*[[The quotidian is a utility, not an asset]] | *[[The quotidian is a utility, not an asset]] | ||