Software-as-a-service: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 5: | Line 5: | ||
If your software were any good you would design a [[user interface|user-interface]] easy enough for the [[meatware]] to deal with ''so you didn’t need a service contract''. Right? | If your software were any good you would design a [[user interface|user-interface]] easy enough for the [[meatware]] to deal with ''so you didn’t need a service contract''. Right? | ||
===The [[reg tech]] business model conundrum=== | ===The [[reg tech]] business model conundrum=== | ||
{{quote|'''Lesson one''': Insist on an unsupervised pilot where ''real'' users get to push and pull the product by themselves without help from the vendor, and not just a chaperoned proof of concept where the software vendor can control inputs and outcomes to make the product seem satisfactory.}} | {{quote|'''Lesson one''': Insist on an unsupervised pilot where ''real'' users get to push and pull the product by themselves without help from the vendor, and not just a chaperoned [[proof of concept]] where the software vendor can control inputs and outcomes to make the product seem satisfactory. Remember the [[sixth law of worker entropy]].}} | ||
It is a familiar experience amongst buyers of [[reg tech]] and [[legal tech]] that hawked products do fabulously when demonstrated to the [[general counsel]] at the pitch (often by performing some kind of [[magic]] on a pre-prepared [[non-disclosure agreement]]), but underwhelm upon implementation when set upon by the [[morlock]]s who actually need to use them to solve real-life problems. | It is a familiar experience amongst buyers of [[reg tech]] and [[legal tech]] that hawked products do fabulously when demonstrated to the [[general counsel]] at the pitch (often by performing some kind of [[magic]] on a pre-prepared [[non-disclosure agreement]]), but underwhelm upon implementation when set upon by the [[morlock]]s who actually need to use them to solve real-life problems. | ||
This is partly because the yen to be [[thought leader|thought-leading]]s [[agent]]s for [[step-change]] in their industry, plays to a [[general counsel]]’s innate credulity and weakness for flattery, but has a profounder operating cause: [[reg tech]] struggles mightily with a business model that ''scales''. [[Reg tech|reg tech]] strives to automate [[tedious]], repetitive and manual tasks, thereby removing a significant cost item from the departmental budget, and accelerating and improving the output quality at the same time. | This is partly because the yen to be [[thought leader|thought-leading]]s [[agent]]s for [[step-change]] in their industry, plays to a [[general counsel]]’s innate credulity and weakness for flattery, but has a profounder operating cause: [[reg tech]] struggles mightily with a business model that ''scales''. [[Reg tech|reg tech]] strives to automate [[tedious]], repetitive and manual tasks, thereby removing a significant cost item from the departmental budget, and accelerating and improving the output quality at the same time. The idea is to [[disintermediate]], taking out expensive, unreliable, high-maintenance machinery and replacing it with does the same job for nothing. | ||
If you are buying that product “off the shelf” — assuming it can already do what its vendors claim; by no means a given — observe where the vendor’s energy is going: exclusively, ''sales''. They are costlessly reprinting something they made earlier, and proposing to charge you a licence for it, per seat, per use, or per time period. On this model, there is only one way to make decent amount of money: by ''extracting rent''. Now this would be fine, of course, if the product indeed ''did'' work as billed, and intelligently anticipated your particular applications, and handled them quickly, quietly and immaculately right out of the box. | |||
But, of course, they don’t. It is a common experience, when you finally get to play with it, that a reg tech application ''doesn’t quite do what you want it to''. Either your intended application isn’t ''quite'' the one the vendor had in mind, and the product can’t ''quite'' do it and isn’t flexible enough for you to reconfigure it on the fly — call this a “misalignment” problem — or it ''can'', but to get the application to be of any use, it will need a good deal of energy, expertise and effort from ''your'' people to configure or train it; energy [[change adoption|they will be disinclined to provide]] — call this a “configuration” problem. | |||
These are different problems, but most [[reg tech]] offerings suffer from both, because they both stem from the same fact of life: while there is an unquantifiably huge volume of [[tedium]] to be automated, ''no two instances of tedium are quite alike''. Tedium is particular, not generic. ''That is why it is [[tedious]]''. It the same source of tedium were common to enough participants that a glib SaaS solution would sort it, ''it would have already been sorted''. This is the tale of the tape in technology implementation. | |||
====Misalignment==== | |||
===Then there’s [[blockchain]], of course=== | ===Then there’s [[blockchain]], of course=== | ||
Revision as of 09:44, 7 February 2021
|
JC pontificates about technology
An occasional series.
|
Software as a service — fondly known as SAAS but known to users as rent-seeking as a service — is rent-seeking by means of intellectual property or some other kind of monopolistic behaviour. It is also basically the only business model reg tech entrepreneurs — a.k.a. refugee managing associates with JavaScript developers from Bucharest they found on the dark web — can figure out.
The equivalent of selling a warranty on a toaster. Charging a running cost for a software application which shouldn’t need a lot of maintenance, unless you built it to need maintenance.
If your software were any good you would design a user-interface easy enough for the meatware to deal with so you didn’t need a service contract. Right?
The reg tech business model conundrum
Lesson one: Insist on an unsupervised pilot where real users get to push and pull the product by themselves without help from the vendor, and not just a chaperoned proof of concept where the software vendor can control inputs and outcomes to make the product seem satisfactory. Remember the sixth law of worker entropy.
It is a familiar experience amongst buyers of reg tech and legal tech that hawked products do fabulously when demonstrated to the general counsel at the pitch (often by performing some kind of magic on a pre-prepared non-disclosure agreement), but underwhelm upon implementation when set upon by the morlocks who actually need to use them to solve real-life problems.
This is partly because the yen to be thought-leadings agents for step-change in their industry, plays to a general counsel’s innate credulity and weakness for flattery, but has a profounder operating cause: reg tech struggles mightily with a business model that scales. reg tech strives to automate tedious, repetitive and manual tasks, thereby removing a significant cost item from the departmental budget, and accelerating and improving the output quality at the same time. The idea is to disintermediate, taking out expensive, unreliable, high-maintenance machinery and replacing it with does the same job for nothing.
If you are buying that product “off the shelf” — assuming it can already do what its vendors claim; by no means a given — observe where the vendor’s energy is going: exclusively, sales. They are costlessly reprinting something they made earlier, and proposing to charge you a licence for it, per seat, per use, or per time period. On this model, there is only one way to make decent amount of money: by extracting rent. Now this would be fine, of course, if the product indeed did work as billed, and intelligently anticipated your particular applications, and handled them quickly, quietly and immaculately right out of the box.
But, of course, they don’t. It is a common experience, when you finally get to play with it, that a reg tech application doesn’t quite do what you want it to. Either your intended application isn’t quite the one the vendor had in mind, and the product can’t quite do it and isn’t flexible enough for you to reconfigure it on the fly — call this a “misalignment” problem — or it can, but to get the application to be of any use, it will need a good deal of energy, expertise and effort from your people to configure or train it; energy they will be disinclined to provide — call this a “configuration” problem.
These are different problems, but most reg tech offerings suffer from both, because they both stem from the same fact of life: while there is an unquantifiably huge volume of tedium to be automated, no two instances of tedium are quite alike. Tedium is particular, not generic. That is why it is tedious. It the same source of tedium were common to enough participants that a glib SaaS solution would sort it, it would have already been sorted. This is the tale of the tape in technology implementation.
Misalignment
Then there’s blockchain, of course
The latest iteration — talked about in tones of reverent optimism here — is “blockchain as a service”. But a service to whom? And did I hear a siren going off?