The
ENIAC general-purpose computer came to market in 1951, so why, after 68 years, do we still have usability issues with large-scale systems of record?
The definition of insanity is doing the same thing over and over again and expecting a different result!
Waterfall, joint application development, rapid application development, rapid prototyping, total quality, ITIL, Agile scrum, Six Sigma -- and whatever else the B-schools, tech schools, and Silicon Valley can fabricate as the latest-and-greatest method for defining and developing software -- all share one trait. That is, they all depend on some form of software requirement that isn’t written by the people who write the software. If you manage business operations, then you know what I’m talking about. You know the software you use is written by people who never processed an order, applied a credit, authorized a return, issued an invoice, made a delivery, stocked a shelve, or answered a customer call.
These software developers make hundreds or thousands of decisions about how business processes should be supported in the seclusion of their “development environment.” They spend weeks or months at a time relying on their own experiences to decide how the business process “should” be supported. An example of this is when a developer thinks it’s reasonable to require copying and pasting of 16 data elements from three different systems of record to another system to create a “case.”
Another example is the expectation that it’s reasonable to make a contact center agent sift through five mainframe screens to find an answer for a customer. This situation is made even more time-consuming when each screen refresh takes five seconds. Contact center agents who are victimized by these software development decisions are forced to put customers on hold for minutes at a time so they don’t make a copy/paste or screen navigation error. Think of how rewarding this process is for the agents. Then think about how happy customers are to listen to dead air while the agents work to overcome the stupidity of the technical class.
What’s interesting is that the majority of white-collar business operations is supported by these techy-built software solutions. In many cases, especially in contact center operations, the techies seemed to think that it’s OK to ask operations employees to spend 30% to 50% of their days with their hands on their keyboards. Developers spend 70% to 80% of their days on their keyboards, so I guess they figure they’re doing the rest of us a favor by only requiring 30% to 50%.
Aren’t the computers supposed to do this repetitive and mundane work? It took me 29 minutes to order a new TV/Internet service the other day. That was after spending 43 minutes in a failed attempt to get a new cable box shipped to my house. Those are 72 minutes that I’ll never get back. Three cheers for the telco business!
Conventional wisdom, universities, and Silicon Valley all say this is fixable with just one more new iteration of requirements written by business people and software written by software developers. Brilliance masked by the repetition of insanity.
But there is a new game in town. It’s called
robotic process automation. These are software robots that automate the mundane and the repetitive. Yes, there are now more than 100 companies that make software that contact center agents can use to trigger the copy/pastes of those 16 data elements into the case in a matter of seconds, as well as sift through those five mainframe screens with the same ease (the five-second screen-refresh rates will persist until the techies can figure it out, however).
The rest of this story is that the majority of RPA companies create what the industry calls “low-code” development environments. What this means is that you don’t need to know C++, Java, JavaScript, HTML, or any other “language” to build useful automation tools that fix what the technical class has imposed on business people.
Further, many of these new RPA solutions use a utility called “computer vision.” This utility allows the robot to read and manipulate the computer interface just like a human. This means that with the low-code development environment, a businessperson can use drag-and-drop, computer-vision utilities to build robots that can read and write to any interface just like a human.
Typically, these low-code development environments also include a “record” feature. Basically, you trip the recorder, execute the process (five-screen navigation, for example) and the robot writes the software necessary to automate the process. There is some testing and exception management that needs to be refined at this point. Then you deploy the software to every desktop that needs the automation.
Maybe this will free up enough techie-time to fix the irksome five-second screen-refresh rates.
