2 ms·
I'd put the limiting factors as: (1) archaic automation software package architecture (see: Automation Anywhere's cutting-edge-of-1975 choices) (2) incompatib
by ethbro 10y ago
I'd put the limiting factors as:
(1) archaic automation software package architecture (see: Automation Anywhere's cutting-edge-of-1975 choices)
(2) incompatibility of automation software packages with anything outside their stack (including version control / automated deployment)
(3) lack of compatibility with legacy apps (that tiny UI library sold in 1993 and then orphaned when the vendor went bankrupt in 1996? Some company used it to write an entire business critical app, and is still using today)
(4) lack of ability for a business to document its process (you'd be amazed how often they doesn't have the knowledge to tell you how a thing should be done, despite doing it every day)
(5) management conservatism / political struggles
(6a) inability of in-house IT at smaller companies to be agile and fast enough to keep up with automation development speed and needs, (6b) even worse outsourced IT, who want to charge for anything outside the box, then deliver half of what you asked for, wrong, 6 months later & (6c) complete lack of knowledge about business critical system / application internals (someone retired, company never ensured knowledge transition; or they outsourced their IT with same result)
(7) input data in a non-standardized format (example from insurance: there are major hospitals, to say nothing of the doc offices, that are used to submitting out-of-spec claims because the insurance processor is used to correcting them & has been doing so for the last 10 years)