Launch HN: ElectroNeek (YC W20) – Automatically find and automate routine work
Some of you may have heard of a technology niche called Robotic Process Automation, or RPA. Basically, it’s about automating user actions on Graphic User Interface level, so no API is needed to automate any type of repetitive work on the computer. It has been known for 20+ years in the software testing space but emerged as a business process automation tool over the last decade, getting big momentum in Enterprise (95% of Fortune 500 use it for back-office task automations). If you know what Selenium is and how it automates work in browsers you may think of RPA that is a Selenium on steroids that can work in any desktop or SaaS app.
Basic RPA bots interact with app interfaces using mouse and keyboard, so if some repetitive process can be described by an instruction it can be automated (in theory) with RPA. There are a few fundamental issues with GUI-level automation (like, how should a programmed bot behave if the interface has changed?) but the major limit historically has been the complexity of RPA bot development and administration.
The biggest benefits of RPA come from automating complex tasks, sometimes even end-to-end jobs across multiple pieces of software and websites. As you might expect, this approach to automation works great until it doesn't, and then someone has to step in with duct tape, a.k.a. write glue code to stick the pieces together, especially when it comes to variables, cycles and unstructured data (a lot of real business documents). RPA turned into something that business users can not use without having coding experience, which defeats the whole purpose.
In 2016-2018, Sergey and Dmitry, long time friends, separately got into RPA consulting business on two different continents. Sergey ran his own boutique firm that worked with big banks and natural resource companies in Eastern Europe and Dmitry was in charge of RPA branding and marketing strategy at EY’s Americas business. The idea to build new software in the space came from Sergey’s inbound marketing pipeline – many mid-market companies understood the benefits of RPA, attended Sergey’s firm demos of RPA bots in action, but walked away from implementations because they haven’t been able to afford them due to limited in-house IT resources and absence of a budget for consultants. ‘Too complex and expensive’ - the most common feedback of such potential clients who in fact were underserved by major vendors and integrators. To move forward with making RPA easier for such customers, Sergey and Dmitry brought in Mike, Dmitry’s college friend with a major in mathematics and career in cloud architecture.
We got some momentum among small banks, insurance companies and other companies with relatively tiny IT teams. But then we realized that there are obstacles with this market. The biggest problem lies in finding what to automate in the first place. There is lots of manual repetition going on in companies that people just don't notice. Managers and IT often understand the RPA tech and its capabilities, but struggle to find where to start.
An even bigger obstacle to automation is the need to learn complex tools and in fact, the need to code in order to automate significant routines. It turns out that navigating desktop or website interface requires more complex logic than taking data from SaaS A to SaaS B (the land of Zapier).
Over the time we adopted a mantra ‘if it can be done with a mouse only, without touching the keyboard, it should be automatable in this way'. At present, ...
48 comments
[ 3.3 ms ] story [ 117 ms ] threadI can't find any demo videos on your website that would make it clearer how it actually works, though.
Also, check out this recent case of using ElectroNeek to automate accounting data transfer into SaaS tool https://www.youtube.com/watch?v=z5YXsWSGaRM
However, I wonder about the reliability aspects of it? Many sites are pretty hostile to Selenium and robot-like behaviors. Also, software can change it's layout, colors, icons, etc.
I've seen this with a team that was using SikuliX[0] to automate testing of a GUI application. It worked, but any time the UI changed even a little, the whole automation program would have to be re-done.
In short, I wonder how ElectroNeek solves these issues:
1. Working around software that has been designed to be hostile to automation.
2. Coping with changes to a UI when a software is updated.
3. All the difficult little error handling bits. How do you know if the workflow succeeded? How do you make sure it only happens once? How do you notify the user?
4. Where does the program run? Do you have to have a pile of PCs sitting around running mouse movement scripts in real-time?
Another thing I wonder -- how do the users feel about this? I think many people would be uncomfortable knowing that there is a Sword of Damocles hanging over their head, waiting to automate their job away if it seems too repetitive. I guess that would ultimately be a cultural issue for the company using this tool to solve, but still something I think would be important in order for clients to be successful using it long-term. For example, you don't want to create an incentive for people to try and make their tasks seem non-repetitive in order to avoid having their job automated.
0 - http://www.sikulix.com/
1. Interface elements on windows apps and websites typical have identifiers that allow to hook to them correctly even if visual representation/layout changes so we were ablate automate pretty much any software/website we have tried. Some websites use active A/B testing all the time and theta becomes a challenger, though, doable.
2. This is a fundamental challenge of GUI-level automation, were is no silver bullet to completely eliminate the need for bot 'maintenance'. We allow users to create a library of UI elements that they are using in their workflows, again, their identifiers often allow automatically handle UI changes but if not, users can just relink their interface library with changed GUI elements, without disrupting the bot logic, so it becomes a minor effort to see the bot working in changing GUI environment.
3. (1) Real-time tracking of what the bot does, (2) Logs, (3) 'Exception' port to build custom logic for user involvement/notification at every step of the automated process. For instance, the bot can send you Slack message or email if it ran into an issue.
4. It can run on end-user computers, will look like a cross-application macro, or on a virtual machine/server 24/7 ('unattended' process automation). We partner with Microsoft to bundle our software with Azure infrastructure and make it scalable - so you can deploy more specific bots when the workload for them goes up.
5. You are right, this is a cultural aspect and people challenge. In my own experience, the best way to address is to let people who got a few hours back due to routine elimination to share their experience and how their career path has changed since that, for instance they picked up some analytical tasks that otherwise would require a new hire.
The best usage is automating repetitive tasks in a call center environment. Like you click a "Start my day" button and it opens up and logs you into every application that you use. Then a customer calls in and you put their information in one place and that opens the customer's record in all of those applications. Time is money in call centers and you can save a lot of time with simple stuff like this.
More questionable usage is as a psuedo-api background process. The users fill out a form and that information is sent over to a queue. The robot pulls it out of the queue and then enters it into the slow/confusing legacy backend system. This is good because it's cheaper/faster than building out an API to a legacy backend that is difficult and expensive to change.
The problem is that now you have a brittle and asynchronous communication layer over a legacy backend that is difficult and expensive to change. You compound the problem you have in exchange for quick benefits.
What's that about? Just the right words for the right concepts?
Good luck with your business. it's really awesome you were able to get through to them that this is a huge business
There might be many reasons why you were never accepted to YC, despite applying nine times. Heck, I actually plaude your "stubbornness" / "determination", which is not common.
Don't despair. Sometimes life is hard, sometimes life has other plans for us. Perhaps there's a big success for you just around the corner.
And if not... There's nothing wrong with not being YC-backable. You are still a human being.
Looking at your marketing communication and seeing Robotic Process Automation I thought, hey cool those guys can build me an assembly-line powered by robots for my new hardware product I'm designing. Then coming back reading a bit more your post (but still too lazy to read it concentrated because it's way too long, I head to the comments and see stuff more in the software automation territory like Autohotkey, Selenium...
I guess I got it all wrong but your positioning is super broad or is it just misleading communication. Whatever, good luck!
For example, Rapid Miner: https://www.rapidminer.com
There's also a Coursera:
https://www.coursera.org/learn/process-mining
https://apromore.org/
https://www.kofax.com/Products/rpa/overview