[HN Gopher] Launch HN: ElectroNeek (YC W20) - Automatically find...
___________________________________________________________________
Launch HN: ElectroNeek (YC W20) - Automatically find and automate
routine work
Hey Hacker News! We are Sergey Yudovsky, Dmitry Karpov and Mike
Rozhin, founders of ElectroNeek (https://electroneek.com), an
automation platform for repetitive business tasks. The product we
build let users design software 'robots' that imitate human actions
in apps and websites, and deploy them to eliminate routine work.
Our software also spots patterns of repetitive processes that users
do in business app and suggests what to automate in the first
place. 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, about
25% of our bot developers are non-IT. Typically their role in a
company is related to working with analysis or operations data.
They benefit from automating data extraction or data entry tasks
and are motivated enough to learn a new tool to make their own life
easier. These 'Citizen Automator's' have a very simple decision-
making process when they evaluate automation opportunities: will I
get back the time I invest in designing a workflow? What are the
time gains? If so, I invest my time and request a budget for a
solution. Our big insight about how to solve these obstacles came
from the simple idea that 'robots' that execute automations also
have all the capabilities to passively monitor how users interact
with different interface elements, mouse, keyboard, etc. Why not
let the 'robot' look at what you do in the first place, and attempt
to find whether you run the same process repetitively, even if runs
are spaced in time. Normally this could be seen as an invasion of
privacy but, unlike with time trackers, the purpose of this
monitoring is not a control of how people spend their working hours
but the voluntarily search for automation possibilities for giving
time back to people. From that we built a simple repetitive-
actions analytics tool that any users, regardless of IT experience,
can use out of the box. Users across a company can download a
client that passively monitors how they interact with different
interface elements (forms, buttons) across whitelisted applications
and websites, looks at clipboard frequency, mouse and keyboard
usage patterns. On the back end, the cloud portion of the software
identifies repetitive patterns and estimates potential (in hours)
for automation on the level of software, users, and the
organization. For instance, if a user often switches between 2
application windows and uses Ctrl+C/V in each iteration, this is a
pattern of repetitive process that can be automated with RPA. The
platform counts specific automation opportunities (like copy-
pasting, repetitive click-throughs) to give a better sense on what
exact routine it identified. These types of job are common for RPA
automations. Even more common is the case of clicking through a
legacy system to process a transaction (for instance, underwriting
insurance) - users click on interface element on the same screens
in the same orders for 30+ times and don't even think of
accelerating the clickthrough with automation. Or accounting case -
many CPAs charge clients for manually uploading ledger account into
cloud accounting software, taking data from excel to web forms.
'Robots' will 'eat' such tasks. Once the repetitive patterns have
been identified, it's time to start automating. Designated users
can build bots with no code/low-code. Finding and eliminating
inefficiencies is a pretty addictive process. When you have an
automation tool in your hands you definitely look very differently
at how your teams spend their working hours. On the business side
of the house, we adopted SaaS model and charge clients for the
access to process discovery and automation suite that has both web
and downloadable parts. We eat our own dog food a lot: all of us,
from sales and marketing to product, have our own set of automated
workflows. In sales, we use bots to automate going to LinkedIn
Sales Navigator to enrich contact lists, to check emails in these
lists against spam databases (using tool named Scrapp) and then to
build email sequences in Gmail, bypassing # of sent emails limit
set by CRM vendor on our plan. We're really happy to get to this
point and share our story here, thank you for reading about it!
Please let us know your thoughts and questions in the comments.
Author : Digitaltzar
Score : 86 points
Date : 2020-07-08 14:30 UTC (8 hours ago)
| maxehmookau wrote:
| Interesting that you use a lot of the same terminology as UiPath.
| Orchestrator, Robot, Studio. Even the same OCR libraries.
|
| What's that about? Just the right words for the right concepts?
| Digitaltzar wrote:
| Yes, these terms actually root in pre-UiPath era and now become
| the industry standard. OCR libraries are not specific to RPA
| (e.g. Microsoft OCR,Google OCR, Tesseract, Abbyy) but, again,
| are pretty much the standard, what we do differently from other
| RPA vendors is providing users with the ability to visually map
| scanned template data to variables so it can be done with no
| code, using only mouse (in line with our focus on simplicity
| for the developer, works really well for cases when you deal
| with limited set of templates.
| maxehmookau wrote:
| Thanks for the clarification!
| Digitaltzar wrote:
| You are welcome!
| dorianmariefr wrote:
| Reminds me of AutoHotKey which I used to automate some work for a
| warehouse a while ago
| Digitaltzar wrote:
| Yep, it's a right way to think about this as of AutoHotKey on a
| lot of steroids:)
| mongojunction wrote:
| I applied to YC with this idea more than 9 times. I guess I'm
| just a loser
|
| Good luck with your business. it's really awesome you were able
| to get through to them that this is a huge business
| Digitaltzar wrote:
| Hey, please don't be discouraged, for us it worked because
| (imho) we came to YC interview with existing paid user base
| growth, so it was far beyond the idea stage. And I personally
| applied to YC 3 times, starting from 2015:)
| jamestimmins wrote:
| Super cool to see how much talking to customers has informed your
| product decisions. Identifying tasks to automate sounds like a
| hard problem, but I'd imagine it's a huge advantage when making
| sales. Good luck!
| Digitaltzar wrote:
| Thank you, James! Yes, finding processes out of the box helps a
| lot to open the doors that otherwise stay closed
| 35post wrote:
| Thanks for sharing. I've skimmed your post and headed right to
| your website in hope to get a quick overview of what you guys are
| actually doing.
|
| 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!
| Digitaltzar wrote:
| Thanks for the feedback! Robotic Process Automation or RPA is a
| common name for GUI-level automation but it can be confusing,
| that's why we more and more often try to refer to what we do as
| 'software robots' or 'software bots'
| SergeyYudovskiy wrote:
| Useful feedback. Thank you!
| cpr wrote:
| Looks fantastic!
|
| I can't find any demo videos on your website that would make it
| clearer how it actually works, though.
| Digitaltzar wrote:
| Hey, we host demo videos on our youtube channel
| https://www.youtube.com/channel/UC014owEr9E1tRVJJKJ3wXdA
|
| Also, check out this recent case of using ElectroNeek to
| automate accounting data transfer into SaaS tool
| https://www.youtube.com/watch?v=z5YXsWSGaRM
| SergeyYudovskiy wrote:
| By the way, you can create a free trial account always and test
| our solution on your computer!
| blackbear_ wrote:
| How do you identify and deal with edge cases and rare situations?
| Digitaltzar wrote:
| Hi, many repetitive processes have certain exceptions and rare
| situations when a rule-based logic breaks, typically due to
| variability of incoming data (e.g. robot finds a text instead
| of a number in certain template field). Our approach is to (1)
| provide users with custom exception/error handling logic, e.g.
| evert robot logic step has an "exception" branch that activates
| of the bot can't correctly complete the activity; (2) be able
| to activate "human in the loop' function to bring in user when
| needed; (3) be bale to work with unstructured data like random
| invoices to minimize the need for (1) and (2)
| bradyo wrote:
| A lot of commenters are focusing on the RPA part, but what seems
| to be more novel (to me at least) is the passive discovery of
| what could be automated with RPA. That seems like a generically
| hard problem, good luck!
| Digitaltzar wrote:
| Thank you, a great point! We have witnessed so many
| automation/RPA initiatives put on hold/buried because of the
| complexity or cost of process discovery, that's why a lot of
| R&D efforts are focused on this specific stage of automation
| lifecycle
| SergeyYudovskiy wrote:
| Thank you!
| SMAAART wrote:
| This is interesting, leaving comment to remember the post.
| dang wrote:
| Please don't comment for that reason. You can either upvote it
| or favorite it - both of which lists are accessible later from
| your profile.
| Digitaltzar wrote:
| ([?]#_#)
| charlesdaniels wrote:
| This sounds really cool!
|
| 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/
| zippy5 wrote:
| I worked on 2 a little bit. Serializing the dom then putting it
| into probabilistic data structures is the way to go. Bloom
| filters, lsh hashing, min-sketch are good ways to fuzzy match.
| UI's change but for the most part code doesn't.
| Digitaltzar wrote:
| Thank you Charles,
|
| 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.
| treis wrote:
| I use this in the wild and like anything it has its pros and
| cons.
|
| 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.
| [deleted]
| Digitaltzar wrote:
| Yep, it sounds like a plug:)
| chaostheory wrote:
| If I were to guess, a good chunk of office tasks that need to be
| automated are Excel related.
| Digitaltzar wrote:
| Yes, Excel is the ultimate data mashing/analysis tool for most
| of the office workers, especially in mid-market. Unfortunately,
| most users import data to Excel manually, collecting them
| across different systems and reports, and then manually uoload
| output of their data manipulation to web forms and legacy
| software, it seems unreal but people some time take a role of
| an interface between Excel and other systems. That's why we
| created visual tool for users to automate working with tables
| (from spreadsheets to databases) without coding, for some
| reason no other desktop automation software went that far with
| Excel/G-sheets.
| chaostheory wrote:
| Makes total sense - good luck guys
| Digitaltzar wrote:
| Thanks!
___________________________________________________________________
(page generated 2020-07-08 23:00 UTC)