4 ms·
So is this an effect of byers not having to use the product, or the fact that the checklist is huge and the software has to fit a ton of distinct use-cases that
by ssharp 11y ago
So is this an effect of byers not having to use the product, or the fact that the checklist is huge and the software has to fit a ton of distinct use-cases that ultimately makes the software bad. I've never worked on enterprise software like that, so I'm honestly not sure.
At a previous job, I had to bend Blackboard a little to do what I needed it to do and this was my only exposure to Blackboard from the admin/instructor side. I had interacted with it as a student and found it sufficient.
From the admin side, it was certainly unintuitive, like most other enterprise software. However, also like most other enterprise software, once you used it enough and/or did the necessary training, it did make more sense.
I'd be curious to know examples of enterprise software that is easy to learn and use without having to build experience or go through training.
- acdha 11y ago> So is this an effect of byers not having to use the product, or the fact that the checklist is huge and the software has to fit a ton of distinct use-cases that ultimately makes the software bad. It's an artifact of the types of organizations which buy enterprise software and how well they [don't] handle communication and responsibility internally. Fundamentally, the results are rarely good when someone is buying software on behalf of someone else unless they have a deep understanding of how the other group works and where they spend the most time. One really common manifestation of this problem is when senior managers buy the software which gives them the reports which they want but doesn't consider how painful the process of entering the data is or whether the system design biases that data. Enterprise software exacerbates that problem because the business model is a one-time decision to make a very expensive purchase. Since correcting a mistake is hard-to-impossible, that tends to lead to “requirements” which include everything anyone has ever thought they might need, which favors the really large vendors who can afford to check most of those boxes and promise that their expensive consultants can customize the software after the fact to get the remaining ones, which has a near-certainty of resulting in the problem mentioned where someone implemented just enough to say they satisfied a requirement but will never improve it before the next round unless you cough up more money and since it's customized per-customer there's limited ability to get improvements which someone else paid for.
- VLM 11y agoA very simple, obvious, possibly universal example of buyer and purchaser disconnect is well meaning grandma (or other non-gamer relative) buys kid the wrong video game. If you take the antics out of the sitcom TV trope and into a business, you can see the laugh track turn into agony. Another example or analogy that everyone probably has experience with is the old Robert Conquest's "Third Law" or fourth or whatever about all organizations devolving into appearing to be ruled by a cabal of their enemies, and if you think that manual hand operated torture devices are painful, wait until the same gang implements automated computerized high performance torture implements upon their organization. An organization that can tolerate the destructive influence of its leadership in a manual process arena might not survive automation of the destructive processes. But enough comedy (or is it merely snarky insight?) Two business sociology problems are empire building by complicated processes and projecting power by gatekeepers, both being short circuited by "the big automated system". There is also a psychological trap where automation systems are more accurately described as micromanagement systems, and two outcomes are possible under computerized micromanagement, one is a spontaneous rebellion where everyone knows they and everyone else are better off if the project fails so they do the obvious, and the other outcome is an organization that can be micromanaged is either already dead or solely exists as a theoretical construct, so the project flops.